Kial DNS ĉesas funkcii post kiam OpenVPN konektiĝas en Windows

Ping al la oficeja solvilo ankoraŭ respondas post kiam "OpenVPN" konektiĝas, kaj tamen ĉiu nom-serĉo malsukcesas. La adreso estas atingebla dum la pordo ne estas, kombinaĵo kiu havas sencon kiam vi scias ke Windows povas filtri DNS laŭ adaptilo. Kun block-outside-dns en la profilo, tiu filtro estas la unua suspektato, kaj la enruta tabelo estas la malĝusta loko por serĉi. La du testoj sube apartigas la tavolojn en sekundoj.

Atingebla adreso, morta pordo

Sukcesa ping pruvas ke la gastiganto vivas kaj ke vojo ekzistas. Ĝi diras nenion pri permeso atingi pordon 53, ĉar la koncerna filtro laboras en alia tavolo kaj dependas de la adaptilo. Tial la sama maŝino povas respondi al ICMP kaj rifuzi ĉiun peton senditan al la sama adreso. Rulu ambaŭ testojn en la sama seanco antaŭ ol ŝanĝi ajnan agordon.

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

La paro estas la diagnozo. Ordinara trafiko al la subreto daŭre funkcias dum nom-solvado mortas, kaj homoj konkludas ke la servilo rompiĝis aŭ ke DNS neniam estis sendita. Ambaŭ klarigoj multekostas por postkuri, kaj la pruvoj montras al io pli mallarĝa. Konfirmu la paron antaŭ ol tuŝi agordon.

La opcio estas regulo de la filtra platformo

La OpenVPN-referenco priskribas block-outside-dns kiel limigon de Windows Filtering Platform kiu malhelpas aplikojn atingi DNS sur adaptiloj ekster la tunelo. Ĝi kovras TCP kaj UDP pordon 53. Ĉar la filtro vivas en WFP kaj ne en la ordinara listo de fajroŝirmilaj reguloj, aldoni permesan regulon aliloke ne nepre ŝanĝas la rezulton. Tial la ordinara konsilo permesi DNS daŭre malsukcesas.

La agordo povas veni el la importita profilo aŭ de la servilo, kaj la dosiero kiun vi laste redaktis "ne pruvas kion la kliento ŝargis". Legu la efikan agordon kaj la konektan protokolon kune. La opcio ankaŭ estas specifa al Windows, kaj trakti ĝin kiel portebla produktas konsilojn kiuj ne aplikiĝas.

Serĉu la klientan komponanton kiu posedas la limigon anstataŭ aldoni pliajn regulojn. La posedanto estas tio kio povas efektive forigi ĝin.

Filtro ne estas solvilo

Blokado de trafiko ekster la tunelo ne instalas funkciantan solvilon interne de ĝi. La opcio forigas vojon kaj lasas la DNS-agordon de la tunelo al tiu kiu starigis la profilon. Profilo kiu neniam sendis solvilon nun havas neniun.

Trairu tri kontrolojn laŭvice. Unue, kiun solvilon la malsukcesanta aplikaĵo efektive uzas. Due, ĉu la kliento aplikis la VPN-DNS-agordojn. Trie, kiu interfaco portas trafikon al tiu solvilo.

1. Solvilo en uzo: komparu Resolve-DnsName -Server <resolver-ip> <name> kun la DNS-serviloj listigitaj de ipconfig /all.
2. VPN-DNS aplikita: ekzamenu la DNS-rikordojn de la tunela adaptilo en la sama eligo de ipconfig /all.
3. Uzata interfaco: Find-NetRoute -RemoteIPAddress <resolver-ip> nomas la eliran interfacon por tiu celo.

LAN-solvilo fariĝas neatingebla laŭ la dezajno sub ĉi tiu politiko, eĉ dum alia LAN-trafiko funkcias. Tio estas la opcio faranta sian taskon. Se la dezajno bezonas VPN-DNS, riparu la solvilan registriĝon kaj la tunelan vojon; se split DNS kun lokaj esceptoj estas bezonata, la posedanto de la agordo devas esprimi tiujn esceptojn laŭsubtena maniero.

Kion la opcio ne kovras

Pordo 53 ne estas la tuta nom-solvado. DNS over HTTPS kaj DNS over TLS uzas malsamajn transportojn, kaj iuj aplikaĵoj rulas sian propran solvilan logikon sendepende de sistemaj agordoj. Retumilo do povas solvi nomojn dum la komanda linio ne povas.

Traktu tiun diferencon kiel diagnozon kaj ne kiel kontraŭdiron. Komparu la du antaŭ ol decidi ke la sistema solvilo rompiĝis.

Tenu la konkludon mallarĝa kiam vi skribas ĝin. Ĉi tiu opcio limigas unu transporton sur unu platformo, kaj la resto de la solva vojo estas aparta dezajna demando kun propra posedanto.

Kontrolu la staton antaŭ kaj post malkonekto

Rulu la saman serĉon dum la konekto kaj denove post kiam la posedanta kliento malkonektiĝas. La unua devus malsukcesi por ekstera solvilo dum la tunelo estas supre, kaj la dua devus sukcesi tuj kiam la filtro estas forigita. Se ĝi ankoraŭ malsukcesas post malkonekto, la filtro ne estis purigita.

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

Restartigi la klientan servon aŭ la maŝinon kutime purigas malnovan filtron. Tio konfirmas la diagnozon sen pruvi permanentan riparon. Notu kion vi vidis, ĉar filtro kiu postvivas malkonekton faros ĝin denove, kaj la noto estas tio kio pravigas cimraporton.

Nur post tiuj kontroloj sencas anstataŭigi la solvilon aŭ rekonstrui la fajroŝirmilan politikon. Ambaŭ estas pli grandaj ŝanĝoj ol la pruvoj subtenas.