DNS na itinulak ng OpenVPN ay binabalewala: aling bahagi ang nag-aaplay nito

Ipinapakita ng log ang opsyon na itinulak ng server, aktibo ang lagusan, at nabibigo pa rin ang mga panloob na pangalan. Sumasagot ang direktang query sa resolver, kaya maayos ang server, ngunit patuloy na nagtatanong sa lokal na router ang bawat aplikasyon. Ang dumating sa kliyente ay isang alok, hindi pagbabago sa resolver, at ang bahaging may-ari ng resolution ng pangalan ay naiiba sa Linux, Windows at macOS. Kapag hinati mo ang opsyon mula sa may-ari nito, apat na depekto ang sumasaklaw sa halos lahat ng ulat: walang hook, dalawang hook na naglalaban, gumaganang split DNS ayon sa disenyo, o maikling pangalan na nangangailangan ng suffix at hindi server.

Ang itinulak na opsyon ay alok, hindi pag-install

Sa server, dalawang direktiba ang naglalarawan ng layunin, hindi epekto:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

Hindi tumatanggap ng naka-configure na resolver ang kliyente. Tumatanggap ito ng mga environment variable, foreign_option_1 at mga kasunod, isa sa bawat itinulak na linya, at may lokal na bagay na dapat bumasa sa mga ito at muling magsulat ng estado ng resolver ng operating system. Sa Linux walang gumagawa nito bilang default, kaya't ang tamang server at konektadong kliyente ay maaari pa ring mag-resolve ng pangalan sa pamamagitan ng LAN.

Sa pagitan ng dalawang dulo ay may tatlong yugto: dapat umabot ang push, dapat ilantad ito ng kliyente, at dapat ilapat ito ng hook. Basahin ang gitnang yugto sa log ng kliyente at ang huling yugto sa estado ng resolver, huwag kailanman baliktarin, dahil isang linya ng log lamang ang pinapatunayan ng unang dalawa.

Tiyakin na umabot ang push at hanapin ang may-ari

Simulan sa pagpangalan sa launcher: isang hubad na openvpn command, isang systemd instance, NetworkManager o kliyente ng vendor. Nagpapasya ito kung saan maaaring manirahan ang hook. Sa host na may systemd-resolved, resolvectl status ililista ang bawat link kasama ang mga DNS server at domain ng paghahanap na aktwal nitong ginagamit, at ang link ng lagusan ay hindi laging tinatawag na tun0.

Kung ang itinulak na address ay lumitaw sa log ngunit wala sa alinmang link, kulang ang integrasyon. Kung lumitaw ito sa link at ang mga query ay lumalabas pa rin sa ibang lugar, ang problema ay aling mga query ang pumipili ng link na iyon. Nagpapatakbo ang NetworkManager dns=dnsmasq sa file /etc/NetworkManager/NetworkManager.conf ng lokal na forwarder na sadyang nagpapatupad ng split DNS: ang mga pangalan sa loob ng VPN domain ay pumupunta sa VPN resolver, at ang lahat ng iba ay pinapanatili ang dating landas. Ang pag-uugaling ito ay mukhang depekto kapag inaasahan mong lilipat ang lahat ng trapiko; suriin ang mga setting bawat koneksyon gamit ang nmcli connection show "My VPN", kung saan ipv4.dns at ipv4.dns-search ang mga halaga sa likod ng iniuulat ng aparato, bago mo itong tawaging sira. Kung ang bawat query ay talagang dapat umabot sa VPN resolver, alisin ang dns=dnsmasq mula sa NetworkManager.conf at i-restart ang NetworkManager, na nagbabalik ng resolution sa mga setting ng koneksyon; kung hindi, panatilihin ang split DNS at itama ang itinulak na listahan ng domain.

Linux: ibigay ang mga opsyon sa resolver

Nagbibigay ang mga pakete ng distribusyon ng hook para dito, at dapat payagan ang kliyente na patakbuhin ito. Karaniwang kaayusan sa host na walang systemd-resolved:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Sa systemd-resolved, maaaring walang mababago ang lumang resolv.conf script na mahalaga, dahil hawak ng stub resolver ang estado bawat link. update-systemd-resolved idinodokumento ng helper ang isang anyo ng hook na gumagamit ng up-restart at down-pre, na mahalaga kapag ang interface ay tumagal nang higit sa isang pagtatangka ng koneksyon. Anuman ang piliin mo, isang bahagi lang ang dapat may-ari ng estado. Ang pagdagdag ng walang kaugnayang hook sa tabi ng NetworkManager ay nagbibigay ng dalawang manunulat sa parehong link, at ang resulta ay nakadepende sa pagkakasunod-sunod at hindi sa iyong configuration.

May kaso rin kung saan ganap na binabalewala ng NetworkManager ang itinulak na opsyon hanggang sa mailagay ang address ng server sa mga setting ng IPv4 ng koneksyon, pagkatapos ay ipinakita ng estado ng resolver na ginagamit ito. Sulit subukan bago isulat muli ang mga script, dahil inililipat nito ang problema mula sa shell hook patungo sa profile ng koneksyon na nagdadala na ng lagusan.

Windows at macOS ay nag-aaplay ng magkaibang bahagi

