Uma NIC ou duas? Decidir a disposição das interfaces de um servidor VPN

Um único adaptador físico chega para muitos servidores VPN, e também não é uma solução universal. A ligação cifrada chega a esse adaptador, o processo VPN desencripta-a e, em seguida, o tráfego interno sai por uma interface virtual antes de chegar a um serviço local ou a uma LAN encaminhada. Se isso funciona depende de três condições: onde está o destino, se a LAN tem um caminho de regresso para o conjunto de clientes e se uma única ligação física partilhada lhe dá o isolamento que afirma. Responda às três e o número de adaptadores decorre daí.

As três condições que o decidem

A primeira condição é o destino. Um serviço no próprio servidor VPN é alcançado apenas pela interface do túnel, enquanto um servidor na LAN exige encaminhamento e um caminho de regresso. A segunda condição é esse caminho de regresso, porque o dispositivo da LAN tem de saber como chegar ao conjunto de clientes, seja por uma rota, seja por tradução no servidor.

A terceira condição é a separação. Um adaptador significa que cada pacote, cifrado ou não, partilha uma ligação e, habitualmente, uma cadeia de políticas, pelo que uma alegação de isolamento que depende de hardware separado não é satisfeita por uma única interface. É um facto sobre o caminho, não sobre a forma como o sistema operativo está configurado. Pode continuar a filtrar o tráfego do túnel, mas não pode reclamar uma fronteira que não tem.

Nenhuma das três diz respeito ao número de portas no chassis. Dizem respeito ao encaminhamento, à propriedade dos endereços e ao quanto o desenho depende da separação física.

Dois adaptadores continuam a ser uma escolha legítima quando zonas físicas, ligações ascendentes separadas, débito ou um caminho de recuperação fora de banda o justificam. São requisitos concretos e vale a pena declará-los antes de alguém encomendar hardware.

Quando o serviço corre no servidor VPN

O caso mais simples não precisa de encaminhamento nenhum. O daemon recebe os pacotes do cliente na interface do túnel e entrega-os a um socket local, e a resposta regressa pela mesma interface. Para o servidor, o endereço do conjunto de clientes é um endereço local verdadeiro.

Duas coisas têm de continuar certas: o serviço tem de escutar num endereço que o túnel consiga alcançar, e a firewall do servidor tem de aceitar o tráfego que chega à interface do túnel. Ambas são visíveis nos comandos abaixo.

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

Ligar um serviço apenas ao endereço público, ou filtrar a interface do túnel por engano, produz uma ligação que chega ao servidor e depois morre. Parece uma falha de VPN e é normalmente uma decisão de socket ou de firewall.

Quando o destino está na LAN

É aqui que um desenho de adaptador único ganha a reputação de ser complicado. O servidor tem de encaminhar os pacotes do cliente para a LAN, e o dispositivo da LAN tem de enviar as respostas de volta para o conjunto de clientes. Ou transporta esse conjunto como rota na LAN, ou traduz o endereço de origem no servidor para que as respostas voltem ao próprio servidor.

Ambas as respostas são legítimas e falham de forma diferente. Uma rota de regresso mantém o endereço original do cliente visível para o destino, o que é bom para registos e mau para regras de firewall que assumem endereços de LAN. A tradução mantém a LAN simples e esconde a identidade do cliente do destino.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

Um caminho assimétrico é o sintoma clássico: o pedido do cliente chega, a resposta sai por outro router e a ligação expira sem erro em nenhuma das pontas. Capture dos dois lados antes de concluir algo sobre o túnel.

Porque é que um alias não cria uma segunda zona

Adicionar um segundo endereço ao mesmo adaptador, ou criar uma interface dummy para imitar uma segunda porta, muda muito pouco. Os pacotes continuam a sair pela mesma ligação física, pela mesma porta do switch e habitualmente pela mesma cadeia de firewall, pelo que não existe uma nova fronteira entre eles. É conveniência de configuração, não segmentação. Tratá-lo como fronteira de zona é a forma de uma alegação de isolamento sobreviver apenas no papel.

Uma zona separada exige uma separação real no caminho, e é esse o requisito que um segundo adaptador satisfaz. Se uma regra depende de o tráfego virado para a VPN nunca partilhar um domínio de difusão com o tráfego virado para a LAN, um único cabo não pode garantir essa propriedade, independentemente do endereçamento do servidor.

Quando um produto documenta uma topologia multi-interface para um modo específico, siga a documentação desse produto em vez de inventar uma alternativa. Os fornecedores também alteram as topologias suportadas entre versões, o que é outra razão para ler o guia atual e não uma captura de ecrã de um assistente antigo.

Verifique a disposição face ao tráfego que permite

Liste as classes de tráfego que o servidor deve transportar: cliente para servidor, cliente para LAN, servidor para LAN e a ligação externa cifrada. Cada classe tem uma origem, um destino e uma interface, e a disposição tem de satisfazer as quatro ao mesmo tempo. Um desenho que resolve três delas é normalmente o que gera pedidos de suporte.

Depois confirme as interfaces reais e a captura real, não o diagrama do documento de projeto. Os comandos abaixo mostram as duas vistas.

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

Se a captura exterior mostrar o tráfego cifrado e a captura interior mostrar o tráfego desencriptado na interface do túnel, enquanto o adaptador físico transporta ambos, uma única NIC está a fazer o trabalho. Se a captura interior estiver vazia, o problema está no túnel ou nas regras de encaminhamento, não no número de adaptadores. Decida a topologia a partir dessas duas capturas e da tabela de rotas, e a próxima alteração terá algo com que ser comparada.