NetBIOS su una VPN: nome, datagramma e sessione sono servizi separati
Lo slogan sui router è troppo ampio. Verificate quale dei tre servizi usa la vostra applicazione e se risolve i nomi per broadcast o tramite un server.
«NetBIOS non attraversa i router» si ripete come se avesse risolto il progetto. Non lo ha fatto. Una ricerca del nome per broadcast di solito resta nel proprio dominio di broadcast, ma i servizi NetBIOS possono usare anche traffico IP diretto che viene instradato benissimo. La domanda utile non è se NetBIOS attraversi i router; è quale dei suoi tre servizi usa la vostra applicazione.
Un’interfaccia software, non un solo protocollo su cavo
La RFC 1001 descrive NetBIOS come un’interfaccia contro cui le applicazioni programmano, con diversi trasporti sotto. Il suo modello TCP/UDP separa il servizio dei nomi, la distribuzione dei datagrammi e il servizio di sessione, e supporta esplicitamente il funzionamento con o senza broadcast IP.
| Service | What it does | Transport dependence |
|---|---|---|
| Name | Registers and resolves names | Broadcast, point-to-point, or a name server |
| Datagram | Connectionless messages, including broadcast | Broadcast domain or directed delivery |
| Session | Connection-oriented exchange | TCP connection to a named endpoint |
È quella tabella a far fallire lo slogan. Un servizio di sessione tra due host con nome è una conversazione IP; un datagramma in broadcast no. Un progetto VPN può soddisfare il primo e non il secondo, e un test che dimostra il primo non dice nulla sul secondo.
I tipi di nodo decidono cosa chiede il client
I modelli di nodo broadcast, punto a punto e misto della RFC 1001 descrivono come un host risolve i nomi: interrogando la rete locale, interrogando direttamente un server dei nomi, oppure provando l’uno e poi l’altro. Il modello influisce su quale traffico debba essere permesso, non sul fatto che l’applicazione funzioni o meno.
Una disposizione gestita con server dei nomi dà ai client un percorso punto a punto, ma solo ai client configurati per usarlo. Mettere un server da qualche parte sulla rete non fa sì che un’applicazione lo consulti, e un client lasciato in modalità broadcast continuerà a interrogare il segmento locale e andrà in timeout. L’indirizzo del server deve raggiungere la configurazione del client, attraverso quel percorso di gestione che il client rispetta.
Annotate quindi tre osservazioni per l’applicazione in questione: come trasforma il nome del server in un indirizzo, se l’individuazione o la messaggistica usano il broadcast o un endpoint diretto, e quale indirizzo e trasporto usa la sessione reale. Sono fatti indipendenti, e ciascuno ha la propria correzione. Un solo successo di risoluzione del nome è una prova solo per il primo.
NetBIOS su TCP/IP non è NetBEUI
I due vengono confusi perché entrambi sono detti obsoleti. NetBIOS su TCP/IP porta i suoi servizi dentro pacchetti IP, che un tunnel instradato trasporta già. NetBEUI è un protocollo di livello 2 non instradabile, e un tunnel IP non trasporta frame Ethernet arbitrari solo perché trasporta IP.
Aggiungere una rotta IP non può convertire un frame non IP in un’applicazione IP. Se un’applicazione dipende davvero dal comportamento del livello 2, le opzioni sono un servizio di livello 2 esplicitamente delimitato oppure la sostituzione dell’applicazione; nessun cambiamento di routing sostituisce nessuna delle due.
Scegliete il cambiamento più piccolo che soddisfa il compito
Una condivisione SMB esistente raggiunta tramite un nome DNS approvato e un percorso UNC esplicito non ha bisogno di un’estensione Ethernet. Il compito del servizio file e l’esperienza di esplorazione sono requisiti diversi, e solo il secondo dipende dall’elenco dei vicini. Raggiungere la condivisione per nome risolve il compito senza allungare il dominio di broadcast attraverso un tunnel.
L’esplorazione è la parte che di solito fallisce, e fallisce in silenzio. Una macchina può aprire una condivisione per percorso mentre l’elenco dei computer vicini resta vuoto, perché l’elenco è popolato dall’individuazione in broadcast e il percorso usa il DNS. Decidere che serve l’elenco è un requisito diverso dal decidere che serve il file. Annotate quale dei due l’utente ha davvero chiesto prima di progettare qualcosa.
Quando un’applicazione vecchia richiede davvero il broadcast o frame non IP, valutate un servizio di livello 2 delimitato con un proprietario nominato, oppure sostituite l’applicazione. Un bridge amplia il dominio di guasto condiviso e il confine di policy, e questa è una decisione architetturale, non una casella con l’etichetta NetBIOS. Documentate le operazioni precise che il tunnel deve trasportare, e un amministratore potrà valutare la richiesta invece di indovinare su «tutta la rete Windows».