Szűkítse az OpenVPN SNAT szabályt, mielőtt elrontja az nginxet

Két hiba érkezik mindig ugyanolyan típusú gazdagépről. Az elsőben az ügyfelek hitelesítenek, majd semmit nem érnek el az alagúton túl. A másodikban a VPN feljön, és a kiszolgáló saját webhelye abbahagyja a válaszolást, ami a riasztóbb, mert járulékos kárnak tűnik. Konténeralapú VPS-en mindkettő általában ugyanahhoz a rövid ellenőrzéslistához vezet vissza, és a sorrend számít: először az eszköz, másodszor a fordítás, harmadszor a hatókör.

Győződjön meg róla, hogy a konténer tud tun eszközt létrehozni

Semmi más nem számít, ha az alagút interfész nem létezhet. Ellenőrizze, hogy /dev/net/tun jelen van-e, és hogy a teszt eszköz létrehozása sikerül-e, mert sok szolgáltató alapértelmezés szerint kikapcsolja a tun-t a konténerekben. Semmilyen firewall-munka nem kompenzál egy soha létre nem hozott eszközt.

Ha az eszköz hiányzik, csak a gazdagép vagy a szolgáltató engedélyezheti. Egy másik csomag gyakran olcsóbb, mint egy egy hétig tartó nyitott támogatási szál. Erősítse meg ezt, mielőtt egyetlen OpenVPN-naplósort elolvasna. Különben az estét olyan szabályok hangolásával tölti, amelyek soha nem látnak csomagot.

Döntse el, mit tesz a MASQUERADE ezen az interfészen

Egy közönséges virtuális gépen a szokásos kimenő szabály POSTROUTING MASQUERADE a fő interfészről. Egy OpenVZ konténerben a látható eszköz gyakran venet0, gazdagép által kezelt virtuális interfész, nem irányított hálókártya, és a MASQUERADE ott nem mindig úgy viselkedik, ahogy az oktatóanyagok feltételezik.

A működő forma a kifejezett fordítás arra a címre, amelyet az ügyfelek már elérnek, mindkét irányban engedélyezett továbbítással. A pool cseréje a kiszolgáló konfigurációjából ugyanolyan fontos, mint a cím cseréje. Olvasson el minden sort, mielőtt beilleszti.

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

A továbbítási szabályok nélkül a fordítás továbbra is megtörténik, és a kernel továbbra is megtagadja a továbbítást. Ez a kombináció azt a zavarba ejtő állapotot hozza létre, amelyben a NAT-szabály számlálói nőnek, miközben az ügyfél semmit nem kap. A két FORWARD sornak szintén bármely széles drop-szabály előtt kell állnia ugyanabban a láncban. A sorrend a konfiguráció része, nem megvalósítási részlet.

Szűkítse a szabályt egy poolra és egy interfészre

A második tünetnek más az oka: forrás- és kimeneti korlátozás nélküli POSTROUTING szabály. Az ilyen szabály átír minden csomagot, amely elhagyja a gazdagépet.

Az eredeti forrástól függő szolgáltatások ezután rosszul viselkednek. Egy helyi proxy mögötti webkiszolgáló abbahagyhatja a válaszolást, és az újraindítás semmit nem változtat, mert a szabály még mindig az úton van. A gazdagép saját nyilvános címére küldött forgalma is érintett, ezért a hiba DNS- vagy tanúsítványproblémának tűnhet firewall-probléma helyett. A szabályt szinte biztosan az első tünet javítására adták hozzá.

A megoldás az, hogy az egyezést az alagút pooljára és a kimenő interfészre szűkítjük, majd poolonként egy szabályt adunk hozzá ahelyett, hogy egyetlen szabályt szélesítenénk több lefedésére.

Tegye tartóssá a szabályokat, és derítse ki, ki más birtokolja őket

A kézzel hozzáadott szabályok újraindításkor eltűnnek, ezért mentse őket iptables-save-mal, vagy kezelje őket netfilter-persistent-en keresztül ott, ahol telepítve van. Erősítse meg, hogy a visszaállítás az OpenVPN indulása előtt lefut. Ezután indítsa újra egyszer szándékosan, ahelyett hogy egy incidens közben fedezné fel a rést.

Konténergazdagépen azt is erősítse meg, hogy a tartóssági fájl írható konténer-tárolóban van, és a szolgáltató nem cseréli ki a szűrést indításkor. Egyes platformok a konténeren kívül kezelik a szabályzatot, ahol a helyi szabályokat vagy figyelmen kívül hagyják, vagy a gazdagép sajátjaival versenyeznek.

Ellenőrizze számlálókkal és egy rögzített folyammal

Egy csatlakozott ügyfélről ellenőrizze a nyilvános címet, amelyet egy külső szolgáltatás jelent. Ha egyezik a kiszolgáló címével, a fordítás működik; ha nem, a csomag más úton távozik, vagy egyáltalán nem távozik. Ezután próbáljon ki egy kiszolgálón hosztolt szolgáltatást és egyet a nyilvános interneten, mert azok különböző utakon haladnak át ugyanazon szabálykészleten.

A kiszolgálón olvassa a csomagszámlálókat a NAT és FORWARD szabályokon iptables -t nat -L -v -n segítségével, és figyeljen meg egy folyamot egy rögzítésben. Ha az ügyfél címe megjelenik a rögzítésben, és nem következik válasz, a rés a visszaúton vagy a szolgáltató szűrésében van, nem az ügyfélprofilban. Hasonlítsa össze a rögzített forrást azzal a címmel, amelyre a szabály fordít, mert az eltérés azt jelenti, hogy előbb egy másik szabály egyezett. Egy megfigyelt folyam többet dönt el, mint egy oldal konfigurációolvasás.

Tartsa együtt a poolt, a fordított címet és az interfész nevét a változási nyilvántartásban. Egy poolra helyes szabály a következőt hibásan fordítja.