TCP / IP-csomóponttípusok és ügyfél-bejelentkezés

ha több alhálózaton keresztül irányított több webhelyből álló tartományt hoz létre, akkor feltételezheti, hogy egy tartalék tartományvezérlő távoli webhelyre történő telepítése biztosítja, hogy az adott webhely ügyfelei helyben érvényesítésre kerüljenek. A cél természetesen kettős: a LAN-on kívüli forgalom csökkentése egy drága kapcsolaton keresztül, valamint annak biztosítása, hogy az ügyfelek bejelentkezését ne késleltesse a WAN-kapcsolat sebessége (vagy hiánya). A helyi tartományvezérlő telepítése valóban működhet, de vajon ez a siker tervezés vagy véletlen?
sajnos nem lehet megadni azt a tartományvezérlőt, amely érvényesíteni fogja az adott ügyfelet, függetlenül attól, hogy az ügyfél Windows NT Server, Windows NT Workstation vagy Windows 9x rendszert futtat. a Windows korábbi verziói ugyanúgy működnek, feltéve, hogy 32 bites TCP/IP-veremet vagy 16 bites WINS-tudatos TCP/IP-veremet használnak.
ebben a napi lebontásban áttekintést adunk az érintett folyamatokról. Azt is elmagyarázzuk, hogy miért lehet egy olyan tartományvezérlő, amely egy másik országban van elhelyezve egy lassú modem linken, amelyet az ügyfélgép választott a bejelentkezési kérelem kiszolgálására.
háttér
azok számára, akik nem ismerik a Windows NT tartományok fogalmát, itt található egy gyors frissítés: az NT tartomány olyan hálózati kiszolgálók és más számítógépek gyűjteménye, amelyek közös biztonsági és fiókadatokkal rendelkeznek. A tartomány központosított felhasználói, számítógépes és hálózati adminisztrációt biztosít. A biztonsági információkat egy központi adatbázisban tárolják egy elsődleges tartományvezérlőként (PDC) kijelölt és konfigurált kiszolgálón, és más speciális kiszolgálókra replikálják, amelyek tartalék tartományvezérlőként (BDC) vannak kijelölve és konfigurálva. Egyszerre csak egy szerver lehet A PDC, de ez a különleges szerep szükség szerint bármely BDC-re átvihető. Amikor egy TCP/IP-t futtató ügyfél megpróbál bejelentkezni erre az NT-tartományra, a bejelentkezési kérelmet a hálózat ugyanazon tartományhoz tartozó tartományvezérlői dolgozzák fel.
WINS
a WINS-kiszolgálók a hálózaton található összes WINS-kompatibilis ügyfél listáját vezetik. A WINS-kiszolgálók a <1C>típusként azonosított tartományvezérlők listáját is fenntartják. Csak számukra ismert okokból a WINS tervezői úgy döntöttek, hogy a <1C> listában 25 bejegyzés korlátozásának kell lennie, ami azt jelenti, hogy a későbbi tartományvezérlők nem jelennek meg ezen a listán. Az ügyfelek akkor kapják meg ezt a listát, amikor megpróbálnak tartományvezérlőt találni a bejelentkezési kérésük kiszolgálására.

a tartományvezérlők listában való megjelenési sorrendje ezt a logikát követi:

1. a WINS-kiszolgálón regisztrált tartományvezérlői bejegyzések, a legutóbb frissült
2. tartományvezérlői bejegyzések sorrendjében, amelyeket más WINS-kiszolgálókkal történő replikáció során szereztek be
3. az első bejegyzés mindig a PDC

csomópontok
amikor a TCP/IP-t ügyfélen konfigurálják, az egyik lehetőség, amelyet (attól függően a telepítésen) a csomópont típusa. A csomóponttípus arra utal, hogy az ügyfél hogyan talál egy tartományvezérlőt a bejelentkezési kérelmek kiszolgálására.
négy csomóponttípus van a TCP/IP-ben:

• B-node (broadcast node): amikor egy ügyfélnek meg kell találnia egy tartományvezérlőt, akkor adást hajt végre. Az első válaszadó tartományvezérlő megkapja a bejelentkezési kérés kiszolgálásának feladatát.
• P-csomópont (pont-pont csomópont): ebben a környezetben a név lekérdezések közvetlenül a WINS-kiszolgálóra kerülnek.
• M-node (multi-homed node): egy m-node környezet először a b-node—ot, majd—ha szükséges-a p-node-ot használja a nevek feloldásához.
• H-csomópont (hibrid csomópont): egy h-csomópont környezet először a p-csomópontot, majd a b-csomópontot használja, ha a névszolgáltatás nem érhető el.

