Care conexiune răspunde: domenii de rutare pentru DNS-ul unui VPN cu tunel divizat

Păstrați navigarea obișnuită pe conexiunea locală în timp ce numele companiei se rezolvă prin serverul DNS furnizat de tunel. Oprirea rutei implicite a VPN-ului vă dă prima jumătate și lasă a doua neconstruită. Urmează setarea lipsă, semnul de punctuație care îi schimbă sensul și singura comandă care arată care conexiune a răspuns de fapt. NetworkManager și systemd-resolved sunt presupuse în tot textul, pentru că exact acea pereche este locul unde începe de obicei confuzia.

Primul pas: separați ruta de resolver

ipv4.never-default răspunde la o întrebare de rutare și împiedică NetworkManager să instaleze această conexiune ca drum pentru tot traficul IPv4. Un domeniu de rutare DNS răspunde la altă întrebare: care servere de nume ale cărei conexiuni primesc o interogare pentru un sufix potrivit. Niciunul nu îl implică pe celălalt, iar un profil poate purta unul ani de zile în timp ce celălalt lipsește. Doar rută înseamnă că tunelul transportă subrețelele companiei și resolverul lui răspunde la numele companiei, în timp ce tot restul rămâne neatins.

Setați doar proprietatea de rută și numele interne eșuează, de obicei cu un timeout care sună ca un tunel stricat. Setați doar domeniul și ați adăugat în tăcere un sufix de căutare la fiecare nume scurt de pe mașină. Ambele greșeli trimit tichetul la serverul VPN, care rareori este partea greșită.

Al doilea pas: adăugați în profil un domeniu doar de rutare

Să presupunem că conexiunea se numește corp-vpn, sufixul companiei este internal.example, iar resolverul tunelului este deja accesibil. Citiți mai întâi valorile curente, pentru că comenzile de mai jos modifică proprietăți care pot avea deja intrări.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

Înlocuiți cu propriul nume de conexiune și propriul sufix, pentru că valorile de mai sus sunt ilustrative. Semnul plus contează mai mult decât pare: cu el valoarea se adaugă la lista existentă, iar fără el proprietatea este înlocuită și domeniile nelegate dispar dintr-un profil care funcționa ieri. Tilda schimbă comportamentul, nu stilul, iar paragraful de mai jos explică ce selectează. Păstrați citirea înaintea scrierii, ca forma de înlocuire să nu vă surprindă niciodată.

O tildă la început marchează un domeniu doar de rutare, așa că interogările potrivite merg la serverele acestei conexiuni, iar sufixul nu este adăugat la numele scurte. Scoateți tilda și același șir devine și sufix de căutare, un rezultat diferit pe care oamenii rareori îl urmăresc. Ambele setări de mai sus sunt IPv4, deci un profil cu stivă dublă are nevoie de ipv6.never-default și de același domeniu de rutare în ipv6.dns-search, altfel partea IPv6 continuă să folosească ruta implicită și numele interne eșuează acolo.

Al treilea pas: întrebați resolvectl care conexiune a răspuns

Rulați resolvectl status și citiți serverele DNS și domeniile fiecărei conexiuni, apoi rulați resolvectl query host.internal.example pe un nume intern real pe care aveți voie să îl interogați. A doua comandă este singura dovadă directă că domeniul de rutare își face treaba, pentru că numește conexiunea care a răspuns. Doar lista de stare dovedește configurația; interogarea dovedește rezolvarea.

systemd-resolved alege domeniul de rutare care se potrivește cel mai bine, așa că un domeniu mai specific pe altă conexiune poate câștiga totuși cursa. Dacă interogarea se întoarce de la o conexiune la care nu vă așteptați, citiți listele de domenii înainte de a atinge serverul DNS al VPN-ului. Un domeniu rădăcină ~. se potrivește cu tot, iar dacă este deja prezent domeniul specific câștigă în continuare pentru numele sale, în timp ce conexiunea răspunde la mult mai mult decât ați cerut. Eliminați sau restrângeți acea intrare rădăcină când intenția era doar numele companiei.

Dacă conexiunea VPN nu listează deloc un server DNS, clientul nu a înregistrat niciodată unul. Un domeniu de rutare fără server în spate eșuează altfel decât un domeniu lipsă, așa că reparați mai întâi înregistrarea.

Al patrulea pas: când numele se rezolvă, dar serviciul nu

Un răspuns corect dovedește doar că rezolvarea a funcționat, iar aplicația are încă nevoie de o rută către adresa primită. Acea rută trebuie să supraviețuiască rutei implicite divizate pe care tocmai ați configurat-o, deci verificați-o înainte de a da din nou vina pe DNS. Apoi verificați accesibilitatea pe portul serviciului, pentru că o partajare de fișiere sau un serviciu de director eșuează la rezolvare, rutare sau autentificare și produce mesaje foarte asemănătoare în fiecare caz. Țineți cele trei straturi separate când raportați rezultatul, altfel următoarea persoană reverifică un DNS care era deja corect.

Modificarea din Samba care circulă alături de această întrebare privește stratul de acces, nu alegerea DNS. Aplicarea ei la o defecțiune de rezolvare a numelor este felul în care o problemă mică dobândește a doua.

Al cincilea pas: nu înlocuiți resolverul pentru a repara un domeniu lipsă

Sfatul care suprascrie fișierul resolverului sau instalează alt manager de resolver rezolvă altă problemă. Sunt modificări de integrare a sistemului cu propriile moduri de eșec, iar niciuna nu adaugă un domeniu de rutare care nu a fost niciodată configurat. Stabiliți ce componentă deține rezolvarea numelor pe mașină înainte de a o înlocui, pentru că pe un desktop NetworkManager cu systemd-resolved acea proprietate este deja definită. Lupta cu ea este felul în care o configurație funcțională devine ceva ce nimeni nu poate reproduce.

Ordinea de lucru: confirmați că tunelul furnizează un resolver, adăugați domeniul doar de rutare, reconectați-vă prin controalele profilului, verificați conexiunea care răspunde și apoi testați serviciul pe portul său. Acea secvență lasă un rezultat pe care îl puteți preda următoarei persoane fără o a doua discuție.