Tas pats serverio IP, du keliai: OpenVPN išorinio srauto žymėjimas

Įprasta apsauga nuo kilpos yra maršrutas iki mazgo: siųskite srautą į viešą VPN serverio adresą per uplink, kad užšifruota sesija niekada nepatektų į savo paties tunelį. Tai veikia iki to momento, kai norite per tunelį pasiekti ir žiniatinklio paslaugą tame pačiame serveryje, nes išimtis susieta su paskirties vieta, o paskirties vieta yra ta pati. Išeitis — nustoti klasifikuoti pagal paskirties vietą ir pradėti klasifikuoti pagal tai, kuris lizdas išsiuntė paketą.

Pradėkite nuo dviejų srautų, kuriuos norite atskirti

Vienas srautas yra pats užšifruotas OpenVPN transportas, kuris turi išeiti per uplink, kitaip tunelis neštų savo paties išorinį ryšį. Kitas — įprasta HTTPS užklausa į tą patį viešą adresą, kurią norite turėti tunelio viduje, kad ji pasiektų paslaugą iš tunelio šaltinio. Ta pati paskirties vieta, daugeliu atvejų tas pats prievado numeris, kitas reikiamas kelias.

Šioje apžvalgoje tarkime, kad klientas yra 10.90.0.10 per tun1, viešas serverio adresas yra 198.51.100.25, o pagrindinė lentelė nepaliesta ir jos numatytasis maršrutas rodo į įprastą uplink. Serverio pusė taip pat turi priimti žiniatinklio paslaugą vidiniame kelyje ir grąžinti srautą tunelio šaltiniui; paketo siuntimas į viešą adresą nepanaikina serverio klausytojo ar ugniasienės politikos.

Prieš ką nors keisdami, užfiksuokite dabartines mazgo taisykles ir pasirinkite reikšmes, kurių niekas kitas nenaudoja: žymą, lentelės numerį ir tris taisyklių prioritetus. Palikite kelią atgal į mašiną, kuris neina per šį ryšį, nes klaida čia atima jūsų pačių nuotolinę prieigą, o ne tik sugadina naršyklės skirtuką.

Pažymėkite lizdą, kuris neša apvalkalą

Kliento konfigūracija gauna žymą savo užšifruotiems išeinantiems paketams ir nustoja pati diegti maršrutus, kad pakeitimo politika būtų vienintelis dalykas, lemiantis kelius:

mark 42
route-noexec
disable-dco

Dešimtainis 42 yra šešioliktainis 0x2a, ir būtent šešioliktainę formą atitiks maršrutizavimo taisyklės. Nuoroda apie link-options apibūdina mark kaip taikomą užšifruotiems išeinantiems paketams Linux sistemoje, tai yra būtent tam lizdui, kurio kelią reikia valdyti. Išjungus duomenų kanalo iškrovimą, šis pavyzdys lieka vartotojo erdvės kelyje, kur žymos elgsena yra aprašytoji.

route-noexec slopina automatinį OpenVPN maršrutų pridėjimą ir šalinimą. Vietoj jų jis nieko neįdiegia, todėl nuo šio momento maršrutų savininkas turi palaikyti kiekvieną tuneliui reikalingą maršrutą. Jei po pakeitimo privati paskirties vieta išnyksta, tai yra trūkstama pakeitimo politika, o ne žymos defektas.

Nelaikykite maršruto iki mazgo pagrindinėje lentelėje 198.51.100.25 atžvilgiu, kol tai darote. Toks maršrutas iš naujo įveda būtent tą išimtį, kurią dizainas bando susiaurinti, ir laimės HTTPS srautui prieš tai, kai bus paklausta bet kuri iš žemiau pateiktų politikų.

Siųskite visa kita į tunelio lentelę

Kai tunelio sąsaja egzistuoja ir turi savo adresą, politika atrodo taip:

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

Pirmoji taisyklė išlaiko konkretžius mazgo maršrutus matomus, įskaitant bet kurį patvirtintą vietinį tinklą, o pagrindinės lentelės numatytąjį maršrutą padaro nematomą šiai paieškai. Šis skirtumas svarbus: numatytojo maršruto slopinimas nėra tas pats kaip lentelės ignoravimas, o vietinės išimtys, kurių dar reikia, išlieka būtent dėl to. Skaitykite tas išimtis po vieną, o ne manykite, kad rezultatas yra universalus avarinis jungiklis.

