Waarom private DNS-name op VPN-kliënte misluk en waar om te kyk

Jy maak 'n skootrekenaar in 'n hotelkamer oop, begin die kliënt, tik die naam van die interne lêerserver in en kry niks terug nie. Die tonnel sê dit is gekoppel, en 'n ping na 'n adres in dieselfde subnet antwoord steeds, so die vervoer self is reg. Net die naam misluk, en daardie gaping vernou die probleem tot twee plekke: watter resolveerder die kliënt gevra het en of die antwoord wat hy gekry het deur die tonnel kan terugkeer. Kry die een reg en slaan die ander oor, en die fout skuif net.

Voordat jy enige profiel wysig, bevestig wat die kliënt met die naam doen. Op Linux wys resolvectl query files.corp.example watter skakel en watter resolveerder die antwoord gelewer het. Op Windows wys Resolve-DnsName files.corp.example die bediener wat geantwoord het en die adres wat hy teruggegee het.

Lees die antwoord voordat jy enigiets verander

As die naam binne 'n paar millisekondes as NXDOMAIN terugkom, het die navraag nooit jou sone bereik nie en het een of ander openbare of hotel-resolveerder eerder geantwoord. As dit ná 'n lang pouse terugkom, is iets op die pad besig om UDP-poort 53 te laat val en het die kliënt uiteindelik teruggeval. As dit met die regte adres antwoord maar die verbinding steek steeds, is die opsoek reg en is jou probleem die roetering of die diens self.

Daardie driedeling spaar 'n uur se raai. Dit sê ook vir jou of jy die VPN hoegenaamd moet aanraak: 'n naam wat na die regte private adres oplos, het die resolveerder-pad al bewys, dus die werk wat oorbly is op die datapad.

Deel die resolveerder vanuit die tonnel uit

Kliënte val in twee groepe. Aan die een kan die bediener tydens die opstel van die verbinding 'n resolveerder gee; die ander hou die instelling in 'n plaaslike lêer wat geen poort van veraf kan verander nie.

OpenVPN is in die eerste groep. Op die bediener reis push "dhcp-option DNS 10.8.0.53" en push "dhcp-option DOMAIN corp.example" deur die beheerkanaal af, maar net as die kliënt se konfigurasie pull nog geaktiveer het. 'n Handgewysigde kliënt met pull-filter ignore "dhcp-option" sal hulle nooit sien nie, en daardie enkele reël verduidelik verbasend baie gevalle van „die bediener stoot dit maar my skootrekenaar stem nie saam nie“.

WireGuard is in die tweede groep, want die protokol het glad geen opsie-onderhandeling nie. Die resolveerder en soekdomein gaan in die kliënt se eie [Interface]-blok as DNS = 10.8.0.53, corp.example. wg-quick pas dit deur resolvconf of systemd-resolved toe, en op Windows installeer die amptelike kliënt NRPT-reëls wat net bestaan terwyl die tonnel op is: Get-DnsClientNrptPolicy lys hulle, wat dit 'n vinnige manier maak om te sien of die kliënt jou lêer ooit toegepas het.

IPsec/IKEv2 sit in die middel. Die attr-inprop van strongSwan kan 'n DNS-bediener uit 'n poel teruggee, en 'n Windows-kliënt aanvaar dit gewoonlik, maar 'n profiel wat sy eie naamserver vaspen, wen teen alles wat die poort bied. Op 'n Linux-kliënt is die ekwivalente handstap resolvectl dns wg0 10.8.0.53 gevolg deur resolvectl domain wg0 '~corp.example'; albei verdwyn saam met die koppelvlak, wat presies is wat jy wil hê vir 'n instelling wat aan die tonnel gebind is.

Beperk die agtervoegsel in plaas daarvan om elke navraag in te sluk

Om die kliënt se hele resolveerder-lys na jou interne bediener te wys, is maklik en gewoonlik verkeerd. Dan los elke openbare naam via jou datacentrum se uitgang op, CDN's gee verafgeleë adresse terug, en een resolveerder-onderbreking neem die gebruiker se blaaiery saam.

