Extensión do sitio VPN: siga a ruta de volta máis aló da pasarela

O tráfico dunha sucursal remata nunha pasarela cuxa LAN non contén a aplicación á que se lle pediu chegar. O servidor está nun segundo centro de datos, alén dunha ligazón interna que a VPN nunca configurou. Engadir outro prefixo á pasarela próxima non fai nada para ese caso, porque a pasarela afastada é un punto final de cifrado e non o último enrutador. O camiño necesita unha ruta cara adiante, unha admisión na fronteira de seguridade afastada e unha decisión de retorno na propia rede do destino.

A pasarela afastada é un punto final de cifrado

O IPsec de pasarela a pasarela protexe o tráfico entre dous dispositivos de seguridade, e os enderezos internos viaxan cifrados por ese segmento. Máis aló da pasarela afastada, asume o control o enrutamento ordinario, incluída calquera política que exista entre centros de datos. O segmento protexido cobre, xa que logo, parte da viaxe e non o resto. Supoñer o contrario é como un deseño acaba cun túnel san e unha aplicación inalcanzable.

Debuxe o camiño en tres tramos: sucursal a pasarela próxima, próxima a afastada, afastada á aplicación. Cada tramo ten o seu propio dono e o seu propio modo de fallo.

Lea as dúas direccións da política do túnel

A política do túnel adoita escribirse desde a perspectiva do lado local, e desa costume veñen as configuracións parciais. Ambos os pares deben listar a orixe da sucursal e o destino tal como aparecerán dentro do túnel, incluída calquera tradución que o deseño pretenda. Actualizar só o extremo próximo produce un desaxuste de fase dous que parece un fallo de enrutamento. Compare os dous conxuntos de políticas antes de tocar calquera ruta.

Escriba orixe e destino como enderezos en lugar de nomes de sitio. A ambigüidade aquí reaparece máis tarde como unha asimetría desconcertante.

Engada a ruta cara adiante e confirme a admisión

A pasarela afastada necesita unha ruta cara á subrede da aplicación, e cada enrutador entre ambas debe admitir a orixe da sucursal. Verifique o que a pasarela afastada ten realmente en lugar do que afirma o diagrama.

ip route get 10.30.5.10 from 10.10.1.50
traceroute -n -s 10.10.1.50 10.30.5.10

O primeiro comando informa da interface de saída e do seguinte salto que a pasarela afastada escollería para esa orixe, unha pregunta que unha táboa de enrutamento simple non pode responder. O trazado mostra onde se deteñen os paquetes, e unha interrupción despois da pasarela afastada apunta ao tránsito interno e non ao túnel. Cando a ruta existe e o tráfico segue desaparecendo, capture na pasarela afastada e lea o enderezo de orixe que chega, porque un enderezo inesperado significa que a tradución ocorre nalgún lugar non planificado. Todos os enderezos de aquí son marcadores, así que substitúa as subredes reais de sucursal, tránsito e aplicación.

Probe desde a sucursal e logo volva probar o camiño antigo

A aceptación necesita unha orixe real en lugar dunha sonda desde a pasarela afastada. Execute a comprobación desde un equipo da sucursal e manteña os destinos que xa funcionaban na mesma proba.

curl -sS -m 5 http://10.30.5.10:8080/health
ping -c 3 10.20.1.1

Unha resposta da aplicación demostra o camiño de ida e o de volta á vez, mentres que o ping ao destino antigo demostra que o cambio non rompeu o que xa funcionaba. Capture o enderezo de orixe que rexistra a aplicación, porque as súas regras de acceso e calquera ruta de retorno deben coincidir con ese valor. Onde a sucursal traduce antes do túnel, o enderezo da política e o enderezo que ve a aplicación difiren por deseño, así que rexistre ambos. Repita a proba tras unha renovación de clave ou un cambio de enrutamento, porque estes camiños adoitan validarse unha vez e logo esquecerse.

Asigne un dono a cada un dos tres segmentos e á ruta de retorno dentro da rede de destino. Un camiño con catro donos falla nos ocos entre eles.