vizsgáljuk meg részletesebben az egyes csomóponttípusokat.
B-csomópont
a b-csomópont mód broadcast üzeneteket használ a név regisztrálásához és felbontásához. Például, ha EGY nt_pc1 nevű számítógép kommunikálni akar egy NT_PC2 nevű számítógéppel, az NT_PC1 sugárzott üzenetet küld arról, hogy nt_pc2-t keres. Ezután egy meghatározott időt vár az NT_PC2 válaszára.
A B-csomópontnak két fő problémája van:

• nagy környezetben a hálózatot sugárzott üzenetekkel tölti be.
• az útválasztók általában nem továbbítják a sugárzott üzeneteket, így az útválasztó ellentétes oldalán lévő számítógépek soha nem hallják a kéréseket.

a hálózaton található olyan számítógépek, amelyek b-csomópontú kliensek lehetnek, például az MS-DOS, A Windows 3.1 vagy a munkacsoportok számára Windows rendszert futtató számítógépek, amelyeken nincs telepítve WINS-ügyfélszoftver. A lehetséges kiszolgálók közé tartoznak a Server Message Block (SMB) alapú hálózati kiszolgálók, például az IBM LAN Server, a DEC PATHWORKS, az AT&t StarLAN és a LAN Manager for OS/2 vagy UNIX rendszerek.
P-csomópont
a p-csomópont mód azokat a problémákat kezeli, amelyeket a b-csomópont nem old meg. P-node környezetben a számítógépek sem nem hoznak létre, sem nem válaszolnak a sugárzott üzenetekre. Minden számítógép regisztrálja magát a WINS-kiszolgálón, amely felelős a számítógépnevek és címek megismeréséért, valamint annak biztosításáért, hogy a hálózaton ne legyenek ismétlődő nevek.

ebben a környezetben, amikor az NT_PC1 kommunikálni akar az NT_PC2-vel, lekérdezi a WINS-kiszolgálót az NT_PC2 címére. A cím kézhezvételét követően az NT_PC1 műsorszórás nélkül közvetlenül az NT_PC2-re megy. Mivel a név lekérdezések közvetlenül a WINS szerverre kerülnek, a p-node elkerüli a hálózat sugárzási üzenetekkel történő betöltését. Mivel a sugárzott üzeneteket nem használják, és a cím közvetlenül érkezik, a számítógépek az útválasztók ellentétes oldalán lehetnek.
a P-csomópont legfontosabb problémái a következők:

• minden számítógépet úgy kell konfigurálni, hogy ismerje a WINS-kiszolgáló címét.
• ha a WINS-kiszolgáló nem működik, azok a számítógépek, amelyek a címek feloldására támaszkodnak, nem juthatnak el a hálózat más rendszereihez.

M-csomópont
az m-csomópont módot elsősorban a b-csomópont és a p-csomópont problémáinak megoldására hozták létre. M-node környezetben a számítógép először megkísérli a regisztrációt és a felbontást a b-node segítségével. Ha ez nem sikerül, akkor p-csomópontra vált. Az előnyök a következők:

• az M-csomópont keresztezheti az útválasztókat
• mivel a b-csomópontot mindig először próbálják ki, az útválasztó ugyanazon oldalán lévő számítógépek továbbra is a szokásos módon működnek, ha a WINS szerver nem működik
• elméletileg az m-csomópont használata növeli a LAN teljesítményét

