Isti IP strežnika, dve poti: označevanje zunanjega toka OpenVPN

Običajna zaščita pred zanko je pot gostitelja: pošljite promet na javni naslov strežnika VPN čez uplink, da šifrirana seja nikoli ne vstopi v svoj tunel. To deluje prav do trenutka, ko želite skozi tunel doseči tudi spletno storitev na istem strežniku, ker je izjema vezana na cilj in je cilj enak. Izhod je, da prenehate razvrščati po cilju in začnete razvrščati po tem, kateri socket je poslal paket.

Začnite z dvema tokovoma, ki ju želite ločiti

En tok je sam šifriran prenos OpenVPN, ki mora oditi čez uplink, sicer bi tunel nosil svojo lastno zunanjo povezavo. Drugi je običajna zahteva HTTPS na isti javni naslov, ki jo želite znotraj tunela, da do storitve pride iz vira tunela. Isti cilj, v mnogih primerih ista številka vrat, drugačna zahtevana pot.

Za to razlago predpostavite odjemalca na 10.90.0.10 prek tun1, javni naslov strežnika 198.51.100.25 in nedotaknjeno glavno tabelo, katere privzeta pot kaže na običajni uplink. Strežniška stran mora sprejeti tudi spletno storitev na notranji poti in vračati promet viru tunela; pošiljanje paketa na javni naslov ne obide poslušalca ali požarne politike strežnika.

Preden karkoli spremenite, zabeležite trenutna pravila gostitelja in izberite vrednosti, ki jih nihče drug ne uporablja: oznako, številko tabele in tri prioritete pravil. Ohranite pot nazaj v stroj, ki ne gre skozi to povezavo, ker napaka tukaj odstrani vaš lastni oddaljeni dostop, namesto da bi le pokvarila zavihek brskalnika.

Označite socket, ki nosi ovojnico

Konfiguracija odjemalca dobi oznako za svoje šifrirane odhodne pakete in preneha sama nameščati poti, tako da je nadomestna politika edina, ki odloča o poteh:

mark 42
route-noexec
disable-dco

Desetiško 42 je šestnajstiško 0x2a in šestnajstiška oblika je tista, na katero se bodo ujemala pravila usmerjanja. Referenca link-options opisuje mark kot nekaj, kar velja za šifrirane odhodne pakete na Linuxu, kar je natanko tisti socket, katerega pot morate nadzorovati. Izklop offloada podatkovnega kanala ohrani ta primer na poti uporabniškega prostora, kjer je obnašanje oznake to opisano.

route-noexec zatira samodejno dodajanje in odstranjevanje poti OpenVPN. Ničesar ne namesti namesto njih, zato mora od tega trenutka lastnik poti vzdrževati vsako pot, ki jo tunel potrebuje. Če zasebni cilj po spremembi izgine, je to manjkajoča nadomestna politika, ne napaka v oznaki.

Med tem ne ohranjajte poti gostitelja v glavni tabeli za 198.51.100.25. Takšna pot znova uvaja natanko tisto izjemo, ki jo poskuša zasnova zožiti, in zmagala bo za tok HTTPS, preden bo vprašana katera koli od spodnjih politik.

Pošljite vse ostalo v tabelo tunela

Ko vmesnik tunela obstaja in ima svoj naslov, je politika videti takole:

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

Prvo pravilo ohranja posebne poti gostitelja vidne, vključno z morebitnim odobrenim lokalnim omrežjem, medtem ko naredi privzeto pot glavne tabele za to iskanje nevidno. Ta razlika je pomembna: zatiranje privzete poti ni isto kot ignoriranje tabele, in lokalne izjeme, ki jih še vedno potrebujete, preživijo prav zaradi tega. Berite te izjeme eno za drugo, namesto da bi predpostavili, da je rezultat univerzalno varnostno stikalo.

Neoznačen promet nato pade v tabelo tunela, prevzame vir tunela in odide skozi VPN. Označen promet spodleti pri preizkusu fwmark na naslednjih dveh pravilih in nadaljuje do običajnega glavnega iskanja nižje na seznamu, kjer še vedno leži privzeta pot uplinka. Končno pravilo unreachable je tisto, ki prepreči, da bi neoznačen tok tiho padel nazaj na uplink, ko pot tunela manjka. Selektor je oznaka od začetka do konca in naslov cilja nikoli ne vstopi v odločitev.

Ohranjajte to varovalko med prekinitvami in jo namestite skupaj z ostalo politiko, ne ročno. Pravilo, ki izgine z vmesnikom, ni politika, ampak naključje. Brisanje politike, ko tunel pade, spremeni način odpovedi iz »blokirano« v »uhajalo«, in zastarela pot tunela, ki pozneje poteče, je veliko lažje razložljiva težava kot promet, ki je odšel skozi napačen vmesnik.

Naj povratna pot vidi isto oznako

Odhodne oznake so le polovica mehanizma in to je del, ki ga večina reprodukcij izpusti. Odgovori na šifrirano sejo prispejo po uplinku in so predmet preverjanja povratne poti, ki sprašuje, ali bi bil vir usmerjen nazaj po isti poti, po kateri je prišel. Brez pomoči to iskanje uporabi vašo neoznačeno politiko tunela in sklene, da je paket na napačnem vmesniku.

Popravek pripada lastniku požarnega zidu: shranite oznako na odhodni povezavi, obnovite jo na ustreznih dohodnih paketih in omogočite obravnavo oznak, potrjeno z virom, za zadevno pot. To, da OpenVPN nastavi oznako vtičnice, ne naredi nobene od teh treh stvari, in recept, ki navaja le možnosti odjemalca, je nepopoln. Zahtevajte to integracijo pisno, ker je najmanj vidni del zasnove in najlažje izgubljeni pri ponovni gradnji.

Tudi ohlapno preverjanje povratne poti ni nadomestilo. Ohlapni način še vedno potrebuje neko pot za vir, in varovalka unreachable, ki ste jo dodali, namerno odstrani eno za neoznačena iskanja. Dokončajte in pregledajte integracijo oznake povezave, preden se zanesete na to zasnovo, in filtre gostitelja obravnavajte kot ločeno vprašanje: oznaka je signal usmerjanja, ne dovoljenje. Če integracija manjka, je simptom seja, ki se vzpostavi in nato utihne takoj, ko začnejo prihajati odgovori.

Dokažite to z dvema iskanjema poti

Primerjajte, kaj jedro odloči za oba konteksta, in berite polji dev in src namesto izhodnega stanja:

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

Prvo iskanje bi moralo razrešiti na tun1 z virom tunela, drugo pa na uplink. To so sintetična iskanja, zato dokazujejo politiko in ne delujočega procesa: ločeno potrdite dejansko transportno pot delujočega odjemalca in nato izvedite resnično zahtevo HTTPS z vključenim preverjanjem potrdil.

Zapišite, česa zasnova ne pokriva, preden jo razglasite za dokončano. DNS, IPv6 in življenjski cikel pravil potrebujejo vsak svojo odločitev, in to je primer usmerjanja IPv4, ne popolna konfiguracija zasebnosti. Njena vrednost je selektor: ovojnica dobi izjemo uplinka, in običajna storitev na istem naslovu je ne potrebuje podedovati.