Tipi di nodo TCP/IP e accesso client

Quando si crea un dominio multi-sito instradato su più sottoreti, si può presumere che l’inserimento di un controller di dominio di backup in un sito remoto assicurerà che i client in quel sito vengano convalidati localmente. Lo scopo, ovviamente, è duplice: ridurre il traffico che andrà fuori dalla LAN su un collegamento costoso e garantire che gli accessi client non siano ritardati dalla velocità (o dalla mancanza di esso) della connessione WAN. L’installazione di un controller di dominio locale può effettivamente funzionare, ma il successo sarà di progettazione o per caso?
Sfortunatamente, non c’è modo di specificare il controller di dominio che convaliderà un determinato client, se quel client esegue Windows NT Server, Windows NT Workstation o Windows 9x. Le versioni precedenti di Windows funzioneranno allo stesso modo, a condizione che stiano utilizzando lo stack TCP/IP a 32 bit o uno stack TCP/IP a conoscenza di WINS a 16 bit.
In questo Drill Down giornaliero, ti forniremo una panoramica dei processi coinvolti. Spiegheremo anche perché un controller di dominio situato in un altro paese su un collegamento modem lento potrebbe essere quello scelto da una macchina client per soddisfare la sua richiesta di accesso.
Background
Per quelli di voi che non hanno familiarità con il concetto di domini Windows NT, ecco un rapido aggiornamento: Un dominio NT è una raccolta di server abilitati alla rete e altri computer che condividono informazioni di sicurezza e account comuni. Il dominio fornisce l’amministrazione centralizzata di utenti, computer e rete. Le informazioni di sicurezza vengono conservate in un database centrale su un server designato e configurato come controller di dominio primario (PDC) e vengono replicate su altri server speciali, designati e configurati come controller di dominio di backup (BDC). Solo un server può essere il PDC in qualsiasi momento, ma questo ruolo speciale può essere trasferito a qualsiasi BDC come richiesto. Quando un client che esegue TCP / IP tenta di accedere a questo dominio NT, la richiesta di accesso viene elaborata da uno qualsiasi dei controller di dominio della rete che appartengono allo stesso dominio.
WINS
I server WINS mantengono un elenco di tutti i client WINS abilitati sulla rete. I server WINS mantengono anche un elenco di controller di dominio identificati come type <1C>. Per motivi noti solo a loro, i progettisti di WINS hanno deciso che ci dovrebbe essere un limite di 25 voci nell’elenco <1C>, il che significa che i controller di dominio successivi non appariranno in questo elenco. I client vengono forniti con questo elenco quando tentano di trovare un controller di dominio per soddisfare la loro richiesta di accesso.

L’ordine in cui i controller di dominio appaiono nell’elenco segue questa logica:

1. voci di controller di Dominio registrato con il server WINS, nell’ordine di più rinnovate di recente al meno recente rinfrescato
2. voci di controller di Dominio ottenuto dalla replica con altri server WINS
3. La prima voce è sempre la PDC

Nodi
Quando la configurazione del TCP/IP su un client, è una delle opzioni che si possono vedere (a seconda dell’installazione) è il tipo di nodo. Il tipo di nodo si riferisce al modo in cui il client trova un controller di dominio per soddisfare le sue richieste di accesso.
Ci sono quattro tipi di nodi in TCP / IP:

• Nodo B (nodo broadcast): quando un client deve trovare un controller di dominio, eseguirà una trasmissione. Al primo controller di dominio a rispondere verrà affidato il compito di gestire la richiesta di accesso.
• Nodo P (nodo punto-punto): in questo ambiente, le query dei nomi vanno direttamente al server WINS.
• M-node( nodo multi-homed): un ambiente m-node utilizza prima b-node e poi-se necessario-p-node per risolvere i nomi.
• H-node (nodo ibrido): un ambiente h-node utilizza prima p-node e poi b-node se il servizio dei nomi non è disponibile.

Esaminiamo ogni tipo di nodo in modo più completo.
B-node
La modalità b-node utilizza messaggi broadcast per la registrazione e la risoluzione dei nomi. Ad esempio, se un computer denominato NT_PC1 desidera comunicare con un computer denominato NT_PC2, NT_PC1 invia un messaggio di trasmissione che sta cercando NT_PC2. Quindi attende un tempo specificato per la risposta di NT_PC2.
B-node ha due problemi principali:

• In un ambiente di grandi dimensioni, carica la rete con messaggi broadcast.
• In genere, i router non inoltrano messaggi broadcast, quindi i computer sui lati opposti di un router non sentono mai le richieste.