Nepažymėtas srautas tada patenka į tunelio lentelę, paima tunelio šaltinį ir išeina per VPN. Pažymėtas srautas nepraeina fwmark testo kitose dviejose taisyklėse ir tęsia į įprastą pagrindinę paiešką žemiau sąraše, kur vis dar yra uplink numatytasis maršrutas. Baigiamoji unreachable taisyklė yra tai, kas neleidžia nepažymėtam srautui tyliai grįžti prie uplink, kai tunelio maršruto nėra. Selektorius yra žyma nuo pradžios iki pabaigos, o paskirties adresas niekada neįeina į sprendimą.

Laikykite tą apsaugą vietoje tarp atsijungimų ir įdiekite ją kartu su visa politika, o ne rankiniu būdu. Taisyklė, kuri išnyksta su sąsaja, nėra politika, tai atsitiktinumas. Ištrynus politiką, kai tunelis nukrenta, gedimo režimas pasikeičia iš „užblokuota“ į „nutekėjo“, o pasenęs tunelio maršrutas, kuris vėliau baigiasi, yra daug lengviau paaiškinama problema nei srautas, išėjęs per netinkamą sąsają.

Tegul grįžtamasis kelias mato tą pačią žymą

Išeinančios žymos yra tik pusė mechanizmo, ir tai yra dalis, kurią dauguma reprodukcijų praleidžia. Atsakymai į užšifruotą sesiją ateina per uplink ir yra tikrinami grįžtamojo kelio, kuris klausia, ar šaltinis būtų maršrutizuojamas atgal tuo pačiu keliu. Be pagalbos ta paieška pritaiko jūsų nepažymėtą tunelio politiką ir daro išvadą, kad paketas yra netinkamoje sąsajoje.

Pataisa priklauso ugniasienės savininkui: išsaugokite žymą išeinančiame ryšyje, atkurkite ją atitinkamuose įeinančiuose paketuose ir įjunkite šaltinio patvirtintą žymų apdorojimą atitinkamam keliui. Tai, kad OpenVPN nustato lizdo žymą, neatlieka nė vieno iš šių trijų dalykų, o receptas, kuriame išvardytos tik kliento parinktys, yra nepilnas. Paprašykite šios integracijos raštu, nes tai mažiausiai matoma dizaino dalis ir lengviausiai pametama perstatant.

Laisvas grįžtamojo kelio tikrinimas taip pat nėra pakaitalas. Laisvas režimas vis tiek reikalauja, kad šaltiniui egzistuotų koks nors maršrutas, o jūsų pridėta unreachable apsauga tyčia pašalina vieną nepažymėtoms paieškoms. Užbaikite ir peržiūrėkite ryšio žymos integraciją prieš pasikliaudami šiuo dizainu, o mazgo filtrus traktuokite kaip atskirą klausimą: žyma yra maršrutizavimo signalas, ne leidimas. Jei integracijos nėra, simptomas yra sesija, kuri užmezgama ir paskui nutyla, kai tik pradeda ateiti atsakymai.

Įrodykite tai dviem maršruto paieškomis

Palyginkite, ką branduolys nusprendžia dviem kontekstais, ir skaitykite laukus dev ir src, o ne išėjimo būseną:

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

Pirmoji paieška turėtų išspręsti į tun1 su tunelio šaltiniu, o antroji į uplink. Tai sintetinės paieškos, todėl jos įrodo politiką, o ne veikiantį procesą: atskirai patvirtinkite tikrąjį veikiančio kliento transporto kelią ir tada atlikite tikrą HTTPS užklausą su įjungtu sertifikato tikrinimu.

Užsirašykite, ko dizainas neapima, prieš paskelbdami jį baigtu. DNS, IPv6 ir taisyklių gyvavimo ciklas kiekvienas reikalauja savo sprendimo, o tai yra IPv4 maršrutizavimo pavyzdys, o ne visa privatumo konfigūracija. Jo vertė yra selektorius: apvalkalas gauna uplink išimtį, o įprasta paslauga tame pačiame adrese neturi jos paveldėti.