Odpověď VPN mezi lokalitami nejde tunelem

Strávil jsem ráno tunelem, který se čistě zvedl a přenášel provoz přesně jedním směrem: pobočka dosáhla na souborový server v centrále a každé spojení otevřené z centrály do pobočky umíralo na prvním SYN. SA byly aktivní, počítadla tunelu rostla a handshake nikdy nebyl problém. Odpověď se směrovala někam, kam tunel nedosáhne, a toto rozhodnutí patří vzdálené straně. VPN mezi lokalitami přenáší jen pakety, které hostitel předá bráně, a každý hostitel toto rozhodnutí dělá zvlášť, v každém směru, ze své vlastní směrovací tabulky.

Oba směry se směrují odděleně

IP si nepamatuje směr konverzace. Každý hostitel, který odešle paket, provede vlastní hledání nejdelšího prefixu, vybere jeden další skok a rozhodnutí zapomene. Požadavek a odpověď jsou dva nesouvisející pakety, které náhodou patří ke stejnému spojení, a tunel je jeden skok, který může a nemusí použít kterýkoli z nich. Nic ve výměně IKE neučí vzdálený server, jak dosáhnout vaší podsítě; vyjednávání se jen shodne na tom, které prefixy smějí být šifrovány.

Tato dohoda je druhá brána. V strongSwanu jsou selektory provozu leftsubnet a rightsubnet a paket, jehož zdroj nebo cíl leží mimo vyjednanou dvojici, se nešifruje, ať směrovací tabulka říká cokoli. Prefix, který se směruje do tunelu, ale chybí v selektorech, je tiché jednosměrné selhání: trasa vypadá správně, paket přesto odchází v čitelném tvaru nebo se zahodí, a stěžuje si jen protokol charonu.

Vzdálený hostitel o vašem tunelu nic neví

Uvnitř vzdálené LAN je odpověď obyčejný paket adresovaný vašemu klientovi. Cílový hostitel nevidí žádnou hlavičku IPsec a nemá důvod dávat přednost VPN bráně; vyhledá váš prefix, nenajde nic konkrétnějšího než svou výchozí trasu a půjde po ní. Pokud výchozí trasa ukazuje na hlavní firewall, má firewall buď trasu zpět do tunelu, nebo ne. Když ji nemá, dostanete tiché zahození, ICMP nedostupnost nebo odpověď, která vyjde rozhraním směrem k internetu a zahyne.

Druhé rozhraní stačí k tomu, aby se to rozbilo i tehdy, když trasa existuje. NAS s management rozhraním v jiné VLAN, server se záložním uplinkem, pravidlo politiky, které posílá jeden rozsah zdrojů do druhé tabulky: cokoli z toho může odpověď zachytit. V Linuxu ip rule show a ip route show table all ukážou pravidla a tabulky, které výchozí výpis skrývá.

Přečtěte rozhodnutí na stroji, který odpověď odesílá

Ptejte se jádra, než něco změníte, a dejte mu zdrojovou adresu, protože pravidla závislá na zdroji mění odpověď.

ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"

Výstup uvádí odchozí rozhraní a další skok. Pokud rozhraní není to, které míří k VPN bráně, našli jste závadu a zbývá vybrat, kam trasa patří. Ping z brány zde dokazuje málo: odpovídá adresou, kterou vzdálený hostitel umí umístit, ne adresou vašeho notebooku.

Ve Windows jsou ekvivalenty Find-NetRoute -RemoteIPAddress 10.10.5.10 pro rozhodnutí a Get-NetRoute pro tabulku. Trasa přidaná pomocí New-NetRoute s vyšší metrikou než výchozí prohrává tiše, takže čtěte sloupec metriky, ne záznam. Pak to potvrďte pakety: tcpdump -ni any "host 10.10.5.10 and tcp port 445" na vzdáleném LAN rozhraní ukáže požadavek a stejný filtr na straně tunelu ukáže, zda se odpověď vrátila. Viditelný požadavek bez odpovědi znamená, že odpověď byla směrována jinam nebo zahozena; odpověď na špatném rozhraní vám dá viníka dřív, než se dotknete trasy.

Když brána serveru není koncovým bodem VPN

Mnoho lokalit staví firewall mezi servery a koncentrátor. Ten firewall odpověď přeposílá, takže potřebuje trasu pro prefix vašeho klienta směrem k VPN bráně a politiku přeposílání v obou směrech. Stavová zařízení to zhoršují: požadavek prošel firewallem z LAN hostitele, kterému to povolil, odpověď teď přichází z jiného směru a záznam sledování spojení už nesedí, takže se paket zahodí jako neplatný, nikoli jako zakázaný. Proto log politiky vypadá prázdný, zatímco provoz mizí.

Brána má vlastní druhý filtr. Zpětné filtrování cesty v Linuxu zahazuje pakety, jejichž zdroj není dostupný přes rozhraní, kterým dorazily, což je přesně podoba legitimní asymetrické zpětné cesty. průvodce přeposíláním strongSwanu proto žádá net.ipv4.ip_forward a uvolněný net.ipv4.conf.all.rp_filter. Přísná hodnota 1 na kterékoli bráně tiše rozbije správnou trasu a nstat -az ukáže zahození, pokud víte, kam se dívat.

Směrujte nebo překládejte, pak ověřte v obou směrech

Obě opravy nejsou rovnocenné. Přidání trasy zachová adresu klienta nedotčenou, takže pravidla založená na zdroji, auditní záznamy a aplikace, které zaznamenávají volajícího, dál fungují; cenou je, že každý skok, který rozhodnutí činí, potřebuje trasu, což je víc míst, kde se dá udělat chyba. Maskování na vzdálené bráně smrští zpětnou cestu na jeden skok, protože odpověď je nyní adresována samotné bráně, a skryje, který klient co udělal.

iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADE

Vyberte ho vědomě: jakmile se klienti jeví jako adresa brány, ACL založené na zdroji je přestanou rozlišovat a conntrack musí držet mapování, aby se odpověď přepsala zpět do tunelu. Pokud selektory stále vylučují prefix klienta, NAT nic nezmění, protože požadavek do tunelu nikdy nevstoupil.

Než to prohlásíte za opravené, potvrďte čtyři věci v pořadí: trasu na hostiteli, který odpověď odesílá, trasu na každém skoku, který ji přeposílá, selektory pokrývající oba prefixy a záznam, který ukazuje odpověď vstupující do tunelu se zdrojem, který očekáváte. Pak test zopakujte z druhé lokality. Jeden procházející směr je polootevřený návrh a druhý směr obvykle selhává z jiného důvodu, než jaký jste právě opravili.