Tag: network

Tipikus

Az a mém megvan, hogy ‘váratlanul megjavult magától’?

Trust kapcsolat egy multi két leányvállalata között. A végpontok különböző országokban, a központ meg valahol Európában. Egyszer csak ügyfél jelzi, hogy nem működik a trust. Megnézem, tényleg.
Network ellenőrzés, kiderül, hogy valahol blokkolják az udp389-et. Levél elmegy mindegyik országba, plusz a központba: – Uraim, nézzenek utána, mi van a tűzfalakon/routereken? Levelek vissza. Kivétel nélkül mindenhonnan azt írják, hogy leellenőrizték és a port mindenhol engedélyezve van.

Csak éppen onnantól megint működik a trust.

Hát, megtörtént

Tudom, index cikket nem linkelünk, mert az mindenki olvassa, aki meg nem, az utálja. De most, a hír érdekessége miatt mégis kivételt teszek. Évtizedek óta mondogatjuk, hogy elfogy a kőolaj. Aztán mindig találnak valahol még egy kicsit. És évtizedek óta mondogatjuk, hogy elfogynak az IPv4 címek – amíg aztán tényleg elfogytak.

Emberek, aki eddig még nem vette komolyan a helyzetet: most jött el a legeslegutolsó pillanat, hogy nekiálljunk megtanulni, hogyan is néz ki az a fránya IPv6.

Könyvek, csak jönnek

Elnézést a keresztpostázásért, de gondolnom kell azokra is, akik csak a szakmai blogot olvassák.

Kapaszkodj, mert nem lesz egyszerű.

Amikor lezártam a TCP/IP Alapok könyvet, még volt bennem egy jó adag hiányérzet. Annyi virág nyílik az alkalmazás rétegben. Oké, hogy a DHCP és a DNS példaként be lett mutatva, de egy csomó izgalmas téma még kibontatlan maradt.

Kapóra jött, hogy tervben volt egy TMG könyv. Összedugtuk a fejünket és azt találtuk ki, hogy lesz egy közös könyv: én írok a webes protokollokról, ezek biztonságosabbá tételéről, GT pedig a TMG-ről.

Aztán összeállt az anyag első fele. Az én blokkom három részből állt: jó 50 oldalon összefoglaltam a TCP/IP Alapok könyv lényegét, a maradék 170 pedig felszántotta – jó mélyre eresztett ekevassal – a webes protokollok témát (HTTP, FTP, SMTP), beleértve a biztonsági megfontolásokat (TLS, SSH, IPSec, VPN, RADIUS) is.
Jó erős anyag lett. Nézegettük. Nemcsak, hogy megállt a saját lábán, de még a kávét is ágyba hozta. Úgy döntöttünk, hogy inkább önálló kötetként adjuk ki, méghozzá hozzácsapva a TCP/IP könyvhöz. Mert utólag végigolvasva, sokkal inkább ahhoz passzol, mint a TMG-hez. (Mely blokk szintén bőven erős lesz ahhoz, hogy önállóan is megálljon.)

Most jön a kavarás része:

  • A teljes kéziratból kiemeltem azokat a részeket, melyeknek inkább a TCP/IP Alapokban volt a helye. Ezekkel szépen bővült a könyv.
  • Örömteli hír, hogy rengeteg visszajelzés érkezett a korábbi (1.1) könyvhöz. Ezekből lettek levelezések, tisztázások, melyek következtében egyrészt bővült az anyag, másrészt világosabb lett. Itt kell beismernem, hogy volt olyan terület az 1.1-ben (TCP folyamszabályozás), ahol alapvetően rosszul értelmeztem a koncepciót. Egy kedves olvasó helyretette a folyamatokat a fejemben, én pedig átírtam az egész fejezetet. (Részletes lista a könyv végén.)

Emiatt a két pont miatt váltott a könyv fő verziószámot. mostantól 2.0.

  • A kéziratból leválasztottam a bevezető fejezetet. Ebből a műtét során egy 42 oldalas füzet lett. Ez az anyag a keresztségben a ‘TCP/IP – 1 óra alatt’ nevet kapta. Bárkinek, akit elrémisztene a 350 oldalnyi bitekkel tömött szöveg, de azért szeretne egy átfogó képet kapni a TCP/IP működéséről, bátran tudom ajánlani.
  • A maradék 161 oldal pedig önálló könyvként jelent meg, pontosabban a TCP/IP Alapok könyv második köteteként.

Lássuk a végeredményt:

Fontos látni, hogy az utolsó két kötet képez egy egységet, mely nem kompatibilis az 1.1 verzióval. Ha érdekel a téma, akkor nyugodtan dobd ki a korábbi verziót és töltsd le ezt a kettőt. (És elnézést azoktól, akik kinyomtatták. Megnyugtatásként közlöm, hogy ekkora strukturális átalakítást már nem tervezünk, maximum hibajavítások lesznek még.)

