Jó téma, napokig lehetne cikkezni róla. Konkrétan arról van szó, hogyan nyúl bele a tűzfal a legegyszerűbb adatáramlásokba is. Melyekről persze kiderül, hogy nem is olyan egyszerűek.
Az első sztorink egy világméretű hálózaton történt. Két Exchange organizáció között kellett Free/Busy szinkront összelőni. A túloldal Amerikában volt, jó nagy időeltolódással. A kommunikáció enélkül is igen nehézkesen ment, ilyen környezetben nem egyszerű összehozni egy élő kapcsolatot, hogy mind a két oldalon ott üljön a megfelelő mérnök és szinkronban taperolják a billentyűzetet.
Előtte határozottan felhívtam a tűzfalas kollégák figyelmét, hogy a két host között any-any kapcsolatot kérek az oldalunkon. Belső hálózatról van szó, épp elég lesz az F/B szinkronnal játszanunk, első körben nem szeretnénk, ha a tűzfal bekavarna. (Utána lehet majd szigorítani.) Megigérték, beállították.
Eljött az idő. Próbálkoztunk. Nem működött. Kiderült, hogy a túloldali tűzfalon mindösszesen néhány portot engedélyeztek, csak éppen ezt a portlistát elfelejtették közölni. Mi viszont az Exchange megfelelő szolgáltatását nem korlátoztuk konkrét portokra. Némi gondot jelentett, hogy az általuk engedélyezett portokat nálunk már más Exchange szolgáltatások használták. Hasraütve kiválasztottunk néhányat a környékről (6xxx), a túloldalon engedélyezték a tűzfalon, nálunk ugye nem kellett.
Továbbra sem működött a szinkronizáció. Izzadtunk még egy sort, majd kölcsönös és sűrű sorry-k mellett befejeztük a közös munkát. Majd legközelebb.
Másnap a biztonság kedvéért rákérdeztem a helyi biztonsági erőknél, hogy tényleg any-any lett-e beállítva? Mellékeltem a konkrét portszámot is. Erre kaptam egy olyan választ, hogy jojózott a szemem. Ugyanis a véletlenszerű porttal pont beletaláltam egy általam még csak soha nem is hallott protokoll tartományába, melyet a konkrét tűzfalon nem engednek át direktben, hanem proxyznak. Innentől jókedvű anyázásba fordult a levelezés, én próbáltam elmagyarázni, hogy az any-any azt jelenti, hogy a két host között minden kommunikáció transzparens, ők viszont ragaszkodtak ahhoz, hogy az any-any az egy beállítás a szabályon, de nem érinti a különböző protokollproxykat.
A vége az lett, hogy kerestünk egy olyan portot, amelyiken biztosan nincs semmi trükközés, a következő partira az amik módosították a náluk lévő tűzfal szabályát, be is indult a kommunikáció.
A második sztori nem sokkal ezután esett meg egy kollégámmal és kisértetiesen hasonlított az előzőre.
Ügyfélnél két telephely, két AD site. Mindkettőn vannak Exchange Hub Transport szerverek. A jelenség: nem mennek át a levelek. Ott állnak a várakozási sorban, és azt mondják, hogy a túloldali szerver nem képes az Exchange szerver autentikációra. (Lásd a korábbi cikk.) A tűzfalas kolléga szerint a hostok között a kért portok engedélyezve vannak.
Ami alapvetően igaz is volt, de amikor megpróbáltak telnetelni, elég érdekes válaszokat kaptak. Lényeg a lényeg, a tűzfalas úriember csak azt felejtette el közölni, hogy a készüléken be van kapcsolva a MailGuard, amelyik meglehetősen szigorú ellenőrzést gyakorol az smtp forgalom felett: egyedül a HELO, MAIL, RCPT, DATA, RSET, NOOP és QUIT parancsokat támogatja, minden más tiltott. Igen, már az ESMTP és az AUTH is.
Nyilván a kikapcsolás után beindult minden.
Recent Comments