A portellenőrzéstől a valódi protokollszintű monitoringig
Nyitott az SMTP port, mégsem válaszol a levelezőszerver
Egy levelezőszerver ellenőrzésénél könnyű azt hinni, hogy ha a 25-ös TCP-port elérhető, akkor az SMTP-szolgáltatás is megfelelően működik. A gyakorlatban azonban a kettő nem ugyanaz. Előfordulhat, hogy a TCP-kapcsolat szinte azonnal létrejön, miközben az SMTP-szerver csak több másodperc múlva küldi el a szabványos 220-as üdvözlő üzenetet. Egy rövid timeouttal dolgozó monitoring rendszer ezt már hibának érzékelheti, miközben maga a levelezés valójában működőképes.
Ez jó példa arra, miért nem elegendő egy szerveren egyszerűen azt ellenőrizni, hogy egy port nyitva van-e. A valódi szolgáltatásmonitoringnak a protokoll működését is vizsgálnia kell.
A nyitott 25-ös port még nem jelent működő SMTP-t
A legegyszerűbb ellenőrzés általában egy TCP-kapcsolat felépítése a levelezőszerver 25-ös portjára. Ha a kapcsolat sikerül, abból annyit tudunk biztosan, hogy a hálózati útvonal működik, a tűzfal átengedi a forgalmat, és valamilyen folyamat fogadja a kapcsolatot az adott porton.
Ez azonban még nem bizonyítja, hogy az SMTP-szolgáltatás megfelelően kommunikál.
Egy valódi SMTP-ellenőrzés ennél tovább megy. Megvárja a szerver üdvözlő üzenetét, majd szükség esetén SMTP-parancsokat is küld. Egy normál kapcsolat elején például a szerver egy 220 kezdetű választ küld, amelyből kiderül, hogy az SMTP-szolgáltatás valóban készen áll a kommunikációra.
Ha ez az üzenet nem érkezik meg időben, a TCP-port ugyan nyitott, de a monitoring rendszer SMTP-hibát fog jelezni.
Miért késhet az SMTP üdvözlő üzenete?
A késleltetésnek több oka is lehet, és nem mindegyik jelent műszaki hibát.
Levelezőszervereknél gyakoriak olyan védelmi mechanizmusok, amelyek szándékosan lassítják az ismeretlen vagy gyanús kapcsolatokat. A szerver például ellenőrizheti a kapcsolódó IP-cím reverse DNS rekordját, reputációját, különböző tiltólistákat vagy helyi spamvédelmi szabályokat.
Egyes rendszerek úgynevezett SMTP tarpitting technikát is alkalmazhatnak. Ennek lényege, hogy a szerver szándékosan lassabban kommunikál bizonyos kapcsolatfelépítések során. A spammerek automatizált rendszerei számára ez jelentősen csökkenti az egy idő alatt kiküldhető üzenetek számát, miközben a normál levelezőszerverek általában kivárják a választ.
Az ilyen működés miatt könnyen előfordulhat az a furcsa helyzet, hogy a 25-ös port ellenőrzése egy ezredmásodperc alatt sikerül, de az SMTP-protokoll szintű ellenőrzés csak 10–20 másodperc múlva kap választ.
A monitoring timeout helyes beállítása
A monitoring rendszerek többségében minden szolgáltatásellenőrzéshez tartozik egy időkorlát. Ha ezen belül nem érkezik megfelelő válasz, az ellenőrzés hibával tér vissza.
Nagios esetében például a check_smtp plugin nemcsak azt vizsgálhatja, hogy elérhető-e a port, hanem tényleges SMTP-kommunikációt is kezdeményez. Ha a szerver csak 20 másodperc után küldi ki a 220-as bannert, miközben a plugin timeoutja ennél rövidebb, akkor a monitoring CRITICAL állapotot fog mutatni.
Ez önmagában még nem jelenti azt, hogy növelni kell minden timeoutot.
Előbb meg kell érteni, mi okozza a késleltetést. Ha a szerver konfigurációjának normális része, akkor a monitoring időkorlátját ehhez lehet igazítani. Ha viszont korábban egy másodpercen belül válaszolt, majd hirtelen 20–30 másodperces késés jelent meg, az már olyan változás, amelyet érdemes kivizsgálni.
Portellenőrzés és szolgáltatásellenőrzés együtt
Megbízható monitoringnál érdemes különválasztani a hálózati és az alkalmazásszintű ellenőrzést.
A TCP-port ellenőrzése választ ad arra, hogy hálózati szinten elérhető-e a szolgáltatás. Az SMTP-ellenőrzés viszont azt mutatja meg, hogy maga a levelezőszoftver is kommunikál-e megfelelően.
A két eredmény együtt sokkal többet mond.
Ha a TCP/25 sem érhető el, akkor valószínűleg hálózati, tűzfal- vagy szolgáltatásindítási problémával állunk szemben. Ha a port elérhető, de nincs SMTP-válasz, akkor már szűkebb körben kereshetjük a hibát: Exim vagy más MTA állapota, DNS-ellenőrzések, spamvédelem, terhelés, processzek vagy konfigurációs problémák irányában.
Ez jelentősen lerövidítheti a hibakeresés idejét.
A levelezés állapota nem egyetlen ellenőrzésből áll
Egy üzleti levelezőrendszer monitoringját nem célszerű egyetlen zöld vagy piros SMTP-ellenőrzésre építeni.
A teljes képhez tartozhat az SMTP mellett az IMAP vagy IMAPS elérhetősége, a levélsor mérete, a háttértár szabad kapacitása, a DNS és MX rekordok működése, valamint a kiszolgáló terhelése is.
Különösen fontos a mail queue figyelése. Egy SMTP-szerver kívülről tökéletesen válaszolhat, miközben a kimenő levelek valamilyen probléma miatt órák óta sorban állnak. Ilyenkor a felhasználó azt látja, hogy elküldte a levelet, a valódi kézbesítés azonban nem történik meg.
Ugyanez fordítva is igaz: egy rövid ideig lassabban válaszoló SMTP-szerver nem feltétlenül jelent tényleges levelezési kiesést.
Miért jobb a protokollszintű monitoring?
A monitoring célja nem az, hogy minél több zöld ikon legyen egy felületen. A cél az, hogy olyan ellenőrzéseket használjunk, amelyek valóban a felhasználók által igénybe vett szolgáltatások működését mutatják.
Ezért egy webkiszolgálónál nem csak a 443-as portot érdemes ellenőrizni, hanem HTTP vagy HTTPS választ is. DNS-nél nem elég az 53-as port: valódi DNS-lekérdezést kell indítani. SMTP-nél pedig ugyanígy nem elég a 25-ös port elérhetősége.
A jól felépített Nagios vagy Zabbix monitoring több rétegben vizsgálja ugyanazt az infrastruktúrát. Így egy riasztásból sokkal gyorsabban eldönthető, hogy hálózati problémáról, kiszolgálóhibáról vagy konkrét alkalmazásszolgáltatás hibájáról van-e szó.
A megfelelő riasztás fontosabb, mint a sok riasztás
A túl érzékenyre állított monitoring hamar használhatatlanná válik. Ha egy normális, ismert SMTP-késleltetés miatt néhány percenként CRITICAL riasztás érkezik, az üzemeltető idővel figyelmen kívül fogja hagyni a jelzéseket.
Ez veszélyesebb lehet, mint maga a kezdeti rossz beállítás.
A küszöbértékeket ezért mindig a tényleges rendszer működéséhez kell igazítani. A cél az, hogy egy valódi eltérés jelezzen, az ismert és elfogadható működés pedig ne generáljon felesleges incidenst.
Egy jól beállított monitoring rendszer nem egyszerűen azt mondja meg, hogy egy gép „él-e”. Azt próbálja megállapítani, hogy az adott üzleti szolgáltatás ténylegesen használható-e.
Összegzés
A nyitott SMTP-port és a működő levelezőszerver nem ugyanaz. A TCP/25 sikeres kapcsolata csak a hálózati elérhetőséget bizonyítja, miközben a tényleges SMTP-kommunikáció külön ellenőrzést igényel.
Ha egy szerver lassan küldi ki a 220-as SMTP bannert, először az okot kell megérteni, majd ennek megfelelően lehet beállítani a monitoring timeoutját. A portellenőrzés, a protokollszintű SMTP-check, a levélsor figyelése és a szerver állapotának monitorozása együtt ad használható képet a levelezési szolgáltatás valódi állapotáról.
Az 1B Telecom rendszerüzemeltetési és monitoring feladataiban ezért nemcsak azt vizsgáljuk, hogy egy szerver elérhető-e, hanem azt is, hogy a rajta futó szolgáltatások ténylegesen válaszolnak-e. Nagios és Zabbix alapú felügyelettel a webes, levelezési, DNS-, hálózati és mentési folyamatok külön is ellenőrizhetők, így egy hiba sokszor már azelőtt láthatóvá válik, hogy abból felhasználói probléma lenne.