Egy hétfői leállás története

hálózat illusztráció

Vasárnap este, 11 óra, beköltözés (nem én, hanem az 500+ felhasználóm), otthonról ránézek a statisztikára. A Munin szokatlan I/O aktivitást jelez a routeren. Számomra nem volt ez több, mint egy keményebb vasárnap este. Amúgy is, március 15, zavargások Budapesten, a Pam hurrikán lecsapott a Vanuatu szigetcsoportra, szóval van mit nézni és olvasni a neten.

Hétfő reggel, 7 óra 30 perc. Az egyik nem túl kellemes álmomból a telefonom ver fel, amiért most kivételesen nem haragszok… annyira. Munkahelyről keres a titkárnő, hogy használhatatlan a rendszer, kéri hogy siessek be vagy csináljak valamit távolról, mert rengeteg a tennivaló, dolgozni szeretne, de nem tud. A portárs szerint már este is akadozott. A rendszer jelenleg, felhasználói nyelvről lefordítva, a hálózatot és az internet-kapcsolatot jelenti.

Mondom oké, lássuk. Míg a gépem bootolt, addig én is elindítottam a startszekvenciámat, egy csésze kávé támogatásával. A bejelentkezés csont és lag nélkül ment, vagy csak szimplán átaludtam a műveletet. A Munin még mindig mutatta azt bizonyos I/O terhelést, ami amúgy nincs sehol. Már mint látszólag nincs, mert értem én, hogy van, de merre. A naplózás (legalábbis amit így távolról látok belőle) fura üzeneteket tartalmaz, mely szerint egy gép olyan csomagokat kapott, melynek ő a feladója… hmm… hétfő reggel, jól indul a hét!

Közelebbről megnézve a statisztikát, látszik, hogy négy hoston is szinte csontra ugyanaz az I/O terhelés van, többek közt a routeren is. Betörtek volna hozzánk? Megtámadtak volna minket? DDOS? Áh, minek tették volna, nincs semmi érdekes vagy mások számára annyira értékes információnk, hogy megérje egy ilyenbe belefogni, ráadásul hamarabb „tömődik el” a kimenő csövünk, minthogy azt bármi is megérezze odabent. Bot? Talán annyira azért követem a frissítéseket, hogy ezeknek ne sok esélyük legyen.

Megpróbáltam távolról szegmentálni a hibát, de nem igazán jutottam egyről a kettőre. Főleg, hogy ha megfeszülök se látok normálisan ki a DMZ-ből, csak a marginális rendszerekhez van korlátozott szintű elérésem, ami ez esetben elég nagy gond. Már megint ez a fránya kérdés: ha lazítok a DMZ-n, egyszerűbben tudok távolról dolgozni, de ezzel egy potenciális betörő munkáját is megkönnyíthetem. A VPN is törhető. Azzal nem vagyok előrébb, ha egy sorral kevesebbet gépelek, de ugyanazokkal a jogokkal rendelkezem. Ha a VPN a védett hálózatba továbbítana, akkor az a legrosszabb forgatókönyv szerint…, no ezért sincs VPN.

Néhány újraindítás és pár tűzfalszabály után jelentkezett egy kis placebo hatás, mikor úgy nézett ki, hogy buksisimi nélkül is „kibírja” a rendszer amíg beérek. A naplózás látszólag még mindig üres, bár a router is panaszkodik, hogy még mindig kap olyan csomagokat, melyeknek saját maga a feladója… Ezen a ponton még reménykedtem abban, hogy megbolondult valamelyik Realtek retek (lásd itt: hálókártya). Éppen ezért továbbra is abban bíztam, hogy egy újraindítás megoldja a dolgot…vagy egy teljes áramtalanítás. Először rombolni kell ugye, hogy építhessünk. Ja, mégsem. Csodálatos dolog az SSH, de nem csodafegyver, szóval irány be, már úgysem tudok mit tenni távolról.

Odabent azonnal világossá vált, hogy ez a probléma nem oldható meg egy teljes újraindítással. Első körben szemmel látható és füllel hallható volt, hogy a Munin nem hazudott. Nagyon tekertek a lemezek. Azonban periodikusan abbahagyták, majd újrakezdték.

A helyzet rosszabb volt, mint azt elsőre gondoltam, ugyanis a tekerős időszakban megszűnt minden. Megszakadt vagy botrányosan laggolt az SSH, elvesztek a pingek. A nyugis periódusok lehetőséget adtak arra, hogy bejelentkezzek a routerre és a többi érintett gépre, majd iotoppal figyelhettem (volna), hogy mire fel ez a nagy I/O, és amúgy is, mi a fene történik. Az iotop nem sokat mondott, mert pont akkor szakadt meg a kapcsolat, mikor megindult az I/O, bár a „csendes” időszakban azért sikerült leolvasnom, hogy miről is van szó: PostgreSQL és az Endian.

Talán DDOS? De miért történne? De ha mégis: miféle hatalmas tervezési malőr hibája az, hogy ennyi rendszert érint? A gondolat végére elcsendesült a vihar is, röptében lezártam minden bejövő portot, hátha megszűnik a jelenség. A káosz azonban nem váratott magára sokáig, mert az access logokig se jutottam el, és újra záporozni kezdtek a bitek. Dropbox! Frissült a Dropbox, biztos bugos lett a LAN Sync, így telespammeli a teljes hálózatot… Ha nem tud kinézni a netre, talán a LAN Sync se megy, szóval épp itt az ideje (és az időablak) kideríteni, hogy hogyan blokkoljam a Dropbox-ot. Leírtam egy kisokosban, hogyan kell, katt! (reklám helye). Nem jött be, a Dropbox blokkolása nem oldotta meg a gondokat.

