Bakit Tumitigil ang DNS Pagkatapos Kumonekta ang OpenVPN sa Windows

May sagot pa rin ang ping sa resolver ng opisina pagkatapos kumonekta ang "OpenVPN", at nabigo pa rin ang bawat paghahanap ng pangalan. Naabot ang address habang hindi ang port, isang kombinasyon na may saysay kapag alam mong kayang mag-filter ng DNS ang Windows ayon sa adapter. Kapag may block-outside-dns sa profile, ang filter na iyon ang unang suspetsa at ang talahanayan ng ruta ang maling lugar na tingnan. Hinihiwalay ng dalawang pagsubok sa ibaba ang mga layer sa ilang segundo.

Naabot na address, patay na port

Pinatutunayan ng matagumpay na ping na buhay ang host at may landas. Wala itong sinasabi tungkol sa pahintulot na maabot ang port 53, dahil gumagana ang filter na tinutukoy sa ibang layer at nakadepende sa adapter. Kaya ang parehong makina ay makakasagot sa ICMP at tatanggihan ang bawat query na ipinadala sa parehong address. Patakbuhin ang dalawang pagsubok sa parehong sesyon bago baguhin ang anumang configuration.

ping <resolver-ip>
nslookup <name> <resolver-ip>

Ang pares na iyon ang diagnosis. Nagpapatuloy ang ordinaryong trapiko patungo sa subnet habang namamatay ang resolusyon ng pangalan, at napagpapasyahan ng mga tao na sira ang server o hindi kailanman naipadala ang DNS. Mahal sundan ang dalawang paliwanag, at tumuturo ang ebidensya sa mas makitid na lugar. Kumpirmahin ang pares bago hawakan ang anumang setting.

Ang opsyon ay patakaran ng filtering platform

Inilalarawan ng reperensya ng OpenVPN ang block-outside-dns bilang paghihigpit ng Windows Filtering Platform na pumipigil sa mga aplikasyon na maabot ang DNS sa mga adapter sa labas ng tunnel. Sinasaklaw nito ang TCP at UDP port 53. Dahil nabubuhay ang filter sa WFP at hindi sa karaniwang listahan ng patakaran ng firewall, ang pagdaragdag ng patakaran ng pahintulot sa ibang lugar ay hindi laging nagbabago ng resulta. Kaya patuloy na nabigo ang karaniwang payo na payagan ang DNS.

Maaaring magmula ang setting sa inangkat na profile o sa server, at ang file na huling inedit mo ay "hindi patunay kung ano ang na-load ng kliyente". Basahin nang sabay ang epektibong configuration at ang log ng koneksyon. Partikular din ang opsyon sa Windows, at ang pagtrato dito bilang portable ay nagbubunga ng payong hindi naaangkop.

Hanapin ang component ng kliyente na nagmamay-ari ng paghihigpit sa halip na magdagdag ng mas maraming patakaran. Ang may-ari ang bagay na talagang makakatanggal nito.

Ang filter ay hindi resolver

Ang pagharang ng trapiko sa labas ng tunnel ay hindi naglalagay ng gumaganang resolver sa loob nito. Tinatanggal ng opsyon ang isang landas at iniiwan ang DNS configuration ng tunnel sa nag-set up ng profile. Ang profile na hindi kailanman nagpadala ng resolver ay wala nang kahit isa ngayon.

Daanan ang tatlong pagsusuri nang sunod-sunod. Una, aling resolver ang talagang ginagamit ng nabigong aplikasyon. Pangalawa, kung inilapat ng kliyente ang mga setting ng DNS ng VPN. Pangatlo, aling interface ang nagdadala ng trapiko sa resolver na iyon.

1. Resolver na ginagamit: ihambing ang Resolve-DnsName -Server <resolver-ip> <name> sa mga server ng DNS na inililista ng ipconfig /all.
2. DNS ng VPN na inilapat: suriin ang mga entry ng DNS ng tunnel adapter sa parehong output ng ipconfig /all.
3. Interface na ginamit: pinangalanan ng Find-NetRoute -RemoteIPAddress <resolver-ip> ang palabas na interface para sa destinasyong iyon.

Nagiging hindi maabot ang resolver sa LAN ayon sa disenyo sa ilalim ng patakarang ito, kahit gumagana ang ibang trapiko sa LAN. Iyon ang opsyon na ginagawa ang trabaho nito. Kung kailangan ng disenyo ang DNS sa VPN, ayusin ang pagpaparehistro ng resolver at ang landas ng tunnel; kung kailangan ang split DNS na may lokal na pagbubukod, kailangang ipahayag ng may-ari ng configuration ang mga pagbubukod na iyon sa paraang sinusuportahan.

Ano ang hindi sinasaklaw ng opsyon

Ang port 53 ay hindi ang buong resolusyon ng pangalan. Gumagamit ang DNS over HTTPS at DNS over TLS ng ibang transport, at may mga aplikasyong nagpapatakbo ng sariling lohika ng resolver anuman ang mga setting ng system. Kaya makakaresolba ng pangalan ang browser habang hindi kaya ng command line.

Ituring ang pagkakaibang iyon bilang diagnostic at hindi bilang kontradiksyon. Ihambing ang dalawa bago magpasyang sira ang resolver ng system.

Panatilihing makitid ang konklusyon kapag isinusulat ito. Nililimitahan ng opsyong ito ang isang transport sa isang platform, at ang natitirang bahagi ng landas ng resolusyon ay hiwalay na tanong sa disenyo na may sariling may-ari.

Suriin ang kalagayan bago at pagkatapos ng pagkadiskonekta

Patakbuhin ang parehong paghahanap habang konektado at muli pagkatapos magdiskonekta ang kliyenteng may-ari. Dapat mabigo ang una para sa panlabas na resolver habang nakataas ang tunnel, at dapat magtagumpay ang pangalawa kapag natanggal na ang filter. Kung nabibigo pa rin pagkatapos ng pagkadiskonekta, hindi nalinis ang filter.

ipconfig /displaydns
nslookup <name> <resolver-ip>

Ang pag-restart ng serbisyo ng kliyente o ng makina ay karaniwang naglilinis ng lumang filter. Pinatutunayan nito ang diagnosis nang hindi pinatutunayan ang permanenteng pag-aayos. Isulat ang nakita mo, dahil ang filter na nakakaligtas sa pagkadiskonekta ay gagawin itong muli, at ang tala ang nagbibigay-katwiran sa ulat ng bug.

Pagkatapos lamang ng mga pagsusuring iyon may saysay na palitan ang resolver o itayong muli ang patakaran ng firewall. Pareho silang mas malaking pagbabago kaysa sinusuportahan ng ebidensya.