Názvy hostiteľov VPN zlyhávajú, IP adresy fungujú: kam sa pozrieť

Zdieľaný prostriedok otvoríte podľa adresy a ten istý prostriedok podľa názvu zlyhá, čo znamená, že tunel prenáša pakety a vrstva názvov nie. Toto jediné pozorovanie ušetrí obchádzku cez zmeny firewallu a trás. Názvy potrebujú príponu, rezolver a cestu pre dopyt, a klient VPN môže nainštalovať trasu bez inštalácie čohokoľvek z toho. Prejdite štyri kontroly nižšie v poradí a zastavte sa pri prvej, ktorá sa zlomí.

Názov kladie otázku, ktorú adresa nekladie

Adresa je cieľ, ktorý zásobník môže použiť okamžite. Krátky názov je otázka, ktorú treba rozšíriť príponou, poslať rezolveru a nechať zodpovedať niečím, čo pozná zónu. Tunel, ktorý inštaluje trasy, ale žiadny rezolver, nechá prvé fungovať a druhé pokazené. Preto symptóm vyzerá tak konzistentne naprieč veľmi odlišnými produktmi VPN.

Pracujte od adresy von: najprv plný názov, potom holý názov hostiteľa, a poznamenajte si, ktorý z troch funguje. Vzor vám povie, ktorú vrstvu preskúmať, než otvoríte jedinú obrazovku nastavení. Hádať trasy, keď sa FQDN prekladá, je zbytočná práca.

Prečítajte si rezolver, ktorý tunel skutočne nainštaloval

Opýtajte sa operačného systému ktorý rezolver spracúva dopyty pre internú zónu, nie ktorý inzeruje rozhranie klienta VPN. Server, ktorý vnucuje verejný rezolver bez internej zóny, produkuje presne toto zlyhanie, a je to chyba konfigurácie, nie porucha smerovania.

resolvectl status
nslookup fileserver.corp.example
nslookup fileserver

Na klientovi Windows pripojenom k doméne rozhoduje zásada smerovania menného priestoru o tom, ktoré dopyty idú ktorému rezolveru, a vlastné nastavenia DNS adaptéra VPN sa objavujú v podrobnostiach adaptéra. Čítajte platnú zásadu, nie profil, pretože zásada v cache môže prežiť pripojenie, ktoré ju nainštalovalo. Ak rezolver odpovedá na plný názov a nie na krátky, problém sa už presunul do zoznamu prípon.

Get-DnsClientNrptPolicy
ipconfig /all

Zastavte sa, ak sa interná zóna prekladá cez správny server. Rezolver nie je váš problém.

Prípony vysvetľujú krátke názvy, ktoré zlyhávajú

Názov s jednou značkou sa pred odoslaním dopytu rozšíri zoznamom prípon pripojenia. Ak VPN nedodá internú príponu, fileserver sa nikdy nestane fileserver.corp.example a dopyt vyjde ako názov, ktorý žiadny verejný rezolver nepozná. Vnútenie prípony alebo napísanie plného názvu otestuje hypotézu bez zmeny čohokoľvek na serveri.

nslookup fileserver.corp.example
ping -a 192.168.50.20

V Linuxe služba rezolvera viaže server DNS na prepojenie a na množinu smerovacích domén, takže vnútený server, ktorý nie je pridružený k prepojeniu tunela, sa správa, akoby tam nebol. Kontrolujte stav po prepojení, nie súbor stub, ktorý môže ukazovať len na miestny rezolver. Rovnaké rozdelenie sa objavuje aj opačným smerom: doména vyhľadávania, ktorá existuje, ale nie je aplikovaná na rozhranie tunela, produkuje zlyhania krátkych názvov, ktoré vyzerajú náhodne.

Ak pridanie prípony problém vyrieši, zostáva doručiť túto príponu cez profil VPN namiesto žiadania každého používateľa, aby ju písal.

NetBIOS a WINS sú iný mechanizmus

Starší SMB ešte dokáže vyhľadať holý názov službou názvov NetBIOS, ktorá odpovedá vysielaním alebo cez server WINS. Vysielanie zostáva v jednej vysielacej doméne a zastaví sa na prvom smerovači, takže nemôže prejsť tunelom; WINS funguje, pretože klient má jednosmerovú adresu, na ktorej sa registruje a ktorú sa pýta. Preto VPN prenášajúci len IP môže stále podporovať staré názvy, keď je WINS nakonfigurovaný a dostupný.

nbtstat -n
nbtstat -R

Pre moderný SMB sa spoľahnite na DNS a plný názov a starú cestu pošlite do dôchodku. Ak je skutočne stará, zabezpečte WINS alebo nahraďte aplikáciu; stredná cesta je front podpory, ktorý sa nikdy nevyprázdni.

Prechádzka končí, keď môžete povedať, ktorá vrstva zlyhala: rezolver, prípona alebo staré zisťovanie. Zapíšte rezolver, ktorý odpovedal, a tvar názvu, ktorý fungoval, pretože ďalší človek začne pri rovnakom symptóme.