Como mover un servidor VPN de Raspberry Pi a Ethernet

Cambiar a Pi de Wi-Fi a un cable parece un traballo de cinco minutos, e só o segue sendo se tratas o cambio como catro axustes separados en lugar de un. O nome do punto final que marcan os teus clientes pode seguir exactamente igual mentres o enderezo por baixo cambia. O que realmente rompe é un listener fixado ao enderezo antigo, un redireccionamento de portos aínda dirixido á concesión sen fíos, ou unha ruta de retorno que sae pola interface que pensabas que retiraras. Esta guía mantén unha ruta de recuperación aberta en cada paso, así que unha transición fallida só custa un reinicio.

Anota os catro responsables antes de desconectar calquera cousa

Catro axustes deciden se a transición sobrevive: o enderezo da Pi, o enderezo de vinculación OpenVPN, o destino de redirección do router e a ruta que toman as respostas. Anota os catro antes de tocar o cable, porque unha vez desaparece a concesión sen fíos xa non podes ler os valores antigos da máquina. A interface con cable non herda o perfil sen fíos, e en Bookworm o enderezo vive en NetworkManager mentres Bullseye o mantén en dhcpcd.conf. Unha reserva que fixaba o enderezo MAC sen fíos non di nada sobre eth0. Trata o novo enderezo como unha asignación nova que precisa a súa propia proba.

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

O listener é o segundo responsable. Se o servizo arrincou cun enderezo de vinculación específico, o socket morre coa interface antiga; se vincula todos os enderezos, o socket sobrevive e a regra do router convértese no único que queda por arranxar.

O destino de redirección e a ruta de retorno son os responsables que a xente salta. Un redireccionamento que aínda apunta a 10.42.7.24 envía os handshakes entrantes a un enderezo que a Pi xa non ten, así que os clientes esgotan o tempo sen ningunha liña de log no servidor. A ruta de retorno importa cando ambos os enlaces están brevemente activos, porque a Pi responde desde a interface que prefire a táboa de rutas, e non sempre é a que recibiu o paquete. A consulta de ruta de abaixo mostra que fonte escolle o kernel.

Le o socket real antes de confiar no novo enderezo

Os ficheiros de configuración describen a intención e o socket describe a realidade. Pregunta ao servizo en execución a que está vinculado en lugar de confiar na configuración que recordas. O manual de OpenVPN 2.6 define --local como vinculación a un enderezo e sinala que omitilo vincula todas as interfaces.

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

Le a columna do enderezo local en lugar da columna de estado. Unha liña que mostra 10.42.7.24:1194 significa que o socket está fixado ao enderezo que estás a piques de eliminar, mentres que 0.0.0.0:1194 ou *:1194 significa que o daemon seguirá o cambio de interface por si mesmo. Se o enderezo está fixado, edita o perfil e reinicia a unidade en lugar de reescribir o socket activo a man, e despois confirma que o servizo segue chegando aos seus ficheiros de certificado e chave.

Percorre o cambio nunha orde que te manteña accesible

A orde importa aquí máis que a velocidade. Levanta o enlace con cable mentres o sen fíos aínda funciona, confirma o novo enderezo e a ruta de retorno, e despois retira o perfil sen fíos. Esa secuencia mantén unha sesión operativa aberta ata que o substituto estea probado.

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

O primeiro comando responde se eth0 recibiu o enderezo que pretendías, e o segundo imprime o enderezo de orixe que o kernel usaría para un destino exterior, así que execútao antes e despois do cambio. Se esa orixe segue sendo o enderezo sen fíos, o enlace con cable aínda non é a ruta preferida e a proba desde fóra fallará por unha razón que non ten nada que ver con OpenVPN. Corrixe a preferencia de rutas antes de tocar o redireccionamento.

Con ambos os enlaces activos, a Pi pode preferir a ruta por defecto sen fíos porque se instalou primeiro ou porque o enlace con cable leva unha métrica maior. En Bookworm o parafuso admitido é ipv4.route-metric na conexión, e en Bullseye o equivalente é unha liña metric específica da interface en dhcpcd.conf. Degrada o enlace sen fíos en lugar de desactivalo, para que a ruta de reversión quede a un comando de distancia.

Proba o túnel desde fóra, non desde a LAN

Unha conexión VPN que funciona desde o sofá proba menos do que parece. O tráfico desde dentro da LAN cara ao enderezo público pasa por regras de hairpin ou reflexión que os routers implementan de forma inconsistente, así que unha proba LAN exitosa pode convivir cunha ruta exterior rota. Usa un teléfono con datos móbiles, ou calquera host fóra da rede, para a proba de aceptación. Mantén o intento LAN como un diagnóstico opcional á parte.

Despois le o log na orde na que chegan os paquetes. Nada en absoluto significa que o handshake nunca chegou á Pi, así que o destino de redirección ou a firewall do host está mal. Un handshake que comeza e se atasca apunta a claves, certificados ou MTU. Unha sesión que se completa e cae normalmente significa a ruta de retorno ou unha segunda ruta por defecto, e a liña de log do cliente Initialization Sequence Completed diche que o túnel en si levantouse.

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

Se non aparece nada no log do servidor mentres o cliente o tenta de novo, deixa de ler a configuración de OpenVPN e volve ao destino de redirección. A captura responde á pregunta da chegada en segundos, e os paquetes entrantes sen resposta reducen o problema á ruta.

Mantén unha reversión dun paso e retira o perfil sen fíos

Deixa o perfil sen fíos instalado ata que a disposición con cable pase un reinicio. nmcli con show lista os nomes de perfil que necesitarás, e un perfil borrado ten que reconstruírse de memoria no peor momento. Anota o nome da interface, o método de enderezo e a métrica xunto aos outros catro valores. Unha reversión que podes escribir desde unha nota vale máis ca unha que tes que reconstruír.

Retirar a dependencia sen fíos é un cambio de propiedade en lugar dunha eliminación. Ao establecer connection.autoconnect no mantéñense as credenciais e o historial de enderezos intactos mentres a Pi queda impedida de volver conectarse a unha rede da que te afastaches.

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

Antes de dar o traballo por rematado, confirma catro cousas: o destino de redirección coincide co enderezo con cable, o listener sobreviviu a un reinicio, un cliente desde fóra completa un handshake, e a Pi segue respondendo no enderezo con cable tras un reinicio. Un reinicio é a forma máis barata de detectar unha asignación que só existía no kernel en execución. Se calquera dos catro falla, levanta de novo o perfil sen fíos con sudo nmcli con up e compara os valores anotados cos activos.