Interne navne fejler på VPN, mens offentlige sider virker

En bruger rapporterer, at intranet-værtsnavnet ikke slår op over VPN. En anden rapport, fra samme bærbare, siger at en lækagetest stadig viser forespørgsler besvaret af den lokale resolver. De lyder som ét problem og er to, med forskellige beviser, og den sædvanlige reparation af det første gør det andet værre. Adskil dem, før du rører en indstilling.

To symptomer, der ikke er én fejl

At et internt navn ikke kan slås op betyder, at spørgsmålet gik et sted hen, hvor der ikke findes et svar. At forespørgsler forlader tunnelen betyder, at spørgsmålet gik det forkerte sted hen, selv når svaret var tilgængeligt. Det er modsatte fejl: den ene er et manglende svar, den anden er en overflødig destination.

Fælden er, at tilføjelse af kontorets resolver overalt retter den første og garanterer den anden. Tilføjelse af en offentlig resolver overalt gør det modsatte.

Skriv begge observationer ned med tidsstempel, og gå derefter gennem de fire kontroller nedenfor i rækkefølge.

Hvilken adapters resolver får spørgsmålet

På Windows vælger DNS-klienten servere efter adapterbindingernes rækkefølge, og tunneladapteren er ikke automatisk først. Åbn adapterens avancerede indstillinger og flyt fjernadgangsforbindelsen op over den fysiske adapter, og genopret derefter forbindelsen, så ændringen gælder i en ny session.

Bindingsrækkefølgen er kun den første halvdel. Klienten skal også vide, hvilke navne der hører til den adapter, og det er et suffiksspørgsmål, ikke et rækkefølgespørgsmål.

Læg outputtet fra ipconfig /all på den fungerende maskine ved siden af den bærbares, begge taget mens tunnelen er oppe. Den fungerende maskine viser et forbindelsesspecifikt DNS-suffiks på sin kontoradapter, og den bærbare viser måske intet på tunnelen. Den forskel forklarer en hel klasse af rapporter af typen serveren er lige der, og navnet fejler stadig, for uden et suffiks bliver kortnavnet aldrig færdiggjort til den zone, som kontorets resolver betjener.

Et kort navn har brug for et suffiks, før det har brug for en rute

At skrive et ukvalificeret værtsnavn beder resolveren gætte et domæne. Gættet kommer fra suffikslisten, der er knyttet til forbindelsen, og hvis listen er tom, går forespørgslen ud som en enkelt label, som ingen privat zone vil matche.

Kopiér den fungerende maskines suffiks ind i VPN-adapterens IPv4-egenskaber på DNS-fanen, og genopret derefter forbindelsen. På Linux er modstykket søgedomænet på tunnellinket, som systemd-resolved viser per link og ikke globalt.

Hold de to indstillinger adskilt i dine noter. Suffikset ændrer, hvad der spørges om; resolveradressen ændrer, hvem der spørges. At rette den ene, mens den anden er forkert, giver et resultat, der virker tilfældigt.

Spørg resolveren direkte, derefter navnet

En direkte forespørgsel til kontorets resolver skiller et navneproblem fra et vejproblem, fordi den helt omgår klientens resolvervalg.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

Den første kommando spørger en bestemt server om et fuldt kvalificeret navn. Svarer den, er resolveren og ruten dertil i orden, og fejlen ligger i valget eller suffikset. Løber tiden ud, er adressen forkert eller uopnåelig, og problemet er routing, ikke DNS. Den anden kommando viser, hvad der sker med kortnavnet, og den tredje udskriver resolverkonfigurationen per link på en systemd-vært.

Vær opmærksom på wildcard-svar, som nogle netværk returnerer for ukendte navne. Et plausibelt svar er ikke bevis for, at den tilsigtede server svarede, så sammenlign den returnerede adresse med den, den interne tjeneste faktisk bruger. Hører adressen til en parkeringsside eller en proxy, svarede resolveren, men svaret var aldrig dit. Den sondring sparer en time på at jage en tunnel, der fungerede hele tiden.

På Linux erstatter en VPN-klient, der omskriver /etc/resolv.conf, de lokale resolvere helt. vpnc blotlægger DNSUpdate no for at forhindre det, og systemd-resolved kan kun rute de listede domæner til tunnellinket. Begge tilgange holder offentlige navne på den lokale resolver og sender interne navne til kontoret.

Lækager er en regel, ikke et flueben

Navneopslag er en UDP-udveksling til port 53, så en tunnel, der bærer webtrafik men ikke UDP, lader forespørgslen blive på den fysiske vej. Bevis det ved at optage på det fysiske netkort, mens et offentligt navn slås op. En forespørgsel, der er synlig på den grænseflade i læsbar form, betyder, at tunnelen ikke bærer den.

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

Hvis forespørgslen vises på den grænseflade i læsbar form, bærer tunnelen den ikke. Reparationen er en regel, der kun tillader port 53 til den resolver, VPN'et skubbede, og dropper andre destinationer, plus en klientkonfiguration, der ikke stiltiende kasserer den skubbede option.

Den sidste del betyder mere, end den ser ud til. Start OpenVPN med route-nopull, og den skubbede DNS-option forsvinder sammen med ruterne, medmindre pull-filteret udvides til at beholde den. Og en klient, der ignorerer dhcp-option DNS, fortsætter med at bruge det, den havde før. Enhver ændring på serversiden kræver en ny session, fordi resolverlisten leveres, når tunnelen kommer op, og en gammel session bliver ved med at vise den gamle tilstand.

Notér, hvilken fejl du faktisk observerede, før du lukker sagen. Et manglende internt svar og en forespørgsel, der undslipper tunnelen, kræver forskellige reparationer, og en suffiksændring, der retter det første, kan stille forværre det andet. Den, der tager sagen næste gang, vil stole på etiketten, så gør etiketten præcis.