Zergatik galtzen duen OpenVPN bide batek strongSwan XFRM politikaren aurrean
OpenVPN bide jakin batek ez du XFRM politika gainditzen: irakurri bidea eta politikaren hautatzaileak, eta gero estu, salbuetsi edo joan XFRM interfaze batera.
Paketeek OpenVPN bide bat jarrai dezakete eta, hala ere, IPsec politika batek harrapa ditzake, eta konbinazio horrek bideratze akatsa dirudi angelu guztietatik zuzena izan ezik. Linuxek bide bat ebazten du eta gero segurtasun politiken datu-base bereizi bat kontsultatzen du, beraz helmuga-bide zehatzago batek ez du XFRM politika parekidea ordezkatzen. Ikusgai dagoen sintoma hosta uzten duen eta inoiz iristen ez den trafikoa da, bi tunelek osasuntsu daudela jakinarazten duten bitartean. Hiru aukerek konpontzen dute, eta zein aukeratzen duzun bi bideetatik zein den aurrizki hori eramateko behar den araberakoa da.
Bi erabaki, ez bat
Bideen hautaketak galdera estu bat erantzuten du: zein hurrengo jauzi eta iturburu-helbidek eraman behar duten pakete hau. Segurtasun politiken datu-baseak beste bat erantzuten du: pakete honek IPsec babesa behar duen, eta zein hautatzaileren pean. Biak pakete berarentzat exekutatzen dira, eta lehenengoa betetzeak ez du ezer esaten bigarrenaz. Horregatik, metrika bat aldatzeak edo bide estatiko bat gehitzeak sintoma ukitu gabe utz dezake.
IPsec hautatzaile zabal bat da ohiko arrazoia. 172.16.0.0/12 babesten duen politika batek 172.20.8.0/24 ere estaltzen du, eta administratzaileak OpenVPN tunelaren bidez iritsi nahi izan dezake hara. Asmoa bideratze-taulan bakarrik dago, eta politiken datu-baseak ez zuen inoiz haren berri izan.
Hartu hori konfiguratutako bi babes-bideren arteko gatazka gisa, bi metrikaren arteko lehia gisa baino. Konponketa gaizki konfiguratutako esparrua duen osagaiari dagokio.
Irakurri kernela benetan aukeratzen duen bidea
Hasi kernelek egiten duen bilaketarekin, iturburu-helbidea eta beste taula batera desbidera dezakeen edozein politika-arau barne. Taula nagusiko bide bat inoiz kontsultatu ez daiteke aurretik beste taula bat hautatzen badu arau batek, eta aurrizki luzeenaren parekatzea arauak hautatzen duen taularen barruan soilik aplikatzen da.
ip rule show
ip route show table all
ip route get 172.20.8.20 from 10.44.7.15
Azken komandoa da garrantzitsuena, aukeratutako bidea kernelak erabiliko lukeen iturburu-helbidearekin batera inprimatzen duelako. Konparatu irteera hori IPsec politikak parekatzen duen hautatzailearekin. Bidea OpenVPN interfazera zuzentzen denean eta politikak pare berarekin bat egiten jarraitzen duenean, gatazka asmatu gabe erreproduzitu duzu.
Mantendu dumps-ak erlaziorik gabeko helbiderik gabe tiket batera iritsi aurretik. Ekoizpen-host bateko bideratze-taulak barne-topologia dakar, eta galderari erantzuten dioten lerroak soilik merezi dute itsastea.
Irakurri ere aplikatzen den politika
Politika-zerrendak norabidea, hautatzaileak eta pakete parekide bati zer gertatzen zaion erabakitzen duen txantiloia erakusten ditu. Irakurri lehenengo irteerako norabidea, gero sarrerako aldea itzulerako trafikoarentzat, norabide bakarreko salbuespen batek hasten den eta inoiz osatzen ez den konexio bat sortzen baitu.
ip -s xfrm policy
swanctl --list-sas
Konparatu zerrendako hautatzaileak konexioak negoziatu zituen aurrizkiekin. strongSwanen bide-instalazioa desgaitzeak ez ditu politika horiek kentzen, eta metrika bat aldatzeak ez du aldatzen politikak zein iturburu-helmuga pare babesten duen. Bi konponketa faltsu horiek goiz baztertzea merezi du, jendeak lehenengo probatzen dituenak baitira.
Zerrendak espero zenuen aurrizkiarentzat politikarik ez badu, arazoa beste nonbait dago eta bideratze-taulak seguruenik egia dio. Aurrizkia estaltzen duen politika zabalago bat badauka, harrapaketa aurkitu duzu.
Hiru aukera bi bideak zilegiak direnean
IPsec hautatzailea estutzea da aukerarik garbiena aurrizki zabala eskakizuna baino erosotasuna zenean. Urrutiko trafikoaren hautatzailea IPsec-en atzean benetan dauden azpisareetara murrizteak gatazka kentzen du host guztientzat batera, eta gako-birnegoziazioa kostatzen du, osagai berri bat ez.
Passthrough salbuespena aukera kirurgikoa da hautatzaile zabalari eutsi behar zaionean. strongSwanek bere child-ak pass modua erabiltzen duen konexio bereizi bat onartzen du, eta horrek kernelari esaten dio trafiko parekidea ez dela IPsec-ek prozesatu behar. Loopback urruneko helbideak konexio hori sarrerako pareek hautatzea eragozten du, eta hautatzaileek benetako bikote baimendua deskribatu behar dute, dena ez.
connections {
openvpn-exception {
remote_addrs = 127.0.0.1
children {
openvpn-exception {
local_ts = 10.44.7.0/24
remote_ts = 172.20.8.0/24
mode = pass
start_action = trap
}
}
}
}
strongSwan konfigurazio-adibideek politika mota hau eta loopback parekidearen konbentzioa dokumentatzen dituzte. Hirugarren aukera XFRM interfazeekin bideratzean oinarritutako diseinua da, politikak hautatzaile global bati lotu beharrean izendatutako interfaze batetik bideratutako trafikoari lotzen dizkiona. Migrazioa da, doikuntza ez, eta trafikoak negoziatutako hautatzaileak bete behar ditu oraindik.
| Option | Use it when | Cost |
|---|---|---|
| Narrow the selector | The broad prefix was convenience | A rekey and a policy review |
| Passthrough child | The broad selector must stay | One exception per intended pair |
| XFRM interface | Policy should follow routing | A design migration |
Frogatu salbuespena gainerakoa ahuldu gabe
Aldaketa kargatu ondoren, probatu salbuespena eta babestuta egon behar duen ohiko helmuga bat. Egiaztatu bi norabideak, gero jaitsi OpenVPN tunela eta egiaztatu salbuetsitako trafikoari zer gertatzen zaion. Tunela behera dagoela aurrizki hori isilean argi eta garbi bidaltzen duen salbuespena nahita hartu beharreko politika-erabakia da, ez intzidente batean aurkitu beharrekoa.
Idatzi zein aurrizkik zein bide erabiltzen duen eta zergatik. Bestela, hautatzaile zabal bat ikusten duen hurrengo ingeniariak ikerketa bera berrirekiko du, eta erantzuna inork irakurtzen ez duen commit mezu batean egongo da.