Tunneln är uppe, så varför misslyckas det privata namnet fortfarande?

Allt med anslutningen ser rätt ut: tunneln är uppe och konsolen visar den privata ändpunkten, men varje begäran misslyckas i namnmatchningen. Det naturliga draget är att skylla på tunneln, som vanligtvis visar sig oskyldig. Frågan skickas till en server som inte vet något om den privata zonen. Ingen ruttändring kommer att ändra det svaret, eftersom problemet är vem som tillfrågades.

Vilken resolver nådde frågan?

Hitta resolvern som är kopplad till varje länk innan du ens tittar på tunneln. Linux visar servrar per länk via resolver-statuskommandot, och macOS visar scopade resolvrar i sin DNS-konfigurationsdump. Om svaret fortfarande kommer från hemroutern har tunnellänken aldrig konsulterats.

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

Här blandas två faser ihop: en server som knuffar en resolveradress och en klient som installerar den på den aktiva länken. En profil kan innehålla valet, och en logg kan visa att det anländer, medan operativsystemet fortsätter använda den gamla servern. Jämför loggen med det länken rapporterar och lita på länken.

Använd en adress som molnnätverket faktiskt svarar på

Molnnätverk svarar vanligtvis på privata namn via en reserverad adress två steg från basen av intervallet, så ett nätverk som börjar på 10.0.0.0 svarar på 10.0.0.2. Vissa leverantörer publicerar också en link-lokal resolver som fungerar utan att känna till intervallet, vilket hjälper när någon annan byggt nätverket. Fråga kandidatadressen direkt innan du knuffar den till någon. En adress som inte är en resolver ser exakt ut som en brandväggs-drop, eftersom frågan helt enkelt aldrig får något svar.

Om den direkta frågan svarar inifrån nätverket men inte över tunneln, är resolvern i ordning och vägen mellan de två punkterna inte. Det resultatet flyttar utredningen till rutter, vidarebefordran och åtkomstregler i stället för klientprofilen.

En tunnel bär inte namnrymden

Paket passerar; namn inte. Varje sida måste få veta vilken namnrymd som tillhör den andra, och det är ett separat objekt som ägs av den som håller zonen. Den vanliga formen är en vidarebefordran för en namnrymd, riktad mot en resolver som nås via tunneln.

I praktiken behöver varje riktning sin egen regel, eftersom sidan som äger zonen måste skicka frågan vidare. Båda riktningarna kräver att frågans källa routas och tillåts, och den svarande sidan måste returnera svar genom tunneln i stället för mot internet. Håll vidarebefordran smal, så att bara den privata namnrymden beror på länken. Att skicka varje fråga genom den förvandlar ett litet beroende till ett totalt avbrott i samma ögonblick som tunneln faller.

Gå igenom gränserna i ordning

Testa resolvern som är installerad på den aktiva länken, sedan en direkt fråga till den resolvern, sedan samma fråga från fjärrsidan och till sist applikationen som använder samma namn. Varje steg isolerar en gräns, så ett fel talar om var du ska titta i stället för att börja om utredningen. Ett svar som fungerar medan applikationen misslyckas pekar på certifikatförtroende eller en API-policy i stället för DNS. De felen är verkliga, och ingen resolverändring kommer att reparera dem.

Skriv ned vilket steg som misslyckades. Den enda raden är det nästa person behöver, och det tar tio sekunder att registrera den.

Håll kedjan där nästa person kan hitta den

Registrera den knuffade resolvern, vidarebefordringsregeln, den tillåtna frågekällan och den svarande ändpunkten på ett ställe. När det privata namnet misslyckas igen visar posten om tunneln flyttade sig, om resolveradressen ändrades eller om en regel snävades in. Utan den börjar varje incident på noll och slutar med samma tre gissningar.

Håll posten kort nog att förbli korrekt: fyra rader, ett datum och namnet på den som äger varje del. En inaktuell post är värre än ingen, eftersom den ser auktoritativ ut medan den är fel.