Bakit nabibigo ang mga pribadong pangalan ng DNS sa mga kliyente ng VPN at saan dapat tingnan

Bubuksan mo ang laptop sa isang kuwarto ng hotel, patatakbuhin ang kliyente, itatype ang pangalan ng panloob na file server, at wala kang makuha. Sinasabi ng tunnel na nakakonekta ito, at sumasagot pa rin ang ping sa isang address sa parehong subnet, kaya maayos ang transport mismo. Ang pangalan lang ang nabibigo, at pinaliit ng puwang na iyon ang problema sa dalawang lugar: aling resolver ang tinanong ng kliyente at kung kayang bumalik ng sagot na nakuha nito sa tunnel. Ayusin ang isa at laktawan ang isa pa, at lumilipat lang ang sira.

Bago i-edit ang anumang profile, tiyakin kung ano ang ginagawa ng kliyente sa pangalan. Sa Linux, ipinapakita ng resolvectl query files.corp.example kung aling link at aling resolver ang gumawa ng sagot. Sa Windows, ipinapakita ng Resolve-DnsName files.corp.example ang server na sumagot at ang address na ibinalik nito.

Basahin ang sagot bago ka magbago ng anuman

Kung bumabalik ang pangalan bilang NXDOMAIN sa loob ng ilang millisecond, hindi nakarating ang query sa iyong zone at may pampublikong resolver o resolver ng hotel na sumagot. Kung bumabalik ito pagkatapos ng mahabang paghinto, may isang bagay na nagtatapon ng UDP port 53 sa daan at sa kalaunan ay nag-fallback ang kliyente. Kung sumasagot ito ng tamang address pero natigil pa rin ang koneksyon, maayos ang paghahanap at ang problema mo ay sa routing o sa serbisyo mismo.

Ang paghahati sa tatlo ay nakakatipid ng isang oras na hulaan. Sinasabi rin nito sa iyo kung dapat mo pang galawin ang VPN: ang pangalang nalulutas sa tamang pribadong address ay napatunayan na ang landas ng resolver, kaya ang natitirang trabaho ay nasa landas ng data.

Ipamahagi ang resolver mula sa loob ng tunnel

Dalawang grupo ang mga kliyente. Ang isang grupo ay maaaring bigyan ng resolver ng server habang inaayos ang koneksyon; ang isa pa ay nagtatago ng setting sa isang lokal na file na walang gateway na kayang baguhin mula sa malayo.

OpenVPN ay kabilang sa unang grupo. Sa server, dumadaan ang push "dhcp-option DNS 10.8.0.53" at push "dhcp-option DOMAIN corp.example" sa control channel, pero kung naka-enable pa ang pull sa configuration ng kliyente. Ang kliyenteng inedit sa kamay na may dalang pull-filter ignore "dhcp-option" ay hindi kailanman makikita ang mga iyon, at ang nag-iisang linyang iyon ay nagpapaliwanag ng kamangha-manghang dami ng mga kaso ng «itinitulak ito ng server pero hindi sumasang-ayon ang laptop ko».

Ang WireGuard ay kabilang sa ikalawang grupo, dahil wala itong anumang negosasyon ng opsyon sa protokol. Pumapasok ang resolver at ang search domain sa sariling bloke na [Interface] ng kliyente bilang DNS = 10.8.0.53, corp.example. Inilalapat ito ng wg-quick sa pamamagitan ng resolvconf o systemd-resolved, at sa Windows inilalagay ng opisyal na kliyente ang mga patakaran ng NRPT na umiiral lamang habang nakatayo ang tunnel: inililista ng Get-DnsClientNrptPolicy ang mga ito, kaya mabilis itong paraan para makita kung inilapat kailanman ng kliyente ang iyong file.

Nasa gitna ang IPsec/IKEv2. Kayang magbalik ng DNS server na hinango sa pool ang attr plugin ng strongSwan, at karaniwang tinatanggap ito ng kliyente sa Windows, pero ang profile na nagpipirmi ng sarili nitong name server ay nananalo sa kahit anong ialok ng gateway. Sa kliyente sa Linux, ang katumbas na manu-manong hakbang ay resolvectl dns wg0 10.8.0.53 at pagkatapos ay resolvectl domain wg0 '~corp.example'; nawawala ang dalawa kasama ng interface, na eksaktong gusto mo para sa setting na nakatali sa tunnel.

Bakuran ang suffix sa halip na lamunin ang bawat query

Ang pagturo ng buong listahan ng resolver ng kliyente sa iyong panloob na server ay madali at kadalasang mali. Nalulutas noon ang bawat pampublikong pangalan mula sa labasan ng iyong data center, nagbabalik ang mga CDN ng malalayong address, at ang isang outage ng resolver ay nadadamay ang pagba-browse ng gumagamit.

