Por qué una VPN que funciona sigue agotando el tiempo en la respuesta
Que una petición llegue a un servidor privado es solo la mitad del intercambio. Su respuesta tiene que encontrar al cliente del túnel por la pasarela, la ruta o la traducción previstas.
La petición llega, el servidor la registra y el cliente sigue informando de un tiempo de espera agotado. Esa combinación significa que la respuesta no encontró el camino de vuelta, y es uno de los pocos fallos que puedes confirmar desde los dos extremos a la vez. Haz las comprobaciones en orden y detente cuando una falle.
Empieza por dónde llegó la petición
Confirma que el paquete llegó al servicio antes de inspeccionar cualquier otra cosa. Una entrada en el registro del servidor, un contador de conexiones o una captura permitida en el extremo remoto responden a la misma pregunta, y su ausencia te devuelve al túnel en lugar de llevarte hacia la respuesta. Esta es la comprobación que separa un problema de reenvío de un problema de camino de vuelta.
Si la petición nunca llegó, detente aquí. El túnel, el enrutamiento hacia el prefijo privado o la regla de acceso son el asunto, y el camino de la respuesta aún no es relevante. Anota también la dirección de origen que vio el servidor. Es o bien la dirección del grupo que recibió el cliente o una dirección traducida, y esa diferencia determina cuál de las comprobaciones posteriores se aplica.
La respuesta necesita una ruta hacia el grupo
Un cliente de acceso remoto suele recibir una dirección de un grupo, y la red privada necesita una ruta de vuelta hacia ese grupo. Un servidor cuya ruta predeterminada apunta a su propia pasarela entrega el paquete a esa pasarela, que no tiene ni idea de dónde vive el grupo, así que la respuesta muere allí. El cliente ve un tiempo de espera porque no volvió nada, lo que es indistinguible de una petición que nunca salió.
Comprueba la ruta que el servidor elige para la dirección del cliente, no la ruta que usa para su propia subred. Esas dos consultas pueden dar respuestas distintas, y la segunda es la que importa aquí. La traducción es el diseño alternativo y cambia lo que ve el servidor. Puede simplificar un camino de vuelta, y además elimina la dirección original del cliente de los registros del servidor, lo que afecta a cualquier regla o informe construido sobre ese campo.
Compara la captura del servidor con la captura de la pasarela
Compara lo que sale del servidor con lo que llega a la pasarela. Una captura en la interfaz de salida del servidor y una captura en la pasarela del túnel responden a mitades distintas de la pregunta, y el hueco entre ellas localiza la pérdida.
ip route get 10.90.0.14
tcpdump -ni any host 10.90.0.14 and port 443
ip route show table all | grep 10.90.0.0| Where the reply stops | What it proves |
|---|---|
| Request in the server log, nothing on its outbound capture | The server picked a gateway that cannot reach the pool |
| Reply leaves the server but never shows up at the gateway | Loss on the LAN path, not on the tunnel |
| Reply reaches the gateway but not the client | Return translation or tunnel policy, not the server route |
Una petición generada por la propia pasarela es un mal sustituto de una prueba desde el cliente, porque se origina en otra dirección y se encuentra con otras reglas. Por eso un ping correcto desde la pasarela y una petición fallida desde el cliente pueden ser ciertos a la vez.
Cuando hay varios enrutadores en el camino, comprueba cada uno que necesite una ruta hacia el grupo. Un diseño de sitio a sitio a menudo exige que el prefijo remoto sea conocido en más de un dispositivo, y la propia pasarela tiene que reenviar entre el túnel y la LAN; las notas de reenvío de strongSwan cubren la parte de sysctl y de cortafuegos.
Anota el grupo, el prefijo y el responsable
En la nota van cuatro hechos: el grupo que recibió el cliente, el prefijo privado que necesitaba, el enrutador responsable de la respuesta y la regla de traducción si existe. Con ellos, un cambio posterior de pasarela es una comparación y no una investigación.
Después vuelve a probar con un cliente corriente y la cuenta real de la aplicación. Ampliar los privilegios de la aplicación no puede reparar el camino de vuelta de un paquete, y un cambio de cuenta hecho durante este diagnóstico confundirá la siguiente comparación. Si el diseño depende de la traducción, documéntalo donde se leen los registros del servidor. Quien ve una dirección de origen desconocida en una traza de auditoría no debería tener que redescubrir la correspondencia a partir de un tique.