Onde observar o tráfego de um cliente OpenVPN no gateway

Quer saber a que destinos chega um cliente ligado, por isso abre uma shell no servidor VPN e escreve ss. Não aparece nada de útil, e a conclusão de que o túnel está avariado surge com demasiada facilidade. Um gateway OpenVPN encaminhado reencaminha os pacotes do cliente; não termina as suas ligações TCP nem possui sockets para elas. A prova vive noutro lugar, e qual depende de como o tráfego é tratado depois de sair do túnel.

Decida que disposição está a observar

Duas formas comuns produzem provas completamente diferentes. Um gateway de encaminhamento desencapsula, reencaminha e possivelmente aplica NAT de origem, pelo que a ligação do cliente continua a existir de ponta a ponta sem socket local.

Um proxy termina o tráfego: aceita a ligação e depois abre a sua própria ligação ascendente. Nessa disposição há duas ligações para um pedido, e a associação entre elas existe apenas nos registos do próprio proxy. Saber qual das duas implementou decide se deve ler o estado de fluxos do kernel ou os registos da aplicação.

A maior parte da confusão vem de adivinhar. Confirme a forma antes de escolher a ferramenta. Leia primeiro a configuração do servidor à procura de uma diretiva de proxy, porque a sua presença altera todos os passos seguintes. Sem ela, o caminho dos pacotes é encaminhamento e o estado de fluxos do kernel é a sua prova.

Ligue primeiro o endereço a uma sessão

Comece pelo estado de sessões do servidor e identifique o endereço interno atual do cliente. Os endereços do conjunto são reciclados, pelo que um endereço por si só é um aluguer, não uma pessoa.

Registe a hora e a identidade autenticada em conjunto, e repare se toda uma LAN se esconde atrás desse cliente. Se o extremo remoto encaminha uma sub-rede, os endereços internos que vê podem ser equipamentos originais ou traduzidos.

ip -4 addr show dev tun0
journalctl -u [email protected] --since '-10 min' | tail -n 40

Esse par responde a duas perguntas ao mesmo tempo: que prefixo serve a interface do túnel, e que sessão estava ativa no intervalo que lhe interessa. Faça isto antes de interpretar qualquer entrada de fluxo, porque um tuplo convincente ligado à sessão errada é pior do que nenhuma prova.

Leia a tabela de fluxos num gateway de encaminhamento

Estabelecidos o endereço e o intervalo, uma listagem apenas de leitura das ligações seguidas mostra o que o gateway reencaminha por ela. Filtre pela origem original para não ler a tabela inteira.

sudo conntrack -L -p tcp -f ipv4 --orig-src 10.8.0.37

Cada entrada contém dois tuplos, original e resposta, que são as duas direções de um só fluxo e não duas aplicações. Num caminho com NAT de origem o tuplo original mantém o endereço do túnel, enquanto o lado da resposta mostra o endereço traduzido do gateway, e é exatamente isso que faz a saída parecer errada à primeira vista.

Trate a listagem como estado vivo e não como histórico. Os fluxos curtos podem já ter expirado, o tráfego não seguido nunca aparece, e outro espaço de nomes de rede mostra outra tabela. A referência do conntrack documenta os filtros e a saída nas duas direções.

Uma captura limitada para confirmar a leitura

Se a interface do túnel for visível onde está a olhar, uma única captura limitada resolve se os pacotes que identificou são os que estão no cabo. Mantenha o filtro estreito e o limite de pacotes pequeno.

sudo tcpdump -ni tun0 -nn -c 50 'host 10.8.0.37 and tcp'

Compare marcas temporais, protocolo e portas com a entrada de fluxo e com o pedido que fez como teste. Uma captura feita depois do NAT mostra apenas o endereço público do gateway, enquanto o lado do túnel ainda pode mostrar o do cliente, e essa diferença é informação e não uma inconsistência.

Se a interface não vê nada, verifique o caminho dos dados antes de concluir que o cliente está inativo: o tráfego de cliente para cliente e alguns caminhos de descarga nunca atravessam o ponto que está a observar.

Registos do proxy e os limites do que viu

Quando um proxy está no caminho, os seus sockets ascendentes são visíveis na tabela de sockets mas não correspondem um a um aos clientes VPN, sobretudo com agrupamento ou multiplexagem. Use o registo de transações configurado do proxy para correlacionar a identidade do cliente, o destino, a marca temporal e qualquer identificador de pedido que registe.

Verifique a configuração de registo da versão implementada em vez de assumir que cada pedido é registado por predefinição.

Por fim, seja preciso quanto ao âmbito. Um endereço de destino e uma porta são metadados, não um URL nem o conteúdo de uma página, porque a sessão HTTPS interna mantém a sua própria proteção independentemente do túnel. Relate o que observou, a partir de que ponto de observação e a que horas.