NetBIOS sur un VPN : le nom, le datagramme et la session sont des services distincts
Le slogan sur les routeurs est trop large. Vérifiez lequel des trois services votre application utilise, et si elle résout les noms par diffusion ou par un serveur.
« NetBIOS ne traverse pas les routeurs » se répète comme si cela réglait la conception. Ce n’est pas le cas. Une recherche de nom par diffusion reste généralement dans son propre domaine de diffusion, mais les services NetBIOS peuvent aussi utiliser du trafic IP dirigé qui s’achemine parfaitement bien. La question utile n’est pas de savoir si NetBIOS traverse les routeurs ; c’est de savoir lequel de ses trois services votre application utilise.
Une interface logicielle, pas un seul protocole câblé
La RFC 1001 décrit NetBIOS comme une interface contre laquelle les applications se programment, avec plusieurs transports en dessous. Son modèle TCP/UDP sépare le service de noms, la distribution des datagrammes et le service de session, et il prend explicitement en charge le fonctionnement avec ou sans diffusion 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 |
C’est ce tableau qui fait échouer le slogan. Un service de session entre deux hôtes nommés est une conversation IP ; un datagramme de diffusion ne l’est pas. Une conception de VPN peut satisfaire le premier et pas le second, et un test qui prouve le premier ne dit rien du second.
Les types de nœud décident de ce que demande le client
Les modèles de nœud de diffusion, point à point et mixte de la RFC 1001 décrivent comment un hôte résout les noms : en interrogeant le réseau local, en interrogeant directement un serveur de noms, ou en essayant l’un puis l’autre. Le modèle influe sur le trafic à autoriser, pas sur le fait que l’application fonctionne ou non.
Un dispositif géré avec serveur de noms donne aux clients un chemin point à point, mais seulement aux clients configurés pour l’utiliser. Placer un serveur quelque part sur le réseau ne fait pas qu’une application le consulte, et un client laissé en mode diffusion continuera d’interroger le segment local et finira par expirer. L’adresse du serveur doit atteindre la configuration du client, par le chemin de gestion que ce client respecte.
Notez donc trois observations pour l’application concernée : comment elle transforme le nom du serveur en adresse, si la découverte ou la messagerie utilise la diffusion ou un point de terminaison dirigé, et quelle adresse et quel transport la session réelle utilise. Ce sont des faits indépendants, et chacun a sa propre correction. Une seule résolution de nom réussie n’est une preuve que pour le premier.
NetBIOS sur TCP/IP n’est pas NetBEUI
Les deux sont confondus parce qu’on les qualifie tous deux d’anciens. NetBIOS sur TCP/IP transporte ses services dans des paquets IP, qu’un tunnel routé achemine déjà. NetBEUI est un protocole de couche 2 non routable, et un tunnel IP ne transporte pas des trames Ethernet arbitraires simplement parce qu’il transporte de l’IP.
Ajouter une route IP ne peut pas convertir une trame non IP en application IP. Si une application dépend réellement du comportement de la couche 2, les options sont un service de couche 2 explicitement délimité ou le remplacement de l’application ; aucun changement de routage ne remplace l’une ni l’autre.
Choisissez le plus petit changement qui satisfait la tâche
Un partage SMB existant atteint par un nom DNS approuvé et un chemin UNC explicite n’a pas besoin d’une extension Ethernet. La tâche du service de fichiers et l’expérience de navigation sont des exigences différentes, et seule la seconde dépend de la liste des voisins. Atteindre le partage par son nom résout la tâche sans étirer le domaine de diffusion à travers un tunnel.
La navigation est la partie qui échoue le plus souvent, et elle échoue en silence. Une machine peut ouvrir un partage par chemin pendant que la liste des ordinateurs proches reste vide, parce que la liste est remplie par la découverte par diffusion et que le chemin utilise DNS. Décider que vous avez besoin de la liste est une exigence différente de décider que vous avez besoin du fichier. Notez laquelle des deux l’utilisateur a réellement demandée avant de concevoir quoi que ce soit.
Lorsqu’une application ancienne exige vraiment la diffusion ou des trames non IP, évaluez un service de couche 2 délimité avec un propriétaire nommé, ou remplacez l’application. Un pont élargit le domaine de panne partagé et la frontière de politique, ce qui est une décision d’architecture et non une case à cocher portant l’étiquette NetBIOS. Documentez les opérations précises que le tunnel doit transporter, et un administrateur pourra évaluer la demande au lieu de deviner « tout le réseau Windows ».