Aplenkti VPN tik vieną vietinę žiniatinklio paslaugą pagal prievadą

Viena prieglobos paslauga turi atsakyti internetui fizine aukštynkryptine jungtimi, o visa kita mašinoje toliau naudoja tunelį. Tris sąlygos lemia, ar politika pagrįstas maršrutizavimas gali išlaikyti tą apkrovą, ir kiekvieną jų pigiai patikrinti prieš rašant taisyklę. Paslauga turi baigtis šiame prieglobstyje, o ne už DNAT ar persiųsto prievado, pačios VPN taisyklės turi leisti išimtį, ir jūs turite sutapatinti atsakymą, o ne užklausą. Jei nepavyksta bent viena iš trijų, žemiau esančios komandos įkeliamos be klaidų, bet nedaro nieko naudingo.

Patikrinkite tris sąlygas prieš rašydami taisyklę

Konteineris, skelbiantis prievadą per DNAT, arba serveris už prievado persiuntimo, kuria paketus, kurie neatsiranda šiame prieglobstyje. Tie paketai persiunčiami, todėl taisyklė, pagrįsta vietiniu prieglobos įėjimu, jų niekada nemato ir srautas toliau naudoja numatytąjį maršrutą. Prieš tęsdami patvirtinkite, kur paslauga iš tikrųjų veikia, nes tai sąlyga, kurią žmonės dažniausiai supainioja.

Antroji sąlyga yra politika, o ne mechanika. Bet koks maršrutas, aplenkiantis tunelį, yra tunelio paskirties išimtis, o valdomame prieglobstyje tą sprendimą priima politikos savininkas, o ne asmuo, derinantis laukimo laiką.

Sutapatinkite atsakymą, o ne kliento paskirties prievadą

Serverio, klausančio TCP 443, atsakymas palieka prieglobstį su šaltinio prievadu 443. To paties prieglobos naršyklė, jungdamasi prie nuotolinės HTTPS svetainės, siunčia laikiną šaltinio prievadą ir paskirties prievadą 443. Abu yra 443 prievado srautas, ir tik vienas iš jų turėtų naudoti WAN lentelę, todėl paskirties prievado sutapatinimas pagautų ne tą pusę.

Atsakymo kryptis yra tai, ką galite atskirti. Sutapatinkite šaltinio prievadą, apribokite taisyklę vietoje sukurtais paketais, ir taisyklė apima pačios paslaugos atsakymus neliesdama naršyklės užklausų.

Sukurkite visą grąžinimo lentelę, kol taisyklė į ją dar nerodo

Tuščia lentelė reiškia nėra maršruto, o tai atrodo kaip sugedusi paslauga, o ne sugedusi politika. Pirmiausia ją užpildykite lentelės numeriu ir prioritetu, kurių niekas kitas prieglobstyje nereikalauja:

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

Skaičius skaitykite iš gyvos prieglobos, o ne nusikopijuokite. ip -4 rule show parodo, kurie prioritetai užimti, o taisyklės pridėjimas prie jau esamo prioriteto tyliai pakeičia dviejų taisyklių, kurios atskirai atrodo tvarkingai, eilę.

Tikrą darbą čia atlieka du selektoriai. iif lo yra būdas, kuriuo branduolys praneša apie pačios prieglobos sukurtus paketus, todėl taisyklė negali atsitiktinai pagauti iš išorės ateinančio persiunčiamo srauto. ipproto tcp sport 443 susiaurina jį iki vieno transporto ir vieno prievado, o tai taip griežta, kaip leidžia reikalavimas. Pašalinkite protokolo selektorių, ir taisyklė pagaus ir UDP 443, kuri yra kita paslauga su kitu elgesiu.

Laikykite privačius atsakymus tunelio viduje

Jei tas pats klausytojas atsako ir privatinės pusės klientams, numatytasis WAN maršrutas, kuris pagauna viską 100 lentelėje, bandys tuos atsakymus grąžinti per aukštynkryptinę jungtį. Pridėkite privačius prefiksus, kurie neturi sekti numatytuoju WAN maršrutu, arba leiskite jiems pereiti prie kitos politikos taisyklės:

ip -4 route add table 100 throw 10.90.0.0/24

Throw maršrutas baigia paiešką šioje lentelėje ir grąžina paketą taisyklių sąrašui, todėl toliau einanti VPN politika gauna savo šansą. Jis pats nieko nenukreipia į tunelį, o jei nė viena vėlesnė taisyklė neturi atitinkančio maršruto, paketas vis tiek nepraeina; patikrinkite kitą politiką, o ne manykite, kad throw yra pataisa.

Atvirkštinio kelio filtravimas ir prieglobos užkardos taisyklės vis dar taikomos gaunamai užklausai. Pažiūrėkite į jų tikruosius sprendimus prieš silpnindami validavimą, nes maršrutizavimo išimtis nepriverčia rp_filter priimti grįžimo kelio, kurį jis laiko neįmanomu.

Išbandykite TCP, tada QUIC, tada perkrovimą

Atidarykite vieną ryšį iš įgalioto išorinio kliento ir vieną iš privatinės pusės, tada patikrinkite atsakymo paiešką su tikraisiais adresais ir prievadais. Jei išorinis atsakymas naudoja 100 lentelę, o privatus ne, politika daro tai, ko prašėte.

HTTP/3 teikiama per UDP ir nebus sutapatinama TCP taisykle, todėl QUIC klausytojui reikia savo selektoriaus, kitaip jis toliau naudos tunelį, kol HTTPS veikia. Išsaugokite taisykles, prie kurių apsistosite, komponente, kuris valdo sąsają, ir patvirtinkite jas po pakartotinio prisijungimo ar DHCP atnaujinimo. Kai konkuruojantis valdytojas po perkrovimo pašalina vykdymo laiko maršrutą, tai yra nuosavybės problema, kurią reikia taisyti šaltinyje, o ne priežastis pridėti platesnių NAT taisyklių viršuje.