Wêrom privee DNS-nammen mislearje op VPN-klanten en wêr't te kontrolearjen

Do iepest in laptop yn in hotelkeamer, startest de klant, typest de namme fan de ynterne bestânsferver en krigest neat werom. De tunnel meldt ferbûn, en in ping nei in adres yn itselde subnet antwurdet noch altyd, dus it ferfier sels is yn oarder. Allinnich de namme mislearret, en dat gat beheint it probleem ta twa plakken: hokker resolver de klant frege hat en oft it antwurd dat er krige werom troch de tunnel kin. Reparjearest it iene en slost it oare oer, en de flater ferpleatst him gewoan.

Foardat do in profyl bewurkest, befêstigje wat de klant mei de namme docht. Op Linux lit resolvectl query files.corp.example sjen hokker keppeling en hokker resolver it antwurd makken. Op Windows lit Resolve-DnsName files.corp.example de tsjinner sjen dy't antwurde en it adres dat er weromjoech.

Lês it antwurd foardat do wat feroarest

Komt de namme werom as NXDOMAIN yn in pear millisekonden, dan hat de fraach dyn sône nea berikt en hat in iepenbiere of hotelresolver antwurde. Komt er werom nei in lange skoft, dan is der wat ûnderweis UDP-poarte 53 oan it falle litten en is de klant úteinlik weromfallen. Antwurdet er mei it juste adres mar bliuwt de ferbining hingjen, dan is it sykjen yn oarder en is dyn probleem de rûteleas of de tsjinst sels.

Dy trijedieling besparret in oere fan rieden. It fertelt dy ek oft do de VPN oanreitsje moatst: in namme dy't oplost nei it juste privee adres hat it resolverpaad al bewiisd, dus it oerbleaune wurk leit op it datapaad.

Diel de resolver út fan binnen de tunnel

Klanten falle yn twa groepen. Oan de iene kin de tsjinner by it opsetten fan de ferbining in resolver jaan; de oare hâldt de ynstelling yn in lokaal bestân dat gjin gateway fan ôfstân feroarje kin.

OpenVPN sit yn de earste groep. Op de tsjinner reizgje push "dhcp-option DNS 10.8.0.53" en push "dhcp-option DOMAIN corp.example" del troch it kontrôlekanaal, mar allinnich as de klantkonfiguraasje pull noch oan hat. In mei de hân bewurke klant mei pull-filter ignore "dhcp-option" sil se nea sjen, en dy iene rigel ferklearret fernuverjend folle gefallen fan „de tsjinner triuwt it mar myn laptop is it net iens“.

WireGuard sit yn de twadde groep, om't it protokoll hielendal gjin opsje-ûnderhanneling hat. De resolver en it sykdomein geane yn it eigen [Interface]-blok fan de klant as DNS = 10.8.0.53, corp.example. wg-quick past dat ta fia resolvconf of systemd-resolved, en op Windows ynstallearret de offisjele klant NRPT-regels dy't allinnich bestean salang't de tunnel oerein is: Get-DnsClientNrptPolicy listet se op, wat it in flugge manier makket om te sjen oft de klant dyn bestân ea tapast hat.

IPsec/IKEv2 sit der tuskenyn. De attr-plugin fan strongSwan kin in DNS-tsjinner weromjaan dy't út in pool helle is, en in Windows-klant akseptearret dat normaal, mar in profyl dat syn eigen nammentsjinner fêstset wint fan alles wat de gateway biedt. Op in Linux-klant is de lykweardige hânmjittige stap resolvectl dns wg0 10.8.0.53 folge troch resolvectl domain wg0 '~corp.example'; beide ferdwine mei de ynterface, wat krekt is wat do wolst foar in ynstelling dy't oan 'e tunnel bûn is.

Behein it efterheaksel ynstee fan elke fraach troch te slikken

De hiele resolverlist fan de klant nei dyn ynterne tsjinner wize is maklik en meastentiids ferkeard. Dan wurdt elke iepenbiere namme oplost fan de útgong fan dyn datacenter, CDN's jouwe fiere adressen werom, en ien resolverstoring nimt it browsen fan de brûker mei.

