Pse DNS ndalon së punuari pasi OpenVPN lidhet në Windows

Porta 53 nuk çon askund, ndërsa zgjidhësi vazhdon të përgjigjet në ping. Kontrolloni nëse block-outside-dns filtron, pastaj siguroni një zgjidhës që tuneli mund ta arrijë.

Ping-u drejt zgjidhësit të zyrës vazhdon të marrë përgjigje pasi "OpenVPN" lidhet, dhe megjithatë çdo kërkim emri dështon. Adresa është e arritshme ndërsa porta nuk është, një kombinim që ka kuptim kur e dini se Windows mund të filtrojë DNS sipas përshtatësit. Me block-outside-dns në profil, ai filtër është i dyshuari i parë dhe tabela e rrugëzimit është vendi i gabuar për të kërkuar. Dy testet më poshtë i ndajnë shtresat në sekonda.

Adresë e arritshme, portë e vdekur

Një ping i suksesshëm provon se hosti është aktiv dhe se ekziston një rrugë. Nuk thotë asgjë për lejen për të arritur portën 53, sepse filtri në fjalë punon në një shtresë tjetër dhe varet nga përshtatësi. Prandaj e njëjta makinë mund t'i përgjigjet ICMP-së dhe të refuzojë çdo pyetje të dërguar në të njëjtën adresë. Ekzekutoni dy testet në të njëjtën sesion përpara se të ndryshoni çfarëdo konfigurimi.

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

Ky çift është diagnoza. Trafiku i zakonshëm drejt nënrrjetit vazhdon, ndërsa zgjidhja e emrave vdes, dhe njerëzit përfundojnë se serveri është prishur ose se DNS nuk u dërgua kurrë. Të dy shpjegimet kushtojnë shtrenjtë për t'u ndjekur, dhe provat tregojnë drejt një vendi më të ngushtë. Konfirmoni çiftin përpara se të prekni një rregullim.

Opsioni është një rregull i platformës së filtrimit

Referenca e OpenVPN e përshkruan block-outside-dns si një kufizim të Windows Filtering Platform që i pengon aplikacionet të arrijnë DNS në përshtatës jashtë tunelit. Ai mbulon TCP dhe UDP në portën 53. Meqenëse filtri jeton në WFP dhe jo në listën e zakonshme të rregullave të murit të zjarrit, shtimi i një rregulli lejimi diku tjetër nuk e ndryshon domosdoshmërisht rezultatin. Prandaj këshilla e zakonshme për të lejuar DNS vazhdon të dështojë.

Rregullimi mund të vijë nga profili i importuar ose nga serveri, dhe skedari që redaktuat për herë të fundit "nuk është provë e asaj që ngarkoi klienti". Lexoni konfigurimin efektiv dhe regjistrin e lidhjes së bashku. Opsioni është gjithashtu specifik për Windows, dhe trajtimi i tij si i transportueshëm prodhon këshilla që nuk zbatohen.

Kërkoni komponentin e klientit që zotëron kufizimin në vend që të shtoni më shumë rregulla. Zotëruesi është gjëja që vërtet mund ta heqë atë.

Një filtër nuk është zgjidhës

Bllokimi i trafikut jashtë tunelit nuk instalon një zgjidhës funksional brenda tij. Opsioni heq një rrugë dhe e lë konfigurimin DNS të tunelit tek ai që ndërtoi profilin. Një profil që nuk dërgoi kurrë një zgjidhës tani nuk ka asnjë.

Kaloni nëpër tre kontrolle me radhë. Së pari, cilin zgjidhës përdor vërtet aplikacioni që dështon. Së dyti, nëse klienti zbatoi rregullimet DNS të VPN-së. Së treti, cili ndërfaqe e çon trafikun drejt atij zgjidhësi.

  1. Zgjidhësi në përdorim: krahasoni Resolve-DnsName -Server <resolver-ip> <name> me serverat DNS që rendit ipconfig /all.
  2. DNS i VPN-së i zbatuar: shqyrtoni hyrjet DNS të përshtatësit të tunelit në të njëjtin dalje të ipconfig /all.
  3. Ndërfaqja e përdorur: Find-NetRoute -RemoteIPAddress <resolver-ip> emërton ndërfaqen dalëse për atë destinacion.

Një zgjidhës LAN bëhet i paarritshëm sipas projektimit nën këtë politikë, edhe kur trafik tjetër LAN funksionon. Ky është opsioni duke bërë punën e vet. Nëse projektimi kërkon DNS përmes VPN-së, rregulloni regjistrimin e zgjidhësit dhe rrugën e tunelit; nëse kërkohet split DNS me përjashtime lokale, zotëruesi i konfigurimit duhet t'i shprehë ato përjashtime në një mënyrë të mbështetur.

Çfarë nuk mbulon opsioni

Porta 53 nuk është e gjithë zgjidhja e emrave. DNS over HTTPS dhe DNS over TLS përdorin transport tjetër, dhe disa aplikacione ekzekutojnë logjikën e tyre të zgjidhësit pavarësisht rregullimeve të sistemit. Prandaj një shfletues mund të zgjidhë emra ndërsa rreshti i komandave nuk mundet.

Trajtojeni atë ndryshim si diagnostic dhe jo si kundërshti. Krahasoni të dyja përpara se të vendosni që zgjidhësi i sistemit është prishur.

Mbajeni përfundimin të ngushtë kur e shkruani. Ky opsion kufizon një transport në një platformë, dhe pjesa tjetër e rrugës së zgjidhjes është një pyetje projektimi më vete me zotëruesin e vet.

Kontrolloni gjendjen përpara dhe pas shkëputjes

Ekzekutoni të njëjtin kërkim gjatë lidhjes dhe përsëri pasi klienti zotërues të shkëputet. I pari duhet të dështojë për një zgjidhës të jashtëm ndërsa tuneli është lart, dhe i dyti duhet të ketë sukses sapo filtri hiqet. Nëse ende dështon pas shkëputjes, filtri nuk u pastrua.

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

Rinisja e shërbimit të klientit ose e makinës zakonisht pastron një filtër të vjetër. Kjo e konfirmon diagnozën pa provuar një rregullim të përhershëm. Shkruani çfarë patë, sepse një filtër që i mbijeton një shkëputjeje do ta bëjë përsëri, dhe pikërisht shënimi justifikon një raport gabimi.

Vetëm pas atyre kontrolleve ka kuptim zëvendësimi i zgjidhësit ose rindërtimi i politikës së murit të zjarrit. Të dyja janë ndryshime më të mëdha sesa mbështesin provat.

Artikuj të ngjashëm