NetBIOS over en VPN: navn, datagram og session er adskilte tjenester
Sloganet om routere er for bredt. Undersøg, hvilken af de tre tjenester din applikation bruger, og om den opløser navne via broadcast eller via en server.
«NetBIOS krydser ikke routere» gentages, som om det afgjorde designet. Det gør det ikke. Et broadcast-navneopslag bliver normalt inde i sit eget broadcast-domæne, men NetBIOS-tjenester kan også bruge dirigeret IP-trafik, som routes ganske udmærket. Det nyttige spørgsmål er ikke, om NetBIOS krydser routere; det er, hvilken af dens tre tjenester din applikation bruger.
En softwaregrænseflade, ikke én ledningsprotokol
RFC 1001 beskriver NetBIOS som en grænseflade, som applikationer programmerer imod, med flere transportlag nedenunder. Dens TCP/UDP-model adskiller navnetjeneste, datagramdistribution og sessionstjeneste, og den understøtter udtrykkeligt drift med eller uden IP-broadcast.
| 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 |
Den tabel er grunden til, at sloganet fejler. En sessionstjeneste mellem to navngivne værter er en IP-samtale; et broadcast-datagram er det ikke. Et VPN-design kan opfylde det første og ikke det andet, og en test, der beviser det første, siger intet om det andet.
Nodetyper afgør, hvad klienten spørger om
RFC 1001's broadcast-, punkt-til-punkt- og blandede nodemodeller beskriver, hvordan en vært opløser navne: ved at spørge det lokale netværk, ved at spørge en navneserver direkte eller ved at prøve det ene og derefter det andet. Modellen påvirker, hvilken trafik der skal tillades, ikke om applikationen fungerer overhovedet.
En administreret navneserverordning giver klienterne en punkt-til-punkt-vej, men kun til klienter, der er konfigureret til at bruge den. At placere en server et sted på netværket får ikke en applikation til at spørge den, og en klient, der efterlades i broadcast-tilstand, vil blive ved med at spørge det lokale segment og løbe ud i tidsudløb. Serverens adresse skal nå klientens konfiguration gennem den administrationsvej, som den klient respekterer.
Noter derfor tre observationer for den pågældende applikation: hvordan den omdanner servernavnet til en adresse, om opdagelse eller meddelelser bruger broadcast eller et dirigeret endepunkt, og hvilken adresse og transport den faktiske session bruger. Det er uafhængige fakta, og hver har sin egen løsning. Én vellykket navneopløsning er kun bevis for det første.
NetBIOS over TCP/IP er ikke NetBEUI
De to forveksles, fordi begge kaldes ældre. NetBIOS over TCP/IP bærer sine tjenester inde i IP-pakker, som en routet tunnel allerede transporterer. NetBEUI er en ikke-routbar lag-2-protokol, og en IP-tunnel bærer ikke vilkårlige Ethernet-rammer, blot fordi den bærer IP.
Det hjælper ikke at tilføje en IP-rute; den kan ikke omdanne en ikke-IP-ramme til en IP-applikation. Hvis en applikation virkelig afhænger af lag-2-adfærd, er valgmulighederne en udtrykkeligt afgrænset lag-2-tjeneste eller at erstatte applikationen; der er ingen ændring i routing, der kan træde i stedet for nogen af dem.
Vælg den mindste ændring, der opfylder opgaven
En eksisterende SMB-deling, der nås via et godkendt DNS-navn og en eksplicit UNC-sti, har ikke brug for en Ethernet-udvidelse. Filopgaven og browseroplevelsen er forskellige krav, og kun det andet afhænger af nabolisten. At nå delingen ved navn løser opgaven uden at strække broadcast-domænet gennem en tunnel.
Det er browsing, der oftest fejler, og det fejler lydløst. En maskine kan åbne en deling via sti, mens listen over nærliggende computere forbliver tom, fordi listen fyldes af broadcast-opdagelse, og stien bruger DNS. At beslutte, at du har brug for listen, er et andet krav end at beslutte, at du har brug for filen. Skriv ned, hvilket af dem brugeren faktisk bad om, før du designer noget.
Når en ældre applikation virkelig kræver broadcast eller ikke-IP-rammer, vurder en afgrænset lag-2-tjeneste med en navngivet ejer, eller udskift applikationen. En bro udvider det fælles fejldomæne og policygrænsen, og det er en arkitekturbeslutning, ikke et afkrydsningsfelt med navnet NetBIOS. Dokumentér de konkrete operationer, som tunnelen skal bære, så kan en administrator vurdere anmodningen i stedet for at gætte på «alt Windows-netværk».