Ezzel párhuzamosan nyilván bővült a letölthető könyvek listája is, immár 8 könyvre mutatnak linkek. (Kihasználom a lehetőséget és szólok, hogy az első kettőt mostanában ne töltsd le, ezerrel írom, illetve szerkesztem át az anyagot.)

Geek úr nyaral

Nem tudom, te hogyan vagy vele, én nagyon aggódós utazásszervező vagyok. Akkor nyugszom meg, ha előre minden le van foglalva, ki van fizetve. Igaz, ekkor meg azon szoktam parázni, hogy időben odaérünk-e mindenhová.

Tudtam, hogy hová akarunk menni a nyáron. Igaz, még január volt, de mivel konkrét eseményre terveztünk, az időpont biztos volt. Maga az esemény miatt jókora tömeg várható, a kiválasztott kemping pedig picike. Ráadásul éppen erős is a forint – ergo minden jel afelé mutat, hogy már most foglaljam le a szállást.

Elmentem a weblapra, megkerestem a Reservation menüpontot.

Nagyítás

Erre feljött egy iframe-be ágyazott webes form. Kitöltöttem az adatokat, rányomtam a ‘send’ gombra. Kaptam egy kövér 404-est.

Nagyítás

Nagyítás

Ez bizony baj. Lemenjek úgy, hogy nincs biztos szállás? Egy ilyen frekventált időpontban?

Akkor már inkább varázsoljunk.

Első lépés: keressük meg, melyik az az oldal, amely végül nem érhető el. Szerencsére a Wireshark mostanában gyakorlatilag bootoláskor indul, így nem okozott gondot a beröffentése. Eljátszottam ugyanezt a foglalást.

Nagyítás

A webes formok adatait az OK gomb megnyomására egy POST paranccsal szokták elküldeni a webes alkalmazás számára. Rakjuk össze a HOST headert és a POST paraméterét: www.veniceincoming/camp/.okmailnew.asp. Ennek az alkalmazásnak kellene átadni a kép alján található szép nagy emaildest változó értékét.
Csakhogy az alkalmazás sztrájkol. Vagy kiment pisilni. Nincs.

Ami elsőre gyanús, az a ‘.’ karakter az URI-ban. Nem szoktak. Írjuk be anélkül az egészet a böngésző címsorába: és rögtön egy alkalmazásoldali hibaüzenetet kapunk.
Első lépésnek jó. Megvan az alkalmazás, a hiba meg jogos, hiszen tényleg nem adtam át semmilyen paramétert.

Nosza.

Alapvetően két stratégia közül választhatunk. Kezdjük az ‘ököllel szöget falbaverős’ technikával.

Megkértem a Wireshark-ot, hogy az elkapott csomagokból rekonstruálja a teljes forgalmat.

GET /camp/auk.asp HTTP/1.1
Host: www.veniceincoming.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.38 Safari/532.0
Referer: http://www.campingsannicolo.com/uk/contattaci-italiano.htm
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: gzip,deflate,sdch
Cookie: ASPSESSIONIDSQRCQASS=CGGHHKLCBAPCGHMGBFPEJFIC
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6,hu;q=0.4
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

Ez volt a kemping weblapjának lekérése.

HTTP/1.1 200 OK
Date: Tue, 19 Jan 2010 18:19:33 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Content-Length: 26933
Content-Type: text/html; Charset=windows-1252
Cache-control: private

<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”>

<html>

Innen jött egy bazi nagy HTML lap. Miért is? Ugye elment egy GET kérés, arra jött egy 200 OK válasz. Nemrég tanultuk, hogy ennek a válasznak a message blokkjában jön vissza a lekért oldal. Mi választja el a message és a header blokkokat? Üres sor. És tényleg.

</body>

</html>

POST /camp/.okmailnew.asp HTTP/1.1
Host: www.veniceincoming.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.38 Safari/532.0
Referer: http://www.veniceincoming.com/camp/auk.asp
Content-Length: 342
Cache-Control: max-age=0
Origin: http://www.veniceincoming.com
Content-Type: application/x-www-form-urlencoded
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: gzip,deflate,sdch
Cookie: ASPSESSIONIDSQRCQASS=CGGHHKLCBAPCGHMGBFPEJFIC
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6,hu;q=0.4
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

emaildest=info%40campingsannicolo.com&cognome=Jozsef&nome=Petrenyi&
email=jpetrenyi%40gmail.com&fax=&mese_arrivo=05&giorno_arrivo=21&anno_arrivo=2010&
totale_notti=3&numero_adulti=4&numero_bambini=&V-TADU=0&V-B2%2F10=0&V-R%2BAUTO=0&
V-CAMP=0&V-TG=0&N-TX2=0&N-TX4=0&N-R4%2F5=1&N-SP=0&N-LAV=0&N-BICI=0&N-ELE=1&
N-PARK=0&N-PARK-M=0&Note=&Submit=Send

