Kodėl OpenVPN maršrutas pralaimi strongSwan XFRM politikai

Konkretus OpenVPN maršrutas nepanaikina XFRM politikos: perskaitykite maršrutą ir politikos selektorius, tada susiaurinkite, padarykite išimtį arba pereikite prie XFRM sąsajos.

Paketai gali eiti OpenVPN maršrutu ir vis tiek būti pagauti IPsec politikos, o šis derinys iš visų pusių atrodo kaip maršrutizavimo klaida, išskyrus teisingą. Linux išsprendžia maršrutą ir tada kreipiasi į atskirą saugumo politikų duomenų bazę, todėl konkretesnis paskirties maršrutas neišstumia atitinkančios XFRM politikos. Matomas simptomas yra srautas, kuris palieka mazgą ir niekada neatvyksta, nors abu tuneliai praneša esą sveiki. Tai sprendžia trys variantai, o kurį pasirinksite, priklauso nuo to, kuris iš dviejų kelių turėtų nešti tą prefiksą.

Du sprendimai, o ne vienas

Maršruto parinkimas atsako į siaurą klausimą: koks kitas šuolis ir šaltinio adresas turi nešti šį paketą. Saugumo politikų duomenų bazė atsako į kitą: ar šiam paketui reikia IPsec apsaugos ir pagal kokius selektorius. Abu veikia tam pačiam paketui, ir pirmojo įvykdymas nieko nesako apie antrąjį. Štai kodėl metrikos pakeitimas ar statinio maršruto pridėjimas gali palikti simptomą nepaliestą.

Platus IPsec selektorius yra įprasta priežastis. Politika, sauganti 172.16.0.0/12, taip pat apima 172.20.8.0/24, kur administratorius galbūt ketina pasiekti per OpenVPN tunelį. Ketinimas egzistuoja tik maršrutizavimo lentelėje, o politikų duomenų bazė apie jį niekada nesužinojo.

Traktuokite tai kaip konfliktą tarp dviejų sukonfigūruotų apsaugos kelių, o ne kaip dviejų metrikų varžybas. Pataisa priklauso tam komponentui, kuris buvo sukonfigūruotas su neteisinga apimtimi.

Perskaitykite maršrutą, kurį branduolys iš tikrųjų pasirenka

Pradėkite nuo paieškos, kurią atlieka branduolys, įskaitant šaltinio adresą ir bet kurią politikos taisyklę, galinčią jį nukreipti į kitą lentelę. Pagrindinės lentelės maršrutas gali būti niekada neperžiūrėtas, jei ankstesnė taisyklė pasirenka kitą lentelę, o ilgiausio prefikso atitikimas galioja tik toje lentelėje, kurią pasirenka taisyklė.

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

Paskutinė komanda yra svarbiausia, nes ji išspausdina pasirinktą maršrutą kartu su šaltinio adresu, kurį branduolys naudotų. Palyginkite šią išvestį su selektoriumi, kurį atitinka IPsec politika. Kai maršrutas rodo į OpenVPN sąsają, o politika vis dar atitinka tą pačią porą, jūs atkūrėte konfliktą nespėliodami.

Laikykite išrašus be nesusijusių adresų, kol jie nepasiekė bilieto. Produkcinio mazgo maršrutizavimo lentelė neša vidinę topologiją, ir tik tuos eilutes, kurios atsako į klausimą, verta įklijuoti.

Perskaitykite ir politiką, kuri taip pat galioja

Politikų sąrašas rodo kryptį, selektorius ir šabloną, kuris nusprendžia, kas nutinka atitinkančiam paketui. Pirmiausia skaitykite išėjimo kryptį, paskui įėjimo pusę grįžtančiam srautui, nes vienpusė išimtis sukuria ryšį, kuris prasideda ir niekada nepasibaigia.

ip -s xfrm policy
swanctl --list-sas

Palyginkite sąrašo selektorius su prefiksais, dėl kurių susiderėjo ryšys. Išjungus strongSwan maršrutų įdiegimą tos politikos nedingsta, o metrikos pakeitimas nekeičia, kurią šaltinio ir paskirties porą politika saugo. Šias dvi tariamas pataisas verta atmesti anksti, nes žmonės jų pirmiausia imasi.

Jei sąraše nėra politikos laukiamam prefiksui, problema yra kitur ir maršrutizavimo lentelė tikriausiai sako tiesą. Jei jame yra platesnė politika, apimanti prefiksą, radote pagavimą.

Trys variantai, kai abu keliai teisėti

Susiaurinti IPsec selektorių yra švariausias variantas, kai platus prefiksas buvo patogumas, o ne reikalavimas. Nuotolinio srauto selektoriaus sumažinimas iki potinklių, kurie tikrai priklauso už IPsec, pašalina konfliktą visiems mazgams iš karto, ir tai kainuoja raktų pakartotinį derėjimąsi, o ne naują komponentą.

Pralaidumo išimtis yra chirurginis variantas, kai platus selektorius turi likti. strongSwan palaiko atskirą ryšį, kurio vaikas naudoja pass režimą, ir tai branduoliui pasako, kad atitinkančio srauto IPsec neturi apdoroti. Loopback nuotolinis adresas neleidžia to ryšio pasirinkti įeinantiems partneriams, o selektoriai turi aprašyti tikrąją leidžiamą porą, o ne viską.

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 konfigūracijos pavyzdžiai dokumentuoja šį politikos tipą ir loopback partnerio konvenciją. Trečias variantas yra maršrutu pagrįstas dizainas su XFRM sąsajomis, kuris politiką sieja su srautu, maršrutizuojamu per įvardytą sąsają, o ne su visuotiniu selektoriumi. Tai migracija, o ne derinimas, ir srautas vis tiek turi atitikti suderėtus selektorius.

OptionUse it whenCost
Narrow the selectorThe broad prefix was convenienceA rekey and a policy review
Passthrough childThe broad selector must stayOne exception per intended pair
XFRM interfacePolicy should follow routingA design migration

Įrodykite išimtį nesusilpnindami likusios dalies

Įkėlę pakeitimą, išbandykite išimtį ir įprastą paskirties vietą, kuri turi likti apsaugota. Patikrinkite abi kryptis, tada numeskite OpenVPN tunelį ir patvirtinkite, kas nutinka išimtam srautui. Išimtis, kuri tyliai siunčia tą prefiksą atvirai, kai tunelis yra išjungtas, yra politikos sprendimas, kurį turėtumėte priimti sąmoningai, o ne atrasti per incidentą.

Užrašykite, kuris prefiksas naudoja kurį kelią ir kodėl. Priešingu atveju sekantis inžinierius, pamatęs platų selektorių, vėl atvers tą patį tyrimą, o atsakymas gulės commit žinutėje, kurios niekas neskaito.

Susiję straipsniai