O ping desde a pasarela IPsec usa outra dirección de orixe

Faga ping ao lado remoto desde a pasarela IPsec, non reciba resposta e conclúa que o túnel está roto, mentres cada carga de traballo detrás da pasarela cursa tráfico con normalidade. Os dous resultados non se contradín. Un ping iniciado na pasarela é un paquete con orixe local, e a pasarela escolle unha dirección de orixe da súa propia táboa de rutas. Esa escolla pode diferir das direccións que usa o tráfico real do sitio, o que cambia que política coincide e que ruta de volta se aplica. Decida que debe demostrar a proba antes de ler nada no seu resultado.

Tres preguntas distintas ás que un ping pode responder

A primeira pregunta é se o extremo remoto é accesible sequera desde este host. A segunda é se os selectores do túnel ou a política baseada en rutas admiten tráfico dunha orixe concreta. A terceira é se o tráfico reenviado desde unha carga de traballo detrás da pasarela funciona de extremo a extremo. Un só comando non pode responder as tres, e a dirección de orixe é o que as separa.

Escolla primeiro a pregunta. Se non, un ping fallido convértese en proba da teoría que xa tiña.

Por que a pasarela escolle unha dirección que non esperaba

Cando fai ping a un destino, a pila local escolle unha orixe da ruta que coincide con el. Nun túnel baseado en rutas iso pode ser a dirección de enlace da interface do túnel, que en moitos deseños de sitio é un par 169.254.x.x escollido para o salto punto a punto. Esas direccións existen para que o enlace funcione; non se anuncian como redes de orixe de aplicacións no lado remoto.

Así, o extremo remoto pode recibir unha solicitude de eco desde unha dirección á que non ten ruta de volta, ou desde unha que ningún selector coincide. O túnel pode estar san e o ping fallar igualmente, e ese é exactamente o falso negativo do que trata este artigo.

Escolla a orixe a propósito

Nunha pasarela Linux controlada, escolla unha orixe que xa estea asignada localmente: ping -c 4 -I 10.30.0.1 10.40.0.20. As direccións de aquí son ilustrativas, así que substitúa a dirección interior real da pasarela e un destino remoto real, e confirme que a orixe que escolle pertence a este dispositivo e que a política do sitio a admite.

Non tome prestada a dirección dunha carga de traballo para a proba. Suplantar un host que non está asignado á pasarela crea un resultado que ninguén pode reproducir, e nalgúns stacks falla de xeitos que parecen un defecto do túnel.

Lea o camiño de volta, non só a solicitude

Comprobe que orixe chega realmente ao destino remoto, incluída calquera tradución deliberada polo camiño. Despois comprobe a ruta de volta do lado remoto cara a esa orixe e os selectores ou a política que a permiten. Unha solicitude que chega cunha orixe inesperada é unha cuestión de encamiñamento e política, non de criptografía.

Aquí tamén unha captura axuda máis que outro ping: mostra a orixe que viu o extremo remoto, que é a dirección que debe acadar a súa resposta.

Despois probe a carga de traballo

A proba decisiva é un ping desde un host corrente detrás da pasarela ata un host corrente detrás da pasarela remota. Iso exercita o papel de reenvío da pasarela, a orixe real da aplicación e o camiño de volta verdadeiro, que é o fluxo que importa aos usuarios.

Manteña os resultados separados nas súas notas: accesibilidade local desde a pasarela, admisión por política para unha orixe escollida e tráfico reenviado. Un ping fixado con éxito é unha proba útil de que o túnel transporta algo; non é proba de que todo fluxo reenviado funcione. E unha orixe de pasarela escollida automaticamente que non se pode acadar non é proba de que o túnel do sitio estea caído.

Non engada unha ruta xeral para 169.254.0.0/16 só para obter unha resposta de diagnóstico. Iso cambia unha proba enganosa por unha decisión de encamiñamento permanente, e a persoa seguinte hérdana sen o contexto.