Dos saltos VPN en una sola Pi: qué ruta transporta a qué par

Dos direcciones de túnel en una placa pequeña parecen un error, y el reflejo es borrar una. Ese reflejo rompe lo que debía ordenar. Un anfitrión que lleva dos saltos mantiene una dirección por conexión, y cada dirección la selecciona una ruta distinta. La pregunta que merece la pena es qué ruta elige qué portador para qué destino, no cuántas direcciones existen.

Tres destinos que necesitan portadores distintos

Una cadena de dos saltos son tres clases de destino apiladas, y cada una la lleva una conexión distinta. Hay que llegar al par exterior por el enlace físico. Hay que llegar al par interior a través del túnel exterior. Hay que llegar al destino de la aplicación cubierta a través del túnel interior, cuyo propio transporte lo lleva el exterior.

Rellene las filas con las direcciones reales del lector antes de tocar una ruta, porque la tabla solo es útil cuando es concreta. Una cadena que funciona satisface las cuatro filas a la vez, y una cadena a medias suele satisfacer una de ellas con el portador equivocado. Leer la fila equivocada como el fallo es lo que convierte un problema de enrutamiento en una tarde entera de ediciones.

Las direcciones tienen papeles, no un recuento

Linux permite varias direcciones en una interfaz y varios túneles en un anfitrión, así que un recuento no dice nada sobre la corrección. Lo que importa es qué dirección pertenece a qué conexión y si la ruta para un par dado selecciona la conexión que usted quería. Tres vistas responden a eso desde tres direcciones, y merece la pena leerlas en el mismo orden cada vez.

El inventario de direcciones muestra qué existe y qué conexión lo posee. La tabla de rutas responde a la pregunta del portador para el tráfico ordinario hacia destinos. La vista de políticas la responde de nuevo para el tráfico seleccionado por origen o marca, que es la disposición normal cuando dos clientes comparten un anfitrión.

ip -4 addr show
ip -4 route show table all
ip rule show

Borrar una dirección porque la lista parece larga puede eliminar parte del camino, y borrar una ruta porque parece redundante hace lo mismo con más silencio. Ninguna de las dos produce un error; el par simplemente deja de responder por el camino que usted pretendía mientras sigue siendo alcanzable por otro. Una aplicación que informa de la dirección de salida del par interior no demuestra que el tráfico cruzara el túnel exterior, ya que el acceso directo produce la misma observación. Esa brecha entre una observación y una prueba es la razón por la que el portador se comprueba en la capa de enrutamiento.

El orden de activación vence a una espera fija

Si el cliente interior depende de una dirección o una ruta que proporciona el cliente exterior, la activación debe esperar a ese recurso en lugar de a un retardo. Una espera funciona hasta el día en que el túnel exterior va lento, y entonces falla de forma intermitente de una manera que nadie puede reproducir. El orden basado en dependencias elimina la conjetura y no cuesta nada más allá de describir la dependencia una vez. Los nombres de interfaz tampoco son un mecanismo de ordenación.

El núcleo reparte nombres como tun0 y tun1 por orden de creación, y ese orden puede cambiar entre reinicios o reconexiones. Vincule la configuración a una identidad que proporcione la herramienta, o a un nombre que asigne deliberadamente. Un nombre que usted elige es un contrato; un nombre que elige el núcleo es un accidente.

Mantenga el transporte de cada cliente fuera de la ruta de aplicación del otro, y sea preciso sobre lo que las opciones de enrutamiento de OpenVPN 2.6 prometen realmente. El mecanismo documentado de redirección por defecto mantiene a un cliente capaz de alcanzar su propio par remoto a través de la puerta de enlace que ya existía, lo que corta un bucle de recursión concreto. No convierte a un cliente en el portador de otro, así que el resto de la cadena sigue siendo su diseño. Donde la cadena necesita una política en lugar de una ruta, escriba una regla explícita de origen o marca y pruébela con el tráfico con el que debe coincidir.

Qué ocurre cuando muere el salto exterior

Antes de que la cadena cuente como completa, decida qué ocurre cuando desaparece el salto exterior. El transporte del cliente interior muere con él, y el siguiente movimiento es una cuestión de política más que técnica: fallar, reintentar o reconectar directamente por el enlace físico. Ese tercer resultado es el que hay que pensar. Convierte en silencio un diseño de dos saltos en uno de un salto en el momento en que el usuario cree que la cobertura sigue intacta.

Si dos saltos son obligatorios, el cliente interior no debe poder establecer un camino directo cuando el exterior ha desaparecido, y la forma de saberlo es romper el salto exterior y observar qué hace el interior. Un plan de reserva aprobado es una respuesta legítima, pero tiene que estar escrito, probado y comunicado. Un plan de reserva que nadie documentó es indistinguible de una fuga durante la revisión de un incidente.

El DNS y la otra familia de direcciones pertenecen a la misma decisión. Una consulta generada localmente sigue la política del propio anfitrión y no la de un cliente reenviado, así que el resolutor que funciona para el tráfico reenviado puede no ser el que el anfitrión mismo usa.

Acepte cada capa en el orden en que la construyó

Pruebe en el orden en que se construyó la cadena: primero el túnel exterior solo, luego el transporte del cliente interior a través del túnel exterior, luego la aplicación a través del túnel interior. Cada aceptación tiene que ser una conexión nueva y no una página que ya estaba abierta. Después rompa y restaure cada capa por separado y observe qué hace la siguiente.

El resultado del plan de reserva es la observación más valiosa aquí, y la que una página de IP pública nunca muestra. Guarde los caminos de los pares, las direcciones que usan y ese resultado junto a la configuración, porque el camino feliz no es la parte que se cuestiona después.