OpenVPN DNS šliuze: dnsmasq ir užkardos apimtis

Paleiskite dnsmasq tunelio adresu, leiskite DNS tik iš klientų telkinio, nustumkite sprendiklį, tada išbandykite tiesiogines užklausas ir pačios programos paiešką.

Tunelio klientai pasiekia šliuzą, o šliuzas pasiekia vidinį sprendiklį, todėl DNS turėtų veikti. Bet neveikia, nes tai du skirtingi leidimai, o veikianti DNS paslauga yra trečias dalykas. Klausytojas turi egzistuoti adresu, kurį pasiekia klientai, užkarda turi leisti užklausas į tą adresą, o klientui turi būti pasakyta, kad jis jį naudotų. Tunelio atidarymas abiem kryptimis pirmus du išsprendžia atsitiktinai, o trečią palieka nebaigtą.

Klausytojas yra vietinė paslauga su dviem kryptimis

Įeinant klientas siunčia užklausą į šliuzo tunelio adresą 53 prievadu. Išeinant demonas persiunčia tą užklausą savo sukonfigūruotam aukštutiniam srautui. Abi pusės turi veikti, ir jos nepavyksta skirtingais būdais.

Kliento praneštas skirtasis laikas ir šliuze matomas skirtasis laikas nėra tas pats gedimas.

Susiekite tunelio adresą, o ne kiekvieną adresą

Šiam darbui skirta dnsmasq kopija turi turėti aiškų klausymosi adresą, susiejimo režimą, kuris pakelia tunelio pasirodymą po paleidimo, ir vieną aiškų aukštutinį srautą. Tai mažiausia versija, kurią naudoju:

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

bind-dynamic susieja atskirus adresus ir susitvarko, kai tun0 pasirodo vėliau, o tai svarbu pagrindiniame kompiuteryje, kuriame VPN paslauga paleidžiama iš naujo. loopback išvardijimas palaiko vietinius įrankius veikiančius nepridedant viešo klausytojo. no-resolv neleidžia demonui paveldėti aukštutinių srautų iš pagrindinio kompiuterio sprendiklio konfigūracijos, o no-hosts neleidžia šiai kopijai skelbti šliuzo hosts failo. Nė viena iš šių parinkčių niekam nesuteikia leidimo užklausti paslaugos.

Patikrinkite, ar nėra jau esamo klausytojo 53 prievadu prieš paleisdami antrą demoną, ir naudokite distribucijos konfigūracijos savininką, o ne paklydusį failą netinkamame kataloge.

Leiskite DNS įvestį, o ne tunelio tranzitą

Užkardos taisyklės, kurios tai leidžia, yra vietinės įvesties taisyklės, apribotos tunelio sąsaja, klientų telkiniu, šliuzo adresu ir 53 prievadu. Dviejų taisyklių, po vieną protokolui, pakanka:

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 veikia per TCP taip pat kaip per UDP, todėl taisyklė tik UDP palieka didelius atsakymus nepavykstančius taip, kad atrodo periodiškai. Tai ufw route leidimai, ir jie neturi tapti plačiu leidimu tun0. Tvarka svarbi ne mažiau už turinį: ankstesnė taisyklė, kuri atmeta visą įvestį iš tun0, vis tiek laimi, o leidimo pridėjimas po galutinio atmetimo nieko nesukuria.

Jei šliuzo DNS dabar yra dizaino dalis, sąmoningai peržiūrėkite tą ankstesnę politiką ir užrašykite kodėl.

Aukštutinio srauto pusė yra atskiras kelias

Užklausos palieka šliuzą iš jo paties adreso link aukštutinio sprendiklio, todėl šliuzo maršrutas ir išvesties politika to sprendiklio atžvilgiu turi leisti mainus. Tai kita taisyklė nei ta, kuri įleidžia klientus pas klausytoją, ir ji nepavyksta su kitu simptomu.

Nepridėkite neriboto tunelio išėjimo, kad atsakymai veiktų; sekami atsakymai to nereikalauja.

Nustumkite parinktį, tada patikrinkite perdavimą

Serveris gali paskelbti sprendiklį klientams nustumta parinktimi. Tai parinktis, o ne nurodymas, kurio operacinė sistema privalo paisyti:

push "dhcp-option DNS 10.90.0.1"

Linux komandinės eilutės klientui gali prireikti savo ryšio tvarkyklės sprendiklio integracijos, o valdomam įrenginiui gali prireikti atnaujinto valdymo profilio. Prisijungę patvirtinkite aktyvų sprendiklį kliente, o ne manykite, kad nustūmimas pritaikytas. Kai du mechanizmai vienu metu bando nustatyti DNS, gaunate lenktynes, kurios pasireiškia mirksinčiu sprendimu.

Tikslas yra vienas kliento sprendiklio konfigūracijos savininkas, ir nustūmimas paprastai yra tas savininkas tik tada, kai kliento platforma sutinka.

Išbandykite tai, ką tikrai sukūrėte

Užklauskite vieną privatų visiškai kvalifikuotą vardą ir vieną leistiną išorinį vardą tiesiogiai šliuzo tunelio adresu, per UDP ir TCP. Tada pakartokite įprastu programos paieškos keliu.

Jei tiesioginės užklausos veikia, o programa vis tiek nepavyksta, gedimas yra perdavime, o ne serveryje:

  • Klientas niekada nepritaikė nustumtos parinkties.
  • Vėliau buvo nustatytas kitas sprendiklis ir laimėjo lenktynes.
  • Programa naudoja savo sprendiklio biblioteką arba podėlyje saugomą atsakymą.

Užbaikite patvirtindami, kad šaltinis už patvirtinto VPN kelio ribų apskritai negali naudotis klausytoju. Sėkmingas sprendimas nesuteikia teisės į grąžintą adresą, todėl laikykite šiuos du klausimus atskirai.

Susiję straipsniai