DNS-ja e shtyrë nga OpenVPN injorohet: cili komponent e zbaton

Regjistri tregon opsionin që serveri shtyu, tuneli është aktiv, dhe emrat e brendshëm vazhdojnë të dështojnë. Një pyetje e drejtpërdrejtë te zgjidhësi përgjigjet, pra serveri është në rregull, por çdo aplikacion vazhdon të pyesë ruterin lokal. Ajo që arriti te klienti është një ofertë, jo një ndryshim në zgjidhës, dhe komponenti që zotëron zgjidhjen e emrave ndryshon në Linux, Windows dhe macOS. Sapo ta ndash opsionin nga pronari i tij, katër defekte mbulojnë pothuajse çdo raport: asnjë hook, dy hook që konkurrojnë, DNS i ndarë që punon si është projektuar, ose një emër i shkurtër që kërkon një prapashtesë dhe jo një server.

Një opsion i shtyrë është ofertë, jo instalim

Në server, dy direktiva përshkruajnë qëllimin, jo efektin:

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

Klienti nuk merr një zgjidhës të konfiguruar. Merr variabla mjedisi, foreign_option_1 dhe të tjerë, një për çdo rresht të shtyrë, dhe diçka lokale duhet t'i lexojë dhe të rishkruajë gjendjen e zgjidhësit të sistemit operativ. Në Linux asgjë nuk e bën këtë si parazgjedhje, prandaj një server i saktë dhe një klient i lidhur mund të zgjidhin ende emra përmes LAN.

Midis dy skajeve ka tre faza: shtytja duhet të arrijë, klienti duhet ta ekspozojë dhe një hook duhet ta zbatojë. Lexoni fazën e mesme në regjistrin e klientit dhe të fundit në gjendjen e zgjidhësit, kurrë e kundërta, sepse një rresht regjistri vërteton vetëm dy të parat.

Konfirmoni se shtytja arriti dhe gjeni pronarin

Filloni duke emërtuar nisësin: një komandë openvpn e thjeshtë, një instancë systemd, NetworkManager ose një klient i furnizuesit. Kjo përcakton ku mund të jetojë një hook. Në një host me systemd-resolved, resolvectl status rendit çdo lidhje me serverët DNS dhe domenet e kërkimit që përdor vërtet, dhe lidhja e tunelit nuk quhet gjithmonë tun0.

Nëse adresa e shtyrë shfaqet në regjistër por jo në asnjë lidhje, integrimi mungon. Nëse shfaqet në lidhje dhe pyetjet vazhdojnë të dalin diku tjetër, problemi është cilat pyetje zgjedhin atë lidhje. NetworkManager dns=dnsmasq në skedarin /etc/NetworkManager/NetworkManager.conf ekzekuton një përcjellës lokal që zbaton DNS të ndarë me qëllim: emrat brenda domenit VPN shkojnë te zgjidhësi VPN, gjithçka tjetër ruan rrugën e mëparshme. Kjo sjellje duket si defekt kur prisnit që të gjithë trafiku të lëvizte; kontrolloni cilësimet për çdo lidhje me nmcli connection show "My VPN", ku ipv4.dns dhe ipv4.dns-search mbajnë vlerat pas asaj që raporton pajisja, përpara se ta quani të prishur. Nëse çdo pyetje vërtet duhet të arrijë zgjidhësin VPN, hiqni dns=dnsmasq nga NetworkManager.conf dhe rinisni NetworkManager, i cili ia kthen zgjidhjen cilësimeve të lidhjes; përndryshe mbani DNS të ndarë dhe korrigjoni listën e domeneve të shtyra.

Linux: jepini opsionet zgjidhësit

Paketat e shpërndarjes ofrojnë një hook për këtë, dhe klienti duhet të lejohet ta ekzekutojë. Një rregullim tipik në një host pa systemd-resolved:

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

Me systemd-resolved skripti më i vjetër resolv.conf mund të mos ndryshojë asgjë të rëndësishme, sepse zgjidhësi stub mban gjendjen për çdo lidhje. update-systemd-resolved ndihmësi dokumenton një formë hook që përdor up-restart dhe down-pre, çka ka rëndësi kur një ndërfaqe mbijeton një tentativë të vetme lidhjeje. Çfarëdo që të zgjidhni, një komponent duhet të zotërojë gjendjen. Shtimi i një hook të palidhur pranë NetworkManager i jep dy shkrues të njëjtës lidhje, dhe rezultati atëherë varet nga rendi dhe jo nga konfigurimi juaj.

Ekziston edhe rasti kur NetworkManager e injoroi plotësisht opsionin e shtyrë derisa adresa e serverit u fut në cilësimet IPv4 të lidhjes, dhe pastaj gjendja e zgjidhësit tregoi se po përdorej. Ia vlen ta provoni përpara se të rishkruani skripte, sepse e zhvendos problemin nga një hook shell në profilin e lidhjes që tashmë mbart tunelin.

Windows dhe macOS zbatojnë pjesë të ndryshme

