Premostění klienti OpenVPN nemají internet? Zkontrolujte pravidlo NAT

Přemostěný server běží, pravidlo masquerade existuje, a prohlížeč na klientovi se přesto točí. Všechno vypadá, jako by to mělo fungovat, a právě proto jde první hodina na kontrolu tunelu a přihlašovacích údajů. Pak přečtete čítač u pravidla NAT a najdete nulu, která se nepohnula. Pravidlo, které nikdy nespočítalo žádný paket, se nikdy s žádným neshodovalo, a na přemostěném serveru je důvod strukturální: provoz klienta vychází přes virtuální zařízení tap, zatímco pravidlo uvádí fyzickou kartu, kterou jste zkopírovali ze staršího návodu.

Důkazem je čítač, ne řádek v tabulce

Pravidla, která existují, a pravidla, která odpovídají, jsou různé věci a odděluje je čítač. Vypište tabulku NAT s podrobnými čítači a přečtěte čísla u každého pravidla, než cokoli změníte. Čítač stojící na nule, zatímco provoz teče, znamená, že pravidlo bylo přeskočeno, ať jeho adresy vypadají jakkoli rozumně. Čítač, který roste, zatímco spojení stále selhává, vás pošle jinam: přesměrování, zpáteční cesta nebo vzdálený konec.

iptables -t nat -L POSTROUTING -v -n

Nejprve přečtěte čítač u shody rozhraní. Pokud je rozsah zdroje správný a výstupní strana špatná, oprava je jedno slovo v pravidle, nikoli úplně nové pravidlo.

Najděte název, který jádro skutečně zaznamenává

Určete zařízení tunelu podle názvu, než pravidlo napíšete, a použijte seznam rozhraní, ne paměť. U přemostěného OpenVPN uspořádání je zařízením obvykle rozhraní tap vytvořené serverem a jeho název je součástí vaší místní konfigurace, ne univerzální konstanta. Ověřte, že existuje, dokud je tunel aktivní, protože zařízení, které se objeví až po připojení klienta, způsobí, že dřívější test bude vypadat jako problém s pravidlem.

ip -brief link

Název si zapište. Každý další příkaz v této diagnostice se na něj odvolává a překlep zde dá přesně stejný nulový čítač jako původní chyba.

Přepište pravidlo proti zařízení tunelu

Namiřte pravidlo na zařízení tunelu a ponechejte rozsah klientů jako jeho podmínku shody, aby pokrývalo provoz tunelu a nechalo vlastní spojení hostitele na pokoji. Dosaďte svůj rozsah a název zařízení, protože oba příklady níže jsou jen příklady a ani jeden není přenosný mezi instalacemi.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tap0 -j MASQUERADE

Potom zkontrolujte další dvě podmínky, které stejný symptom skrývá. Zkontrolujte, zda je zapnuté přesměrování, a pokud není, zapněte je ve vlastní konfiguraci distribuce, ne pomocí echo, které při restartu zmizí. Přečtěte také čítače řetězu forward, a pokud zahazuje provoz tunelu, povolte konkrétně toto rozhraní a politiku řetězu nechte být.

Přečtení řetězu forward s čítači zabere jeden příkaz a vyloučí polovinu zbývajících možností, než se dotknete dalšího pravidla.

Proč se fyzická karta nikdy neshoduje

Most je softwarový přepínač složený ze zařízení tap a jednoho fyzického rozhraní. Rámec klienta vstoupí do tohoto přepínače a vystoupí k fyzické síti jako člen mostu, ne jako paket na kartě. Jádro proto paket přiřazuje mostu a jeho portu, a právě proto se karta, na kterou jste mysleli, ve shodě nikdy neobjeví. Na fyzickém rozhraní není nic rozbité; prostě to není zařízení, které jádro tomu paketu přiřazuje.

Další problém, na který lidé narazí, pochází ze stejné struktury: filtrování rámců na mostě je samostatná záležitost od filtrování IP. Pokud je požadavkem omezení na úrovni rámců, patří k filtrování mostu, ne k pravidlu tabulky IP.

Dokažte to od začátku do konce a pak to udělejte trvalým

Zvedněte jednoho klienta a pingněte něco v LAN serveru; tato cesta procvičí přesměrování bez jakéhokoli překladu. Potom si vyžádejte něco veřejného, aby se pravidlo masquerade muselo použít, a přečtěte čítač znovu: měl by se pohnout pro tento test a ne pro předchozí. Zachycení na zařízení tunelu ukáže jak to, kde se rámec objeví, tak to, kterou adresu nese.

Poslední krok: dejte fungující pravidla do konfigurace, kterou čte restart, a poznamenejte si název zařízení, které most tohoto hostitele skutečně používá. Cokoli napsané ručně po restartu zmizí a stejná závada se vrátí, aniž by zbylo něco, co by ji vysvětlilo.

Pokud se čítač ani po přepsání nepohne, porovnejte rozsah zdroje v pravidle s adresou, kterou klient skutečně dostal, protože přemostěný server může rozdávat adresy z rozsahu, který jste nezamýšleli.