H-csomópont
a h-csomópont mód megoldja a sugárzott üzenetekkel és az irányított környezeti műveletekkel kapcsolatos legjelentősebb problémákat. Ez a mód A b-csomópont és a p-csomópont kombinációja, amely végső megoldásként a sugárzott üzeneteket használja. A h-node mód nem csupán a b-node és a p-node használatának sorrendjét változtatja meg: ha a WINS—kiszolgáló leáll—ami szükségessé teszi a sugárzott üzenetek küldését -, a számítógép továbbra is lekérdezi a WINS-kiszolgálót. Amikor a WINS szerver újra elérhető, a rendszer visszatér a p-csomóponthoz. A H-csomópont konfigurálható az LMHOSTS fájl használatára is, miután a broadcast névfeloldása sikertelen.
mivel a p-node-ot használják először, a WINS-kiszolgáló futása esetén nem keletkeznek sugárzott üzenetek, és a számítógépek az útválasztók ellentétes oldalán lehetnek. Ha a WINS szerver nem működik, a b-csomópontot használják, így az útválasztó ugyanazon oldalán lévő számítógépek továbbra is a szokásos módon működnek.
egyéb kombinációk
egy másik variációt, az úgynevezett módosított b-csomópontot is használják a Microsoft hálózataiban, hogy az üzenetek átmenjenek az útválasztókon. A módosított b-csomópont nem használ p-csomópont módot vagy WINS-kiszolgálót. Ebben a módban a b-node az LMHOSTS fájlban tárolt számítógépek és címek listáját használja. Ha egy b-csomópont kísérlet sikertelen, a rendszer az LMHOSTS-ban keres egy nevet, majd a társított címet használja az útválasztó átlépéséhez. Azonban minden számítógépnek rendelkeznie kell ezzel a listával, ami adminisztrációs terhet jelent, mivel a listát karbantartani és elosztani kell. Windows for Workgroups 3.11 és LAN Manager 2.x ilyen módosított B-csomópont rendszert használt. A Windows NT ezt a módszert használja, ha a WINS-kiszolgálókat nem használják a hálózaton. A Windows NT – ben néhány kiterjesztést hozzáadtak ehhez a fájlhoz, hogy megkönnyítsék a kezelést, de a módosított b-csomópont nem ideális megoldás.

egyes helyek megkövetelhetik mind a b-csomópont, mind a p-csomópont üzemmódot. Bár ez a konfiguráció működhet, a rendszergazdáknak rendkívül óvatosan kell eljárniuk, és csak átmeneti helyzetekben kell használniuk. Mivel a p-csomópont gazdagépei figyelmen kívül hagyják a sugárzott üzeneteket, a b-csomópont gazdagépei pedig a broadcast üzenetekre támaszkodnak a névfeloldáshoz, a két gazdagép potenciálisan ugyanazzal a NetBIOS névvel konfigurálható, ami kiszámíthatatlan eredményekhez vezet. Továbbá, ha a b-csomópont használatára konfigurált számítógép statikus leképezéssel rendelkezik a WINS-adatbázisban, a p-csomópont használatára konfigurált számítógép nem használhatja ugyanazt a számítógépnevet.
A Windows NT rendszert futtató számítógépek WINS proxyügynökként konfigurálhatók a WINS használatára való áttérés elősegítése érdekében. A Windows-alapú hálózati ügyfelek (WINS-kompatibilis Windows NT, Windows 95 vagy Windows for Workgroups 3.11 számítógépek) közvetlenül használhatják a WINS-t. A b-csomóponttal kompatibilis nem WINS számítógépek (az RFCs 1001 és 1002 szabványban leírtak szerint) proxykon keresztül férhetnek hozzá a WINS-hez. A WINS-proxy egy WINS-kompatibilis számítógép, amely figyeli a név-lekérdezés sugárzott üzeneteit, majd válaszol azokra a nevekre, amelyek nem szerepelnek a helyi alhálózaton. A proxyk p-node számítógépek.
a TCP konfigurálásakor nem talál semmilyen módot a csomópont típusának beállítására. A csomópont típusa alapértelmezettre van állítva a TCP konfiguráció során. Az alapértelmezett Windows 95 TCP / IP csomópont típusok a következők:
ha DHCP=False, és a WINS le van tiltva, akkor a B csomóponttípus-csomópont (0x01)
ha DHCP=False, és a WINS manuálisan van beállítva, akkor a h csomóponttípus-csomópont (0x08)
ha DHCP=True, és a DHCP állítja be a WINS-t, akkor a H csomóponttípus-csomópont (0X08)
ha DHCP=True, és a WINS manuálisan van beállítva, akkor a h csomóponttípus-csomópont (0x08)
ha DHCP=true, és a WINS le van tiltva, akkor a csomópont típusa B-node (0x01)
ha a WINS-kiszolgáló beállításai DHCP-n keresztül vannak megadva, akkor a csomópont típusát a DHCP 46 opcióval kell beállítani; a WINS-kiszolgáló helyi meghatározása azonban felülbírálja ezt a két lehetőséget, mivel a helyileg definiált WINS-kiszolgálók automatikusan h-csomópontra állítják a csomópont típusát.
a csomópont típusa manuálisan módosítható a Windows 95 beállításjegyzék szerkesztésével. A hely a HKEY_LOCAL_MACHINE részfa alatt található a
SYSTEM \ CURRENTCONTROLSET \ SERVICES \ VXD \ MSTCP \ csomóponttípus

