Tunel beží, tak prečo privátne meno stále zlyháva?

Všetko na pripojení vyzerá správne: tunel beží a konzola ukazuje privátny koncový bod, ale každá požiadavka zlyháva pri preklade mien. Prirodzeným krokom je obviniť tunel, ktorý sa zvyčajne ukáže ako nevinný. Dopyt sa posiela serveru, ktorý o privátnej zóne nič nevie. Žiadna zmena smerovania tú odpoveď nezmení, pretože problém je v tom, koho sme sa opýtali.

Ktorý resolver dopyt dostal?

Nájdite resolver pripojený ku každému spojeniu, skôr než sa vôbec pozriete na tunel. Linux zobrazuje servery pre jednotlivé spojenia pomocou príkazu stavu resolvera a macOS zobrazuje resolvery s rozsahom vo výpise konfigurácie DNS. Ak odpoveď stále prichádza od domáceho routera, spojenie tunela nebolo nikdy použité.

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

Zamieňajú sa tu dve fázy: server, ktorý pretláča adresu resolvera, a klient, ktorý ju inštaluje na aktívne spojenie. Profil môže voľbu obsahovať a log môže ukazovať, že prichádza, zatiaľ čo operačný systém ďalej používa starý server. Porovnajte log s tým, čo hlási spojenie, a verte spojeniu.

Použite adresu, na ktorú cloudová sieť skutočne odpovedá

Cloudové siete zvyčajne odpovedajú na privátne mená cez rezervovanú adresu posunutú o dve od základu rozsahu, takže sieť začínajúca na 10.0.0.0 odpovedá na 10.0.0.2. Niektorí poskytovatelia tiež zverejňujú link-local resolver, ktorý funguje bez znalosti rozsahu, čo pomáha, keď sieť postavil niekto iný. Opýtajte sa kandidátskej adresy priamo, skôr než ju niekomu pretlačíte. Adresa, ktorá nie je resolver, vyzerá presne ako zahodenie firewallom, pretože dopyt jednoducho nikdy nedostane odpoveď.

Ak priamy dopyt odpovedá zvnútra siete, ale nie cez tunel, resolver je v poriadku a cesta medzi dvoma bodmi nie. Tento výsledok presúva vyšetrovanie na trasy, preposielanie a pravidlá prístupu namiesto profilu klienta.

Tunel neprenáša menný priestor

Pakety prechádzajú; mená nie. Každej strane treba povedať, ktorý menný priestor patrí druhej, a to je samostatný objekt, ktorý vlastní ten, kto drží zónu. Zvyčajným tvarom je preposielanie pre jeden menný priestor, namierené na resolver dostupný cez tunel.

V praxi každý smer potrebuje vlastné pravidlo, pretože strana, ktorá vlastní zónu, musí dopyt poslať ďalej. Oba smery vyžadujú, aby zdroj dopytu bol smerovaný a povolený, a odpovedajúca strana musí vracať odpovede cez tunel, nie smerom na internet. Držte preposielanie úzke, aby na spojení závisel iba privátny menný priestor. Posielanie každého dopytu cez neho premení malú závislosť na úplný výpadok v okamihu, keď tunel padne.

Prejdite hranice v poradí

Otestujte resolver nainštalovaný na aktívnom spojení, potom priamy dopyt na tento resolver, potom ten istý dopyt z druhej strany a nakoniec aplikáciu používajúcu ten istý názov. Každý krok izoluje jednu hranicu, takže zlyhanie povie, kam sa pozrieť, namiesto začínania vyšetrovania odznova. Odpoveď, ktorá funguje, kým aplikácia zlyháva, ukazuje na dôveru certifikátu alebo politiku API, nie na DNS. Tie poruchy sú skutočné a žiadna zmena resolvera ich neopraví.

Zapíšte, ktorý krok zlyhal. Ten jediný riadok je to, čo ďalší človek potrebuje, a jeho zapísanie trvá desať sekúnd.

Držte reťaz tam, kde ju ďalší človek nájde

Zaznamenajte pretlačený resolver, pravidlo preposielania, povolený zdroj dopytov a odpovedajúci koncový bod na jednom mieste. Keď privátne meno znova zlyhá, záznam ukáže, či sa tunel posunul, adresa resolvera zmenila alebo bolo pravidlo zúžené. Bez toho každý incident začína od nuly a končí rovnakými tromi dohadmi.

Držte záznam dosť krátky, aby zostal presný: štyri riadky, dátum a meno toho, kto vlastní každú časť. Zastaraný záznam je horší ako žiadny, pretože vyzerá autoritatívne, kým je nesprávny.