Onde vixiar o tráfico dun cliente OpenVPN na pasarela

Quere saber a que destinos chega un cliente conectado, así que abre unha consola no servidor VPN e escribe ss. Non aparece nada útil, e a conclusión de que o túnel está roto chega con demasiada facilidade. Unha pasarela OpenVPN encamiñada reenvía os paquetes do cliente; non remata as súas conexións TCP nin posúe sockets para elas. A proba vive noutro lugar, e cal depende de como se trate o tráfico unha vez que sae do túnel.

Decida que disposición está a mirar

Dúas formas habituais producen probas completamente distintas. Unha pasarela de encamiñamento desencapsula, reenvía e quizais aplica NAT de orixe, de xeito que a conexión do cliente segue existindo de extremo a extremo sen un socket local.

Un proxy remata o tráfico: acepta a conexión e despois abre a súa propia conexión ascendente. Nesa disposición hai dúas conexións para unha petición, e a asociación entre elas só existe nos rexistros propios do proxy. Saber cal das dúas despregou decide se debe ler o estado de fluxos do núcleo ou os rexistros da aplicación.

A maior parte da confusión vén de adiviñar. Confirme a forma antes de escoller a ferramenta. Lea primeiro a configuración do servidor por se hai unha directiva de proxy, porque a súa presenza cambia todos os pasos posteriores. Sen ela, o camiño dos paquetes é encamiñamento e o estado de fluxos do núcleo é a súa proba.

Ate primeiro o enderezo a unha sesión

Comece polo estado de sesións do servidor e identifique o enderezo interno actual do cliente. Os enderezos do grupo recíclanse, así que un enderezo por si só é un alugueiro, non unha persoa.

Anote a hora e a identidade autenticada xuntas, e fíxese se toda unha LAN se agocha detrás dese cliente. Se o extremo remoto encamiña unha subrede, os enderezos internos que ve poden ser equipos orixinais ou traducidos.

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

Ese par responde dúas preguntas á vez: que prefixo serve a interface do túnel e que sesión estaba activa durante o intervalo que lle interesa. Fágao antes de interpretar calquera entrada de fluxo, porque unha tupla convincente atada á sesión equivocada é peor que non ter ningunha proba.

Lea a táboa de fluxos nunha pasarela de encamiñamento

Establecidos o enderezo e o intervalo, unha listaxe de só lectura das conexións rastrexadas mostra que reenvía a pasarela para ela. Filtre pola orixe orixinal para non ler toda a táboa.

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

Cada entrada contén dúas tuplas, orixinal e resposta, que son as dúas direccións dun mesmo fluxo e non dúas aplicacións. Nun camiño con NAT de orixe a tupla orixinal conserva o enderezo do túnel mentres o lado de resposta mostra o enderezo traducido da pasarela, e iso é exactamente o que fai que a saída pareza incorrecta a primeira vista.

Trate a listaxe como estado vivo e non como historial. Os fluxos curtos poden caducar xa, o tráfico non rastrexado nunca aparece, e outro espazo de nomes de rede mostra outra táboa. A referencia de conntrack documenta os filtros e a saída en dúas direccións.

Unha captura limitada para confirmar a lectura

Se a interface do túnel é visible onde mira, unha soa captura limitada resolve se os paquetes que identificou son os que hai no cable. Manteña o filtro estreito e o límite de paquetes pequeno.

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

Compare marcas de tempo, protocolo e portos coa entrada de fluxo e coa petición que fixo como proba. Unha captura tomada despois do NAT só mostra o enderezo público da pasarela, mentres que o lado do túnel aínda pode mostrar o do cliente, e esa diferenza é información e non unha inconsistencia.

Se a interface non ve nada, comprobe o camiño de datos antes de concluír que o cliente está inactivo: o tráfico de cliente a cliente e algúns camiños de descarga nunca atravesan o punto que vixía.

Rexistros do proxy e os límites do que viu

Cando un proxy está no camiño, os seus sockets ascendentes son visibles na táboa de sockets pero non se corresponden un a un cos clientes VPN, sobre todo con agrupación ou multiplexación. Use o rexistro de transaccións configurado do proxy para correlacionar a identidade do cliente, o destino, a marca de tempo e calquera identificador de petición que rexistre.

Revise a configuración de rexistro da versión despregada en lugar de supoñer que toda petición se rexistra por defecto.

Por último, sexa preciso sobre o alcance. Un enderezo de destino e un porto son metadatos, non un URL nin o contido dunha páxina, porque a sesión HTTPS interna conserva a súa propia protección independentemente do túnel. Informe do que observou, desde que punto de observación e a que hora.