Itinatakda nga ng Windows client ang mga DNS server ng VPN adapter, ngunit pumipili pa rin ang Windows ng interface ayon sa metric at nangangailangan pa rin ng suffix upang palawakin ang maikling pangalan. Tiyakin ang estado ng adapter at hindi ang profile:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

Kung kulang ang address, itakda ito gamit ang Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, pagkatapos ay idagdag ang suffix sa mga katangian ng IPv4 ng adapter upang fileserver maging fileserver.corp.example. Isang SearchList halaga para sa buong makina sa ilalim ng Tcpip\Parameters ang gumagawa ng pareho. Kung saan nagre-resolve ang mahabang pangalan at hindi ang hubad, tama na ang resolver at ang listahan ng paghahanap ang may kasalanan. Ang mga pagwawasto, sa pagkakasunod-sunod: itulak ang DOMAIN upang matutunan ng kliyente ang suffix, idagdag ang suffix na iyon sa listahan ng paghahanap ng adapter o koneksyon, at bilang pansamantalang hakbang i-pin ang pangalan sa hosts, o sa LMHOSTS sa Windows; hindi tumatawid sa router ang NetBIOS browsing, kaya ang broadcast na nakakahanap ng maikling pangalan sa LAN ng opisina ay hindi kailanman umabot sa kliyente ng lagusan.

block-outside-dns Ang block-outside-dns ay pag-uugali ng Windows client, hindi portable na linya ng profile, at ang pagkopya nito sa Linux o macOS profile ay hindi ito nagre-reproduce doon. Kung gumagana ang mga pampublikong pangalan at nabibigo ang panloob sa Windows, ihambing ang pagkakasunod-sunod ng adapter sa Advanced settings sa ipconfig /all. Sa macOS, ang pagkakasunod-sunod ng resolver bawat serbisyo ay pag-aari ng system, kaya gamitin ang scutil --dns upang makita kung aling resolver ang tinatanong para sa aling domain, at ituring ang anumang isang ulat na pagwawasto ng profile bilang nakadepende sa kliyente at hindi pangkalahatan.

Ang virtual machine sa parehong laptop ay walang namamana rito. Bigyan ang bisita ng sariling entry ng resolver para sa panloob na domain, o hayaang ipasa ng NAT ng hypervisor ang mga query nito sa pamamagitan ng host, na tama lamang habang aktibo ang lagusan ng host.

Ang kasaysayan ang ikatlong dahilan. Ang mga DNS server o setting ng suffix mula sa dating profile ay maaaring mabuhay sa muling pagkonekta, kaya kapag mukhang tama ang adapter at nabibigo pa rin ang paghahanap, ihambing ang buhay na adapter sa Get-VpnConnection at burahin o i-overwrite ang lumang entry bago mo hawakan ang server.

Patunayan kung saan nagpunta ang query

Ang pag-huli habang isang paghahanap ay nagtatapos ng debate: tcpdump -ni eth0 port 53 nagpapakita ng mga query sa pisikal na interface, ibig sabihin lumalabas sila sa labas ng lagusan at hindi kailanman inilipat ang resolver. dig @10.8.0.1 name.corp.example pagkatapos ay hinahati ang dalawang natitirang kaso. Kung sumasagot ang direktang query, gumagana ang resolver at hindi ito ginagamit ng kliyente; kung nag-time out, hindi maabot ang resolver sa lagusan at walang lokal na pagbabago ang makakatulong.

Kung ang resolver na ginagamit pa rin ay ang ibinigay ng provider, ine-encrypt ng lagusan ang trapiko habang nakikita pa rin ng provider na iyon ang mga pangalan. Ito ay isyu ng pagtagas at hindi ng paggana, at ang parehong pag-huli ang sumasagot: ang query sa pisikal na interface ay patungo sa isang tao sa labas ng lagusan.

Kasama sa accessibility ang firewall sa VPN host, na dapat pahintulutan ang UDP at TCP 53 mula sa pool. Ang saradong port ay mukhang sirang push, at gayundin ang resolver na sumasagot lamang mula sa loob ng network ng lagusan. Ulitin ang pag-huli pagkatapos ng isang pagputol at muling pagkonekta, dahil ang mga setting na lumilitaw sa unang koneksyon at nawawala sa pangalawa ay depekto ng lifecycle sa hook, hindi nawawalang opsyon.

Panatilihin ang isang may-ari at i-verify ayon sa pagkakasunod-sunod

Ang script na nagsusulat muli ng DNS ng adapter batay sa hinihinalang estado ng lagusan ay nagdodoble sa configuration na dala na ng profile, at tahimik na nabibigo sa unang pagkakataon na mali ang hinala. Piliin ang sariling DNS settings ng koneksyon o isang dokumentadong hook, at itala kung alin ang pinili mo upang hindi magdagdag ng pangalawa ang susunod na tao.

Isara ang loop gamit ang apat na pagsusuri: ang itinulak na address ay naroroon sa link ng lagusan, ang panloob na pangalan ay nare-resolve bilang ganap na kwalipikadong pangalan, ang parehong pangalan ay nare-resolve nang walang suffix, at pareho pa ring totoo pagkatapos ng isang muling pagkonekta. Isang pag-huli ang magsasabi kung alin sa apat ang nabigo. Ang manwal ng OpenVPN 2.6 ay naglilista ng dhcp-option at ng mga direktiba ng script kasama ang kanilang mga tala sa platform.