Itt történik a lényeg. Először vége van a nagy HTML oldalnak. (Nyilván közben kitöltöttem a mezőket és rányomtam a Send gombra.) A POST paranccsal indul az adatok feltöltése. Egy csomó fejléc mező után jön az üres sor, majd a message blokkban ott figyel az a karakterlánc, melyet a form rakott össze és melyet az alkalmazásnak már jó étvággyal el kellene fogyasztania.

HTTP/1.1 404 Not Found
Content-Length: 1635
Content-Type: text/html
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Tue, 19 Jan 2010 18:20:12 GMT

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01//EN” “http://www.w3.org/TR/html4/strict.dtd”>
<!HTML><!HEAD><!TITLE>The page cannot be found</TITLE>

De nem teszi meg, ehelyett visszajön egy 404-es hibakód. (Emlékszünk, kliens oldali hiba.) Azaz nincs olyan weblap – jelen esetben alkalmazás, melyet meg akartunk hívni.
Az üzenet message blokkjában még ott van egy formázott HTML üzenet is, hogy a nem kockafejűek is értsék, miről is van szó.

Nos, itt van előttünk a teljes folyamat. Minden parancsot, minden fejlécet, minden message blokkot ismerünk. Azt is tudjuk, hogy a POST parancsban van elgépelve az alkalmazás neve.

Mire várunk? Putty.

Nagyítás

Rácsatlakoztam a webszerver 80-as portjára. Soronként átmásoltam a parancsokat a Wireshark kimenetéből. Ahogy egy üres enter-rel jeleztem, hogy vége a parancsnak, rögtön meg is kaptam a weblapot.

Nagyítás

Ha ez most egy böngésző lett volna, akkor értelmezte volna a HTML kódot és szép, színesszagos weblapom lett volna. De most szöveges kliensem van, abban meg így néz ki a weblap.
Képzeletben kitöltöttük a formot, vissza szeretnénk küldeni.

Nagyítás

Vegyük észre, a küldés első sorát, a POST parancsot nem ész nélkül másoltam be. Töröltem a ‘.’ karaktert. A többi maradt. A message blokk utáni üres enter után el is ment a csomag.

Nagyítás

Sajnos kiábrándító eredménnyel. Hiába találtuk meg az alkalmazást, hiába adtunk át neki egy teljesen szabályos adatcsomagot, az alkalmazás hibát dobott. Maximum annyi vigaszt meríthetünk, hogy ez egy 500-as hibakód, azaz kliensként már jók vagyunk, most a szerver dobta el az agyát.

Mondtam, hogy van egy másik módszer is. Egyszerűbb is, elegánsabb is… de kevesebbet lehet belőle tanulni.

Első lépésben lementjük az iframe-ben lévő weboldal forráskódját. Remélem, ezt nem kell külön részleteznem.

Nagyítás

Megkeressük a form parancs action paraméterét. És tényleg, ott van a hibás hivatkozás az alkalmazásra. Kijavítjuk, méghozzá úgy, hogy nem a relatív hivatkozást hagyjuk benne – hiszen a HTML fájl most már itt van a lokális vinyónkon – hanem az abszolút URI-t. Elmentjük, megnyitjuk a böngészőnkben. Kitöltjük a formot, send.
Hiba.

Nagyítás

Ugye látjuk, hogy ez szószerint ugyanaz a hiba, mint amilyet a Puttyban kaptunk – csak itt a böngésző jelenítette meg a szöveget.

A hibaüzenetből egyébként annyit lehet látni, hogy ez egy asp.net alkalmazás, méghozzá a nevéből itélve egy levélküldő alkalmazás. Valószínűleg az lett volna a terv, hogy az alkalmazás emailben elküldi a kempingnek a regisztrációs adataimat – csakhogy a formból rosszul hívják meg, nincs megadva az a cím, ahová a csomagot küldeniük kellene.

Ez ellen már nem segít semmilyen trükközés. Megkerestem a kemping emailcímét és elküldtem nekik szép, ember által is érthető szöveges formában a foglalási igényemet.

– Az írás egy hamarosan megjelenő könyv része. –

Szorgos hétköznapok

A feladat első lépése: telepítsünk HP Blade szerverre Windows Server 2008-at. Nem nagy ügy, virtual media bekonnektálva, nextnextfinish. ILO-ról beléptem, a hálókártyát beállítottam, a hardveres kolléga fellapátolta a PSP-t… aztán más projektre szólított a kötelesség. Miután ott eljutottunk odáig, hogy a labda már az ügyfél oldalán pattogott, jöhettem vissza a blade szerveremhez. Melyet időközben tokkal-vonóval, cage-dzsel, storage-dzsal átcipeltek egy másik épületbe. Ez ugye az alkalmazástelepítőt nem érdekli, a lényeg, hogy a drót túloldalán ott ficánkoljon a vas.

