WireGuard ei työnnä DNS-palvelinta: yksityisen BIND-vyöhykkeen tarjoaminen

Kättely kuljettaa avaimet ja sallitut IP-osoitteet, ei koskaan resolveria. Tässä valmis yksityinen BIND 9 -vyöhyke sekä linkkikohtainen asiakaskäytäntö, joka saa sen ratkeamaan.

Olet nostanut WireGuardin, tunneli kuljettaa liikennettä, eikä sisäinen nimi silti ratkea. Seuraava askel on yleensä etsiä DNS-asetusta WireGuardin kokoonpanosta, ikään kuin vertaisvertais voisi työntää resolverin kuten jotkin muut VPN:t tekevät. Se ei voi. Kättely kuljettaa avaimet, rajapintaosoitteet ja sallitut IP-osoitteet, eikä siinä ole kenttää DNS-palvelimille tai hakutoimialueille. Resolver-käytäntö elää asiakkaassa, ja sinne korjaus kuuluu.

Tunneli ja resolveri ovat erilliset sopimukset

WireGuard on tarkoituksella pieni. Se siirtää paketteja luettelemillesi osoitteille ja todentaa vertaiset; kaikki tuon kerroksen yläpuolella on sinun suunnittelusi. OpenVPN voi työntää dhcp-option DNS, koska sen ohjauskanava kuljettaa kokoonpanoa, ja tuo ero kompastuttaa kahden välillä liikkuvia.

Toimiva tunneli ei siis kerro nimien ratkaisusta mitään. Asiakkaalla voi olla täydellinen reitti osoitteeseen 10.90.0.1 ja se voi silti lähettää kyselynsä julkiselle resolverille, ja siksi oire näyttää siltä kuin “VPN rikkoi DNS:n”, vaikka DNS:tä ei koskaan osoitettu VPN:ään.

Tarjoa vyöhykettä tulematta rekursiiviseksi resolveriksi

Palvelinpuoli on pieni autoritatiivinen vyöhyke, ei yleinen resolveri. Tässä esimerkissä yhdyskäytävä on 10.90.0.1, asiakkaat ovat 10.90.0.0/24 ja sovellus, josta välität, vastaa osoitteessa 10.60.0.20.

Sulauta nämä asetukset olemassa olevaan options-lohkoon sen sijaan, että loisit toisen:

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;
};

Julista sitten vyöhyke ja sen tiedosto:

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

Validoi ennen uudelleenlatausta, sillä syntaksivirhe latauksen aikana kaataa koko palvelimen jokaiselta vyöhykkeeltä, jota se tarjoaa:

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

Avaa UDP ja TCP 53 vain VPN-rajapinnassa. Yksityisen auktoriteetin julkaiseminen julkisessa rajapinnassa kutsuu sekä kyselyitä että luettelointia, ja allow-transfer kannattaa pitää suljettuna, ellei toissijainen todella tarvitse sitä.

Osoita asiakas siihen, linkki kerrallaan

Oleta, että NetworkManager omistaa yhteyden ja että systemd-resolved on resolveri. Lue ensin olemassa oleva käytäntö, erityisesti mahdollinen juurireititystoimialue, sillä ~.-merkintä ohittaa sen, mitä olet lisäämässä.

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

Tilde on tärkeä merkki. Se merkitsee toimialueen vain-reitiksi: corp.example-alueen nimet menevät tämän linkin DNS-palvelimelle, eikä toimialuetta lisätä lyhytnimien hakuliitteeksi. Ilman sitä portal-kirjoittaminen alkaa ratkaista portal.corp.example, mikä on kätevää sinulle ja yllättävää kaikille muille. Pidä tilde lainausmerkkien sisällä, sillä ilman lainausmerkkejä se on komentotulkin laajennus, joka odottaa osoittavansa kotihakemistoosi.

Käytä muutos rajapinnan omistavan hallinnan kautta ja yhdistä sitten yhteys uudelleen. Älä käynnistä toista wg-quick-instanssia samalle rajapinnalle; kaksi omistajaa riitelee reiteistä ja toinen heistä voittaa huonoimmalla hetkellä.

Vahvista polku ennen nimeä

Kysy nimi asiakkaalta ja vahvista sekä vastaus että palvelin, joka sen tuotti:

resolvectl query portal.corp.example

Jos se palauttaa 10.60.0.20, DNS-sopimus on täytetty. Jos se aikakatkaistaan, tarkista ensin reitti osoitteeseen 10.90.0.1, sitten palomuurisääntö ja sitten allow-query palvelimella. Nimien ratkaisun epäonnistumiset tässä kokoonpanossa ovat lähes aina tavoitettavuus tai ACL, eivät vyöhyketiedosto. Työskentele asiakkaasta ulospäin, sillä palvelin ei voi kertoa sinulle, miksi kysely ei koskaan saapunut.

Muista, että sovellus tarvitsee edelleen oman reittinsä ja oman palvelulupansa. Ratkennut nimi, joka osoittaa saavuttamattomaan osoitteeseen, on eri vika samoissa vaatteissa.

Mikä ei vieläkään ole automaattista

Sovellukset, joilla on oma resolver-logiikka, jättävät järjestelmän resolverin kokonaan huomiotta, eikä mikään määrä nmcli muuta sitä. Käyttöönotot, jotka validoivat DNSSEC:iä, tarvitsevat eksplisiittisen luottamusankkurin suunnittelun yksityiselle vyöhykkeelle; vastaus ei ole yleinen ohje kytkeä validointi pois päältä. Testaa samalla asiakasohjelmistolla, jota käyttäjäsi ajavat, älä työkalulla, joka sattuu käyttämään järjestelmän resolveria. Näiden kahden välinen ero on koko vikaraportti.

Laivueet voivat automatisoida tämän asiakaskäytännön provisiointijärjestelmänsä kautta, mutta käytäntö pysyy erillisenä objektina, jolla on omistaja. BIND 9 -viite kattaa yllä käytetyt kuuntelu- ja kyselyohjaimet, ja se on oikea paikka vahvistaa käyttäytyminen asennetulle versiollesi.

Seuraava askel: lisää vyöhykkeen sarjanumeron korotus ja tarkistuskomennot muutospatukseesi, jotta tietueen muokkaus ei voi päästä tuotantoon tarkistamatta.

Aiheeseen liittyvät artikkelit