OpenVPN-i tõrjutud DNS eiratakse: milline komponent seda rakendab

Logi näitab valikut, mille server tõrjus, tunnel on üleval ja sisemised nimed ikka ei lahene. Päring otse resolverile vastab, seega server on korras, ent iga rakendus küsib ikka kohalikku ruuterit. Kliendini jõudis pakkumine, mitte muudatus resolveris, ja komponent, kellel on nimelahendus, erineb Linuxis, Windowsis ja macOS-is. Kui eraldate valiku selle omanikust, katavad neli riket peaaegu kõik raportid: hook puudub, kaks konkureerivat hooki, jaotatud DNS töötab nii nagu projekteeritud, või lühinimi vajab sufiksit, mitte serverit.

Tõrjutud valik on pakkumine, mitte paigaldus

Serveris kirjeldavad kaks direktiivi kavatsust, mitte mõju:

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

Klient ei saa konfigureeritud resolverit. Ta saab keskkonnamuutujad, foreign_option_1 ja järgnevad, üks iga tõrjutud rea kohta, ja miski kohalik peab need lugema ning operatsioonisüsteemi resolveri oleku ümber kirjutama. Linuxis ei tee seda vaikimisi miski, seepärast võivad korrektne server ja ühendatud klient ikkagi LAN-i kaudu lahendada.

Kahe otsa vahel on kolm etappi: push peab kohale jõudma, klient peab selle paljastama ja hook peab selle rakendama. Lugege keskmist etappi kliendi logist ja viimast resolveri olekust, mitte kunagi vastupidi, sest logirida tõestab ainult kahte esimest.

Veenduge, et push jõudis kohale, ja leidke omanik

Alustage käivitaja nimetamisest: paljas openvpn käsk, systemd-instants, NetworkManager või tarnija klient. See määrab, kus hook saab elada. Hostis, kus on systemd-resolved, resolvectl status loetleb iga lingi koos DNS-serverite ja otsingudomeenidega, mida see tegelikult kasutab, ja tunneli link ei ole alati nimega tun0.

Kui tõrjutud aadress on logis, aga mitte ühelgi lingil, on integratsioon puudu. Kui see on lingil ja päringud väljuvad ikka mujale, on probleem selles, millised päringud selle lingi valivad. NetworkManager dns=dnsmasq failis /etc/NetworkManager/NetworkManager.conf käivitab kohaliku edasisaatja, mis rakendab jaotatud DNS-i meelega: VPN-domeeni sees olevad nimed lähevad VPN-resolverile, kõik muu hoiab endist teed. See käitumine näib rikkena, kui ootasite, et kogu liiklus liigub; kontrollige ühendusepõhiseid seadeid käsuga nmcli connection show "My VPN", kus ipv4.dns ja ipv4.dns-search hoiavad väärtusi selle taga, mida seade teatab, enne kui nimetate selle katki. Kui iga päring peab tõesti jõudma VPN-resolverini, eemaldage dns=dnsmasq failist NetworkManager.conf ja taaskäivitage NetworkManager, mis annab nimelahenduse tagasi ühenduse seadetele; vastasel juhul jätke jaotatud DNS ja parandage tõrjutud domeenide nimekiri.

Linux: andke valikud resolverile

Distributsioonipaketid toovad selleks hooki ja kliendil peab olema luba seda käivitada. Tüüpiline lahendus hostis ilma systemd-resolvedita:

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

Systemd-resolvediga ei pruugi vanem resolv.conf-skript midagi olulist muuta, sest stub-resolver hoiab olekut lingi kohta. update-systemd-resolved abiline dokumenteerib hook-vormi, mis kasutab up-restart ja down-pre, mis loeb, kui liides elab üle ühe ühenduskatse. Mida iganes valite, üks komponent peab olekut omama. Kõrvalise hooki lisamine NetworkManageri kõrvale annab samale lingile kaks kirjutajat ja tulemus sõltub siis järjekorrast, mitte teie konfiguratsioonist.

On ka juhtum, kus NetworkManager eiras tõrjutud valikut täielikult, kuni serveri aadress sisestati ühenduse IPv4-seadetesse, mille järel resolveri olek näitas, et see on kasutusel. Seda tasub proovida enne skriptide ümberkirjutamist, sest see viib probleemi shell-hookist ühenduse profiili, mis tunnelit juba kannab.

Windows ja macOS rakendavad eri osi

Windowsi klient seadistab tõesti VPN-adapteri DNS-serverid, aga Windows valib liidese endiselt metrika järgi ja vajab lühinime laiendamiseks endiselt sufiksit. Kinnitage pigem adapteri olekut kui profiili:

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