Ipadala lamang ang pribadong suffix papasok. Sa systemd-resolved, ang domain na nagsisimula sa ~ ay para sa routing lamang, kaya ang ~corp.example ay nangangahulugang ang mga query sa ilalim ng suffix na iyon ay pumupunta sa mga server ng link na iyon habang ang lahat ng iba ay patuloy na gumagamit ng pisikal na network. Ginagawa rin ito ng Windows gamit ang mga patakaran ng NRPT na nakabakod sa isang namespace, at ng macOS gamit ang karagdagang file ng resolver sa ilalim ng /etc/resolver/.

May karapatan sa sariling sagot ang mga pangalang multicast. Ang mga pangalang .local ay link-local ayon sa disenyo (RFC 6762) at hindi dinadala ng puntong-puntong tun interface ang grupong multicast na iyon, kaya hindi sila mailalathala ng karagdagang pampublikong resolver at ang pagtatanong tungkol sa kanila sa panloob na unicast resolver ay nagbabalik ng NXDOMAIN. Kayang magtulay ng isang reflector tulad ng avahi sa reflector mode sa dalawang segment, pero desisyon iyon sa panig ng server na walang kliyenteng makakahiling. Kung kailangang maabot sa pangalan ang isang printer o NAS, bigyan ito ng A record sa iyong zone.

Patunayan na kayang bumalik ang sagot

Ang tamang sagot na tumuturo sa address na hindi maabot ay mukhang eksaktong problema ng resolver hanggang tingnan mo ang ruta. Tanungin ang kernel kung saan pupunta ang sagot: pinapangalanan ng ip route get 10.20.5.20 ang interface at, mas kapaki-pakinabang, ang source address na gagamitin nito.

Bantayan ang address ng resolver mismo. Ang kliyenteng may DNS = 10.8.0.53 sa tabi ng AllowedIPs = 10.20.0.0/16 ay nagpapadala ng mga query nito sa pisikal na NIC, kung saan tahimik silang namamatay, dahil wala ang resolver sa loob ng anumang prefix na hinihingi ng tunnel. Ang pagkakaibang iyon ang pinakakaraniwang iisang dahilan ng sira sa buong larangang ito, at hindi ito nakikita maliban kung ihahambing mo ang setting ng DNS sa mga pinapayagang prefix linya bawat linya.

Ang magkakapatong na range ay nagdudulot ng kabaligtarang sira. Tama ang sagot, umiiral ang ruta, at tumuturo ito sa maling host, dahil ang 192.168.0.0/24 sa bahay ay mas espesipiko kaysa sa ruta ng tunnel sa parehong range. Bilangin muli ang isang panig o itulak ang mas makitid na ruta, pagkatapos tiyakin ang firewall at ang pabalik na landas ng service host; ang mga tala ng strongSwan tungkol sa pagpapasa ay sumasaklaw sa panig sysctl ng landas na iyon.

Ang mga certificate ay hiwalay na pagsusuri ng pagkakakilanlan na sinisisi ng mga tao sa DNS. Kung ang browser ay nag-uulat ng hindi pagtutugma ng pangalan sa halip na error sa paglutas, gumana na ang paghahanap at ang SAN sa certificate ang kailangang ayusin. Subukan ang HTTPS sa pangalan, hindi kailanman sa hubad na IP.

Subukang muli mula sa kliyente, hindi mula sa gateway

Subukan sa loob ng application na inirereklamo ng gumagamit, dahil ang paghahanap sa command line ay hindi patunay na tinatahak ng browser ang parehong landas. Kayang laktawan nang tuluyan ng secure DNS ng Chrome at ng network.trr.mode ng Firefox ang system resolver, at kapag ginawa nila iyon, ang pribadong pangalan ay nabibigo o tumatagas sa pampublikong resolver. Ang paghahambing ng resolvectl query sa isang manu-manong pinatakbong dig @10.8.0.53 files.corp.example ay nagsasabi sa iyo kung alin sa dalawa ang nangyari.

Pagkatapos, idiskonekta at ikonekta muli bago mo sabihing ayos na. Ang mga setting na inilagay sa kamay sa isang interface ay nawawala kasama ng interface, at ang profile na mukhang tama lang dahil sa nakalimutang lokal na pagbabago ay mabibigo sa susunod na boot.

Maikling checklist para sa susunod na makina: nalulutas ang pangalan sa resolver ng tunnel, may hangganan ang suffix sa halip na global, nasa loob ng mga pinapayagang prefix ang address ng resolver, sumasagot ang host mula sa sagot sa port ng serbisyo, at saklaw ng certificate ang pangalang itinype ng gumagamit.