OpenVPN DNS na prehodu: dnsmasq in obseg požarnega zidu

Zaženite dnsmasq na naslovu tunela, dovolite DNS le iz nabora odjemalcev, potisnite razreševalnik in nato preizkusite neposredne poizvedbe ter lastno iskanje aplikacije.

Odjemalci v tunelu dosežejo prehod, prehod pa doseže notranji razreševalnik, zato bi DNS moral delovati. Ne deluje, ker sta to dve različni dovoljenji in delujoča storitev DNS je tretja stvar. Poslušalec mora obstajati na naslovu, ki ga odjemalci dosežejo, požarni zid mora dovoliti poizvedbe na ta naslov, odjemalcu pa je treba povedati, naj ga uporablja. Odprtje tunela v obe smeri prvi dve po naključju reši in tretje pusti nedokončano.

Poslušalec je lokalna storitev z dvema smerema

Navznoter odjemalec pošlje poizvedbo na naslov tunela prehoda na vratih 53. Navzven demon posreduje to poizvedbo svojemu nastavljenemu nadrejenemu strežniku. Obe polovici morata delovati in odpovedujeta na različne načine.

Časovna omejitev, ki jo sporoči odjemalec, in časovna omejitev, vidna na prehodu, nista ista okvara.

Vežite naslov tunela, ne vsakega naslova

Namenski primer dnsmasq za to delo potrebuje izrecen naslov poslušanja, način vezave, ki prenese pojav tunela po zagonu, in en jasen nadrejeni strežnik. To je najmanjša različica, ki jo uporabljam:

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

bind-dynamic veže posamezne naslove in se spopada s tem, ko se tun0 pojavi pozneje, kar je pomembno na gostitelju, kjer se storitev VPN znova zažene. Naštevanje loopback ohranja lokalna orodja delujoča, ne da bi dodalo javnega poslušalca. no-resolv prepreči, da bi demon podedoval nadrejene strežnike iz konfiguracije razreševalnika gostitelja, in no-hosts prepreči temu primeru objavo datoteke hosts prehoda. Nobena od teh možnosti nikomur ne daje dovoljenja za poizvedovanje storitve.

Preverite, ali obstaja obstoječi poslušalec na vratih 53 preden zaženete drugega demona, in uporabite lastnika konfiguracije distribucije namesto zablodele datoteke v napačni mapi.

Dovolite vstop DNS, ne tranzita tunela

Pravila požarnega zidu, ki to omogočajo, so pravila lokalnega vstopa, omejena na vmesnik tunela, nabor odjemalcev, naslov prehoda in vrata 53. Dve pravili, eno na protokol, zadostujeta:

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 teče po TCP kot po UDP, zato pravilo samo za UDP pušča velike odgovore v odpovedi na način, ki deluje občasno. To niso ufw route dovoljenja in ne smejo postati široko dovoljenje na tun0. Vrstni red je enako pomemben kot vsebina: prejšnje pravilo, ki zavrže ves vstop z tun0, še vedno zmaga, dodajanje dovoljenja pod končno zavrženje pa ne ustvari ničesar.

Če je DNS prehoda zdaj del zasnove, to prejšnjo politiko namerno preglejte in zapišite zakaj.

Nadrejena polovica je ločena pot

Poizvedbe zapustijo prehod z njegovega lastnega naslova proti nadrejenemu razreševalniku, zato morata usmerjanje prehoda in izhodna politika do tega razreševalnika dovoliti izmenjavo. To je drugo pravilo od tistega, ki spusti odjemalce do poslušalca, in odpove z drugim simptomom.

Ne dodajajte neomejenega izhoda tunela, da bi odgovori delovali; sledeni odgovori tega ne potrebujejo.

Potisnite možnost in nato preverite predajo

Strežnik lahko razreševalnik razglasi odjemalcem s potisnjeno možnostjo. To je možnost, ne navodilo, ki ga mora operacijski sistem ubogati:

push "dhcp-option DNS 10.90.0.1"

Odjemalec Linuxa iz ukazne vrstice bo morda potreboval vključitev razreševalnika v svojem upravitelju povezav, upravljana naprava pa bo morda potrebovala posodobljen upravljalski profil. Po povezavi potrdite dejaven razreševalnik na odjemalcu, namesto da bi domnevali, da je bil potisk uporabljen. Ko dva mehanizma hkrati poskušata nastaviti DNS, nastane tekma, ki se kaže kot utripajoče razreševanje.

Cilj je en lastnik konfiguracije razreševalnika odjemalca, potisk pa je ta lastnik običajno le takrat, ko se platforma odjemalca strinja.

Preizkusite, kar ste zares zgradili

Poizvedite po enem zasebnem popolnoma kvalificiranem imenu in enem dovoljenem zunanjem imenu neposredno proti naslovu tunela, po UDP in TCP. Nato ponovite po običajni poti iskanja aplikacije.

Če neposredne poizvedbe delujejo in aplikacija še vedno odpove, je okvara v predaji in ne na strežniku:

  • Odjemalec ni nikoli uporabil potisnjene možnosti.
  • Pozneje je bil nastavljen drug razreševalnik in je dobil tekmo.
  • Aplikacija uporablja lastno knjižnico razreševalnika ali shranjen odgovor.

Končajte s potrditvijo, da vir zunaj odobrene poti VPN poslušalca sploh ne more uporabljati. Uspešno razreševanje ne pooblasti naslova, ki ga je vrnilo, zato ti dve vprašanji držite ločeno.

Sorodni članki