Tunnelen er oppe, men hvorfor fejler det private navn stadig?

Alt ved forbindelsen ser rigtigt ud: tunnelen er oppe, og konsollen viser det private endepunkt, men hver anmodning fejler på navneopløsning. Det naturlige træk er at bebrejde tunnelen, som normalt viser sig uskyldig. Forespørgslen sendes til en server, der intet ved om den private zone. Ingen ruteændring vil ændre det svar, fordi problemet er, hvem der blev spurgt.

Hvilken resolver nåede forespørgslen?

Find resolveren, der er knyttet til hvert link, før du overhovedet ser på tunnelen. Linux viser servere for hvert link via resolver-statuskommandoen, og macOS viser scopede resolvere i sit DNS-konfigurationsdump. Hvis svaret stadig kommer fra hjemmeruteren, blev tunnellinket aldrig konsulteret.

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

To faser blandes sammen her: en server, der skubber en resolveradresse, og en klient, der installerer den på det aktive link. En profil kan indeholde indstillingen, og en log kan vise, at den ankommer, mens operativsystemet fortsætter med at bruge den gamle server. Sammenlign loggen med det, linket rapporterer, og stol på linket.

Brug en adresse, som cloud-netværket faktisk svarer på

Cloud-netværk svarer typisk på private navne via en reserveret adresse to pladser fra bunden af området, så et netværk, der starter på 10.0.0.0, svarer på 10.0.0.2. Nogle udbydere offentliggør også en link-local resolver, der virker uden at kende området, hvilket hjælper, når netværket er bygget af en anden. Spørg kandidatadressen direkte, før du skubber den til nogen. En adresse, der ikke er en resolver, ligner præcis et firewall-drop, fordi forespørgslen simpelthen aldrig får et svar.

Hvis den direkte forespørgsel svarer indefra netværket, men ikke over tunnelen, er resolveren fin, og vejen mellem de to punkter er ikke. Det resultat flytter undersøgelsen til ruter, videresendelse og adgangsregler i stedet for klientprofilen.

En tunnel bærer ikke navnerummet

Pakker krydser; navne gør ikke. Hver side skal have at vide, hvilket navnerum der tilhører den anden, og det er et separat objekt, som ejes af den, der har zonen. Den sædvanlige form er en videresendelse for ét navnerum, rettet mod en resolver, der kan nås over tunnelen.

I praksis har hver retning brug for sin egen regel, fordi den side, der ejer zonen, skal sende forespørgslen videre. Begge retninger kræver, at forespørgslens kilde routes og tillades, og den svarande side skal returnere svar gennem tunnelen i stedet for mod internettet. Hold videresendelsen snæver, så kun det private navnerum afhænger af linket. At sende hver forespørgsel gennem den forvandler en lille afhængighed til et totalt udfald i det øjeblik, tunnelen falder.

Gå grænserne igennem i rækkefølge

Test resolveren, der er installeret på det aktive link, derefter en direkte forespørgsel til den resolver, derefter den samme forespørgsel fra den fjerne side og til sidst applikationen, der bruger det samme navn. Hvert trin isolerer én grænse, så en fejl fortæller, hvor du skal kigge, i stedet for at genstarte undersøgelsen. Et svar, der virker, mens applikationen fejler, peger på certifikattillid eller en API-politik i stedet for på DNS. De fejl er reelle, og ingen resolverændring vil reparere dem.

Skriv ned, hvilket trin der fejlede. Den ene linje er det, den næste person har brug for, og det tager ti sekunder at registrere.

Behold kæden, hvor den næste person kan finde den

Registrer den skubbede resolver, videresendelsesreglen, den tilladte forespørgselskilde og det svarande endepunkt ét sted. Når det private navn fejler igen, viser posten, om tunnelen flyttede sig, resolveradressen ændrede sig, eller en regel blev indsnævret. Uden den starter hver hændelse fra nul og slutter med de samme tre gæt.

Hold posten kort nok til at forblive præcis: fire linjer, en dato og navnet på den, der ejer hver del. En forældet post er værre end ingen, fordi den ser autoritativ ud, mens den er forkert.