Esempi di computer in rete che potrebbero essere client b-node includono computer che eseguono MS-DOS, Windows 3.1 o Windows per gruppi di lavoro che non dispongono di software client WINS installato. I server possibili includono server di rete basati su Server Message Block (SMB), come IBM LAN Server, DEC PATHWORKS, AT&T StarLAN e LAN Manager per sistemi OS/2 o UNIX.
P-node
La modalità p-node risolve i problemi che b-node non risolve. In un ambiente p-node, i computer non creano né rispondono ai messaggi broadcast. Tutti i computer si registrano con il server WINS, che è responsabile della conoscenza dei nomi e degli indirizzi dei computer e di garantire che non esistano nomi duplicati sulla rete.

In questo ambiente, quando NT_PC1 vuole comunicare con NT_PC2, interroga il server WINS per l’indirizzo di NT_PC2. Al ricevimento dell’indirizzo, NT_PC1 passa direttamente a NT_PC2 senza trasmissione. Poiché le query del nome vanno direttamente al server WINS, p-node evita di caricare la rete con messaggi broadcast. Poiché i messaggi broadcast non vengono utilizzati e l’indirizzo viene ricevuto direttamente, i computer possono trovarsi su lati opposti dei router.
I problemi più significativi con p-node sono:

• Tutti i computer devono essere configurati per conoscere l’indirizzo del server WINS.
• Se il server WINS è inattivo, i computer che si basano su di esso per risolvere gli indirizzi non possono accedere a nessun altro sistema sulla rete.

M-node
La modalità m-node è stata creata principalmente per risolvere i problemi associati a b-node e p-node. In un ambiente m-node, un computer tenta prima la registrazione e la risoluzione con b-node. Se fallisce, passa a p-node. I vantaggi includono:

• M-nodo è in grado di attraversare i router
• Dal nodo b è sempre provato per primo, computer sullo stesso lato di un router continua a funzionare come al solito se il WINS server è down
• In teoria, utilizzando m-nodo dovrebbe aumentare le prestazioni LAN

H-node
Il nodo h modalità risolve i problemi più significativi associati con la trasmissione di messaggi e instradato-ambiente di operazioni. Questa modalità è una combinazione di nodo b e nodo p che utilizza i messaggi broadcast come ultima risorsa. La modalità h-node non fa altro che modificare l’ordine per l’utilizzo di b-node e p-node: se il server WINS è inattivo, rendendo necessari i messaggi broadcast, il computer continua a eseguire il polling del server WINS. Quando il server WINS può essere raggiunto di nuovo, il sistema ritorna a p-node. H-node può anche essere configurato per utilizzare il file LMHOSTS dopo la risoluzione del nome broadcast non riesce.
Poiché p-node viene utilizzato per primo, non vengono generati messaggi broadcast se il server WINS è in esecuzione e i computer possono trovarsi su lati opposti dei router. Se il server WINS è spento, viene utilizzato b-node, quindi i computer sullo stesso lato di un router continuano a funzionare come al solito.
Altre combinazioni
Un’altra variante, nota come b-node modificato, viene utilizzata anche nelle reti Microsoft in modo che i messaggi possano passare attraverso i router. B-node modificato non utilizza la modalità p-node o un server WINS. In questa modalità, b-node utilizza un elenco di computer e indirizzi memorizzati in un file LMHOSTS. Se un tentativo di nodo b fallisce, il sistema cerca in LMHOSTS per trovare un nome e quindi utilizza l’indirizzo associato per attraversare il router. Tuttavia, ogni computer deve avere questo elenco, il che crea un onere amministrativo perché l’elenco deve essere mantenuto e distribuito. Entrambe le finestre per gruppi di lavoro 3.11 e LAN Manager 2.x ha utilizzato un sistema b-node così modificato. Windows NT utilizza questo metodo se i server WINS non vengono utilizzati nella rete. In Windows NT, alcune estensioni sono state aggiunte a questo file per renderlo più facile da gestire, ma b-node modificato non è una soluzione ideale.

