IPsec dins d'IPsec: quines adreces ha de portar el túnel extern

L'IPsec imbricat és més fàcil de raonar quan les dues capes acaben en màquines diferents. Quatre passarel·les, dos túnels i una sola pregunta que decideix si el disseny funciona: què veu realment el túnel extern quan l'intern ha acabat amb el paquet? Responeu això i els selectors, les rutes i l'ordre de resolució de problemes en surten. Equivoqueu-vos i passareu un dia depurant un túnel que tècnicament està aixecat.

El model de quatre passarel·les

Les passarel·les externes A i B construeixen el primer túnel entre els dos llocs. Darrere d'A hi ha la passarel·la interna C amb adreça de trànsit 10.60.0.2; darrere de B hi ha la passarel·la interna D amb adreça de trànsit 10.70.0.2. Les xarxes d'aplicacions viuen darrere de C i D, i cada adreça de l'exemple és deliberadament no superposada.

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

Dividir les capes entre quatre amfitrions vol dir que cada màquina fa complir una frontera. Un sol amfitrió que executa les dues capes ha de conciliar dos conjunts de polítiques, dues taules d'encaminament i dos modes de fallada en una màquina, cosa que és possible i molt més difícil d'observar.

Cada capa només elimina la seva pròpia protecció

C xifra un paquet d'aplicació per a D. El resultat s'adreça de C a D, i això és el que arriba a A. Tot el que hi ha aigües avall depèn d'aquesta reescriptura.

A el torna a xifrar per a B. B desxifra la capa externa, veu un paquet de C a D i el reenvia encara xifrat. D elimina la protecció interna i lliura el paquet d'aplicació.

Així, A i B veuen els extrems interns i les seves metadades, però no són les parts que desxifren la càrrega útil de l'aplicació. Això és una propietat real del disseny i no una afirmació que C, D o els amfitrions d'aplicacions siguin de confiança.

Els selectors externs anomenen les passarel·les internes

Aquí és on fallen la majoria d'aquestes construccions. Per a un túnel extern basat en polítiques, els selectors que negocieu han de contenir les adreces que A i B gestionen realment: 10.60.0.2/32 i 10.70.0.2/32, en l'ordre local i remot correcte.

Posar les subxarxes finals d'aplicacions als selectors externs no funciona, perquè quan un paquet arriba a A, l'encapsulació interna ja ha reescrit allò que A ha de protegir. Llavors la política externa no coincidiria amb res i el túnel pujaria sense portar dades.

No estrenyi el permís extern a UDP 500. La connexió interna té el seu propi camí de dades, que fa servir ESP o encapsulació UDP segons què hagi negociat, i la política externa ha de permetre aquest protocol.

Comproveu el resultat amb swanctl --list-sas a cada passarel·la i confirmeu que les associacions de seguretat fill informen les adreces que teníeu previstes, no les que havíeu suposat. Si la llista mostra les subxarxes d'aplicacions, la política externa s'ha escrit per a la capa equivocada. Corregiu els selectors abans de depurar l'encaminament, perquè l'encaminament semblarà correcte i els comptadors no es mouen.

El reenviament i el parany de la recursió

Els selectors no substitueixen l'encaminament. A i B han de reenviar trànsit entre C i D en tots dos sentits, cosa que vol dir reenviament IP activat, rutes que apunten al túnel i un camí de tornada que existeixi a l'altre costat.

Si el túnel extern fa servir interfícies XFRM, les rutes seleccionen la interfície mentre les polítiques negociades encara limiten què transporta. Una interfície no amplia allò que està protegit; només canvia com el nucli agafa el paquet.

El parany és la recursió. La ruta d'A cap a l'extrem extern de B ha de seguir la xarxa subjacent, no el túnel que A estableix, o l'encapsulació intenta viatjar dins de si mateixa i la connexió no s'acaba mai.

Inspeccioneu la traducció abans d'afegir capes

Mireu qualsevol NAT d'origen a A i B abans d'ajustar res més. Una regla que reescriu l'adreça de C abans que s'apliqui la política IPsec pot trencar els selectors convinguts, i també pot canviar què rep D a l'altre costat.

L'emmascarament ampli no es fa més segur per tenir dues capes. Amaga quina adreça veu l'extrem llunyà, que és exactament la informació que necessiteu quan el túnel està aixecat i l'aplicació no funciona.

Si una regla NAT és realment necessària, escriviu amb quina adreça creu cada costat que parla. Aquesta sola línia resol la majoria de discussions sobre si la culpa és del túnel o de la traducció. També diu al següent enginyer on mirar quan la regla s'elimini un any després. Un ping no farà res de tot això.

Demostreu fail-closed i comproveu l'MTU

Que una ruta desaparegui no és per si sol una política fail-closed. Una altra taula, una ruta per defecte o una regla de política poden proporcionar silenciosament un camí alternatiu, i l'única manera de saber-ho és baixar el túnel extern i observar què fa el trànsit d'aplicacions. Feu-ho expressament, en una finestra, en lloc de descobrir-ho per accident.

Proveu tres estats: túnel extern baixat, túnel intern baixat i recuperació després que tornin tots dos. Feu servir comptadors de política a cada passarel·la, perquè dues sessions IKE establertes només demostren que la negociació del pla de control ha reeixit.

Pressuposteu les dues encapsulacions. Un IKE que funciona és un resultat de paquets petits, i els paquets d'aplicació de mida completa encara poden fallar quan s'afegeixen dues capçaleres; proveu amb una mida de càrrega útil coneguda al camí real en lloc de suposar que els números quadren. L'aritmètica és fàcil; el camí no.