a NodeType Karakterláncértékként adható hozzá az MSTCP alatt, ha még nem létezik.
a bejelentkezési kérelem
most nézzük meg, mi történik, miután az ügyfél beírja a felhasználónevet, a jelszót és a tartományadatokat, és rákattint az OK gombra a bejelentkezési ablakban (mielőtt a bejelentkezési kérelmet kiszolgálják). A Windows 9x és a Windows NT kissé eltérően viselkednek, ezért külön tárgyalom őket.
Windows 9x ügyfél
az ügyfél megkísérli megtalálni a tartományvezérlőt a konfigurált csomóponttípus által meghatározott módon. Az alábbiakban egy nagyon egyszerűsített eseménysor látható:

1. a b-csomópont kliens küld egy kérést. Ha egy kiszolgáló nem válaszol, a bejelentkezés sikertelen lesz.
2. egy p-node kliens kérni fogja a < 1C> listát a WINS szerverről. Ezután egy kérést továbbít a <1C> listában szereplő szerverek mindegyikéhez, az elsővel kezdve (a PDC).
3. az m-node és a h-node ügyfelek mindkét műveletet a fent leírt sorrendben hajtják végre, azzal a különbséggel, hogy ha az ügyfél munkacsoportjának neve megegyezik azzal a fióktartománnyal, amelyre a bejelentkezést megkísérelték, a helyi alhálózaton a WINS tartományvezérlők keresése kihagyásra kerül. Feltéve, hogy a WINS-kiszolgáló aktív és elérhető, ez azt jelenti, hogy a <1C> listában elsőként válaszoló tartományvezérlő mindig kezeli a bejelentkezési kérést.

mint fentebb említettük, annak biztosítása érdekében, hogy az Ügyfelet a helyi tartományvezérlő érvényesítse, a munkacsoport nevét meg kell egyeznie az adott tartományvezérlő által képviselt tartomány nevével. Ha azonban munkacsoportokat szeretne használni az irodai környezetben, előfordulhat, hogy a helyi érvényesítés biztosításának ez a módszere nem elfogadható. Ebben az esetben a csomópont típusát m-re kell állítani annak biztosítása érdekében, hogy az ügyfél kezdetben a helyi alhálózaton sugározzon, így nagyobb esély van arra, hogy a helyi tartományvezérlő először válaszoljon. Ne feledje, hogy ez nem egy kemény és gyors szabály. A tartományvezérlőnek csak egy kicsit elfoglaltnak kell lennie—amelyek a távoli webhelykiszolgálók gyakran azért vannak, mert a rendszergazdák általában egyetlen tartományvezérlőt helyeznek el egy távoli webhelyen—, és egy érzékenyebb, nem helyi tartományvezérlő juthat be először.
Alternatív megoldásként a WINS telepíthető a helyi tartományvezérlőre, és az ügyfelek elsődleges WINS-kiszolgálóként használhatják. Ez a módszer jó ötlet lehet, ha a felhasználók ritkán férnek hozzá a helyi ágon kívüli erőforrásokhoz, de ez extra terhet jelent a kiszolgálóra, amely valószínűleg fájl-és nyomtatási szolgáltatásokat, DHCP-t, SQL-t, Exchange-et és egyéb feladatokat nyújt.