Alcuni siti potrebbero richiedere entrambe le modalità b-node e p-node. Sebbene questa configurazione possa funzionare, gli amministratori devono prestare estrema cautela e utilizzarla solo per situazioni di transizione. Poiché gli host p-node ignorano i messaggi broadcast e gli host b-node si affidano ai messaggi broadcast per la risoluzione dei nomi, i due host possono potenzialmente essere configurati con lo stesso nome NetBIOS, portando a risultati imprevedibili. Inoltre, se un computer configurato per utilizzare b-node ha una mappatura statica nel database WINS, un computer configurato per utilizzare p-node non può utilizzare lo stesso nome del computer.
I computer che eseguono Windows NT possono essere configurati come agenti proxy WINS per facilitare la transizione all’utilizzo di WINS. I client di rete basati su Windows (computer Windows NT, Windows 95 o Windows per gruppi di lavoro 3.11 abilitati per WINS) possono utilizzare direttamente WINS. I computer non WINS compatibili con b-node (come descritto in RFC 1001 e 1002) possono accedere alle WINS tramite proxy. Un proxy WINS è un computer abilitato a WINS che ascolta i messaggi broadcast name-query e quindi risponde per i nomi che non si trovano nella sottorete locale. I proxy sono computer p-node.
Quando si configura TCP, non si trova alcun modo per impostare il tipo di nodo. Il tipo di nodo è impostato su un valore predefinito durante la configurazione TCP. I tipi di nodo TCP/IP predefiniti di Windows 95 sono:
Se il DHCP=False, e VINCE ” è disabilitata, il Tipo di Nodo b nodo (0x01)
Se il DHCP=False, e VINCE è impostato manualmente, quindi Tipo di Nodo nodo h (0x08)
Se il DHCP=True, DHCP e imposta VINCE, Tipo di Nodo nodo h (0x08)
Se il DHCP=True, e VINCE è impostato manualmente, quindi Tipo di Nodo nodo h (0x08)
Se il DHCP=True, e VINCE ” è disabilitata, il Tipo di Nodo b nodo (0x01)
Se un server WINS opzioni sono fornite tramite DHCP, Tipo di Nodo deve essere impostato utilizzando l’opzione DHCP 46; tuttavia, la definizione locale di un server WINS sul client sovrascriverà queste due opzioni poiché i server WINS definiti localmente impostano automaticamente il tipo di nodo su h-node.
Il tipo di nodo può essere modificato manualmente modificando il Registro di Windows 95. La posizione esiste sotto l’albero secondario HKEY_LOCAL_MACHINE sotto la sottochiave
SYSTEM\CURRENTCONTROLSET\SERVICES\VXD \ MSTCP \ Node Type
NodeType può essere aggiunto come valore Stringa sotto MSTCP se non esiste già.
La richiesta di accesso

Ora, diamo un’occhiata a ciò che avviene dopo che il client inserisce il nome utente, la password e le informazioni sul dominio e fa clic su OK nella finestra del prompt di accesso (prima che la richiesta di accesso venga eseguita). Windows 9x e Windows NT si comportano in modo leggermente diverso, quindi li discuterò separatamente.
Client Windows 9x
Il client tenta di trovare un controller di dominio in un modo definito dal tipo di nodo con cui è stato configurato. Di seguito è riportata una sequenza di eventi molto semplificata:

1. Un client b-node trasmetterà una richiesta. Se un server non risponde, l’accesso avrà esito negativo.
2. Un client p-node richiederà l’elenco < 1C> dal server WINS. Quindi trasmetterà una richiesta a ciascuno dei server nell’elenco <1C> a sua volta, iniziando dal primo (il PDC).
3. I client m-node e h-node eseguono entrambe queste operazioni nell’ordine descritto sopra, tranne che, se il nome del gruppo di lavoro del client è lo stesso del dominio dell’account a cui viene tentato l’accesso, la ricerca WINS per i controller di dominio sulla sottorete locale viene ignorata. A condizione che il server WINS sia attivo e raggiungibile, significa che il primo controller di dominio nell’elenco <1C> per rispondere gestirà sempre la richiesta di accesso.

Come menzionato sopra, per garantire che il client sia convalidato dal controller di dominio locale, è necessario rendere il nome del gruppo di lavoro uguale al dominio rappresentato da tale controller di dominio. Tuttavia, se si desidera utilizzare i gruppi di lavoro all’interno dell’ambiente Office, questo metodo per garantire la convalida locale potrebbe non essere accettabile. In questo caso, il tipo di nodo deve essere impostato su m per garantire che il client trasmetta inizialmente sulla sottorete locale in modo che vi sia una migliore possibilità che il controller di dominio locale risponda per primo. Si noti che non è una regola dura e veloce. Il controller di dominio deve solo essere un po ‘ occupato-che i server di siti remoti sono spesso perché è normale che gli amministratori inseriscano un singolo controller di dominio in un sito remoto—e un controller di dominio non locale più reattivo potrebbe entrare per primo.
In alternativa, WINS potrebbe essere installato sul controller di dominio locale e i client potrebbero utilizzarlo come server WINS primario. Questo metodo può essere una buona idea se gli utenti accedono raramente alle risorse al di fuori del ramo locale, ma è un onere aggiuntivo per il server, che probabilmente fornisce servizi di file e stampa, DHCP, SQL, Exchange e altri compiti.

