OpenVPN-DNS på gatewayen: dnsmasq och brandväggens omfattning

Kör dnsmasq på tunneladressen, tillåt DNS endast från klientpoolen, skjut ut resolvern och testa sedan direkta frågor och appens egen uppslagning.

Klienter på tunneln når gatewayen, och gatewayen når den interna resolvern, så DNS borde fungera. Det gör det inte, eftersom det är två olika behörigheter och en fungerande DNS-tjänst är en tredje sak. Lyssnaren måste finnas på en adress som klienterna når, brandväggen måste tillåta frågor till den adressen, och klienten måste få veta att den används. Att öppna tunneln i båda riktningarna löser de två första av en slump och lämnar den tredje ogjord.

Lyssnaren är en lokal tjänst med två riktningar

Inkommande skickar en klient en fråga till gatewayens tunneladress på port 53. Utgående vidarebefordrar daemonen frågan till sin konfigurerade uppströms server. Båda halvorna måste fungera, och de misslyckas på olika sätt.

En timeout som klienten rapporterar och en timeout som syns på gatewayen är inte samma fel.

Bind tunneladressen, inte varje adress

En dedikerad dnsmasq-instans för det här jobbet behöver en uttrycklig lyssnaradress, ett bindningsläge som tål att tunneln dyker upp efter start, och en tydlig uppströms server. Det här är den minsta versionen jag använder:

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 enskilda adresserna och hanterar när tun0 dyker upp senare, vilket spelar roll på en värd där VPN-tjänsten startar om. Att lista loopback håller lokala verktyg igång utan att lägga till en offentlig lyssnare. no-resolv hindrar daemonen från att ärva uppströms servrar från värdens resolverkonfiguration, och no-hosts hindrar den här instansen från att publicera gatewayens hosts-fil. Ingen av de valen ger någon behörighet att fråga tjänsten.

Kontrollera om det finns en befintlig lyssnare på port 53 innan du startar en andra daemon, och använd distributionens konfigurationsägare i stället för en förirrad fil i fel katalog.

Tillåt DNS-ingång, inte tunneltrafik

Brandväggsreglerna som gör detta möjligt är lokala ingångsregler begränsade till tunnelgränssnittet, klientpoolen, gatewayadressen och port 53. Två regler, en per protokoll, räcker:

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 över TCP liksom UDP, så en regel bara för UDP låter stora svar misslyckas på ett sätt som verkar intermittent. Detta är inte ufw route behörigheter, och de får inte bli ett brett tillstånd på tun0. Ordningen spelar lika stor roll som innehållet: en tidigare regel som släpper all ingång från tun0 vinner fortfarande, och att lägga till ett tillstånd under en terminal drop skapar ingenting.

Om gateway-DNS nu är en del av designen, se över den tidigare policyn med avsikt och notera varför.

Uppström halvan är en egen väg

Frågor lämnar gatewayen från dess egen adress mot uppströms resolvern, så gatewayens rutt och utgångspolicyn mot den resolvern måste tillåta utbytet. Det är en annan regel än den som släpper klienterna till lyssnaren, och den misslyckas med ett annat symptom.

Lägg inte till obegränsad tunnelutgång för att få svaren att fungera; spårade svar behöver det inte.

Skjut ut alternativet och kontrollera sedan överlämningen

Servern kan annonsera resolvern till klienterna med ett utskjutet alternativ. Det är ett alternativ, inte en instruktion som operativsystemet måste lyda:

push "dhcp-option DNS 10.90.0.1"

En Linux-kommandorads klient kan behöva sin anslutningshanterares resolverintegration, och en hanterad enhet kan behöva en uppdaterad hanteringsprofil. Bekräfta den aktiva resolvern på klienten efter anslutning i stället för att anta att utskjutningen tillämpades. När två mekanismer försöker sätta DNS samtidigt får du en kapplöpning som visar sig som flimrande uppslagning.

Målet är en ägare av klientens resolverkonfiguration, och utskjutningen är den ägaren vanligtvis bara när klientplattformen håller med.

Testa det du faktiskt byggde

Fråga efter ett privat fullt kvalificerat namn och ett tillåtet externt namn direkt mot tunneladressen, över både UDP och TCP. Upprepa sedan via applikationens vanliga sökväg.

Om de direkta frågorna fungerar och applikationen fortfarande misslyckas, ligger felet i överlämningen och inte på servern:

  • Klienten tillämpade aldrig det utskjutna alternativet.
  • En annan resolver sattes senare och vann kapplöpningen.
  • Applikationen använder sitt eget resolverbibliotek eller ett cachelagrat svar.

Avsluta med att bekräfta att en källa utanför den godkända VPN-vägen inte kan använda lyssnaren alls. En lyckad uppslagning ger inte behörighet till adressen den returnerade, så håll de två frågorna åtskilda.

Relaterade artiklar