OpenVPN DNS na pristupniku: dnsmasq i obim vatrozida

Pokrenite dnsmasq na adresi tunela, dozvolite DNS samo iz skupa klijenata, gurnite razrješivač, pa testirajte direktne upite i vlastito traženje aplikacije.

Klijenti na tunelu mogu doći do pristupnika, a pristupnik može doći do unutrašnjeg razrješivača, pa bi DNS trebao raditi. Ne radi, jer su to dvije različite dozvole, a ispravna DNS usluga je treća stvar. Slušalac mora postojati na adresi do koje klijenti mogu doći, vatrozid mora dozvoliti upite na tu adresu, a klijentu se mora reći da je koristi. Otvaranje tunela u oba smjera slučajno rješava prva dva i ostavlja treće nedovršenim.

Slušalac je lokalna usluga s dva smjera

Prema unutra, klijent šalje upit na adresu tunela pristupnika na portu 53. Prema van, demon prosljeđuje taj upit svom konfiguriranom uzvodnom serveru. Obje polovine moraju raditi i otkazuju na različite načine.

Istek koji prijavi klijent i istek koji se vidi na pristupniku nisu ista greška.

Vežite adresu tunela, ne svaku adresu

Namjenska instanca dnsmasq-a za ovaj posao treba izričitu adresu slušanja, način vezivanja koji podnosi pojavu tunela nakon pokretanja i jedan jasan uzvodni server. Ovo je najmanja verzija koju koristim:

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 pojedinačne adrese i nosi se s tun0 kada se pojavi kasnije, što je važno na hostu na kojem se VPN usluga ponovo pokreće. Navođenje loopback-a održava lokalne alate u radu bez dodavanja javnog slušaoca. no-resolv sprječava demona da naslijedi uzvodne servere iz konfiguracije razrješivača hosta, a no-hosts sprječava ovu instancu da objavi hosts datoteku pristupnika. Nijedna od tih opcija ne daje nikome dozvolu da upituje uslugu.

Provjerite postoji li postojeći slušalac na portu 53 prije nego pokrenete drugi demon i koristite vlasnika konfiguracije distribucije umjesto zalutale datoteke u pogrešnom direktoriju.

Dozvolite DNS ulaz, ne tranzit tunela

Pravila vatrozida koja ovo omogućavaju su pravila lokalnog ulaza ograničena na sučelje tunela, skup klijenata, adresu pristupnika i port 53. Dva pravila, po jedno za svaki protokol, dovoljna su:

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 radi preko TCP-a kao i preko UDP-a, pa pravilo samo za UDP ostavlja velike odgovore u otkazu na način koji izgleda povremeno. To nisu ufw route dozvole i ne smiju postati široka dozvola na tun0. Redoslijed je važan koliko i sadržaj: ranije pravilo koje odbacuje sav ulaz s tun0 i dalje pobjeđuje, a dodavanje dozvole ispod konačnog odbacivanja ne stvara ništa.

Ako je DNS pristupnika sada dio dizajna, namjerno izmijenite tu raniju politiku i zabilježite zašto.

Uzvodna polovina je odvojen put

Upiti napuštaju pristupnik s vlastite adrese prema uzvodnom razrješivaču, pa rutiranje pristupnika i izlazna politika prema tom razrješivaču moraju dozvoliti razmjenu. To je drugačije pravilo od onog koje pušta klijente do slušaoca i otkazuje s drugačijim simptomom.

Ne dodajte neograničen izlaz tunela da bi odgovori radili; praćeni odgovori to ne trebaju.

Gurnite opciju, pa provjerite predaju

Server može klijentima oglasiti razrješivač gurnutom opcijom. To je opcija, a ne naredba koju operativni sistem mora poslušati:

push "dhcp-option DNS 10.90.0.1"

Linux klijent iz komandne linije može trebati integraciju razrješivača u svom upravitelju veza, a upravljani uređaj može trebati ažuriran profil upravljanja. Potvrdite aktivni razrješivač na klijentu nakon povezivanja umjesto da pretpostavite da je guranje primijenjeno. Kada dva mehanizma istovremeno pokušavaju postaviti DNS, dobijete trku koja izgleda kao treperavo razrješavanje.

Cilj je jedan vlasnik konfiguracije razrješivača klijenta, a guranje je obično taj vlasnik samo kada se platforma klijenta slaže.

Testirajte ono što ste zaista izgradili

Upitajte jedno privatno potpuno kvalificirano ime i jedno dopušteno vanjsko ime direktno prema adresi tunela, preko UDP-a i TCP-a. Zatim to ponovite kroz uobičajeni put traženja aplikacije.

Ako direktni upiti rade, a aplikacija i dalje otkazuje, kvar je u predaji, a ne na serveru:

  • Klijent nikada nije primijenio gurnutu opciju.
  • Drugi razrješivač je postavljen kasnije i pobijedio je u trci.
  • Aplikacija koristi vlastitu biblioteku razrješivača ili keširani odgovor.

Završite potvrdom da izvor izvan odobrene VPN staze uopće ne može koristiti slušaoca. Uspješno razrješavanje ne ovlašćuje adresu koju je vratilo, pa držite ta dva pitanja odvojenim.

Povezani članci