Peka OpenVPN-klienter mot en Pi-hole-resolver på en annan värd

Att lägga en Pi-hole-adress i en OpenVPN-profil skapar ingen väg till den, ger ingen behörighet att fråga den och garanterar inte att klienten använder den. Med Pi-hole på en separat LAN-maskin måste fyra saker stämma: vägen från klienten, vidarebefordran från gatewayen, returvägen till poolen och mottagningspolicyn på Pi-hole själv. Varje fel ser olika ut i en logg. Att gå igenom dem i den ordningen är snabbare än att åtgärda det sista först. Den vanliga genvägen, att öppna rekursion för varje ursprung, byter ett litet problem mot ett permanent.

Vad det pushade DNS-alternativet gör och inte gör

Servern annonserar en resolver med direktivet nedan, förutsatt att 192.168.50.53 är Pi-hole-värden. Klienten tar emot alternativet och, beroende på plattform och resolverintegration , tillämpar det på tunnelgränssnittet eller ignorerar det till förmån för en lokal stub. Ruttraden spelar lika stor roll som DNS-raden, för en resolver som klienten inte når är ingen resolver alls. Inget av detta syns från serversidan.

server 10.90.0.0 255.255.255.0
push "dhcp-option DNS 192.168.50.53"
push "route 192.168.50.0 255.255.255.0"

Att ta emot ett alternativ är inte samma sak som att använda det. En Linux-klient med en resolverhanterare kan acceptera den pushade servern och skicka bara vissa domäner till den; en klient som sköter DNS själv kan skriva över inställningen helt. Pushade rutter är också begränsade på vissa plattformar, vilket lämnar resolvern onåbar även om alternativet accepterades. Kontrollera på klienten vilken server som svarar, inte på servern vad som skickades.

Alternativet säger inte heller något om serversidan. DNS-trafik måste fortfarande färdas från klienten till gatewayen och från gatewayen till Pi-hole innan något alternativ spelar roll. En saknad rutt och en avvisad fråga ser likadana ut från klienten, så bekräfta vidarebefordran på gatewayen först.

Returvägen från Pi-hole till poolen

Om klientens källadress bevaras svarar Pi-hole till en adress inne i VPN-poolen. Dess egen routingtabell vet förmodligen inget om den poolen, så svaret går till dess standardgateway och försvinner. Frågeloggen visar en begäran utan matchande svar, vilket är lätt att misstolka som ett brandväggsproblem.

Ge LAN-routern en statisk rutt för poolen med OpenVPN-gatewayen som nästa hopp, eller översätt källan på gatewayen innan vidarebefordran till Pi-hole. Den första håller varje klients adresser synliga i Pi-holes frågelogg. Den andra tar bort kravet på returrutt men får varje fråga att se ut som om den kom från gatewayen. Ingen av dem är fel; de svarar på olika frågor.

Om rapportering eller policy per klient spelar roll är den statiska rutten det bättre bytet. Om LANet sköts av någon annan och ingen rutt finns tillgänglig är översättning det pragmatiska alternativet, med förlusten av klientidentitet nedskriven. Anteckna vilket du valde, för varje senare loggfråga beror på det.

Pi-holes lyssnarläge för routade klienter

Rullgardinsmenyn för gränssnittens lyssnarbeteende på inställningssidan under DNS avgör vilka källor Pi-hole svarar. Dess striktaste alternativ accepterar bara klienter på direkt anslutna nätverk; alternativet som tillåter enheter högst ett hopp bort utökar det till subnät bakom en intilliggande router, och det är precis hur en routad VPN-klient ser ut. Paketet anländer visserligen på LAN-gränssnittet, men dess källadress tillhör ett annat subnät. Det är en policyvägran och inte ett routingfel, och skillnaden spelar roll när du läser loggar.

Pi-holes lyssnarguide skiljer lokalt anslutna källor från routade ursprung, och ankomstgränssnittet är inte testet. Välj ett läge som tillåter VPN-poolen utan att tillåta hela internet, och para det med en brandväggsregel som bara accepterar DNS från poolen.

Att öppna rekursion för alla ursprung för att få den första frågan att fungera är den felaktiga reparationen. Det förvandlar en privat resolver till en öppen, och rättelsen är en avgränsad behörighet i stället för en global.

Koppla svaret till frågeloggen

Fråga klienten, kontrollera sedan servern och jämför de två. På en systemd-resolved-klient rapporterar kommandona nedan vilken resolver som producerade ett svar och vilka servrar som är konfigurerade per länk. Använd ett namn som bara Pi-hole känner till, för en direkt fråga till Pi-hole-adressen bevisar nåbarhet och inte konfiguration.

resolvectl query intranet.example.lan
resolvectl dns

Det förväntade svaret namnger 192.168.50.53 som server och returnerar en adress som bara den resolvern skulle känna till. Titta sedan på Pi-holes egen vy: pihole -t följer frågeloggen live, och varje rad bär källadressen. Om källan är klientens tunneladress är poolrutten intakt. Om det är gatewayens LAN-adress är källöversättning i spel och klientens egen adress kommer aldrig att synas.

Om inget alls visas i loggen nådde frågan aldrig Pi-hole och vidarebefordran på gatewayen är nästa sak att kontrollera. Om frågan visas och inget svar kommer tillbaka är returvägen problemet, det vill säga föregående avsnitt. Att dela upp felet så hindrar ett routingfel från att misstas för en brandväggsregel.

Kontrollera gatewayens vidarebefordringsregel

Gatewayen måste vidarebefordra klientens DNS-paket mot Pi-hole, och regeln som gör det är värd att läsa i stället för att antas. Kommandona nedan listar reglerna som rör port 53 med räknare, på en nftables-värd och på en iptables-värd. En regel som finns men visar noll träffar är signalen att trafik kastas innan den översätts.

sudo nft list ruleset | grep -A3 'dport 53'
sudo iptables -t nat -L POSTROUTING -n -v | grep 53

Läs räknarna, inte bara reglerna. En regel som aldrig matchar betyder att paketet lämnar via ett annat gränssnitt, eller att klienten aldrig skickade det. En regel som matchar vid varje fråga betyder att vidarebefordran fungerar och att problemet ligger längre fram på vägen.

Vilket verktyg värden än använder, håll kontrollen snäv: poolen som källa, port 53 som destination och Pi-hole som enda tillåtna mål. En bred vidarebefordringsregel som också tillåter port 80 är ett annat problem som väntar på att hända.