OpenVPN-DNS på gatewayen: dnsmasq og brannmurens omfang

Kjør dnsmasq på tunneladressen, tillat DNS bare fra klientbassenget, dytt ut resolverserveren, og test deretter direkte spørringer og appens egen oppslag.

Klienter på tunnelen når gatewayen, og gatewayen når den interne resolveren, så DNS burde virke. Det virker ikke, fordi det er to forskjellige tillatelser, og en fungerende DNS-tjeneste er en tredje ting. Lytteren må finnes på en adresse klientene når, brannmuren må tillate spørringer til den adressen, og klienten må få beskjed om å bruke den. Å åpne tunnelen i begge retninger løser de to første ved en tilfeldighet og lar den tredje stå uferdig.

Lytteren er en lokal tjeneste med to retninger

Innover sender en klient en spørring til gatewayens tunneladresse på port 53. Utover videresender daemonen den spørringen til sin konfigurerte oppstrøms server. Begge halvdeler må virke, og de feiler på forskjellige måter.

En tidsavbrudd som klienten rapporterer, og en tidsavbrudd som ses på gatewayen, er ikke samme feil.

Bind tunneladressen, ikke hver adresse

En dedikert dnsmasq-instans for denne jobben trenger en eksplisitt lyttingsadresse, en bindingsmodus som tåler at tunnelen dukker opp etter start, og én klar oppstrøms server. Dette er den minste versjonen jeg bruker:

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic binder de enkelte adressene og håndterer når tun0 dukker opp senere, noe som betyr noe på en vert der VPN-tjenesten starter på nytt. Å liste loopback holder lokale verktøy i gang uten å legge til en offentlig lytter. no-resolv hindrer daemonen i å arve oppstrøms servere fra vertens resolverkonfigurasjon, og no-hosts hindrer denne instansen i å publisere gatewayens hosts-fil. Ingen av disse valgene gir noen tillatelse til å spørre tjenesten.

Sjekk om det finnes en eksisterende lytter på port 53 før du starter en annen daemon, og bruk distribusjonens konfigurasjonseier i stedet for en bortkommen fil i feil katalog.

Tillat DNS-inndata, ikke tunnelgjennomgang

Brannmurreglene som får dette til å virke, er lokale inndatarregler begrenset til tunellgrensesnittet, klientbassenget, gatewayadressen og port 53. To regler, én per protokoll, er nok:

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

DNS går over TCP så vel som UDP, så en regel bare for UDP lar store svar feile på en måte som virker periodisk. Dette er ikke ufw route tillatelser, og de må ikke bli en bred tillatelse på tun0. Rekkefølgen betyr like mye som innholdet: en tidligere regel som slipper all inndata fra tun0 vinner fortsatt, og å legge til en tillatelse under en terminal dropp skaper ingenting.

Hvis gateway-DNS nå er en del av designet, revider den tidligere policyen med vilje og noter hvorfor.

Oppstrømshalvdelen er en egen vei

Spørringer forlater gatewayen fra dens egen adresse mot oppstrøms resolveren, så gatewayens rute og utgangspolicy mot den resolveren må tillate utvekslingen. Det er en annen regel enn den som slipper klientene til lytteren, og den feiler med et annet symptom.

Ikke legg til ubegrenset tunnelutgang for å få svarene til å virke; sporede svar trenger det ikke.

Dytt ut valget, og sjekk deretter overleveringen

Serveren kan annonsere resolveren til klientene med et utdyttet valg. Det er et valg, ikke en instruks operativsystemet må adlyde:

push "dhcp-option DNS 10.90.0.1"

En Linux-kommandolinjeklient kan trenge tilkoblingsbehandlingens resolverintegrasjon, og en administrert enhet kan trenge en oppdatert administrasjonsprofil. Bekreft den aktive resolveren på klienten etter tilkobling i stedet for å anta at utdyttingen ble brukt. Når to mekanismer prøver å sette DNS samtidig, får du et kappløp som vises som flagrende oppslag.

Målet er én eier av klientens resolverkonfigurasjon, og utdyttingen er vanligvis den eieren bare når klientplattformen er enig.

Test det du faktisk bygde

Spør ett privat fullt kvalifisert navn og ett tillatt eksternt navn direkte mot tunneladressen, over både UDP og TCP. Gjenta deretter gjennom applikasjonens vanlige oppslagsvei.

Hvis de direkte spørringene virker og applikasjonen fortsatt feiler, ligger feilen i overleveringen og ikke på serveren:

  • Klienten brukte aldri det utdyttede valget.
  • En annen resolver ble satt senere og vant kappløpet.
  • Applikasjonen bruker sitt eget resolverbibliotek eller et hurtiglagret svar.

Avslutt med å bekrefte at en kilde utenfor den godkjente VPN-veien ikke kan bruke lytteren i det hele tatt. Vellykket oppslag autoriserer ikke adressen den returnerte, så hold disse to spørsmålene fra hverandre.

Relaterte artikler