typy węzłów TCP/IP i logowanie klienta

podczas budowania domeny wielostanowiskowej, która jest kierowana przez kilka podsieci, można założyć, że umieszczenie kontrolera domeny kopii zapasowej w zdalnej witrynie zapewni, że klienci w tej witrynie zostaną zweryfikowani lokalnie. Cel jest oczywiście dwojaki: zmniejszenie ruchu, który będzie wychodził poza sieć LAN za pośrednictwem drogiego łącza oraz zapewnienie, że logowania klientów nie będą opóźnione przez szybkość (lub jej brak) połączenia WAN. Instalacja lokalnego kontrolera domeny może rzeczywiście zadziałać, ale czy taki sukces będzie z założenia czy przez przypadek?
niestety, nie ma możliwości określenia kontrolera domeny, który będzie sprawdzał poprawność danego Klienta, niezależnie od tego, czy ten klient korzysta z Windows NT Server, Windows NT Workstation, czy Windows 9x. poprzednie wersje systemu Windows będą działać w ten sam sposób, pod warunkiem, że używają 32-bitowego stosu TCP/IP lub 16-bitowego stosu TCP/IP zgodnego z WINS.
w tym codziennym drążeniu, damy Ci przegląd procesów, które są zaangażowane. Wyjaśnimy również, dlaczego kontroler domeny znajdujący się w innym kraju na wolnym łączu modemu może być kontrolerem wybranym przez maszynę kliencką do obsługi żądania logowania.
kontekst
dla tych z was, którzy nie są zaznajomieni z pojęciem domen Windows NT, oto szybkie odświeżenie: domena NT to zbiór serwerów sieciowych i innych komputerów, które mają wspólne informacje o zabezpieczeniach i koncie. Domena umożliwia scentralizowane Administrowanie użytkownikami, komputerami i siecią. Informacje zabezpieczające są przechowywane w centralnej bazie danych na serwerze, który jest wyznaczony i skonfigurowany jako główny kontroler domeny (PDC) i jest replikowany na innych serwerach specjalnych, które są oznaczone i skonfigurowane jako kontrolery domeny zapasowej (BDC). Tylko jeden serwer może być PDC w tym samym czasie, ale ta specjalna rola może być przeniesiona do dowolnego BDC w razie potrzeby. Gdy klient korzystający z protokołu TCP/IP próbuje zalogować się do tej domeny NT, żądanie logowania jest przetwarzane przez dowolny kontroler domeny sieci należący do tej samej domeny.
WINS
serwery WINS utrzymują listę wszystkich klientów obsługujących WINS w sieci. Serwery WINS przechowują również listę kontrolerów domeny, które są identyfikowane jako typ <1C>. Z powodów znanych tylko im, projektanci WINS zdecydowali, że na liście <1C> powinien być limit 25 wpisów, co oznacza, że kolejne kontrolery domen nie pojawią się na tej liście. Klienci otrzymują tę listę, gdy próbują znaleźć kontrolera domeny do obsługi żądania logowania.

kolejność, w jakiej kontrolery domeny pojawiają się na liście, jest następująca:

1. wpisy kontrolera domeny zarejestrowane na serwerze WINS, w kolejności od Ostatnio odświeżonych do ostatnio odświeżonych
2. wpisy kontrolera domeny uzyskane z replikacji z innymi serwerami WINS
3. pierwszym wpisem jest zawsze PDC

węzły
podczas konfigurowania protokołu TCP/IP na kliencie, jedną z opcji, które możesz zobaczyć (w zależności od instalacji) jest typem węzła. Typ węzła odnosi się do sposobu, w jaki klient znajduje kontroler domeny do obsługi żądań logowania.
w TCP / IP są cztery typy węzłów:

• B-node (węzeł broadcast): gdy klient musi znaleźć kontroler domeny, wykona transmisję. Pierwszy kontroler domeny, który odpowie, otrzyma zadanie obsługi żądania logowania.
• P-node (węzeł punkt-punkt): w tym środowisku zapytania o nazwy kierowane są bezpośrednio do serwera WINS.
• m-node (multi-homed node): środowisko m-node używa najpierw B—node, a następnie—w razie potrzeby-P-node do rozwiązywania nazw.
• H-node (węzeł Hybrydowy): środowisko H-node używa najpierw p-node, a następnie B-node, jeśli usługa nazw jest niedostępna.

