NetBIOS přes VPN: název, datagram a relace jsou oddělené služby

„NetBIOS neprochází přes routery“ se opakuje, jako by to vyřešilo návrh. Nevyřešilo. Vyhledání názvu vysíláním obvykle zůstává uvnitř své vysílací domény, ale služby NetBIOS mohou používat i směrovaný IP provoz, který se směruje naprosto bez problému. Užitečná otázka není, zda NetBIOS prochází přes routery; je to, kterou ze tří služeb vaše aplikace používá.

Softwarové rozhraní, ne jeden drátový protokol

RFC 1001 popisuje NetBIOS jako rozhraní, proti kterému aplikace programují, s několika transporty pod ním. Jeho model TCP/UDP odděluje službu názvů, distribuci datagramů a relační službu a výslovně podporuje provoz s IP vysíláním i bez něj.

Právě tato tabulka ukazuje, proč slogan selhává. Relační služba mezi dvěma pojmenovanými hostiteli je IP rozhovor; vysílací datagram ne. Jeden návrh VPN může splnit první a nesplnit druhé, a test, který prokáže první, neříká o druhém nic.

Typy uzlů rozhodují, o co klient žádá

Vysílací, dvoubodový a smíšený model uzlů z RFC 1001 popisují, jak hostitel řeší názvy: dotazem na místní síť, přímým dotazem na server názvů nebo vyzkoušením jednoho a potom druhého. Model ovlivňuje, jaký provoz je nutné povolit, ne to, zda aplikace vůbec funguje.

Řízené uspořádání se serverem názvů dává klientům dvoubodovou cestu, ale jen klientům nakonfigurovaným, aby ji používali. Umístění serveru někam do sítě nezpůsobí, že se ho aplikace dotáže, a klient ponechaný ve vysílacím režimu bude dál žádat místní segment a čekat do vypršení. Adresa serveru se musí dostat do konfigurace klienta, tou cestou správy, kterou tento klient respektuje.

Zapište si tedy tři pozorování pro dotyčnou aplikaci: jak převádí název serveru na adresu, zda zjišťování nebo zasílání zpráv používá vysílání nebo směrovaný koncový bod a jakou adresu a transport používá skutečná relace. To jsou nezávislá fakta a každé má své řešení. Jedno úspěšné vyřešení názvu je důkazem jen o prvním z nich.

NetBIOS přes TCP/IP není NetBEUI

Obě se zaměňují, protože se oběma říká zastaralé. NetBIOS přes TCP/IP nese své služby uvnitř IP paketů, které směrovaný tunel už přenáší. NetBEUI je nesměrovatelný protokol vrstvy 2 a IP tunel nepřenáší libovolné ethernetové rámce jen proto, že přenáší IP.

Přidání IP trasy nemůže proměnit ne-IP rámec v IP aplikaci. Pokud aplikace skutečně závisí na chování vrstvy 2, jsou možnosti výslovně ohraničená služba vrstvy 2, nebo nahrazení aplikace; žádná změna směrování nenahradí ani jedno z toho.

Zvolte nejmenší změnu, která úkol splní

Stávající sdílená složka SMB dostupná přes schválený název DNS a výslovnou cestu UNC nepotřebuje rozšíření Ethernetu. Úkol souborové služby a zážitek z procházení jsou různé požadavky a jen druhý závisí na seznamu sousedů. Dostat se ke složce podle názvu řeší úkol, aniž by se vysílací doména roztahovala přes tunel.

Procházení je ta část, která obvykle selhává, a selhává tiše. Počítač může otevřít složku po cestě, zatímco seznam okolních počítačů zůstává prázdný, protože seznam se plní zjišťováním vysíláním a cesta používá DNS. Rozhodnutí, že potřebujete seznam, je jiný požadavek než rozhodnutí, že potřebujete soubor. Napište si, o co uživatel skutečně požádal, než cokoli navrhnete.

Když zastaralá aplikace skutečně vyžaduje vysílání nebo ne-IP rámce, posuďte ohraničenou službu vrstvy 2 s pojmenovaným vlastníkem, nebo aplikaci nahraďte. Most rozšiřuje společnou doménu poruch i hranici politiky, což je architektonické rozhodnutí, ne zaškrtávací políčko s nápisem NetBIOS. Zdokumentujte konkrétní operace, které tunel musí přenášet, a správce může žádost posoudit, místo aby hádal o „celé síti Windows“.