Miks privaatsed DNS-nimed VPN-klientides ebaõnnestuvad ja kust kontrollida

Avad hotellitoas sülearvuti, käivitad kliendi, trükid sisemise failiserveri nime ja ei saa midagi tagasi. Tunnel teatab, et on ühendatud, ja ping samas alamvõrgus olevale aadressile vastab endiselt, seega transport ise on korras. Ebaõnnestub ainult nimi, ja see lünk kitsendab probleemi kahte kohta: milliselt resolverilt klient küsis ja kas saadud vastus saab tunnelist tagasi tulla. Paranda üks ja jäta teine tegemata, ning viga lihtsalt liigub edasi.

Enne mis tahes profiili muutmist kontrolli, mida klient nimega teeb. Linuxis näitab resolvectl query files.corp.example, milline link ja milline resolver vastuse tekitasid. Windowsis näitab Resolve-DnsName files.corp.example serverit, mis vastas, ja aadressi, mille see tagastas.

Loe vastus enne, kui midagi muudad

Kui nimi tuleb NXDOMAINina tagasi mõne millisekundi jooksul, ei jõudnud päring kunagi sinu tsooni ja vastas hoopis mõni avalik või hotelli resolver. Kui see tuleb tagasi pika pausi järel, viskab miski teel UDP-porti 53 ära ja klient langes lõpuks varuvariandile. Kui see vastab õige aadressiga, aga ühendus ikka takerdub, on nimeotsing korras ja sinu probleem on marsruutimises või teenuses endas.

See kolmeks jagamine säästab tunni oletuste tegemist. See ütleb ka, kas VPN-i üldse puutuda: nimi, mis laheneb õigeks privaatseks aadressiks, on resolveri tee juba tõestanud, seega järelejäänud töö on andmeteel.

Jaga resolver tunnelist välja

Kliendid jagunevad kahte rühma. Ühele saab server ühenduse loomise ajal resolveri anda; teine hoiab seadet kohalikus failis, mida ükski lüüs ei saa kaugelt muuta.

OpenVPN kuulub esimesse rühma. Serveris liiguvad push "dhcp-option DNS 10.8.0.53" ja push "dhcp-option DOMAIN corp.example" juhtkanali kaudu, aga ainult siis, kui kliendi konfiguratsioonis on endiselt lubatud pull. Käsitsi muudetud klient, mis kannab pull-filter ignore "dhcp-option", ei näe neid kunagi, ja see üks rida selgitab hämmastavalt paljusid juhtumeid, kus server lükkab selle peale, aga minu sülearvuti on teisel arvamusel.

WireGuard kuulub teise rühma, sest protokollis pole üldse mingit valikute läbirääkimist. Resolver ja otsingudomeen lähevad kliendi enda [Interface] plokki kujul DNS = 10.8.0.53, corp.example. wg-quick rakendab seda resolvconfi või systemd-resolvedi kaudu, ja Windowsis paigaldab ametlik klient NRPT-reeglid, mis eksisteerivad ainult seni, kuni tunnel on üleval: Get-DnsClientNrptPolicy loetleb need, mis teeb sellest kiire viisi näha, kas klient rakendas sinu faili kunagi.

IPsec/IKEv2 on selle vahel. strongSwani attr-plugin võib tagastada poolist võetud DNS-serveri ja Windowsi klient võtab selle tavaliselt vastu, aga profiil, mis kinnitab oma nimeserveri, võidab kõige üle, mida lüüs pakub. Linuxi kliendil on samaväärne käsitsi samm resolvectl dns wg0 10.8.0.53, millele järgneb resolvectl domain wg0 '~corp.example'; mõlemad kaovad koos liidesega, mis on täpselt see, mida tunnelipõhise seade puhul tahad.

Piira sufiks, selle asemel et iga päring alla neelata

Kliendi kogu resolveriloendi suunamine sinu sisemisele serverile on lihtne ja tavaliselt vale. Siis laheneb iga avalik nimi sinu andmekeskuse väljundi kaudu, CDN-id tagastavad kaugeid aadresse ja üks resolveri katkestus viib kasutaja sirvimise endaga kaasa.

