NXDOMAIN cez VPN neznamená výpadok tunela

Je lákavé čítať jeden neúspešný dopyt ako dôkaz, že sa tunel zrútil, najmä keď názov pred desiatimi minútami fungoval. Odpoveď hovorí niečo iné. NXDOMAIN je dokončená DNS transakcia, v ktorej prekladač uviedol, že dopytovaný názov neexistuje; pokazený tunel zvyčajne produkuje ticho, vypršanie času alebo pokus o preklad proti nesprávnemu serveru. Verzia argumentu bez wiresharku je jeden dopyt, jeden odpovedajúci a jeden kód odpovede, a táto trojica stojí za zaznamenanie pred akýmikoľvek zmenami konfigurácie.

Čo odpoveď vlastne dokazuje

DNS oddeľuje výsledky, ktoré klienti často zlievajú do jedného zlyhania. Neexistujúci názov vytvára negatívnu odpoveď s kódom NXDOMAIN, zatiaľ čo názov, ktorý existuje, ale nemá záznam požadovaného typu, vytvára úspešnú odpoveď s prázdnou sekciou odpovedí. Oboje vyzerá pre aplikáciu ako nič užitočné a len jedno z toho znamená, že názov je nesprávny.

Tento rozdiel rozhoduje, kam oprava patrí. Chýbajúci záznam AAAA na hostiteľovi, ktorý má záznam A, nie je chýbajúci hostiteľ, a opätovné vydanie certifikátu alebo prestavba tunela pri jeho prenasledovaní plytvá jediným dostupným vodítkom. Rozdiel tiež určuje podobu pokračovania: problém pomenovania sa opravuje v zóne a problém typu sa opravuje požiadaním o správny záznam alebo prijatím toho, že rodina adries jednoducho chýba.

Mýtus: chýbajúce súkromné meno znamená, že tunel zlyhal

Mýtus prežíva, pretože tieto dve udalosti tak často prichádzajú spolu. Klient sa pripojí k VPN, operačný systém si ponechá prekladač, ktorému už dôveroval, a interné meno, ktoré teraz potrebuje, sa pýta servera, ktorý o súkromnej zóne nikdy nepočul. Ten server odpovedá čestne a negatívne. Tunel nesie paket; odpoveď sa jednoducho týka priestoru názvov, ktorý odpovedajúci neobsluhuje.

Usporiadania split-horizon to robia rutinou: rovnaký názov zóny existuje verejne aj interne s rôznym obsahom a súkromné záznamy pozná len interný prekladač. Získať negatívnu odpoveď, ktorá vyzerá autoritatívne, je preto dôkaz o tom, ktorý prekladač odpovedal, a nie dôkaz o stave rozhrania.

Výsledok rozhodujú dva detaily konfigurácie. Tunel musí pretlačiť alebo vybrať interný prekladač a klient musí toto vybratie použiť na dopytovaný názov. Pravidlo pre jednotlivú doménu, ktoré pomenuje suffix mierne odlišný od záznamu, ktorý ste napísali, pošle dopyt verejnou cestou a odpoveď bude správna a nepoužiteľná.

Pýtajte sa správneho prekladača so správnym menom

Zaznamenajte odpovedajúceho, kým zaznamenáte verdikt. Dopyt, ktorý neukazuje, ktorý server odpovedal, nedokáže rozlíšiť problém politiky od problému priestoru názvov a oba majú nesúvisiace opravy.

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

Prvé dva riadky ukazujú, čo miestny prekladač rozhodol a koho by sa pýtal. Dopyt +search reprodukuje to, čo aplikácia robí, keď pridá vyhľadávací suffix, čo je často skutočný dopyt a nie ten napísaný do diagnostického nástroja. Posledný riadok sa pýta interného servera priamo, s obídením klientskej politiky; ak to uspeje, zatiaľ čo obyčajný dopyt zlyháva, zóna je v poriadku a smerovanie dopytov nie.

Negatívne kešovanie vysvetľuje oneskorenie po oprave

Negatívne odpovede sa zámerne kešujú a RFC 2308 opisuje, ako sa životnosť negatívnej keše odvodzuje od záznamu autority zóny. Oprava záznamu alebo pravidla prekladača preto nezaručuje okamžitú zmenu na klientovi a opakovanie dopytu, ktorý stále vracia kešovanú odpoveď, nepreukazuje nič nové. Len iný odpovedajúci, iný názov alebo vyčistená keš dávajú čerstvé dôkazy.

Vyčistite miestnu keš a potom zopakujte ten istý dopyt proti tomu istému odpovedajúcemu. Na systémoch s miestnou službou prekladača je to jeden príkaz; na iných je to reštart služby alebo platformový nástroj a konkrétny nástroj je menej dôležitý než následné zopakovanie identického testu.

Oddeľte meno od cesty

Akonáhle sa názov preloží na očakávanú súkromnú adresu, DNS je ako téma u konca a ďalšou otázkou sa stáva cesta aplikácie. Hostiteľ, ktorý odpovedá na dopyty, ale odmieta spojenie, má iný problém, a pokračovanie v ladení prekladačov po správnej odpovedi je spôsob, akým incident získa tri nesúvisiace zmeny. Porovnajte preloženú adresu s tou, na ktorej služba skutočne načúva, kým predpokladáte, že sa obe zhodujú.

Uchovajte záznam: dopyt, odpovedajúceho, kód a preloženú adresu. Tento záznam tiež robí neskoršiu správu overiteľnou a je rozdielom medzi diagnózou a príbehom o tuneli, ktorý sa zdal pomalý.