Nos, ez ficánkolt. Például az általam beállított IP címen nem tudtam elérni. ILO. A kártya DHCP-n volt. Visszaállítottam. Erre közölte, hogy ilyen konfigja már van egy hálózati kártyának, akarom, hogy azt törölje? Na, a hülye megőrzött valami régi értéket… persze, töröld, fiam.
Gépnév? Ez is átalakult valami random krikszkraksszá. Visszaneveztem, újraindítás. Megint nem lehetett elérni RDP-n. ILO. A hálókártya megint DHCP-s lett. Ekkor tűnt föl, hogy megváltoztatta Local Area Connection mögött a számot. Mi a fene? Ez minden újraindításkor újradetektálja és új kártyának ismeri fel a meglévő hálókártyáját? Visszakonfiguráltam. Megint figyelmeztetett, hogy ilyen konfig már van. Töröld, b+. Az OK után kiváncsiságból visszanéztem: kitörölte a DGW értékét. Visszaírtam.

Mehettünk tovább.

Átnéztem a rendszertervet – és kiderült, hogy más IP tartományba kerültünk, mint amit 1 hónappal ezelőtt tudtam. Már remegő kezekkel mentem be az IPv4 beállítások közé. Átírtam az IP címet, újraindítottam a szervert. Mondanom sem kell, megint elveszett. ILO. Újabb szám a hálókártya neve mellett – és persze DHCP-s. Káromkodás. Visszakonfiguráltam, dühösen lenyomtam a figyelmeztetést, miszerint egy nemlétező hálózati kártyának is ugyanez a konfigurációja. Dögölj meg. A beállítás után visszanéztem: és eldobtam a billentyűzetet. Nem csak a DGW-t törölte ki, hanem visszaállította a régi IP címet is. Kijavítottam. Leokéztam. Visszanéztem. Megint átírta az IP címet.

Ekkor néztem körbe, hová van elrejtve a kandikamera.

Gép újraindítás. Jé, most nem lett DHCP-s. IP konfig, beírtam a DGW-t, átírtam az IP címet – és végre bele is törődött, nem bírált felül.

Oké. Next.

Léptessük be a tartományba. Belépett. Kért egy újraindítást. Ajjaj.

Természetesen megint DHCP-s lett, valami lehetetlen címmel. ILO. Megint befaragtam. Megint visszaragadta a régi IP címét, miközben törölte a DGW-t. Újraindítás. Megint befaragtam. Jó lett.
Huh.
Innentől már volt net. SP2. Gondolom, kitaláltad: újraindítás, DHCP, befaragás, régi IP cím, Default Gateway, újraindítás, befaragás.
Windowsupdate. Újraindítás. DHCP, bef, rIP, DGW, újr, bef.
Itt történt egy érdekesség: az időközben felugrott maliciózus kódokat kirugdosó program mellékesen megjegyezte, hogy volt valami conflicker.b a gépen, de letúrta.
Bakker.
Amíg átmentem a másik projektre, a gép csak úgy állt ott, mint szende lófütty a vadvirágos réten… a conflicker meg beporozta. Szóltam a permetezős kollégáknak, hogy fertőtlenítsenek. Nem mintha nem bíznék meg a maliciózus removal tool-ban… de nem bízok meg. Nos, jelzem, hogy meg lehet – a gép tiszta lett. Csakhogy a kolléga nekiállt feldobni egy SEP-et – és találd ki, mi lett belőle? Újraindítás. DHCP, bef, rIP, DGW, újr, bef.
Pedig itt már azt hittem, hogy megvan a bűnös, innentől már rendben lesz minden.

Bevadultam. Kitöröltem az összes hálókártyát. Becsörtettem a registry-be, kitöröltem minden olyan GUID nevű objektumot, ahol a Connection alobjektumban szerepelt a ‘Local Area Connection’ string. Végül újratelepítettem a HP PSP-t.
Újraindítás. Nos, az eddig letiltott két hálókártya eltűnt. Maradt az az egy, amelyiken link is volt. És átváltott DHCP-re. Bef, rIP, DGW, újr, bef.

Ekkor már keményen délután volt. Az egész napom azzal ment el, hogy egyszerűen csak hozzá akartam férni egy géphez. Közel 9 órát töltöttem el ILO felület előtt – és ha volt már hozzá szerencséd, akkor tudod, mennyire frusztráló is tud ez lenni.

Kész. Projekt lefújva. Ezek voltak az első gondolataim. Másik hardver nincs, ez lett volna egy cluster első node-ja… de egy ennyire kiszámíthatatlan hálózati kártyával öngyilkosság lett volna belevágni. Jön egy failover, aztán DHCP-re vált a kártya. Jól néznénk ki.

