tipuri de noduri TCP/IP și logon client

când construiți un domeniu multi-site care este rutat pe mai multe subrețele, puteți presupune că punerea unui controler de domeniu de rezervă într-un site la distanță va asigura că clienții de pe acel site vor fi validați local. Scopul, desigur, este dublu: reducerea traficului care va ieși în afara LAN-ului printr-o legătură scumpă și asigurarea faptului că conectările clienților nu sunt întârziate de viteza (sau lipsa acesteia) a conexiunii WAN. Instalarea unui controler de domeniu local poate funcționa într-adevăr, dar succesul va fi prin proiectare sau accidental?
din păcate, nu există nicio modalitate de a specifica controlerul de domeniu care va valida un anumit client, indiferent dacă acel client rulează Windows NT Server, Windows NT Workstation sau Windows 9x. versiunile anterioare de Windows vor funcționa în același mod, cu condiția să utilizeze stiva TCP/IP pe 32 de biți sau o stivă TCP/IP conștientă de victorii pe 16 biți.
în acest exercițiu zilnic, vă vom oferi o imagine de ansamblu asupra proceselor implicate. Vom explica, de asemenea, de ce un controler de domeniu care este amplasat într-o altă țară pe un link de modem lent poate fi cel ales de o mașină client pentru a-și deservi cererea de conectare.
Background
pentru cei dintre voi care nu sunt familiarizați cu conceptul de domenii Windows NT, iată o actualizare rapidă: un domeniu NT este o colecție de servere activate în rețea și alte computere care partajează informații comune de securitate și cont. Domeniul prevede administrarea centralizată a utilizatorilor, a computerului și a rețelei. Informațiile de securitate sunt păstrate într-o bază de date centrală pe un server care este desemnat și configurat ca controler de domeniu primar (PDC) și este reprodus la alte servere speciale, care sunt desemnate și configurate ca controlere de domeniu de rezervă (BDC). Doar un singur server poate fi PDC la un moment dat, dar acest rol special poate fi transferat la orice BDC după cum este necesar. Când un client care execută TCP / IP încearcă să se conecteze la acest domeniu NT, cererea de conectare este procesată de oricare dintre controlerele de domeniu ale rețelei care aparțin aceluiași domeniu.
WINS
WINS servere menține o listă a tuturor clienților WINS activat în rețea. Serverele WINS mențin, de asemenea, o listă de controlere de domeniu care sunt identificate ca tip <1C>. Din motive cunoscute numai de aceștia, designerii WINS au decis că ar trebui să existe o limită de 25 de intrări în lista <1C>, ceea ce înseamnă că controlerele de domeniu ulterioare nu vor apărea pe această listă. Clienților li se oferă această listă atunci când încearcă să găsească un controler de domeniu pentru a-și deservi cererea de conectare.

ordinea în care controlerele de domeniu apar pe listă urmează această logică:

1. intrările controlerului de domeniu înregistrate la serverul WINS, în ordinea celor mai recent actualizate până la cel mai puțin recent actualizate
2. intrările controlerului de domeniu obținute din replicarea cu alte servere WINS
3. prima intrare este întotdeauna PDC

noduri
când configurați TCP/IP pe un client, una dintre opțiunile pe care le puteți vedea (în funcție de instalare) este tipul de nod. Tipul nodului se referă la modul în care clientul găsește un controler de domeniu pentru a-și deservi cererile de conectare.
există patru tipuri de noduri în TCP / IP:

• B-node (broadcast node): când un client trebuie să găsească un controler de domeniu, acesta va efectua o difuzare. Primul controler de domeniu care va răspunde va primi sarcina de a deservi cererea de conectare.
• nod P (nod punct-la-punct): în acest mediu, interogările de nume merg direct la serverul WINS.
• m-node (multi-homed node): un mediu m-node folosește mai întâi nodul b și apoi-dacă este necesar—nodul p pentru a rezolva numele.
• h-node (nod hibrid): un mediu h-node folosește mai întâi nodul p și apoi nodul B dacă serviciul de nume nu este disponibil.

să examinăm fiecare tip de nod mai complet.
B-node
modul B-node utilizează mesaje difuzate pentru înregistrarea și rezoluția numelui. De exemplu, dacă un computer numit NT_PC1 dorește să comunice cu un computer numit NT_PC2, NT_PC1 trimite un mesaj de difuzare că caută NT_PC2. Apoi așteaptă un timp specificat pentru NT_PC2 pentru a răspunde.
nodul B are două probleme majore:

• într-un mediu mare, încarcă rețeaua cu mesaje difuzate.
• de obicei, routerele nu redirecționează mesajele difuzate, astfel încât computerele de pe laturile opuse ale unui router nu aud niciodată solicitările.

