OpenVPN DNS az átjárón: dnsmasq és a tűzfal hatóköre

Futtassa a dnsmasq-t az alagút címén, csak az ügyfélkészletből engedjen DNS-t, tolja ki a feloldót, majd tesztelje a közvetlen lekérdezéseket és az alkalmazás saját keresését.

Az alagúton lévő ügyfelek elérik az átjárót, az átjáró pedig eléri a belső feloldót, tehát a DNS-nek működnie kellene. Mégsem működik, mert ez két különböző engedély, és egy működő DNS-szolgáltatás a harmadik dolog. A figyelőnek olyan címen kell léteznie, amelyet az ügyfelek elérnek, a tűzfalnak engedélyeznie kell a lekérdezéseket erre a címre, és az ügyfélnek meg kell mondani, hogy használja. Az alagút mindkét irányú megnyitása az első kettőt véletlenül megoldja, a harmadikat pedig befejezetlenül hagyja.

A figyelő kétirányú helyi szolgáltatás

Bejövő irányban az ügyfél lekérdezést küld az átjáró alagútcímére az 53-as porton. Kimenő irányban a démon továbbítja a lekérdezést a beállított felsőbb kiszolgálójának. Mindkét félnek működnie kell, és különböző módon hibáznak.

Az ügyfél által jelentett időtúllépés és az átjárón látott időtúllépés nem ugyanaz a hiba.

Az alagút címét kösse, ne minden címet

A feladathoz rendelt dnsmasq-példánynak kifejezett figyelési címre, a start után megjelenő alagutat tűrő kötési módra és egy világos felsőbb kiszolgálóra van szüksége. Ez a legkisebb verzió, amelyet használok:

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

bind-dynamic az egyes címeket köti, és kezeli, amikor tun0 később megjelenik, ami olyan gazdagépen számít, ahol a VPN-szolgáltatás újraindul. A loopback felsorolása nyilvános figyelő hozzáadása nélkül tartja működésben a helyi eszközöket. no-resolv megakadályozza, hogy a démon a gazdagép feloldó-konfigurációjából örököljön felsőbb kiszolgálókat, a no-hosts pedig megakadályozza, hogy ez a példány közzétegye az átjáró hosts fájlját. Egyik lehetőség sem ad senkinek engedélyt a szolgáltatás lekérdezésére.

Ellenőrizze, van-e már meglévő figyelő az 53-as porton mielőtt második démont indít, és a disztribúció konfigurációtulajdonosát használja a rossz könyvtárban kallódó fájl helyett.

DNS-bemenetet engedjen, ne alagút-átjárást

A tűzfalszabályok, amelyek ezt lehetővé teszik, helyi bemeneti szabályok, amelyek az alagút interfészére, az ügyfélkészletre, az átjáró címére és az 53-as portra korlátozódnak. Két szabály, protokollonként egy, elegendő:

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

A DNS UDP mellett TCP fölött is fut, ezért a csak UDP-re vonatkozó szabály a nagy válaszokat szakaszosnak tűnő módon hagyja meghibásodni. Ezek nem ufw route engedélyek, és nem válhatnak széles engedéllyé ezen: tun0. A sorrend ugyanolyan fontos, mint a tartalom: egy korábbi szabály, amely minden bemenetet eldob erről: tun0 továbbra is nyer, és egy engedély hozzáadása egy végső eldobás alá semmit sem hoz létre.

Ha az átjáró DNS-e most a tervezés része, szándékosan vizsgálja felül azt a korábbi szabályzatot, és jegyezze fel, miért.

A felsőbb fél külön útvonal

A lekérdezések az átjárót a saját címéről hagyják el a felsőbb feloldó felé, ezért az átjáró útvonalának és a feloldó felé irányuló kimeneti szabályzatnak engedélyeznie kell a cserét. Ez más szabály, mint amely az ügyfeleket a figyelőhöz engedi, és más tünettel hibázik.

Ne adjon hozzá korlátlan alagút-kimenetet a válaszok működéséhez; a követett válaszoknak nincs rá szükségük.

Tolja ki a beállítást, majd ellenőrizze az átadást

A kiszolgáló kihirdetheti a feloldót az ügyfeleknek egy kitolt beállítással. Ez beállítás, nem olyan utasítás, amelyet az operációs rendszernek be kell tartania:

push "dhcp-option DNS 10.90.0.1"

Egy Linux parancssori ügyfélnek szüksége lehet a kapcsolatkezelője feloldó-integrációjára, egy felügyelt eszköznek pedig frissített felügyeleti profilra. Csatlakozás után erősítse meg az aktív feloldót az ügyfélen, ahelyett hogy feltételezné, hogy a kitolás érvényesült. Amikor két mechanizmus egyszerre próbál DNS-t beállítani, versenyhelyzet alakul ki, amely villogó feloldásként jelentkezik.

A cél az ügyfél feloldó-konfigurációjának egyetlen tulajdonosa, és a kitolás általában csak akkor az a tulajdonos, ha az ügyfél platformja egyetért.

Azt tesztelje, amit valóban épített

Kérdezzen le egy privát teljesen minősített nevet és egy engedélyezett külső nevet közvetlenül az alagút címével szemben, UDP-n és TCP-n. Ezután ismételje meg az alkalmazás szokásos keresési útvonalán.

Ha a közvetlen lekérdezések működnek, és az alkalmazás mégis meghibásodik, a hiba az átadásban van, nem a kiszolgálón:

  • Az ügyfél soha nem alkalmazta a kitolt beállítást.
  • Később egy másik feloldót állítottak be, és az nyerte a versenyt.
  • Az alkalmazás a saját feloldókönyvtárát vagy gyorsítótárazott választ használ.

Fejezze be annak megerősítésével, hogy a jóváhagyott VPN-útvonalon kívüli forrás egyáltalán nem használhatja a figyelőt. A sikeres feloldás nem jogosítja fel a visszaadott címet, ezért tartsa külön ezt a két kérdést.

Kapcsolódó cikkek