DNS puŝita de OpenVPN estas ignorata: kiu komponanto aplikas ĝin

La protokolo montras la opcion, kiun la servilo puŝis, la tunelo estas aktiva, kaj internaj nomoj ankoraŭ malsukcesas. Mendo rekte al la solvilo respondas, do la servilo estas en ordo, tamen ĉiu aplikaĵo daŭre demandas la lokan ruteron. Tio, kio atingis la klienton, estas propono, ne ŝanĝo en la solvilo, kaj la komponanto, kiu posedas la nomrezolvon, malsamas en Linux, Windows kaj macOS. Kiam vi apartigos la opcion de ĝia posedanto, kvar misfunkcioj kovras preskaŭ ĉiun raporton: neniu hoko, du konkurantaj hokoj, dividita DNS funkcianta laŭ la dezajno, aŭ mallonga nomo, kiu bezonas sufikson anstataŭ servilon.

Puŝita opcio estas propono, ne instalado

Sur la servilo, du instrukcioj priskribas intencon, ne efikon:

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

La kliento ne ricevas agordan solvilon. Ĝi ricevas mediajn variablojn, foreign_option_1 kaj pluajn, unu por ĉiu puŝita linio, kaj io loka devas legi ilin kaj reverki la solvilan staton de la operaciumo. En Linux nenio faras tion defaŭlte, tial ĝusta servilo kaj konektita kliento ankoraŭ povas solvi nomojn tra la LAN.

Tri etapoj staras inter la du finoj: la puŝo devas vojaĝi, la kliento devas malkaŝi ĝin, kaj hoko devas apliki ĝin. Legu la mezan etapon en la klienta protokolo kaj la lastan en la solvila stato, neniam inverse, ĉar protokola linio pruvas nur la du unuajn.

Konfirmu, ke la puŝo alvenis, kaj trovu la posedanton

Komencu nomante la lanĉilon: nuda openvpn komando, systemd-instancaĵo, NetworkManager aŭ provizanta kliento. Tio decidas, kie hoko povas loĝi. Sur gastigo kun systemd-resolved, resolvectl status listigas ĉiun ligilon kun la DNS-serviloj kaj serĉaj domajnoj, kiujn ĝi efektive uzas, kaj la tunela ligilo ne ĉiam nomiĝas tun0.

Se la puŝita adreso aperas en la protokolo sed sur neniu ligilo, la integriĝo mankas. Se ĝi aperas sur la ligilo kaj demandoj ankoraŭ eliras aliloke, la problemo estas kiuj demandoj elektas tiun ligilon. NetworkManager dns=dnsmasq en la dosiero /etc/NetworkManager/NetworkManager.conf funkciigas lokan plusendilon, kiu intence aplikas dividitan DNS: nomoj ene de la VPN-domajno iras al la VPN-solvilo, ĉio alia konservas sian antaŭan vojon. Tiu konduto aspektas kiel misfunkcio, kiam vi atendis, ke la tuta trafiko translokiĝu; kontrolu la agordojn por ĉiu konekto per nmcli connection show "My VPN", kie ipv4.dns kaj ipv4.dns-search tenas la valorojn malantaŭ tio, kion la aparato raportas, antaŭ ol nomi ĝin rompita. Se ĉiu demando vere devus atingi la VPN-solvilon, forigu dns=dnsmasq el NetworkManager.conf kaj restartigu NetworkManager, kio redonas la nomrezolvon al la konektaj agordoj; alie konservu dividitan DNS kaj ĝustigu la puŝitan domajnan liston.

Linux: transdonu la opciojn al la solvilo

Distribuaj pakaĵoj liveras hokon por tio, kaj la kliento devas rajtis ekzekuti ĝin. Tipa aranĝo sur gastigo sen systemd-resolved:

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

Kun systemd-resolved la pli malnova resolv.conf-skripto eble ŝanĝas nenion gravan, ĉar la stub-solvilo tenas staton por ĉiu ligilo. update-systemd-resolved la helpilo dokumentas hokan formon, kiu uzas up-restart kaj down-pre, kio gravas, kiam interfaco postvivas unu konekprovan. Kion ajn vi elektos, unu komponanto devas posedi la staton. Aldoni nerilatan hokon apud NetworkManager donas du skribantojn al la sama ligilo, kaj la rezulto tiam dependas de ordo anstataŭ de via agordo.

Ekzistas ankaŭ la kazo, kiam NetworkManager tute ignoris la puŝitan opcion ĝis la servila adreso estis entajpita en la IPv4-agordoj de la konekto, post kio la solvila stato montris ĝin uzata. Indas provi tion antaŭ ol reverki skriptojn, ĉar ĝi movas la problemon de ŝela hoko al la konekta profilo, kiu jam portas la tunelon.

Windows kaj macOS aplikas malsamajn partojn

