Kial OpenVPN-itinero perdas al strongSwan XFRM-politiko

Pakoj povas sekvi OpenVPN-itineron kaj tamen esti kaptitaj de IPsec-politiko, kaj tiu kombinaĵo aspektas kiel enkursiga cimo el ĉiu angulo krom la ĝusta. Linux solvas itineron kaj poste konsultas apartan sekurec-politikan datumbazon, do pli specifa celitinero ne forpuŝas kongruan XFRM-politikon. La videbla simptomo estas trafiko, kiu forlasas la gastigan maŝinon kaj neniam alvenas, dum ambaŭ tuneloj raportas sin sanaj. Tri opcioj solvas ĝin, kaj kiun vi elektos dependas de tio, kiun el la du vojoj devas porti tiun prefikson.

Du decidoj, ne unu

Itinera elekto respondas mallarĝan demandon: kiu sekva salto kaj fonta adreso devas porti ĉi tiun pakon. La sekurec-politika datumbazo respondas alian: ĉu ĉi tiu pako bezonas IPsec-protektadon, kaj sub kiuj selektiloj. Ambaŭ funkcias por la sama pako, kaj plenumi la unuan diras nenion pri la dua. Tial ŝanĝi metrikon aŭ aldoni statikan itineron povas lasi la simptomon netuŝita.

Larĝa IPsec-selektilo estas la kutima kaŭzo. Politiko protektanta 172.16.0.0/12 ankaŭ kovras 172.20.8.0/24, kiun administranto eble intencas atingi per la OpenVPN-tunelo anstataŭe. La intenco ekzistas nur en la enkursiga tabelo, kaj la politika datumbazo neniam sciis pri ĝi.

Traktu tion kiel konflikton inter du agorditaj protektaj vojoj, ne kiel konkurson inter du metrikoj. La korekto apartenas al tiu komponanto, kiu estis agordita kun la malĝusta amplekso.

Legu la itineron, kiun la kerno efektive elektas

Komencu per la serĉo, kiun la kerno faras, inkluzive de la fonta adreso kaj ajna politika regulo, kiu povus deturni ĝin al alia tabelo. Itinero en la ĉefa tabelo eble neniam estos konsultita, se pli frua regulo elektas alian tabelon, kaj kongruo de la plej longa prefikso validas nur ene de la tabelo, kiun regulo elektas.

ip rule show
ip route show table all
ip route get 172.20.8.20 from 10.44.7.15

La lasta komando estas la grava, ĉar ĝi presas la elektitan itineron kune kun la fonta adreso, kiun la kerno uzus. Komparu tiun eligon kun la selektilo, kiun la IPsec-politiko kongruas. Kiam la itinero montras al la OpenVPN-interfaco kaj la politiko ankoraŭ kongruas la saman paron, vi reproduktis la konflikton sen diveni.

Tenu la elprenaĵojn liberaj de nerilataj adresoj antaŭ ol ili atingos bileton. Enkursiga tabelo de produkta gastiganto portas internan topologion, kaj nur la linioj, kiuj respondas la demandon, indas esti algluitaj.

Legu la politikon, kiu ankaŭ validas

La politika listo montras direkton, selektilojn kaj la ŝablonon, kiu decidas, kio okazas al kongrua pako. Legu unue la eliran direkton, poste la eniran flankon por la revena trafiko, ĉar unudirekta escepto produktas konekton, kiu komenciĝas kaj neniam kompletiĝas.

ip -s xfrm policy
swanctl --list-sas

Komparu la selektilojn en la listo kun la prefiksoj, kiujn la konekto intertraktis. Malŝalti la itineran instaladon de strongSwan ne forigas tiujn politikojn, kaj ŝanĝi metrikon ne ŝanĝas, kiun fontan kaj celan paron politiko protektas. Tiuj du ne-korektoj indas esti frue elpelitaj, ĉar ili estas la unuaj, kiujn homoj provas.

Se la listo enhavas neniun politikon por la atendita prefikso, la problemo estas aliloke kaj la enkursiga tabelo probable diras la veron. Se ĝi enhavas pli larĝan politikon, kiu kovras la prefikson, vi trovis la kapton.

Tri opcioj, kiam ambaŭ vojoj estas legitimaj

Mallarĝigi la IPsec-selektilon estas la plej pura opcio, kiam la larĝa prefikso estis oportuneco, ne postulo. Redukti la foran trafikan selektilon al la subretoj, kiuj vere apartenas malantaŭ IPsec, forigas la konflikton por ĉiu gastiganto samtempe, kaj ĝi kostas reŝlosilan interkonsenton anstataŭ novan komponanton.

Passthrough-escepto estas la kirurgia opcio, kiam la larĝa selektilo devas resti. strongSwan subtenas apartan konekton, kies ido uzas reĝimon pass, kio diras al la kerno, ke la kongrua trafiko ne devas esti prilaborita de IPsec. La loopback-fora adreso gardas tiun konekton kontraŭ elekto por alvenantaj samtavolanoj, kaj la selektiloj devas priskribi la veran rajtigitan paron anstataŭ ĉion.

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
            }
        }
    }
}

La strongSwan-agordaj ekzemploj dokumentas ĉi tiun politikan tipon kaj la loopback-samtavolan konvencion. La tria opcio estas itinero-bazita dezajno kun XFRM-interfacoj, kiu ligas politikon al trafiko enkursigita tra nomita interfaco anstataŭ al tutmonda selektilo. Ĝi estas migrado, ne alĝustigo, kaj la trafiko ankoraŭ devas plenumi la intertraktitajn selektilojn.

Pruvu la escepton sen malfortigi la ceteron

Post ŝargi la ŝanĝon, testu la escepton kaj ordinaran celon, kiu devas resti protektita. Kontrolu ambaŭ direktojn, poste faligu la OpenVPN-tunelon kaj konfirmu, kio okazas al la esceptita trafiko. Escepto, kiu silente sendas tiun prefikson malkaŝe, kiam la tunelo estas malaktiva, estas politika decido, kiun vi faru intence, ne malkovru dum okazaĵo.

Notu, kiu prefikso uzas kiun vojon kaj kial. Alie la sekva inĝeniero, kiu vidos larĝan selektilon, remalfermos la saman esploron, kaj la respondo kuŝos en commit-mesaĝo, kiun neniu legas.