Kodėl IPsec saugumo politika nėra maršrutų lentelės įrašas

Siųskite ping į 10.20.0.5 per tunelį ir nieko negrįžta, nors maršrutų lentelė tvirtina, kad tas potinklis pasiekiamas. Maršrutizavimas ir IPsec atsako į skirtingus klausimus, ir tik vienas iš jų apie pasiekiamumą. Tiesioginė paieška pasirenka kelią, tada saugumo politikos duomenų bazė nusprendžia, ar tą kelią reikia apsaugoti, palikti kaip yra, ar atmesti. Kai du nesutaria, paketas tyliai miršta, todėl skaitykite juos šia tvarka.

Pradėkite nuo paieškos, o ne nuo lentelės

Paklauskite branduolio, ką jis iš tikrųjų darytų: ip route get 10.20.0.5 parodo pasirinktą maršrutą, išeinančią sąsają ir šaltinio adresą, kurį naudotų. Prefiksas, politikos taisyklė, žymė arba pageidaujamas šaltinis gali pakeisti šį atsakymą, todėl gyva paieška pranoksta lentelės skaitymą akimis.

Išbandykite tikslą apsaugotame diapazone, o ne tarpinės adresą. Pasiekti kitos pusės tarpinę tik įrodo, kad koks nors maršrutas egzistuoja; tai nieko nesako apie potinklį, kurio jums iš tikrųjų reikia. Tada patvirtinkite, kad paieškos pasirinkta sąsaja yra ta, kurią tikitės naudos tunelis.

Suderinkite selektorius abiejose pusėse

Politikos duomenų bazė turi savo įrašus, ir kiekvienas nurodo kryptį, šaltinį, tikslą ir protokolą, o tada pasako, kas turi nutikti atitinkantiems paketams. Naudokite ip xfrm policy, kad juos išvardytumėte; vėliavėlės rodo, ar veiksmas yra apsauga, apėjimas ar blokavimas. Politika, kurios selektoriai platesni arba siauresni už jūsų bandomąjį srautą, neatitiks jo, ir paketas išvyks neapsaugotas. Tai tas gedimas, kurio ieškote, o ne trūkstamas maršrutas.

Palyginkite faktines reikšmes: šaltinį, tikslą, protokolą ir prievadus. Jei paieška išsprendė vieną adresų porą, o politikos įrašas apima kitą, abi peržiūros apibūdina skirtingą srautą. Prieš darydami išvadą dar kartą paleiskite abu su ta pačia eilute, kitaip redaguosite politiką, kuri niekada nebuvo kelyje.

Politikos atitikimas nėra įdiegta būsena

Atitinkanti politika tik sako, kad paketas turi būti apsaugotas; branduoliui vis tiek reikia saugumo asociacijos apsaugai atlikti. Išvardykite jas naudodami ip xfrm state arba swanctl --list-sas, kai derybas veda strongSwan, ir perskaitykite kiekvieno įrašo selektorius ir skaitiklius.

Kai politika atitinka, o jokia asociacija neapima tų pačių selektorių, paketas išmetamas, o ne siunčiamas atviru tekstu. Tai tas išmetimas, kurio reikia ieškoti, kai tunelis veikia, bet vienas potinklis nepavyksta. Skaitikliai pasako likusį: asociacija, kuri niekada neauga, niekada nebuvo pasirinkta, o ta, kuri auga ir vis tiek baigiasi išmetimu, nurodo į tolimąją pusę. Selektorų taisymas ir raktų atnaujinimas yra skirtingi taisymai, todėl nuspręskite, kurio jums reikia, prieš liesdami konfigūraciją.

Ko maršrutu pagrįstas tunelis vis dar reikalauja

XFRM sąsaja leidžia tuneliui atrodyti kaip įrenginiui, į kurį galima maršrutizuoti, ir tai tikrai naudinga. Ji nepašalina politikos ir būsenos, kurios nusprendžia, kas nutiks, kai paketas ten atvyks. Maršrutas suteikia kitą šuolį ir nieko daugiau.

Jei įrenginys egzistuoja ir maršrutas rodo į jį, bet jokia asociacija neatitinka vidinių selektorių, paketas išmetamas, ir joks maršrutų redagavimas nesukuria raktų ar selektorių. Patikrinkite sąsają su tuo pačiu šaltiniu ir tikslu, kuriuos maršrutizavote, tada palyginkite tai su būsenų sąrašu.

Išsiaiškinkite nuosavybę prieš ką nors redaguodami

Priimančiojo ugniasienė prideda trečią sprendimą, apie kurį nežino nė viena iš dviejų duomenų bazių. Teisingas maršrutas plius atitinkanti politika plius įdiegta asociacija vis tiek gali baigtis išmestu paketu, o programa praneša tik apie skirtąjį laiką. Patvirtinkite, kad ugniasienė leidžia apsaugotą srautą, prieš kaltindami IPsec. Fiksavimas tunelio įrenginyje ir fizinėje sąsajoje parodo, kurioje šifravimo pusėje paketas dingo.

Konfigūracijos nuosavybė nusprendžia, ar jūsų pataisa išliks po perkrovimo. Vienas komponentas gali įdiegti būseną, o kitas valdo maršrutus, ir rankinis antrojo pakeitimas bus perrašytas, kai tunelis kitą kartą pakils. Pakeiskite savininko konfigūraciją, tada dar kartą perskaitykite abi peržiūras; RFC 4301 laiko dvi duomenų bazes atskirai, kai turite paaiškinti tą padalijimą kam nors kitam.