Modo transporte ou túnel: decida polo paquete, non polo diagrama

Os diagramas dos manuais emparellan o modo transporte con dous hospedadores e o modo túnel con dúas pasarelas, e esa regra mantense ata o primeiro despregamento que a rompe. O modo describe que envolve o paquete ESP, non quen son os pares. Unha pasarela pode protexer tráfico en modo transporte, e un par de hospedadores pode usar modo túnel se así o elixe. Tres preguntas determinan que necesita un despregamento concreto.

O modo é unha disposición, non unha topoloxía

En modo transporte a cabeceira ESP vai despois da cabeceira IP e antes da carga útil da capa seguinte, así que a cabeceira IP orixinal queda fóra e visible. En modo túnel o contido protexido é un paquete IP completo, e unha cabeceira exterior nova nomea os dous pares IPsec.

Coa confidencialidade seleccionada, a rexión protexida en modo túnel inclúe esa cabeceira IP interior, polo que unha captura non pode dicirlle os extremos reais sen chaves. A cabeceira exterior segue sendo lexible en ambos os casos, e iso é o que fai posible a resolución de problemas.

Pregunta un: que hai exactamente dentro de ESP

Mire o paquete que produce a aplicación e pregunte que fronteira o protexe. Se a resposta é a carga útil de transporte entre dous enderezos que xa son correctos, o modo transporte encaixa sen inventar unha segunda cabeceira. Se o contido protexido necesita enderezos propios, porque os extremos reais difiren dos pares que transportan o tráfico, o modo túnel fai o traballo. Ambos os casos existen na mesma organización, e por iso unha soa declaración de política raramente cobre todo.

Esa pregunta pódese responder cunha captura e cunha táboa de encamiñamento. Non se pode responder cun debuxo que etiqueta as caixas como cliente e servidor. Unha captura tomada en calquera dos pares mostra en segundos cal dos dous está a mirar.

Pregunta dous: hai xa un túnel dentro

L2TP é o contraexemplo histórico que o demostra. O servizo transporta PPP dentro dunha sesión L2TP, e IPsec protexe ese intercambio; a disposición especifica o modo transporte, co modo túnel permitido como opción. O resultado visible é un túnel a nivel de servizo cuxa protección exterior usa o modo transporte.

Así, a presenza da palabra túnel na descrición dun produto non di nada sobre o modo da capa que hai debaixo. Anote que pregunta o resolveu, porque o seguinte revisor preguntará o mesmo. Lea a especificación desa combinación en lugar de razoar a partir do nome, xa que ese hábito evita a maioría das discusións sobre que debe admitir un produto.

Pregunta tres: que require o par

Dous pares teñen que poñerse de acordo, e unha proposta que ofrece un modo mentres o outro esixe o segundo falla durante a negociación en lugar de degradarse en silencio. Pregunte ao propietario do extremo remoto que modo nomea a política, e comprobe a proposta en lugar do resumo da documentación.

Os contornos mixtos son habituais: unha pasarela remata sesións de modo transporte para un produto antigo e sesións de modo túnel para unha ligazón de sede. O modo é por asociación, non por dispositivo. Pida a lista de asociacións en lugar do nome da función, porque o nome viaxa máis rápido que a configuración.

Ler a asociación que existe

Para unha revisión, enumere os pares, o modo, os selectores e o protocolo da capa seguinte, e despois engada calquera encapsulación envolta arredor do resultado. A tradución de enderezos engade a súa propia vista exterior e non é un modo; un fluxo traducido pode seguir sendo calquera dos dous. A lista é o único artefacto que mostra a asociación tal como está instalada e non como se pretendía.

Remate coa pregunta de encamiñamento e autorización, porque unha disposición de paquete correcta non lle di nada sobre que subredes están permitidas nin se existe o camiño de volta. Esas viven na política e na táboa de rutas, e ningunha das dúas cambia o argumento sobre o modo.