przyjrzyjmy się dokładniej każdemu typowi węzła.
B-node
tryb B-node wykorzystuje komunikaty nadawcze do rejestracji i rozwiązywania nazw. Na przykład, jeśli komputer o nazwie NT_PC1 chce komunikować się z komputerem o nazwie nt_pc2, NT_PC1 wysyła komunikat, że szuka NT_PC2. Następnie czeka określony czas na odpowiedź NT_PC2.
B-node ma dwa poważne problemy:

• w dużym środowisku ładuje sieć komunikatami rozgłoszeniowymi.
• zazwyczaj Routery nie przesyłają komunikatów, więc komputery po przeciwnych stronach routera nigdy nie słyszą żądań.

przykłady komputerów w sieci, które mogą być klientami węzła b, obejmują komputery z systemem MS-DOS, Windows 3.1 lub Windows dla grup roboczych, które nie mają zainstalowanego oprogramowania klienta WINS. Możliwe Serwery to serwery sieciowe oparte na Server Message Block (SMB), takie jak IBM LAN Server, DEC PATHWORKS, AT&T StarLAN i LAN Manager dla systemów OS/2 lub UNIX.
P-node
tryb P-node rozwiązuje problemy, których b-node nie rozwiązuje. W środowisku p-node komputery nie tworzą ani nie odpowiadają na wiadomości nadawane. Wszystkie komputery rejestrują się na serwerze WINS, który jest odpowiedzialny za znajomość nazw i adresów komputerów oraz za zapewnienie, że w sieci nie istnieją żadne duplikaty nazw.
w tym środowisku, gdy nt_pc1 chce się komunikować z NT_PC2, pyta Serwer WINS o adres nt_pc2. Po otrzymaniu adresu, nt_pc1 przechodzi bezpośrednio do NT_PC2 bez nadawania. Ponieważ zapytania o nazwy kierowane są bezpośrednio do serwera WINS, p-node unika ładowania sieci komunikatami nadawczymi. Ponieważ wiadomości nadawcze nie są używane, a adres jest odbierany bezpośrednio, komputery mogą znajdować się po przeciwnych stronach routerów.

najistotniejsze problemy z węzłem p to:

• wszystkie komputery muszą być skonfigurowane tak, aby znały adres serwera WINS.
• jeśli serwer WINS jest wyłączony, komputery, które używają go do rozwiązywania adresów, nie mogą dostać się do innych systemów w sieci.

m-node
tryb m-node został stworzony głównie do rozwiązywania problemów związanych z węzłem b i węzłem P. W środowisku m-node, komputer pierwszy próbuje zarejestrować i rozwiązać z B-node. Jeśli to się nie powiedzie, przełącza się na węzeł P. Zalety to:

• M-node może przecinać routery
• ponieważ b-node jest zawsze wypróbowany jako pierwszy, Komputery po tej samej stronie routera nadal działają jak zwykle, jeśli serwer WINS jest wyłączony
• Teoretycznie użycie m-node powinno zwiększyć wydajność sieci LAN