Ekkor kezdtem alaposabban gondolkodni. Tényleg nem értem néha magamat. Nagyon szűk határidő, sok feladat – és egy egész napot végigszívok egy lehetetlen hibával, lehetetlen körülmények között – ahelyett, hogy egyből gugliznék. Vagy nák.
Viszont még csak elképzelésem sem volt, hogyan fogalmazzam meg a jelenséget, emiatt kiindultam abból a ritka hülye üzenetből, miszerint egy régi, már nem használt hálózati kártyámnak is ugyanaz a konfigurációja, mint a mostaninak.
Nem írom le a teljes vadászatot, több ugráson keresztül ugyan, de eljutottam ide . Ránézésre baromira nem stimmel. XP. Meg nem konnektált hardverek a Device Manager-ben.

Device Manager displays only non-Plug and Play devices, drivers, and printers when you click Show hidden devices on the View menu. Devices that you install that are not connected to the computer (such as a Universal Serial Bus [USB] device or “ghosted” devices ) are not displayed in Device Manager, even when you click Show hidden devices.

Ez a lényeg kérem, a dőlt betűs rész. Ghost egységek. Hát mi a fene lehet ez, mint egy kupac szellemként rejtőzködő, valójában nem létező hálókártya? Gondold el: van egy hálózati kártya, melyet egyszer így ismert fel, egyszer meg úgy. És ezeket váltogatja. Ilyenkor úgy érzi, hogy kivettem egy hálókártyát és betettem helyette egy másikat. A réginek megőrzi a konfigurációját – mert hátha egyszer vissza fog kerülni – az újat meg DHCP-re rakja. Aztán amikor én beállítom az újon ugyanazt a konfigot és azt mondom neki, törölje a régi hálózati kártyát – akkor nem magát a kártyát törli, hanem csak a konfigját. Jön a következő boot, ekkor a másik kártyának ismeri fel – és kezdődik minden előlről.
Nyilván valami hasonlóra gondoltam én is – de a Device Manager-ben hiába kapcsoltam be a Show Hidden Device opciót, ez csak az ellenség megtévesztése volt. Nem mutatott ez semmit, maximum a szélben lengedező lófüttyöt azon a vadvirágos réten.

Előtte ugyanis el kell indítani egy command promptot adminisztrátori joggal, majd beadni neki, hogy:

set devmgr_show_nonpresent_devices=1

Vigyázat. Én legalábbis megszoptam. Ha ezután elindítottam a Control Panelből egy Device Manager-t, akkor a Show Hidden Device után megint a jólismert árvalányhajas lófütty jött. Ez ugyanis már másik session-nak számít. Azaz nem vagánykodásból kell a promptból indítani a konzolt.

start devmgmt.msc

Na, ekkor jött meg az összes fantom hálózati kártya. Mind a tizensok.

Nagyítás

(A kép már egy későbbi állapotot ábrázol – de jól láthatóak a piros X-szel megjelölt fantom hálókártyák.)

Egyenként kitöröltem a bagázst – és minden rendben lett. Félórán keresztül csak restartoltam, IP címet állítgattam… de tényleg minden rendben.
Aztán eltöltöttem még egy kis időt, mire gatyába ráztam a WINS és DNS szervereket – szegények, mit képzelhettek erről az állandóan máshogy bejelentkezgető hostról – és kész. Jöhet a cluster.

Első lépés: faiover cluster feature telepítése. Lement. Reboot. Na?
Úgy van. DHCP. Csak most ugye megspékelve azzal, hogy a a failover cluster a régi adapterhez rendelődött hozzá, az újnál meg semmi. Illetve lófütty. Hálókártyák rendezése, failover cluster le, failover cluster fel, restart. DHCP. Bef, rIP, DGW, újr, bef.

Péntek éjfél. Ekkor fejeztem be aznapra, mert sürgős kardbadőlhetnékem támadt.

Szombat: új nap, új remények. Először eltávolítottam a rendszerből a HP NIC drivereket, hogy ne tudja keverni, milyen hálókártyának ismeri fel. Nem segített. Sóhaj, partíció töröl, operációs rendszer újratelepül. Kisérletképpen HP PSP nélkül. És csodák csodája, minden muzsikál. A 3 hálózati kártya masszívan tartja magát, se a gépátnevezés, se a tartományba léptetés nem hatja meg. Huh. Ellenteszt. Felraktam a HP Support Pack-ot, restart. DHCP. Bef, rIP, DGW, újr, bef.
Oké. Megvan a bűnös. Valamelyik program/driver a csomagból behülyíti a Windows-t.
Partíció radír, Windows újratelepül. Belépek… erre a hálózati kártyán még mindig ott volt az előző domaintagságra utaló hálózati név. Hát ez meg hogyan élte túl a teljes újratelepítést? Megnéztem a hálózati részt, ott vigyorgott a fantom kártya. Azannya. Újabb gyalu, a biztonság kedvéért 5 GB-vel kisebb új partícióra. Ha ezt is változatlanul éli túl a hálókártya, akkor elnevezem David Copperfield-nek.(1)

