Hvorfor private DNS-navne fejler på VPN-klienter, og hvor du skal kigge

Du åbner en bærbar computer på et hotelværelse, starter klienten, skriver navnet på den interne filserver og får intet tilbage. Tunnelen melder forbundet, og et ping til en adresse i samme subnetsvarer stadig, så transporten i sig selv er i orden. Kun navnet fejler, og det gab indsnævrer problemet til to steder: hvilken resolver klienten spurgte, og om det svar den fik, kan rejse tilbage gennem tunnelen. Ret det ene og spring det andet over, og fejlen flytter sig bare.

Før du redigerer nogen profil, så bekræft hvad klienten gør med navnet. På Linux viser resolvectl query files.corp.example hvilket link og hvilken resolver der kom med svaret. På Windows viser Resolve-DnsName files.corp.example hvilken server der svarede, og hvilken adresse den returnerede.

Læs svaret, før du ændrer noget

Kommer navnet tilbage som NXDOMAIN på få millisekunder, nåede forespørgslen aldrig din zone, og en offentlig eller hotelresolver svarede i stedet. Kommer det tilbage efter en lang pause, er der noget der dropper UDP-port 53 undervejs, og klienten faldt til sidst tilbage. Svarer den med den rigtige adresse, men forbindelsen hakker stadig, er opslaget fint, og problemet er routing eller tjenesten selv.

Den tredeling sparer en time med gætteri. Den fortæller dig også, om du overhovedet skal røre VPN'et: et navn, der slår op til den rigtige private adresse, har allerede bevist resolvervejen, så det resterende arbejde ligger på datavejen.

Del resolveren ud inde fra tunnelen

Klienter falder i to grupper. Den ene gruppe kan få en resolver af serveren under forbindelsesopsætningen; den anden holder indstillingen i en lokal fil, som ingen gateway kan ændre eksternt.

OpenVPN er i den første gruppe. På serveren rejser push "dhcp-option DNS 10.8.0.53" og push "dhcp-option DOMAIN corp.example" ned ad kontrolkanalen, men kun hvis klientkonfigurationen stadig har pull aktiveret. En håndredigeret klient med pull-filter ignore "dhcp-option" ser dem aldrig, og den ene linje forklarer overraskende mange tilfælde af »serveren pusher det, men min bærbare er uenig«.

WireGuard er i den anden gruppe, fordi protokollen slet ikke har nogen optionforhandling. Resolveren og søgedomænet går ind i klientens egen [Interface]-blok som DNS = 10.8.0.53, corp.example. wg-quick anvender det gennem resolvconf eller systemd-resolved, og på Windows installerer den officielle klient NRPT-regler, der kun findes, mens tunnelen er oppe – Get-DnsClientNrptPolicy viser dem, hvilket gør det til en hurtig måde at se, om klienten nogensinde anvendte din fil.

IPsec/IKEv2 ligger imellem. strongSwan's attr-plugin kan returnere en DNS-server fra en pulje, og en Windows-klient accepterer det normalt, men en profil, der fastlåser sin egen navneserver, vinder over hvad gatewayen end tilbyder. På en Linux-klient er det tilsvarende manuelle skridt resolvectl dns wg0 10.8.0.53 efterfulgt af resolvectl domain wg0 '~corp.example'; begge forsvinder, når interfacet gør, hvilket er præcis hvad du vil have til en tunnelafgrænset indstilling.

Afgræns suffikset i stedet for at sluge hver forespørgsel

At pege klientens hele resolverliste mod din interne server er nemt og som regel forkert. Så slår hvert offentligt navn op fra dit datacenters udgang, CDN'er leverer fjerne adresser tilbage, og et enkelt resolverudfald tager brugerens browsing med sig.

Send kun det private suffiks indad. På systemd-resolved er et domæne, der begynder med ~, kun routing, så ~corp.example betyder, at forespørgsler under det suffiks går til den links servere, mens alt andet fortsat bruger det fysiske netværk. Windows gør det samme med NRPT-regler afgrænset til et navnerum, og macOS med en supplerende resolverfil under /etc/resolver/.

Multicast-navne fortjener deres eget svar. .local-navne er link-local af design (RFC 6762), og en punkt-til-punkt tun-interface bærer ikke den multicast-gruppe, så en ekstra offentlig resolver offentliggør dem ikke, og spørger man en intern unicast-resolver, kommer der NXDOMAIN tilbage. En reflektor som avahi i reflektor-tilstand kan bygge bro mellem to segmenter, men det er en beslutning på serversiden, som ingen klient kan kræve. Skal en printer eller NAS kunne nås på navn, så giv den en A-record i din zone i stedet.

Bevis, at svaret kan rejse tilbage

Et korrekt svar, der peger på en uopnåelig adresse, ser præcis ud som et resolverproblem, indtil du tjekker ruten. Spørg kernen, hvor svaret ville gå hen: ip route get 10.20.5.20 navngiver interfacet og, mere nyttigt, den kildeadresse, den ville bruge.

Hold øje med resolveradressen selv. En klient med DNS = 10.8.0.53 ved siden af AllowedIPs = 10.20.0.0/16 sender sine forespørgsler ud gennem det fysiske NIC, hvor de dør stille, fordi resolveren ikke ligger inden for noget præfiks, som tunnelen gør krav på. Den uoverensstemmelse er den mest almindelige enkeltårsag i hele dette område, og den er usynlig, medmindre du sammenligner DNS-indstillingen med de tilladte præfikser linje for linje.

Overlappende områder giver den modsatte fejl. Svaret er rigtigt, ruten findes, og den peger på den forkerte host, fordi 192.168.0.0/24 derhjemme er mere specifik end tunnelens rute til samme område. Omnummerér den ene side eller push en smallere rute, og bekræft derefter tjenesteværtens firewall og returvej; strongSwan's noter om videresendelse dækker sysctl-siden af den vej.

Certifikater er en separat identitetskontrol, som folk skyder skylden på DNS for. Rapporterer browseren et navnemismatch i stedet for en opslagsfejl, virkede opslaget allerede, og det er SAN på certifikatet, der skal rettes. Test HTTPS mod navnet, aldrig mod den bare IP.

Test igen fra klienten, ikke fra gatewayen

Test inde i det program, brugeren klager over, for et opslag på kommandolinjen er ikke bevis for, at browseren tager samme vej. Chromes sikre DNS og Firefox' network.trr.mode kan omgå systemresolveren helt, og når de gør det, fejler et privat navn eller lækker til en offentlig resolver. At sammenligne resolvectl query med et håndkørt dig @10.8.0.53 files.corp.example fortæller dig, hvilket af de to der skete.

Afbryd og genopret derefter forbindelsen, før du kalder det løst. Indstillinger, der er sat i hånden på et interface, forsvinder med interfacet, og en profil, der kun så rigtig ud på grund af en efterladt lokal ændring, fejler ved næste opstart.

En kort tjekliste til den næste maskine: navnet slår op gennem tunnelens resolver, suffikset er afgrænset i stedet for globalt, resolveradressen ligger inden for de tilladte præfikser, værten fra svaret svarer på tjenesteporten, og certifikatet dækker det navn, brugeren skrev.