Kodėl OpenVPN klientai nepataiko į vartų IPsec selektorius

Siųskite ping iš vartų į hostą už nutolusio IPsec tunelio ir jis atsako švariai, tad tunelis atrodo sveikas, o bilietas juda toliau. Tada prisijungęs klientas bando tą patį hostą ir nieko negauna. Tas ping niekada nebuvo kliento srauto įrodymas, nes jis išėjo su pačių vartų šaltinio adresu ir atitiko kitą IPsec selektorių. Supratimas, kodėl šie du atvejai skiriasi, yra didžioji pataisymo dalis.

Vartų ping tikrina srautą, kurio jūsų klientas niekada nenaudoja

Šaltinio adresas nusprendžia, kuri politika galioja. Vartuose sukurtas paketas išeina su adresu iš jų vietinio LAN arba iš tunelio galinio taško, o jį atitinkanti politika buvo parašyta būtent tam atvejui. Kliento paketas atvyksta į OpenVPN sąsają su adresu iš klientų telkinio, o tai yra visiškai kitas selektorius.

Todėl gedimas atrodo kaip maršrutizavimo problema, nors iš tikrųjų tai politikos apimties problema. Pasiekiamumas iš vartų įrodo, kad partneris veikia ir pasiūlymai buvo suderinti, ir neįrodo nieko apie tai, ar telkinys apsaugotas.

Stumkite nutolusį priešdėlį, kurio programai tikrai reikia

Paimkite iliustracinę porą 10.8.0.0/24 prisijungusiems klientams ir 172.30.239.0/25 apsaugotam nutolusiam tinklui. Klientui reikia maršruto į antrąjį priešdėlį, o ne į vartų LAN ir ne į kokį nors kitą tunelio adresą. Į telkinį stumiamas maršrutas yra tai, kas apskritai priverčia klientą perduoti tą srautą vartams. Be jo paketas niekada nepasieks politikos sprendimo, kurį derinate.

Community serveryje, kuris priima stumiamus maršrutus, direktyva ima tikrąją kaukę: push "route 172.30.239.0 255.255.255.128". Access Server sukonfigūruoja tą pačią paskirties vietą per įdiegtos versijos privataus tinklo arba prieigos taisyklių nustatymus, sąmoningai pasirenkant maršrutizuotą arba išverstą režimą. Generuojamų ugniasienės grandinių redagavimas vietoj jas valdančios konfigūracijos yra kelias, kuriuo veikianti instaliacija tampa neatsinaujinama.

Prisijungę skaitykite kliento maršrutizavimo lentelę, o ne serverio ketinimą. Maršrutas, apimantis tik telkinį, reiškia, kad stūmimas neatėjo, o numatytasis maršrutas per tunelį yra platesnis už šį reikalavimą ir vėliau jus nustebins. Patikrinkite kaukę ir priešdėlį, nes /25, stumiamas kaip /24, siunčia kaimyninių adresų srautą keliu, kuris jo negali nešti. Tada patvirtinkite, kad klientas šiai paskirties vietai pasirinko tunelio sąsają.

Padarykite, kad selektoriai apimtų klientų telkinį

Maršrutizuotai prieigai, kuri išsaugo klientų adresus, IPsec politika turi apsaugoti srautą tarp telkinio ir nutolusio priešdėlio. Selektoriai, parašyti pačių vartų LAN tinklui, praleidžia ping ir išmeta kliento užklausą, ir tai yra būtent ta asimetrija, kuri pradėjo šį tyrimą.

Išnagrinėkite suderintą politiką ir sukonfigūruotus pasiūlymus, pavyzdžiui, su ipsec statusall strongSwan sistemoje arba lygiaverte būsenos komanda jūsų įgyvendinimui. Politikomis grindžiamame IPsec įprastas maršrutas gali rodyti į fizinę sąsają, o atitinkantis srautas vis tiek šifruojamas, tad trūkstamas tunelio įtaisas nieko neįrodo. Palyginkite selektorių poras su telkiniu ir priešdėliu, kuriuos užsirašėte.

Bendras šaltinio NAT vartuose taip pat gali sugriauti atitikimą. Jei masquerade taisyklė perrašo kliento šaltinį prieš politikos patikrą, paketas nebeatrodys kaip jūsų parašytas selektorius. Tai viena priežasčių, kodėl plati masquerade taisyklė yra prastas antro VPN sprendimas: ji pakeičia, kuri politika galioja ir kokį adresą registruoja nutolusi pusė. Išskirkite srautą, kurį ketinate maršrutizuoti, arba sąmoningai jį išverskite ir atnaujinkite selektorius.

Sąmoningai rinkitės maršrutizavimą arba vertimą

Maršrutizavimas palieka kliento adresą matomą nutolusiai pusei, todėl nutolę žurnalai ir taisyklės pagal šaltinį išlieka prasmingi, ir reikalauja, kad nutolę vartai žinotų grįžimo kelią į telkinį. Vertimas paslepia telkinį už vieno adreso, o tai pašalina grįžimo maršruto problemą ir sunaikina kiekvieno kliento tapatybę.

Pasirinkite vieną sprendimą ir užrašykite jį, nes abiem reikia skirtingų selektorių ir skirtingos ugniasienės tvarkos. Pusiau pritaikytas masquerade atsiduria tarp jų ir netenkina nė vieno. Užrašytas pasirinkimas taip pat leidžia kitam inžinieriui atskirti klaidą nuo sąmoningo sprendimo.

Uždarykite ciklą persiuntime ir atsakyme

Vartai turi persiųsti protokolą ir paskirties vietą, kurią turite omenyje, o tai reiškia įjungtą IP persiuntimą ir persiuntimo grandinę, leidžiančią porą. Tada nutolusi pusė turi siųsti atsakymus atgal IPsec keliu, ir tai yra maršrutizavimo sprendimas jų vartuose, o ne jūsų. Abi pusės yra įprasta konfigūracija, ir abi lengvai paliekamos nebaigtos. Išbandykite jas atskirai, kad trūkstama persiuntimo taisyklė nebūtų palaikyta sugedusiu tuneliu.

Patikrinkite viena tikra užklausa iš kliento į programą, stebėdami, kaip ji kerta OpenVPN sąsają, IPsec sprendimą ir nutolusį hostą. Nagrinėkite atsakymą kaip atskirą stebėjimą, nes atvykstanti užklausa ir atsakymas, kuris niekada negrįžta, iš kliento vietos atrodo vienodai. Viena atsekta užklausa verta daugiau nei bet kiek ping iš vartų.

Laikykite paskirties leidimą siaurą testuodami ir patvirtinkite, kad klientas be taisyklės negali pasiekti paslaugos. Įdiegtas maršrutas ir užmegztas susiejimas nėra tas pats, kas suteikta prieiga.