Kāpēc OpenVPN maršruts zaudē strongSwan XFRM politikai

Paketes var iet pa OpenVPN maršrutu un tomēr tikt notvertas ar IPsec politiku, un šī kombinācija no visiem leņķiem izskatās kā maršrutēšanas kļūda, izņemot pareizo. Linux atrisina maršrutu un pēc tam konsultējas ar atsevišķu drošības politiku datubāzi, tāpēc konkrētāks galamērķa maršruts neizspiež atbilstošu XFRM politiku. Redzamais simptoms ir plūsma, kas atstāj resursdatoru un nekad neierodas, kamēr abi tuneļi ziņo, ka ir veseli. To risina trīs iespējas, un tas, kuru izvēlēsities, ir atkarīgs no tā, kuram no diviem ceļiem ir jānes šis prefikss.

Divi lēmumi, nevis viens

Maršruta izvēle atbild uz šauru jautājumu: kuram nākamajam lēcienam un avota adresei ir jānes šī pakete. Drošības politiku datubāze atbild uz citu: vai šai paketei nepieciešama IPsec aizsardzība un zem kuriem selektoriem. Abi darbojas vienai un tai pašai paketei, un pirmā izpilde neko nepasaka par otro. Tāpēc metrikas maiņa vai statiska maršruta pievienošana var atstāt simptomu neskartu.

Plašs IPsec selektors ir ierastais iemesls. Politika, kas aizsargā 172.16.0.0/12, aptver arī 172.20.8.0/24, kur administratoram, iespējams, ir nodoms nokļūt pa OpenVPN tuneli. Nodoms pastāv tikai maršrutēšanas tabulā, un politiku datubāze par to nekad nav uzzinājusi.

Uztveriet to kā konfliktu starp diviem konfigurētiem aizsardzības ceļiem, nevis kā divu metriku sacensību. Labojums pieder tai komponentei, kas tika konfigurēta ar nepareizo apjomu.

Izlasiet maršrutu, kuru kodols faktiski izvēlas

Sāciet ar meklēšanu, ko veic kodols, tostarp avota adresi un jebkuru politikas noteikumu, kas varētu to novirzīt uz citu tabulu. Maršruts galvenajā tabulā var tikt nekad neapskatīts, ja agrāks noteikums izvēlas citu tabulu, un garākā prefiksa atbilstība attiecas tikai uz to tabulu, kuru izvēlas noteikums.

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

Pēdējā komanda ir svarīgā, jo tā izdrukā izvēlēto maršrutu kopā ar avota adresi, kuru kodols izmantotu. Salīdziniet šo izvadi ar selektoru, kuram atbilst IPsec politika. Kad maršruts norāda uz OpenVPN interfeisu un politika joprojām atbilst tam pašam pārim, jūs esat atjaunojis konfliktu bez minējumiem.

Turiet izdrukas bez nesaistītām adresēm, pirms tās nonāk biļetē. Ražošanas resursdatora maršrutēšanas tabula satur iekšējo topoloģiju, un tikai tās rindas, kas atbild uz jautājumu, ir vērtas ielīmēšanas.

Izlasiet arī politiku, kas attiecas

Politiku saraksts parāda virzienu, selektorus un veidni, kas izlemj, kas notiek ar atbilstošu paketi. Vispirms lasiet izejošo virzienu, pēc tam ienākošo pusi atgriešanās plūsmai, jo vienvirziena izņēmums rada savienojumu, kas sākas un nekad nebeidzas.

ip -s xfrm policy
swanctl --list-sas

Salīdziniet sarakstā esošos selektorus ar prefiksiem, par kuriem savienojums vienojās. strongSwan maršrutu instalēšanas izslēgšana šīs politikas nenoņem, un metrikas maiņa nemaina, kuru avota un galamērķa pāri politika aizsargā. Šos divus viltotos labojumus ir vērts izslēgt agri, jo cilvēki tos izmēģina vispirms.

Ja sarakstā nav politikas gaidītajam prefiksam, problēma ir citur, un maršrutēšanas tabula, visticamāk, saka patiesību. Ja tajā ir plašāka politika, kas aptver prefiksu, jūs esat atradis notveršanu.

Trīs iespējas, kad abi ceļi ir likumīgi

IPsec selektora sašaurināšana ir vistīrākā iespēja, kad platais prefikss bija ērtība, nevis prasība. Attālās plūsmas selektora samazināšana līdz apakštīkliem, kas patiešām pieder aiz IPsec, novērš konfliktu visiem resursdatoriem uzreiz, un tas maksā atslēgu atkārtotu vienošanos, nevis jaunu komponenti.

Caurlaides izņēmums ir ķirurģiskā iespēja, kad platajam selektoram jāpaliek. strongSwan atbalsta atsevišķu savienojumu, kura child izmanto pass režīmu, un tas kodolam pasaka, ka atbilstošā plūsma nav jāapstrādā ar IPsec. Loopback attālā adrese neļauj šo savienojumu izvēlēties ienākošajiem partneriem, un selektoriem jāapraksta īstais atļautais pāris, nevis viss.

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 konfigurācijas piemēri dokumentē šo politikas veidu un loopback partnera konvenciju. Trešā iespēja ir maršrutā balstīts dizains ar XFRM interfeisiem, kas politiku saista ar plūsmu, kas maršrutēta caur nosauktu interfeisu, nevis ar globālu selektoru. Tā ir migrācija, nevis pielāgojums, un plūsmai joprojām jāatbilst saskaņotajiem selektoriem.

Pierādiet izņēmumu, nesavājinot pārējo

Pēc izmaiņu ielādes pārbaudiet izņēmumu un parastu galamērķi, kam jāpaliek aizsargātam. Pārbaudiet abus virzienus, pēc tam nometiet OpenVPN tuneli un apstipriniet, kas notiek ar izņēmuma plūsmu. Izņēmums, kas klusi sūta šo prefiksu atklāti, kad tunelis ir izslēgts, ir politikas lēmums, kas jāpieņem apzināti, nevis jāatklāj incidenta laikā.

Pierakstiet, kurš prefikss izmanto kuru ceļu un kāpēc. Citādi nākamais inženieris, kurš ieraudzīs plašu selektoru, atkal atvērs to pašu izmeklēšanu, un atbilde paliks commit ziņojumā, ko neviens nelasa.