Exemple de computere din rețea care ar putea fi clienți cu noduri b includ computerele care rulează MS-DOS, Windows 3.1 sau Windows pentru grupuri de lucru care nu au instalat software-ul client WINS. Serverele posibile includ servere de rețea bazate pe Server Message Block (SMB), cum ar fi IBM LAN Server, DEC PATHWORKS, AT&t StarLAN și LAN Manager pentru sistemele OS/2 sau UNIX.
p-node
modul P-node abordează problemele pe care nodul b nu le rezolvă. Într-un mediu P-node, computerele nu creează și nici nu răspund la mesajele difuzate. Toate computerele se înregistrează la serverul WINS, care este responsabil pentru cunoașterea numelor și adreselor computerului și pentru asigurarea faptului că nu există nume duplicate în rețea.

în acest mediu, când NT_PC1 dorește să comunice cu NT_PC2, interoghează serverul WINS pentru adresa NT_PC2. La primirea adresei, NT_PC1 merge direct la NT_PC2 fără difuzare. Deoarece interogările de nume merg direct la serverul WINS, p-node evită încărcarea rețelei cu mesaje difuzate. Deoarece mesajele difuzate nu sunt utilizate și adresa este primită direct, computerele pot fi pe laturile opuse ale routerelor.
cele mai semnificative probleme cu nodul p sunt:

• toate computerele trebuie să fie configurate pentru a cunoaște adresa serverului WINS.
• dacă serverul WINS este defect, computerele care se bazează pe acesta pentru a rezolva adresele nu pot ajunge la alte sisteme din rețea.

m-node
modul m-node a fost creat în primul rând pentru a rezolva problemele asociate cu B-node și p-node. Într-un mediu m-node, un computer încearcă mai întâi înregistrarea și rezoluția cu nodul B. În cazul în care nu reușește, se trece la p-nod. Avantajele includ:

• m-node poate traversa routerele
• deoarece nodul b este întotdeauna încercat mai întâi, computerele de pe aceeași parte a unui router continuă să funcționeze ca de obicei dacă serverul WINS este în jos
• în teorie, utilizarea nodului m ar trebui să crească performanța LAN

nodul H
modul nod h rezolvă cele mai semnificative probleme asociate cu mesajele difuzate și operațiunile de mediu rutate. Acest mod este o combinație de nod b și nod p care utilizează mesajele difuzate ca ultimă soluție. Modul h-node face mai mult decât să schimbe ordinea de utilizare a nodului b și a nodului p: Dacă serverul WINS face din mesajele difuzate o necesitate-computerul continuă să sondeze serverul WINS. Când serverul WINS poate fi atins din nou, sistemul revine la p-node. H-nod, de asemenea, poate fi configurat pentru a utiliza fișierul LMHOSTS după rezoluție nume de difuzare eșuează.
deoarece p-node este utilizat mai întâi, nu sunt generate mesaje difuzate dacă serverul WINS rulează, iar computerele pot fi pe laturile opuse ale routerelor. Dacă serverul WINS este în jos, se utilizează nodul B, astfel încât computerele de pe aceeași parte a unui router continuă să funcționeze ca de obicei.
alte combinații
o altă variantă, cunoscută sub numele de nod B modificat, este utilizată și în rețelele Microsoft, astfel încât mesajele să poată trece prin routere. Modificat B-nod nu utilizează modul P-nod sau un server WINS. În acest mod, B-node utilizează o listă de computere și adrese care sunt stocate într-un fișier LMHOSTS. Dacă o încercare de nod b eșuează, sistemul caută în LMHOSTS pentru a găsi un nume și apoi folosește adresa asociată pentru a traversa routerul. Cu toate acestea, fiecare computer trebuie să aibă această listă, ceea ce creează o sarcină administrativă, deoarece lista trebuie menținută și distribuită. Ambele ferestre pentru grupuri de lucru 3.11 și LAN Manager 2.x a folosit un astfel de sistem B-nod modificat. Windows NT utilizează această metodă dacă serverele WINS nu sunt utilizate în rețea. În Windows NT, unele extensii au fost adăugate la acest fișier pentru a facilita gestionarea, dar nodul B modificat nu este o soluție ideală.

