Hvorfor private DNS-navn feiler på VPN-klienter, og hvor du bør sjekke

Du åpner en bærbar PC på et hotellrom, starter klienten, skriver navnet på den interne filserveren og får ingenting tilbake. Tunnelen melder tilkoblet, og en ping til en adresse i samme subnett svarer fortsatt, så selve transporten er i orden. Bare navnet feiler, og det gapet snevrer problemet inn til to steder: hvilken resolver klienten spurte, og om svaret den fikk kan reise tilbake gjennom tunnelen. Få det ene riktig og hopp over det andre, og feilen flytter seg bare.

Før du redigerer noen profil, bekreft hva klienten gjør med navnet. På Linux viser resolvectl query files.corp.example hvilken lenke og hvilken resolver som ga svaret. På Windows viser Resolve-DnsName files.corp.example hvilken server som svarte og hvilken adresse den returnerte.

Les svaret før du endrer noe

Kommer navnet tilbake som NXDOMAIN på noen millisekunder, nådde spørringen aldri sonen din, og en offentlig eller hotellresolver svarte i stedet. Kommer det tilbake etter en lang pause, er det noe som dropper UDP-port 53 på veien, og klienten falt til slutt tilbake. Svarer den med riktig adresse men tilkoblingen henger fortsatt, er oppslaget i orden, og problemet er rutingen eller tjenesten selv.

Den tredelingen sparer en time med gjetting. Den forteller deg også om du i det hele tatt skal røre VPN-et: et navn som slår opp til riktig privat adresse har allerede bevist resolverveien, så det gjenstående arbeidet ligger på dataveien.

Del ut resolveren inne fra tunnelen

Klienter faller i to grupper. Den ene gruppen kan få en resolver av serveren under oppsettet av tilkoblingen; den andre holder innstillingen i en lokal fil som ingen gateway kan endre eksternt.

OpenVPN er i den første gruppen. På serveren reiser push "dhcp-option DNS 10.8.0.53" og push "dhcp-option DOMAIN corp.example" nedover kontrollkanalen, men bare hvis klientkonfigurasjonen fortsatt har pull aktivert. En håndredigert klient med pull-filter ignore "dhcp-option" ser dem aldri, og den ene linjen forklarer overraskende mange tilfeller av «serveren pusher det, men den bærbare maskinen min er uenig».

WireGuard er i den andre gruppen, fordi protokollen ikke har noen opsjonsforhandling i det hele tatt. Resolveren og søkedomenet går inn i klientens eget [Interface]-blokk som DNS = 10.8.0.53, corp.example. wg-quick anvender det gjennom resolvconf eller systemd-resolved, og på Windows installerer den offisielle klienten NRPT-regler som bare finnes mens tunnelen er oppe: Get-DnsClientNrptPolicy lister dem opp, noe som gjør det til en rask måte å se om klienten noen gang anvendte filen din.

IPsec/IKEv2 ligger imellom. strongSwans attr-plugin kan returnere en DNS-server hentet fra en pool, og en Windows-klient aksepterer det vanligvis, men en profil som låser sin egen navneserver vinner over det gatewayen tilbyr. På en Linux-klient er det tilsvarende manuelle steget resolvectl dns wg0 10.8.0.53 etterfulgt av resolvectl domain wg0 '~corp.example'; begge forsvinner når grensesnittet gjør det, noe som er akkurat det du vil ha for en tunnelavgrenset innstilling.

Avgrens suffikset i stedet for å svelge hver spørring

Å peke hele resolverlisten til klienten mot den interne serveren din er enkelt og som regel feil. Da slås hvert offentlig navn opp fra utgangen til datasenteret ditt, CDN-er leverer fjerne adresser tilbake, og ett resolverutfall tar med seg nettsurfingen til brukeren.

Send bare det private suffikset innover. På systemd-resolved er et domene som begynner med ~ bare for ruting, så ~corp.example betyr at spørringer under det suffikset går til serverne til den lenken, mens alt annet fortsetter å bruke det fysiske nettet. Windows gjør det samme med NRPT-regler avgrenset til et navnerom, og macOS med en supplerende resolverfil under /etc/resolver/.

Multicast-navn fortjener sitt eget svar. .local-navn er link-local av konstruksjon (RFC 6762), og et punkt-til-punkt tun-grensesnitt bærer ikke den multicast-gruppen, så en ekstra offentlig resolver publiserer dem ikke, og spør du en intern unicast-resolver om dem, kommer NXDOMAIN tilbake. En reflektor som avahi i reflektor-modus kan bygge bro mellom to segmenter, men det er en beslutning på serversiden som ingen klient kan kreve. Må en skriver eller en NAS være tilgjengelig på navn, gi den i stedet en A-post i sonen din.

Bevis at svaret kan reise tilbake

Et riktig svar som peker på en utilgjengelig adresse ser nøyaktig ut som et resolverproblem til du sjekker ruten. Spør kjernen hvor svaret ville gå: ip route get 10.20.5.20 navngir grensesnittet og, mer nyttig, kildeadressen den ville bruke.

Følg med på resolveradressen selv. En klient med DNS = 10.8.0.53 ved siden av AllowedIPs = 10.20.0.0/16 sender spørringene sine ut gjennom det fysiske nettverkskortet, hvor de dør stille, fordi resolveren ikke ligger innenfor noe prefiks som tunnelen gjør krav på. Den uoverensstemmelsen er den vanligste enkeltårsaken i hele dette området, og den er usynlig med mindre du sammenligner DNS-innstillingen med de tillatte prefiksene linje for linje.

Overlappende områder gir den motsatte feilen. Svaret er riktig, ruten finnes, og den peker på feil vert, fordi 192.168.0.0/24 hjemme er mer spesifikk enn ruten til tunnelen til samme område. Nummerér om den ene siden eller dytt gjennom en smalere rute, og bekreft deretter brannmuren og returveien til tjenesteverten; strongSwans notater om videresending dekker sysctl-siden av den veien.

Sertifikater er en egen identitetskontroll som folk skylder på DNS. Rapporterer nettleseren et navneavvik i stedet for en oppslagsfeil, virket oppslaget allerede, og det er SAN i sertifikatet som må rettes. Test HTTPS mot navnet, aldri mot den nakne IP-adressen.

Test på nytt fra klienten, ikke fra gatewayen

Test inne i programmet brukeren klager på, for et oppslag på kommandolinjen beviser ikke at nettleseren tar samme vei. Chromes sikre DNS og Firefox network.trr.mode kan omgå systemresolveren helt, og når de gjør det, feiler et privat navn eller lekker til en offentlig resolver. Å sammenligne resolvectl query med en håndkjørt dig @10.8.0.53 files.corp.example forteller deg hvilket av de to som skjedde.

Koble deretter fra og til igjen før du kaller det løst. Innstillinger satt for hånd på et grensesnitt forsvinner med grensesnittet, og en profil som bare så riktig ut på grunn av en glemt lokal endring, vil feile ved neste oppstart.

En kort sjekkliste for neste maskin: navnet slås opp gjennom tunnelens resolver, suffikset er avgrenset i stedet for globalt, resolveradressen ligger innenfor de tillatte prefiksene, verten i svaret svarer på tjenesteporten, og sertifikatet dekker navnet brukeren skrev.