IPsec en IPsec: kiujn adresojn la ekstera tunelo devas porti

Nestita IPsec estas pli facile pripensebla kiam la du tavoloj finiĝas sur malsamaj maŝinoj. Kvar enirejoj, du tuneloj kaj unu demando, kiu decidas ĉu la dezajno funkcias: kion la ekstera tunelo efektive vidas kiam la interna finis kun la pako? Respondu tion, kaj la selektiloj, la itineroj kaj la sinsekvo de problemtraktado sekvas. Se vi eraras, vi pasigos tagon serĉante cimojn en tunelo, kiu teknike estas aktiva.

La modelo kun kvar enirejoj

La eksteraj enirejoj A kaj B konstruas la unuan tunelon inter la du lokoj. Malantaŭ A sidas la interna enirejo C kun transira adreso 10.60.0.2; malantaŭ B sidas la interna enirejo D kun transira adreso 10.70.0.2. La aplikaĵaj retoj vivas malantaŭ C kaj D, kaj ĉiu adreso en la ekzemplo intence ne interkovriĝas.

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

Dividi la tavolojn inter kvar gastigantoj signifas, ke ĉiu maŝino plenumas unu limon. Unu sola gastiganto, kiu rulas ambaŭ tavolojn, devas akordigi du arojn da politikoj, du itinertabelojn kaj du fiaskmanierojn sur unu maŝino, kio estas ebla kaj multe pli malfacile observebla.

Ĉiu tavolo forigas nur sian propran protekton

C ĉifras aplikaĵan pakon por D. La rezulto estas adresita de C al D, kaj tio estas kio atingas A. Ĉio malsupre dependas de tiu reskribo.

A ĉifras ĝin denove por B. B malĉifras la eksteran tavolon, vidas pakon de C al D kaj plusendas ĝin ankoraŭ ĉifrita. D forigas la internan protekton kaj liveras la aplikaĵan pakon.

Do A kaj B vidas la internajn finpunktojn kaj iliajn metadatenojn, sed ili ne estas la partioj, kiuj malĉifras la aplikaĵan utilŝarĝon. Tio estas reala eco de la dezajno, ne aserto, ke C, D aŭ la aplikaĵaj gastigantoj estas fidindaj.

La eksteraj selektiloj nomas la internajn enirejojn

Ĉi tie malsukcesas la plej multaj el ĉi tiuj konstruoj. Por politikbazita ekstera tunelo, la selektiloj, kiujn vi intertraktas, devas enhavi la adresojn, kiujn A kaj B efektive pritraktas: 10.60.0.2/32 kaj 10.70.0.2/32, en la ĝusta loka kaj fora ordo.

Meti la finajn aplikaĵajn subretojn en la eksterajn selektilojn ne funkcias, ĉar kiam pako atingas A, la interna enkapsuligo jam reskribis tion, kion A devas protekti. La ekstera politiko tiam kongruus kun nenio, kaj la tunelo leviĝus portante neniujn datumojn.

Ne mallarĝigu la eksteran permeson al UDP 500. La interna konekto havas sian propran datumpadon, kiu uzas ESP aŭ UDP-enkapsuligon laŭ tio, kion ĝi intertraktis, kaj la ekstera politiko devas permesi tiun protokolon.

Kontrolu la rezulton per swanctl --list-sas sur ĉiu enirejo kaj konfirmu, ke la infanaj sekurecaj asocioj raportas la adresojn, kiujn vi intencis, ne tiujn, kiujn vi supozis. Se la listo montras la aplikaĵajn subretojn, la ekstera politiko estis skribita por la malĝusta tavolo. Riparu la selektilojn antaŭ ol senerarigi la itineralancon, ĉar la itineralanco aspektos bone kaj la nombriloj ne moviĝos.

Plusendo kaj la rekursia kaptilo

Selektiloj ne anstataŭas itineralancon. A kaj B devas plusendi trafikon inter C kaj D en ambaŭ direktojn, kio signifas ŝaltitan IP-plusendon, itinerojn montrantajn al la tunelo kaj returnan vojon, kiu ekzistas ĉe la alia flanko.

Se la ekstera tunelo uzas XFRM-interfacojn, itineroj elektas la interfacon dum la intertraktitaj politikoj ankoraŭ limigas tion, kion ĝi portas. Interfaco ne larĝigas la protektitan; ĝi nur ŝanĝas kiel la kerno prenas la pakon.

La kaptilo estas rekursio. La itinero de A al la ekstera finpunkto de B devas sekvi la suban reton, ne la tunelon, kiun A starigas, alie la enkapsuligo provas vojaĝi ene de si mem kaj la konekto neniam finiĝas.

Ekzamenu tradukadon antaŭ ol aldoni tavolojn

Rigardu ajnan fontan NAT ĉe A kaj B antaŭ ol agordi ion alian. Regulo, kiu reskribas la adreson de C antaŭ ol la IPsec-politiko aplikiĝas, povas rompi la interkonsentitajn selektilojn, kaj ĝi ankaŭ povas ŝanĝi tion, kion D ricevas ĉe la alia flanko.

Vasta maskado ne fariĝas pli sekura pro du tavoloj. Ĝi kaŝas, kiun adreson vidas la fora flanko, kaj tio estas ĝuste la informo, kiun vi bezonas kiam la tunelo estas aktiva kaj la aplikaĵo ne.

Se NAT-regulo vere necesas, skribu, kun kiu adreso ĉiu flanko opinias, ke ĝi parolas. Tiu unu linio solvas la plej multajn disputojn pri tio, ĉu la tunelo aŭ la tradukado kulpas. Ĝi ankaŭ diras al la sekva inĝeniero, kie rigardi kiam la regulo estos forigita post jaro. Ping faros neniun el tiuj.

Pruvu fail-closed kaj kontrolu la MTU

Malaperanta itinero ne estas per si mem fail-closed-politiko. Alia tabelo, defaŭlta itinero aŭ politika regulo povas silente provizi alternativon, kaj la sola maniero scii estas mallevi la eksteran tunelon kaj observi, kion faras la aplikaĵa trafiko. Faru tion intence, en fenestro, anstataŭ malkovri ĝin hazarde.

Testu tri statojn: ekstera tunelo malsupre, interna tunelo malsupre kaj resaniĝo post kiam ambaŭ revenos. Uzu politiknombrilojn ĉe ĉiu enirejo, ĉar du establitaj IKE-sesioj pruvas nur, ke la intertraktado de la rega ebeno sukcesis.

Buĝetu por ambaŭ enkapsuligoj. Funkcianta IKE estas rezulto de malgrandaj pakoj, kaj plenmezuraj aplikaĵaj pakoj ankoraŭ povas malsukcesi post aldono de du kapoj; testu per konata utilŝarĝa grando sur la reala vojo anstataŭ supozi, ke la nombroj sumiĝas. La aritmetiko estas facila, la vojo ne.