A WireGuard nem küld DNS-t: privát BIND-zóna kiszolgálása

A kézfogás kulcsokat és engedélyezett IP-címeket hordoz, soha nem feloldót. Íme egy kész privát BIND 9 zóna, valamint a kapcsolatonkénti kliensszabály, amely feloldhatóvá teszi.

Felállította a WireGuardot, az alagút átengedi a forgalmat, és a belső név még mindig nem oldódik fel. A következő lépés általában az, hogy DNS-beállítást keres a WireGuard konfigurációjában, mintha egy peer tudna feloldót küldeni, ahogy más VPN-ek teszik. Nem tud. A kézfogás kulcsokat, interfészcímeket és engedélyezett IP-címeket hordoz, és nincs mezője DNS-kiszolgálók vagy keresési tartományok számára. A feloldószabály a kliensen él, és oda tartozik a javítás.

Az alagút és a feloldó külön szerződések

A WireGuard szándékosan kicsi. A felsorolt címekhez továbbítja a csomagokat, és hitelesíti a peer-eket; minden, ami e réteg felett van, az Ön tervezése. OpenVPN tud dhcp-option DNS küldeni, mert a vezérlőcsatornája konfigurációt hordoz, és ez a különbség megbotlik azokon, akik a kettő között mozognak.

Egy működő alagút tehát semmit sem mond a névfeloldásról. A kliensnek lehet tökéletes útvonala a 10.90.0.1 felé, és mégis nyilvános feloldóhoz küldheti a lekérdezéseit, ezért tűnik a tünet olyannak, mintha “a VPN elrontotta a DNS-t”, holott a DNS soha nem a VPN felé mutatott.

Szolgálja ki a zónát anélkül, hogy rekurzív feloldóvá válna

A kiszolgálói oldal egy kis autoritatív zóna, nem általános feloldó. Ebben a példában az átjáró 10.90.0.1, a kliensek 10.90.0.0/24, és az Önt érdeklő alkalmazás a 10.60.0.20 címen válaszol.

Olvassza össze ezeket a beállításokat a meglévő options blokkba, ahelyett hogy másodikat hozna létre:

options {
    listen-on { 127.0.0.1; 10.90.0.1; };
    listen-on-v6 { none; };
    allow-query { 127.0.0.1; 10.90.0.0/24; };
    allow-transfer { none; };
    recursion no;
};

Ezután deklarálja a zónát és a fájlját:

zone "corp.example" {
    type primary;
    file "/etc/bind/db.corp.example";
};
$TTL 300
@ IN SOA ns.corp.example. hostmaster.corp.example. ( 1 3600 600 604800 300 )
@      IN NS ns.corp.example.
ns     IN A  10.90.0.1
portal IN A  10.60.0.20

Érvényesítse újratöltés előtt, mert az újratöltéskor fellépő szintaktikai hiba az egész kiszolgálót leviszi minden zóna számára, amelyet kiszolgál:

named-checkconf
named-checkzone corp.example /etc/bind/db.corp.example

Csak a VPN-interfészen nyissa meg az UDP és TCP 53-at. Ha privát tekintélyt tesz közzé a nyilvános interfészen, az lekérdezéseket és felsorolást is hív, és a allow-transfer maradjon zárva, hacsak egy másodlagosnak valóban nincs rá szüksége.

Irányítsa rá a klienst, kapcsolatonként

Tegyük fel, hogy a kapcsolat a NetworkManageré, a feloldó pedig a systemd-resolved. Először olvassa el a meglévő szabályt, különösen bármely gyökér-útvonalválasztási tartományt, mert a ~. bejegyzés felül fogja múlni azt, amit hozzáadni készül.

nmcli connection modify wg-office +ipv4.dns 10.90.0.1
nmcli connection modify wg-office +ipv4.dns-search '~corp.example'

A tilde a fontos karakter. Csak-útvonalként jelöli meg a tartományt: a corp.example alatti nevek ennek a kapcsolatnak a DNS-kiszolgálójára mennek, és a tartomány nem fűződik hozzá rövidnév-keresési utótagként. Nélküle a portal begépelése elkezdi feloldani a portal.corp.example nevet, ami Önnek kényelmes, mindenki másnak meglepő. A tildét tartsa az idézőjelek között, mert a jegyzet nélküli egy shell-kiterjesztés, amely arra vár, hogy az otthoni könyvtárára mutasson.

Az interfész tulajdonos kezelőjén keresztül alkalmazza a változtatást, majd csatlakoztassa újra a kapcsolatot. Ne indítson második wg-quick példányt ugyanahhoz az interfészhez; két tulajdonos fog háborúzni az útvonalakért, és egyikük a legrosszabb pillanatban nyer.

Az útvonalat ellenőrizze a név előtt

Kérdezze le a nevet a kliensről, és erősítse meg a választ és az azt előállító kiszolgálót is:

resolvectl query portal.corp.example

Ha ez 10.60.0.20-at ad vissza, a DNS-szerződés teljesült. Ha lejár az idő, először a 10.90.0.1 felé vezető útvonalat ellenőrizze, aztán a tűzfal szabályát, majd a allow-query beállítást a kiszolgálón. A névfeloldási hibák ebben az összeállításban szinte mindig elérhetőség vagy ACL, nem a zónafájl. A klienstől kifelé haladjon, mert a kiszolgáló nem tudja megmondani, miért nem érkezett meg soha egy lekérdezés.

Ne feledje, hogy az alkalmazásnak még mindig szüksége van a saját útvonalára és a saját szolgáltatási engedélyére. Egy feloldott név, amely elérhetetlen címre mutat, más hiba ugyanabban a ruhában.

Mi még mindig nem automatikus

A saját feloldói logikával rendelkező alkalmazások teljesen figyelmen kívül hagyják a rendszer feloldóját, és ezen semmilyen mennyiségű nmcli nem változtat. A DNSSEC-et érvényesítő telepítéseknek kifejezett bizalmi horgony-tervre van szükségük a privát zónához; a válasz nem egy általános utasítás az érvényesítés kikapcsolására. Ugyanazzal a kliensszoftverrel teszteljen, amelyet a felhasználói futtatnak, ne olyan eszközzel, amely véletlenül a rendszer feloldóját használja. A kettő közötti rés az egész hibajelentés.

A flották automatizálhatják ezt a kliensszabályt a provisioning rendszerükön keresztül, de a szabály továbbra is külön objektum tulajdonossal. A BIND 9 referencia lefedi a fent használt figyelő- és lekérdezésvezérlőket, és ez a megfelelő hely a viselkedés megerősítésére a telepített verziójához.

Következő lépés: adja hozzá a zóna sorozatszám-növelését és az ellenőrző parancsokat a változási eljárásához, hogy egy rekord szerkesztése ne érhesse el ellenőrizetlenül a produkciót.

Kapcsolódó cikkek