Miks OpenVPN-i kliendid ei taba lüüsi IPsec-valijaid

Tee lüüsist ping kaugema IPsec-tunneli taga olevale hostile ja see vastab puhtalt, nii et tunnel näib terve ja pilet liigub edasi. Seejärel proovib ühendatud klient sama hosti ja ei saa midagi tagasi. See ping ei olnud kunagi kliendi voo tõestus, sest see väljus lüüsi enda lähteaadressiga ja sobis teise IPsec-valijaga. Arusaamine, miks need kaks juhtumit lahknevad, on suurem osa parandusest.

Lüüsi ping testib voogu, mida sinu klient kunagi ei kasuta

Lähteaadress otsustab, milline poliitika kehtib. Lüüsil loodud pakett väljub aadressiga selle kohalikust LAN-ist või tunneli lõpp-punktist ning sellele vastav poliitika kirjutati täpselt selle juhtumi jaoks. Kliendi pakett saabub OpenVPN-liidesele kliendipooli aadressiga, mis on hoopis teine valija.

Seetõttu näeb tõrge välja nagu marsruutimisprobleem, kuigi tegelikult on see poliitika ulatuse probleem. Lüüsist saavutatavus tõestab, et partner on üleval ja ettepanekud kokku lepitud, ning ei tõesta midagi selle kohta, kas pool on kaitstud.

Lükka kaugemale see eesliide, mida rakendus tõesti vajab

Võta näitlik paar 10.8.0.0/24 ühendatud klientide jaoks ja 172.30.239.0/25 kaitstud kaugvõrgu jaoks. Kliendil on vaja marsruuti selle teise eesliiteni, mitte lüüsi LAN-ini ja mitte mõne muu tunneli aadressini. Just pooli lükatud marsruut paneb kliendi selle liikluse üldse lüüsile üle andma. Ilma selleta ei jõua pakett kunagi poliitikaotsuseni, mida sa silud.

Community-serveris, mis võtab lükatud marsruute vastu, võtab direktiiv tõelise maski: push "route 172.30.239.0 255.255.255.128". Access Server seadistab sama sihtkoha paigaldatud versiooni privaatvõrgu või juurdepääsureeglite seadetega, valides teadlikult marsruuditud või tõlgitud režiimi. Genereeritud tulemüüriahelate muutmine vastutava konfiguratsiooni asemel on viis, kuidas töötav seadistus muutub taasesitamatuks.

Pärast ühendamist loe kliendi marsruutimistabelit, mitte serveri kavatsust. Ainult pooli kattev marsruut tähendab, et lükkamine ei jõudnud kohale, ja tunnelit läbiv vaikemarsruut on sellest nõudest laiem ning üllatab sind hiljem. Kontrolli maski ja ka eesliidet, sest /25-na lükatud /24 saadab naaberaadresside liikluse teele, mis ei suuda seda kanda. Seejärel kinnita, et klient valis selle sihtkoha jaoks tunneliliidese.

Pane valijad kliendipooli kaasama

Marsruuditud juurdepääsu puhul, mis säilitab kliendi aadressid, peab IPsec-poliitika kaitsma liiklust pooli ja kaugema eesliite vahel. Lüüsi enda LAN-i jaoks kirjutatud valijad lasevad pingi läbi ja jätavad kliendi päringu kõrvale ning just see asümmeetria algatas selle uurimise.

Uuri kokkulepitud poliitikat ja ka seadistatud ettepanekuid, näiteks käsuga ipsec statusall strongSwanis või sinu rakenduse samaväärse olekukäsuga. Poliitikapõhise IPsec-i puhul võib tavaline marsruut osutada füüsilisele liidesele, samal ajal kui sobiv liiklus on endiselt krüpteeritud, seega puuduv tunneliseade ei tõesta midagi. Võrdle valijapaare pooli ja eesliitega, mille üles kirjutasid.

Üldine lähte-NAT lüüsil võib samuti sobivuse rikkuda. Kui masquerade-reegel kirjutab kliendi lähte ümber enne poliitikakontrolli, ei näe pakett enam välja nagu sinu kirjutatud valija. See on üks põhjus, miks lai masquerade-reegel on teise VPN-i jaoks halb lahendus: see muudab, milline poliitika kehtib ja millise aadressi kaugem pool logib. Vabasta liiklus, mida kavatsed marsruutida, või tõlgi see teadlikult ja uuenda valijaid.

Vali marsruutimine või tõlkimine meelega

Marsruutimine hoiab kliendi aadressi kaugemale poolele nähtavana, nii et kauglogid ja allikapõhised reeglid jäävad mõtestatuks, ning see nõuab, et kaugem lüüs teaks tagasiteed pooli. Tõlkimine peidab pooli ühe aadressi taha, mis kõrvaldab tagasitee probleemi ja hävitab iga kliendi identiteedi.

Vali üks lahendus ja kirjuta see üles, sest need kaks vajavad erinevaid valijaid ja erinevat tulemüüri järjekorda. Poolikult rakendatud masquerade jääb nende vahele ega rahulda kumbagi. Kirja pandud valik on ka see, mis laseb järgmisel inseneril eristada viga teadlikust otsusest.

Sulge ring edastamise ja vastuse juures

Lüüs peab edastama protokolli ja sihtkoha, mida kavatsed, mis tähendab sisse lülitatud IP-edastust ja edastusahelat, mis paari lubab. Seejärel peab kaugem pool saatma vastused tagasi IPsec-teed pidi ja see on marsruutimisotsus nende lüüsil, mitte sinu omal. Mõlemad pooled on tavaline konfiguratsioon ja mõlemad jäävad kergesti pooleli. Testi neid eraldi, et puuduvat edastusreeglit ei peetaks katkiseks tunneliks.

Kontrolli ühe tõelise kliendist rakendusse suunduva päringuga, jälgides, kuidas see läbib OpenVPN-liidese, IPsec-otsuse ja kaugema hosti. Vaata vastust eraldi vaatlusena, sest kohale jõudev päring ja vastus, mis kunagi ei naase, näevad kliendi kohalt ühesugused välja. Üks jälitatud päring on väärtuslikum kui ükskõik kui palju pingi lüüsist.

Hoia sihtkoha volitus testimise ajal kitsas ja kinnita, et reeglita klient ei pääse teenuseni. Paigaldatud marsruut pluss loodud assotsiatsioon ei ole sama mis antud juurdepääs.