Tunel běží, internet ne: kde se zastaví předávání

Ověření identity a funkční tunel ještě neznamenají odchod do internetu. Sledujte jeden požadavek přes adresování zdroje, předávání a zpáteční cestu.

Klient se připojí, tunel přenáší pingy k bráně a nic za ní neodpovídá. Tento stav je normální u brány, která měla vždy sloužit jen k přístupu do chráněných sítí, a je závadou u brány inzerované jako výstup plného tunelu. Než změníte pravidla, ověřte, jaká služba byla slíbena. Potom sledujte jeden veřejný požadavek čtyřmi místy, kde se může zastavit. Jeden požadavek a jeden záznam paketů vyřeší víc než stránka dohadů.

Ověřte, zda byl odchod do internetu vůbec záměrem

Profil rozděleného tunelu směruje do VPN jen chráněné podsítě, takže veřejné prohlížení pokračuje přes místní spojení a brány se nikdy nedotkne. Profil plného tunelu instaluje do tunelu výchozí trasu, čímž se brána stává odpovědnou za celou cestu. Oba jsou legitimní návrhy a jejich záměna vytváří hlášení závady tam, kde žádná není. Přečtěte si trasy inzerované klientem, než začnete testovat cokoli jiného, protože tabulka tras odpovídá na otázku, kterou tiket obvykle klade špatně.

To, co klient nainstaluje, není vždy to, co profil zamýšlí. Zaslanou trasu může přebít místní trasa s nižší metrikou a klient, který si ponechává trasu do LAN a přitom přidává výchozí trasu, se pro tuto podsíť chová jako rozdělený tunel.

Sledujte jeden veřejný požadavek

Vyberte jeden cíl a sledujte jej od klienta ven. Na klientovi zkontrolujte, zda paket skutečně volí tunel a kterou místní adresu používá jako zdroj. Potom zkontrolujte bránu: přichází paket a opouští veřejné rozhraní. Každá z těchto odpovědí odstraňuje celou kategorii příčin.

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

Pokud brána paket nikdy nevidí, je špatná trasa klienta nebo volba tunelu. Pokud dorazí a neodejde, je problém na bráně a platí zbývající tři kontroly.

Zkontrolujte předávání, trasu a překlad

Pokyny k předávání dodávané se strongSwanem platí pro bránu jakéhokoli typu tunelu: jádru musí být povoleno přesouvat pakety mezi rozhraními a použitelná trasa musí ukazovat k internetu. Politika firewallu pak musí provoz povolit a zdrojová adresa musí být taková, aby na ni veřejná strana mohla odpovědět. Soukromá adresa klienta předaná beze změny do internetu nikdy nedostane odpověď.

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

Překlad zdroje je obvyklý chybějící díl. S ním brána přepíše zdroj klienta na svou veřejnou adresu a sleduje tok; bez něj odpověď nemá kam jít. Cloudové platformy přidávají druhou hranici, kde tabulka tras nebo bezpečnostní skupina instance může zahodit provoz, který firewall hosta povoluje. Tuto hranici lze snadno přehlédnout, protože systém hosta vypadá zevnitř správně nastavený.

Filtrování zpětné cesty u asymetrického uspořádání může také zahazovat platné pakety. Přečtěte si počítadlo tohoto pravidla, místo abyste předpokládali, že je v pořádku, protože přísné nastavení na veřejném rozhraní odmítá provoz, který přichází jinou cestou, než předpovídá tabulka tras.

Zpáteční cesta a resolver jsou dvě různé odpovědi

Sledujte i odpověď, nejen požadavek. Pokud požadavek odchází přeložený a odpověď se vrací do přeloženého toku, předávání funguje i tehdy, když aplikace stále selhává, a další vyšetřování patří aplikaci nebo DNS.

Web, který vrátí chybu HTTP, je důkazem, že předávání do internetu funguje. Jméno, které se nerozřeší, zatímco přístup podle adresy funguje, je problém resolveru, ne NAT.

Po úzké opravě znovu otestujte klienta i každý záměrně omezený soukromý zdroj. Udělení přístupu k internetu nesmí tiše rozšířit přístup do každé sítě připojené k bráně.

Související články