WireGuard stjoert gjin DNS: in privee BIND-sône betsjinje

De hânskot draacht kaaien en tastiene IP's, nea in resolver. Hjir is in útwurke privee BIND 9-sône plus it kliïntbelied per keppeling dat har resolvje lit.

Jo hawwe WireGuard oprjochte, de tunnel lit ferkear troch, en de ynterne namme resolvet noch hieltyd net. De folgjende stap is meastentiids in DNS-ynstelling sykje yn 'e WireGuard-konfiguraasje, as koe in peer in resolver trochdrukke lykas guon oare VPN's dogge. Dat kin net. De hânskot draacht kaaien, interface-adressen en tastiene IP's, en hat gjin fjild foar DNS-tsjinners of sikedomeinen. Resolverbelied wennet op 'e kliïnt, en dêr heart de ferbettering.

De tunnel en de resolver binne aparte kontrakten

WireGuard is mei opsetsin lyts. It ferpleatst pakketten foar de adressen dy't jo opjaan en autentisearret peers; alles boppe dy laach is jo eigen ûntwerp. OpenVPN kin in dhcp-option DNS trochdrukke om't syn kontrâlekanaal konfiguraasje draacht, en dat ferskil stroffelet minsken dy't tusken de twa bewege.

In wurkjende tunnel seit dus neat oer nammeresolúsje. De kliïnt kin in perfekte rûte nei 10.90.0.1 hawwe en dochs syn fragen nei in iepenbiere resolver stjoere, en dêrom liket it symptoom as “de VPN hat DNS brutsen”, wylst DNS nea nei de VPN wiisde.

Betsjinje de sône sûnder in rekursive resolver te wurden

De tsjinnerkant is in lytse autoritative sône, gjin algemiene resolver. Yn dit foarbyld is de gateway 10.90.0.1, binne de kliïnten 10.90.0.0/24, en antwurdet de applikaasje dy't jo oanbelanget op 10.60.0.20.

Foegje dizze ynstellingen gear yn it besteande options-blok ynstee fan in twadde te meitsjen:

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

Ferwerkje dan de sône en har bestân:

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

Falidearje foar it werladen, want in syntaksflater by it werladen hellet de hiele tsjinner del foar elke sône dy't er betsjinnet:

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

Iepenje UDP en TCP 53 allinnich op 'e VPN-interface. In privee autoriteit op 'e iepenbiere interface publisearje noeget sawol fragen as telling út, en allow-transfer moat ticht bliuwe, útsein as in sekundêre it wier nedich hat.

Rjochtsje de kliïnt dêrop, per keppeling

Nim oan dat NetworkManager de ferbining hat en dat systemd-resolved de resolver is. Lês earst it besteande belied, benammen in eventueel woartelrûte-domein, want in ~.-ynskriuwing sil boppe dat wat jo tafoegje sille gean.

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

De tilde is it wichtige teken. It markearret it domein as allinnich-rûte: nammen ûnder corp.example gean nei de DNS-tsjinner fan dizze keppeling, en it domein wurdt net taheakke as efterheaksel foar it sykjen fan koarte nammen. Sûnder dat begjint it typen fan portal portal.corp.example te resolvjen, wat handich foar jo en ferrassend foar alle oaren is. Hâld de tilde binnen de oanhellingstekens, want ien sûnder oanhellingstekens is in shell-útwreiding dy't wachtet om nei jo thúsmap te wizen.

Pas de wiziging ta fia de behearder dy't de interface hat, en ferbynje dan de ferbining opnij. Start gjin twadde wg-quick-eksimplaar foar deselde interface; twa eigners sille fjochtsje oer rûtes en ien fan harren sil winne op it minste momint.

Falidearje it paad foar de namme

Freegje de namme by de kliïnt op en befêstigje sawol it antwurd as de tsjinner dy't it makke hat:

resolvectl query portal.corp.example

As dat 10.60.0.20 werombringt, is it DNS-kontrakt klear. As it ferrint, kontrolearje dan earst de rûte nei 10.90.0.1, dan de firewall-regel, dan allow-query op 'e tsjinner. Nammresolúsjeflaters yn dizze opset binne hast altyd berikberens of in ACL, net it sônebestân. Wurkje fan de kliïnt nei bûten, want de tsjinner kin jo net sizze wêrom't in fraach nea oankaam.

Tink deroan dat de applikaasje noch hieltyd syn eigen rûte en syn eigen tsjinstfergunning nedich hat. In resolvet namme dy't nei in ûnberikber adres wiist, is in oare flater yn deselde klean.

Wat noch hieltyd net automatysk is

Applikaasjes mei har eigen resolverlogika negearje de systeemresolver folslein, en gjin hoemannichte nmcli feroaret dat. Ynstallaasjes dy't DNSSEC falidearje hawwe in eksplisyt ûntwerp fan fertrouwensanker foar de privee sône nedich; it antwurd is gjin algemiene opdracht om falidaasje út te skeakeljen. Test mei deselde kliïntsoftware dy't jo brûkers draaie, net mei in helpmiddel dat tafallich de systeemresolver brûkt. It gat tusken dy beide is it hiele flaterrapport.

Fleatsen kinne dit kliïntbelied automatisearje fia harren foarsjenningenssysteem, mar it belied bliuwt in apart objekt mei in eigner. De BIND 9-referinsje behannelet de hark- en fraachkontrôles hjirboppe brûkt, en it is it juste plak om gedrach foar jo ynstalleare ferzje te befêstigjen.

Folgjende stap: foegje de ferheging fan it searjenûmer fan 'e sône en de kontrôle-opdrachten ta oan jo feroaringsproseduere, sadat in recordbewurking net kontrolearre produksje berikke kin.

Relatearre artikelen