ha a munkacsoport neve eltér a fióktartománytól, akkor az m-node használata növeli a bejelentkezési kérelem helyi kiszolgálásának esélyét.
Windows NT kliens
A Windows NT bejelentkezés némileg eltér a Windows 9x bejelentkezéstől—az NT munkaállomás gépazonosítóval rendelkezik egy tartományban. Tehát az ügyfél négy lépésen megy keresztül a bejelentkezés érvényesítéséhez. Először az NT munkaállomás-ügyfél érvényesíti a gépazonosítóját az erőforrástartomány tartományvezérlőivel, majd elküldi a felhasználói bejelentkezési információkat az áthaladás ellenőrzéséhez. Az erőforrástartomány tartományvezérlője átadja a bejelentkezési adatokat a fióktartományban lévő tartományvezérlőnek. Az erőforrás tartomány-tartományvezérlő ezután továbbítja a felhasználó hitelesítési adatait (a fióktartomány-tartományvezérlőtől kapott) a felhasználónak.
függetlenül attól, hogy a felhasználók be vannak-e jelentkezve hozzájuk, az NT munkaállomás-ügyfelek az inicializálás során, illetve szükség szerint később AZONOSÍTÓELLENŐRZÉSEN mennek keresztül (például ha valaki a helyi gyorsítótárazott profillal jelentkezik be az NT-gépre, mert az erőforrás-tartományvezérlő nem működik).
először a tartományvezérlők névfelbontása következik. Az NT munkaállomás-ügyfélnek meg kell találnia egy erőforrás-tartományvezérlőt. Az NT munkaállomás-ügyfél által az erőforrás-tartományvezérlő megkeresésére használt felderítési folyamat megegyezik azzal, amelyet az erőforrás-tartományvezérlő használ a fióktartomány-tartományvezérlővel való megbízható kapcsolat létrehozásához.
ezután az NT gépazonosító érvényesül. Az NT munkaállomás-ügyfél mindig küld egy helyi bejelentkezési sugárzást a <1C> erőforrás-tartományba, mielőtt unicast bejelentkezési kéréseket küldene a WINS-től kapott erőforrás-tartományvezérlőknek.
az ügyfél érvényesíti az NT munkaállomás gépazonosítóját—az erőforrás-tartomány első tartományvezérlőjével, amely válaszol a bejelentkezési kérésre.
az NT munkaállomás-ügyfél kéri az erőforrástartomány-tartományvezérlőt a megbízható tartományok listájának felsorolására. A kapott tartománynevek a bejelentkezési ablak Domain legördülő mezőjében jelennek meg.
az NT munkaállomás-ügyfél átadja a felhasználói bejelentkezési hitelesítő adatokat az erőforrástartomány-tartományvezérlőnek, és átmenő hitelesítést kér.
az erőforrástartomány-tartományvezérlő átadja a felhasználói bejelentkezési hitelesítő adatokat annak a fióktartomány-tartományvezérlőnek, amellyel megbízható kapcsolatot létesített, és kéri a felhasználó hitelesítését. Ezután továbbítja az érvényesítési információkat az NT munkaállomás-ügyfélnek.
az NT munkaállomás-ügyfél megkapja a fióktartomány-tartományvezérlő nevét az erőforrástartomány-tartományvezérlőtől a bejelentkezési parancsfájl/profil csatlakoztatásához és végrehajtásához, ha az konfigurálva van.
az NT felhasználó most bejelentkezett a fióktartományba, végrehajtott egy bejelentkezési parancsfájlt, és megfelelő hálózati kapcsolatokat létesített az otthoni könyvtárakkal.
természetesen, ha a gépazonosító a helyi alhálózaton kívüli tartományhoz van regisztrálva, vagy ha a Felhasználó olyan tartományba jelentkezik be, amely nem rendelkezik tartományvezérlővel a helyi alhálózaton, a bejelentkezési folyamat WAN-on keresztüli kommunikációt igényel. Ha ez egy lassú kapcsolat, a bejelentkezési folyamat meghosszabbodik.
következtetés
Windows 9x ügyfelek esetén a helyi hitelesítés úgy érhető el, hogy a munkacsoport nevét megegyezik a bejelentkezési névvel vagy fiókkal, domainnel, vagy B-mode vagy m-node használatával biztosítja, hogy a bejelentkezési kérelmet először helyben sugározzák. Nyilvánvaló, hogy a b-node nem túl sokoldalú, és sikertelen bejelentkezést okoz, ha a helyi tartományvezérlő nem reagál gyorsan.
Windows NT kliensek esetén a helyi szegmensben erőforrástartomány-vezérlőnek és fióktartomány-vezérlőnek kell lennie. (Lehet, hogy egyetlen kiszolgáló, ha az erőforrás – és fióktartományok azonosak.)
tovább javíthatja a folyamatot, ha több WINS-kiszolgálóval rendelkezik, és az ügyfeleket arra a WINS-kiszolgálóra irányítja, amely regisztrálja a helyi vagy a legközelebbi tartományvezérlőt a < 1C> listában.

Richard Charrington számítógépes karrierje akkor kezdődött, amikor PC—kkel kezdett dolgozni-még akkor, amikor mikroszámítógépekként ismerték őket. Programozóként kezdve egészen a Windows NT rendszergazda magaslatáig dolgozott, és szinte mindent megtett a kettő között. Richard már dolgozik a Windows, mivel mielőtt volt egy megfelelő GUI és a Windows NT, mivel ez volt LANManager. Most egy vállalkozó, ő csúszott script írásban a Windows NT és épített néhány nagyon hasznos auto-admin segédprogramok.

a szerzők és szerkesztők gondoskodtak az itt található tartalom előkészítéséről, de semmilyen kifejezett vagy hallgatólagos garanciát nem vállalnak, és nem vállalnak felelősséget a hibákért vagy hiányosságokért. Semmilyen kárért nem vállalunk felelősséget. A módosítások elvégzése előtt mindig legyen ellenőrzött biztonsági másolat.