La Windows-kliento ja agordas la DNS-servilojn de la VPN-adaptilo, sed Windows ankoraŭ elektas interfacon laŭ metriko kaj ankoraŭ bezonas sufikson por etendi mallongan nomon. Konfirmu la staton de la adaptilo, ne tiun de la profilo:

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

Se la adreso mankas, agordu ĝin per Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, poste aldonu la sufikson al la IPv4-ecoj de la adaptilo, por ke fileserver fariĝu fileserver.corp.example. Valoro SearchList por la tuta maŝino sub Tcpip\Parameters faras la samon. Kie la longa nomo solviĝas kaj la nuda ne, la solvilo jam estas ĝusta kaj la serĉlisto kulpas. La riparoj, laŭ ordo: puŝu DOMAIN por ke la kliento lernu la sufikson, aldonu tiun sufikson al la serĉlisto de la adaptilo aŭ konekto, kaj kiel provizora rimedo fiksu la nomon en hosts, aŭ LMHOSTS en Windows; NetBIOS-brosado ne transiras ruteron, do la dissendo, kiu trovas mallongan nomon en la oficeja LAN, neniam atingas tunelan klienton.

block-outside-dns block-outside-dns estas konduto de la Windows-kliento, ne portebla profillieno, kaj kopii ĝin al Linux aŭ macOS-profilo ne reproduktas ĝin tie. Se publikaj nomoj funkcias kaj internaj malsukcesas en Windows, komparu la adaptilan ordon sub Altprogresintaj agordoj kun ipconfig /all. En macOS la solvila ordo por servo apartenas al la sistemo, do uzu scutil --dns por vidi, kiu solvilo estas demandata por kiu domajno, kaj traktu ĉiun unuopan raportitan profilriparon kiel dependan de la kliento, ne kiel ĝeneralan.

Virtuala maŝino sur la sama tekkomputilo heredas nenion el tio. Donu al la gasto propran solvilan enskribon por la interna domajno, aŭ lasu la NAT de la hipervizoro plusendi ĝiajn demandojn tra la gastiganto, kio ĝustas nur dum la tunelo de la gastiganto estas aktiva.

Historio estas la tria kaŭzo. DNS-serviloj aŭ sufikso-agordoj el pli frua profilo povas postvivi rekonektojn, do kiam la adaptilo aspektas ĝusta kaj serĉoj ankoraŭ malsukcesas, komparu la vivan adaptilon kun Get-VpnConnection kaj forviŝu aŭ anstataŭigu la malnovan enskribon antaŭ ol tuŝi la servilon.

Pruvu, kien iris la demando

Kaptaĵo dum unu serĉo solvas la disputon: tcpdump -ni eth0 port 53 montras demandojn sur la fizika interfaco, kio signifas, ke ili eliras ekster la tunelon kaj la solvilo neniam estis ŝaltita. dig @10.8.0.1 name.corp.example poste apartigas la du restajn kazojn. Se la rekta demando respondas, la solvilo funkcias kaj la kliento ne uzas ĝin; se ĝi tempolimas, la solvilo estas neatinebla tra la tunelo kaj nenia loka ŝanĝo helpos.

Se la solvilo ankoraŭ uzata estas tiu, kiun la provizanto disdonis, la tunelo ĉifras la trafikon dum la nomoj restas videblaj al tiu provizanto. Tio estas demando pri liko, ne pri funkciado, kaj la sama kaptaĵo respondas ĝin: demando sur la fizika interfaco iras al iu ekster la tunelo.

Atingebleco inkluzivas la fajroŝirmilon sur la VPN-gastiganto, kiu devas permesi UDP kaj TCP 53 el la naĝejo. Fermita pordo aspektas ĝuste kiel rompita puŝo, kaj same solvilo, kiu respondas nur el la interno de la tunela reto. Ripetu la kaptaĵon post unu malkonekto kaj rekonekto, ĉar agordoj, kiuj aperas ĉe la unua konekto kaj malaperas ĉe la dua, estas vivcikla misfunkcio en la hoko, ne mankanta opcio.

Tenu unu posedanton kaj kontrolu laŭ ordo

Skripto, kiu reverkas la adaptilan DNS surbaze de divenita tunela stato, duobligas agordon, kiun la profilo jam portas, kaj malsukcesas silente la unuan fojon, kiam la diveno malĝustas. Preferu la proprajn DNS-agordojn de la konekto aŭ unu dokumentitan hokon, kaj notu, kiun vi elektis, por ke la sekva persono ne aldonu duan.

Fermu la ciklon per kvar kontroloj: la puŝita adreso ĉeestas sur la tunela ligilo, la interna nomo solviĝas kiel plene kvalifikita nomo, la sama nomo solviĝas sen la sufikso, kaj ambaŭ ankoraŭ validas post unu rekonekto. Unu kaptaĵo diras al vi, kiu el la kvar malsukcesis. La manlibro de OpenVPN 2.6 listigas dhcp-option kaj la skriptajn instrukciojn kun iliaj platformaj notoj.