OpenVPN DNS lüüsil: dnsmasq ja tulemüüri ulatus

Käivitage dnsmasq tunneliaadressil, lubage DNS ainult kliendikogumist, lükake resolver välja ja seejärel testige otseseid päringuid ning rakenduse enda otsingut.

Tunnelis olevad kliendid pääsevad lüüsile ja lüüs pääseb sisemisele resolverile, seega peaks DNS töötama. See ei tööta, sest need on kaks erinevat luba ja töötav DNS-teenus on kolmas asi. Kuulaja peab eksisteerima aadressil, kuhu kliendid pääsevad, tulemüür peab lubama päringuid sellele aadressile ja kliendile tuleb öelda, et ta seda kasutaks. Tunneli avamine mõlemas suunas lahendab kaks esimest juhuslikult ja jätab kolmanda tegemata.

Kuulaja on kahe suunaga kohalik teenus

Sissepoole saadab klient päringu lüüsi tunneliaadressile pordil 53. Väljapoole edastab deemon selle päringu oma konfigureeritud ülesvoolu serverile. Mõlemad pooled peavad töötama ja need ebaõnnestuvad erineval viisil.

Kliendi teatatud ajalõpp ja lüüsil nähtav ajalõpp ei ole sama rike.

Siduge tunneliaadress, mitte iga aadress

Selle töö jaoks mõeldud eraldi dnsmasq eksemplar vajab selget kuulamisadressi, sidumisrežiimi, mis talub tunneli ilmumist pärast käivitamist, ja üht selget ülesvoolu serverit. See on väikseim versioon, mida kasutan:

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

bind-dynamic seob üksikud aadressid ja tuleb toime, kui tun0 ilmub hiljem, mis on oluline hostil, kus VPN-teenus taaskäivitub. Loopbacki loetlemine hoiab kohalikud tööriistad töös ilma avalikku kuulajat lisamata. no-resolv takistab deemonil hosti resolveri konfiguratsioonist ülesvoolu servereid pärida, ja no-hosts takistab sellel eksemplaril lüüsi hosts-faili avaldada. Ükski neist valikutest ei anna kellelegi luba teenust pärida.

Kontrollige, kas portil 53 on juba olemasolev kuulaja enne teise deemonit käivitamist, ja kasutage distributsiooni konfiguratsiooni omanikku, mitte vales kataloogis ekslevat faili.

Lubage DNS-i sisend, mitte tunneli läbikäik

Tulemüüri reeglid, mis seda võimaldavad, on kohaliku sisendi reeglid, mis on piiratud tunneli liidese, kliendikogumi, lüüsi aadressi ja pordiga 53. Kahest reeglist, üks protokolli kohta, piisab:

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 töötab TCP kui ka UDP kaudu, seega ainult UDP reegel jätab suured vastused ebaõnnestuma viisil, mis tundub katkendlik. Need ei ole ufw route load, ja need ei tohi saada laiaks looks aadressil tun0. Järjekord loeb sama palju kui sisu: varasem reegel, mis viskab kogu sisendi aadressilt tun0 võidab endiselt, ja loa lisamine lõpliku viskamise alla ei loo midagi.

Kui lüüsi DNS on nüüd disaini osa, vaadake see varasem poliitika meelega üle ja kirjutage üles, miks.

Ülesvoolu pool on eraldi tee

Päringud lahkuvad lüüsist oma aadressilt ülesvoolu resolveri suunas, seega peavad lüüsi marsruut ja väljundpoliitika selle resolveri suunas vahetust lubama. See on erinev reegel sellest, mis laseb klientidel kuulajani jõuda, ja see ebaõnnestub teistsuguse sümptomiga.

Ärge lisage piiramatut tunneli väljundit, et vastused töötaksid; jälgitud vastused ei vaja seda.

Lükake valik välja ja kontrollige seejärel üleandmist

Server saab resolveri klientidele väljalükatud valikuga teada anda. See on valik, mitte käsk, mida operatsioonisüsteem peab kuulama:

push "dhcp-option DNS 10.90.0.1"

Käsurealt kasutatav Linuxi klient võib vajada oma ühendusehalduri resolveri integratsiooni ja hallatav seade võib vajada uuendatud haldusprofiili. Pärast ühendamist kinnitage kliendil aktiivne resolver, selle asemel et eeldada, et väljalükkamine rakendus. Kui kaks mehhanismi üritavad korraga DNS-i seada, tekib võidujooks, mis näib vilkuva lahendusena.

Eesmärk on üks omanik kliendi resolveri konfiguratsioonile ja väljalükkamine on tavaliselt see omanik ainult siis, kui kliendi platvorm nõustub.

Testige seda, mille tegelikult ehitasite

Pärige üht privaatset täielikult kvalifitseeritud nime ja üht lubatud välist nime otse tunneliaadressi vastu, nii UDP kui TCP kaudu. Seejärel korrake rakenduse tavalisel otsinguteel.

Kui otsesed päringud töötavad ja rakendus ikka ebaõnnestub, on rike üleandmises, mitte serveris:

  • Klient ei rakendanud väljalükatud valikut kunagi.
  • Hiljem seati teine resolver ja see võitis võidujooksu.
  • Rakendus kasutab oma resolveri teeki või vahemällu salvestatud vastust.

Lõpetage kinnitusega, et heakskiidetud VPN-teest väljaspool olev allikas ei saa kuulajat üldse kasutada. Edukas lahendus ei anna õigust tagastatud aadressile, seega hoidke need kaks küsimust lahus.

Seotud artiklid