Ohraďte pravidlo SNAT pro OpenVPN, než rozbije nginx

Ze stejného druhu hostitele přicházejí dvě selhání. V prvním se klienti ověří a pak nedosáhnou nic za tunelem. Ve druhém se VPN zvedne a vlastní web serveru přestane odpovídat, což je to znepokojivější, protože to vypadá jako vedlejší škoda. Na VPS založeném na kontejneru se obojí obvykle vrací ke stejnému krátkému seznamu kontrol a pořadí je důležité: nejprve zařízení, potom překlad, nakonec rozsah.

Ověřte, že kontejner dokáže vytvořit zařízení tun

Na ničem jiném nezáleží, pokud rozhraní tun nemůže existovat. Zkontrolujte, že /dev/net/tun je přítomno a že vytvoření testovacího zařízení uspěje, protože mnoho poskytovatelů ve výchozím nastavení vypíná tun uvnitř kontejnerů. Žádná práce s firewallem nenahradí zařízení, které nikdy nevzniklo.

Pokud zařízení chybí, může ho povolit jen hostitel nebo poskytovatel. Jiný tarif je často levnější než otevřené vlákno podpory, které trvá týden. Potvrďte to, než přečtete jediný řádek logu OpenVPN. Jinak strávíte večer laděním pravidel, která nikdy neuvidí paket.

Rozhodněte, co MASQUERADE na tomto rozhraní dělá

Na běžném virtuálním stroji je obvyklé pravidlo odchodu POSTROUTING MASQUERADE z hlavního rozhraní. V kontejneru OpenVZ je viditelné zařízení často venet0, virtuální rozhraní spravované hostitelem, nikoli routovaná síťová karta, a MASQUERADE se tam nechová vždy tak, jak návody předpokládají.

Funkční podoba je explicitní překlad na adresu, kterou klienti již dosahují, s povoleným předáváním v obou směrech. Nahrazení poolu z konfigurace serveru je stejně důležité jako nahrazení adresy. Přečtěte si každý řádek, 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 pravidel předávání se překlad stále děje a jádro stále odmítá předávat. Tato kombinace vytváří matoucí stav, kdy počítadla na pravidle NAT rostou, zatímco klient nic nedostává. Dva řádky FORWARD také musí stát před jakýmkoli širokým pravidlem drop ve stejném řetězci. Pořadí je součástí konfigurace, ne implementační detail.

Omezte pravidlo na jeden pool a jedno rozhraní

Druhý příznak má jinou příčinu: pravidlo POSTROUTING bez omezení zdroje i bez omezení výstupu. Takové pravidlo přepisuje každý paket opouštějící hostitele.

Služby závislé na původním zdroji se pak chovají špatně. Webový server za místní proxy může přestat odpovídat a restart nic nezmění, protože pravidlo je stále v cestě. Provoz, který hostitel posílá na svou vlastní veřejnou adresu, je také zasažen, a proto může selhání vypadat jako problém DNS nebo certifikátu, ne firewallu. Pravidlo bylo téměř jistě přidáno, aby opravilo první příznak.

Řešením je zúžit shodu na pool tunelu a odchozí rozhraní a pak přidat jedno pravidlo na pool místo rozšiřování jednoho pravidla na několik.

Učiňte pravidla trvalými a zjistěte, kdo další je vlastní

Ručně přidaná pravidla po restartu zmizí, proto je uložte pomocí iptables-save nebo je spravujte přes netfilter-persistent tam, kde je nainstalován. Ověřte, že obnova proběhne před startem OpenVPN. Pak jednou záměrně restartujte, místo abyste mezeru objevili během incidentu.

Na hostiteli s kontejnery také ověřte, že soubor trvalosti leží v zapisovatelném úložišti kontejneru a že poskytovatel při bootu nenahrazuje filtrování. Některé platformy spravují politiku mimo kontejner, kde se místní pravidla buď ignorují, nebo se přou s vlastními pravidly hostitele.

Ověřte počítadly a jedním zachyceným tokem

Z připojeného klienta zkontrolujte veřejnou adresu, kterou hlásí externí služba. Pokud odpovídá adrese serveru, překlad funguje; pokud ne, paket odchází jinou cestou nebo neodchází vůbec. Potom vyzkoušejte službu hostovanou na serveru i službu na veřejném internetu, protože procházejí stejnou sadou pravidel různými cestami.

Na serveru čtěte počítadla paketů na pravidlech NAT a FORWARD pomocí iptables -t nat -L -v -n a sledujte jeden tok v zachycení. Pokud se adresa klienta v zachycení objeví a odpověď nepřijde, mezera je na zpětné cestě nebo ve filtrování poskytovatele, ne v profilu klienta. Porovnejte zachycený zdroj s adresou, na kterou pravidlo překládá, protože neshoda znamená, že jako první se shodovalo jiné pravidlo. Jeden pozorovaný tok vyřeší víc než stránka čtení konfigurace.

Držte pool, přeloženou adresu a název rozhraní pohromadě v záznamu změn. Pravidlo správné pro jeden pool přeloží další špatně.