Mit tehetünk akkor, ha a feladatunk a világ másik végén lévő telephely LAN-jának minél alaposabb feltérképezése, és nincs semmiféle dokumentáció, amivel neki lehetne kezdeni a feladatnak? A helyi IT-s munkaerő nem ismeri igazán a hálózati eszközöket, ha kell, néhány alapvető dolgot -- hostname, IP, default gateway, admin jelszó -- be tud állítani webes felületen, de itt nagyjából kimerül a szakértelem.
Ilyenkor az lenne a legjobb, ha az ember csak ráeresztene valami okos szoftvert a megfelelő subnetre, az meg minden kis információmorzsát felcsipegetne, benézne ide is, oda is, HTTP-n, HTTPS-en, telneten, SSH-n, SNMP-n, amelyiken éppen lehet, végül kiadna egy részletes layer 2-es topológia ábrát hostnevekkel, IP-kkel, portszámokkal, az eszközök típusával, meg minden. A valóság ezzel szemben az, hogy nem véletlenül jut el a világnak erre a felére a probléma, az adott telephelyen a LAN eszközök nincsenek egységesen konfigurálva, különböző felhasználónevek és jelszavak vannak rajtuk beállítva (ha egyáltalán be van állítva valami), több különböző gyártótól valóak, vicces hurkokat kötöttek rájuk, némelyiknek még IP-je sincs.
A tipikusan ilyesmire használt gyártóspecifikus szoftverek, mint amilyen régi kedvencem, a 3Com Network Director (3ND) vagy újabban az azt felváltó HP Intelligent Management Center - IMC (bár szerintem ez kissé nehézkesre sikeredett) vagy a Nortel Enterprise Switch Manager vagy a Cisco Network Assistant nem igazán rúgnak labdába ilyen helyzetben, és soha nem lesz pontos az, amit kiköpnek magukból egy discovery után, de azért kiindulási alapként nem feltétlenül rossz az. Jelenleg épp a 3ND és a Cisco Network Assistant volt kéznél, gondoltam kipróbálom, mire mennek.
A menedzsment szoftverek alternatívájaként pedig ott a CLI-s buherálás, első körben nmap-pel kiszűrhetők az adott subnetben lévő gyanús hostok: a már említett protokollok portjai közül legalább egy nyitva van, szerencsésebb esetben több is (TCP-80, TCP-22, TCP-23, TCP-443, UDP-161), ezekről listát készít az ember, összeszedi a helyi IT-től előzetesen begyűjtött jelszavakat, majd jöhet a favágás: megpróbálni belépkedni mindenhova. A sikeres műveletekről táblázat készül, hogy egy adott IP adott portján mivel lehetett belépni. Ha a subnet elfogyott, akkor jó eséllyel a legtöbb távolról adminisztrálható eszközt sikerült azonosítani, így már csak a köztük lévő kapcsolatokat kell feltérképezni. A kapcsolatok feltérképezésében óriási segítség a CDP, NDP vagy egyéb hasonló protokoll által begyűjtött információ, ám nem mindig elegendő. A végső megoldás annak megállapítására, hogy mely portra van kötve egy-egy eszköz, a CAM tábla nézegetése. Ha sikerült bejutni már akár csak egyetlen eszköz parancssorába, onnantól a subnet összes hostjának MAC címét meg tudjuk keresni, egy ping után ott lesz az ARP táblánkban. Az ARP táblából kikeresett MAC címet utána már megleljük a CAM táblában is, és ha kell, switchről switchre, CAM tábláról CAM táblára végig lehet követni addig a portig, ahová az adott eszköz ténylegesen be van dugva. A CAM tábla további előnye, hogy megmutatja az összes csatolt switchet, hubot: ha azt látjuk a CAM táblában, hogy mondjuk az Fa0/8-as porton 13 MAC címet tanult be az eszközünk, akkor biztosak lehetünk benne, hogy a 8-as porton lóg még valamilyen hálózati eszköz, akár mutatja a CDP neighbor-ök közt a switchünk, akár nem (leszámítva az olyan extrém eseteket, mint például a virtual hostok, ahol virtuális a switch is). Végül a CLI-ben elérhető STP, LACP információk alapján pontosíthatjuk a topológiát, bejelölve a redundáns linkeket is. Hát, ez a kézi módszer, sziszifuszi meló, az biztos.
No, de hogy valami érdekes is jusson végére, az említett telephely feltérképezését megcsináltam 3ND-vel, Cisco Network Assistant-tal és kézzel is. Amint az utólag kiderült, a telephelyen az eszközök többsége Cisco volt, szóval a 3ND-nek eleve nem voltak nagy esélyei. Gondoltam érdemes az eredményeket számszerűsíteni is, ha a layer2-es topológia gráfjának minden megtalált éle és csúcsa egy-egy pontnak számít (az élek estén szükségesek a portok információi is a ponthoz, pl. egyik eszköz Gi1/0/2-ről megy a másik Gi0/1-re), akkor a következő eredmények születtek:
A kézi módszerrel 41 pontot sikerült elérni, 21 csúcs és 20 él került fel a topológia ábrájára (semmi redundancia), ez összesen 16 Cisco eszközt jelent, egy 3Com eszközt és négy közelebbről nem azonosítható, feltehetően unmanaged switchet. Természetesen messze ez a módszer igényli a legtöbb időt, a management szoftverek néhány vagy néhány tíz perces discovery idejéhez képest itt több óráról van szó.
A Cisco Network Assistant 20 pontot gyűjtött, a 16 Cisco eszközből 11-et megtalált, köztük egy olyat is, mely csak a CDP neighbor-ök közt volt megtalálható, egyébként nem volt IP cím beállítva rajta. A többi Cisco eszközre különféle okokból nem tudott bejelentkezni, az egyik például szolgáltatói eszköz volt az ötből, amelyhez nincs jelszavunk, a maradék négy Cisco eszközökhöz pedig csak Telnet hozzáférés volt, amit nem tudott használni, míg az egyéb (nem Cisco) eszközöket pedig hivatalból ignorálta. De legyünk méltányosak a programhoz, az általa megrajzolt topológia pontos volt, nem húzott be téves éleket a gráf csúcsai közé, minden teljesen egybevágott az eszközökből kinyerhető CDP információkkal, így sokat segített a kézi módszer felgyorsításában, ellenőrzésében.
A 3Com Network Director meglepetésre 21 pontot ért el, összesen 16 eszközt talált meg (ugye emlékszünk: a maradék 5 eszköznek nincs IP címe!), ám csak 5 kapcsolatot fedezett fel az eszközök közt helyesen, a többi eszköz fura felhőkön keresztül csatlakozott vagy csak úgy lógott a levegőben. Vitathatatlanul ez volt a legzajosabb módszer, számos nyomtató és egyéb SNMP-képes eszköz bukkant fel a topológiában, igaz ezeket nem volt nehéz kiszűrni.
A végső találati arányokat még sajnos nem tudom, ugyanis nemrég küldtem el a helyi IT-snek ellenőrzésre a kézi módszerrel összeállított topológiáról a Visio ábrát, amit ki fog egészíteni/javítani a tényleges állapotoknak megfelelően. Remélhetőleg a 41 pont nem lesz messze a valós értéktől...
A következő címkéjű bejegyzések mutatása: tervezés. Összes bejegyzés megjelenítése
A következő címkéjű bejegyzések mutatása: tervezés. Összes bejegyzés megjelenítése
2011-04-13
2011-03-02
DHCP relay agent NAT-olt hálózatban: esélytelen
Adott egy telephelyünkön egy több subnetre osztott LAN, minden subnetben a LAN router a DHCP relay agent, ez így eddig tiszta sor, semmi meglepő nincs benne. Na most vannak persze olyan subnetek is ezen a telephelyen, amelyek nincsenek Layer 3 összeköttetésben a telephely egyéb részeivel, ezer oka lehet, a legtöbb persze nem szakmai, mindenesetre ilyesmi dolgot kell elképzelni:
A gondok természetesen akkor kezdődnek, amikor a 192.168.1.0/24-ben mégiscsak akadnak hostok amelyek a többi subnettel kommunikálnának. Persze ilyenkor a network admin kaján vigyorral közli, hogy látjátok-látjátok, nem kellett volna azt a subnetetet így oda tenni, megmondtuk mi annak idején, hogy olyan hálózatot válasszatok, ami illeszkedik a globális címzési rendszerünkbe és a telephelyen használt supernetben benne van.
Aztán a vigyor, meg a címzési tervek gyorsan eltűnnek, amikor kiderül, hogy itt most nem "légből kapott", "ködös" elvekhez kell ragaszkodni, hanem a felmerülő üzleti igényeket kell gyorsan, pontosan kiszolgálni, és nincs apelláta: a 192.168.1.0/24-nek tudnia kell kommunikálni, most, nincs sem idő, sem erőforrás, sem hajlandóság az utált subneten belüli 150+ statikus IP-s hoston címváltásra (vagyis nem lehet belőle semmilyen körülmények közt sem pl. 10.10.15.0), és igazából csak a VLAN99-ből kell elérni egy-két külső dolgot, "hát már ennyit sem lehet rátok bízni?" stb.
Száz szónak is egy a vége, meg kell patkolni, egy végzetes napon a VLAN99 NAT-olva rácsatlakozik a VLAN10-re. Aztán jönnek az újabb és újabb problémák, amelyek fel sem merülnének ugye, ha a VLAN99 rendes subnet lenne, olyanok például, hogy egyik-másik adatbázis szervert a VLAN99-ben mégiscsak el kellene érni kívülről, legyen port forward, ezt ide, azt oda, akkor persze jön a kérdés, hogy miért nem lehet a belső adatbázis-szervereket kívülről pingelni, aztán újabb és újabb port forwardok, persze az egész rögtön biztonsági kérdéseket is felvet, mert természetesen a VLAN99-ben nincs szabványos kliensvédelem, hiszen az úgyis "szeparált", szóval egy-két év alatt ebből egy teljesen dokumentálatlan össze-vissza rugdosott rendszert lehet felépíteni, amihez senki nem nyúl szívesen, akik meg használják, elégedetlenek.
Na, most ott tart a dolog, hogy a VLAN99-ben be kellene vezetni a központi DHCP szolgáltatást, és persze sikerült ráfutni a DHCP relay agent beüzemelése közben egy elég alapvető problémára: NAT-olt hálózat felé nem fog menni a relayezés, hiszen a relay agent még csak kiküldi a VLAN99-ből a DHCP üzeneteket a DHCP szerver felé, azonban a relay agent és a DHCP szerver közt már unicast forgalom zajlik, amely kommunikációban a relay agent a belső, a DHCP szervertől távolabbi lábának az IP-jével vesz részt (pl. 192.168.1.1), így a DHCP szerver hiába küldené vissza a választ a default gatewayen... Persze így vagy úgy folytatódni fog a hályogkovácsolás, át lehet azt a DHCP-t küldeni ezer más módon.
Az egészben a legbosszantóbb, hogy az üzleti oldal még mindig, sok év után sem látja, hogy itt az alapkoncepció hibás, ugyanakkor újabb és újabb dolgokat építene az ingatag alapokra. Erős IT-t szeretnék, ahol nem engedik ki az IT kezéből az IT-ra tartozó döntéseket.
A gondok természetesen akkor kezdődnek, amikor a 192.168.1.0/24-ben mégiscsak akadnak hostok amelyek a többi subnettel kommunikálnának. Persze ilyenkor a network admin kaján vigyorral közli, hogy látjátok-látjátok, nem kellett volna azt a subnetetet így oda tenni, megmondtuk mi annak idején, hogy olyan hálózatot válasszatok, ami illeszkedik a globális címzési rendszerünkbe és a telephelyen használt supernetben benne van.
Aztán a vigyor, meg a címzési tervek gyorsan eltűnnek, amikor kiderül, hogy itt most nem "légből kapott", "ködös" elvekhez kell ragaszkodni, hanem a felmerülő üzleti igényeket kell gyorsan, pontosan kiszolgálni, és nincs apelláta: a 192.168.1.0/24-nek tudnia kell kommunikálni, most, nincs sem idő, sem erőforrás, sem hajlandóság az utált subneten belüli 150+ statikus IP-s hoston címváltásra (vagyis nem lehet belőle semmilyen körülmények közt sem pl. 10.10.15.0), és igazából csak a VLAN99-ből kell elérni egy-két külső dolgot, "hát már ennyit sem lehet rátok bízni?" stb.
Száz szónak is egy a vége, meg kell patkolni, egy végzetes napon a VLAN99 NAT-olva rácsatlakozik a VLAN10-re. Aztán jönnek az újabb és újabb problémák, amelyek fel sem merülnének ugye, ha a VLAN99 rendes subnet lenne, olyanok például, hogy egyik-másik adatbázis szervert a VLAN99-ben mégiscsak el kellene érni kívülről, legyen port forward, ezt ide, azt oda, akkor persze jön a kérdés, hogy miért nem lehet a belső adatbázis-szervereket kívülről pingelni, aztán újabb és újabb port forwardok, persze az egész rögtön biztonsági kérdéseket is felvet, mert természetesen a VLAN99-ben nincs szabványos kliensvédelem, hiszen az úgyis "szeparált", szóval egy-két év alatt ebből egy teljesen dokumentálatlan össze-vissza rugdosott rendszert lehet felépíteni, amihez senki nem nyúl szívesen, akik meg használják, elégedetlenek.
Na, most ott tart a dolog, hogy a VLAN99-ben be kellene vezetni a központi DHCP szolgáltatást, és persze sikerült ráfutni a DHCP relay agent beüzemelése közben egy elég alapvető problémára: NAT-olt hálózat felé nem fog menni a relayezés, hiszen a relay agent még csak kiküldi a VLAN99-ből a DHCP üzeneteket a DHCP szerver felé, azonban a relay agent és a DHCP szerver közt már unicast forgalom zajlik, amely kommunikációban a relay agent a belső, a DHCP szervertől távolabbi lábának az IP-jével vesz részt (pl. 192.168.1.1), így a DHCP szerver hiába küldené vissza a választ a default gatewayen... Persze így vagy úgy folytatódni fog a hályogkovácsolás, át lehet azt a DHCP-t küldeni ezer más módon.
Az egészben a legbosszantóbb, hogy az üzleti oldal még mindig, sok év után sem látja, hogy itt az alapkoncepció hibás, ugyanakkor újabb és újabb dolgokat építene az ingatag alapokra. Erős IT-t szeretnék, ahol nem engedik ki az IT kezéből az IT-ra tartozó döntéseket.
2011-01-19
A szórási tartományok méretéről
Néhány éve, amikor elkezdtem a jelenlegi munkahelyemen dolgozni, egyszerűen sokkolt a gondolat, hogy azon a telephelyen, ahol én is ügyködni fogok, teljesen strukturálatlan a LAN layer3-ban. Az adott telephely legtöbb munkaállomása, a notebookok, a nyomtatók, a szerverek, a termelési gépek, az ilyen-olyan célhardverek, biszbaszok, beágyazott rendszerek, a hálózati eszközök management felülete, a szerverek iLO/RMC portjai, de még a céges wifi is egyetlen nagy /21-es hálózatban élt egymás mellett.
Komolyan azt gondoltam, hogy itt vége a világnak, hogy ez maga a fertő, a networkös pokol. Persze tudtam, hiszen korábban az interjúk során is elmondták, hogy az alkalmazásom egyik oka épp ez, hogy vannak úgymond anomáliák ezen a telephelyen, amiket meg kellene oldani, és hogy addig nem volt teljes állásban hálózatos ember. Mondanom sem kell ugye, minden létező szakkönyv szerint ellenjavallt az ilyen bazi nagyra felhízlalt broadcast domain, amiben még a legcsendesebb éjszakákon is működget nagyjából 1000 host, de volt olyan időszak, amikor a /21-es hálózat 2000-es gépszáma is elérhető távolságba került.
Most már lassan három éve élek együtt ezzel a dinoszaurusszal a munkahelyemen, és persze az évek során számos dolog letisztult, nagyon sok host, sok munkával, szervezéssel külön VLAN-okba került, innen is csippentettünk egy kicsit, onnan is, ezeknek a hostoknak ilyen VLAN, amazoknak amolyan került, de alapvetően a harminc-egynéhány VLAN mellett a /21-es nagy hálózat ma is létezik, rengeteg benne a gazdátlan, fix IP-s host, melyek adminisztrációjával senki nem akar törődni, egészen addig, míg nincs vele valami baj, szóval a telephely életébe, működésébe szó szerint ezer szállal bele van fűzve a /21-es monstrum.
Azt gondolná az ember, hogy az elképzelhetetlen mennyiségű broadcast forgalom miatt itt nincs egyetlen ép host sem, de a helyzet valójában nem annyira vészes. A broadcast forgalom legnagyobb része egyébként az SMB/CIFS balgaságaiból adódik, rettenetesen szószátyár ez a protkollcsalád, és persze nálunk is SMB/CIFS-et natívan beszélő Microsoft OS-ek vannak leginkább a hostokon. De még ennek ellenére is az átlagos broadcast terhelés nagyából megáll 50-70 kbit/s környékén. Multicastot nem használunk, az egyetlen dolog, ami még rondíthat ezen az 50-70 kbit/s-on, az az elárasztásos (flood) forgalom. Ilyen floodként jelentkezik a switchek által nem ismert MAC-címre történő forgalmazás, amit a broadcast domain minden hostja megkap, mert a switch nem tudja, hogy melyik portjára switchelje, így kiteszi mindegyikre - sajnos vannak olyan "megoldások", amelyek építenek is erre az egyébként nem kívánatos jelenségre.
Hogy mit tapasztalhat az ember 50-70 kbit/s állandó broadcast mellett? Semmit. Nevetségesen kicsi ez a forgalom az elérhető 100 vagy 1000Mbit/s-os sebességhez viszonyítva, nincs érezhető, mérhető hatása a hostok működésére. Sajnos emiatt a döntéshozók sem értik meg az IP szegmentáció mielőbbi szükségességét. Biztos vagyok benne, hogy még csak nem is feszegetjük a technológia határait, és hogy egy hostokkal megpakolt /20-as vagy akár egy /19-es is működőképes lenne.
Azt azért nem állítom, hogy soha nincs gond egy ilyen méretű hálózattal alapvetően magára a méretére visszavezethető okok miatt. Egyszer például néhány kolléga úgy látta jónak, ha Norton Ghosttal, anélkül, hogy bármilyen hálózati támogatás lett volna hozzá, multicast üzemmódban terítenek image-eket néhány gépen. A switchek persze azonnal broadcastba fordították a multicast forgalmat, és tolták minden portjukon, ami csak a csövön kifért. Na, ezt már mindenki megérezte, 80 Mbit/s egy ekkora hálózat minden portján azonnal látványos eredmény ad. De ez egy extrém példa, és nem áll neki bárki multicast Ghost terítésnek, viszont látható, hogy ha a napi rutinfeladatokon nem is vérzik el a nagy szórási tartomány, biztonsági szempontból semmiképp nem javasolt.
Meggyőződésem, hogy amennyiben valaha is megszűnik ezen a telephelyen a /21, az biztonsági problémák miatt lesz. Gondoljunk csak bele, hogy egy ekkora szórási tartomány micsoda lehetőségeket tartogat a különféle layer2-es támadásokra, ARP spoofingra, STP támadásokra, de még egy egyszerű passzív broadcast forgalom gyűjtögetés is rengeteg értékes információval szolgál.Őszintén szólva nem is szeretek rá csatlakozni, inkább megyek wifin, ami azóta külön subnetbe került vagy remote access VPN-en (szintén külön subnet). Csak a kollégáim meg ne tudják... (tudják) :)
Komolyan azt gondoltam, hogy itt vége a világnak, hogy ez maga a fertő, a networkös pokol. Persze tudtam, hiszen korábban az interjúk során is elmondták, hogy az alkalmazásom egyik oka épp ez, hogy vannak úgymond anomáliák ezen a telephelyen, amiket meg kellene oldani, és hogy addig nem volt teljes állásban hálózatos ember. Mondanom sem kell ugye, minden létező szakkönyv szerint ellenjavallt az ilyen bazi nagyra felhízlalt broadcast domain, amiben még a legcsendesebb éjszakákon is működget nagyjából 1000 host, de volt olyan időszak, amikor a /21-es hálózat 2000-es gépszáma is elérhető távolságba került.
Most már lassan három éve élek együtt ezzel a dinoszaurusszal a munkahelyemen, és persze az évek során számos dolog letisztult, nagyon sok host, sok munkával, szervezéssel külön VLAN-okba került, innen is csippentettünk egy kicsit, onnan is, ezeknek a hostoknak ilyen VLAN, amazoknak amolyan került, de alapvetően a harminc-egynéhány VLAN mellett a /21-es nagy hálózat ma is létezik, rengeteg benne a gazdátlan, fix IP-s host, melyek adminisztrációjával senki nem akar törődni, egészen addig, míg nincs vele valami baj, szóval a telephely életébe, működésébe szó szerint ezer szállal bele van fűzve a /21-es monstrum.
Azt gondolná az ember, hogy az elképzelhetetlen mennyiségű broadcast forgalom miatt itt nincs egyetlen ép host sem, de a helyzet valójában nem annyira vészes. A broadcast forgalom legnagyobb része egyébként az SMB/CIFS balgaságaiból adódik, rettenetesen szószátyár ez a protkollcsalád, és persze nálunk is SMB/CIFS-et natívan beszélő Microsoft OS-ek vannak leginkább a hostokon. De még ennek ellenére is az átlagos broadcast terhelés nagyából megáll 50-70 kbit/s környékén. Multicastot nem használunk, az egyetlen dolog, ami még rondíthat ezen az 50-70 kbit/s-on, az az elárasztásos (flood) forgalom. Ilyen floodként jelentkezik a switchek által nem ismert MAC-címre történő forgalmazás, amit a broadcast domain minden hostja megkap, mert a switch nem tudja, hogy melyik portjára switchelje, így kiteszi mindegyikre - sajnos vannak olyan "megoldások", amelyek építenek is erre az egyébként nem kívánatos jelenségre.
Hogy mit tapasztalhat az ember 50-70 kbit/s állandó broadcast mellett? Semmit. Nevetségesen kicsi ez a forgalom az elérhető 100 vagy 1000Mbit/s-os sebességhez viszonyítva, nincs érezhető, mérhető hatása a hostok működésére. Sajnos emiatt a döntéshozók sem értik meg az IP szegmentáció mielőbbi szükségességét. Biztos vagyok benne, hogy még csak nem is feszegetjük a technológia határait, és hogy egy hostokkal megpakolt /20-as vagy akár egy /19-es is működőképes lenne.
Azt azért nem állítom, hogy soha nincs gond egy ilyen méretű hálózattal alapvetően magára a méretére visszavezethető okok miatt. Egyszer például néhány kolléga úgy látta jónak, ha Norton Ghosttal, anélkül, hogy bármilyen hálózati támogatás lett volna hozzá, multicast üzemmódban terítenek image-eket néhány gépen. A switchek persze azonnal broadcastba fordították a multicast forgalmat, és tolták minden portjukon, ami csak a csövön kifért. Na, ezt már mindenki megérezte, 80 Mbit/s egy ekkora hálózat minden portján azonnal látványos eredmény ad. De ez egy extrém példa, és nem áll neki bárki multicast Ghost terítésnek, viszont látható, hogy ha a napi rutinfeladatokon nem is vérzik el a nagy szórási tartomány, biztonsági szempontból semmiképp nem javasolt.
Meggyőződésem, hogy amennyiben valaha is megszűnik ezen a telephelyen a /21, az biztonsági problémák miatt lesz. Gondoljunk csak bele, hogy egy ekkora szórási tartomány micsoda lehetőségeket tartogat a különféle layer2-es támadásokra, ARP spoofingra, STP támadásokra, de még egy egyszerű passzív broadcast forgalom gyűjtögetés is rengeteg értékes információval szolgál.Őszintén szólva nem is szeretek rá csatlakozni, inkább megyek wifin, ami azóta külön subnetbe került vagy remote access VPN-en (szintén külön subnet). Csak a kollégáim meg ne tudják... (tudják) :)
Feliratkozás:
Bejegyzések (Atom)