Um único host público para VPN e web: como dividir as funções

Uma só máquina pode atender às três necessidades ao mesmo tempo: terminar túneis, responder em HTTPS e encaminhar entre duas LAN privadas. Se isso é sensato resume-se a três pontos que pode resolver no papel: quem é dono do endereço público, quem é dono de cada par de porta e protocolo e qual processo tem permissão para encaminhar pacotes. Se acertar, o host compartilhado não tem nada de especial. Se errar, vai passar um fim de semana com um serviço que arranca limpo e nunca responde.

O que se segue é um procedimento de decisão, não uma folha de construção. Cada passo termina com a verificação que prova que a função que acabou de acrescentar está realmente isolada.

Escolha o dono do endereço antes das portas

Um endpoint de túnel e um servidor web podem partilhar um kernel; partilhar um endereço, uma porta e um protocolo ao mesmo tempo é o que falha. O WireGuard ocupa normalmente UDP 51820, OpenVPN ocupa UDP 1194 ou TCP 443, e um servidor web ocupa TCP 443. O par que dói é o OpenVPN sobre TCP 443 ao lado do HTTPS, porque ambos querem o mesmo socket e o kernel dá-o a quem se ligou primeiro. Só um demultiplexador à frente, como o sslh ou um proxy conhecedor de TLS, os deixa partilhar essa porta, e acrescenta um componente cuja falha parece exatamente um problema de firewall.

Olhe para os donos antes de mudar o que quer que seja: ss -lntup imprime o endereço local, a porta e o processo de cada socket à escuta. Duas linhas a mostrar 0.0.0.0:443 significam que o segundo serviço nunca se ligou, por mais alegre que fosse o seu script init. A ponte também move o dono. Quando eth0 se junta a br0, o IP passa para br0 e cada regra de firewall que nomeia eth0 deixa de coincidir, por isso ligue os serviços na ponte e confirme com ip -br addr.

A mesma regra de propriedade explica uma surpresa que aparece com máquinas virtuais. Um servidor de túnel que corre dentro de um convidado na mesma LAN mantém o endereço do convidado, por isso as ligações dirigidas ao endereço do próprio anfitrião ficam no anfitrião e o túnel do convidado nunca as vê, diga o que disser o perfil do cliente.

Encaminhe entre as duas LAN ou faça NAT de um lado

Duas LAN que não se veem podem cada uma marcar o host público, que depois encaminha entre os túneis. Esse desenho encaminhado precisa de três coisas: encaminhamento ligado, uma rota para cada prefixo remoto e uma política de encaminhamento que deixe passar o trânsito. sysctl -w net.ipv4.ip_forward=1 cobre a primeira, ip route add 10.20.0.0/24 dev wg1 a segunda, e uma linha nftables como nft add rule inet filter forward iifname "wg0" oifname "wg1" accept a terceira.

O NAT de origem é mais fácil de acrescentar e mais difícil de depurar. O masquerading reescreve o endereço do cliente, por isso o lado remoto vê o hub em vez do anfitrião real, e as suas regras de acesso e registos deixam de ser úteis para atribuição. Quando as duas redes são suas, encaminhe. Quando um lado pertence a um terceiro que não vai acrescentar uma rota de retorno, o NAT é a opção que sai esta semana. De qualquer forma, escreva o plano de endereços, porque duas /24 sobrepostas não podem ser encaminhadas por nenhuma configuração.

Nada no facto de a caixa servir de saída para a internet de um portátil impede a mesma caixa de terminar túneis de entrada. Só os endereços sobrepostos o impedem, e é por isso que o plano de endereços é o documento que importa.

Teste a divisão com duas funções paradas

O teste útil é a subtração: pare duas funções e confirme que a terceira ainda responde. Um pedido web deve completar-se com o serviço de túnel desligado, e um aperto de mão de túnel deve completar-se com o servidor web parado. Se ambos só funcionam quando tudo corre, tem uma dependência acidental, como uma tabela de firewall partilhada, uma rota perdida ou um nome a apontar para o endereço errado.

Três comandos tornam esse teste concreto. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ prova que o ouvinte local responde sem DNS externo, wg show no cliente prova que o aperto de mão se completou, e tcpdump -ni any port 51820 no hub separa um problema de encaminhamento de um problema de chave. Um aperto de mão que nunca aparece na captura morreu antes do anfitrião: firewall do fornecedor, endereço público errado ou uma regra NAT no caminho.

Repita a subtração para as LAN encaminhadas. Com um par desligado, um ping através do hub deve falhar; com ele reconectado, o ping deve recuperar sem tocar numa regra. Um ping que só recupera depois de reiniciar o túnel aponta para a política e não para a acessibilidade, e isso é outra correção.

Mantenha o conjunto de regras legível enquanto subtrai funções. nft list ruleset deve mostrar uma regra de aceitação por direção de que realmente precisa, e uma cadeia de encaminhamento que aceita tudo não é separação, é uma demonstração a funcionar.

Linhas de acesso apenas IPv6 e serviços IPv4

Algumas linhas de acesso só dão acessibilidade IPv6, e os serviços têm de ser publicados por IPv4 na mesma. O próprio túnel viaja pela família que ainda deixa passar tráfego, enquanto o serviço publicado fica num endereço dentro do túnel. Isso inverte a suposição habitual e quebra a monitorização em silêncio: uma regra de firewall ou uma verificação de uptime escrita para o caminho IPv4 passa a vigiar uma interface que não transporta nada.

Teste cada família separadamente com curl -4 e curl -6, porque um pedido bem-sucedido não diz nada sobre o caminho que não experimentou. A propriedade das portas não muda entre famílias, mas o ouvinte muda: ss -lntup lista os sockets IPv4 e IPv6 em linhas separadas, e 0.0.0.0:443 não cobre [::]:443 a menos que o processo tenha pedido um socket dual-stack.

Um serviço que responde numa família e recusa na outra é normalmente um problema de ouvinte, não de encaminhamento. Antes de dar o desenho por terminado, confirme que cada função tem o seu próprio endereço ou porta, que o encaminhamento está ligado e permitido, e que cada função ainda responde com as outras duas paradas.