NetBIOS över en VPN: namn, datagram och session är separata tjänster

«NetBIOS korsar inte routrar» upprepas som om det avgjorde designen. Det gör det inte. En namnsökning via broadcast stannar oftast inom sin egen broadcast-domän, men NetBIOS-tjänster kan också använda riktad IP-trafik som routas alldeles utmärkt. Den användbara frågan är inte om NetBIOS korsar routrar; den är vilken av dess tre tjänster din applikation använder.

Ett programvarugränssnitt, inte ett enda trådprotokoll

RFC 1001 beskriver NetBIOS som ett gränssnitt som applikationer programmerar mot, med flera transportlager under. Dess TCP/UDP-modell skiljer namntjänsten, datagramdistributionen och sessionstjänsten, och den stöder uttryckligen drift med eller utan IP-broadcast.

Det är den tabellen som gör att slagordet faller. En sessionstjänst mellan två namngivna värdar är ett IP-samtal; ett broadcast-datagram är det inte. En VPN-design kan uppfylla det första och inte det andra, och ett test som bevisar det första säger ingenting om det andra.

Nodtyper avgör vad klienten frågar efter

RFC 1001:s broadcast-, punkt-till-punkt- och blandade nodmodeller beskriver hur en värd löser namn: genom att fråga det lokala nätet, genom att fråga en namnserver direkt eller genom att prova det ena och sedan det andra. Modellen påverkar vilken trafik som måste tillåtas, inte om applikationen fungerar alls.

En hanterad namnserverlösning ger klienterna en punkt-till-punkt-väg, men bara till klienter som är konfigurerade att använda den. Att placera en server någonstans i nätet får inte en applikation att fråga den, och en klient som lämnas i broadcast-läge fortsätter att fråga det lokala segmentet och går till tidsgräns. Serverns adress måste nå klientens konfiguration, via vilken hanteringsväg den klienten än respekterar.

Notera därför tre observationer för den aktuella applikationen: hur den omvandlar servernamnet till en adress, om upptäckt eller meddelanden använder broadcast eller en riktad ändpunkt, och vilken adress och transport den faktiska sessionen använder. Det är oberoende fakta, och var och en har sin egen lösning. En enda lyckad namnmatchning är bara bevis om den första.

NetBIOS över TCP/IP är inte NetBEUI

De två förväxlas eftersom båda kallas gamla. NetBIOS över TCP/IP bär sina tjänster inne i IP-paket, som en routad tunnel redan transporterar. NetBEUI är ett icke-routbart protokoll på lager 2, och en IP-tunnel transporterar inte godtyckliga Ethernet-ramar bara för att den transporterar IP.

Att lägga till en IP-rutt kan inte göra en icke-IP-ram till en IP-applikation. Om en applikation verkligen är beroende av beteende på lager 2, är valen en uttryckligen avgränsad tjänst på lager 2 eller att ersätta applikationen; ingen routingändring ersätter någon av dem.

Välj den minsta ändring som uppfyller uppgiften

En befintlig SMB-delning som nås via ett godkänt DNS-namn och en explicit UNC-sökväg behöver ingen Ethernet-utökning. Filuppgiften och bläddringsupplevelsen är olika krav, och bara det andra beror på grannlistan. Att nå delningen via namn löser uppgiften utan att sträcka broadcast-domänen genom en tunnel.

Det är bläddringen som oftast misslyckas, och den misslyckas tyst. En maskin kan öppna en delning via sökväg medan listan över närliggande datorer förblir tom, eftersom listan fylls av broadcast-upptäckt och sökvägen använder DNS. Att bestämma att du behöver listan är ett annat krav än att bestämma att du behöver filen. Skriv ner vilket av dem användaren faktiskt bad om innan du designar något.

När en gammal applikation verkligen kräver broadcast eller icke-IP-ramar, bedöm en avgränsad tjänst på lager 2 med en namngiven ägare, eller ersätt applikationen. En bro utökar den delade feldomenen och policygränsen, och det är ett arkitekturbeslut, inte en kryssruta märkt NetBIOS. Dokumentera de konkreta operationer som tunneln måste bära, så kan en administratör bedöma begäran i stället för att gissa om «hela Windows-nätverket».