OpenVPN DNS uz vārtejas: dnsmasq un ugunsmūra tvērums

Palaidiet dnsmasq tuneļa adresē, atļaujiet DNS tikai no klientu kopas, nobīdiet atrisinātāju un pēc tam pārbaudiet tiešos vaicājumus un pašas lietotnes meklēšanu.

Tuneļa klienti sasniedz vārteju, un vārteja sasniedz iekšējo atrisinātāju, tāpēc DNS būtu jādarbojas. Taču tas nedarbojas, jo tās ir divas dažādas atļaujas, un strādājošs DNS pakalpojums ir trešā lieta. Klausītājam jāpastāv adresē, kuru sasniedz klienti, ugunsmūrim jāatļauj vaicājumi uz šo adresi, un klientam jāpasaka, ka tas to izmanto. Tuneļa atvēršana abos virzienos pirmos divus atrisina nejauši un atstāj trešo nepabeigtu.

Klausītājs ir vietējs pakalpojums ar diviem virzieniem

Ienākošā virzienā klients sūta vaicājumu uz vārtejas tuneļa adresi portā 53. Izejošā virzienā dēmons pārsūta šo vaicājumu savai konfigurētajai augšupstraumei. Abām pusēm jādarbojas, un tās neizdodas dažādos veidos.

Klienta ziņotais taimauts un vārtejā redzamais taimauts nav viens un tas pats bojājums.

Piesaistiet tuneļa adresi, nevis katru adresi

Šim darbam veltītai dnsmasq kopijai vajadzīga skaidra klausīšanās adrese, piesaistes režīms, kas pieļauj tuneļa parādīšanos pēc palaišanas, un viena skaidra augšupstraume. Šī ir mazākā versija, ko izmantoju:

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

bind-dynamic piesaista atsevišķās adreses un tiek galā, kad tun0 parādās vēlāk, kas ir svarīgi resursdatorā, kur VPN pakalpojums tiek restartēts. loopback uzskaitīšana uztur vietējos rīkus darbībā, nepievienojot publisku klausītāju. no-resolv neļauj dēmonam mantot augšupstraumes no resursdatora atrisinātāja konfigurācijas, un no-hosts neļauj šai kopijai publicēt vārtejas hosts failu. Neviena no šīm opcijām nedod nevienam atļauju vaicāt pakalpojumu.

Pārbaudiet, vai nav jau esoša klausītāja portā 53 pirms otrā dēmona palaišanas, un izmantojiet distribūcijas konfigurācijas īpašnieku, nevis nomaldījušos failu nepareizajā mapē.

Atļaujiet DNS ievadi, nevis tuneļa tranzītu

Ugunsmūra noteikumi, kas to ļauj, ir vietējie ievades noteikumi, kas ierobežoti ar tuneļa saskarni, klientu kopu, vārtejas adresi un portu 53. Ar diviem noteikumiem, pa vienam protokolam, pietiek:

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 darbojas gan pār TCP, gan UDP, tāpēc noteikums tikai UDP atstāj lielas atbildes neizdevušās tādā veidā, kas izskatās periodiski. Tie ufw route atļaujas, un tiem nevajadzētu kļūt par plašu atļauju tun0. Secība ir tikpat svarīga kā saturs: agrāks noteikums, kas izmet visu ievadi no tun0, joprojām uzvar, un atļaujas pievienošana zem galīgās nomešanas neko nerada.

Ja vārtejas DNS tagad ir dizaina daļa, apzināti pārskatiet to agrāko politiku un pierakstiet, kāpēc.

Augšupstraumes puse ir atsevišķs ceļš

Vaicājumi atstāj vārteju no tās pašas adreses pretī augšupstraumes atrisinātājam, tāpēc vārtejas maršrutam un izejošās politikas attiecībā pret šo atrisinātāju jāatļauj apmaiņa. Tas ir cits noteikums nekā tas, kas ļauj klientiem nokļūt pie klausītāja, un tas neizdodas ar citu simptomu.

Nepievienojiet neierobežotu tuneļa izeju, lai atbildes darbotos; izsekotajām atbildēm tas nav vajadzīgs.

Nobīdiet opciju, tad pārbaudiet nodošanu

Serveris var paziņot atrisinātāju klientiem ar nobīdītu opciju. Tā ir opcija, nevis norādījums, kam operētājsistēmai jāpakļaujas:

push "dhcp-option DNS 10.90.0.1"

Linux komandrindas klientam var būt vajadzīga sava savienojumu pārvaldnieka atrisinātāja integrācija, un pārvaldītai ierīcei var būt vajadzīgs atjaunināts pārvaldības profils. Pēc savienojuma apstipriniet aktīvo atrisinātāju klientā, nevis pieņemiet, ka nobīde tika piemērota. Kad divi mehānismi vienlaikus mēģina iestatīt DNS, rodas sacensība, kas izpaužas kā mirgojoša izšķiršana.

Mērķis ir viens klienta atrisinātāja konfigurācijas īpašnieks, un nobīde parasti ir tas īpašnieks tikai tad, kad klienta platforma piekrīt.

Pārbaudiet to, ko patiešām uzbūvējāt

Vaicājiet vienu privātu pilnībā kvalificētu nosaukumu un vienu atļautu ārēju nosaukumu tieši pret tuneļa adresi, gan UDP, gan TCP. Pēc tam atkārtojiet lietotnes parastajā meklēšanas ceļā.

Ja tiešie vaicājumi darbojas un lietotne joprojām neizdodas, bojājums ir nodošanā, nevis serverī:

  • Klients nekad nepiemēroja nobīdīto opciju.
  • Vēlāk tika iestatīts cits atrisinātājs, un tas uzvarēja sacensībā.
  • Lietotne izmanto savu atrisinātāja bibliotēku vai kešatmiņā saglabātu atbildi.

Pabeidziet, apstiprinot, ka avots ārpus apstiprinātā VPN ceļa vispār nevar izmantot klausītāju. Veiksmīga izšķiršana nepiešķir tiesības uz atgriezto adresi, tāpēc turiet šos divus jautājumus atsevišķi.

Saistītie raksti