(1) Persze én voltam a hülye. Egyszerűen csak DHCP-re váltott, IP címet kapott, azon meg felismerte a tartományt. Csak nekem volt furcsa, hogy frissen telepített oprendszer már tartományt mutat.

De nem. Teljesen szép, szűz Windows 2008 jött fel. Oké. Hálózati kártya bekonfigurálva, gép átnevezés, reboot.
DHCP. Bef, rIP, DGW, újr, bef. Kardbadőlés.
Abszolút üres Windows, sehol semmi – és ott vigyorog a fantom kártya. Ami a reboot előtt az éles kártya volt. Aznapra ennyi jutott a sikerélményekből.

Vasárnap. Sebnyalogatás.

Hétfő. Ekkor már valamennyire állnia kellett volna a clusternek… ehhez képest legszívesebben már rég elhantoltam volna azt a szutyok vasat. Új ötlet. Hardveres kollégával konzultálva kiderült, hogy a gépben egy duálportos és két single portos hálókártya van. Mivel a cage csak három hálózati kimenettel rendelkezik, így az egyik hálózati kártyát letiltották – csakhogy ez pont a duál portos egyik portja lett. Lehet, hogy ettől hülyült meg a Windows. Mivel nekem elég a két hálózati kapcsolat, így váltunk: letiltják a duál portost és marad a két másik.
Kolléga elutazott a szerverekhez, átkonfigurálta.
Teszt.
Két fantom hálózati kártya vigyorgott vissza. Meg a tükörből az őrület. Aztán a remény fénye: lehet, hogy ez a két fantom még korábbi kisérletezések maradéka? Töröltem, Scan for new hardware… és nincs több fantom. Kezdtem reménykedni. Megint Scan. Még mindig jó. Kérem… én nem ehhez vagyok szokva. Elkezdtem őrült módon mindenfélének átnevezgetni a gépet, majd újraindítgattam. (Később csak az volt egy óra, míg a WINS szervereket kipucoltam.) De tartotta magát a gép, nem jöttek elő a fantomkártyák. Jöhetett a tartománybaléptetés, a HP PSP csomag… meg minden más.
28 órányi munka alatt eljutottam oda, hogy elkezdhettem bekonfigurálni az operációs rendszert. Miközben az egész cluster elindítására volt 3 munkanapunk. Szerencsére volt közben egy hétvége – az ugye nem számít, maximum csak nekem, de az meg megint nem számít. Így ha hajnalig nyomom, akkor esély van utolérni magunkat. (Kedd reggelre igértük a működőképes clustert.)

Szóval így.

Feljegyzés magamnak

Még az ősszel kaptam egy megbízást. Mondanom sem kell, eddig esélyem sem volt foglalkozni vele… és most is éppen csak beleharaptam a témába, éppen csak elkezdtem anyagot gyűjteni.

De azért lepődtem már meg.

Nézzük például az EAP autentikációt. Azt ugye tudjuk, hogy az EAP alapvetően nem egy önálló autentikáció, sokkal inkább egy keretrendszer. Mint az MMC: beletűzdeljük a snap-in-eket és így lesz egy jól használható valami belőle. Az EAP-ba ilyesmiket szoktak beledöfni, hogy TLS (melyről tudjuk, hogy az SSL leszármazottja), illetve MS-CHAPv2. (Bónusz kérdés: mi a különbség az MS-CHAPv2 és NTLMv2 között? Bónusz válasz: a módszer ugyanaz. Csak máshol használjuk.)
No, most jön a meglepődés. Vajon MS rendszerekben wifi autentikációhoz melyik EAP sündísznót használjuk? Az EAP-TLS-t? Ahol tudjuk, hogy a TLS elődje az tkp. Netscape kreálmány? Vagy inkább az MS saját édes gyermekét?
Persze, hogy az EAP-TLS-t. Az MS édes gyermeke… most nem kapott lapot.

De mielőtt szottyosra zokognánk a kispárnánkat, olvassunk tovább.

Nemcsak EAP van a világon… létezik PEAP is. Mi a különbség? Úgy van, nagyon jól éreztél rá: a ‘P’ betű. ‘P’, mint Protected. Anélkül, hogy túlzottan belemennék a részletekbe, a különbség lényege az, hogy az EAP esetén a felek kölcsönös becsületsértegetése nyilvános, míg a PEAP esetén már ez is titkosított. És igen, a PEAP-nál már egyenrangú a PEAP-TLS és a PEAP-MSCHAPv2.

Névfeloldás

Jogosan kérdezheted, mit lehet még ebből a témából kifacsarni? Leírtak már mindent, amit csak lehet.

