Miért vallanak kudarcot a privát DNS-nevek a VPN-klienseken, és hol érdemes ellenőrizni

Kinyitsz egy laptopot egy hotelszobában, elindítod a klienst, beírod a belső fájlszerver nevét, és semmit sem kapsz. Az alagút kapcsolódott állapotot jelez, és a ping a saját alhálózaton belüli címre még mindig válaszol, tehát maga az átvitel rendben van. Csak a név hiányzik, és ez a rés a problémát két helyre szűkíti: melyik resolverhez fordult a kliens, és hogy a kapott válasz vissza tud-e jutni az alagúton. Az egyiket javítod, a másikat kihagyod, és a hiba egyszerűen tovább csúszik.

Mielőtt bármelyik profilt szerkesztenéd, ellenőrizd, mit tesz a kliens a névvel. Linuxon a resolvectl query files.corp.example megmutatja, melyik kapcsolat és melyik resolver állította elő a választ. Windowson a Resolve-DnsName files.corp.example mutatja a válaszoló szervert és a visszaadott címet.

Olvasd el a választ, mielőtt bármit módosítanál

Ha a név néhány ezredmásodperc alatt NXDOMAIN-ként tér vissza, a lekérdezés soha nem érte el a zónádat, és valamelyik nyilvános vagy szállodai resolver válaszolt helyette. Ha hosszú szünet után tér vissza, valami útközben eldobálja az UDP 53-as portot, és a kliens végül visszaesett. Ha a helyes címmel válaszol, de a kapcsolat továbbra is akadozik, a feloldás rendben van, és a probléma az útválasztás vagy maga a szolgáltatás.

Ez a hármas felosztás egy órányi találgatást takarít meg. Azt is megmondja, hogy egyáltalán hozzá kell-e nyúlnod a VPN-hez: egy név, amely a helyes privát címre oldódik fel, már bizonyította a resolver útvonalát, tehát a maradék munka az adatútvonalon van.

Oszd ki a resolvert az alagút belsejéből

A kliensek két csoportba esnek. Az egyiknek a szerver adhat resolvert a kapcsolat felépítése során; a másik helyi fájlban tartja a beállítást, amelyet semmilyen átjáró nem tud távolról megváltoztatni.

OpenVPN az első csoportba tartozik. A szerveren a push "dhcp-option DNS 10.8.0.53" és a push "dhcp-option DOMAIN corp.example" a vezérlőcsatornán utazik, de csak akkor, ha a kliens konfigurációjában a pull még engedélyezve van. Egy kézzel szerkesztett kliens, amely pull-filter ignore "dhcp-option"-t tartalmaz, soha nem látja őket, és ez az egyetlen sor meglepően sok olyan esetet megmagyaráz, amikor „a szerver tolná, de a laptopom nem ért egyet”.

A WireGuard a második csoportba tartozik, mert a protokollban egyáltalán nincs opcióegyeztetés. A resolver és a keresési tartomány a kliens saját [Interface] blokkjába kerül, DNS = 10.8.0.53, corp.example formájában. A wg-quick ezt a resolvconf vagy a systemd-resolved felé alkalmazza, Windowson pedig a hivatalos kliens olyan NRPT-szabályokat telepít, amelyek csak addig léteznek, amíg az alagút áll: a Get-DnsClientNrptPolicy kilistázza őket, ami gyors módja annak, hogy lásd, a kliens valaha alkalmazta-e a fájlodat.

Az IPsec/IKEv2 középen áll. A strongSwan attr bővítménye visszaadhat egy poolból húzott DNS-szervert, és egy Windows-kliens ezt általában elfogadja, de az a profil, amely a saját névszerverét rögzíti, felülírja, amit az átjáró kínál. Linuxos kliensen a megfelelő kézi lépés a resolvectl dns wg0 10.8.0.53, majd a resolvectl domain wg0 '~corp.example'; mindkettő eltűnik az interfésszel együtt, ami pontosan az, amit egy alagúthoz kötött beállításnál szeretnél.

Határold körül a szuffixumot, ahelyett hogy minden lekérdezést lenyelnél

A kliens teljes resolverlistáját a belső szerveredre irányítani egyszerű és többnyire hibás. Ilyenkor minden nyilvános név az adatközpontod kimenetén oldódik fel, a CDN-ek távoli címeket adnak vissza, és egyetlen resolverkiesés viszi magával a felhasználó böngészését.

