Směrovaný klient VPN dosáhne na server, ale ne na hostitele v LAN

Tunel se zvedne, klient pingne server VPN a sdílená složka na stroji o jeden skok dál nikdy neodpoví. Nic v konfiguraci klienta to nevysvětluje, protože požadavek klienta skutečně opustil a skutečně dorazil. Selhala cesta zpět a zařízení, které selhalo, je obvykle brána LAN, nikoli hostitel VPN. Sledování paketu s odpovědí vysvětluje celou tuto třídu symptomů.

Sledujte odpověď, ne požadavek

Server VPN dešifruje paket klienta a předá jej do LAN, přičemž adresa klienta zůstává v poli zdroje. Cílový hostitel na tuto adresu odpoví a nyní rozhoduje vše jeho vlastní směrovací tabulka. Jeho výchozí brána o poolu tunelu nic neví, takže odpověď odejde k poskytovateli internetu a někde na této cestě je zahozena.

Na klientovi je symptom tichý timeout: žádné odmítnutí, žádný reset, prostě nic. Procházení sdílené složky zamrzne, ping hlásí, že odpověď nepřišla, a protokoly serveru vypadají zdravě, protože server udělal svou práci.

Umístěte zpětnou trasu tam, kam se hostitelé dívají

Každý hostitel v LAN se ptá své výchozí brány, takže brána je jediné zařízení, které musí vědět, kde pool tunelu žije. Přidejte tam statickou trasu a každý hostitel zdědí správnou cestu, aniž by byl změněn.

Pokud brána rozdává svou vlastní adresu jako volbu DHCP, distribuujte trasu tímto způsobem, aby si ji nové stroje převzaly automaticky. Jinak trasa žije v jednom konfiguračním souboru a při příštím přebudování zmizí.

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

Proč to Source NAT vypadá, že opravuje

Maskování poolu klientů za adresou serveru VPN odstraní problém tím, že z paketu odstraní adresu klienta. Odpovědi se pak vracejí na server, který už ví, jak se k tunelu dostat, a všechno funguje. Cenou je, že interní hostitelé už nevidí, kdo je klient, a každé spojení vypadá, jako by vycházelo z jednoho stroje.

Tato výměna je někdy správná, například když zařízení dodavatele nelze dát statickou trasu. Nedělejte pravidlo širší než aktuální pool, protože pravidlo napsané pro /24 přestane odpovídat v den, kdy je pool přečíslován na /16, a prvním signálem je dávka nových klientů, kteří se připojí a na nic nedosáhnou.

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

Cloudová cesta potřebuje tři nastavení

Ve VPC se stejná mezera vrací v jiné podobě, protože podsíť nemá pro rozsah klientů vůbec žádnou trasu. Směrovací tabulka potřebuje záznam pro pool tunelu, který cílí na síťové rozhraní instance, a rozhraní potřebuje vypnutou kontrolu zdroje a cíle, aby platforma přijala pakety, jejichž zdrojem není jeho vlastní adresa. Bezpečnostní skupiny a síťové ACL musí také pustit pool v obou směrech.

Každé vynechání vytvoří jinou částečnou poruchu. Vynechejte záznam ve směrovací tabulce a privátní instance odpovídají do podsítě, která nedokáže dopravit odpověď zpět do poolu. Při zapnuté kontrole platforma odpověď zahodí poté, co ji instance už odeslala. Bez pravidla bezpečnostní skupiny samotný požadavek nikdy nedorazí a klient vidí timeout o vrstvu dřív.

Proveďte kontroly v tomto pořadí

Potvrďte předávání a politiku filtrování, než obviníte směrování, protože hostitel, který nebude předávat, selhává stejně tiše. Potom přečtěte efektivní nastavení zpětné cesty na rozhraní, které nese tunel, protože přísný filtr může zahodit odpovědi přicházející z neočekávaného směru.

Skončete zachycením na hostiteli v LAN, zatímco na něj klient pingá. Požadavek, který dorazí bez odpovídající odpovědi, dokazuje zpětnou cestu, a požadavek, který nikdy nedorazí, přesouvá vinu zpět na server nebo tunel.

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

Kontrola zdroje a cíle je zdokumentována v průvodci elastickým síťovým rozhraním. Nastavte ji na rozhraní, které skutečně nese provoz tunelu, ne na nesouvisející adaptér připojený ke stejné instanci.