Tunelul este activ, deci de ce numele privat încă eșuează?

Totul la conexiune pare corect: tunelul este activ și consola afișează punctul final privat, dar fiecare cerere eșuează la rezolvarea numelor. Mișcarea naturală este să dăm vina pe tunel, care de obicei se dovedește nevinovat. Interogarea este trimisă către un server care nu știe nimic despre zona privată. Nicio schimbare de rutare nu va modifica acel răspuns, pentru că problema este pe cine am întrebat.

Ce resolver a primit interogarea?

Găsiți resolverul atașat fiecărei legături înainte de a privi tunelul. Linux expune servere pe legătură prin comanda de stare a resolverului, iar macOS arată resolvere cu domeniu în dumpul de configurare DNS. Dacă răspunsul vine încă de la routerul de acasă, legătura tunelului nu a fost niciodată consultată.

resolvectl status
scutil --dns | head -40
dig +short internal.example.com

Aici se confundă două etape: un server care împinge o adresă de resolver și un client care o instalează pe legătura activă. Un profil poate conține opțiunea, iar un jurnal poate arăta că sosește, în timp ce sistemul de operare continuă să folosească serverul vechi. Comparați jurnalul cu ce raportează legătura și aveți încredere în legătură.

Folosiți o adresă la care rețeaua cloud răspunde cu adevărat

Rețelele cloud răspund de obicei la numele private printr-o adresă rezervată deplasată cu doi de la baza intervalului, așa că o rețea care începe la 10.0.0.0 răspunde la 10.0.0.2. Unii furnizori publică și un resolver local de legătură care funcționează fără să cunoască intervalul, ceea ce ajută când rețeaua a fost construită de altcineva. Interogați adresa candidată direct înainte de a o împinge cuiva. O adresă care nu este resolver arată exact ca o respingere a firewallului, pentru că interogarea pur și simplu nu primește niciodată răspuns.

Dacă interogarea directă răspunde din interiorul rețelei, dar nu prin tunel, resolverul este în regulă, iar calea dintre cele două puncte nu. Acest rezultat mută investigația către rute, redirecționare și reguli de acces în loc de profilul clientului.

Un tunel nu transportă spațiul de nume

Pachetele trec; numele nu. Fiecare parte trebuie să știe ce spațiu de nume aparține celeilalte, iar acesta este un obiect separat deținut de cel care are zona. Forma obișnuită este o redirecționare pentru un singur spațiu de nume, îndreptată către un resolver accesibil prin tunel.

În practică fiecare direcție are nevoie de propria regulă, pentru că partea care deține zona trebuie să trimită interogarea mai departe. Ambele direcții necesită ca sursa interogării să fie rutată și permisă, iar partea care răspunde trebuie să returneze răspunsurile prin tunel, nu către internet. Păstrați redirecționarea îngustă, astfel încât doar spațiul de nume privat să depindă de legătură. Trimiterea fiecărei interogări prin ea transformă o dependență mică într-o cădere totală în momentul în care tunelul cade.

Parcurgeți granițele în ordine

Testați resolverul instalat pe legătura activă, apoi o interogare directă către acel resolver, apoi aceeași interogare din partea îndepărtată și, în final, aplicația care folosește același nume. Fiecare pas izolează o graniță, așa că o defecțiune spune unde să priviți în loc să reîncepeți investigația. Un răspuns care funcționează în timp ce aplicația eșuează indică încrederea în certificat sau o politică API, nu DNS. Acele defecțiuni sunt reale, iar nicio schimbare de resolver nu le va repara.

Notați care pas a eșuat. Acea singură linie este ce are nevoie următoarea persoană, iar înregistrarea ei durează zece secunde.

Păstrați lanțul unde următoarea persoană îl poate găsi

Înregistrați resolverul împins, regula de redirecționare, sursa de interogare permisă și punctul final care răspunde într-un singur loc. Când numele privat eșuează din nou, înregistrarea arată dacă tunelul s-a mutat, dacă adresa resolverului s-a schimbat sau dacă o regulă a fost restrânsă. Fără ea, fiecare incident începe de la zero și se termină cu aceleași trei presupuneri.

Păstrați înregistrarea suficient de scurtă pentru a rămâne exactă: patru linii, o dată și numele celui care deține fiecare parte. O înregistrare învechită este mai rea decât niciuna, pentru că pare autoritară în timp ce este greșită.