VPN klienti dosáhnou na server, ale ne do sítě LAN: které řešení?

Klient pingne adresu tunelu serveru OpenVPN a dostane odpověď, pak zkusí hostitele v síti LAN serveru a nedostane nic. Toto rozdělení hodně zužuje závadu: tunel je nahoře, předávání pravděpodobně funguje a odpověď odchází dveřmi, které nevedou zpět. Existují tři řešení a to správné závisí na tom, co ovládáte a čeho jste ochotni se vzdát. Odpovězte na tři otázky níže popořadě a volba přestane být věcí vkusu.

Nejprve zjistěte, který směr je rozbitý

Požadavek přichází na rozhraní tunelu se zdrojovou adresou z fondu VPN. Server ho předá hostiteli v síti LAN a ten odpoví bráně, kterou určí jeho vlastní tabulka, obvykle routeru sítě LAN. Pokud router nemá trasu do fondu, odpověď tam zemře nebo bloudí směrem k internetu.

Otestujte oba stroje, než některý upravíte. Zeptejte se serveru, kudy by se jeho tabulka dostala ke klientovi; zeptejte se hostitele v síti LAN, kudy by se dostal na stejnou adresu. První hledání obvykle ukazuje na tunel a druhé na router sítě LAN, a ten rozdíl je závada na jednom řádku. Dvě hledání jsou levnější než audit firewallu a určí směr problému.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Pokud hostitel v síti LAN už ukazuje na server VPN, je problémem pravidlo firewallu nebo limit MTU, ne chybějící cesta zpět. Nepřidávejte trasu, abyste opravili filtr.

Otázka první: můžete upravit router vzdálené sítě LAN?

Když je router sítě LAN váš, čistou odpovědí je statická trasa do fondu VPN s adresou LAN serveru VPN jako dalším skokem. Zachovává nedotčené zdrojové adresy klientů, což má význam, když hostitelé v síti LAN logují, filtrují nebo omezují rychlost podle adresy. Také nevyžaduje žádný překlad na serveru, takže tunel zůstává čistou cestou směrování. Závazek, který vytváří, je dokumentační, protože fond, trasa a konfigurace serveru se musí shodovat.

Selhává tiše v den, kdy někdo fond změní. Zapište hodnotu jednou a berte úpravu na kterémkoli ze tří míst jako úpravu všech tří.

NAS nebo přepínač vrstvy 3, který hostuje službu, potřebuje stejnou trasu, pokud neposílá vše přes router, který ji má. Zkontrolujte zařízení, které ukončuje podsíť, ne jen to obrácené k internetu. Malé sítě mají často tři zařízení s názorem na směrování.

Otázka druhá: může síť LAN přestat vidět adresy klientů?

Když router patří někomu jinému, překlad na serveru VPN nevyžaduje spolupráci. Hostitel v síti LAN vidí adresu LAN serveru, odpoví jí a server přeloží zpět. Proto se zařízení a role vzdáleného přístupu založené na NAT chovají právě tak.

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

Cenou je přiřazení: adresy na klienta mizí z logů sítě LAN. Každý seznam povolených na hostiteli v síti LAN pak musí jmenovat server místo fondu.

Zvolte překlad, když spolupráce není dostupná, ne když je jen nepohodlná. Skrývá klienta před každým budoucím vyšetřováním, i před těmi, kde potřebujete vědět, který notebook otevřel spojení. Může také rozbít protokoly, které vkládají adresy do užitečného zatížení, protože překlad žije v hlavičce. Ani jedna možnost není vyspělejší; odpovídají na různé otázky o vlastnictví.

Otázka třetí: je server sám klientem jiného tunelu?

Představte si druhou topologii: server VPN také vytáčí komerčního poskytovatele, takže má dva tunely a dvě sady adres. Provoz, který předává svým vlastním klientům, odchází přes poskytovatele, a ten nebude směrovat odpovědi zpět na adresy fondu. Proto odpovědi mizí, i když jsou oba tunely zdravé.

Řešením je maskovat i odchozí tunel, aby poskytovatel viděl jen adresu tunelu serveru. Opačný směr potřebuje vlastní pravidlo, protože server, který navazuje spojení ke svému vlastnímu klientovi, je jiný tok. Bez toho pravidla klient odpovídá na adresu, kterou nedokáže směrovat. Umístěte úzké pravidlo před každé široké maskování, aby vyhrál konkrétní překlad.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Hostitelé s více rozhraními přidávají příbuznou závadu, která z pohledu klienta vypadá stejně. Odpověď odchází rozhraním s nižší metrikou, protože zdrojová adresa byla vybrána z jiné tabulky. Zkontrolujte cestu zpět hledáním, místo abyste předpokládali, že cesta tam ji implikuje.

Pak ověřte oba směry a obě velikosti

Po změně pingněte z klienta na hostitele v síti LAN a potom z hostitele v síti LAN na klienta. Druhý směr je ten, který lidé přeskakují, a je to ten, který odhalí neúplné pravidlo překladu. Zaznamenejte oba výsledky s časovým razítkem, aby bylo pozdější regresi možné srovnat.

Pak přeneste skutečná data, protože malý ping, který projde, zatímco velký přenos se zasekne, je příznak MTU. Ta závada se objeví hned poté, co si pogratulujete k opravě trasy.

Nakonec otestujte znovu po restartu. Příkazy trasy a firewallu za běhu ho nepřežijí a oprava, která při dalším startu zmizí, bude znovu diagnostikována někým s menším kontextem. Udělejte změnu trvalou tak, jak to váš systém už dělá, a pak jednou restartujte záměrně.