H-node
tryb H-node rozwiązuje najważniejsze problemy związane z komunikatami rozgłoszeniowymi i operacjami routed-environment. Ten tryb jest kombinacją węzła b i węzła p, który wykorzystuje wiadomości nadawcze jako ostateczność. Tryb H-node robi więcej niż zmienia kolejność korzystania z B-node I P-node: jeśli serwer WINS jest wyłączony-co sprawia, że transmisja wiadomości jest koniecznością-komputer nadal sonduje Serwer WINS. Gdy serwer WINS będzie ponownie dostępny, system powróci do p-node. H-node można również skonfigurować tak, aby używał pliku LMHOSTS po niepowodzeniu rozdzielczości nazwy transmisji.
ponieważ p-node jest używany jako pierwszy, nie są generowane żadne komunikaty, jeśli serwer WINS jest uruchomiony, a komputery mogą znajdować się po przeciwnych stronach routerów. Jeśli serwer WINS jest wyłączony, używany jest b-node, więc komputery po tej samej stronie routera nadal działają jak zwykle.
inne kombinacje
inna odmiana, znana jako zmodyfikowany węzeł b, jest również używana w Microsoft networks, dzięki czemu wiadomości mogą przesyłać się między routerami. Zmodyfikowany B-node nie używa trybu P-node ani serwera WINS. W tym trybie b-node używa listy komputerów i adresów, które są przechowywane w pliku LMHOSTS. Jeśli próba węzła b nie powiedzie się, system szuka w LMHOSTS nazwy, a następnie używa powiązanego adresu do przekroczenia routera. Jednak każdy komputer musi mieć tę listę, co stwarza obciążenie administracyjne, ponieważ lista musi być utrzymywana i rozpowszechniana. Zarówno Windows for Workgroups 3.11, jak i LAN Manager 2.x zastosował tak zmodyfikowany system węzłów B. System Windows NT używa tej metody, jeśli serwery WINS nie są używane w sieci. W systemie Windows NT dodano do tego pliku niektóre rozszerzenia, aby ułatwić zarządzanie, ale zmodyfikowany B-node nie jest idealnym rozwiązaniem.

niektóre strony mogą wymagać zarówno trybów B-node, jak i P-node. Chociaż ta konfiguracja może działać, administratorzy muszą zachować szczególną ostrożność i używać jej tylko w sytuacjach przejściowych. Ponieważ hosty p-node nie uwzględniają komunikatów rozgłoszeniowych, a hosty B-node polegają na komunikatach rozgłoszeniowych do rozwiązywania nazw, oba hosty mogą być potencjalnie skonfigurowane z tą samą nazwą NetBIOS, co prowadzi do nieprzewidywalnych wyników. Ponadto, jeśli komputer skonfigurowany do używania b-node ma mapowanie statyczne w bazie danych WINS, komputer skonfigurowany do używania P-node nie może używać tej samej nazwy komputera.
komputery z systemem Windows NT mogą być skonfigurowane jako agenci proxy WINS, aby ułatwić przejście do korzystania z WINS. Klienci sieciowi z systemem Windows (komputery Windows NT, Windows 95 lub windows for Workgroups 3.11 z obsługą WINS) mogą bezpośrednio używać WINS. Komputery inne niż WINS, które są kompatybilne z b-node (jak opisano w RFCs 1001 i 1002), mogą uzyskać dostęp do WINS przez proxy. Serwer proxy WINS to komputer obsługujący funkcję WINS, który nasłuchuje wiadomości nadawanych z zapytaniem o nazwy, a następnie odpowiada na nazwy, które nie znajdują się w podsieci lokalnej. Proxy to komputery typu P-node.
podczas konfigurowania TCP nie znajdziesz sposobu na ustawienie typu węzła. Typ węzła jest ustawiony na wartość domyślną podczas konfiguracji TCP. Domyślnymi typami węzłów TCP/IP systemu Windows 95 są:Typ węzła b-node (0x01)
jeśli DHCP=False, A WINS jest ustawiony ręcznie, typ węzła H-node (0x08)
jeśli DHCP=True, a DHCP ustawia WINS, typ węzła H-node (0x08)
jeśli DHCP=True, a WINS ustawia ręcznie, typ węzła H-node (0x08)
jeśli DHCP=true, a Wins jest wyłączony, wtedy typ węzła B-node (0x01)
jeśli Opcje serwera WINS są dostarczane przez DHCP, to typ węzła powinien być ustawiony przy użyciu opcji DHCP 46; jednak lokalnie definiowanie serwera WINS na kliencie zastąpi te dwie opcje, ponieważ lokalnie zdefiniowane serwery WINS automatycznie ustawiają typ węzła na h-node.
typ węzła można zmienić ręcznie, edytując Rejestr systemu Windows 95. Lokalizacja istnieje w poddrzewie HKEY_LOCAL_MACHINE pod podkluczem
SYSTEM\CURRENTCONTROLSET\SERVICES\VXD \ Mstcp \ node Type
NodeType można dodać jako wartość łańcuchową pod MSTCP, jeśli jeszcze nie istnieje.
żądanie logowania
teraz przyjrzyjmy się temu, co ma miejsce po wprowadzeniu przez Klienta nazwy użytkownika, hasła i informacji o domenie i kliknięciu OK w oknie podpowiedzi logowania (przed obsługą żądania logowania). Windows 9X i Windows NT zachowują się nieco inaczej, więc omówię je osobno.

