OpenVPN-DNS op de gateway: dnsmasq plus omfang fan de firewall

Rin dnsmasq op it tunneladres, stean DNS allinnich fan 'e kliïntpúl ta, stjûr de resolver út, en test dan direkte fragen en it eigen sykjen fan 'e app.

Kliïnten op 'e tunnel kinne de gateway berikke, en de gateway kin de ynterne resolver berikke, dus DNS soe wurkje moatte. It wurket net, want dat binne twa ferskillende tastimmingen en in wurkjende DNS-tsjinst is in tredde ding. De harker moat bestean op in adres dat de kliïnten berikke kinne, de firewall moat fragen nei dat adres tastean, en de kliïnt moat ferteld wurde dat er it brûkt. De tunnel yn beide rjochtingen iepenje lost de earste twa by tafal op en lit de tredde ûndien.

De harker is in lokale tsjinst mei twa rjochtingen

Yngeand stjoert in kliïnt in fraach nei it tunneladres fan 'e gateway op poarte 53. Utgeand stjoert de daemon dy fraach troch nei syn konfigurearre boppestream. Beide helten moatte wurkje, en se mislearje op ferskillende manieren.

In timeout dy't de kliïnt rapportearret en in timeout dy't op 'e gateway te sjen is, binne net deselde flater.

Bynt it tunneladres, net elk adres

In aparte dnsmasq-eksimplaar foar dizze taak hat in eksplisyt harkadres nedich, in bynmodus dy't it ferskinen fan 'e tunnel nei de start ferneart, en ien dúdlike boppestream. Dit is de lytste ferzje dy't ik brûk:

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

bind-dynamic bynt de yndividuele adressen en kin oerwei as tun0 letter ferskynt, wat fan belang is op in host dêr't de VPN-tsjinst op 'e nij start. loopback listje hâldt lokale ark oan 'e gong sûnder in iepenbiere harker ta te foegjen. no-resolv foarkomt dat de daemon boppestreams erft fan 'e resolverkonfiguraasje fan 'e host, en no-hosts foarkomt dat dit eksimplaar it hosts-bestân fan 'e gateway publisearret. Gjin fan dy opsjes jout immen tastimming om de tsjinst te befreegjen.

Kontrolearje op in besteande harker op poarte 53 foardat jo in twadde daemon starte, en brûk de konfiguraasje-eigner fan 'e distribúsje ynstee fan in ferdwaald bestân yn 'e ferkearde map.

Stean DNS-ynfier ta, net tunnelferkear

De firewallregels dy't dit wurkje litte, binne lokale ynfierregels beheind ta de tunnelinterface, de kliïntpúl, it gatewayadres en poarte 53. Twa regels, ien foar elk protokol, binne genôch:

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 rint oer TCP likegoed as oer UDP, dus in regel allinnich foar UDP lit grutte antwirden mislearje op in manier dy't ûnregelmjittich liket. Dit binne gjin ufw route tastimmingen, en se meie gjin brede tastimming wurde op tun0. De folchoarder is like wichtich as de ynhâld: in eardere regel dy't alle ynfier fan tun0 weilern docht, wint noch altyd, en in tastimming ûnder in terminale wegering taheakje skept neat.

As gateway-DNS no part fan it ûntwerp is, besjoch dat eardere belied dan bewust opnij en lis fêst wêrom.

De boppestreamhelte is in apart paad

Fragen ferlitte de gateway fan syn eigen adres nei de boppestreamresolver, dus de rûte fan 'e gateway en it útfierbelied nei dy resolver moatte de útwikseling tastean. Dat is in oare regel as dy't kliïnten by de harker komme lit, en it mislearret mei in oar symptoom.

Foegje gjin ûnbeheinde tunnelútfier ta om antwirden wurkje te litten; folge antwirden hawwe it net nedich.

Stjûr de opsje út, en kontrolearje dan de oerdracht

De tsjinner kin de resolver oan kliïnten oankundigje mei in útsjûrde opsje. Dat is in opsje, net in opdracht dêr't it bestjoeringssysteem oan foldwaan moat:

push "dhcp-option DNS 10.90.0.1"

In Linux-kommando rigel kliïnt kin de resolveryntegraasje fan syn ferbiningbehearder nedich hawwe, en in beheard apparaat kin in bywurke behearprofyl nedich hawwe. Befêstigje de aktive resolver op 'e kliïnt nei it ferbinen ynstee fan oan te nimmen dat de útsjûrde opsje tapast is. As twa meganismen tagelyk DNS besykje te setten, krije jo in race dy't him foar as flodderjende oplossing.

Ien eigner foar de resolverkonfiguraasje fan 'e kliïnt is it doel, en de útsjûrde opsje is dy eigner meastentiids allinnich as it kliïntplatfoarm it iens is.

Test wat jo echt boud hawwe

Freegje ien privee folslein kwalifisearre namme en ien tastien eksterne namme direkt tsjin it tunneladres, oer UDP en TCP. Werhelje it dan fia it gewoane sykpaad fan 'e applikaasje.

As de direkte fragen wurkje en de applikaasje noch mislearret, sit de flater yn 'e oerdracht en net op 'e tsjinner:

  • De kliïnt hat de útsjûrde opsje nea tapast.
  • In oare resolver waard letter set en wûn de race.
  • De applikaasje brûkt syn eigen resolverbibleteek of in bewarre antwird.

Einigje mei te befêstigjen dat in boarne bûten it goedkarde VPN-paad de harker hielendal net brûke kin. In slagge oplossing jout gjin tastimming foar it adres dat it weromjoech, dus hâld dy twa fragen skieden.

Relatearre artikelen