El trànsit passa realment pel VPN? Com verificar-ho
La consulta de ruta, el primer salt, una captura a l'adaptador físic i una comprovació de l'adreça des de fora responen a parts diferents de la pregunta.
Dos errors semblen idèntics des de la icona de la safata: el trànsit que entra al túnel i el trànsit que l'envolta en silenci. El client mostra Connected en tots dos casos, perquè Connected només vol dir que la interfície del túnel existeix i que el client ha instal·lat les rutes que volia. Si un paquet d'una aplicació va fer servir aquestes rutes és una pregunta a part, que es respon en un altre punt de la pila. Quatre mesures resolen la major part — la consulta de ruta, el primer salt, una captura a l'adaptador físic i una observació des de fora — i la vista de sessió del servidor cobreix la resta.
Comenceu per la ruta que prendrà el paquet
La taula d'encaminament és la decisió, així que pregunteu-li per una destinació en lloc de llegir-la sencera i endevinar. A Linux, ip route get indica la interfície i l'adreça d'origen que ha triat el nucli:
ip route get 203.0.113.10
ip route get 10.20.5.7A Windows, Find-NetRoute -RemoteIPAddress 203.0.113.10 és més útil que route print -4 pel mateix motiu: informa de la ruta que ha guanyat, no de totes les rutes que existeixen. Tot i així, llegiu la taula una vegada per la seva fila 0.0.0.0. Una parella /1 allà vol dir que un client de túnel complet ha reescrit la ruta per defecte: l'opció redirect-gateway def1 d'OpenVPN instal·la 0.0.0.0/1 i 128.0.0.0/1 pel túnel, cosa que guanya a la 0.0.0.0/0 existent per la coincidència de prefix més llarga sense esborrar la ruta per defecte física. Per això dues rutes per defecte poden conviure mentre tot continua entrant al túnel.
Dos detalls fan que la taula menteixi. Primer, mireu el prefix que ha coincidit i no el nombre de rutes per defecte, perquè la mètrica de la interfície o una parella /1 decideixen el guanyador. Segon, una connexió que ja existeix conserva el camí amb què es va establir; després que el túnel pugi, una sessió oberta pot continuar fent servir la ruta antiga fins que es reiniciï, i per això reconnectar-se sembla arreglar un problema d'encaminament. Un client en marxa — ps ax | grep openvpn — només demostra que el procés s'ha iniciat.
Resseguiu un nom intern i un nom públic
La consulta de ruta mostra la intenció; el camí mostra el lliurament. Resseguiu un nom que ha de ser intern i un que no ho ha de ser, mentre esteu connectats, i compareu el primer salt:
traceroute intranet.corp.example
traceroute 1.1.1.1El mateix primer salt per a tots dos vol dir que el nom intern no ha entrat mai al túnel i que la fallada és per sobre, normalment un nom que es resol a una adreça pública o una ruta que no es va instal·lar mai. Si el trànsit intern surt per 10.8.0.1 mentre el públic surt per 192.168.1.1, el túnel partit fa exactament allò per a què es va configurar. Un traçat que arriba a la passarel·la del VPN i després només retorna temps d'espera sol ser un problema de camí de tornada o del tallafoc del servidor, no una ruta d'avançament absent.
L'ICMP filtrat fa que aquesta comprovació menteixi: estrelles a tots dos traçats semblen un túnel mort i normalment són un tallafoc. Provedeu un port TCP on pugueu — traceroute -T -p 443 a Linux — i recordeu que el traçat no diu quin resolutor ha contestat: un nom es pot resoldre localment i tot i així arribar-s'hi pel túnel.
Captureu a l'adaptador físic, no al túnel
L'enllaç físic és l'únic lloc que mostra què veu realment la xarxa. Amb el túnel aixecat, una sessió a l'oficina hauria d'aparèixer com a càrrega xifrada adreçada al servidor VPN, no com una connexió a 10.20.5.7:
sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5El primer filtre caça la resolució de noms que surt localment, que és la fuita més comuna i la més silenciosa — la pàgina encara carrega, el resolutor només ha vist la consulta. El segon caça trànsit pla a una adreça interna que només hauria d'existir dins del túnel. A Windows, pktmon fa la mateixa feina sense controlador: pktmon filter add -p 53, després pktmon start --capture --pkt-size 128, després pktmon stop i pktmon format pktmon.etl -o capture.txt. Aquests indicadors varien una mica entre versions de Windows, així que comproveu pktmon filter add /? abans de confiar en la sintaxi.
Captureu la interfície física per trobar fuites; una captura al túnel conté els paquets que ja creieu que hi són, i en un servidor conté paquets externs il·legibles la font dels quals és la passarel·la. Els comptadors de bytes de qualsevol interfície descriuen paquets, no programes; atribuir trànsit a un procés necessita un monitor que associï sockets amb processos.
Pregunteu a un servei extern, i torneu a preguntar-ho per aplicació
L'única comprovació que demostra la sortida és una resposta des de fora: un servei que retorna l'adreça d'origen que ha vist. Executeu-lo des d'un intèrpret d'ordres, on podeu triar la interfície, i executeu-lo dues vegades:
sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ipRespostes diferents us donen prova de tots dos camins i una manera de provar una aplicació concreta: lligueu-la, o executeu-la en un espai de noms de xarxa amb una sola ruta, i mireu quina adreça enregistra l'extrem llunyà. Respostes idèntiques són la fallada interessant: o la lligadura no ha tingut efecte, o alguna cosa entre l'amfitrió i l'extrem llunyà reescriu l'adreça d'origen abans que arribi. A Windows, curl --interface vol l'adreça de l'adaptador i no el seu nom.
Un navegador que informa de l'adreça del VPN demostra el navegador. Un client de correu, un gestor de paquets, un agent de còpia de seguretat o un segon perfil de navegador poden prendre cadascun un camí diferent, sobretot quan un paràmetre de servidor intermediari o una ruta de túnel partit en cobreix un. Un canvi d'adreça no és prova de fuita per si sol: un balancejador pot contestar diferent segons la sortida que ha vist, així que compareu l'adreça d'origen enregistrada, no la pàgina.
Feu servir la vista del servidor per confirmar el parell
El servidor respon una altra pregunta: si un parell està connectat, quant ha portat i si la sessió s'ha reiniciat. Un parell actiu al servidor mentre els comptadors del client gairebé no es mouen vol dir que el trànsit de l'aplicació no entra al túnel, digui el que digui la taula del client. Un parell que mou moltes dades per a un usuari que diu que no li funciona res és una altra investigació.
Aquí hi ha dues trampes. Un túnel emmascarat fa que cada flux sembli venir de la passarel·la, així que els registres i la comptabilitat per client es col·lapsen en una sola adreça. I el client es tracta com un amfitrió local, així que la pregunta sobre si algú copia fitxers pel VPN es respon amb el trànsit de compartició de fitxers al servidor o amb l'auditoria de l'amfitrió al servidor — vigilar el túnel dóna extrems i volum, no noms de fitxers.
Distingiu una decisió de disseny d'una fuita
No tot el que queda fora del túnel és una fuita. El trànsit d'enllaç local i de difusió es queda local per disseny, una impressora trobada per multicast continua anunciant-se a la LAN, i el DHCP ha de sortir localment. Una aplicació lligada a una interfície concreta evita la taula d'encaminament a propòsit, i només una regla de tallafoc, un espai de noms o una ruta de política ho canvien.
IPv6 mereix la seva pròpia línia a la llista de comprovació. Un túnel que només porta IPv4 deixa un amfitrió de doble pila amb un segon camí utilitzable, i una destinació de doble pila el preferirà — inclòs el DNS, si el resolutor és abastable per IPv6. Desactiveu IPv6 a l'adaptador o confirmeu que el túnel el porta abans de tractar un resultat IPv4 com a complet.
Quan les comprovacions no coincideixen, la discrepància sol assenyalar la fallada:
| What you see | What it means | Next step |
|---|---|---|
| The route picks tun0 but the capture shows cleartext to 10.20.5.7 | Something bypassed the table: a bound app, a policy route or a session older than the tunnel | Reset the flow, check the app bind, check the ip rule list |
| The route picks eth0 for an internal name | The name resolves to a public address, or the route was never installed | Compare the resolved address with the routes the server pushes |
| The capture shows DNS to the LAN resolver | Resolver leak: data is tunneled, lookups are not | Point the resolver inside, or push it from the server |
| All four checks agree and one app still fails | Path selection is fine; suspect MTU, a per-app proxy or the far end | Test the same destination from a known-good client |
Un ordre que funciona: deseu la taula d'encaminament abans i després de connectar, resseguiu un nom intern i un de públic, captureu DNS a l'adaptador físic, retorneu l'adreça de sortida des de l'intèrpret per a l'aplicació concreta, i després llegiu el servidor pel volum. Si les quatre primeres coincideixen, el túnel porta el que us penseu i el problema restant és per sobre. Si dues no coincideixen, la parella que discrepa és la fallada, no la icona.