NetBIOS przez VPN: nazwa, datagram i sesja to odrębne usługi

«NetBIOS nie przechodzi przez routery» powtarza się tak, jakby to rozstrzygało projekt. Nie rozstrzyga. Wyszukiwanie nazwy przez rozgłaszanie zwykle pozostaje w swojej własnej domenie rozgłaszania, ale usługi NetBIOS mogą też korzystać z kierowanego ruchu IP, który trasuje się zupełnie dobrze. Użyteczne pytanie nie brzmi, czy NetBIOS przechodzi przez routery; brzmi, której z trzech swoich usług używa Twoja aplikacja.

Interfejs programowy, a nie jeden protokół przewodowy

RFC 1001 opisuje NetBIOS jako interfejs, przeciwko któremu programują aplikacje, z kilkoma transportami pod spodem. Jego model TCP/UDP rozdziela usługę nazw, dystrybucję datagramów i usługę sesji, i wyraźnie obsługuje pracę z rozgłaszaniem IP lub bez niego.

Właśnie ta tabela pokazuje, dlaczego slogan zawodzi. Usługa sesji między dwoma nazwanymi hostami to rozmowa IP; datagram rozgłaszania nią nie jest. Jeden projekt VPN może spełniać pierwsze, a nie drugie, a test, który dowodzi pierwszego, nie mówi nic o drugim.

Typy węzłów decydują, o co pyta klient

Modele węzłów rozgłaszania, punkt-do-punktu i mieszany z RFC 1001 opisują, jak host rozwiązuje nazwy: pytając sieć lokalną, pytając bezpośrednio serwer nazw albo próbując jednego, a potem drugiego. Model wpływa na to, jaki ruch trzeba dopuścić, a nie na to, czy aplikacja w ogóle działa.

Zarządzane rozwiązanie z serwerem nazw daje klientom ścieżkę punkt-do-punktu, ale tylko klientom skonfigurowanym do jej używania. Umieszczenie serwera gdzieś w sieci nie sprawia, że aplikacja go zapyta, a klient pozostawiony w trybie rozgłaszania będzie dalej pytał segment lokalny i doczeka się przekroczenia czasu. Adres serwera musi dotrzeć do konfiguracji klienta, tą ścieżką zarządzania, którą ten klient respektuje.

Zapisz więc trzy obserwacje dla danej aplikacji: jak zamienia nazwę serwera na adres, czy wykrywanie lub komunikacja używają rozgłaszania albo kierowanego punktu końcowego, i jakiego adresu oraz transportu używa rzeczywista sesja. To niezależne fakty i każdy ma własne rozwiązanie. Jedno udane rozwiązanie nazwy jest dowodem tylko co do pierwszego.

NetBIOS przez TCP/IP to nie NetBEUI

Te dwa są mylone, bo oba nazywa się przestarzałymi. NetBIOS przez TCP/IP niesie swoje usługi w pakietach IP, które trasowany tunel i tak przenosi. NetBEUI to protokół warstwy 2, którego nie da się trasować, a tunel IP nie przenosi dowolnych ramek Ethernet tylko dlatego, że przenosi IP.

Dodanie trasy IP nie może zamienić ramki nie-IP w aplikację IP. Jeśli aplikacja naprawdę zależy od zachowania warstwy 2, opcje to wyraźnie ograniczona usługa warstwy 2 albo zastąpienie aplikacji; żadna zmiana trasowania nie zastępuje żadnej z nich.

Wybierz najmniejszą zmianę, która spełnia zadanie

Istniejący udział SMB osiągany przez zatwierdzoną nazwę DNS i jawną ścieżkę UNC nie potrzebuje rozszerzenia Ethernet. Zadanie usługi plików i doświadczenie przeglądania to różne wymagania, a tylko drugie zależy od listy sąsiadów. Osiągnięcie udziału po nazwie rozwiązuje zadanie bez rozciągania domeny rozgłaszania przez tunel.

Przeglądanie to ta część, która zwykle zawodzi, i zawodzi cicho. Maszyna może otworzyć udział po ścieżce, podczas gdy lista pobliskich komputerów pozostaje pusta, bo lista jest wypełniana wykrywaniem rozgłaszania, a ścieżka używa DNS. Decyzja, że potrzebujesz listy, to inne wymaganie niż decyzja, że potrzebujesz pliku. Zapisz, o które naprawdę prosił użytkownik, zanim cokolwiek zaprojektujesz.

Gdy stara aplikacja naprawdę wymaga rozgłaszania lub ramek nie-IP, oceń wyraźnie ograniczoną usługę warstwy 2 z nazwanym właścicielem albo zastąp aplikację. Most poszerza wspólną domenę awarii i granicę polityki, a to decyzja architektoniczna, nie pole wyboru z etykietą NetBIOS. Udokumentuj konkretne operacje, które tunel musi przenosić, a administrator oceni wniosek, zamiast zgadywać o „całej sieci Windows”.