On cal vigilar el trànsit d'un client OpenVPN a la passarel·la

Voleu saber a quines destinacions arriba un client connectat, així que obriu un intèrpret d'ordres al servidor VPN i escriviu ss. No hi apareix res d'útil, i la conclusió que el túnel està trencat arriba una mica massa fàcilment. Una passarel·la OpenVPN encaminada reenvia els paquets del client; no acaba les seves connexions TCP ni té sockets per a elles. La prova viu en un altre lloc, i aquest lloc depèn de com es tracta el trànsit un cop surt del túnel.

Decidiu quina disposició esteu mirant

Dues formes habituals produeixen proves completament diferents. Una passarel·la d'encaminament desencapsula, reenvia i potser fa NAT d'origen, de manera que la connexió del client continua existint d'extrem a extrem sense cap socket local.

Un proxy acaba el trànsit: accepta la connexió i després obre la seva pròpia connexió ascendent. En aquesta disposició hi ha dues connexions per a una petició, i l'associació entre elles només existeix als registres propis del proxy. Saber quin dels dos heu desplegat decideix si heu de llegir l'estat de fluxos del nucli o els registres de l'aplicació.

La major part de la confusió ve de conjecturar. Confirmeu la forma abans de triar l'eina. Llegiu primer la configuració del servidor per si hi ha una directiva de proxy, perquè la seva presència canvia tots els passos posteriors. Sense cap, el camí dels paquets és encaminament i l'estat de fluxos del nucli és la vostra prova.

Primer lligueu l'adreça a una sessió

Comenceu per l'estat de sessions del servidor i identifiqueu l'adreça interna actual del client. Les adreces de la reserva es reciclen, així que una adreça per si sola és un lloguer, no una persona.

Anoteu l'hora i la identitat autenticada juntes, i fixeu-vos si tota una LAN s'amaga darrere d'aquest client. Si l'extrem remot encamina una subxarxa, les adreces internes que veieu poden ser equips originals o traduïts.

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

Aquesta parella respon dues preguntes alhora: quin prefix serveix la interfície del túnel i quina sessió era activa durant l'interval que us interessa. Feu-ho abans d'interpretar qualsevol entrada de flux, perquè una tupla convincent lligada a la sessió equivocada és pitjor que no tenir cap prova.

Llegiu la taula de fluxos en una passarel·la d'encaminament

Un cop establertes l'adreça i l'interval, una llista de només lectura de les connexions rastrejades mostra què reenvia la passarel·la per a ella. Filtreu per l'origen original per no llegir tota la taula.

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

Cada entrada conté dues tuples, original i resposta, que són les dues direccions d'un sol flux i no dues aplicacions. En un camí amb NAT d'origen la tupla original conserva l'adreça del túnel mentre el costat de resposta mostra l'adreça traduïda de la passarel·la, i això és exactament el que fa que la sortida sembli incorrecta a primera vista.

Tracteu la llista com a estat viu i no com a historial. Els fluxos curts poden haver caducat ja, el trànsit no rastrejat no apareix mai, i un altre espai de noms de xarxa mostra una altra taula. La referència de conntrack documenta els filtres i la sortida en dues direccions.

Una captura limitada per confirmar la lectura

Si la interfície del túnel és visible on mireu, una sola captura limitada resol si els paquets que heu identificat són els que hi ha al cable. Manteniu el filtre estret i el límit de paquets petit.

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

Compareu les marques de temps, el protocol i els ports amb l'entrada de flux i amb la petició que heu fet com a prova. Una captura presa després del NAT només mostra l'adreça pública de la passarel·la, mentre que el costat del túnel encara pot mostrar la del client, i aquesta diferència és informació i no una inconsistència.

Si la interfície no veu res, comproveu el camí de dades abans de concloure que el client està inactiu: el trànsit de client a client i alguns camins de descàrrega mai no travessen el punt que mireu.

Registres del proxy i els límits del que heu vist

Quan un proxy és al camí, els seus sockets ascendents són visibles a la taula de sockets però no es corresponen u a u amb els clients VPN, sobretot amb agrupació o multiplexació. Feu servir el registre de transaccions configurat del proxy per correlacionar la identitat del client, la destinació, la marca de temps i qualsevol identificador de petició que enregistri.

Reviseu la configuració de registre de la versió desplegada en lloc de suposar que cada petició es registra per defecte.

Finalment, sigueu precisos sobre l'abast. Una adreça de destinació i un port són metadades, no un URL ni el contingut d'una pàgina, perquè la sessió HTTPS interna conserva la seva pròpia protecció independentment del túnel. Informeu del que heu observat, des de quin punt d'observació i a quina hora.