Webový server zmizí, když se připojí VPN klient

Služba, která zmizí ve chvíli, kdy se připojí VPN klient, obvykle není blokovaná, ale odpovídá přes špatné rozhraní. Požadavek dorazí na fyzickou síťovou kartu, démon zapíše odpověď a směrovací tabulka tuto odpověď předá tunelu, protože tunel převzal výchozí trasu. Vzdálený klient nikdy neuvidí odpověď na spojení, které otevřel, takže čeká a potom ohlásí vypršení časového limitu. V tomto sledu se neuplatní žádné pravidlo firewallu.

Příznak: požadavky dovnitř, odpovědi ven špatnými dveřmi

Příznakem je příchozí spojení, které selže, zatímco všechno ostatní na hostiteli funguje. Dalším vodítkem je hostitel dostupný z LAN, ale ne z internetu, nebo takový, který funguje, dokud se tunel znovu nepřipojí, a pak přestane. V každém případě fungoval směr tam a směr zpět ne, což ukazuje na asymetrii směrování, nikoli na politiku.

Potvrďte to sledováním, kam jde odpověď, ne sledováním, jak přichází požadavek.

Zachytávejte současně na fyzickém rozhraní a na zařízení tunelu. Pokud se požadavek objeví na fyzickém rozhraní a odpověď na tunelu, diagnóza je hotová. Odpověď, která se neobjeví nikde, znamená, že služba spojení nikdy nepřijala, což je samostatné vyšetřování se samostatnou příčinou.

Dvě výchozí trasy a jedno rozhodnutí o směrování

Klient, který nainstaluje výchozí trasu, přidá druhý záznam s lepší metrikou než má brána LAN. Někteří klienti místo toho nainstalují dvě trasy polovičního rozsahu, které pokrývají stejný prostor konkrétněji a vyhrají vyhledávání stejným způsobem. Obě techniky nechávají běžné odchozí pakety vybírat rozhraní tunelu.

Tato volba se provádí pouze podle cíle. Jádro se neptá, odkud paket přišel, pokud mu to pravidlo politiky nepřikáže. Odpověď na veřejnou adresu klienta se tedy předá tunelu, jehož vzdálený konec obdrží paket se zdrojovou adresou, kterou nevlastní, a zahodí ho nebo přepošle někam zbytečně. V Linuxu může striktní filtrování zpětné cesty také zahodit původní požadavek dřív, než ho vaše služba vůbec uvidí, což zvenku vypadá stejně. Oba příznaky pocházejí ze stejného chybějícího spojení mezi příchozím tokem a jeho odpovědí.

Tunel se po celou dobu chová správně. Bylo mu řečeno, aby nesl výchozí trasu, a dělá přesně to.

Opravte zpětnou cestu, aniž byste rozbili tunel

Existují tři trvalé formy opravy a volba závisí na tom, kolik vlastního provozu hostitele má zůstat uvnitř tunelu. Vyloučení cíle nebo portu služby je nejmenší změna. Směrování podle politiky podle zdroje nebo značky je nejpřesnější. Překlad zdroje je nejhrubší a nejlépe se vysvětluje po dvou letech.

Vybírejte podle toho, co hostitel musí dělat, ne podle toho, který fragment jste našli první.

Vyloučení cíle se hodí pro službu se stabilní veřejnou adresou a připoutání démona k fyzické adrese místo ke každé adrese činí toto vyloučení bezpečnějším. Pravidlo politiky, které vybírá tabulku podle zdroje, udržuje vlastní spojení hostitele uvnitř tunelu a přitom vrací odpovědi služby přes bránu WAN. Maskování odpovědí na rozhraní WAN dosáhne stejné cesty za cenu skrytí adresy klienta před protokoly služby. Ad hoc změna výchozí trasy je diagnostika, ne konfigurace, protože klient při každém opětovném připojení přepisuje trasy.

ip rule show
ip route get 203.0.113.9 from 192.0.2.44

Když hostitel také směruje pro LAN za sebou

O jeden skok dál se stejná asymetrie vrací s více pohyblivými částmi. Provoz dorazí do routeru z internetu, předá se internímu zařízení a jediná cesta toho zařízení zpět je tunel, takže odpověď dorazí k původnímu klientovi z vlastní adresy poskytovatele. Sledování spojení pak narazí na odpověď pro tok, jehož začátek nevidělo, a zahodí ji. Klient mezitím nevidí vůbec nic.

Opravují to dvě změny: překlad cíle, aby se příchozí spojení dostalo k internímu zařízení, a překlad zdroje, aby odpověď toho zařízení vypadala, že přichází od samotného routeru.

Ve firmwaru routeru je obvyklým vyjádřením pravidlo politiky, které připíná přesměrování portu na stranu WAN, zatímco vlastní provoz routeru jede tunelem. Bez překladu zdroje je tato odpověď adresována externímu klientovi a interní zařízení k němu prostě nemá trasu. Otestujte tři věci odděleně, protože selhávají z různých důvodů: spojení přicházející zvenku, spojení, které hostitel sám zahájí, a vyhledání jména.