klient Windows 9X
klient próbuje znaleźć kontroler domeny w sposób określony przez typ węzła, z którym został skonfigurowany. Poniżej przedstawiamy bardzo uproszczoną sekwencję zdarzeń:

1. klient B-node wyśle żądanie. Jeśli serwer nie odpowie, logowanie się nie powiedzie.
2. klient p-node zażąda listy <1C> z serwera WINS. Następnie wyśle żądanie do każdego z serwerów z listy < 1C>, zaczynając od pierwszego (PDC).
3. klienty m-node i H-node wykonują obie te czynności w kolejności opisanej powyżej, z tym wyjątkiem, że jeśli nazwa grupy roboczej klienta jest taka sama jak domena konta, do którego próbowano się zalogować, funkcja wins lookup dla kontrolerów domeny w podsieci lokalnej jest pomijana. Jeśli serwer WINS jest aktywny i osiągalny, oznacza to, że pierwszy kontroler domeny na liście <1C>, który odpowie, zawsze będzie obsługiwał żądanie logowania.

jak wspomniano powyżej, aby upewnić się, że klient jest sprawdzany przez lokalnego kontrolera domeny, należy ustawić nazwę grupy roboczej na taką samą, jak domena reprezentowana przez tego kontrolera domeny. Jeśli jednak chcesz używać grup roboczych w środowisku biurowym, ta metoda zapewnienia lokalnej walidacji może nie być akceptowalna. W takim przypadku typ węzła powinien być ustawiony na m, aby zapewnić, że klient początkowo transmituje w lokalnej podsieci, tak aby była większa szansa, że lokalny kontroler domeny odpowie jako pierwszy. Zauważ, że nie jest to trudna i szybka zasada. Kontroler domeny musi być tylko trochę zajęty—co często ma miejsce na serwerach zdalnych, ponieważ zwykle administratorzy umieszczają pojedynczy kontroler domeny w zdalnej witrynie-a bardziej responsywny, Nie-lokalny kontroler domeny może wejść jako pierwszy.
alternatywnie WINS może być zainstalowany na lokalnym kontrolerze domeny, a klienci mogą go używać jako głównego serwera WINS. Ta metoda może być dobrym pomysłem, jeśli użytkownicy rzadko mają dostęp do zasobów poza lokalną gałęzią, ale jest to dodatkowe obciążenie dla serwera, który prawdopodobnie dostarcza usługi plików i drukowania, DHCP, SQL, Exchange i inne obowiązki.
jeśli nazwa grupy roboczej różni się od domeny konta, użycie m-node zwiększy szanse na obsługę żądania logowania lokalnie.
Windows NT client
Windows NT logon różni się nieco od Windows 9X logon—stacja robocza NT ma identyfikator maszyny w domenie. Tak więc klient przechodzi przez cztery kroki walidacji logowania. Najpierw klient NT Workstation weryfikuje swój identyfikator maszyny za pomocą kontrolerów domeny z domeny zasobu, a następnie wysyła informacje o logowaniu użytkownika w celu weryfikacji przelotowej. Kontroler domeny z domeny zasobu przekazuje informacje o logowaniu do kontrolera domeny w domenie konta. Resource domain-kontroler domeny następnie przekazuje z powrotem informacje uwierzytelniające Użytkownika (otrzymane od domeny konta-kontroler domeny) do użytkownika.