Stjoer allinnich it privee efterheaksel nei binnen. By systemd-resolved is in domein dat mei ~ begjint allinnich foar rûteleas, dus ~corp.example betsjut dat fragen ûnder dat efterheaksel nei de tsjinners fan dy keppeling geane, wylst al it oare it fysike netwurk bliuwt brûken. Windows docht itselde mei NRPT-regels dy't ta in nammeromte beheind binne, en macOS mei in oanfoljend resolverbestân ûnder /etc/resolver/.

Multicast-nammen fertsjinje har eigen antwurd. .local-nammen binne neffens it ûntwerp link-local (RFC 6762) en in punt-nei-punt tun-ynterface draacht dy multicast-groep net, dus in ekstra iepenbiere resolver publisearret se net en in ynterne unicastresolver jout der NXDOMAIN op werom. In reflektor lykas avahi yn reflektor-modus kin twa segminten oerbringe, mar dat is in beslissing oan tsjinnerkant dy't gjin klant freegje kin. Moat in printer of in NAS by namme te berikken wêze, jou him dan in A-record yn dyn sône.

Bewiis dat it antwurd werom kin

In korrekt antwurd dat nei in ûnberikber adres wiist liket krekt op in resolverprobleem oant do de rûte kontrolearrest. Freegje de kernel wêr't it antwurd hinne soe: ip route get 10.20.5.20 neamt de ynterface en, nuttiger, it boarne-adres dat er brûke soe.

Hâld it resolveradres sels yn 'e gaten. In klant mei DNS = 10.8.0.53 njonken AllowedIPs = 10.20.0.0/16 stjoert syn fragen út troch de fysike NIC, dêr't se stil stjerre, om't de resolver net yn in prefiks leit dat de tunnel opeasket. Dy misbetingst is de meast foarkommende ien-oarsaak-flater yn dit hiele fjild, en hy is ûnsichtber of do moatst de DNS-ynstelling rigel foar rigel mei de tastiene prefiksen fergelykje.

Oerlaapjende berikken feroarsaakje de tsjinstelde flater. It antwurd is goed, de rûte bestiet, en hy wiist nei de ferkearde host, om't 192.168.0.0/24 thús spesifiker is as de rûte fan 'e tunnel nei itselde berik. Nûmerje ien kant opnij of triuw in smeller rûte troch, en befêstigje dan de firewall en de weromwei fan de tsjinsthost; de oantekeningen fan strongSwan oer trochstjoeren omfetsje de sysctl-kant fan dy wei.

Sertifikaten binne in aparte identiteitskontrôle dy't minsken op DNS skowe. Meldt de browser in nammferskil ynstee fan in oplossingsflater, dan hat it sykjen al wurke en is it SAN op it sertifikaat wat reparearre wurde moat. Test HTTPS tsjin de namme, nea tsjin it neakene IP.

Test opnij fan de klant, net fan de gateway

Test yn 'e applikaasje dêr't de brûker oer klaget, want in sykjen op 'e opdrachtline bewissiget net dat de browser deselde wei nimt. De feilige DNS fan Chrome en network.trr.mode fan Firefox kinne de systeemresolver hielendal omgean, en as se dat dogge, mislearret in privee namme of lekt er nei in iepenbiere resolver. resolvectl query fergelykje mei in mei de hân draaide dig @10.8.0.53 files.corp.example fertelt dy hokker fan de beide bard is.

Briek dan de ferbining en meitsje dy opnij foardat do it reparearre neamst. Ynstellingen dy't mei de hân op in ynterface set binne, ferdwine mei de ynterface, en in profyl dat allinnich mar goed like troch in fergetten lokale bewurking sil by de folgjende start mislearje.

In koarte checklist foar de folgjende masine: de namme wurdt oplost fia de resolver fan 'e tunnel, it efterheaksel is ôfbeakene ynstee fan globaal, it resolveradres leit binnen de tastiene prefiksen, de host út it antwurd antwurdet op 'e tsjinstpoarte, en it sertifikaat dekt de namme dy't de brûker typte.