Se il nome del gruppo di lavoro è diverso dal dominio dell’account, l’utilizzo di m-node aumenterà le possibilità di ottenere la richiesta di accesso gestita localmente.
Client Windows NT
L’accesso a Windows NT è leggermente diverso dall’accesso a Windows 9x: la workstation NT ha un ID macchina in un dominio. Quindi, il client passa attraverso quattro passaggi per la convalida dell’accesso. Innanzitutto, il client NT Workstation convalida il proprio ID macchina con i controller di dominio dal dominio della risorsa e quindi invia le informazioni di accesso dell’utente per la convalida pass-through. Il controller di dominio dal dominio della risorsa passa le informazioni di accesso a un controller di dominio nel dominio dell’account. Il resource domain-domain controller restituisce all’utente le informazioni di autenticazione dell’utente (ricevute dal controller di dominio-dominio dell’account).
Indipendentemente dal fatto che gli utenti abbiano effettuato l’accesso, i client NT Workstation passano attraverso la convalida dell’ID durante l’inizializzazione e come richiesto in seguito (ad esempio se qualcuno accede alla macchina NT con il profilo memorizzato nella cache locale perché il controller di dominio delle risorse non è attivo).
Prima viene la risoluzione dei nomi dei controller di dominio. Il client NT Workstation deve individuare un dominio di risorsa-controller di dominio. Il processo di rilevamento utilizzato da un client NT Workstation per trovare un controller di dominio risorsa è lo stesso utilizzato dal controller di dominio-dominio risorsa per stabilire una connessione attendibile con un controller di dominio-dominio account.
Successivamente, l’ID macchina NT viene convalidato. Il client NT Workstation invia sempre una trasmissione di accesso locale a Resource-Domain < 1C> prima di inviare richieste di accesso unicast a resource domain-domain controller ottenuti da WINS.
Il client convalida l’ID macchina della workstation NT—con il primo controller di dominio dal dominio della risorsa per rispondere alla richiesta di accesso.
Il client NT Workstation richiede al resource domain-domain controller di enumerare l’elenco dei domini attendibili. I nomi di dominio ottenuti vengono visualizzati nella casella a discesa Dominio nella finestra di accesso.
Il client NT Workstation passa le credenziali di accesso dell’utente al resource domain-domain controller e richiede l’autenticazione pass-through.
Il resource domain-domain controller passa le credenziali di accesso dell’utente all’account domain-domain controller con cui ha stabilito una connessione attendibile e richiede di autenticare l’utente. Passa quindi le informazioni di convalida al client NT Workstation.
Il client NT Workstation ottiene il nome dell’account domain-domain controller dal resource domain-domain controller per connettersi ed eseguire lo script di accesso/profilo, se è stato configurato.
L’utente NT è ora connesso al dominio dell’account, ha eseguito uno script di accesso e ha effettuato connessioni di rete appropriate alle directory home.
Naturalmente, se l’ID macchina è registrato con un dominio esterno alla sottorete locale o se l’utente accede a un dominio che non dispone di un controller di dominio sulla sottorete locale, il processo di accesso richiederà la comunicazione tramite la WAN. Se si tratta di un collegamento lento, il processo di accesso verrà esteso.
Conclusione
Con i client Windows 9x, l’autenticazione locale si ottiene rendendo il nome del gruppo di lavoro uguale all’accesso, o all’account, al dominio o utilizzando la modalità b o il nodo m per garantire che la richiesta di accesso venga trasmessa localmente per prima. Ovviamente, b-node non è molto versatile e causerà un accesso non riuscito se il controller di dominio locale non risponde rapidamente.
Con i client Windows NT, dovrebbe esserci un controller di dominio delle risorse e un controller di dominio dell’account nel segmento locale. (Potrebbe essere un singolo server se i domini di risorse e account sono gli stessi.)
È possibile migliorare ulteriormente il processo avendo più server WINS e puntando i client al server WINS che registrerà il controller di dominio locale o più vicino nell’elenco <1C>.

La carriera informatica di Richard Charrington è iniziata quando ha iniziato a lavorare con i PC-back quando erano conosciuti come microcomputer. A partire come programmatore, ha lavorato la sua strada fino alle alte altezze di un amministratore di sistemi Windows NT, e ha fatto quasi tutto il resto. Richard ha lavorato con Windows da prima che avesse una GUI corretta e con Windows NT da quando era LANManager. Ora un appaltatore, è scivolato nella scrittura di script per Windows NT e ha costruito alcune utilissime utility di auto-amministrazione.

Gli autori e gli editori si sono presi cura nella preparazione dei contenuti qui contenuti, ma non rilasciano alcuna garanzia espressa o implicita di alcun tipo e non si assumono alcuna responsabilità per errori o omissioni. Nessuna responsabilità è assunta per eventuali danni. Avere sempre un backup verificato prima di apportare modifiche.