Az UFW eldobja a VPN DNS-szerverét, amint az alagút felépül

A nevek abban a pillanatban feloldhatatlanná válnak, amikor a VPN csatlakozik, miközben egy nyilvános címre küldött ping még válaszol, és a tűzfal állapota nem mutat semmi hibásnak látszót. A szabályzatban semmi nem változott; az változott meg, hogy megjelent egy új interfész, és az alapértelmezett elutasítás az első csomagtól kezdve lefedi. Az UFW irány és interfész szerint dönt, ezért a vezeték nélküli kapcsolatra írt szabály semmit nem mond az alagutat elhagyó forgalomról. A javítás néhány szűk szabály, meghatározott sorrendben alkalmazva.

A tünet csak azután jelenik meg, hogy az alagút felépült

Az alapértelmezett elutasító szabályzat pontosan azt teszi, amit mondtak neki: minden egyező szabály nélküli dolog elutasításra kerül, minden létező interfészen. Az alagút nem létezett a szabályok írásakor, így egyik sem tudja elkapni, és a mindig ott lévő elutasítás most a névfeloldásra vonatkozik. Egy szó szerinti címre menő közvetlen forgalom még működhet, ha szélesebb engedély fedi, és ezért sikerül egy nyilvános feloldóra küldött ping, miközben egy név keresése meghiúsul. A hiány egy szabály egy olyan interfészhez, amelyet a szabályzat soha nem látott.

Ez azt is megmagyarázza, miért fordul vissza tisztán a hiba: bontsd le az alagutat, és a nevek újra feloldódnak, mert a lekérdezés visszatér egy olyan interfészre, amelynek vannak szabályai. Egy szabályzat, amely csak az alagút állása alatt hibázik, nem DNS-probléma, és magának a feloldónak a hangolása itt pazarolja a legtöbb időt. Olvasd el az interfészlistát, mielőtt a feloldó konfigurációját olvasnád.

Három irány, három különböző szabálykészlet

Egyetlen munkamenet egynél több irányban érint szabályokat, és az alagút szinte mindegyikhez hozzáad egy második interfészt. A forgalom irány és interfész szerinti előzetes rendezése mechanikussá teszi a többit, mert az alábbi minden sor a saját helyén igényli a saját szabályát. A példák a tun0-t és egy 10.8.0.0/24-es készletet használnak, ezért helyettesítsd a neveket és tartományokat a kliens saját kimenetéből származókkal.

Két sort gyakran összekevernek, mert mindkettő említi az alagutat. A feloldóra vonatkozó szabály engedi a forgalmat, amelyet a kliens az alagútba küld, míg az SSH-ra vonatkozó szabály engedi a forgalmat, amelyet a szerver onnan fogad; különböző gépeken élnek, és egymástól függetlenül hibáznak. A leggyakrabban elfelejtett sor a második, mert a kliens addig egyáltalán nem tudja felépíteni az alagutat, amíg a szerver nyilvános címére menő forgalma nincs engedélyezve. Dolgozz fentről lefelé, és minden hibának egyetlen lehetséges oka van.

A betolt feloldónak saját szabálya kell

Hogy az alagút visz-e DNS-t, attól függ, mit küld a szerver. Az a szerver, amely betol egy feloldó beállítást, privát címet telepít a kliens konfigurációjába, és ez a cím csak az alagúton keresztül irányítható. Ha a szerver semmit nem tol be, a kliens megtartja a korábbi feloldót, és az alábbi szabályoknak nincs mit engedélyezniük. Bármit is írsz, előbb ellenőrizd a betolt állapotot és az aktuális lekérdezés eredményét:

dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numbered

Az állapotkimenet megnevezi a használt feloldót és a kapcsolatot, amelyhez kötve van, a mögötte lévő útvonalkeresés pedig megmutatja, melyik interfész vinné a lekérdezést arra a címre. Ha a feloldó másik kapcsolaton ül, a probléma korábbi a tűzfalmálnál, és egyetlen szabály sem segít. Ha mindkettő egyetért az alagútban, két szabály kell, mert a lekérdezések többségét az UDP viszi, és a TCP veszi át, amikor egy válasz csonkolódik. Jegyezd fel mindkét értéket, mert ezeket fogják a szabályok megnevezni:

sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'

A külső útvonalat nyisd meg a belső előtt

A kliensnek el kell érnie a szerver nyilvános címét, mielőtt alagút létezik, ezért az arra vonatkozó szabály a fizikai kapcsolaton ül, és először kell a helyén lennie. Az a szabályzat, amely engedi a feloldót, de elfelejti a szervert, teljesen képtelenné teszi a klienst az alagút felépítésére, és ezt a tünetet általában egy kill switchre fogják. Utána engedélyezd azokat a szolgáltatásokat, amelyeket valóban az alagúton keresztül akartál, egyszerre egy szűk szabályt, ahelyett hogy az interfészt egészében megnyitnád. A szűk szabályok az okai annak, hogy az elutasítás a helyén maradhat.

sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'

A sorrend számít a tesztelés alatt, mert az első szabály az, ami egyáltalán fel tudja hozni az alagutat. Add hozzá, csatlakozz, és erősítsd meg, hogy az alagút áll, mielőtt a szolgáltatásszabályt hozzáadnád, mert a kettőt egyszerre csinálni azt jelenti, hogy egy hiba semmit nem mond arról, melyik fél a rossz. Helyettesítsd a fenti dokumentációs címet azzal a végponttal, amelyre a kliens be van állítva.

Fejezd be az ügyféloldalt szándékos leválasztással. Az elutasításnak továbbra is el kell utasítania a szándékosan kizárt forgalmat, mert az a feloldó, amely az alagút állása alatt válaszol, egy kétkedés esetén elutasító szabályzatnak csak a felét fedi le.

A csatlakozó kliens még nincs beengedve

A szervernek is megvan a maga iránya, és a kézfogást befejező kliens még mindig nem ér el semmit, ami a szerveren fut, amíg a szerver be nem engedi. A nyilvános listenerre vonatkozó szabály csak az alagút létezését engedi; nem engedi be az alagút forgalmát. A szerveren ez két szabály plusz egy ellenőrzés, hogy a szolgáltatás valóban figyel:

sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'

A szabályban szereplő készletnek meg kell egyeznie azzal a tartománnyal, amelyet a szerver kioszt, és az alagút számának egyeznie kell azzal, amelyet a szerver létrehozott, mert egy másik interfészre vonatkozó szabály megkülönböztethetetlen a szabály hiányától. limit szándékos egy adminisztratív portnál, mert korlátozza az ismételt kapcsolatokat ahelyett, hogy korlátlanul beengedné őket. A listener-ellenőrzés elválasztja a zárt portot az eldobott csomagtól, amelyek a kliens felől azonosnak látszanak. A számozott szabályok sem a teljes kép: az UFW before-szabályai és minden kézzel írt nftables-sor korábban illeszkedik, és még mindig elutasíthat egy csomagot, amelyet a lista látszólag enged.