Mégis találtam érdekességet.

Kezdjük a szituáció felvázolásával:

  • Több tartományból álló környezet.
  • Minden tartomány minden tartományvezérlője DNS és WINS szerver is egyben. A WINS szerverek replikációs partnerek. Az összes DNS zóna AD integrált, méghozzá forest szinten.
  • Az összes szerver az egyik – mondjuk a.cegnev.hu – tartományban van.
  • Van DHCP.

Jelenség:
Kiderült, hogy az összes tartományból (b.cegnev.hu, c.cegnev.hu), amennyiben rövid névvel akarják elérni a szervereket, a WINS végzi el a névfeloldást.
Nyilván nem ez a cél: minek autózzunk Trabanttal, ha van Lexusunk is?

Ismételjük csak át a névfeloldást:

  • A kliens megnézi a saját lokális cache-ét.
  • Ha nem talál semmit, akkor hozzácsapja a rövid névhez az összes beállított suffix-ot, majd az így kialakult FQDN-t megnézi a megfelelő zónafájlokban.
  • Ha még mindig nem talál semmit, akkor megy a WINS-hez.
  • Tovább is van, de ez most nem lényeges.

Megnéztük, és azt tapasztaltuk, hogy minden kliens gépen csak primary suffix van beállítva, a DNS ablakban bizony üres a DNS suffix search ablak.
Oké. helyben vagyunk. Mivel a keresett szerver az a.cegnev.hu zónában van, de ez nincs rajta a keresési listán, a WINS fogja végül kapni a munkát.

Megvan a probléma, javítsuk ki. Nyilván többszáz gépes, neadjisten több telephelyes környezetben az ‘egyenként sorbajárjuk a gépeket’ módszer nem igazán hatékony.
Mik is jöhetnek szóba lehetőségként?

  • Biztosan létezik valamilyen DHCP opció.
  • Biztosan létezik valamilyen csoportházirend beállítás.
  • Ha neadjisten egyik sem, még mindig ott van a netsh, mely mindent tud.
  • Ad abszurdum, még nekiállhatunk saját szkriptet is írni.

Nos, van választék bőven, nézzük meg, melyik is működik konkrétan.

Első találat:

The following methods of distribution are not available for pushing the domain suffix search list to DNS clients:
• Dynamic Host Configuration Protocol (DHCP). You cannot configure DHCP to send out a domain suffix search list. This is currently not supported by the Microsoft DHCP server.
• Netsh (Netshell). The Netsh utility has no command to set or to change the domain suffix search list.
• Group Policy. In Windows 2000, Group Policy has no mechanism for distributing the domain suffix search list. However, Windows Server 2003 includes this feature.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
294785 New group policies for DNS in Windows Server 2003.
• Microsoft Visual Basic Scripting Edition (VBScript). No application programming interfaces (APIs) are available that enable you to script a change to the domain suffix search list.

Első pillantásra komplett infarktus. A felsorolt módszerek egyike sem működik. Ráadásul még a netsh sem!
Aztán jön az alaposabb olvasás. Dátum? 2007 március. Hát, nem mai cikk. Érintett rendszerek? Windows 2000 szerverek, Windows 2000 Prof. Huhh.

Aztán ott van egy link az idézetben: milyen új opciók jöttek be DNS kezelés terén a Windows 2003 szerver csoportházirendjében? És igen:

• Enable or disable dynamic registration of the DNS records by a client
• Configure DNS suffix search list of the clients
• Devolution of the primary DNS suffix in a name resolution process
• DNS suffix search list

Örülés. Szerencsére a kliens fél évvel ezelőtt átlépett natív AD2003-ba.
Egyébként cucli lett volna: egyedül a Windows 2000 Resource Kit Regini programja jöhetett volna szóba. (Melynek már a beszerzése sem túl egyszerű: a Windows 2000 RSK oldalon nincs fent, igaz lehet próbálkozni a Windows 2003 RSK-val.)

Apu, hod med be?

Az a rengeteg alkalmazás a másik számítógépre? Jó kérdés. Rengetegszer láttam már, hogy valaki tűzfal mögött akart elérni egy akármilyen alkalmazásszervert, megnyitott érzésre portokat… majd végül, belefáradva a nyomozásokba, bebillentette az any-any szabályt.

Nos, itt egy – szószerint – kimerítő lista arról, hogy mely alkalmazás mely portokat használja.

Mivel ez azért alapvetően levelezéscentrikus blog, itt van egy másik írás arról, hogy konkrétan az Exchange 2007 milyen portokat használ, amikor dolgozik.

Desszertként pedig álljon itt egy leírás arról, hogyan lehet az Exchange RPC szolgáltatásait egyetlen portra koncentrálni – azaz tűzfalbaráttá tenni. Igaz, ez Exchange 2000/2003-ra íródott, de a cikk végén megjegyzik, hogy a beállítások remekül működnek 2007 alatt is.

