Egy OpenVPN-ügyfél blokkolása a LAN-ból az alagút leállítása nélkül

A OpenVPN-kiszolgálóján egy ügyfélnek el kell veszítenie a LAN-hozzáférést, miközben minden más alagút működik. Ha erre keres, a legjobb válasz általában azt mondja, hogy a démon ezt nem tudja, ami csak félig igaz: az OpenVPN-nek nincs ügyfelenkénti tűzfala, de az alagutat lezáró gazdagép már szűri a csomagokat. A két döntés, amely számít, a blokkolt identitás és a szabály helye. Ha ezeket jól csinálja, a változás egyetlen sor lesz, amelyet tesztelhet és eltávolíthat.

Rögzítse az ügyfelet, mielőtt megírja a szabályt

Az OpenVPN egy készletből bérli az alagútcímeket, így a 10.8.0.6 hely, nem személy. Amikor a munkamenet véget ér, a bérlet visszatér, és a következő kapcsolat kaphatja meg, ami azt jelenti, hogy az adott cím ellen írt szabály a helyet követi, nem a felhasználót. Ezért először döntse el, mit is blokkol valójában: egy címet egy rövid kísérlethez, vagy egy tanúsítványt valakihez, akit kint akar tartani.

A cím tanúsítványhoz kötéséhez hozzon létre fájlt a client-config-dir által megnevezett könyvtárban, és adja a fájlnak pontosan a tanúsítvány common name értékét. Tegyen bele egy direktívát, ifconfig-push 10.8.0.6 255.255.255.0, és az az ügyfél újracsatlakozáskor is ugyanazt az alagútcímet tartja. Két beállításnak kell léteznie ehhez: a client-config-dir legyen deklarálva a kiszolgáló konfigurációjában, és a küldött cím olyan alhálózatban legyen, amelyet a kiszolgáló tud irányítani. Ha az egyik hiányzik, a fájlt hiba nélkül figyelmen kívül hagyja, ami a következő tűzfal-tesztet félrevezetővé teszi.

Egy ideiglenes blokk használhat készletcímet, feltéve, hogy a jegy rögzíti, melyik munkamenet tartotta akkoriban.

A sorrend dönti el, lefut-e az eldobás

Egy Linux-átjárón, amely az alagút és a LAN között továbbít, a csomagok a FORWARD láncon haladnak át. Olvassa az alábbi parancsot mondatként: szúrja be a FORWARD elejére, egyeztesse a tun0-ból érkező, kizárólag abból az egy gazdagépből jövő, a LAN-alhálózat felé címzett forgalmat, és dobja el.

iptables -I FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP

A -I az, ami a szabályt működteti. -A-val hozzáfűzve az alagút alhálózatára vonatkozó bármely széles elfogadás alá kerül, és soha nem lát csomagot. Ellenőrizze a helyet a iptables -vnL FORWARD --line-numbers paranccsal, és olvassa a számlálókat is: egy felül lévő eldobás, amely semmit nem számol, azt jelenti, hogy a forgalom más úton érkezik.

Az átjáró saját LAN-címe más út. A doboznak magának küldött csomagok a INPUT-ba mennek, nem a FORWARD-ba, így egy ügyfél elveszíthet egy LAN-gazdagépet, és mégis megnyithatja az útválasztó admin oldalát. Adja hozzá a megfelelő INPUT-szabályt, amikor ez számít.

Amit a szűrő nem láthat

A szűrés a csomag értékelésekor történik, így egy létrejött TCP-munkamenet addig folytatódhat, amíg le nem zárul vagy vissza nem állítják. Ha a blokknak azonnal hatnia kell, törölje az adott forrás követett folyamait a conntrack -D -s 10.8.0.6 paranccsal, miután a szabály bekerült. Ha néhány másodperc átfedés elfogadható, jegyezze fel ezt a döntést ahelyett, hogy implicit hagyná. Akárhogy is, a következő embernek tudnia kell, hogy a szabály az élő forgalmat állítja-e meg, vagy csak az új kapcsolatokat.

A partnerek közötti forgalom soha nem érinti a gazdagép tűzfalát. Ha a client-to-client engedélyezett, az OpenVPN a démonon belül továbbítja ezeket a csomagokat, így sem a FORWARD, sem a INPUT nem látja őket. Az egyetlen megoldás a client-to-client kikapcsolása vagy annak elfogadása, hogy a partnerek elérhetik egymást; egy iptables-szabály nem fogja látni ezt a forgalmat.

IPv6, firmware és az újraindítás túlélése

Az IPv4-szabály semmit nem mond az IPv6-ról. Ha az alagút és a LAN is hordozza mindkét családot, az egyenértékű szabálynak léteznie kell az ip6tables-ben, vagy abban az nftables-szabálykészletben, amely a gazdagépen a házirendet birtokolja. Az útválasztó firmware-e gyakran saját absztrakciója mögé rejti a netfiltert, ezért a fórumról másolt szintaxis és táblanevek nem biztos, hogy érvényesek.

Az OpenWrt-n a dokumentált út egy tűzfal-konfigurációs bejegyzés, nem kézzel írt iptables-sor, és egy kézzel írt sor eltűnhet, amikor a tűzfal újratöltődik. Más disztribúciók a netfilter-persistent, egy indítási egység vagy a gyártói tárhely segítségével állítják vissza a szabályokat, és ezek a mechanizmusok nem cserélhetők fel. Bizonyítsa a választottat újraindítással, mert az újratöltés más utat gyakorol.

Útvonalanként ellenőrizzen, majd tisztán állítsa vissza

Minden utat külön teszteljen, mert egy sikeres ellenőrzés elrejti a többit. Egy blokkolt ügyfélnek továbbra is el kell érnie az internetet az alagúton, de el kell buknia egy LAN-gazdagéppel szemben, egy második ügyfélnek el kell érnie ugyanazt a gazdagépet, az átjárócímnek és a partnerútnak pedig külön megfigyelésre van szüksége. Írja az eredményeket a szabály mellé, hogy a következő változásnak legyen alapja. Az alábbi táblázat az a készlet, amelyet érdemes a jegyben tartani.

A visszaállítás specifikáció szerinti törlés, nem flush: a iptables -D FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP pontosan azt a bejegyzést távolítja el, és a lánc többi részét érintetlenül hagyja. Távolítsa el ugyanazt a sort abból a fájlból, amely indításkor visszaállítja a szabályokat, töltse újra, és erősítse meg, hogy az ügyfél ismét eléri a LAN-gazdagépet. A FORWARD flush-elése azokat a szabályokat is visszavonná, amelyeket nem Ön írt, ami a visszaállítást második eseménnyé teszi.

A jegy lezárása előtt erősítsen meg három dolgot: a rögzített cím megfelel a tanúsítványnak, a szabály az elfogadások felett van, és a számláló nem nulla, valamint a tartóssági fájl ugyanazt a szabályt tartalmazza, amelyet tesztelt. Ha ezek közül bármelyik hiányzik, a blokk shell-munkamenetbeli illúzió.