Előfeltételek

Akárhol is helyezkedik el a levelező szerverünk, egy biztos: nem fognak kijutni és betalálni a levelek, amennyiben a DNS konfigurációnk nincs korrektül rendezve. A sulineten belül a központi DNS szerverekben minden intézmény számára be van jegyezve a szükséges MX (Mail eXchanger) rekord, amely elárulja az interneten működő levelezőszervereknek, hogy a mi szerverünknek mi az IP címe, tehát hogyan található meg. Sőt a reverse DNS zónákban is van egy-egy bejegyzés, amely fordítva (DNS név > IP cím) is rendezi a helyzetet. Az intézményekben csak annyit kell biztosítani, hogy ez az IP cím legyen a tűzfal külső hálózati interfészének a címe. Hivatkozni többféleképpen lehet erre az IP címre, hiszen (szintén központilag) a server.iskola_neve.sulinet.hu cím mellett, a "mail", a "www" és az "ftp" aliasok is be vannak jegyezve.

Ami még fontos, az az hogy, a belső hálózatunkban (vagy éppen az ISA-n) működő levelező szerverünk (pl. az Exchange), a legközelebbi külső DNS szerver felé route-oljon (ha van saját _külső_ DNS szerverünk akkor oda), azaz ide küldje tovább az e-mail-eket. Ezt egy Windows 2000/2003 tartományban pl. a belső hálózaton működő DNS szerver továbbitó (forwarder) funkciójával tudjuk elérni, úgy, hogy a belső DNS szerver(ek) az általuk nem feloldható címeket továbbküldik automatikusan az általunk beállított külső DNS szervernek (ezek a sulinetes root DNS szerverek lesznek, pl. tudomásom szerint Pest megyében és Budapesten a bp.sulinet.hu és/vagy a központi a core.sulinet.hu). A DNS szerver továbbító funkciójáról ebben a cikkben esett szó bővebben. Ha ez rendben van és jól működik az ISA is, akkor mind a befelé, mind a kifelé irányuló forgalom zavartalan lesz, bár az ISA Server rajta tartja ezen a forgalmon a "szemét". Nézzük, ehhez mit kell tennünk a két alapesetben (belső és az ISA-n működő mailszerver esetén).

Belső mailszerver publikálása

A levelezőszerver publikálása kicsit más mint a web- és ftp szerveré, bár ennek a varázslónak az indítása is a Publishing pont alól kezdődik.

1. A Publishing fülön kattintsunk a jobb gombbal és válasszuk a Secure Mail Server... menüpontot!
2. Az üdvözlő képernyő után a Mail Services Selection panelen válasszuk ki a megfelelő, általunk használt szolgáltatásokat. Szabjuk szűkre a választást, felesleges kiválasztanunk azokat az opciókat amelyeket nem használunk. Az "Apply content filtering" csábítóan hangzik, de ha nem készítettük elő (kell hozzá pár feltétel), természetesen nem fog működni, tehát szintén hagyjuk üresen. Az SSL Authentication oszlopban csak akkor jelöljünk be bármit is, ha mind szerver-, mind kliens oldalon rendelkezésre állnak az SSL használatához szükséges feltételek (pl. a tanúsítványok).
   
   

   A szükséges Exchange protokollok kiválasztása itt történik
3. A következő panelen az ISA külső IP címét kell megadnunk (amire a fent emlegetett MX rekord mutat).
4. Ezután a LAT-ban szereplő belső Exchange szerver IP címét kell megadunk a panel felső részében ("At this IP address"). Ha ez megvan, immár csak az összegző képenyő maradt.
   
   

   Belső vagy az ISA-n lévő levelező szerverről van szó?
   Ha kész vagyunk a varázslóval, nézzünk be a Publishing > Server Publishing Rules menüpontba, fogunk látni számos "Mail Rule Wizard"-al kezdődő bejegyzést, amelyeket most készítettünk el a varázslóval. Ha valami nem stimmel, akár rögtön akár, később, ezeket törölve újra publikálhatjuk a levelezőszervert.

További nagyon lényeges tudnivaló, hogy szöges ellentétben a Proxy 2.0 szerverrel, az Exchange szerver számítógép ISA esetén semmiféleképp nem lehet tűzfal kliens, csak SNAT!

Mailszerver publikálás az ISA-n

Ez az eset szintén akkor fordulhat elő, ha az Exchange szerver az ISA szerver számítógépre van telepítve. Ekkor a fent említett Exchange és DNS követelmények és beállítások változatlanok, és igazából a publikáló varázsló lépései is hasonlóak, csak egy panelen van különbség, mégpedig a 4. pontban. Ekkor az "At this IP address helyett" válasszuk a "On the local host" opciót. Ez a változás két különbséget, pontosabban két hiányosságot okoz az Exchange szerver és az ISA kapcsolatában, amiről rögtön e lépés után kapunk is figyelmezetést.

1. Az ISA Server Message Screener (ami egy egészen korrekt, beépített e-mail szűrő) funkcióját elveszítjük. Ez a Message Screener működéséből adódik, ugyanis ez egy olyan SMTP szervert kívánna meg pluszban az Exchange szerveren kívül, amely az ISA-n működik. Amikor az Exchange küld vagy kap egy e-mailt, ennek az SMTP szervernek küldi el, illetve ettől kapja meg, így az ISA külön tudja kontrollálni ezt az SMTP szervert. Ha az Exchange az ISA-n van, akkor megéegy SMTP szerver nem telepíthető, ergo ez a funkció nem használható.
2. Az Exchange RPC (Remote Procedure Call - Távoli eljáráshívás) szolgáltatása az ISA-n telepített és publikálni kívánt Exchange szervernél. Ez egy beépített limitáció, amely megakadályozza, hogy az Outlook MAPI kliensek távolról elérjék az ISA-n működő Exchange Server-t.

Ezután már csak az összegző képernyő van hátra. A varázsló által készített csomagszűrőket (merthogy ebben az esetben ezek készülnek, mivel az ISA Server számítógépen működő szolgáltatásról van szó), megtekinthetjük az Access Policy/IP Packet Filters alatt.