Stejná IP serveru, dvě cesty: označení vnějšího toku OpenVPN

Obvyklá ochrana proti smyčce je trasa hostitele: pošlete provoz na veřejnou adresu serveru VPN přes uplink, aby šifrovaná relace nikdy nevstoupila do vlastního tunelu. To funguje přesně do chvíle, kdy chcete také dosáhnout webové služby na stejném serveru přes tunel, protože výjimka je vázána na cíl a cíl je totožný. Východiskem je přestat klasifikovat podle cíle a začít klasifikovat podle toho, který socket paket odeslal.

Začněte dvěma toky, které chcete oddělit

Jeden tok je samotný šifrovaný přenos OpenVPN, který musí odejít přes uplink, jinak by tunel nesl své vlastní vnější spojení. Druhý je běžný požadavek HTTPS na stejnou veřejnou adresu, který chcete uvnitř tunelu, aby k službě dorazil ze zdroje tunelu. Stejný cíl, v mnoha případech stejné číslo portu, jiná požadovaná cesta.

Pro tento postup předpokládejme klienta na 10.90.0.10 přes tun1, veřejnou adresu serveru 198.51.100.25 a nedotčenou hlavní tabulku, jejíž výchozí trasa ukazuje na běžný uplink. Strana serveru musí také přijímat webovou službu na vnitřní cestě a vracet provoz zpět zdroji tunelu; odeslání paketu na veřejnou adresu nepřepíše listener ani firewallovou politiku serveru.

Než něco změníte, zaznamenejte aktuální pravidla hostitele a zvolte hodnoty, které nikdo jiný nepoužívá: značku, číslo tabulky a tři priority pravidel. Zachovejte si cestu zpět do stroje, která nevede přes toto spojení, protože chyba zde odebere váš vlastní vzdálený přístup, místo aby jen rozbila kartu prohlížeče.

Označte socket, který nese obálku

Konfigurace klienta získá značku pro své šifrované odchozí pakety a přestane sama instalovat trasy, takže náhradní politika je jediná, kdo rozhoduje o cestách:

mark 42
route-noexec
disable-dco

Desítkové 42 je šestnáctkové 0x2a a šestnáctkový tvar je to, na co budou směrovací pravidla porovnávat. Reference link-options popisuje mark jako něco, co platí pro šifrované odchozí pakety na Linuxu, což je přesně ten socket, jehož cestu musíte řídit. Vypnutí offloadu datového kanálu udržuje tento příklad na cestě uživatelského prostoru, kde je chování značky to popsané.

route-noexec potlačuje automatické přidávání a odebírání tras OpenVPN. Nic je nenahrazuje, takže od této chvíle musí vlastník tras udržovat každou trasu, kterou tunel potřebuje. Pokud po změně zmizí soukromý cíl, je to chybějící náhradní politika, ne chyba značky.

Neponechávejte trasu hostitele v hlavní tabulce pro 198.51.100.25, dokud to děláte. Taková trasa znovu zavádí přesně tu výjimku, kterou se design snaží zúžit, a vyhraje pro tok HTTPS dříve, než je dotázána kterákoli z níže uvedených politik.

Pošlete vše ostatní do tabulky tunelu

Jakmile rozhraní tunelu existuje a drží svou adresu, politika vypadá takto:

ip -4 route add default dev tun1 src 10.90.0.10 table 47100
ip -4 rule add priority 20000 lookup main suppress_prefixlength 0
ip -4 rule add priority 20001 not fwmark 0x2a lookup 47100
ip -4 rule add priority 20002 not fwmark 0x2a unreachable

První pravidlo udržuje specifické trasy hostitele viditelné, včetně případné schválené místní sítě, zatímco výchozí trasu hlavní tabulky činí pro toto hledání neviditelnou. Tento rozdíl je důležitý: potlačení výchozí trasy není totéž jako ignorování tabulky a místní výjimky, které stále potřebujete, přežívají právě díky tomu. Čtěte ty výjimky jednu po druhé, místo abyste předpokládali, že výsledkem je univerzální nouzový vypínač.

Neoznačený provoz pak spadne do tabulky tunelu, převezme zdroj tunelu a odejde přes VPN. Označený provoz neprojde testem fwmark na dalších dvou pravidlech a pokračuje k běžnému hlavnímu hledání níže v seznamu, kde stále leží výchozí trasa uplinku. Závěrečné pravidlo unreachable je to, co brání neoznačenému toku tiše spadnout zpět na uplink, když trasa tunelu chybí. Selektor je značka od začátku do konce a adresa cíle nikdy do rozhodnutí nevstupuje.

Udržujte tu pojistku i mezi odpojeními a instalujte ji spolu se zbytkem politiky, ne ručně. Pravidlo, které zmizí s rozhraním, není politika, ale náhoda. Smazání politiky při pádu tunelu mění režim selhání z „zablokováno“ na „vyteklo“ a zastaralá trasa tunelu, která později vyprší, je mnohem snazší problém k vysvětlení než provoz, který odešel špatným rozhraním.

Ať zpětná cesta vidí stejnou značku

Odchozí značky jsou jen polovina mechanismu a toto je část, kterou většina reprodukcí vynechává. Odpovědi na šifrovanou relaci přicházejí přes uplink a podléhají validaci zpětné cesty, která se ptá, zda by zdroj byl směrován zpět stejnou cestou. Bez pomoci toto hledání použije vaši neoznačenou politiku tunelu a dojde k závěru, že paket je na špatném rozhraní.

Oprava patří vlastníku firewallu: uložte značku na odchozím spojení, obnovte ji na odpovídajících příchozích paketech a povolte zpracování značek validované zdrojem pro příslušnou cestu. To, že OpenVPN nastaví značku socketu, nedělá žádnou z těchto tří věcí, a recept, který uvádí jen volby klienta, je neúplný. Požádejte o tuto integraci písemně, protože je to nejméně viditelná část návrhu a nejsnáze ztracená při přestavbě.

Ani volná kontrola zpětné cesty není náhradou. Volný režim stále potřebuje, aby pro zdroj existovala nějaká trasa, a pojistka unreachable, kterou jste přidali, jednu pro neoznačená hledání záměrně odstraňuje. Nechte integraci značky spojení dokončit a zkontrolovat, než se na tento návrh spolehnete, a filtry hostitele berte jako samostatnou otázku: značka je směrovací signál, ne povolení. Pokud integrace chybí, symptomem je relace, která se naváže a pak ztichne, jakmile začnou přicházet odpovědi.

Dokažte to dvěma hledáními trasy

Porovnejte, co jádro rozhodne pro oba kontexty, a čtěte pole dev a src místo stavu ukončení:

ip -4 route get 198.51.100.25
ip -4 route get 198.51.100.25 mark 0x2a

První hledání by mělo vést na tun1 se zdrojem tunelu a druhé na uplink. Jsou to syntetická hledání, takže dokazují politiku, ne běžící proces: potvrďte zvlášť skutečnou transportní cestu běžícího klienta a poté proveďte skutečný požadavek HTTPS s ponechaným ověřováním certifikátů.

Zapište si, co návrh nepokrývá, než jej prohlásíte hotovým. DNS, IPv6 a životní cyklus pravidel potřebují každý své vlastní rozhodnutí, a toto je příklad směrování IPv4, nikoli úplná konfigurace soukromí. Jeho hodnota je selektor: obálka dostane výjimku uplinku a běžná služba na stejné adrese ji nemusí dědit.