Cómo mover un servidor VPN Raspberry Pi a Ethernet

Cambiar la Pi de Wi-Fi a un cable parece un trabajo de cinco minutos, y solo lo sigue siendo si tratas el cambio como cuatro ajustes separados en lugar de uno. El nombre del punto de conexión al que marcan tus clientes puede seguir exactamente igual mientras cambia la dirección que hay debajo. Lo que de verdad se rompe es un listener fijado a la dirección antigua, un reenvío de puertos que aún apunta a la concesión inalámbrica, o una ruta de retorno que sale por la interfaz que creías haber retirado. Este recorrido mantiene abierta una ruta de recuperación en cada paso, así que un cambio fallido solo cuesta un reinicio.

Anota los cuatro responsables antes de desconectar nada

Cuatro ajustes deciden si el cambio sobrevive: la dirección de la Pi, la dirección de vinculación OpenVPN, el destino de redirección del router y la ruta que toman las respuestas. Anota los cuatro antes de tocar el cable, porque en cuanto desaparece la concesión inalámbrica ya no puedes leer los valores antiguos de la máquina. La interfaz con cable no hereda el perfil inalámbrico, y en Bookworm la dirección vive en NetworkManager mientras que Bullseye la guarda en dhcpcd.conf. Una reserva que fijaba la dirección MAC inalámbrica no dice nada sobre eth0. Trata la nueva dirección como una asignación nueva que necesita su propia prueba.

Old wireless lease:   10.42.7.24/24 on wlan0
New wired address:    10.42.7.31/24 on eth0
Client endpoint:      vpn.lab.example:1194/udp

El listener es el segundo responsable. Si el servicio se inició con una dirección de vinculación específica, el socket muere con la interfaz antigua; si vincula todas las direcciones, el socket sobrevive y la regla del router se convierte en lo único que queda por arreglar.

El destino de redirección y la ruta de retorno son los responsables que la gente se salta. Un reenvío que todavía apunta a 10.42.7.24 envía los handshakes entrantes a una dirección que la Pi ya no tiene, así que los clientes agotan el tiempo sin ninguna línea de registro en el servidor. La ruta de retorno importa cuando ambos enlaces están brevemente activos, porque la Pi responde desde la interfaz que prefiere la tabla de rutas, y no siempre es la que recibió el paquete. La consulta de ruta de abajo muestra qué origen elige el kernel.

Lee el socket real antes de fiarte de la nueva dirección

Los archivos de configuración describen la intención y el socket describe la realidad. Pregunta al servicio en ejecución a qué está vinculado en lugar de fiarte de la configuración que recuerdas. El manual de OpenVPN 2.6 define --local como vinculación a una dirección y señala que omitirlo vincula todas las interfaces.

sudo systemctl cat openvpn-server@server | grep -n -- '--local'
sudo ss -lunp '( sport = :1194 )'

Lee la columna de la dirección local en lugar de la columna de estado. Una línea que muestra 10.42.7.24:1194 significa que el socket está fijado a la dirección que estás a punto de eliminar, mientras que 0.0.0.0:1194 o *:1194 significa que el daemon seguirá el cambio de interfaz por sí solo. Si la dirección está fijada, edita el perfil y reinicia la unidad en lugar de reescribir el socket activo a mano, y luego confirma que el servicio sigue llegando a sus archivos de certificado y clave.

Recorre el cambio en un orden que te mantenga accesible

El orden importa aquí más que la velocidad. Levanta el enlace con cable mientras el inalámbrico aún funciona, confirma la nueva dirección y la ruta de retorno, y después retira el perfil inalámbrico. Esa secuencia mantiene abierta una sesión operativa hasta que el sustituto esté probado.

ip -br addr show eth0
ip route get 203.0.113.10
nmcli -g ipv4.method,ipv4.addresses con show "Wired connection 1"

El primer comando responde si eth0 recibió la dirección que pretendías, y el segundo imprime la dirección de origen que el kernel usaría para un destino exterior, así que ejecútalo antes y después del cambio. Si ese origen sigue siendo la dirección inalámbrica, el enlace con cable aún no es la ruta preferida y la prueba desde fuera fallará por una razón que no tiene nada que ver con OpenVPN. Corrige la preferencia de rutas antes de tocar el reenvío.

Con ambos enlaces activos, la Pi puede preferir la ruta por defecto inalámbrica porque se instaló primero o porque el enlace con cable lleva una métrica mayor. En Bookworm el control admitido es ipv4.route-metric en la conexión, y en Bullseye el equivalente es una línea metric específica de la interfaz en dhcpcd.conf. Degrada el enlace inalámbrico en lugar de desactivarlo, para que la ruta de reversión quede a un comando de distancia.

Prueba el túnel desde fuera, no desde la LAN

Una conexión VPN que funciona desde el sofá prueba menos de lo que parece. El tráfico desde dentro de la LAN hacia la dirección pública pasa por reglas de hairpin o reflexión que los routers implementan de forma inconsistente, así que una prueba LAN exitosa puede convivir con una ruta exterior rota. Usa un teléfono con datos móviles, o cualquier host fuera de la red, para la prueba de aceptación. Mantén el intento LAN como un diagnóstico opcional aparte.

Después lee el registro en el orden en que llegan los paquetes. Nada en absoluto significa que el handshake nunca llegó a la Pi, así que el destino de redirección o el cortafuegos del host está mal. Un handshake que empieza y se atasca apunta a claves, certificados o MTU. Una sesión que se completa y cae normalmente significa la ruta de retorno o una segunda ruta por defecto, y la línea de registro del cliente Initialization Sequence Completed te dice que el túnel en sí levantó.

sudo journalctl -u openvpn-server@server -n 40 --no-pager
sudo tcpdump -ni any udp port 1194 -c 20

Si no aparece nada en el registro del servidor mientras el cliente lo reintenta, deja de leer la configuración de OpenVPN y vuelve al destino de redirección. La captura responde a la pregunta de la llegada en segundos, y los paquetes entrantes sin respuesta reducen el problema a la ruta.

Mantén una reversión de un paso y retira el perfil inalámbrico

Deja el perfil inalámbrico instalado hasta que la disposición con cable haya pasado un reinicio. nmcli con show enumera los nombres de perfil que necesitarás, y un perfil borrado tiene que reconstruirse de memoria en el peor momento. Anota el nombre de la interfaz, el método de dirección y la métrica junto a los otros cuatro valores. Una reversión que puedes escribir desde una nota vale más que una que tienes que reconstruir.

Retirar la dependencia inalámbrica es un cambio de propiedad en lugar de una eliminación. Al establecer connection.autoconnect no se mantienen intactas las credenciales y el historial de direcciones mientras se impide que la Pi vuelva a conectarse a una red de la que te alejaste.

nmcli con show
sudo nmcli con up "Wired connection 1"
sudo nmcli con mod "previously-used-wifi" connection.autoconnect no

Antes de dar el trabajo por terminado, confirma cuatro cosas: el destino de redirección coincide con la dirección con cable, el listener sobrevivió a un reinicio, un cliente desde fuera completa un handshake, y la Pi sigue respondiendo en la dirección con cable tras un reinicio. Un reinicio es la forma más barata de detectar una asignación que solo existía en el kernel en ejecución. Si cualquiera de las cuatro falla, levanta de nuevo el perfil inalámbrico con sudo nmcli con up y compara los valores anotados con los activos.