VPN klient na serveru LAN: proč odpovědi odcházejí špatnou cestou

Příznaky sledují jeden vzorec: hostitel funguje, pak se jako klient připojí k VPN, a nyní se k němu klienti LAN dostanou, zatímco jeho odpovědi mizí. Zachycení na hostiteli ukazuje, že odpovědi odcházejí tunelem místo rozhraním LAN. Na tunelu není nic rozbité a opravou je trasa, ne opětovné připojení. Projděte čtyři kontroly níže v pořadí a zastavte se u první, která selže.

Odpověď je nový paket, ne opačná cesta

Pomáhá opustit představu, že odpověď putuje zpět po cestě, kterou šel požadavek. Směrování se rozhoduje pro každý paket a každý směr na odesílajícím hostiteli. Požadavek, který dorazil z 10.64.0.23 uvnitř tunelu, nevytváří žádnou zpětnou cestu; když hostitel odpoví, je tato odpověď porovnána s tabulkou jako nový paket a odejde trasou, která vyhraje.

Proto klient plného tunelu na stroji, který zároveň obsluhuje LAN, vytváří tak matoucí selhání. Klient nainstaluje výchozí trasu, nebo dvě poloviny výchozí trasy, které někteří klienti preferují, a odpověď klientovi LAN nyní odpovídá tunelu. Odejde poskytovateli, který nemá důvod ji přeposílat, a klient LAN vidí vypršení času, přestože hostitel běží a odpovídá lokálně. Zachycení to ukáže jasně a směrovací tabulka to vysvětlí.

Mějte v hlavě dvě podsítě, zatímco čtete zbytek. Jedna je fond adres VPN, odkud přicházejí vzdálení klienti, v tomto příkladu 10.64.0.0/24. Druhá je LAN, která musí dál fungovat, 172.16.24.0/24 s routerem na 172.16.24.1. Chyba je v tom, že provoz mezi nimi rozhoduje výchozí trasa.

Dokažte to zachycením a vyhledáním

Než cokoli změníte, ověřte, které zařízení odpověď použije. Vyhledání je rychlejší než zachycení a odpovídá přesně na otázku, kterou jádro zodpoví při sestavování paketu.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

Čtěte odpověď ve dvou částech. Pokud uvádí dev tun0, hostitel odpověď zapouzdří a předá poskytovateli a klient LAN ji nikdy neuvidí. Pokud uvádí dev eth0, ale klient přesto dostane vypršení času, trasa je už správná a paket se zahazuje později, což je jiný problém s jinou opravou.

Zachcení ve stejném kroku vyřeší pochybnost, kterou ping nemůže. Odpověď echa, která dorazí ke klientovi LAN, dokazuje, že nějaká cesta funguje, ne které rozhraní ji neslo, proto zachycení provádějte na samotném hostiteli a sledujte, odkud rámce odcházejí. Tiskárna ve stejné podsíti dál odpovídá, protože její přímá trasa je konkrétnější než výchozí trasa tunelu. Přesměrovaný port selhává stejně jako každý jiný tok, protože rozhraní vybírá tabulka, ne spojení.

Nainstalujte nejužší trasu, která předčí tunel

Rozhoduje délka prefixu, ne metrika, takže trasa pro fond klientů přes LAN router vyhraje nad každou výchozí trasou, kterou klient VPN nainstaluje. Operace s metrikou nejsou potřeba a výchozí trasa může zůstat přesně tam, kam ji klient umístil.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

Použijte replace místo add, protože klient, který se znovu připojí, už nainstaloval svůj vlastní záznam a druhý add selže s chybou existující trasy, která vypadá jako problém s oprávněními. Na hostiteli Windows je ekvivalentem route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, kde -p zachová záznam i po restartech, protože klient může tabulku znovu sestavit, když tunel znovu naběhne. Na současném hostiteli Windows je podporovaným ekvivalentem New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, přičemž starší příkaz route zůstává jako starší forma.

Jeden detail rozhoduje, zda je to správné, nebo jen uvěřitelné: další skok musí být router, který skutečně vlastní cestu zpět ke klientům. Nasměrování trasy na adresu, která je sama dosažitelná tunelem, vytváří smyčku, která se projeví jako občasná ztráta, ne jako čisté selhání. Před zadáním řádku ověřte, že další skok je v podsíti LAN.

Zachovejte odpověď po opětovném připojení

Trasa přidaná ručně přežije v nejlepším případě do dalšího připojení. Pokud je fond klientů dynamický, připněte ho v konfiguraci serveru, aby prefix, který jste směrovali, zůstal prefixem, který klienti dostávají; jinak záznam ukazuje na prázdný rozsah a příznak se po týdnech vrátí bez zjevné příčiny. Zapsání trasy do vlastního up-skriptu klienta je druhá spolehlivá možnost, protože se spustí poté, co klient tabulku přepsal.

Stavový firewall může správnou trasu přesto porazit. Pokud zachycení nyní ukazuje, že odpověď odchází přes eth0, a klient přesto dostane vypršení času, zkontrolujte, zda hostitel paket nezahazuje před odesláním. Přísné filtrování reverzní cesty a net.ipv4.conf.all.rp_filter nastavený na 1 zahazují pakety, jejichž zdroj by se nesměroval zpět rozhraním, kterým dorazily, což je přesně asymetrický případ, který jste právě vytvořili a pak opravili, a stav conntrack vypráví stejný příběh u přesměrovaných portů.

Poslední kontrola je ta, kterou lidé přeskakují: zopakujte vyhledání poté, co tunel spadl a znovu naběhl. Čtyři hodnoty mají odpovídat tomu, co jste si zapsali: cíl, další skok, zařízení a zvolený zdroj. Pokud se některá posunula, klient tabulku přepsal a oprava patří do jeho hooků, ne do historie shellu.