Prečo privátne názvy DNS zlyhávajú na klientoch VPN a kde to skontrolovať

Otvoríte notebook v hotelovej izbe, spustíte klienta, napíšete názov interného súborového servera a nič nedostanete. Tunel hlási pripojené a ping na adresu v tej istej podsieti stále odpovedá, takže transport samotný je v poriadku. Zlyháva len názov, a tá medzera zužuje problém na dve miesta: na ktorý resolver sa klient pýtal a či sa odpoveď, ktorú dostal, môže vrátiť tunelom. Opravte jedno a druhé vynechajte, a porucha sa jednoducho posunie.

Skôr než začnete upravovať akýkoľvek profil, overte, čo klient s názvom robí. Na Linuxe resolvectl query files.corp.example ukáže, cez ktoré rozhranie a ktorý resolver odpoveď vznikla. Na Windows Resolve-DnsName files.corp.example ukáže server, ktorý odpovedal, a adresu, ktorú vrátil.

Prečítajte si odpoveď, kým čokoľvek zmeníte

Ak sa názov vráti ako NXDOMAIN v priebehu niekoľkých milisekúnd, dopyt sa k vašej zóne nikdy nedostal a odpovedal nejaký verejný alebo hotelový resolver. Ak sa vráti až po dlhej pauze, niečo cestou zahadzuje UDP port 53 a klient napokon siahol po zálohe. Ak odpovie správnou adresou, ale spojenie stále visí, preklad je v poriadku a váš problém je v routingu alebo v samotnej službe.

Toto rozdelenie na tri ušetrí hodinu hádania. Tiež vám povie, či sa do VPN vôbec púšťať: názov, ktorý sa preloží na správnu privátnu adresu, už dôkaz cesty resolvera podal, takže zostávajúca práca je na dátovej ceste.

Rozdejte resolver zvnútra tunela

Klienti sa delia do dvoch skupín. Jednej môže server resolver odovzdať pri nadväzovaní spojenia; druhá drží nastavenie v miestnom súbore, ktorý žiadna brána nedokáže zmeniť na diaľku.

OpenVPN patrí do prvej skupiny. Na serveri putujú push "dhcp-option DNS 10.8.0.53" a push "dhcp-option DOMAIN corp.example" riadiacim kanálom, ale len keď má konfigurácia klienta stále zapnuté pull. Ručne upravený klient s pull-filter ignore "dhcp-option" ich nikdy neuvidí, a ten jediný riadok vysvetľuje prekvapivo veľa prípadov typu „server to posiela, ale môj notebook nesúhlasí“.

WireGuard patrí do druhej skupiny, pretože protokol nemá vôbec žiadne vyjednávanie volieb. Resolver a vyhľadávacia doména idú do vlastného bloku [Interface] klienta ako DNS = 10.8.0.53, corp.example. wg-quick to aplikuje cez resolvconf alebo systemd-resolved a vo Windows oficiálny klient nainštaluje pravidlá NRPT, ktoré existujú len počas toho, ako je tunel hore: Get-DnsClientNrptPolicy ich vypíše, čo z neho robí rýchly spôsob, ako zistiť, či klient váš súbor vôbec aplikoval.

IPsec/IKEv2 stojí medzi nimi. Plugin attr od strongSwanu môže vrátiť DNS server vytiahnutý z poolu a windowsový klient ho zvyčajne prijme, ale profil, ktorý si presadzuje vlastný menný server, vyhrá nad čímkoľvek, čo brána ponúkne. Na linuxovom klientovi je ekvivalentným ručným krokom resolvectl dns wg0 10.8.0.53 nasledované resolvectl domain wg0 '~corp.example'; oboje zmizne spolu s rozhraním, čo je presne to, čo pri nastavení viazanom na tunel chcete.

Vymedzte sufix namiesto toho, aby ste prehltli každý dopyt

Nasmérovať celý zoznam resolverov klienta na váš interný server je jednoduché a väčšinou nesprávne. Každý verejný názov sa potom prekladá cez výstup vášho dátového centra, CDN vracajú vzdialené adresy a jeden výpadok resolvera so sebou vezme aj prehliadanie používateľa.

