iptables-gazdagép csak VPN-nel: a tun-eszközt nevezd meg, ne a tun+-t

Ha -o tun+-t írunk, az pontos utasításnak tűnik, valójában viszont egy helyettesítő karakter, amely a kernel minden alagútjára illeszkedik. Egy második VPN-kliens, egy konténerhíd vagy egy összeomlott munkamenet után maradt interfész mind megfelel neki, és a gazdagép ekkor átengedi azt a forgalmat, amelyet a szabályzat meg akart akadályozni. Az alábbi eljárás egyetlen eszköznevet rögzít, úgy rendezi a kivételeket, hogy az alagút valóban létrejöhessen, és visszautat hagy, ha a szabályok rosszul sikerülnek. Minden lépés elég rövid ahhoz, hogy önállóan visszavonható legyen.

1. lépés: rögzítsd a jelenlegi szabályokat

Egy alapértelmezett szabályzat módosítása előtt mentsd el a jelenlegi állapotot, hogy a visszaállítás parancs legyen, ne emlék. iptables-save > /root/iptables.pre minden táblát olyan fájlba ír, amelyet vissza tudsz állítani, és a második terminál nyitott root-munkamenettel nem paranoia, amikor a beállítandó szabályzat eldobja az őt szállító kapcsolatot. Ha távolról dolgozol, ütemezz egy flush-t is vészleállítóként.

Ezután listázd az interfészeket, mert egy feltételezett név olyan név, amelyet el kellett volna olvasnod: ip -br link megmutatja, mi létezik most, és az alagút nem jelenik meg, amíg fel nem jön. Írd fel az eszközneveket, ahogy olvasod őket.

2. lépés: adj az alagútnak saját nevet

OpenVPN elfogadja a dev tun_work beállítást a kliens konfigurációjában, és a Linux ekkor pontosan ezzel a névvel hoz létre interfészt ahelyett, hogy tun0-t osztana ki. A név újracsatlakozások között is stabil marad, amíg semmi más nem tart rá igényt, és ez teszi értelmessé az eszközt megnevező szabályt.

Ahol a név nem szabályozható, ott inkább az alagút címére vagy egy csomagjelölésre illeszkedj. Mindkettő működik, mindkettő nehezebben olvasható, és mindkettő halkabban hibázik, amikor az alagút újraszámozódik. Mindenképpen egyetlen dologra illeszkedj, és mondd meg egyértelműen, melyikre.

3. lépés: írd meg a szabályzatot az endpoint-kivétellel elöl

A csak VPN-nel működő gazdagép alapértelmezett elutasítású gazdagép rövid kivétellistával, és a legfontosabb kivétel az, amely engedi, hogy az alagút létezzen. Ebben a sorrendben építsd fel, az endpoint-szabályt az alagút-eszköz szabálya előtt, hogy a kézfogásnak legyen hova mennie:

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Az endpoint szó szerinti címe és portja a szolgáltatódé, nem ezé az oldalé. Ha az endpoint hosztnév, oldd fel egyszer, és rögzítsd az eredményt, mert egy szabály nem tud nevet lekérdezni, és a forgó válasz csendben elrontja a szabályzatot a következő DNS-változás után. A portot is ellenőrizd, mert a szolgáltatók, amelyek TCP 443-ra visznek át, különben olyan szabályt igényelnek, amelyet senki nem írt le. Az az alagút, amely csak egy protokollon működik, általában éppen ez a kihagyás, és nem tűzfalhiba.

Egy routeren ugyanez a forma a FORWARD láncba kerül a mögötte lévő kliensek számára, és a router saját forgalmának saját szabályokra van szüksége. Az a szabálykészlet, amely csak továbbított csomagokat fed le, SSH-t és DNS-t a régi úton hagy, és így válik a router elérhetetlenné abban a pillanatban, amikor az alagút feljön.

4. lépés: a sorrendet ellenőrizd, ne csak a jelenlétet

A szabályok sorrendben értékelődnek ki, így a korábban jövő ACCEPT egyszerűen elrejti a később hozzáadott REJECT-et. Az established és related egyezés az, ami engedi, hogy a saját kimenő kéréseidre érkező válaszok visszatérjenek anélkül, hogy általános bejövő utat nyitna, és ha az alagút elfogadása után helyezed el, az azt jelenti, hogy egy elesett alagút továbbra is átengedi a visszirányú forgalmat a saját interfészén.

Tartsd a szabályok számát elég kicsin ahhoz, hogy egy képernyőn elolvasható legyen. Az a szabálykészlet, amelyet nem tudsz auditálni, az, amelyet felül kivételek hozzáadásával foltozol, és így szereznek az alapértelmezett elutasítású szabályzatok fokozatosan alapértelmezett engedélyezési peremet. Számold meg az ACCEPT-eket a változás előtt és után.

5. lépés: tedd túlélővé a boot és a címcsalád számára

A kézzel bevitt szabályok újraindításkor eltűnnek, ezért töltsd be őket a disztribúció tűzfalszolgáltatásából vagy egy olyan unitból, amely az alagút-interfész létezése után fut. Ha egy szkriptben, amely az OpenVPN indulása előtt fut, a tun_work-ra hivatkozol, az gyakori módja annak, hogy eldobott forgalmú boot-hurkot hozz létre.

Ezután ellenőrizd az IPv6-ot külön, mert egy jó IPv4-es alapértelmezett elutasítású szabályzat semmit nem mond a másik családról. A ip -6 route megmondja, van-e a gazdagépnek olyan útvonala, amely forgalmat vihet el egy csak IPv4-et kezelő alagút mellett, és az ip6tables vagy az nftables saját megfelelő szabályokat igényel. IPv6-only célponttal tesztelj, ahelyett hogy a szabálykészlet szimmetriájában bíznál.

6. lépés: ellenőrizd, és légy készen a visszaállításra

Hozd fel az alagutat, erősítsd meg, hogy a kívánt szolgáltatás működik, majd próbálj ki valamit, amit a szabályzatnak el kellene utasítania. Állítsd vissza a iptables-restore < /root/iptables.pre-cal, ha a válasz meglep, és csak utána kezdd el szerkeszteni a szabályokat. A tartósság és egy kipróbált visszaállítási útvonal teszi ezt olyan változtatássá, amelyet kétszer is meg tudsz csinálni.