IPsec v IPsec: katere naslove mora nositi zunanji tunel

O gnezdenem IPsecu je lažje razmišljati, ko se oba sloja končata na različnih strojih. Štirje prehodi, dva tunela in eno vprašanje, ki odloči, ali zasnova deluje: kaj zunanji tunel v resnici vidi, ko notranji konča s paketom? Odgovorite na to in selektorji, poti ter vrstni red odpravljanja težav sledijo. Zmotite se in boste preživeli dan z razhroščevanjem tunela, ki je tehnično aktiven.

Model štirih prehodov

Zunanja prehoda A in B zgradita prvi tunel med obema lokacijama. Za A stoji notranji prehod C s tranzitnim naslovom 10.60.0.2; za B stoji notranji prehod D s tranzitnim naslovom 10.70.0.2. Aplikacijska omrežja živijo za C in D, in vsak naslov v primeru se namerno ne prekriva.

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

Razdelitev slojev na štiri gostitelje pomeni, da vsak stroj uveljavlja eno mejo. En gostitelj, ki izvaja oba sloja, mora uskladiti dva nabora pravilnikov, dve usmerjevalni tabeli in dva načina odpovedi na enem stroju, kar je mogoče in veliko težje opazovati.

Vsak sloj odstrani le svojo zaščito

C šifrira aplikacijski paket za D. Rezultat je naslovljen od C do D in to doseže A. Vse nižje je odvisno od tega prepisa.

A ga znova šifrira za B. B dešifrira zunanji sloj, vidi paket od C do D in ga posreduje še vedno šifriranega. D odstrani notranjo zaščito in dostavi aplikacijski paket.

Tako A in B vidita notranje končne točke in njihove metapodatke, nista pa strani, ki dešifrirata aplikacijsko koristno obremenitev. To je resnična lastnost zasnove in ne trditev, da so C, D ali aplikacijski gostitelji vredni zaupanja.

Zunanji selektorji imenujejo notranje prehode

Tu spodleti večina takšnih zgradb. Za zunanji tunel, ki temelji na pravilnikih, morajo selektorji, o katerih se pogajate, vsebovati naslove, s katerimi A in B resnično ravnata: 10.60.0.2/32 in 10.70.0.2/32, v pravilnem lokalnem in oddaljenem vrstnem redu.

Postavljanje končnih aplikacijskih podomrežij v zunanje selektorje ne deluje, ker ko paket doseže A, je notranja inkapsulacija že prepisala tisto, kar mora A zaščititi. Zunanji pravilnik se potem ne bi ujemal z ničimer in tunel bi se dvignil, ne da bi prenašal podatke.

Zunanjega dovoljenja ne zožite na UDP 500. Notranja povezava ima svojo podatkovno pot, ki uporablja ESP ali inkapsulacijo UDP glede na to, kaj je bilo dogovorjeno, in zunanji pravilnik mora dovoliti ta protokol.

Preverite rezultat s swanctl --list-sas na vsakem prehodu in potrdite, da podrejene varnostne povezave poročajo naslove, ki ste jih nameravali, ne tistih, ki ste jih predpostavili. Če seznam prikazuje aplikacijska podomrežja, je bil zunanji pravilnik napisan za napačen sloj. Popravite selektorje, preden razhroščujete usmerjanje, ker bo usmerjanje videti v redu, števci pa se ne bodo premaknili.

Posredovanje in past rekurzije

Selektorji ne nadomestijo usmerjanja. A in B morata posredovati promet med C in D v obe smeri, kar pomeni omogočeno posredovanje IP, poti, ki kažejo na tunel, in povratno pot, ki obstaja na drugi strani.

Če zunanji tunel uporablja vmesnike XFRM, poti izbirajo vmesnik, medtem ko dogovorjeni pravilniki še vedno omejujejo, kaj prenaša. Vmesnik ne razširi zaščitenega; le spremeni, kako jedro pobere paket.

Past je rekurzija. Pot A do zunanje končne točke B mora slediti spodnjemu omrežju, ne tunelu, ki ga A gradi, sicer poskusi inkapsulacija potovati vase in povezava se nikoli ne dokonča.

Preglejte prevajanje, preden dodate sloje

Poglejte vsak vir NAT na A in B, preden karkoli drugega uglasite. Pravilo, ki prepiše naslov C pred uporabo pravilnika IPsec, lahko zlomi dogovorjene selektorje in lahko tudi spremeni, kaj D prejme na drugi strani.

Široko maskiranje ne postane varnejše zaradi dveh slojev. Skriva, kateri naslov vidi oddaljena stran, in to je natanko informacija, ki jo potrebujete, ko je tunel aktiven, aplikacija pa ne.

Če je pravilo NAT res potrebno, zapišite, s katerim naslovom misli vsaka stran, da se pogovarja. Ta ena vrstica razreši večino razprav o tem, ali je kriv tunel ali prevajanje. Pove tudi naslednjemu inženirju, kam pogledati, ko bo pravilo čez leto odstranjeno. Ping ne bo naredil nič od tega.

Dokažite fail-closed in preverite MTU

Izginotje poti samo po sebi ni pravilnik fail-closed. Druga tabela, privzeta pot ali pravilo pravilnika lahko tiho zagotovijo rezervno pot in edini način, da to izveste, je spustiti zunanji tunel in opazovati, kaj počne aplikacijski promet. Naredite to namerno, v oknu, namesto da bi to odkrili po naključju.

Preizkusite tri stanja: zunanji tunel spuščen, notranji tunel spuščen in obnovitev po vrnitvi obeh. Uporabite števce pravilnikov na vsakem prehodu, ker dve vzpostavljeni seji IKE dokazujeta le, da je pogajanje na krmilni ravnini uspelo.

Načrtujte obe inkapsulaciji. Delujoč IKE je rezultat majhnih paketov in aplikacijski paketi polne velikosti lahko še vedno spodletijo, ko se dodata dve glavi; preizkusite z znano velikostjo koristne obremenitve na resnični poti, namesto da predpostavljate, da se številke seštejejo. Aritmetika je lahka, pot ne.