Kui aadress puudub, määrake see käsuga Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, seejärel lisage sufiks adapteri IPv4-omadustesse, et fileserver muutuks fileserver.corp.example. Väärtus SearchList kogu masina jaoks jaotises Tcpip\Parameters teeb sama. Kui pikk nimi laheneb ja paljas mitte, on resolver juba korras ja süüdi on otsingunimekiri. Parandused järjekorras: tõrjugem DOMAIN et klient õpiks sufiksi, lisage see sufiks adapteri või ühenduse otsingunimekirja ja kinnitage nimi ajutise meetmena faili hosts, või LMHOSTS Windowsis; NetBIOS-i sirvimine ei ületa ruuterit, seega kontori LAN-is lühinime leidev ringhääling ei jõua kunagi tunnelikliendini.

block-outside-dns block-outside-dns on Windowsi kliendi käitumine, mitte kaasaskantav profiilirida, ja selle kopeerimine Linuxi või macOS-i profiili ei taasta seda seal. Kui avalikud nimed töötavad ja sisemised Windowsis ei, võrrelge adapterite järjekorda jaotises Täpsemad seaded käsuga ipconfig /all. macOS-is kuulub resolverite järjekord teenuse kohta süsteemile, seega kasutage scutil --dns , et näha, millist resolverit millise domeeni jaoks küsitakse, ja käsitlege iga üksikut teatatud profiiliparandust kliendist sõltuvana, mitte üldisena.

Sama sülearvuti virtuaalmasin ei päri sellest midagi. Andke külalisele sisemise domeeni jaoks oma resolveri-kirje või laske hüperviisori NAT-il selle päringud hosti kaudu edasi saata, mis on õige ainult seni, kuni hosti tunnel on üleval.

Ajalugu on kolmas põhjus. Varasema profiili DNS-serverid või sufiksiseaded võivad ühenduste vahel püsida, seega kui adapter näib korras ja otsingud ikka ebaõnnestuvad, võrrelge elusat adapterit käsuga Get-VpnConnection ning kustutage või kirjutage aegunud kirje üle, enne kui serverit puutute.

Tõestage, kuhu päring läks

Ühe otsingu ajal tehtud püük lõpetab vaidluse: tcpdump -ni eth0 port 53 näitab päringuid füüsilisel liidesel, mis tähendab, et need väljuvad tunnelist välja ja resolverit ei vahetatud kunagi. dig @10.8.0.1 name.corp.example eraldab seejärel kaks ülejäänud juhtumit. Kui otsepäring vastab, resolver töötab ja klient ei kasuta seda; kui see aegub, on resolver tunnelist kättesaamatu ja ükski kohalik muudatus ei aita.

Kui veel kasutusel olev resolver on see, mille teenusepakkuja jagas, krüpteerib tunnel liiklust, samal ajal kui nimed jäävad sellele pakkujale nähtavaks. See on lekkimise, mitte funktsionaalsuse küsimus, ja sama püük vastab sellele: päring füüsilisel liidesel läheb kellelegi väljapoole tunnelit.

Kättesaadavus hõlmab VPN-hosti tulemüüri, mis peab lubama UDP ja TCP 53 porti basseinist. Suletud port näib täpselt nagu katkine push, samuti resolver, mis vastab ainult tunneli võrgu seest. Korrake püüki pärast ühte katkestust ja taasühendust, sest seaded, mis ilmuvad esimesel ühendusel ja kaovad teisel, on hooki elutsükli rike, mitte puuduv valik.

Hoidke üks omanik ja kontrollige järjekorras

Skript, mis kirjutab adapteri DNS-i ümber oletatud tunneli oleku põhjal, dubleerib konfiguratsiooni, mida profiil juba kannab, ja ebaõnnestub vaikselt esimesel korral, kui oletus on vale. Eelistage ühenduse enda DNS-seadeid või üht dokumenteeritud hooki ja kirjutage üles, millise valisite, et järgmine inimene teist ei lisaks.

Sulgege ring nelja kontrolliga: tõrjutud aadress on tunnelilingil, sisemine nimi laheneb täielikult kvalifitseeritud nimena, sama nimi laheneb ilma sufiksita ja mõlemad kehtivad veel pärast ühte taasühendust. Üks püük ütleb, milline neljast ebaõnnestus. OpenVPN 2.6 käsiraamat loetleb dhcp-option ja skriptidirektiivid koos platvormimärkustega.