niezależnie od tego, czy użytkownicy są do nich zalogowani, klienci NT Workstation przechodzą walidację ID podczas inicjalizacji i zgodnie z wymaganiami później (na przykład, jeśli ktoś loguje się do maszyny NT z lokalnym profilem buforowanym, ponieważ kontroler domeny zasobów jest wyłączony).
po pierwsze pochodzi nazwa kontrolerów domeny. Klient stacji roboczej NT musi zlokalizować domenę zasobów-kontroler domeny. Proces wykrywania używany przez Klienta stacji roboczej NT do znalezienia kontrolera domeny zasobów jest taki sam, jak ten używany przez kontroler domeny zasobów do nawiązania zaufanego połączenia z kontrolerem domeny konta.
następnie sprawdzany jest identyfikator maszyny NT. Klient NT Workstation zawsze wysyła lokalną transmisję logowania do Resource-Domain < 1C> przed wysłaniem żądań logowania unicast do kontrolerów resource domain-domain uzyskanych z WINS.
klient weryfikuje identyfikator maszyny stacji roboczej NT – pierwszy kontroler domeny z domeny zasobu odpowiada z powrotem na żądanie logowania.
klient NT Workstation prosi kontrolera domeny zasobów o wyliczenie listy zaufanych domen. Uzyskane nazwy domen są wyświetlane w polu rozwijanym Domena w oknie logowania.
klient NT Workstation przekazuje poświadczenia logowania użytkownika do kontrolera domeny zasobów i żąda uwierzytelnienia przelotowego.
kontroler domeny zasobu przekazuje poświadczenia logowania użytkownika do kontrolera domeny konta, z którym nawiązało zaufane połączenie i żąda uwierzytelnienia użytkownika. Następnie przekazuje informacje o walidacji do klienta stacji roboczej NT.
klient NT Workstation pobiera nazwę konta domena-kontroler domeny z zasobu domena-kontroler domeny, aby podłączyć i wykonać skrypt logowania/profil, jeśli został skonfigurowany.
użytkownik NT jest teraz zalogowany do domeny konta, wykonał skrypt logowania i dokonał odpowiednich połączeń sieciowych do katalogów domowych.
oczywiście, jeśli identyfikator maszyny jest zarejestrowany w domenie spoza podsieci lokalnej lub jeśli użytkownik loguje się do domeny, która nie ma kontrolera domeny w podsieci lokalnej, proces logowania będzie wymagał komunikacji przez sieć WAN. Jeśli jest to wolne łącze, proces logowania zostanie przedłużony.
wniosek
w przypadku klientów Windows 9x uwierzytelnianie lokalnie jest osiągane poprzez nadanie nazwy grupy roboczej takiej samej jak nazwa logowania lub konta, domeny lub poprzez użycie trybu b lub węzła m, aby upewnić się, że żądanie logowania jest najpierw nadawane lokalnie. Oczywiście b-node nie jest zbyt wszechstronny i spowoduje nieudane logowanie, jeśli lokalny kontroler domeny nie zareaguje szybko.
w przypadku klientów Windows NT powinien istnieć kontroler domeny zasobów i kontroler domeny konta w segmencie lokalnym. (Może to być jeden serwer, jeśli domeny zasobu i konta są takie same.)
możesz jeszcze bardziej usprawnić proces, posiadając wiele serwerów WINS i wskazując klientom Serwer WINS, który zarejestruje lokalny lub najbliższy kontroler domeny na liście < 1C>.

kariera komputerowa Richarda Charringtona rozpoczęła się, gdy zaczął pracować z komputerami PC—jeszcze wtedy, gdy były one znane jako mikrokomputery. Zaczynając jako programista, wspinał się na wyżyny administratora Systemów Windows NT i zrobił prawie wszystko pomiędzy. Richard pracował z Windows, ponieważ wcześniej miał odpowiedni GUI, a z Windows NT, ponieważ był LANManager. Teraz wykonawca, on wsunął się do pisania skryptów dla Windows NT i zbudował kilka bardzo przydatnych narzędzi auto-admin.

autorzy i redaktorzy zadbali o przygotowanie treści zawartych w niniejszym dokumencie, ale nie udzielają żadnych wyraźnych ani dorozumianych gwarancji i nie ponoszą odpowiedzialności za błędy lub pominięcia. Nie ponosimy odpowiedzialności za jakiekolwiek szkody. Zawsze miej zweryfikowaną kopię zapasową przed dokonaniem jakichkolwiek zmian.