Spagetti routing tábla

Egyik ügyfelünknél beköltözött a nagy Sztochasztikus Vezetékelharapó az informatikai rendszerükbe. Időnként ugyanis az egyik kritikus telephelyükről nem érték el a központi Exchange szervert. Máskor viszont minden tökéletesen ment.
– Máskor tökéletesen ment? – kérdeztem vissza – Akkor hívjátok a networkos emberünket, mert ez nem Exchange hiba lesz.
És dobáltam tovább a dartsokat.

A networkos ember megnézte a routereket, switcheket, tűzfalakat… minden tökéletesen működött. Nem volt mit tenni, meg kellett várni egy üzemzavart. Meg is jött. Networkos ember ismét átnézett mindent. Alles oké. Csak éppen az Exchange szerver se telnet, se icmp szinten nem volt elérhető.
Vicces.
Aztán a kolléga tovább vizsgálódott, végül arckarmolás mellett felüvöltött: a rohadt istenit az Exchange szervernek!
Ekkor tettem le a nyílhegyeket. Lehet, hogy mégis érintve vagyok?

Mielőtt továbbmennénk, pár szó a hálózatról. Ez egy országos kiépítettségű hálózat, rengeteg telephellyel, subnettel, dmz-vel. Nem viccelek, a dmz-k mennyiségre kétszámjegyűek, nem ritka a két-három kijárattal bíró subnet sem. Nem is a szétszórt routerek kezelik a route logikát, hanem van középen egy RSP (Route Switch Processor), ő az ész. Meg a default gateway is mindenhol.
És akkor nézzük meg, mi borította ki a kollégát. Kéremszépen, megnézte az Exchange szerver route tábláját – és vagy 187 bejegyzést talált benne. 187 rosszat. Ez már nem volt annyira vicces.
Arra viszonylag hamar rájöttünk, mi történik: jön egy Outlook kliens valamelyik másik subnetből, az Exchange szerver meg felveszi annak a routernek a lábát a route táblába, ahonnan a kliens jött, természetesen a szabályban a kliens IP címe szerepel 255.255.255.255 maszkkal.
De miért is okozott ez a jelenség ekkora problémát?
Az elején mondtam, hogy az a bizonyos telephely borzalmasan kritikus az ügyfél számára. Ergo redundáns bérelt vonal van kihúzva, úgy, hogy a szolgáltatók sem azonosak. Ha ledől az egyik vonal, a routerek automatikusan átváltanak a másikra, az RSP is ennek megfelelően módosítja az útvonalakat. Csakhogy az a szerencsétlen helóta Exchange szerver minderről semmit sem tud, továbbra is a route táblájában lévő, immár fals kijárattal próbálkozik. Miért nem megy el az RSP-hez? Mert a 255.255.255.255 maszk szorosabban illeszkedik a csomagra, mint a default gateway maszkja.

Vadul elkezdtem keresni a neten, de nem igazán tudtam jól megfogalmazni a kérdésemet. Ha legalább a jelenség nevét tudnám. Végső menedékként dobtam egy körlevelet nagytudású, művelt cimboráimnak, hogy ki találkozott már ilyesmivel. Rövidesen meg is jött a válasz. Gömöri Zoli szerint a router dumál vissza a szervernek, hogy van egy rövidebb út Géza, mostantól menj arra, engem meg hagyj ki a buliból. Stone pedig megírta a jelenség nevét és azt, hogy hol lehet kikapcsolni. Imhol:

  • A jelenség – és a kulcs – neve: EnableICMPRedirects
  • Registry ág: HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\

Ha az érték nulla, akkor a szerver magasról leszarja, mit mond a router.
Beállítottuk, az incidens elhárult.
Jöhetett a problémamegoldás. Biztos, hogy nem okoz galibát ez a registry módosítás? Mivel most már volt név a kezemben, körbenéztem. Találtam is egy ajánlást, hogyan védjük szervereinket (D)DOS ellen – hát például úgy, hogy a fenti értéket egyre állítjuk. Oké. Akkor ez a kérdés meg lett válaszolva.
De miért csak mostanában jelentkezett a hiba, régebben miért nem? Nos, kiderült, volt korábban egy RSP csere. A művelet tökéletesen sikerült, az új RSP remekül működött – csakhogy ez az ún. icmpredirect érték defaultban engedélyezett volt minden lábán. A réginél meg nyilván nem.
Azaz, ha biztosra akartunk menni, akkor nem csak az Exchange szerveren kellett beállítani, hogy ne figyeljen arra, mit mond a router – hanem a routeren is, hogy ne molesztálja a hostokat.
Most, és csak most mondhatjuk azt, hogy lekezeltük a problémát… írhatjuk végre a változásigénylést.