Stuur net die private agtervoegsel inwaarts. Op systemd-resolved is 'n domein wat met ~ begin net vir roetering, so ~corp.example beteken dat navrae onder daardie agtervoegsel na die bedieners van daardie skakel gaan terwyl alles anders die fisiese netwerk bly gebruik. Windows doen dieselfde met NRPT-reëls wat tot 'n naamruimte afgebaken is, en macOS met 'n aanvullende resolveerder-lêer onder /etc/resolver/.

Multicast-name verdien hul eie antwoord. .local-name is volgens ontwerp link-local (RFC 6762) en 'n punt-tot-punt tun-koppelvlak dra nie daardie multicast-groep nie, so 'n bykomende openbare resolveerder sal hulle nie publiseer nie, en as jy 'n interne unicast-resolveerder daaroor vra, kom NXDOMAIN terug. 'n Reflektor soos avahi in reflektor-modus kan twee segmente oorbrug, maar dit is 'n besluit aan die bedienerkant wat geen kliënt kan vra nie. As 'n drukker of 'n NAS by naam bereikbaar moet wees, gee hom eerder 'n A-rekord in jou sone.

Bewys dat die antwoord kan terugkeer

'n Korrekte antwoord wat na 'n onbereikbare adres wys, lyk presies soos 'n resolveerder-probleem totdat jy die roete nagaan. Vra die kern waarheen die antwoord sou gaan: ip route get 10.20.5.20 noem die koppelvlak en, nuttiger, die bronadres wat dit sou gebruik.

Hou die resolveerder-adres self dop. 'n Kliënt met DNS = 10.8.0.53 langs AllowedIPs = 10.20.0.0/16 stuur sy navrae deur die fisiese NIC uit, waar hulle stil sterf, want die resolveerder lê nie binne enige voorvoegsel wat die tonnel opeis nie. Daardie wanverhouding is die mees algemene enkel-oorsaak-fout in hierdie hele gebied, en dit is onsigbaar tensy jy die DNS-instelling lyn vir lyn met die toegelate voorvoegsels vergelyk.

Oorvleuelende reekse veroorsaak die teenoorgestelde fout. Die antwoord is reg, die roete bestaan, en dit wys na die verkeerde gasheer, want 192.168.0.0/24 by die huis is meer spesifiek as die tonnel se roete na dieselfde reeks. Hermommer een kant of stoot 'n smaller roete deur, en bevestig dan die diensgasheer se vuurmuur en terugpad; strongSwan se notas oor deurstuur dek die sysctl-kant van daardie pad.

Sertifikate is 'n aparte identiteitskontrole wat mense op DNS skuif. As die blaaier 'n naamwanverhouding rapporteer in plaas van 'n oplossingsfout, het die opsoek al gewerk en is die SAN op die sertifikaat wat reggemaak moet word. Toets HTTPS teen die naam, nooit teen die kaal IP nie.

Toets weer van die kliënt af, nie van die poort nie

Toets in die toepassing waaroor die gebruiker kla, want 'n opsoek op die opdraglyn bewys nie dat die blaaier dieselfde pad volg nie. Chrome se veilige DNS en network.trr.mode van Firefox kan die stelsel-resolveerder heeltemal omseil, en wanneer hulle dit doen, misluk 'n private naam of lek dit na 'n openbare resolveerder. Om resolvectl query met 'n handgelope dig @10.8.0.53 files.corp.example te vergelyk, sê vir jou watter van die twee gebeur het.

Ontkoppel dan en koppel weer voordat jy dit reggestel noem. Instellings wat met die hand op 'n koppelvlak gesit is, verdwyn saam met die koppelvlak, en 'n profiel wat net reg gelyk het weens 'n vergeet plaaslike wysiging sal by die volgende opstart misluk.

'n Kort kontrolelys vir die volgende masjien: die naam los op deur die tonnel se resolveerder, die agtervoegsel is afgebaken eerder as globaal, die resolveerder-adres lê binne die toegelate voorvoegsels, die gasheer uit die antwoord antwoord op die dienspoort, en die sertifikaat dek die naam wat die gebruiker getik het.