este posibil ca unele site-uri să necesite atât moduri B-node, cât și moduri P-node. Deși această configurație poate funcționa, administratorii trebuie să fie extrem de precauți și să o utilizeze numai pentru Situații de tranziție. Deoarece gazdele p-node ignoră mesajele difuzate și gazdele B-node se bazează pe mesajele difuzate pentru rezoluția numelui, cele două gazde pot fi configurate cu același nume NetBIOS, ducând la rezultate imprevizibile. De asemenea, dacă un computer configurat să utilizeze nodul b are o mapare statică în baza de date WINS, un computer configurat să utilizeze nodul p nu poate utiliza același nume de computer.
computerele care rulează Windows NT pot fi configurate ca agenți proxy WINS pentru a ajuta la trecerea la utilizarea WINS. Clienții de rețea bazate pe Windows (wins-enabled Windows NT, Windows 95, sau Windows pentru grupuri de lucru 3.11 calculatoare) pot utiliza WINS direct. Computerele non-WINS care sunt compatibile cu nodul b (așa cum este descris în RFC-urile 1001 și 1002) pot accesa câștigurile prin proxy-uri. Un proxy WINS este un computer activat WINS care ascultă mesajele difuzate prin interogare de nume și apoi răspunde pentru Numele care nu se află în subrețeaua locală. Proxy-urile sunt computere cu noduri P.
când configurați TCP, nu veți găsi nicio modalitate de a seta tipul de nod. Tipul de nod este setat la o valoare implicită în timpul configurării TCP. Tipurile implicite de noduri Windows 95 TCP / IP sunt:
dacă DHCP=False și WINS este dezactivat, atunci Node type b-node (0x01)
dacă DHCP=False și WINS este setat manual, atunci Node Type h-node (0x08)
dacă DHCP=True și DHCP setează WINS, atunci Node type h-node (0x08)
dacă DHCP=True și WINS este setat manual, atunci Node type h-node (0x08)
dacă DHCP=true, iar Wins este dezactivat, apoi nod tip B-nod (0x01)
dacă Opțiunile serverului wins sunt furnizate prin DHCP, atunci Tipul de nod trebuie setat folosind opțiunea DHCP 46; cu toate acestea, definirea locală a unui server WINS pe client va suprascrie aceste două opțiuni, deoarece serverele WINS definite local setează automat tipul de nod la nodul H.
tipul de nod poate fi modificat manual prin editarea registrului Windows 95. Locația există sub subarborele HKEY_LOCAL_MACHINE sub subcheia
SYSTEM\CURRENTCONTROLSET\SERVICES\VXD\Mstcp\Node Type
NodeType poate fi adăugat ca valoare șir sub MSTCP dacă nu există deja.
cererea de conectare
acum, să ne uităm la ceea ce are loc după ce clientul introduce numele de utilizator, parola și informațiile despre domeniu și face clic pe OK în fereastra promptă de conectare (înainte ca cererea de conectare să fie deservită). Windows 9x și Windows NT se comportă ușor diferit, așa că le voi discuta separat.

Windows 9x client
clientul încearcă să găsească un controler de domeniu într-un mod definit de tipul de nod cu care a fost configurat. Mai jos este o secvență foarte simplificată de evenimente:

1. un client B-node va difuza o cerere. Dacă un server nu răspunde, conectarea va eșua.
2. un client p-node va solicita lista < 1C> de pe serverul WINS. Apoi va difuza o cerere către fiecare dintre serverele din lista <1C> la rândul său, începând cu primul (PDC).
3. clienții nodului m și nodului h fac ambele lucruri în ordinea descrisă mai sus, cu excepția faptului că, dacă numele grupului de lucru al clientului este același cu domeniul contului la care se încearcă conectarea, căutarea WINS pentru controlerele de domeniu din subrețea locală este omisă. Cu condiția ca serverul WINS să fie activ și accesibil, înseamnă că primul controler de domeniu din lista <1C> pentru a răspunde va gestiona întotdeauna cererea de conectare.

după cum sa menționat mai sus, pentru a vă asigura că clientul este validat de controlerul de domeniu local, trebuie să faceți numele grupului de lucru la fel ca domeniul reprezentat de acel controler de domeniu. Cu toate acestea, dacă doriți să utilizați grupuri de lucru în mediul office, este posibil ca această metodă de asigurare a validării locale să nu fie acceptabilă. În acest caz, tipul de nod ar trebui să fie setat la m pentru a se asigura că clientul difuzează inițial pe subrețea locală, astfel încât să existe o șansă mai bună ca controlerul de domeniu local să răspundă mai întâi. Rețineți că nu este o regulă grea și rapidă. Controlerul de domeniu trebuie doar să fie puțin ocupat—care servere de site la distanță sunt adesea pentru că este obișnuit ca administratorii să pună un singur controler de domeniu la un site la distanță—și un controler de domeniu non-local mai receptiv ar putea intra mai întâi.
alternativ, WINS ar putea fi instalat pe controlerul de domeniu local, iar clienții l-ar putea folosi ca server principal WINS. Această metodă poate fi o idee bună dacă utilizatorii accesează rar resurse în afara sucursalei locale, dar este o povară suplimentară pentru server, care probabil furnizează servicii de fișiere și tipărire, DHCP, SQL, Exchange și alte sarcini.
dacă numele grupului de lucru este diferit de domeniul contului, atunci utilizarea m-node va crește șansele de a obține solicitarea de conectare la nivel local.
client Windows NT
conectarea Windows NT este oarecum diferită de conectarea Windows 9x—stația de lucru NT are un ID de mașină într-un domeniu. Deci, clientul trece prin patru pași pentru validarea logon. Mai întâi, clientul stației de lucru NT validează ID-ul mașinii sale cu controlerele de domeniu din domeniul resurselor și apoi trimite informații de conectare a utilizatorului pentru validarea pass-through. Controlerul de domeniu din domeniul resurselor transmite informațiile de conectare la un controler de domeniu din domeniul contului. Resource domain-domain controller transmite apoi utilizatorului informațiile de autentificare a utilizatorului (primite de la cont domain-domain controller).