Saada sissepoole ainult privaatne sufiks. systemd-resolvedis on ~-ga algav domeen ainult marsruutimiseks, seega ~corp.example tähendab, et selle sufiksi all olevad päringud lähevad selle lingi serveritesse, samal ajal kui kõik muu kasutab edasi füüsilist võrku. Windows teeb sama nimeruumiga piiratud NRPT-reeglitega ja macOS täiendava resolverifailiga /etc/resolver/ all.

Multicast-nimed väärib oma vastust. .local-nimed on loomuldasa link-local (RFC 6762) ja punkt-punkt tun-liides ei kanna seda multicast-gruppi, seega avaliku resolveri lisamine ei avalda neid ja kui küsida nende kohta sisemiselt unicast-resolverilt, tuleb vastuseks NXDOMAIN. Reflektor nagu avahi reflektorirežiimis võib kaks segmenti ühendada, aga see on serveripoolne otsus, mida ükski klient nõuda ei saa. Kui printer või NAS peab olema nime kaudu kättesaadav, anna sellele selle asemel oma tsoonis A-kirje.

Tõesta, et vastus saab tagasi tulla

Õige vastus, mis osutab kättesaamatule aadressile, näeb täpselt välja nagu resolveri probleem, kuni kontrollid marsruuti. Küsi tuumalt, kuhu vastus läheks: ip route get 10.20.5.20 nimetab liidese ja, kasulikumalt, lähteaadressi, mida see kasutaks.

Jälgi resolveri aadressi ennast. Klient, kus DNS = 10.8.0.53 on AllowedIPs = 10.20.0.0/16 kõrval, saadab oma päringud füüsilise võrgukaardi kaudu välja, kus need vaikselt surevad, sest resolver ei asu üheski prefiksis, mida tunnel nõuab. See lahknevus on kõige tavalisem üksikpõhjus kogu selles valdkonnas ja jääb nähtamatuks, kui sa ei võrdle DNS-seadet lubatud prefiksitega rida-realt.

Kattuvad vahemikud põhjustavad vastupidise vea. Vastus on õige, marsruut on olemas ja see osutab valele hostile, sest kodus on 192.168.0.0/24 täpsem kui tunneli marsruut samasse vahemikku. Nummerda üks pool ümber või lükka läbi kitsam marsruut, seejärel kinnita teenuse hosti tulemüür ja tagasitee; strongSwani märkused edastamisest katavad selle tee sysctl-poole.

Sertifikaadid on eraldi identiteedikontroll, mille inimesed DNS-i kraesse ajavad. Kui brauser teatab nime lahknevusest, mitte lahendusveast, siis otsing juba toimis ja parandada tuleb sertifikaadi SAN. Testi HTTPS-i nime vastu, mitte kunagi palja IP vastu.

Testi uuesti kliendi, mitte lüüsi poolelt

Testi rakenduses, mille üle kasutaja kurdab, sest käsureaotsing ei tõesta, et brauser läheb sama teed. Chrome'i turvaline DNS ja Firefoxi network.trr.mode võivad süsteemi resolverist täiesti mööda minna ja kui nad seda teevad, siis privaatne nimi kas ebaõnnestub või lekib avalikku resolverisse. resolvectl query võrdlemine käsitsi käivitatud dig @10.8.0.53 files.corp.example-ga ütleb sulle, kumb neist kahest juhtus.

Seejärel katkesta ühendus ja loo see uuesti, enne kui nimetad selle parandatuks. Liidesele käsitsi pandud seaded kaovad koos liidesega ja profiil, mis nägi õige välja ainult allesjäänud kohaliku muudatuse tõttu, veab alt järgmisel käivitusel.

Lühike kontrollnimekiri järgmisele masinale: nimi laheneb tunneli resolveri kaudu, sufiks on piiratud, mitte globaalne, resolveri aadress asub lubatud prefiksite sees, vastuse host vastab teenuse pordil ja sertifikaat katab kasutaja trükitud nime.