Rovnaká IP servera, dve cesty: označenie vonkajšieho toku OpenVPN

Zvyčajná ochrana proti slučke je trasa hostiteľa: pošlite prevádzku na verejnú adresu servera VPN cez uplink, aby šifrovaná relácia nikdy nevstúpila do vlastného tunela. Funguje to presne do chvíle, keď chcete cez tunel dosiahnuť aj webovú službu na tom istom serveri, pretože výnimka je viazaná na cieľ a cieľ je rovnaký. Východiskom je prestať klasifikovať podľa cieľa a začať klasifikovať podľa toho, ktorý socket paket odoslal.

Začnite dvoma tokmi, ktoré chcete oddeliť

Jeden tok je samotný šifrovaný prenos OpenVPN, ktorý musí odísť cez uplink, inak by tunel niesol svoje vlastné vonkajšie spojenie. Druhý je bežná požiadavka HTTPS na rovnakú verejnú adresu, ktorú chcete vnútri tunela, aby k službe dorazila zo zdroja tunela. Rovnaký cieľ, v mnohých prípadoch rovnaké číslo portu, iná požadovaná cesta.

Pre tento postup predpokladajme klienta na 10.90.0.10 cez tun1, verejnú adresu servera 198.51.100.25 a nedotknutú hlavnú tabuľku, ktorej predvolená trasa ukazuje na bežný uplink. Strana servera musí tiež prijímať webovú službu na vnútornej ceste a vracať prevádzku späť zdroju tunela; odoslanie paketu na verejnú adresu neprepíše listener ani firewallovú politiku servera.

Skôr než čokoľvek zmeníte, zaznamenajte aktuálne pravidlá hostiteľa a zvoľte hodnoty, ktoré nikto iný nepoužíva: značku, číslo tabuľky a tri priority pravidiel. Zachovajte si cestu späť do stroja, ktorá nevedie cez toto spojenie, pretože chyba tu odoberie váš vlastný vzdialený prístup, namiesto toho aby len rozbila kartu prehliadača.

Označte socket, ktorý nesie obálku

Konfigurácia klienta získa značku pre svoje šifrované odchádzajúce pakety a prestane sama inštalovať trasy, takže náhradná politika je jediná, ktorá rozhoduje o cestách:

mark 42
route-noexec
disable-dco

Desiatkové 42 je šestnástkové 0x2a a šestnástkový tvar je to, na čo budú smerovacie pravidlá porovnávať. Referencia link-options opisuje mark ako niečo, čo platí pre šifrované odchádzajúce pakety na Linuxe, čo je presne ten socket, ktorého cestu musíte riadiť. Vypnutie offloadu dátového kanála udržiava tento príklad na ceste používateľského priestoru, kde je správanie značky to opísané.

route-noexec potláča automatické pridávanie a odoberanie trás OpenVPN. Nič ich nenahrádza, takže od tejto chvíle musí vlastník trás udržiavať každú trasu, ktorú tunel potrebuje. Ak po zmene zmizne súkromný cieľ, je to chýbajúca náhradná politika, nie chyba značky.

Neponechávajte trasu hostiteľa v hlavnej tabuľke pre 198.51.100.25, kým to robíte. Taká trasa znova zavádza presne tú výnimku, ktorú sa dizajn snaží zúžiť, a vyhrá pre tok HTTPS skôr, než je niektorá z nižšie uvedených politík opýtaná.

Pošlite všetko ostatné do tabuľky tunela

Keď rozhranie tunela existuje a drží svoju adresu, politika vyzerá 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

Prvé pravidlo udržiava špecifické trasy hostiteľa viditeľné, vrátane prípadnej schválenej miestnej siete, zatiaľ čo predvolenú trasu hlavnej tabuľky robí pre toto hľadanie neviditeľnou. Tento rozdiel je dôležitý: potlačenie predvolenej trasy nie je to isté ako ignorovanie tabuľky a miestne výnimky, ktoré stále potrebujete, prežívajú práve vďaka tomu. Čítajte tie výnimky jednu po druhej, namiesto toho aby ste predpokladali, že výsledkom je univerzálny núdzový vypínač.

