OpenVPN-DNS op die gateway: dnsmasq plus die firewall se omvang

Laat dnsmasq op die tonneladres loop, keur DNS net uit die kliëntpoel goed, stoot die oplosser, en toets dan direkte navrae en die app se eie opsoek.

Kliënte op die tonnel kan die gateway bereik, en die gateway kan die interne oplosser bereik, so DNS behoort te werk. Dit werk nie, want dit is twee verskillende regte en 'n werkende DNS-diens is 'n derde ding. Die luisteraar moet op 'n adres bestaan wat die kliënte kan bereik, die firewall moet navrae na daardie adres toelaat, en die kliënt moet ingelig word om dit te gebruik. Om die tonnel in beide rigtings oop te maak, los die eerste twee per ongeluk op en laat die derde ongedaan.

Die luisteraar is 'n plaaslike diens met twee rigtings

Inkomend stuur 'n kliënt 'n navraag na die gateway se tonneladres op poort 53. Uitgaande stuur die daemon daardie navraag na sy gekonfigureerde opstroom. Albei helftes moet werk, en hulle faal op verskillende maniere.

'n Time-out wat die kliënt rapporteer, en 'n time-out wat by die gateway gesien word, is nie dieselfde fout nie.

Koppel die tonneladres, nie elke adres nie

'n Toegewyde dnsmasq-instansie vir hierdie taak het 'n eksplisiete luisteradres nodig, 'n koppelmodus wat die tonnel verdra wat ná die opstart verskyn, en een duidelike opstroom. Dit is die kleinste weergawe wat ek gebruik:

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

bind-dynamic koppel die afsonderlike adresse en hanteer die geval wanneer tun0 later verskyn, wat saak maak op 'n gasheer waar die VPN-diens herbegin. Om loopback te lys hou plaaslike gereedskap werkend sonder om 'n openbare luisteraar by te voeg. no-resolv verhoed dat die daemon opstrome van die gasheer se oplosserkonfigurasie erwe, en no-hosts verhoed dat hierdie instansie die gateway se hosts-lêer publiseer. Nie een van daardie opsies gee aan iemand toestemming om die diens te bevraag nie.

Kyk vir 'n bestaande luisteraar op poort 53 voordat jy 'n tweede daemon begin, en gebruik die verspreiding se konfigurasie-eienaar eerder as 'n rondloper lêer in die verkeerde gids.

Laat DNS-invoer toe, nie tonneldeurvoer nie

Die firewallreëls wat dit laat werk, is plaaslike invoerreëls wat tot die tonnelkoppelvlak, die kliëntpoel, die gatewayadres en poort 53 beperk is. Twee reëls, een per protokol, is genoeg:

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 loop oor TCP sowel as UDP, so 'n reël wat net UDP dek, laat groot antwoorde misluk op 'n manier wat wisselvallig lyk. Dit is nie ufw route magtigings nie, en hulle mag nie 'n breë toelating op tun0 word nie. Orde maak net soveel saak soos inhoud: 'n vroeëre reël wat alle invoer van tun0 weggooi, wen steeds, en om 'n toelating onder 'n terminale weggooi te voeg, skep niks nie.

As DNS by die gateway nou deel van die ontwerp is, hersien daardie vroeëre beleid doelbewus en teken aan waarom.

Die opstroomhelfte is 'n aparte pad

Navrae verlaat die gateway vanaf sy eie adres na die opstroomoplosser, so die gateway se roete en uitvoerbeleid teenoor daardie oplosser moet die uitruiling toelaat. Dit is 'n ander reël as die een wat kliënte na die luisteraar laat kom, en dit faal met 'n ander simptoom.

Moenie onbeperkte tonneluitvoer byvoeg om antwoorde te laat werk nie; gevolgde antwoorde het dit nie nodig nie.

Stoot die opsie, en kyk dan na die oorhandiging

Die bediener kan die oplosser aan kliënte adverteer met 'n gestote opsie. Dit is 'n opsie, nie 'n opdrag wat die bedryfstelsel moet gehoorsaam nie:

push "dhcp-option DNS 10.90.0.1"

'n Linux-opdragreëlkliënt het dalk sy verbindingsbestuurder se oplosserintegrasie nodig, en 'n bestuurde toestel het dalk sy bestuursprofiel nodig wat bygewerk word. Bevestig die aktiewe oplosser op die kliënt ná verbinding in plaas daarvan om aan te neem die stoot is toegepas. Wanneer twee meganismes albei DNS probeer stel, kry jy 'n wedloop wat as wisselende resolusie voorkom.

Een eienaar vir die kliënt se oplosserkonfigurasie is die doel, en die stoot is gewoonlik daardie eienaar net wanneer die kliëntplatform saamstem.

Toets wat jy werklik gebou het

Bevraag een private volledig gekwalifiseerde naam en een toegelate eksterne naam direk teen die tonneladres, oor beide UDP en TCP. Herhaal dit dan deur die toepassing se gewone opsoekpad.

As die direkte navrae werk en die toepassing steeds faal, is die fout in die oorhandiging eerder as op die bediener:

  • Die kliënt het nooit die gestote opsie toegepas nie.
  • 'n Ander oplosser is later gestel en het die wedloop gewen.
  • Die toepassing gebruik sy eie oplosserbiblioteek of 'n gekasde antwoord.

Sluit af deur te bevestig dat 'n bron buite die goedgekeurde VPN-pad die luisteraar glad nie kan gebruik nie. Suksesvolle resolusie magtig nie die adres wat dit teruggegee het nie, so hou daardie twee vrae apart.

Verwante artikels