Obmedzte pravidlo SNAT pre OpenVPN, kým nerozbije nginx

Z rovnakého druhu hostiteľa prichádzajú dve zlyhania. V prvom sa klienti overia a potom nedosiahnu nič za tunelom. V druhom sa VPN zdvihne a vlastná webová stránka servera prestane odpovedať, čo je to znepokojujúcejšie, pretože to vyzerá ako vedľajšia škoda. Na VPS založenom na kontajneri sa oboje zvyčajne vracia k rovnakému krátkemu zoznamu kontrol a poradie je dôležité: najprv zariadenie, potom preklad, nakoniec rozsah.

Overte, že kontajner dokáže vytvoriť zariadenie tun

Na ničom inom nezáleží, ak rozhranie tunela nemôže existovať. Skontrolujte, či /dev/net/tun je prítomné a či vytvorenie testovacieho zariadenia uspeje, pretože mnohí poskytovatelia v kontajneroch predvolene vypínajú tun. Žiadna práca s firewallom nenahradí zariadenie, ktoré nikdy nevzniklo.

Ak zariadenie chýba, môže ho povoliť len hostiteľ alebo poskytovateľ. Iný plán je často lacnejší ako otvorené vlákno podpory, ktoré trvá týždeň. Potvrďte to, skôr než prečítate čo i len jeden riadok logu OpenVPN. Inak strávite večer ladením pravidiel, ktoré nikdy neuvidia paket.

Rozhodnite, čo MASQUERADE na tomto rozhraní robí

Na bežnom virtuálnom stroji je obvyklé pravidlo odchodu POSTROUTING MASQUERADE z hlavného rozhrania. V kontajneri OpenVZ je viditeľné zariadenie často venet0, virtuálne rozhranie spravované hostiteľom, nie smerovaná sieťová karta, a MASQUERADE sa tam nechová vždy tak, ako predpokladajú návody.

Funkčná podoba je explicitný preklad na adresu, ktorú klienti už dosahujú, s povoleným preposielaním v oboch smeroch. Nahradenie poolu z konfigurácie servera je rovnako dôležité ako nahradenie adresy. Prečítajte si každý riadok, než ho vložíte.

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

Bez pravidiel preposielania sa preklad stále deje a jadro stále odmieta preposielať. Táto kombinácia vytvára mätúci stav, keď počítadlá na pravidle NAT rastú, zatiaľ čo klient nič nedostáva. Dva riadky FORWARD tiež musia stáť pred akýmkoľvek širokým pravidlom drop v tom istom reťazci. Poradie je súčasťou konfigurácie, nie implementačný detail.

Obmedzte pravidlo na jeden pool a jedno rozhranie

Druhý príznak má inú príčinu: pravidlo POSTROUTING bez obmedzenia zdroja aj bez obmedzenia výstupu. Také pravidlo prepisuje každý paket opúšťajúci hostiteľa.

Služby závislé od pôvodného zdroja sa potom správajú nesprávne. Webový server za miestnym proxy môže prestať odpovedať a reštart nič nezmení, pretože pravidlo je stále v ceste. Zasiahnutá je aj premávka, ktorú hostiteľ posiela na svoju vlastnú verejnú adresu, a preto môže zlyhanie vyzerať ako problém DNS alebo certifikátu, nie firewallu. Pravidlo bolo takmer isto pridané, aby opravilo prvý príznak.

Riešením je zúžiť zhodu na pool tunela a odchádzajúce rozhranie a potom pridať jedno pravidlo na pool namiesto rozširovania jedného pravidla na niekoľko.

Urobte pravidlá trvalými a zistite, kto ďalší ich vlastní

Pravidlá pridané ručne po reštarte zmiznú, preto ich uložte pomocou iptables-save alebo ich spravujte cez netfilter-persistent tam, kde je nainštalovaný. Overte, že obnova prebehne pred štartom OpenVPN. Potom raz zámerne reštartujte, namiesto toho, aby ste medzeru objavili počas incidentu.

Na hostiteľovi s kontajnermi tiež overte, že súbor trvalosti leží v zapisovateľnom úložisku kontajnera a že poskytovateľ pri bootovaní nenahrádza filtrovanie. Niektoré platformy spravujú politiku mimo kontajnera, kde sa miestne pravidlá buď ignorujú, alebo sa bijú s vlastnými pravidlami hostiteľa.

Overte počítadlami a jedným zachyteným tokom

Z pripojeného klienta skontrolujte verejnú adresu, ktorú hlási externá služba. Ak sa zhoduje s adresou servera, preklad funguje; ak nie, paket odchádza inou cestou alebo neodchádza vôbec. Potom vyskúšajte službu hostovanú na serveri aj službu na verejnom internete, pretože prechádzajú tou istou sadou pravidiel rôznymi cestami.

Na serveri čítajte počítadlá paketov na pravidlách NAT a FORWARD pomocou iptables -t nat -L -v -n a sledujte jeden tok v zachytení. Ak sa adresa klienta v zachytení objaví a odpoveď nepríde, medzera je na spiatočnej ceste alebo vo filtrovaní poskytovateľa, nie v profile klienta. Porovnajte zachytený zdroj s adresou, na ktorú pravidlo prekladá, pretože nezhoda znamená, že ako prvé sa zhodovalo iné pravidlo. Jeden pozorovaný tok vyrieši viac ako stránka čítania konfigurácie.

Držte pool, preloženú adresu a názov rozhrania spolu v zázname zmien. Pravidlo správne pre jeden pool preloží ďalší nesprávne.