Otevření portu VPN nedovolí klientům dosáhnout na LAN

Tunel se zvedne, klient se ověří, ale LAN za bránou zůstává neviditelná. Pravidlo, které to mělo opravit, propouští port VPN a funguje přesně tak, jak je napsané, protože řídí pakety adresované samotné bráně. Provoz klienta k hostiteli za bránou má jiné cíle i jiný řetězec. Úspěšné přihlášení nemění, který z obou řetězců jádro prohlíží.

Dva řetězce, dva různé cíle

Osud paketu určuje, kam jde, ne jak dorazil. Provoz na adresu brány se doručí lokálně a vyhodnotí podle vstupních pravidel. Provoz, který brána přeposílá dál, se vyhodnocuje podle pravidel forwardingu. Stejné rozhraní tunelu může vytvářet oba druhy paketů, proto jedno pravidlo nemůže pokrýt obě práce.

Celý mýtus v jedné větě: povolení posluchače nic neříká o povolení sítě za ním. Jsou to dvě oddělená rozhodnutí s oddělenými důkazy a jméno rozhraní na obou je neslévá.

Co pravidlo posluchače skutečně propouští

Pakety posluchače končí v procesu VPN, a to vůbec umožňuje vznik tunelu. Administrační stránka brány i lokální diagnostická odpověď také používají vlastní vstupní cestu hostitele, proto test na bránu projde, zatímco vše za ní selže. Oba výsledky jsou správné a ani jeden není o LAN.

Když proces dekapsuluje provoz klienta pro jiný cíl, paket vstoupí do cesty forwardingu a tam potřebuje povolení. Úspěšná autentizace rozhoduje, kdo je klient; nerozhoduje, kam smí. Obě otázky mají jiné vlastníky, jiné logy a jiné chybové zprávy.

Testujte z klienta, nikdy z brány

Test vytvořený na bráně sleduje vlastní výstupní cestu hostitele a může projít, i když je přeposílaná cesta zavřená. Začněte test z klienta a sledujte oba konce toku.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Pokud se požadavek objeví na tun0 a k cíli nic nedorazí, paket se po doručení zahodí, což ukazuje na pravidla forwardingu nebo na vlastní filtrování cíle. Pokud se na tun0 neobjeví vůbec nic, klient ho do tunelu ani neposílá a problém je ve směrování na klientovi, ne v politice brány. Srovnejte to s požadavkem, který správně odejde a nic nevrátí, což je případ zpáteční cesty.

Forwarding potřebuje tři věci, ne jednu

Forwarding v jádru musí být zapnutý, filtrovací pravidlo musí tok přijmout a cíl musí být dostupný s cestou pro návrat odpovědi. Chybí-li cokoli z toho, je ticho z pohledu klienta stejné.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

Čtěte tři výstupy společně. Nula v prvním dělá další dva nepodstatnými a politika výchozího zahazování ve druhém zahazuje pakety klienta, zatímco vlastní provoz brány dál funguje. Třetí výstup ukazuje, proč pravidlo posluchače nikdy nebylo problémem.

Držte obě sady pravidel v dokumentaci oddělené

Napište pravidlo posluchače a pravidlo přeposílané služby na samostatné řádky s oddělenými vlastníky a důvody. Když se port VPN změní nebo se publikuje nová služba, toto oddělení brání tomu, aby jedna změna tiše rozšířila druhou.

Místo abyste každého ověřeného partnera brali jako důvěryhodného člena LAN, používejte úzká pravidla pro rozsahy klientů a služby, které je potřebují. Poznámky k forwardingu StrongSwan popisují stranu zpáteční trasy a překladu stejné hranice, což je znovu třetí rozhodnutí.

Nakonec držte vrstvy rovné, když je uživatel odmítnut. Pokud požadavek dorazí na hostitele a aplikace odmítne účet, opravte oprávnění aplikace na této vrstvě; rozšíření forwardingu nemůže dodat přihlašovací údaje ke sdílení souborů a rozšíří přístup všem ostatním, kdo se úspěšně připojí.