OpenVPN-DNS på gatewayen: dnsmasq og omfanget til brannmuren

Køyr dnsmasq på tunneladressa, tillat DNS berre frå klientbassenget, dytt ut resolvaren, og test deretter direkte spørjingar og appen sitt eige oppslag.

Klientar på tunnelen når gatewayen, og gatewayen når den interne resolvaren, så DNS burde verke. Det gjer det ikkje, fordi det er to ulike løyve, og ein DNS-teneste som verkar er ein tredje ting. Lyttaren må finnast på ei adresse klientane når, brannmuren må tillate spørjingar til den adressa, og klienten må få beskjed om å bruke henne. Å opne tunnelen i båe retningar løyser dei to fyrste ved eit tilfelle og lèt den tredje stå uferdig.

Lyttaren er ei lokal teneste med to retningar

Innover sender ein klient ei spørjing til tunneladressa til gatewayen på port 53. Ut over sender daemonen den spørjinga vidare til oppstraums-tenaren sin. Båe halvdelar må verke, og dei feilar på ulike måtar.

Ein tidsavbrot som klienten rapporterer, og eit tidsavbrot som ein ser på gatewayen, er ikkje same feil.

Bind tunneladressa, ikkje kvar adresse

Ein eigen dnsmasq-instans for denne jobben treng ei eksplisitt lyttaradresse, ein bindemåte som toler at tunnelen dukkar opp etter start, og éin klår oppstraums-tenar. Dette er den minste versjonen eg brukar:

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

bind-dynamic bind dei einskilde adressene og handterer når tun0 dukkar opp seinare, noko som tel på ein vert der VPN-tenesta startar på nytt. Å liste loopback held lokale verkty i gang utan å leggje til ein offentleg lyttar. no-resolv hindrar daemonen i å arve oppstraums-tenarar frå resolveroppsettet til verten, og no-hosts hindrar denne instansen i å publisere hosts-fila til gatewayen. Ingen av desse vala gir nokon løyve til å spørje tenesta.

Sjekk om det finst ein eksisterande lyttar på port 53 før du startar ein annan daemon, og bruk konfigurasjonseigaren til distribusjonen i staden for ei bortkomen fil i feil mappe.

Tillat DNS-inn-data, ikkje tunnelgjennomgang

Brannmurreglane som gjer dette mogleg, er lokale inn-datarreglar avgrensa til tunellgrensesnittet, klientbassenget, gatewayadressa og port 53. To reglar, éin 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å ein regel berre for UDP lèt store svar feile på ein måte som verkar periodisk. Dette er ikkje ufw route løyve, og dei må ikkje bli eit breitt løyve på tun0. Rekkjefølgja tel like mykje som innhaldet: ein tidlegare regel som slepp all inn-data frå tun0 vinn framleis, og å leggje til eit løyve under eit terminalt dropp skapar ingenting.

Viss gateway-DNS no er ein del av designet, revider den tidlegare policyen med vilje og noter kvifor.

Oppstraums-halvdelen er ein eigen veg

Spørjingar forlèt gatewayen frå si eiga adresse mot oppstraums-resolvaren, så ruta til gatewayen og utgangspolicyen mot den resolvaren må tillate utvekslinga. Det er ein annan regel enn den som slepp klientane til lyttaren, og han feilar med eit anna symptom.

Ikkje legg til ubegrensa tunnelutgang for å få svara til å verke; spora svar treng det ikkje.

Dytta ut valet, og sjekk deretter overleveringa

Tenaren kan annonsere resolvaren til klientane med eit utdytta val. Det er eit val, ikkje ein instruks operativsystemet må lyda:

push "dhcp-option DNS 10.90.0.1"

Ein Linux-kommandolinjeklient kan trenge resolverintegreringa til tilkoplingshandsamaren sin, og ein administrert eining kan trenge ein oppdatert administrasjonsprofil. Stadfest den aktive resolvaren på klienten etter tilkopling i staden for å gå ut frå at utdyttinga vart brukt. Når to mekanismar prøver å setje DNS samstundes, får du eit kappløp som viser seg som flimrande oppslag.

Målet er éin eigar av resolveroppsettet til klienten, og utdyttinga er vanlegvis den eigaren berre når klientplattforma er samd.

Test det du faktisk bygde

Spør eitt privat fullt kvalifisert namn og eitt tillate eksternt namn direkte mot tunneladressa, over både UDP og TCP. Gjenta deretter gjennom den vanlege oppslagsvegen til applikasjonen.

Viss dei direkte spørjingane verkar og applikasjonen framleis feilar, ligg feilen i overleveringa og ikkje på tenaren:

  • Klienten brukte aldri det utdytta valet.
  • Ein annan resolver vart sett seinare og vann kappløpet.
  • Applikasjonen brukar sitt eige resolverbibliotek eller eit hurtiglagra svar.

Avslutt med å stadfeste at ei kjelde utanfor den godkjende VPN-vegen ikkje kan bruke lyttaren i det heile. Vellykka oppslag autoriserer ikkje adressa han returnerte, så hald desse to spørsmåla frå kvarandre.

Relaterte artiklar