Interne namen falen op de VPN terwijl publieke sites gewoon oplossen

Eén gebruiker meldt dat de intranet-hostnaam niet wordt opgelost via de VPN. Een tweede melding, vanaf dezelfde laptop, zegt dat een lektest nog steeds query's laat zien die door de lokale resolver worden beantwoord. Ze klinken als één probleem en zijn er twee, met verschillend bewijs, en de gebruikelijke reparatie voor het eerste maakt het tweede erger. Scheid ze voordat je een instelling aanraakt.

Twee symptomen die niet één storing zijn

Een interne naam niet kunnen oplossen betekent dat de vraag ergens terechtkwam waar geen antwoord voor is. Query's die de tunnel verlaten betekenen dat de vraag op de verkeerde plek kwam, zelfs toen het antwoord beschikbaar was. Dat zijn tegenovergestelde storingen: de ene is een ontbrekend antwoord, de andere een extra bestemming.

De valkuil is dat overal de kantooresolver toevoegen het eerste oplost en het tweede gegarandeerd maakt. Overal een publieke resolver toevoegen doet het omgekeerde.

Schrijf beide waarnemingen met een tijdstempel op en werk daarna de vier controles hieronder in volgorde af.

Welke adapter de vraag bij zijn resolver krijgt

Op Windows kiest de DNS-client servers volgens de bindvolgorde van de adapters, en de tunneladapter staat niet automatisch vooraan. Open de geavanceerde instellingen van de adapter, zet de verbinding voor externe toegang boven de fysieke adapter en maak opnieuw verbinding zodat de wijziging op een nieuwe sessie van toepassing is.

De bindvolgorde is maar de helft. De client moet ook weten welke namen bij die adapter horen, en dat is een suffixvraag, geen volgordevraag.

Zet de ipconfig /all van de werkende machine naast die van de laptop, beide opgenomen terwijl de tunnel actief is. De werkende machine toont een verbindingsspecifiek DNS-suffix op zijn kantooradapter, en de laptop toont er mogelijk geen op de tunnel. Dat verschil verklaart een hele reeks meldingen dat de server er wel is en de naam toch faalt, want zonder suffix wordt de korte naam nooit aangevuld tot de zone die de kantooresolver bedient.

Een korte naam heeft eerst een suffix nodig, dan een route

Het typen van een niet-gekwalificeerde hostnaam vraagt de resolver een domein te raden. De gok komt uit de suffixlijst die aan de verbinding hangt, en als die lijst leeg is, gaat de query eruit als één label dat geen enkele privézone zal matchen.

Kopieer het suffix van de werkende machine naar de IPv4-eigenschappen van de VPN-adapter op het tabblad DNS en maak daarna opnieuw verbinding. Op Linux is het equivalent het zoekdomein op de tunnelkoppeling, dat systemd-resolved per koppeling toont in plaats van globaal.

Houd de twee instellingen gescheiden in je notities. Een suffix verandert wat er gevraagd wordt; het resolveradres verandert wie er gevraagd wordt. Het ene repareren terwijl het andere fout is, levert een resultaat op dat willekeurig lijkt.

Vraag het eerst rechtstreeks aan de resolver, dan naar de naam

Een rechtstreekse query naar de kantooresolver scheidt een naamprobleem van een padprobleem, omdat hij de resolverselectie van de client volledig omzeilt.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

De eerste opdracht vraagt een specifieke server om een volledig gekwalificeerde naam. Als hij antwoordt, zijn de resolver en de route ernaartoe in orde en zit de fout in de selectie of het suffix. Als hij een time-out geeft, is het adres fout of onbereikbaar en is het probleem routing, niet DNS. De tweede opdracht laat zien wat er met de korte naam gebeurt, en de derde toont de resolverconfiguratie per koppeling op een systemd-host.

Let op wildcard-antwoorden, die sommige netwerken voor onbekende namen teruggeven. Een antwoord dat plausibel lijkt, is geen bewijs dat de bedoelde server antwoordde, dus vergelijk het teruggegeven adres met het adres dat de interne dienst werkelijk gebruikt. Als het adres bij een parkeerpagina of een proxy hoort, antwoordde de resolver wel, maar was het antwoord nooit van jou. Dat onderscheid bespaart een uur jagen op een tunnel die al die tijd werkte.

Op Linux vervangt een VPN-client die /etc/resolv.conf herschrijft de lokale resolvers volledig. vpnc biedt DNSUpdate no om dat te stoppen, en systemd-resolved kan alleen de opgegeven domeinen naar de tunnelkoppeling routeren. Beide aanpakken houden publieke namen bij de lokale resolver terwijl interne namen naar kantoor gaan.

Lekken zijn een regel, geen vinkje

Naamresolutie is een UDP-uitwisseling naar poort 53, dus een tunnel die webverkeer maar geen UDP vervoert, laat de query op het fysieke pad. Bewijs het door op de fysieke NIC mee te kijken terwijl een publieke naam wordt opgelost. Een query die op die interface leesbaar zichtbaar is, betekent dat de tunnel hem niet vervoert.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Als de query op die interface leesbaar verschijnt, vervoert de tunnel hem niet. De reparatie is een regel die poort 53 alleen toestaat naar de resolver die de VPN pushte en andere bestemmingen laat vallen, plus een clientconfiguratie die de gepushte optie niet stilzwijgend weggooit.

Dat laatste deel is belangrijker dan het lijkt. Start OpenVPN met route-nopull en de gepushte DNS-optie verdwijnt samen met de routes, tenzij het pull-filter wordt verbreed om hem te behouden. Een client die dhcp-option DNS negeert, blijft gebruiken wat hij al had. Elke wijziging aan de serverkant vereist een nieuwe sessie om effect te hebben, want de resolverlijst wordt geleverd wanneer de tunnel opkomt en een oude sessie blijft de oude toestand tonen.

Noteer welke storing je werkelijk hebt waargenomen voordat je de ticket sluit. Een ontbrekend intern antwoord en een query die de tunnel ontsnapt vragen om verschillende reparaties, en een suffixwijziging die het eerste oplost kan het tweede stilletjes verergeren. Wie de ticket hierna oppakt, vertrouwt op het label, dus maak het label juist.