Interna namn misslyckas över VPN medan publika sajter löses ut

En användare rapporterar att intranätets värdnamn inte löses över VPN. En andra rapport, från samma laptop, säger att ett läckagetest fortfarande visar frågor som besvaras av den lokala resolvern. De låter som ett problem men är två, med olika bevis, och den vanliga åtgärden för det första gör det andra värre. Separera dem innan du rör någon inställning.

Två symtom som inte är ett fel

Att ett internt namn inte löses betyder att frågan gick någonstans där det inte finns något svar. Att frågor lämnar tunneln betyder att frågan gick till fel plats även när svaret fanns. Det är motsatta fel: det ena är ett saknat svar, det andra en extra destination.

Fällan är att om du lägger till kontorets resolver överallt lagar du det första och garanterar det andra. Att lägga till en publik resolver överallt gör det motsatta.

Skriv ner båda observationerna med tidsstämpel och arbeta sedan igenom de fyra kontrollerna nedan i ordning.

Vilken adapters resolver får frågan

I Windows väljer DNS-klienten servrar enligt adaptrarnas bindningsordning, och tunneladaptern är inte automatiskt först. Öppna adapterns avancerade inställningar och flytta fjärråtkomstanslutningen ovanför den fysiska adaptern, och återanslut sedan så att ändringen gäller en ny session.

Bindningsordningen är bara första halvan. Klienten måste också veta vilka namn som hör till den adaptern, och det är en suffixfråga snarare än en ordningsfråga.

Lägg ipconfig /all från den fungerande datorn bredvid laptopens, båda tagna medan tunneln är uppe. Den fungerande datorn visar ett anslutningsspecifikt DNS-suffix på sin kontorsadapter, och laptopen kanske inte visar något på tunneln. Den skillnaden förklarar en hel klass av rapporter om att servern är där och namnet ändå inte fungerar, eftersom kortnamnet utan suffix aldrig kompletteras till den zon som kontorets resolver betjänar.

Ett kortnamn behöver ett suffix innan det behöver en väg

Att skriva ett okvalificerat värdnamn ber resolvern gissa en domän. Gissningen kommer från suffixlistan som hör till anslutningen, och om listan är tom går frågan ut som en enda etikett som ingen privat zon matchar.

Kopiera den fungerande datorns suffix till VPN-adapterns IPv4-egenskaper på fliken DNS och återanslut sedan. På Linux är motsvarigheten sökdomänen på tunnellänken, som systemd-resolved exponerar per länk i stället för globalt.

Håll de två inställningarna åtskilda i dina anteckningar. Ett suffix ändrar vad som frågas; resolveradressen ändrar vem som frågas. Att laga den ena medan den andra är fel ger ett resultat som verkar slumpmässigt.

Fråga resolvern direkt och sedan namnet

En direkt fråga till kontorets resolver skiljer ett namnproblem från ett vägproblem, eftersom den helt kringgår klientens resolverval.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

Det första kommandot frågar en specifik server om ett fullständigt kvalificerat namn. Om den svarar är resolvern och vägen dit okej och felet ligger i valet eller suffixet. Om den timar ut är adressen fel eller onåbar och problemet är routning, inte DNS. Det andra kommandot visar vad som händer med kortnamnet, och det tredje skriver ut resolverkonfigurationen per länk på en systemd-värd.

Se upp för jokerteckenssvar, som vissa nätverk returnerar för okända namn. Ett svar som verkar rimligt är inte bevis på att den avsedda servern svarade, så jämför den returnerade adressen med den som den interna tjänsten faktiskt använder. Om adressen tillhör en parkeringssida eller en proxy svarade resolvern, men svaret var aldrig ditt. Den distinktionen sparar en timme av jakt på en tunnel som fungerade hela tiden.

På Linux ersätter en VPN-klient som skriver om /etc/resolv.conf de lokala resolvrarna helt. vpnc exponerar DNSUpdate no för att stoppa det, och systemd-resolved kan dirigera bara de listade domänerna till tunnellänken. Båda metoderna behåller publika namn hos den lokala resolvern medan interna namn skickas till kontoret.

Läckor är en regel, inte en kryssruta

Namnuppslagning är ett UDP-utbyte till port 53, så en tunnel som bär webbtrafik men inte UDP lämnar frågan på den fysiska vägen. Bevisa det genom att fånga på det fysiska nätverkskortet medan ett publikt namn löses. En fråga som syns på det gränssnittet i läsbar form betyder att tunneln inte bär den.

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

Om frågan dyker upp på det gränssnittet i läsbar form bär tunneln den inte. Åtgärden är en regel som tillåter port 53 bara till den resolver som VPN:en pushade och släpper andra destinationer, plus en klientkonfiguration som inte tyst kastar det pushade alternativet.

Den sista delen spelar större roll än den ser ut att göra. Starta OpenVPN med route-nopull och det pushade DNS-alternativet försvinner tillsammans med rutterna, om inte pull-filtret vidgas för att behålla det. och en klient som ignorerar dhcp-option DNS fortsätter att använda det den hade tidigare. Varje ändring på serversidan kräver en ny session för att träda i kraft, eftersom resolverlistan levereras när tunneln kommer upp och en gammal session fortsätter visa det gamla läget.

Anteckna vilket fel du faktiskt observerade innan du stänger ärendet. Ett saknat internt svar och en fråga som rymmer ur tunneln kräver olika åtgärder, och en suffixändring som lagar det första kan tyst förvärra det andra. Den som tar över ärendet härnäst litar på etiketten, så gör etiketten korrekt.