indiferent dacă utilizatorii sunt conectați sau nu la ei, clienții stației de lucru NT trec prin validarea ID-ului în timpul inițializării și după cum este necesar mai târziu (cum ar fi dacă cineva se conectează la mașina nt cu profilul cache local, deoarece controlerul de domeniu al resurselor este dezactivat).
mai întâi vine rezoluția numelui controlerelor de domeniu. Clientul NT Workstation trebuie să localizeze un domeniu de resurse-controler de domeniu. Procesul de descoperire utilizat de un client NT Workstation pentru a găsi un controler de domeniu de resurse este același cu cel utilizat de controlerul domeniu-domeniu de resurse pentru a stabili o conexiune de încredere cu un controler domeniu-domeniu de cont.
apoi, ID-ul mașinii NT este validat. Clientul stației de lucru NT trimite întotdeauna o difuzare locală de conectare la domeniul de resurse < 1C> înainte de a trimite cereri de conectare unicast către controlerele de domeniu de resurse care sunt obținute din WINS.
clientul validează ID—ul mașinii stației de lucru NT-cu primul controler de domeniu din domeniul resurselor pentru a răspunde înapoi la cererea de conectare.
clientul NT Workstation solicită controlerului de domeniu de resurse să enumere lista de domenii de încredere. Numele de domeniu obținute sunt afișate în caseta derulantă domeniu din fereastra de conectare.
clientul stației de lucru NT transmite acreditările de conectare ale utilizatorului către controlerul de domeniu de resurse și solicită autentificarea prin trecere.
resource domain-domain controller transmite acreditările de conectare ale utilizatorului către cont domain-domain controller cu care a stabilit o conexiune de încredere și îi solicită autentificarea utilizatorului. Apoi trece înapoi informațiile de validare către Clientul stației de lucru NT.
clientul NT Workstation primește numele controlerului domeniu-domeniu de cont de la controlerul domeniu-domeniu de resurse pentru a conecta și executa scriptul/profilul de conectare, dacă a fost configurat.
utilizatorul NT este acum conectat la domeniul contului, a executat un script de conectare și a făcut conexiuni de rețea adecvate la directoarele de acasă.
desigur, dacă ID-ul mașinii este înregistrat cu un domeniu în afara subrețelei locale sau dacă utilizatorul se conectează la un domeniu care nu are un controler de domeniu pe subrețea locală, procesul de conectare va necesita comunicare prin WAN. Dacă este o legătură lentă, procesul de conectare va fi extins.
concluzie
cu clienții Windows 9x, obținerea autentificării locale se realizează făcând numele grupului de lucru la fel ca logon-ul sau contul, domeniul sau utilizând modul B sau nodul m pentru a vă asigura că cererea de conectare este difuzată mai întâi local. Evident, nodul b nu este foarte versatil și va provoca o Conectare eșuată dacă controlerul de domeniu local nu răspunde rapid.
cu clienții Windows NT, ar trebui să existe un controler de domeniu de resurse și un controler de domeniu de cont în segmentul local. (Ar putea fi un singur server dacă resursele și domeniile contului sunt aceleași.)
puteți îmbunătăți procesul în continuare având mai multe servere WINS și îndreptând clienții către serverul WINS care va înregistra controlerul de domeniu local sau cel mai apropiat în lista < 1C>.

cariera de calculator Richard Charrington a început atunci când a început să lucreze cu PC—uri-înapoi când au fost cunoscute sub numele de microcomputere. Începând ca programator, și-a croit drum până la înălțimile înalte ale unui Administrator de sisteme Windows NT și a făcut aproape totul între ele. Richard a lucrat cu Windows, deoarece înainte de a avea o interfață grafică adecvată și cu Windows NT, deoarece a fost LANManager. Acum, un antreprenor, el a alunecat în script scris Pentru Windows NT și a construit unele utilitati foarte utile auto-admin.

autorii și editorii au avut grijă în pregătirea conținutului conținut aici, dar nu fac nici o garanție explicită sau implicită de orice fel și nu își asumă nici o responsabilitate pentru erori sau omisiuni. Nici o responsabilitate este asumată pentru orice daune. Aveți întotdeauna o copie de rezervă verificată înainte de a efectua modificări.