IPsec IPsec viduje: kokius adresus turi nešti išorinis tunelis

Duokite išoriniam tuneliui vidinių šliuzų adresus, o ne programų potinklius. Tada įrodykite persiuntimą, vertimą ir MTU kiekviename sluoksnyje, prieš vadindami tai įdėtuoju.

Įdėtąjį IPsec lengviau apgalvoti, kai du sluoksniai baigiasi skirtingose mašinose. Keturi šliuzai, du tuneliai ir vienas klausimas, lemiantis, ar sprendimas veikia: ką išorinis tunelis iš tikrųjų mato, kai vidinis baigia su paketu? Atsakykite į tai, ir selektoriai, maršrutai bei trikčių šalinimo tvarka ateis savaime. Suklysite — praleisite dieną derindami tunelį, kuris techniškai yra aktyvus.

Keturių šliuzų modelis

Išoriniai šliuzai A ir B stato pirmąjį tunelį tarp dviejų vietovių. Už A yra vidinis šliuzas C su tranzito adresu 10.60.0.2; už B yra vidinis šliuzas D su tranzito adresu 10.70.0.2. Programų tinklai gyvena už C ir D, ir kiekvienas pavyzdyje esantis adresas sąmoningai nesutampa.

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

Sluoksnių padalijimas keturiems kompiuteriams reiškia, kad kiekviena mašina įgyvendina vieną ribą. Vienas kompiuteris, vykdantis abu sluoksnius, turi suderinti du politikos rinkinius, dvi maršrutų lenteles ir du gedimo režimus vienoje mašinoje, o tai įmanoma ir daug sunkiau stebima.

Kiekvienas sluoksnis pašalina tik savo apsaugą

C užšifruoja programos paketą D. Rezultatas adresuojamas iš C į D, ir būtent tai pasiekia A. Viskas toliau priklauso nuo šio perrašymo.

A užšifruoja jį dar kartą B. B iššifruoja išorinį sluoksnį, pamato paketą iš C į D ir persiunčia jį vis dar užšifruotą. D pašalina vidinę apsaugą ir pristato programos paketą.

Taigi A ir B mato vidinius galinius taškus ir jų metaduomenis, bet nėra šalys, kurios iššifruoja programos naudingąją apkrovą. Tai tikra dizaino savybė, o ne teiginys, kad C, D ar programų kompiuteriai yra patikimi.

Išoriniai selektoriai įvardija vidinius šliuzus

Čia žlunga dauguma tokių konstrukcijų. Politikos pagrindu veikiančiam išoriniam tuneliui selektoriai, dėl kurių deratės, turi turėti adresus, kuriuos A ir B iš tikrųjų tvarko: 10.60.0.2/32 ir 10.70.0.2/32, teisinga vietine ir nuotoline tvarka.

Galutinių programų potinklių dėjimas į išorinius selektorius neveikia, nes kai paketas pasiekia A, vidinė inkapsuliacija jau perrašė tai, ką A turi apsaugoti. Tuomet išorinė politika nieko neatitiktų, o tunelis pakiltų nenešdamas duomenų.

Nesusiaurinkite išorinio leidimo iki UDP 500. Vidinė jungtis turi savo duomenų kelią, kuris naudoja ESP arba UDP inkapsuliaciją pagal tai, dėl ko susitarta, ir išorinė politika turi leisti tą protokolą.

Patikrinkite rezultatą naudodami swanctl --list-sas kiekviename šliuze ir patvirtinkite, kad antrinės saugos asociacijos praneša tuos adresus, kurių ketinote, o ne tuos, kuriuos numatėte. Jei sąrašas rodo programų potinklius, išorinė politika parašyta netinkamam sluoksniui. Pataisykite selektorius prieš derindami maršrutus, nes maršrutai atrodys gerai, o skaitikliai nejudės.

Persiuntimas ir rekursijos spąstai

Selektoriai nepakeičia maršrutizavimo. A ir B turi persiųsti srautą tarp C ir D abiem kryptimis, tai reiškia įjungtą IP persiuntimą, į tunelį nukreiptus maršrutus ir grįžimo kelią, kuris egzistuoja kitoje pusėje.

Jei išorinis tunelis naudoja XFRM sąsajas, maršrutai parenka sąsają, o suderėta politika vis dar riboja, ką ji neša. Sąsaja neišplečia saugomos srities; ji tik pakeičia, kaip branduolys paima paketą.

Spąstai yra rekursija. A maršrutas į B išorinį galinį tašką turi eiti pagrindiniu tinklu, o ne tuneliu, kurį A stato, kitaip inkapsuliacija bando keliauti savyje ir ryšys niekada nebaigiamas.

Patikrinkite vertimą prieš pridėdami sluoksnių

Pažiūrėkite į bet kokį šaltinio NAT A ir B, prieš ką nors kita derindami. Taisyklė, perrašanti C adresą prieš taikant IPsec politiką, gali sugriauti suderėtus selektorius, o taip pat gali pakeisti, ką D gauna kitoje pusėje.

Platus maskavimas netampa saugesnis dėl dviejų sluoksnių. Jis slepia, kurį adresą mato tolimoji pusė, ir būtent šios informacijos reikia, kai tunelis veikia, o programa ne.

Jei NAT taisyklė tikrai reikalinga, užrašykite, su kokiu adresu kiekviena pusė mano kalbanti. Ta viena eilutė išsprendžia daugumą ginčų, ar kalta tunelis, ar vertimas. Ji taip pat pasako kitam inžinieriui, kur žiūrėti, kai taisyklė bus pašalinta po metų. Ping to nepadarys.

Įrodykite fail-closed ir patikrinkite MTU

Maršruto dingimas pats savaime nėra fail-closed politika. Kita lentelė, numatytasis maršrutas ar politikos taisyklė gali tyliai suteikti atsarginį kelią, ir vienintelis būdas tai sužinoti yra nuleisti išorinį tunelį ir stebėti, ką daro programų srautas. Darykite tai sąmoningai, priežiūros lange, o ne atsitiktinai atrasdami.

Išbandykite tris būsenas: išorinis tunelis išjungtas, vidinis tunelis išjungtas ir atkūrimas, kai abu grįžta. Naudokite politikos skaitiklius kiekviename šliuze, nes dvi užmegztos IKE sesijos tik įrodo, kad valdymo plokštumos derybos pavyko.

Numatykite abi inkapsuliacijas. Veikiantis IKE yra mažų paketų rezultatas, o viso dydžio programų paketai vis tiek gali nepraeiti, kai pridedamos dvi antraštės; bandykite su žinomu naudingosios apkrovos dydžiu realiame kelyje, o ne manydami, kad skaičiai susidės. Aritmetika lengva, kelias ne.

Susiję straipsniai