VPN-hostnamen falen, IP-adressen werken: waar je moet kijken

Je kunt de share via het adres openen en dezelfde share via de naam faalt, wat betekent dat de tunnel pakketten vervoert en de naamlaag niet. Die ene observatie bespaart een omweg via wijzigingen aan de firewall en de routes. Namen hebben een suffix, een resolver en een pad voor de query nodig, en een VPN-client kan een route installeren zonder een van die drie te installeren. Loop de vier controles hieronder in volgorde na en stop bij de eerste die breekt.

Een naam stelt een vraag die een adres niet stelt

Een adres is een bestemming die de stack meteen kan gebruiken. Een korte naam is een vraag die met een suffix moet worden uitgebreid, naar een resolver moet worden gestuurd en beantwoord moet worden door iets dat de zone kent. Een tunnel die routes installeert maar geen resolver, laat het eerste werken en het tweede kapot. Daarom ziet het symptoom er zo consistent uit bij heel verschillende VPN-producten.

Werk van het adres naar buiten: eerst de volledige naam, dan de kale hostnaam, en noteer welke van de drie werkt. Het patroon vertelt je welke laag je moet onderzoeken voordat je één configuratiescherm opent. Raden naar routes wanneer de FQDN oplost, is verspilde moeite.

Lees de resolver die de tunnel werkelijk heeft geïnstalleerd

Vraag het besturingssysteem welke resolver de queries voor de interne zone afhandelt, niet welke de interface van de VPN-client adverteert. Een server die een publieke resolver zonder interne zone opdringt, levert precies deze fout op, en het is een configuratiefout en geen routeringsstoring.

resolvectl status
nslookup fileserver.corp.example
nslookup fileserver

Op een aan een domein gekoppelde Windows-client bepaalt het routeringsbeleid van de naamruimte welke queries naar welke resolver gaan, en de eigen DNS-instellingen van de VPN-adapter verschijnen in de adapterdetails. Lees het effectieve beleid in plaats van het profiel, want een beleid in de cache kan de verbinding die het installeerde overleven. Als de resolver de volledige naam beantwoordt en niet de korte naam, is het probleem al naar de suffixlijst verschoven.

Get-DnsClientNrptPolicy
ipconfig /all

Stop als de interne zone via de juiste server oplost. De resolver is niet jouw probleem.

Suffixen verklaren korte namen die falen

Een naam met één label wordt vóór het verzenden van de query uitgebreid met de suffixlijst van de verbinding. Als de VPN het interne suffix niet levert, wordt fileserver nooit fileserver.corp.example, en gaat de query eruit als een naam die geen enkele publieke resolver kent. Het suffix opdringen, of de volledige naam typen, test de hypothese zonder iets op de server te wijzigen.

nslookup fileserver.corp.example
ping -a 192.168.50.20

Onder Linux koppelt de resolverservice een DNS-server aan een link en aan een reeks routeringsdomeinen, zodat een opgedrongen server die niet aan de link van de tunnel is gekoppeld, zich gedraagt alsof hij er niet is. Controleer de status per link in plaats van het stub-bestand, dat misschien alleen naar de lokale resolver wijst. Dezelfde splitsing verschijnt in de andere richting: een zoekdomein dat aanwezig is maar niet op de tunnelinterface wordt toegepast, levert korte-naamfouten op die willekeurig lijken.

Als het toevoegen van het suffix het oplost, is het resterende werk dat suffix via het VPN-profiel leveren in plaats van elke gebruiker te vragen het te typen.

NetBIOS en WINS zijn een ander mechanisme

Oude SMB kan een kale naam nog opzoeken met de NetBIOS-naamdienst, die via broadcast of via een WINS-server antwoordt. Broadcast blijft binnen één broadcastdomein en stopt bij de eerste router, dus kan niet over een tunnel reiken; WINS werkt omdat de client een unicastadres heeft om zich bij te registreren en te bevragen. Daarom kan een VPN die alleen IP vervoert nog oude namen ondersteunen wanneer WINS is geconfigureerd en bereikbaar.

nbtstat -n
nbtstat -R

Voor moderne SMB, vertrouw op DNS en de volledige naam, en zet het oude pad op pension. Als het echt oud is, lever WINS of vervang de toepassing; de middenweg is een supportwachtrij die nooit leegloopt.

De wandeling eindigt wanneer je kunt zeggen welke laag faalde: resolver, suffix of oude ontdekking. Noteer de resolver die antwoordde en de naamvorm die werkte, want de volgende persoon begint bij hetzelfde symptoom.