A router panaszkodik, hogy olyan csomagokat kap, melynek ő a feladója. Az access logban semmi nincs, ami külső támadásra utalna, jelenleg pedig más „belépési pont” nincs. Tehát nem külső okok. Oké, akkor valaki biztos ki akar velem tolni és szándékosan a router IP címével konfigurálta fel a kütyüjét és most röhög a markában, hogy milyen ügyesen kitolt velem. Azonban mielőtt elkezdtem volna keresni a renitens eszközt egy kicsit meglepődtem.

A helyi gépen megjelent valamilyen adatforgalom. Pontosabban nem most jelent meg, csupán most tulajdonítottam neki nagyobb jelentőséget. Ugye logaritmikus a hálózati forgalmat mutató skála a Rendszerterhelés-indikátorban, így ránézésre nem tűnik fel, hogy pár KBit vagy GBit adatforgalmat bonyolítok. Lehet ez ugye bármi, aptd esetleg az unattended-upgrades élesedett…

A Rendszermonitor tisztázta a helyzetet, hogy itt bizony 100 MBitről van szó. A következő érdekességet a nethogs biztosította, ami megmondta, hogy nincs itt semmi látnivaló, az a pár szakadozó, SSH session generál pár KByte-nyi adatforgalmat és semmi más. Itt jött az első nagyobb „Mi a fene folyik itt?” felkiáltás. Magamban.

Wireshark über alles, avagy ha ő nem mondja meg, mi a gond, akkor semmi se. Ami elsőre feltűnt, hogy nagyon nagy a DHCP jellegű forgalom. Az átlagos, másodperenként 1-2 ilyen jellegű kommunikáció helyett 10-20, ráadásul teljesen logikátlan sorrendben követte egymást az discovery-offer-requesk-ack. Így kezdett előttem világossá válni, hogy miről is van szó:

Hálózati hurok

Ami a broadcast storm jelenséget avagy üzenetszórási vihart eredményezett. Joggal lehet feltételezni, hogy manapság minden értelmes switch tud STP-t, storm controlt és egyebeket, amivel kiszűrhettem volna ezt a gikszert (is). Nos, ami azt illeti, csak a hálózat gerincét alkotó switch beszéli ezt, a többi eszköznek közel sincs köze ilyen úri huncutságokhoz. Szóval megvan az ok, ami miatt a hálózat kinyiffant, már csak az okozat hiányzik.

Minden út a routerhez vezet, akárhányszor is kell a hurkon átmenni. Így elkezdtem nyomozni, megpróbálni legalább emeletre leszűkíteni a hibát. A BIO-Nagios-ok, (lásd itt: felhasználók) folyamatos hibajelentései közepette ez elég sürgető volt, szóval figyeltem a forgalmat és elkezdtem lekapcsolni a felvezető uplinkeket.

Legnagyobb meglepetésemre a probléma forrása a földszinten volt. Különösen érdekes, ugyanis mint utólag kiderült, van egy szoba, ahova két link is vezet. Az egyik egy „buta” switchből egy másik „buta” switch-be, a másik a gerincből egy fali csatlakozóba. Hogy ez a két link mikor, miért és milyen szándékkal lett kiépítve, nem tudom, de talán jobb is így.

Szóval, meg kellett határozni, hogy melyik a "kóbor" link. Kihúztam a fő uplinket, helyére ment egy laptop. Majd az „okos switch” CAM táblázatából csak ki kellett vadászni, hogy a laptop MAC-je melyik porton tűnik fel. Meg is lett. Port kihúz, uplink helyére, problem solved. A kérdéses szobában pedig elrendeztem mindent, így akarva-akaratlan sem sikerülhet újra egy hurkot létrehozni.

Tanulságok

  • A Munin 22:57 perckor kezdett el jelezni magas I/O műveletet, négy gépen. Ebből kettő a teszt DRBD szerver volt, a másik a router, a negyedik pedig a naplózó szerver. Az I/O oka nem más volt, mint a naplózás. Egyrészt minden DHCP kérés többszörösen futott be, amire többszörös válasz érkezett, amiket a router naplózott. Ezeket pedig ahogy tudta, továbbította a naplózó szervernek is, ami a DRBD-n csücsül és PostgreSQL-be naplóz.
  • A kora délutáni & késő délelőtti „nyugi” nem volt más, mint a hálózatra csatlakozott eszközök számának további csökkenése, így a broadcast-ekből adódó „zavar” csökkent ~ placebo hatás.
  • A naplózásban nem tűnt elsőre fel, hogy ugyanazok a dhcp kérések többször ismétlődnek, logikátlan sorrendben vannak. Ezt a későbbiekben fejben fogom tartani és gyanakodni fogok.
  • Sehol sem hagyunk még véletlenül sem plusz kábeleket, hogy az ördögnek ne legyen lehetősége galibát okozni (nem tisztünk kideríteni az „ok okát”, ugyanis nem vág az oldal profiljába. ;) (Ha végig Tony Stark Robert Downey Jr. játszaná Sherlockot nézném, de így…)
  • Végül, de messze nem utolsósorban, felül kell vizsgálni az STP és Storm Control (nem) működését a hálózatban.

Végül pedig most akadtam rá eme „szépségre” (itt), használjátok egészséggel!

Network Connection Protocols