Abrir a porta VPN não faz os clientes chegarem à LAN

O túnel sobe, o cliente autentica-se, mas a LAN atrás do gateway continua invisível. A regra que devia corrigir isso permite a porta VPN e funciona exatamente como está escrita, porque essa regra governa os pacotes dirigidos ao próprio gateway. O tráfego do cliente para um host atrás do gateway tem outro destino e outra cadeia. Um início de sessão bem-sucedido não muda qual das duas cadeias o kernel consulta.

Duas cadeias, dois destinos diferentes

O destino de um pacote é decidido por onde ele vai, não por como chegou. O tráfego dirigido a um endereço do gateway é entregue localmente e avaliado pelas regras de entrada. O tráfego que o gateway encaminha é avaliado pelas regras de encaminhamento. A mesma interface de túnel pode produzir os dois tipos de pacote, por isso uma só regra não cobre as duas tarefas.

Todo o mito numa frase: permitir o ouvinte não diz nada sobre permitir a rede por trás dele. São duas decisões separadas com provas separadas, e um nome de interface nas duas não as funde.

O que a regra do ouvinte realmente admite

Os pacotes do ouvinte terminam no processo VPN, e é isso que permite estabelecer o túnel. A página de administração do gateway e uma resposta de diagnóstico local também usam o caminho de entrada do próprio host, por isso um teste ao gateway passa enquanto tudo atrás dele falha. Os dois resultados estão corretos e nenhum trata da LAN.

Quando o processo desencapsula o tráfego do cliente para outro destino, o pacote entra no caminho de encaminhamento e precisa de permissão ali. A autenticação bem-sucedida decide quem é o cliente; não decide para onde ele pode ir. As duas perguntas têm donos, registos e mensagens de erro diferentes.

Teste a partir de um cliente, nunca a partir do gateway

Um teste gerado no gateway segue o caminho de saída do próprio host e pode passar enquanto o caminho encaminhado está fechado. Comece o teste no cliente e observe as duas pontas do fluxo.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Se o pedido aparecer em tun0 e nada chegar ao destino, o pacote é descartado após a chegada, o que aponta para as regras de encaminhamento ou para a filtragem do próprio destino. Se nada aparecer em tun0, o cliente nem sequer o envia para o túnel, e o problema é o roteamento no cliente e não a política no gateway. Compare com um pedido que sai corretamente e não devolve nada, que é o caso do caminho de volta.

O encaminhamento precisa de três coisas, não de uma

O encaminhamento no kernel tem de estar ativo, uma regra de filtro tem de aceitar o fluxo, e o destino tem de ser alcançável com um caminho para a resposta voltar. Se faltar uma das três, o silêncio é o mesmo do ponto de vista do cliente.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

Leia as três saídas em conjunto. Um zero na primeira torna as outras duas irrelevantes, e uma política de descarte predefinida na segunda descarta os pacotes do cliente enquanto o tráfego do próprio gateway continua a funcionar. A terceira saída mostra porque a regra do ouvinte nunca foi o problema.

Mantenha os dois conjuntos de regras separados na documentação

Escreva a regra do ouvinte e a regra do serviço encaminhado em linhas separadas, com donos e motivos separados. Quando a porta VPN muda ou um novo serviço é publicado, essa separação impede que uma alteração alargue silenciosamente a outra.

Em vez de tratar cada par autenticado como membro de confiança da LAN, use regras estreitas para os intervalos de clientes e os serviços que delas precisam. As notas de encaminhamento do StrongSwan descrevem o lado da rota de retorno e da tradução da mesma fronteira, que é novamente uma terceira decisão.

Por fim, mantenha as camadas direitas quando um utilizador é recusado. Se o pedido chega ao host e a aplicação recusa a conta, repare a permissão da aplicação nessa camada; alargar o encaminhamento não pode fornecer credenciais de partilha de ficheiros e vai alargar o acesso a todos os outros que se ligam com sucesso.