Tunel běží, tak proč privátní jméno stále selhává?

Všechno na připojení vypadá správně: tunel běží a konzole ukazuje privátní koncový bod, ale každý požadavek selhává při překladu jmen. Přirozeným krokem je obvinit tunel, který se obvykle ukáže jako nevinný. Dotaz se posílá serveru, který o privátní zóně nic neví. Žádná změna směrování tuto odpověď nezmění, protože problém je v tom, koho jsme se zeptali.

Který resolver dotaz dostal?

Najděte resolver připojený ke každému spoji, než se vůbec podíváte na tunel. Linux vystavuje servery pro jednotlivé spoje pomocí příkazu stavu resolveru a macOS ukazuje resolvery s rozsahem ve výpisu konfigurace DNS. Pokud odpověď stále přichází od domácího routeru, spoj tunelu nebyl nikdy použit.

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

Zaměňují se tu dvě fáze: server, který protlačuje adresu resolveru, a klient, který ji instaluje na aktivní spoj. Profil může volbu obsahovat a log může ukazovat, že přichází, zatímco operační systém dál používá starý server. Porovnejte log s tím, co spoj hlásí, a věřte spoji.

Použijte adresu, na kterou cloudová síť skutečně odpovídá

Cloudové sítě obvykle odpovídají na privátní jména přes rezervovanou adresu posunutou o dvě od základu rozsahu, takže síť začínající na 10.0.0.0 odpovídá na 10.0.0.2. Někteří poskytovatelé také zveřejňují link-local resolver, který funguje bez znalosti rozsahu, což pomáhá, když síť postavil někdo jiný. Zeptejte se kandidátské adresy přímo, než ji předáte komukoli. Adresa, která není resolver, vypadá přesně jako zahození firewallem, protože dotaz prostě nikdy nedostane odpověď.

Pokud přímý dotaz odpovídá zevnitř sítě, ale ne přes tunel, resolver je v pořádku a cesta mezi oběma body ne. Tento výsledek přesouvá vyšetřování na trasy, přeposílání a pravidla přístupu, nikoli na profil klienta.

Tunel nenese jmenný prostor

Pakety procházejí; jména ne. Každé straně je třeba říct, který jmenný prostor patří druhé, a to je samostatný objekt, který vlastní ten, kdo drží zónu. Obvyklým tvarem je přeposílání pro jeden jmenný prostor namířené na resolver dostupný přes tunel.

V praxi každý směr potřebuje vlastní pravidlo, protože strana, která zónu vlastní, musí dotaz poslat dál. Oba směry vyžadují, aby zdroj dotazu byl směrován a povolen, a odpovídající strana musí vracet odpovědi tunelem, nikoli směrem k internetu. Držte přeposílání úzké, aby na spoji závisel jen privátní jmenný prostor. Posílání každého dotazu přes něj promění malou závislost v úplný výpadek ve chvíli, kdy tunel spadne.

Projděte hranice v pořadí

Otestujte resolver nainstalovaný na aktivním spoji, pak přímý dotaz na tento resolver, pak stejný dotaz z druhé strany a nakonec aplikaci používající stejné jméno. Každý krok izoluje jednu hranici, takže selhání řekne, kam se podívat, místo aby začínalo vyšetřování znovu. Odpověď, která funguje, zatímco aplikace selhává, ukazuje na důvěru certifikátu nebo zásadu API, nikoli na DNS. Tyto poruchy jsou skutečné a žádná změna resolveru je neopraví.

Zapište, který krok selhal. Ten jediný řádek je to, co další člověk potřebuje, a jeho zapsání trvá deset sekund.

Udržujte řetěz tam, kde ho další člověk najde

Zaznamenejte protlačený resolver, pravidlo přeposílání, povolený zdroj dotazů a odpovídající koncový bod na jednom místě. Když privátní jméno znovu selže, záznam ukáže, zda se tunel posunul, adresa resolveru změnila nebo bylo pravidlo zúženo. Bez něj každý incident začíná od nuly a končí stejnými třemi dohady.

Držte záznam dost krátký, aby zůstal přesný: čtyři řádky, datum a jméno toho, kdo vlastní každou část. Zastaralý záznam je horší než žádný, protože vypadá autoritativně, i když je špatný.