Zakaj varnostna politika IPsec ni vnos v usmerjevalni tabeli

Pošljite ping na 10.20.0.5 skozi tunel in nič se ne vrne, medtem ko usmerjevalna tabela vztraja, da je to podomrežje dosegljivo. Usmerjanje in IPsec odgovarjata na različna vprašanja in samo eno od njiju je o dosegljivosti. Iskanje naprej izbere pot, nato baza varnostne politike odloči, ali je treba to pot zaščititi, pustiti pri miru ali zavrniti. Ko se dva ne strinjata, paket tiho umre, zato ju berite v tem vrstnem redu.

Začnite z iskanjem, ne s tabelo

Vprašajte jedro, kaj bi v resnici naredilo: ip route get 10.20.0.5 izpiše izbrano pot, izhodni vmesnik in naslov vira, ki bi ga uporabilo. Predpona, pravilo politike, oznaka ali prednostni vir lahko spremenijo ta odgovor, zato iskanje v živo premaga branje tabele z očesom.

Preizkusite cilj znotraj zaščitenega obsega, ne naslova prehoda. Doseči prehod na drugi strani dokaže le, da neka pot obstaja; ne pove ničesar o podomrežju, ki ga v resnici potrebujete. Nato potrdite, da je vmesnik, ki ga je izbralo iskanje, tisti, ki ga pričakujete od tunela.

Ujemite selektorje na obeh straneh

Baza politike ima svoje vnose in vsak navaja smer, vir, cilj in protokol, nato pa pove, kaj naj se zgodi z ujemajočimi paketi. Za seznam uporabite ip xfrm policy; zastavice kažejo, ali je dejanje zaščita, obhod ali blokada. Politika, katere selektorji so širši ali ožji od vašega preskusnega toka, se z njim ne bo ujemala in paket odide nezaščiten. To je okvara, ki jo iščete, ne manjkajoča pot.

Primerjajte dejanske vrednosti: vir, cilj, protokol in vrata. Če je iskanje razrešilo en par naslovov, medtem ko vnos politike pokriva drugega, oba pogleda opisujeta različen promet. Preden sklepate, zaženite oba znova z istim tuple, sicer boste urejali politiko, ki ni bila nikoli na poti.

Ujemanje politike ni nameščeno stanje

Ujemajoča politika samo pove, da mora biti paket zaščiten; jedro še vedno potrebuje varnostno asociacijo, da izvede zaščito. Naštejte jih z ip xfrm state ali s swanctl --list-sas, ko pogajanja vodi strongSwan, in preberite selektorje in števce pri vsakem vnosu.

Ko politika ustreza in nobena asociacija ne pokriva istih selektorjev, se paket zavrže, namesto da bi bil poslan v jasnem besedilu. To je zavrženje, ki ga je treba iskati, ko tunel deluje, a eno podomrežje odpove. Števci povedo ostalo: asociacija, ki nikoli ne raste, ni bila nikoli izbrana, tista, ki raste in vseeno konča z zavrženjem, pa kaže na oddaljeno stran. Popravljanje selektorjev in obnavljanje ključev sta različni popravili, zato se odločite, katero potrebujete, preden se dotaknete konfiguracije.

Kaj potni tunel še vedno zahteva

Vmesnik XFRM naredi, da je tunel videti kot naprava, v katero lahko usmerjate, kar je resnično koristno. Ne odstrani pa politike in stanja, ki odločata, kaj se zgodi, ko paket prispe tja. Pot prispeva naslednji skok in nič več.

Če naprava obstaja in pot kaže vanjo, medtem ko nobena asociacija ne ustreza notranjim selektorjem, se paket zavrže in nobena količina urejanja poti ne ustvari ključev ali selektorjev. Preverite vmesnik z istim virom in ciljem, ki ste ju usmerili, nato to primerjajte s seznamom stanj.

Pred urejanjem česarkoli razčistite lastništvo

Požarni zid gostitelja doda tretjo odločitev, ki je ne pozna nobena od obeh baz. Pravilna pot plus ujemajoča politika plus nameščena asociacija se lahko še vedno končajo z zavrženim paketom, aplikacija pa poroča le o poteku časa. Potrdite, da požarni zid dovoljuje zaščiten promet, preden obtožite IPsec. Zajem na tunelski napravi in na fizičnem vmesniku pokaže, na kateri strani šifriranja je paket izginil.

Lastništvo konfiguracije odloči, ali bo vaš popravek preživel ponovni zagon. Ena komponenta lahko namesti stanje, medtem ko druga upravlja poti, in ročni popravek druge se prepiše ob naslednjem dvigu tunela. Spremenite konfiguracijo lastnika in nato znova preberite oba pogleda; RFC 4301 drži obe bazi ločeni, ko morate razdelitev razložiti nekomu drugemu.