Kvifor private DNS-namn feilar på VPN-klientar og kvar du bør sjekke

Du opnar ein berbar datamaskin på eit hotellrom, startar klienten, skriv namnet på den interne filserveren og får ingenting tilbake. Tunnelen melder tilkopla, og ein ping til ei adresse i same subnett svarar framleis, så sjølve transporten er i orden. Berre namnet feilar, og det gapet snevrar problemet inn til to stader: kva resolver klienten spurde, og om svaret han fekk kan reise tilbake gjennom tunnelen. Få det eine rett og hopp over det andre, og feilen flyttar seg berre.

Før du redigerer nokon profil, stadfest kva klienten gjer med namnet. På Linux viser resolvectl query files.corp.example kva lenkje og kva resolver som gav svaret. På Windows viser Resolve-DnsName files.corp.example kva tenar som svara og kva adresse han returnerte.

Les svaret før du endrar noko

Kjem namnet tilbake som NXDOMAIN på nokre millisekund, nådde førespurnaden aldri sona di, og ein offentleg eller hotellresolver svara i staden. Kjem det tilbake etter ein lang pause, er det noko som droppar UDP-port 53 på vegen, og klienten fall til slutt tilbake. Svarar han med rett adresse men sambandet heng framleis, er oppslaget i orden, og problemet er rutings eller tenesta sjølv.

Den tredelinga sparer ein time med gjetting. Ho fortel deg òg om du i det heile skal røre VPN-et: eit namn som blir løyst til rett privat adresse har allereie prova resolvervegen, så det gjenverande arbeidet ligg på datavvegen.

Del ut resolveren innanfrå tunnelen

Klientar fell i to grupper. Den eine gruppa kan få ein resolver av tenaren under oppsettet av sambandet; den andre held innstillinga i ei lokal fil som ingen gateway kan endre på avstand.

OpenVPN er i den første gruppa. På tenaren reiser push "dhcp-option DNS 10.8.0.53" og push "dhcp-option DOMAIN corp.example" ned gjennom kontrollkanalen, men berre om klientkonfigurasjonen framleis har pull slått på. Ein handredigert klient med pull-filter ignore "dhcp-option" ser dei aldri, og den eine linja forklarer overraskande mange tilfelle av »tenaren pushar det, men den berbare maskina mi er usamd«.

WireGuard er i den andre gruppa, fordi protokollen ikkje har noka valforhandling i det heile. Resolveren og søkjedomenet går inn i klienten sitt eige [Interface]-blokk som DNS = 10.8.0.53, corp.example. wg-quick brukar det gjennom resolvconf eller systemd-resolved, og på Windows installerer den offisielle klienten NRPT-reglar som berre finst medan tunnelen er oppe: Get-DnsClientNrptPolicy listar dei, noko som gjer det til ein snøgg måte å sjå om klienten nokosinne brukte fila di.

IPsec/IKEv2 ligg mellom. attr-programtillegget til strongSwan kan returnere ein DNS-tenar henta frå ein pool, og ein Windows-klient godtek det vanlegvis, men ein profil som låser sin eigen namnetenar vinn over det gatewayen byr på. På ein Linux-klient er det tilsvarande manuelle steget resolvectl dns wg0 10.8.0.53 følgd av resolvectl domain wg0 '~corp.example'; begge forsvinn når grensesnittet gjer det, som er akkurat det du vil ha for ei tunnellavgrensa innstilling.

Avgrens suffikset i staden for å svelgje kvar førespurnad

Å peike heile resolverlista til klienten mot den interne tenaren din er enkelt og som regel gale. Då blir kvart offentleg namn løyst frå utgangen til datasenteret ditt, CDN-ar returnerer fjerne adresser, og eitt resolverbrot tek med seg nettlesinga til brukaren.

Send berre det private suffikset innover. På systemd-resolved er eit domene som byrjar med ~ berre for rutting, så ~corp.example tyder at førespurnader under det suffikset går til tenarane til den lenkja, medan alt anna held fram med å bruke det fysiske nettet. Windows gjer det same med NRPT-reglar avgrensa til eit namnerom, og macOS med ei supplerande resolverfil under /etc/resolver/.

Multicast-namn fortener sitt eige svar. .local-namn er link-local av konstruksjon (RFC 6762), og eit punkt-til-punkt-tun-grensesnitt ber ikkje den multicast-gruppa, så ein ekstra offentleg resolver publiserer dei ikkje, og om ein spør ein intern unicast-resolver om dei, kjem NXDOMAIN tilbake. Ein reflektor som avahi i reflektor-modus kan bru mellom to segment, men det er eit val på tenarsida som ingen klient kan krevje. Må ein skrivar eller ein NAS vere tilgjengeleg på namn, gje han då ein A-post i sona di i staden.

Prov at svaret kan reise tilbake

Eit rett svar som peikar på ei utilgjengeleg adresse ser nøyaktig ut som eit resolverproblem til du sjekkar ruta. Spør kjernen kvar svaret ville gå: ip route get 10.20.5.20 namngjev grensesnittet og, meir nyttig, kjeldeadressa det ville bruke.

Fylg med på resolveradressa sjølv. Ein klient med DNS = 10.8.0.53 ved sida av AllowedIPs = 10.20.0.0/16 sender førespurnadene sine ut gjennom det fysiske nettkortet, der dei døyr stille, fordi resolveren ikkje ligg innanfor noko prefiks som tunnelen gjer krav på. Den skilnaden er den vanlegaste einskildårsaka i heile dette feltet, og han er usynleg med mindre du samanliknar DNS-innstillinga med dei tillatne prefiksa line for line.

Overlappande område gjev den motsette feilen. Svaret er rett, ruta finst, og ho peikar på feil vert, fordi 192.168.0.0/24 heime er meir spesifikk enn ruta til tunnelen til same området. Nummerér om den eine sida eller dytt gjennom ei trongare rute, og stadfest så brannmuren og returvegen til tenesteverten; notatane til strongSwan om vidaresending dekkjer sysctl-sida av den vegen.

Sertifikat er ein eigen identitetskontroll som folk skuldar på DNS. Meldar nettlesaren eit namneavvik i staden for ein oppslagsverkfeil, har oppslaget allereie funka, og det er SAN i sertifikatet som må rettast. Test HTTPS mot namnet, aldri mot den nakne IP-adressa.

Test på nytt frå klienten, ikkje frå gatewayen

Test inne i programmet brukaren klagar på, for eit oppslag på kommandolinja provar ikkje at nettlesaren tek same vegen. Det trygge DNS-et til Chrome og network.trr.mode i Firefox kan gå heilt utanom systemresolveren, og når dei gjer det, feilar eit privat namn eller lek til ein offentleg resolver. Å samanlikne resolvectl query med ein handkøyrd dig @10.8.0.53 files.corp.example fortel deg kva av dei to som hende.

Kopla så frå og kople til att før du kallar det løyst. Innstillingar sette for hand på eit grensesnitt forsvinn med grensesnittet, og ein profil som berre såg rett ut på grunn av ei gløymd lokal endring, vil feile ved neste oppstart.

Ei kort sjekkliste for den neste maskina: namnet blir løyst gjennom resolveren til tunnelen, suffikset er avgrensa i staden for globalt, resolveradressa ligg innanfor dei tillatne prefiksa, verten i svaret svarar på tenesteporten, og sertifikatet dekkjer namnet brukaren skreiv.