Csak a privát szuffixumot küldd befelé. A systemd-resolvedben a ~ jellel kezdődő tartomány csak útválasztási célú, tehát a ~corp.example azt jelenti, hogy az adott szuffixum alatti lekérdezések annak a kapcsolatnak a szervereihez mennek, miközben minden más továbbra is a fizikai hálózatot használja. A Windows ugyanezt névtérre szűkített NRPT-szabályokkal végzi, a macOS pedig egy kiegészítő resolverfájllal a /etc/resolver/ alatt.

A multicast nevek saját választ érdemelnek. A .local nevek tervezésüknél fogva link-local címek (RFC 6762), és egy pont-pont tun interfész nem viszi át azt a multicast csoportot, tehát egy nyilvános resolver hozzáadása nem teszi őket közzé, és ha egy belső unicast resolverhez fordulsz velük, NXDOMAIN jön vissza. Egy reflektor, például az avahi reflektor módban, képes két szegmenst összekötni, de ez szerveroldali döntés, amelyet egyetlen kliens sem kérhet. Ha egy nyomtatónak vagy NAS-nak névvel elérhetőnek kell lennie, adj neki inkább egy A rekordot a zónádban.

Bizonyítsd, hogy a válasz vissza tud jutni

Egy helyes válasz, amely elérhetetlen címre mutat, pontosan úgy néz ki, mint egy resolverprobléma, amíg meg nem nézed az útvonalat. Kérdezd meg a kernelt, hova menne a válasz: a ip route get 10.20.5.20 megnevezi az interfészt és, ami hasznosabb, azt a forráscímet, amelyet használna.

Figyeld magát a resolver címét. Egy kliens, amelynél DNS = 10.8.0.53 mellett AllowedIPs = 10.20.0.0/16 szerepel, a lekérdezéseit a fizikai hálókártyán küldi ki, ahol csendben elhalnak, mert a resolver nem esik olyan előtagba, amelyet az alagút igényel. Ez az eltérés a leggyakoribb egyetlen ok ezen a területen, és láthatatlan marad, hacsak nem hasonlítod össze a DNS-beállítást az engedélyezett előtagokkal sorról sorra.

Az átfedő tartományok az ellenkező hibát okozzák. A válasz helyes, az útvonal létezik, és mégis a rossz gazdagépre mutat, mert a 192.168.0.0/24 otthon specifikusabb, mint az alagút útvonala ugyanahhoz a tartományhoz. Számozd újra az egyik oldalt, vagy tolj ki egy szűkebb útvonalat, majd ellenőrizd a szolgáltatásgazdagép tűzfalát és visszaútját; a strongSwan jegyzetei a továbbításról kiterjednek ennek az útnak a sysctl oldalára.

A tanúsítványok külön identitásellenőrzés, amelyet az emberek a DNS-re fognak. Ha a böngésző névbeli eltérést jelez feloldási hiba helyett, a keresés már működött, és a tanúsítvány SAN mezőjét kell rendbe tenni. HTTPS-t a név ellen tesztelj, soha a csupasz IP ellen.

Tesztelj újra a kliensről, ne az átjáróról

Azon alkalmazáson belül tesztelj, amelyre a felhasználó panaszkodik, mert egy parancssori keresés nem bizonyítja, hogy a böngésző ugyanazt az utat járja. A Chrome biztonságos DNS-e és a Firefox network.trr.mode beállítása teljesen megkerülheti a rendszer resolvert, és amikor ezt teszi, a privát név vagy meghiúsul, vagy kiszivárog egy nyilvános resolverhez. A resolvectl query összevetése egy kézzel futtatott dig @10.8.0.53 files.corp.example paranccsal megmondja, melyik történt a kettő közül.

Utána bontsd a kapcsolatot, és csatlakozz újra, mielőtt megjavítottnak nyilvánítod. Az interfészre kézzel tett beállítások az interfésszel együtt eltűnnek, és az a profil, amely csak egy ottfelejtett helyi módosítás miatt tűnt helyesnek, a következő indításkor el fog hasalni.

Rövid ellenőrzőlista a következő géphez: a név az alagút resolverén keresztül oldódik fel, a szuffixum körülhatárolt, nem globális, a resolver címe az engedélyezett előtagokon belül van, a válaszban szereplő gazdagép a szolgáltatás portján válaszol, és a tanúsítvány lefedi a felhasználó által beírt nevet.