OpenVPN-DNS på gatewayen: dnsmasq plus firewallens omfang

Kør dnsmasq på tunneladressen, tillad kun DNS fra klientpuljen, skub resolverserveren ud, og test derefter direkte forespørgsler og appens egen opslag.

Klienter på tunnelen kan nå gatewayen, og gatewayen kan nå den interne resolver, så DNS burde virke. Det gør den ikke, fordi det er to forskellige tilladelser, og en fungerende DNS-tjeneste er en tredje ting. Lytteren skal findes på en adresse, klienterne kan nå, firewallen skal tillade forespørgsler til den adresse, og klienten skal have besked om at bruge den. At åbne tunnelen i begge retninger løser de to første ved et tilfælde og lader den tredje være uafsluttet.

Lytteren er en lokal tjeneste med to retninger

Indgående sender en klient en forespørgsel til gatewayens tunneladresse på port 53. Udgående videresender dæmonen den forespørgsel til sin konfigurerede opstrøms server. Begge halvdele skal virke, og de fejler på forskellige måder.

En timeout, som klienten rapporterer, og en timeout, som ses på gatewayen, er ikke samme fejl.

Bind tunneladressen, ikke alle adresser

En dedikeret dnsmasq-instans til denne opgave har brug for en eksplicit lytteadresse, en bindtilstand, der tåler, at tunnelen dukker op efter start, og én klar opstrøms server. Dette er den mindste version, jeg bruger:

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 adresser og håndterer, at tun0 dukker op senere, hvilket betyder noget på en vært, hvor VPN-tjenesten genstarter. At liste loopback holder lokale værktøjer kørende uden at tilføje en offentlig lytter. no-resolv forhindrer, at dæmonen arver opstrøms servere fra værtens resolverkonfiguration, og no-hosts forhindrer, at denne instans offentliggør gatewayens hosts-fil. Ingen af disse valgmuligheder giver nogen tilladelse til at forespørge tjenesten.

Tjek for en eksisterende lytter på port 53 før du starter en anden dæmon, og brug distributionens konfigurationsejer i stedet for en løsrevet fil i den forkerte mappe.

Tillad DNS-input, ikke tunnelgennemgang

De firewallregler, der får dette til at virke, er lokale inputregler afgrænset til tunnelinterfacet, klientpuljen, gatewayadressen og port 53. To regler, én for hver protokol, 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 kører over TCP såvel som UDP, så en regel kun for UDP lader store svar fejle på en måde, der virker periodisk. Dette er ikke ufw route tilladelser, og de må ikke blive en bred tilladelse på tun0. Rækkefølgen betyder lige så meget som indholdet: en tidligere regel, der dropper al input fra tun0 vinder stadig, og at tilføje en tilladelse under et terminalt drop skaber intet.

Hvis gateway-DNS nu er en del af designet, skal du med vilje revidere den tidligere politik og notere hvorfor.

Opstrømshalvdelen er en separat vej

Forespørgsler forlader gatewayen fra dens egen adresse mod den opstrøms resolver, så gatewayens rute og udgående politik mod den resolver skal tillade udvekslingen. Det er en anden regel end den, der lader klienter nå lytteren, og den fejler med et andet symptom.

Tilføj ikke ubegrænset tunneloutput for at få svar til at virke; sporede svar har ikke brug for det.

Skub valgmuligheden ud, og tjek derefter overdragelsen

Serveren kan annoncere resolveren til klienter med en skubbet valgmulighed. Det er en valgmulighed, ikke en instruktion, som styresystemet skal adlyde:

push "dhcp-option DNS 10.90.0.1"

En Linux-kommandolinjeklient kan have brug for sin forbindelsesstyrings resolverintegration, og en administreret enhed kan have brug for en opdateret administrationsprofil. Bekræft den aktive resolver på klienten efter forbindelse i stedet for at antage, at skubbet blev anvendt. Når to mekanismer begge prøver at sætte DNS, får du et kapløb, der viser sig som flagrende opløsning.

Målet er én ejer af klientens resolverkonfiguration, og skubbet er normalt kun den ejer, når klientplatformen er enig.

Test det, du faktisk har bygget

Forespørg ét privat fuldt kvalificeret navn og ét tilladt eksternt navn direkte mod tunneladressen, over både UDP og TCP. Gentag derefter gennem applikationens almindelige opslagsvej.

Hvis de direkte forespørgsler virker, og applikationen stadig fejler, ligger fejlen i overdragelsen og ikke på serveren:

  • Klienten anvendte aldrig den skubbede valgmulighed.
  • En anden resolver blev sat senere og vandt kapløbet.
  • Applikationen bruger sit eget resolverbibliotek eller et cachelagret svar.

Slut af med at bekræfte, at en kilde uden for den godkendte VPN-vej slet ikke kan bruge lytteren. Vellykket opløsning autoriserer ikke den adresse, den returnerede, så hold de to spørgsmål adskilt.

Relaterede artikler