Klienti i Windows vërtet vendos serverët DNS të përshtatësit VPN, por Windows vazhdon të zgjedhë ndërfaqen sipas metrikës dhe vazhdon të ketë nevojë për një prapashtesë për të zgjeruar një emër të shkurtër. Konfirmoni gjendjen e përshtatësit, jo profilin:

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

Nëse adresa mungon, vendoseni me Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, pastaj shtoni prapashtesën te vetitë IPv4 të përshtatësit që fileserver të bëhet fileserver.corp.example. Një vlerë SearchList për të gjithë makinën nën Tcpip\Parameters bën të njëjtën. Aty ku emri i gjatë zgjidhet dhe ai i thjeshtë jo, zgjidhësi është tashmë i saktë dhe faji është i listës së kërkimit. Korrigjimet, sipas radhës: shtyni një DOMAIN që klienti të mësojë prapashtesën, shtoni atë prapashtesë në listën e kërkimit të përshtatësit ose të lidhjes, dhe si masë e përkohshme fiksoni emrin në hosts, ose në LMHOSTS në Windows; shfletimi NetBIOS nuk kalon një ruter, prandaj transmetimi që gjen një emër të shkurtër në LAN-in e zyrës nuk arrin kurrë te një klient tuneli.

block-outside-dns block-outside-dns është sjellje e klientit Windows, jo një rresht profili i transportueshëm, dhe kopjimi në një profil Linux ose macOS nuk e riprodhon atje. Nëse emrat publikë punojnë dhe ata të brendshëm dështojnë në Windows, krahasoni rendin e përshtatësve në Cilësimet e avancuara me ipconfig /all. Në macOS rendi i zgjidhësve për shërbim i takon sistemit, prandaj përdorni scutil --dns për të parë cili zgjidhës pyetet për cilin domen, dhe trajtojeni çdo korrigjim të vetëm të raportuar të profilit si të varur nga klienti dhe jo të përgjithshëm.

Një makinë virtuale në të njëjtin laptop nuk trashëgon asgjë nga kjo. Jepini mysafirit hyrjen e vet të zgjidhësit për domenin e brendshëm, ose lini NAT-in e hipervizorit t'i përcjellë pyetjet e tij përmes hostit, gjë që është e saktë vetëm sa kohë tuneli i hostit është aktiv.

Historiku është shkaku i tretë. Serverët DNS ose cilësimet e prapashtesës nga një profil i mëparshëm mund t'i mbijetojnë rilidhjeve, prandaj kur përshtatësi duket i saktë dhe kërkimet vazhdojnë të dështojnë, krahasoni përshtatësin aktiv me Get-VpnConnection dhe fshini ose mbishkruani hyrjen e vjetruar përpara se të prekni serverin.

Provoni ku shkoi pyetja

Një kapje gjatë një kërkimi e zgjidh mosmarrëveshjen: tcpdump -ni eth0 port 53 tregon pyetje në ndërfaqen fizike, çka do të thotë se dalin jashtë tunelit dhe zgjidhësi nuk u ndërrua kurrë. dig @10.8.0.1 name.corp.example pastaj ndan dy rastet e mbetura. Nëse pyetja e drejtpërdrejtë përgjigjet, zgjidhësi punon dhe klienti nuk e përdor; nëse skadon, zgjidhësi është i paarritshëm përmes tunelit dhe asnjë ndryshim lokal nuk do të ndihmojë.

Nëse zgjidhësi që përdoret ende është ai që dha ofruesi, tuneli kripton trafikun ndërsa emrat mbeten të dukshëm për atë ofrues. Është çështje rrjedhjeje dhe jo funksionimi, dhe e njëjta kapje përgjigjet: një pyetje në ndërfaqen fizike shkon te dikush jashtë tunelit.

Arritshmëria përfshin murin e zjarrit në hostin VPN, i cili duhet të lejojë UDP dhe TCP 53 nga grupi. Një port i bllokuar duket saktësisht si një shtytje e prishur, dhe po ashtu një zgjidhës që përgjigjet vetëm nga brendësia e rrjetit të tunelit. Përsëriteni kapjen pas një shkëputjeje dhe rilidhjeje, sepse cilësimet që shfaqen në lidhjen e parë dhe zhduken në të dytën janë defekt i ciklit të jetës në hook, jo një opsion që mungon.

Mbani një pronar dhe verifikoni sipas radhës

Një skript që rishkruan DNS-në e përshtatësit bazuar në një gjendje tuneli të supozuar dublon konfigurimin që profili tashmë mbart, dhe dështon në heshtje herën e parë që supozimi është i gabuar. Preferoni cilësimet DNS të vetë lidhjes ose një hook të dokumentuar, dhe shënoni cilindërqë zgjodhët, që personi tjetër të mos shtojë një të dytë.

Mbyllni ciklin me katër kontrolle: adresa e shtyrë e pranishme në lidhjen e tunelit, emri i brendshëm i zgjidhur si emër plotësisht i kualifikuar, i njëjti emër i zgjidhur pa prapashtesën, dhe të dyja ende të vërteta pas një rilidhjeje. Një kapje ju tregon cila nga të katërt dështoi. Manuali i OpenVPN 2.6 rendit dhcp-option dhe direktivat e skripteve me shënimet e tyre për platformat.