Porque uma reserva DHCP não é um IP estático para o teu servidor VPN

Mudei uma caixa VPN doméstica do Wi-Fi para o Ethernet e o seu endereço «permanente» mudou nessa mesma noite. No router não havia nada avariado. A reserva correspondia ao adaptador sem fios, e esse adaptador já não estava no caminho.

O mesmo equívoco tem uma segunda metade. Corrigir o endereço LAN não faz nada pelo endereço a que os teus amigos se ligam, e não tem nada a ver com o conjunto privado que a VPN entrega aos clientes. Três endereços, três modos de falha distintos, e só um deles é trabalho de uma reserva.

Uma reserva corresponde a um cliente, não a um dispositivo

Em DHCPv4 a reserva está ligada ao endereço de hardware do cliente; em DHCPv6 está ligada a um DUID que se espera que o cliente conserve. O campo hostname é uma etiqueta para humanos. O que o router compara de facto é o identificador que chega no pedido.

Lê a entrada como uma condição: quando este identificador pede, dá-lhe este endereço. As renovações mantêm o mesmo aluguer enquanto a correspondência se mantém, e um reinício volta simplesmente a pedir. Quando o identificador muda, o pedido falha a reserva e o cliente fica com o que o conjunto dinâmico oferecer. Sem erro, sem aviso, apenas um endereço diferente.

O OpenWrt mostra a forma com clareza. Um bloco config host em /etc/config/dhcp liga um nome, um MAC e um endereço, e a documentação dos alugueres estáticos explica como essa entrada interage com o conjunto. Outros routers escondem os mesmos três campos atrás de etiquetas diferentes.

Onde a correspondência cai em silêncio

Trocar de hardware é o caso comum. Troca a placa de rede, ou move a máquina entre Ethernet e Wi-Fi, e o endereço que o router vê muda com ela. A reserva antiga fica na lista, ainda a parecer correta.

Uma reinstalação é o segundo caso, e morde mais forte em IPv6. Uma instalação nova pode gerar um DUID novo enquanto o aluguer IPv4 antigo ainda é válido, por isso o endereço v4 sobrevive algum tempo e a entrada v6 deixa de se aplicar sem qualquer edição visível.

O terceiro é um identificador de cliente fixado. Vários clientes DHCP permitem definir uma cadeia de identificador em vez de usar o MAC. Se uma atualização ou uma reescrita da configuração eliminar essa definição, a correspondência desaparece mesmo que a máquina não se tenha movido.

O quarto é a duplicação: um bloco antigo e um bloco novo para o mesmo anfitrião. O servidor responde com a regra que corresponder, muitas vezes o endereço do conjunto que querias evitar. Apaga a entrada antiga em vez de acrescentar uma segunda.

Configuração do lado do anfitrião e quanto custa

Definir o endereço no anfitrião elimina por completo a questão da correspondência. A interface sobe com esse endereço responda o DHCP ou não, e é isso que queres de uma máquina que tem de estar acessível depois de reiniciar o router.

O custo é a propriedade. Agora és tu que forneces o prefixo, a gateway e os resolvedores, e tens de manter o endereço fora do conjunto dinâmico por tua conta. No Ubuntu com netplan, leva-o /etc/netplan/01-vpn.yaml:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: false
      addresses: [192.168.50.10/24]
      routes:
        - to: default
          via: 192.168.50.1
      nameservers:
        addresses: [192.168.50.1]

Os utilizadores do NetworkManager chegam ao mesmo estado com nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1, e depois com nmcli con up "Wired connection 1". Aplica o netplan com netplan try à primeira tentativa em vez de netplan apply; uma gateway mal escrita tira a caixa da rede e deixa-te à procura de uma consola.

Mantém ainda assim uma reserva correspondente. Não é redundante. A entrada registra o endereço do lado do router e impede o servidor DHCP de dar esse endereço a um dispositivo convidado se alguém alargar o conjunto mais tarde.

Um endereço LAN estável não é um ponto final público

Aponta o port forward para 192.168.50.10 e a regra sobrevive a cada alteração do lado LAN. Não te dá um endereço de internet estável. O teu IP público pertence ao ISP e pode deslocar-se numa reconexão ou numa troca de modem, que é para isso que serve o DNS dinâmico.

Atrás de NAT de nível de operador não há nenhum IPv4 público para encaminhar, e nenhuma reserva cria um. Verifica a página WAN do router antes de qualquer outra coisa: se o endereço estiver num intervalo partilhado, o encaminhamento de entrada não pode funcionar, por muito limpa que seja a reserva.

O terceiro endereço é o conjunto do túnel, muitas vezes algo como 10.8.0.0/24. Esses endereços só existem dentro do túnel e nunca aparecem na LAN. Confundi-los com o endereço LAN do servidor é como uma porta acaba encaminhada para um cliente que só está online enquanto está ligado.

Verifica o caminho na ordem em que se quebra

Começa no router. Compara a entrada da tabela de alugueres com o alvo da reserva; se o servidor ficou com um endereço do conjunto, o identificador está errado, e ip link show no anfitrião dá-te o valor para comparar.

Depois o anfitrião. ip -4 addr show eth0 deve indicar o endereço e o prefixo esperados. Um segundo endereço na mesma interface normalmente significa que o DHCP ainda está a correr ao lado da tua configuração estática.

Depois o encaminhamento. Confirma que o destino continua igual ao endereço que acabaste de verificar, e confirma que algo está à escuta com ss -lntp. Um encaminhamento para uma porta fechada parece exatamente um encaminhamento avariado visto de fora.

Termina de fora, num telefone com o Wi-Fi desligado. Esse único teste separa «o endereço local está errado» de «a acessibilidade pública está avariada», os dois problemas que esta configuração não se cansa de misturar.

Anota os três endereços, LAN, público e conjunto do túnel, e indica que sistema possui cada um. Quando no próximo mês uma ligação falhar, vais saber qual inspecionar em vez de mudar os três ao mesmo tempo.