Cinco papeis do enderezo nun perfil IPsec e cal está mal

Cinco tarefas distintas reciben un enderezo nunha definición de conexión típica, e non teñen por que coincidir entre si. Os administradores atascan porque un instinto razoable, facer que todos os campos apunten ao mesmo host, é erróneo para polo menos tres deles. A saída consiste en nomear primeiro o síntoma e despois mirar o campo ou os dous campos que poderían producilo.

As cinco tarefas, na orde en que importan

O punto final de transporte é onde se entrega o intercambio IKE. A identidade autenticada é o nome que demostra cada lado, e compróbase contra a política, non contra unha táboa de encamiñamento. As subredes protexidas son os selectores que deciden que tráfico interno pertence ao túnel. Despois está a orixe que se usa cando a propia pasarela inicia unha conversa, e por último o seguinte salto da capa inferior para acadar o par.

As etiquetas de participante como left e right son convencións para os dous lados dunha conexión, non sinónimos de local e remoto. Lea o manual da implementación que realmente está instalada antes de supoñer que unha clave significa o que outro produto entendía por ela.

Decisión un: non se establece nada

Cando non aparece ningún intercambio nos rexistros, o punto final é o primeiro sospeitoso: un enderezo equivocado, unha ruta filtrada ou unha interface na que o demo non escoita. Pase aos campos de identidade só cando o aperto de mans sexa visible, porque a identidade xúlgase dentro do intercambio, non antes. Unha ruta filtrada e un enderezo equivocado vense idénticos desde o cliente, así que revise o lado que escoita antes de editar nada. Confirme que o demo está ligado á interface que espera, porque un servizo que escoita nun enderezo vese exactamente como unha ruta bloqueada.

Un enderezo público observado a través da tradución non é o mesmo que a identidade que demostra un par. Cambiar un enderezo para que coincida co que mostra unha captura de paquetes no extremo afastado é unha corrección habitual e equivocada.

Decisión dous: o túnel está levantado e o tráfico morre

Os selectores deciden que entra no túnel, e unha discrepancia aquí produce unha conexión que negocia con éxito mentres a aplicación segue fallando. O lado afastado ten que nomear o seu rango protexido como o seu rango remoto, e é exactamente aí onde se coan os valores invertidos.

Lea ambas configuracións unha ao lado da outra antes de editar. O rango local dun host é o rango remoto do outro, e un só par intercambiado explica un túnel que non transporta nada. Estreite o par antes de tocar as claves: unha subrede dentro do túnel e outra fóra dinlle se a culpa é do selector ou do encamiñamento.

Decisión tres: só falla o tráfico propio da pasarela

O tráfico reenviado para clientes pode funcionar perfectamente mentres falla unha petición que a propia pasarela inicia, porque ese fluxo non ten unha orixe de cliente que herdar. O axuste de orixe preferida existe para este caso, e non é tradución de orixe: elixe un enderezo de orixe en lugar de reescribir un.

Unha aplicación que liga explicitamente outro enderezo pode impoñerse á preferencia, así que confirme a orixe real do paquete antes de concluír que o axuste se ignora. Capture na interface propia da pasarela en lugar de confiar na intención da configuración.

O seguinte salto é unha instrución local

O seguinte salto da capa inferior di a este host como chegar ao par, e o lado afastado non necesita o mesmo valor. Tratalo como un axuste compartido ou codificar de forma fixa unha pasarela predeterminada rompe no momento en que cambia a ruta ou aparece un segundo camiño.

Algunhas implementacións ofrecen valores especiais aquí. O que o manual enumera para a versión instalada é a única resposta segura, e a táboa de encamiñamento local é a proba de que funcionou. Cando un par é alcanzable polo nome pero non polo enderezo, esa discrepancia é o achado, non un detalle que sortear.

Lea o perfil desde ambos extremos

Inverter os papeis sobre o papel é a revisión máis rápida que existe: intercambie os rangos protexidos, manteña o seguinte salto propio de cada lado e a identidade propia de cada lado. Todo o que non sobrevive ao intercambio probablemente está asignado á tarefa equivocada.

Despois probe un fluxo por papel: alcanzabilidade entre pares, un fluxo de cliente interno e unha petición orixinada na pasarela. Tres probas dinlle que tarefa está mal asignada sen volver abrir a configuración. Engada o resultado ao tícket xunto ao campo que cambiou, porque o seguinte enxeñeiro atopará o mesmo perfil.