Como mover um servidor VPN Raspberry Pi para Ethernet

Passar a Pi de Wi-Fi para um cabo parece um trabalho de cinco minutos, e só continua a ser se tratares a mudança como quatro definições separadas em vez de uma. O nome do endpoint que os teus clientes marcam pode manter-se exatamente igual enquanto o endereço por baixo muda. O que realmente quebra é um listener fixado ao endereço antigo, um encaminhamento de portas ainda apontado à concessão sem fios, ou um caminho de retorno que sai pela interface que pensavas ter retirado. Este guia mantém um caminho de recuperação aberto em cada passo, por isso uma transição falhada custa apenas um reinício.

Regista os quatro responsáveis antes de desligares alguma coisa

Quatro definições decidem se a transição sobrevive: o endereço da Pi, o endereço de ligação OpenVPN, o destino de redirecionamento do router e o caminho que as respostas tomam. Regista os quatro antes de tocares no cabo, porque assim que a concessão sem fios desaparece já não consegues ler os valores antigos da máquina. A interface com cabo não herda o perfil sem fios, e no Bookworm o endereço vive no NetworkManager enquanto o Bullseye o guarda em dhcpcd.conf. Uma reserva que fixava o endereço MAC sem fios não diz nada sobre eth0. Trata o novo endereço como uma nova atribuição que precisa da sua própria prova.

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 responsável. Se o serviço arrancou com um endereço de ligação específico, o socket morre com a interface antiga; se liga todos os endereços, o socket sobrevive e a regra do router passa a ser a única coisa que falta corrigir.

O destino de redirecionamento e o caminho de retorno são os responsáveis que as pessoas saltam. Um encaminhamento que ainda aponta para 10.42.7.24 envia os handshakes que chegam para um endereço que a Pi já não tem, por isso os clientes expiram sem qualquer linha de log no servidor. O caminho de retorno importa quando ambas as ligações estão brevemente ativas, porque a Pi responde pela interface que a tabela de rotas prefere, e nem sempre é a que recebeu o pacote. A consulta de rota abaixo mostra que origem o kernel escolhe.

Lê o socket real antes de confiares no novo endereço

Os ficheiros de configuração descrevem a intenção e o socket descreve a realidade. Pergunta ao serviço em execução a que está ligado em vez de confiares na configuração que te lembras. O manual do OpenVPN 2.6 define --local como ligação a um endereço e nota que omiti-lo liga todas as interfaces.

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

Lê a coluna do endereço local em vez da coluna de estado. Uma linha que mostra 10.42.7.24:1194 significa que o socket está fixado ao endereço que estás prestes a remover, enquanto 0.0.0.0:1194 ou *:1194 significa que o daemon seguirá a mudança de interface por si próprio. Se o endereço estiver fixado, edita o perfil e reinicia a unidade em vez de reescrever o socket ativo à mão, e depois confirma que o serviço ainda chega aos seus ficheiros de certificado e chave.

Percorre a mudança numa ordem que te mantenha acessível

A ordem importa aqui mais do que a velocidade. Levanta a ligação com cabo enquanto a sem fios ainda funciona, confirma o novo endereço e o caminho de retorno, e depois retira o perfil sem fios. Essa sequência mantém uma sessão operacional aberta até o substituto estar provado.

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 recebeu o endereço que pretendias, e o segundo imprime o endereço de origem que o kernel usaria para um destino exterior, por isso executa-o antes e depois da mudança. Se essa origem continuar a ser o endereço sem fios, a ligação com cabo ainda não é o caminho preferido e o teste de fora falhará por uma razão que nada tem a ver com o OpenVPN. Corrige a preferência de rotas antes de tocares no encaminhamento.

Com ambas as ligações ativas, a Pi pode preferir a rota predefinida sem fios porque foi instalada primeiro ou porque a ligação com cabo tem uma métrica mais alta. No Bookworm o controlo suportado é ipv4.route-metric na ligação, e no Bullseye o equivalente é uma linha metric específica da interface em dhcpcd.conf. Degrada a ligação sem fios em vez de a desativar, para que o caminho de reversão fique a um comando de distância.

Prova o túnel de fora, não da LAN

Uma ligação VPN que funciona do sofá prova menos do que parece. O tráfego de dentro da LAN para o endereço público passa por regras de hairpin ou reflexão que os routers implementam de forma inconsistente, por isso um teste LAN bem-sucedido pode coexistir com um caminho exterior quebrado. Usa um telefone com dados móveis, ou qualquer host fora da rede, para o teste de aceitação. Mantém a tentativa LAN como um diagnóstico opcional à parte.

Depois lê o log na ordem em que os pacotes chegam. Nada de nada significa que o handshake nunca chegou à Pi, por isso o destino de redirecionamento ou a firewall do host está errado. Um handshake que começa e encrava aponta para chaves, certificados ou MTU. Uma sessão que se completa e cai normalmente significa o caminho de retorno ou uma segunda rota predefinida, e a linha de log do cliente Initialization Sequence Completed diz-te que o túnel em si subiu.

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

Se não aparecer nada no log do servidor enquanto o cliente tenta de novo, para de ler a configuração do OpenVPN e volta ao destino de redirecionamento. A captura responde à pergunta da chegada em segundos, e os pacotes recebidos sem resposta reduzem o problema à rota.

Mantém uma reversão de um passo e retira o perfil sem fios

Deixa o perfil sem fios instalado até a disposição com cabo ter passado um reinício. nmcli con show lista os nomes de perfil de que vais precisar, e um perfil apagado tem de ser reconstruído de memória no pior momento. Regista o nome da interface, o método de endereço e a métrica ao lado dos outros quatro valores. Uma reversão que consegues escrever a partir de uma nota vale mais do que uma que tens de reconstruir.

Retirar a dependência sem fios é uma mudança de propriedade em vez de uma eliminação. Ao definir connection.autoconnect no mantêm-se intactas as credenciais e o histórico de endereços enquanto se impede a Pi de se voltar a ligar a uma rede da qual te afastaste.

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

Antes de dares o trabalho por terminado, confirma quatro coisas: o destino de redirecionamento corresponde ao endereço com cabo, o listener sobreviveu a um reinício, um cliente de fora completa um handshake, e a Pi ainda responde no endereço com cabo após um reinício. Um reinício é a forma mais barata de apanhar uma atribuição que só existia no kernel em execução. Se qualquer das quatro falhar, volta a levantar o perfil sem fios com sudo nmcli con up e compara os valores registados com os ativos.