A VPN-doméned a dnsmasq-ban nem zónaátvitel

A vállalati zónát keresed az ügyfél dnsmasq-konfigurációjában, nem találod, és arra jutsz, hogy a VPN nem küldte le a doménjét. Amit leküldtek, az útválasztási utalás, nem zóna. Az ügyfél rögzíti a domént és azt a resolvert, amelynek válaszolnia kell rá, a felügyelt back-end pedig feltételes továbbítássá alakítja. A rossz helyen való keresés magabiztos és teljesen hamis diagnózist ad.

Amit az ügyfél elfogadott, nem az, amit az átjáró felkínált

Az átjáró felkínálhat egy resolvert, egy domént és az ahhoz a resolverhez szükséges útvonalat, és az ügyfél mindhármat vagy egyiket sem fogadhatja el. Egy importált profil, egy segédscript vagy a leküldött beállításokat figyelmen kívül hagyó szabály üresen hagyhatja az elfogadott halmazt, miközben a kiszolgálói oldal helyesnek tűnik. Az ügyfél rögzített állapotából indulj ki, ne a kiszolgáló konfigurációjából, mert a resolver valójában ezt az állapotot kapja. Ha az elfogadott domén hiányzik, semmi további nem számít. Mielőtt bármilyen gyorsítótárat vizsgálnál, ellenőrizd a kapcsolat DNS-tulajdonságait.

Ez a különbség magyarázza a legtöbb jelentést egy doménről, amely soha nem érkezett meg. Felkínálták, és nem alkalmazták.

Kétféle doménbejegyzés

A kapcsolat hordozhat közönséges keresési doméneket és csak útválasztási doméneket, és a második fajta tildével kezdődik. A keresési domén egyaránt irányítja a lekérdezéseket és lehetővé teszi a rövid nevek kiterjesztését, ami munkaállomáson kényelmes, kiszolgálón pedig meglepő. A csak útválasztási domén azt mondja, hogy az adott utótag lekérdezéseit meghatározott kiszolgálókra kell küldeni anélkül, hogy megváltoztatná a rövid nevek feloldásának módját. Ugyanazt a domént mindkét módon leírni nem feleslegesség, mert a két bejegyzés különböző feladatot lát el.

Privát névtérhez általában a csak útválasztási forma az, amit szeretnél. A vállalati utótagot a vállalati resolver felé tartja, minden mást pedig békén hagy.

A localhost a resolv.conf-ban nem hiba

Ha helyi gyorsítótárazó resolver van használatban, a rendszerfájl a loopback-címre mutat, és semmi másra. Ez a bejegyzés a helyi figyelőt azonosítja, nem azokat a felsőbb kiszolgálókat, amelyeket a kezelő adott neki. A vállalati cím jogosan hiányzik a fájlból.

Ennek a bejegyzésnek nyilvános resolverrel való helyettesítése a klasszikus hibás javítás. Helyreállítja a nyilvános névfeloldást, és ugyanabban a szerkesztésben eldobja a feltételes szabályt.

Ne keverd össze a back-endeket

A felügyelt dnsmasq-példány és a rendszerresolver különböző programok, különböző konfigurációval és különböző állapotnézetekkel. Az egyik állapotparancsa semmi hasznosat nem mond a másikról.

Állapítsd meg, melyik back-endet használja a kezelő, majd olvasd el annak a back-endnek a generált konfigurációját, ne egy disztribúció-szintű fájlt, amely véletlenül létezik. A kezelő a saját példánykonfigurációját írja, és egyedi beállításokat támogat ehhez a példányhoz, ezért egy független globális fájl szerkesztése semmit nem változtat, és hatás nélküli változásnak tűnik. Egy második daemon indítása az 53-as porton rosszabb, mint haszontalan, mert most két program vitatkozik azon, kié a port. Először állapítsd meg a tulajdonost, aztán szerkessz ott, ahol az a tulajdonos olvas.

A névteret teszteld, ne csak a választ

Kérdezz le egy engedélyezett privát nevet és egy nyilvános kontrollnevet az alkalmazás szokásos útvonalán. A vállalati kiszolgáló elleni közvetlen lekérdezés bizonyítja, hogy a rekord létezik; azt nem bizonyítja, hogy az ügyfél azt a kiszolgálót választotta. A második lekérdezés az, amely a szabályt teszteli.

Ezután ismételd meg újracsatlakozás és leválasztás után. A társításnak a kapcsolat életciklusát kell követnie, és a privát neveknek meg kell szűnniük feloldódni, amikor az alagút eltűnik, ahelyett hogy visszaesnének egy nyilvános resolverre, amely ugyanarra az utótagra válaszol. Ha mégis visszaesnek, szivárgást találtál, ami más hiba, mint a törött keresés. Írd fel, melyik back-end futott, mely domének kerültek alkalmazásra, és mit adott vissza az egyes lekérdezés.