Neoznačená prevádzka potom spadne do tabuľky tunela, prevezme zdroj tunela a odíde cez VPN. Označená prevádzka neprejde testom fwmark na ďalších dvoch pravidlách a pokračuje k bežnému hlavnému hľadaniu nižšie v zozname, kde stále leží predvolená trasa uplinku. Záverečné pravidlo unreachable je to, čo bráni neoznačenému toku ticho spadnúť späť na uplink, keď trasa tunela chýba. Selektor je značka od začiatku do konca a adresa cieľa nikdy do rozhodnutia nevstupuje.

Udržiavajte tú poistku aj medzi odpojeniami a inštalujte ju spolu so zvyškom politiky, nie ručne. Pravidlo, ktoré zmizne s rozhraním, nie je politika, ale náhoda. Zmazanie politiky pri páde tunela mení režim zlyhania z „zablokované“ na „vytieklo“ a zastaraná trasa tunela, ktorá neskôr vyprší, je oveľa ľahší problém na vysvetlenie než prevádzka, ktorá odišla nesprávnym rozhraním.

Nech spätná cesta vidí rovnakú značku

Odchádzajúce značky sú len polovica mechanizmu a toto je časť, ktorú väčšina reprodukcií vynecháva. Odpovede na šifrovanú reláciu prichádzajú cez uplink a podliehajú validácii spätnej cesty, ktorá sa pýta, či by zdroj bol smerovaný späť tou istou cestou. Bez pomoci toto hľadanie použije vašu neoznačenú politiku tunela a dospeje k záveru, že paket je na nesprávnom rozhraní.

Oprava patrí vlastníkovi firewallu: uložte značku na odchádzajúcom spojení, obnovte ju na zodpovedajúcich prichádzajúcich paketoch a povoľte spracovanie značiek validované zdrojom pre príslušnú cestu. To, že OpenVPN nastaví značku socketu, nerobí žiadnu z týchto troch vecí, a recept, ktorý uvádza len voľby klienta, je neúplný. Požiadajte o túto integráciu písomne, pretože je to najmenej viditeľná časť návrhu a najľahšie stratená pri prestavbe.

Ani voľná kontrola spätnej cesty nie je náhradou. Voľný režim stále potrebuje, aby pre zdroj existovala nejaká trasa, a poistka unreachable, ktorú ste pridali, jednu pre neoznačené hľadania zámerne odstraňuje. Nechajte integráciu značky spojenia dokončiť a skontrolovať, skôr než sa na tento návrh spoľahnete, a filtre hostiteľa berte ako samostatnú otázku: značka je smerovací signál, nie povolenie. Ak integrácia chýba, symptómom je relácia, ktorá sa nadviaže a potom stíchne, len čo začnú prichádzať odpovede.

Dokážte to dvoma hľadaniami trasy

Porovnajte, čo jadro rozhodne pre oba kontexty, a čítajte polia dev a src namiesto stavu ukončenia:

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

Prvé hľadanie by malo viesť na tun1 so zdrojom tunela a druhé na uplink. Sú to syntetické hľadania, takže dokazujú politiku, nie bežiaci proces: potvrďte zvlášť skutočnú transportnú cestu bežiaceho klienta a potom vykonajte skutočnú požiadavku HTTPS s ponechaným overovaním certifikátov.

Zapíšte si, čo návrh nepokrýva, než ho vyhlásite za hotový. DNS, IPv6 a životný cyklus pravidiel potrebujú každý svoje vlastné rozhodnutie, a toto je príklad smerovania IPv4, nie úplná konfigurácia súkromia. Jeho hodnota je selektor: obálka dostane výnimku uplinku a bežná služba na rovnakej adrese ju nemusí dediť.