Kāpēc Windows sistēmā pēc OpenVPN pievienošanās DNS pārstāj darboties

53. ports nekur neved, tomēr atrisinātājs joprojām atbild uz ping. Pārbaudiet, vai filtrē block-outside-dns, pēc tam nodrošiniet atrisinātāju, kuru tunelis sasniegs.

Ping uz biroja atrisinātāju joprojām saņem atbildi pēc tam, kad "OpenVPN" ir pievienojies, un tomēr katra nosaukuma meklēšana neizdodas. Adrese ir sasniedzama, bet ports nav, kombinācija, kurai ir jēga, kad zināt, ka Windows var filtrēt DNS pēc adaptera. Ja profilā ir block-outside-dns, šis filtrs ir pirmais aizdomās turamais, un maršrutēšanas tabula ir nepareizā vieta, kur meklēt. Divi testi zemāk atdala slāņus sekundēs.

Sasniedzama adrese, miris ports

Veiksmīgs ping pierāda, ka resursdators darbojas un ka ceļš pastāv. Tas neko neizsaka par atļauju sasniegt portu 53, jo attiecīgais filtrs strādā citā slānī un ir saistīts ar adapteri. Tāpēc viena un tā pati iekārta var atbildēt uz ICMP un noraidīt katru vaicājumu, kas nosūtīts uz to pašu adresi. Palaidiet abus testus vienā sesijā, pirms maināt jebkuru konfigurāciju.

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

Šis pāris ir diagnoze. Parastā plūsma uz apakštīklu turpinās, kamēr nosaukumu atrisināšana mirst, un cilvēki secina, ka serveris ir salūzis vai ka DNS nekad netika nosūtīts. Abu skaidrojumu izsekošana ir dārga, un pierādījumi norāda uz šaurāku vietu. Apstipriniet pāri, pirms aiztiekat jebkuru iestatījumu.

Šī opcija ir filtrēšanas platformas noteikums

OpenVPN uzziņa raksturo block-outside-dns kā Windows Filtering Platform ierobežojumu, kas neļauj lietotnēm sasniegt DNS adapteros ārpus tuneļa. Tas aptver TCP un UDP portu 53. Tā kā filtrs dzīvo WFP, nevis parastajā ugunsmūra noteikumu sarakstā, atļaujas noteikuma pievienošana citur ne vienmēr maina rezultātu. Tāpēc parastais padoms atļaut DNS joprojām neizdodas.

Iestatījums var nākt no importētā profila vai no servera, un fails, kuru pēdējo reizi rediģējāt, "nav pierādījums tam, ko ielādēja klients". Lasiet faktisko konfigurāciju un savienojuma žurnālu kopā. Opcija ir arī raksturīga tikai Windows, un tās uztveršana kā pārnēsājamas rada padomus, kas neattiecas.

Meklējiet to klienta komponentu, kuram pieder ierobežojums, nevis pievienojiet vairāk noteikumu. Īpašnieks ir tas, kas to patiešām var noņemt.

Filtrs nav atrisinātājs

Plūsmas bloķēšana ārpus tuneļa neinstalē tajā strādājošu atrisinātāju. Opcija noņem ceļu un atstāj tuneļa DNS konfigurāciju tam, kurš izveidoja profilu. Profilam, kas nekad nav nosūtījis atrisinātāju, tagad tā nav nemaz.

Veiciet trīs pārbaudes pēc kārtas. Pirmkārt, kuru atrisinātāju faktiski izmanto nespējīgā lietotne. Otrkārt, vai klients ir piemērojis VPN DNS iestatījumus. Treškārt, kura saskarne nes plūsmu uz šo atrisinātāju.

  1. Izmantotais atrisinātājs: salīdziniet Resolve-DnsName -Server <resolver-ip> <name> ar DNS serveriem, kurus uzskaita ipconfig /all.
  2. VPN DNS piemērots: apskatiet tuneļa adaptera DNS ierakstus tajā pašā ipconfig /all izvadē.
  3. Izmantotā saskarne: Find-NetRoute -RemoteIPAddress <resolver-ip> nosauc izejošo saskarni šim galamērķim.

LAN atrisinātājs šīs politikas ietvaros kļūst nesasniedzams pēc projekta, pat kamēr darbojas cita LAN plūsma. Tā ir opcija, kas dara savu darbu. Ja projektam vajag DNS caur VPN, izlabojiet atrisinātāja reģistrāciju un tuneļa ceļu; ja nepieciešams split DNS ar vietējiem izņēmumiem, konfigurācijas īpašniekam šie izņēmumi jāizsaka atbalstītā veidā.

Ko opcija neaptver

Ports 53 nav visa nosaukumu atrisināšana. DNS over HTTPS un DNS over TLS izmanto citu transportu, un dažas lietotnes darbina savu atrisinātāja loģiku neatkarīgi no sistēmas iestatījumiem. Tāpēc pārlūks var atrisināt nosaukumus, kamēr komandrinda nevar.

Uztveriet šo atšķirību kā diagnostiku, nevis pretrunu. Salīdziniet abus, pirms nolemjat, ka sistēmas atrisinātājs ir salūzis.

Rakstot turiet secinājumu šauru. Šī opcija ierobežo vienu transportu vienā platformā, un atlikusī atrisināšanas ceļa daļa ir atsevišķs projektēšanas jautājums ar savu īpašnieku.

Pārbaudiet stāvokli pirms atvienošanas un pēc tam

Palaidiet to pašu meklēšanu savienojuma laikā un vēlreiz pēc tam, kad īpašnieks klients atvienojas. Pirmajai vajadzētu neizdoties ārējam atrisinātājam, kamēr tunelis ir uzcelts, un otrajai vajadzētu izdoties, tiklīdz filtrs ir noņemts. Ja pēc atvienošanas tā joprojām neizdodas, filtrs nav notīrīts.

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

Klienta pakalpojuma vai iekārtas restartēšana parasti notīra novecojušu filtru. Tas apstiprina diagnozi, nepierādot pastāvīgu labojumu. Pierakstiet, ko redzējāt, jo filtrs, kas pārdzīvo atvienošanu, to izdarīs vēlreiz, un tieši pieraksts pamato kļūdas ziņojumu.

Tikai pēc šīm pārbaudēm ir jēga nomainīt atrisinātāju vai pārbūvēt ugunsmūra politiku. Abi ir lielākas izmaiņas, nekā pierādījumi atbalsta.

Saistītie raksti