Gateway VPN no Raspberry Pi: uma só NIC ou uma porta de cliente dedicada

Tem um Pi, um perfil VPN de saída a funcionar e dois dispositivos que devem chegar à internet através dele. A pergunta que decide toda a construção não é qual guia seguir, mas quanta contenção precisa. Uma só porta deixa o Pi ficar ao lado desses dispositivos na LAN do router e funcionar como gateway adicional; uma segunda porta permite colocá-los num segmento onde o Pi é a única saída. Tudo o que vem depois dessa escolha — DHCP, âmbito da firewall, DNS, o caso de falha — decorre dela.

Em que diferem realmente os dois esquemas

Ambos os desenhos encaminham. A diferença está em quem mais está no cabo e no que acontece quando a política está errada.

A contenção é o eixo real. O esquema A é indicativo: um dispositivo que ignora o gateway fornecido por DHCP e escolhe o router continua a funcionar, mas sem cifra. O esquema B é imposto pela topologia, porque não há outro salto seguinte para escolher.

Esquema A: o Pi como gateway adicional na LAN existente

Suponha que o router do ISP é 192.168.50.1, o Pi é 192.168.50.2 e os clientes escolhidos apontam para o Pi. O importante é que dois fluxos de pacotes diferentes partilham um só cabo. O pacote interno do cliente chega ao Pi e tem de sair pelo túnel; o pacote cifrado do próprio Pi para o par VPN tem de sair pelo mesmo cabo para o router. Viajam em direções opostas na mesma interface e precisam de tratamento diferente.

Dê ao Pi o seu endereço através do gestor de rede instalado, não com uma receita antiga de ficheiro de interface que se lhe opõe pelo dispositivo. Depois configure os clientes: um gateway estático num dispositivo, ou uma reserva DHCP que entrega 192.168.50.2 como router. Não altere todo o âmbito DHCP do router por causa de dois dispositivos, e não assuma que um cliente respeita a opção — verifique.

A fraqueza é estrutural, não reparável. Qualquer cliente nesse segmento pode apontar para 192.168.50.1 e sair em claro, e um dispositivo com uma segunda interface ou rádio celular abandona por completo o seu caminho de imposição. Se essa frase é inaceitável para o dispositivo em causa, já tem a resposta: use o esquema B.

Esquema B: uma porta dedicada fecha os dispositivos dentro

Aqui o Pi mantém 192.168.50.2 na ligação ascendente com gateway 192.168.50.1, e assume 10.20.0.1/24 numa segunda interface para os dispositivos ligados. O Pi é agora um router com duas redes, e o segmento ligado tem exatamente uma saída.

Verifique o intervalo contra tudo o resto antes de se comprometer: a sub-rede do próprio túnel, outros prefixos entre locais e tudo o que é alcançável através da VPN. Um 10.20.0.0/24 que colide com uma LAN remota produz aquele resultado a meio funcionar que custa uma noite a diagnosticar. Se a segunda porta for um adaptador USB, confirme que é suportado e fixe o nome no gestor de rede para que uma reordenação após reinício não desloque o seu endereço de LAN.

Execute o ouvinte DHCP apenas nessa interface. Um servidor que responde na ligação ascendente compete com o router do ISP e entrega os endereços do seu segmento ao resto da casa. Ligue-o à interface LAN, restrinja-o ao intervalo declarado e mantenha o endereço do próprio Pi fora do conjunto.

Reencaminhamento, tradução e a regra de fecho em caso de falha

Quatro coisas são frequentemente descritas como uma e não são. Ativar o reencaminhamento (net.ipv4.ip_forward=1) diz apenas ao núcleo que pode mover pacotes entre interfaces; por si só não permite nada nem garante qualquer caminho. Escolher a saída é uma decisão de encaminhamento. Permitir o pacote é uma decisão de política na cadeia forward. Reescrever a sua origem é uma decisão de postrouting. Uma construção que só faz a primeira produz um Pi que reencaminha alegremente o tráfego dos clientes para fora pela ligação ascendente.

Limite a permissão às fontes que pretendia e à interface que o tráfego deve usar, e inclua o caminho de volta e os destinos de que o Pi precisa. Depois traduza na saída do túnel se o fornecedor não encaminhar o seu prefixo de LAN de volta. manual do nftables trata o reencaminhamento, a saída local e a tradução de origem como operações separadas, que é o modelo mental correto aqui.

A falha comum é uma regra masquerade larga na interface física. Então o tráfego chega à internet pela via do ISP enquanto, do lado do cliente, parece exatamente uma VPN a funcionar. Isso não prova nada. Mantenha a tradução ligada à saída declarada e mantenha as suas regras na firewall que o anfitrião já usa, em vez de acrescentar um conjunto de regras concorrente que esvazia uma cadeia postrouting partilhada.

Depois trate a ausência do túnel. Um perfil de cliente que instala uma rota predefinida larga também significa que, quando o túnel cai, a rota predefinida comum pode voltar e o tráfego dos clientes regressa em silêncio à ligação ascendente. Onde o regresso a texto simples não é aceitável, a política forward tem de negar explicitamente o tráfego de cliente para a ligação ascendente, no estado em que a rota VPN desapareceu. Escreva isso como regra de rejeição, não como suposição. O transporte cifrado do próprio Pi até ao par VPN é um fluxo local-output separado e tem de continuar permitido, senão o túnel nunca poderá voltar.

DNS e IPv6 precisam da sua própria resposta

Se os clientes usarem o Pi como resolvedor, chegam a um ouvinte local e o Pi origina uma nova consulta. Essa consulta ascendente segue a rota do próprio Pi, não a regra forward que escreveu para os clientes, portanto um caminho de cliente só pelo túnel mais um resolvedor que sai diretamente é uma fuga sem qualquer mensagem de erro. Decida deliberadamente: um resolvedor alcançado pelo túnel, ou um local que aceita como direto, e faça a política de saída do próprio Pi corresponder a essa decisão.

IPv6 é de novo um caso à parte. Uma regra forward para IPv4 não restringe nada quanto a IPv6, e os anúncios de router na ligação ascendente podem dar ao Pi, e por ele ao segmento ligado, uma segunda rota predefinida que contorna a sua política. Ou dá ao IPv6 o seu próprio caminho protegido pelo mesmo princípio, ou restringe-o explicitamente no segmento de clientes e diz isso.

Teste a fronteira antes de confiar nela

Aceite o desenho só depois de quatro verificações separadas, porque o teste único tentador — abrir um navegador num cliente — passa em vários estados avariados.

Confirme que um cliente real chega à internet pelo túnel e depois confirme que o mesmo cliente não chega à internet com o túnel em baixo. Confirme que a resolução DNS funciona e que a consulta sai onde pretendia. Confirme que o transporte do próprio Pi ainda funciona após um reinício do túnel, e que a recuperação não exige reiniciar a máquina. Por fim, verifique um dispositivo que não escolheu: no esquema A deve continuar a funcionar normalmente, e no esquema B não deve existir de todo nesse segmento.

• Duas portas e uma regra de negação dão imposição; uma porta e uma opção DHCP dão conselho.
• A tradução na interface errada parece um sucesso e não é.
• O tráfego do próprio Pi, o DNS e o IPv6 precisam cada um de uma decisão, não de uma inferência.