Posielajte dovnútra len privátny sufix. V systemd-resolved je doména začínajúca na ~ len pre routing, takže ~corp.example znamená, že dopyty pod týmto sufixom idú na servery toho rozhrania, zatiaľ čo všetko ostatné ďalej používa fyzickú sieť. Windows robí to isté pomocou pravidiel NRPT vymedzených na menný priestor a macOS pomocou doplnkového súboru resolvera v /etc/resolver/.

Multicastové názvy si zaslúžia vlastnú odpoveď. Názvy .local sú z podstaty link-local (RFC 6762) a tun rozhranie typu bod-bod tento multicastový kanál nenesie, takže pridanie verejného resolvera ich nezverejní a dopyt na interný unicastový resolver vráti NXDOMAIN. Reflector, akým je avahi v režime reflector, dokáže spojiť dva segmenty, ale to je rozhodnutie na strane servera, ktoré žiadny klient nemôže vyžiadať. Ak musí byť tlačiareň alebo NAS dostupné podľa názvu, dajte im radšej záznam A vo svojej zóne.

Dokážte, že sa odpoveď môže vrátiť

Správna odpoveď ukazujúca na nedosiahnuteľnú adresu vyzerá presne ako problém resolvera, kým si neskontrolujete trasu. Opýtajte sa jadra, kam by odpoveď šla: ip route get 10.20.5.20 pomenuje rozhranie a užitočnejšie zdrojovú adresu, ktorú by použilo.

Sledujte samotnú adresu resolvera. Klient s DNS = 10.8.0.53 vedľa AllowedIPs = 10.20.0.0/16 posiela svoje dopyty von fyzickou NIC, kde ticho umierajú, pretože resolver neleží v žiadnom prefixe, ktorý tunel nárokuje. Ten rozpor je najčastejšia jednopríčinná porucha v celej tejto oblasti a zostáva neviditeľný, kým neporovnáte nastavenie DNS s povolenými prefixmi riadok po riadku.

Prekrývajúce sa rozsahy spôsobujú opačnú poruchu. Odpoveď je správna, trasa existuje a ukazuje na nesprávneho hostiteľa, pretože 192.168.0.0/24 doma je konkrétnejšia než trasa tunela do rovnakého rozsahu. Prečíslujte jednu stranu alebo pretlačte užšiu trasu, potom overte firewall a spiatočnú cestu hostiteľa služby; poznámky strongSwanu o preposielaní pokrývajú stránku sysctl tejto cesty.

Certifikáty sú samostatná kontrola identity, ktorú ľudia zvaľujú na DNS. Ak prehliadač hlási nezhodu názvu namiesto chyby prekladu, vyhľadanie už fungovalo a opraviť treba SAN v certifikáte. Testujte HTTPS proti názvu, nikdy proti holej IP.

Otestujte to znova z klienta, nie z brány

Testujte v aplikácii, na ktorú sa používateľ sťažuje, pretože vyhľadanie z príkazového riadka nedokazuje, že prehliadač ide rovnakou cestou. Zabezpečené DNS Chromu a network.trr.mode vo Firefoxe môžu systémový resolver úplne obísť, a keď to urobia, privátny názov buď zlyhá, alebo unikne verejnému resolveru. Porovnanie resolvectl query s ručne spusteným dig @10.8.0.53 files.corp.example vám povie, ktorý z tých dvoch prípadov nastal.

Potom sa odpojte a pripojte znova, kým to vyhlásite za opravené. Nastavenia zadané ručne na rozhraní zmiznú spolu s rozhraním a profil, ktorý vyzeral správne len kvôli zabudnutej miestnej úprave, zlyhá pri ďalšom štarte.

Krátky kontrolný zoznam pre ďalší stroj: názov sa preloží cez resolver tunela, sufix je vymedzený, nie globálny, adresa resolvera leží vnútri povolených prefixov, hostiteľ z odpovede odpovedá na porte služby a certifikát pokrýva názov, ktorý používateľ napísal.