Què és un túnel VPN i on s’atura la protecció

El client diu que està connectat, el cadenat és tancat i, tot i així, un lloc encara registra l’adreça del teu pis. No ha fallat res. Un túnel no substitueix la teva Wi-Fi ni el teu enllaç mòbil; posa un segon sobre al voltant de determinats paquets i envia aquest sobre per la xarxa que ja tenies. Entendre el truc és, sobretot, qüestió de seguir una sol·licitud i fixar-se on s’obre el sobre, perquè gairebé tots els símptomes confusos, des d’una adreça de casa que es filtra fins a una gran descàrrega encallada, vénen d’aquesta frontera.

Dos sobres, un enllaç físic

El portàtil manté la connexió normal amb el router, i el router manté la connexió normal amb el proveïdor. Res d’aquest camí no canvia quan s’aixeca un túnel. El que canvia és que determinats paquets es lliuren a una interfície virtual, s’embolcallen dins d’un paquet nou adreçat a l’igual de VPN i s’envien com a trànsit ordinari per l’enllaç físic.

L’extrem receptor és un dispositiu que desembolcalla el sobre i reenvia el paquet original cap a la seva destinació. Entre els dos extrems, un observador veu la capçalera exterior i res de la interior, tret que el protocol la xifri, cosa que fan la majoria de protocols de consum i que la tècnica general no exigeix.

Per això la interfície virtual és alhora real i enganyosa. Existeix com a objecte del nucli amb una adreça i una unitat màxima de transmissió, i el sistema operatiu hi encamina el trànsit com a qualsevol altra interfície. No és un cable, i la seva existència només demostra que hi ha un component instal·lat. Si el navegador la fa servir ho decideixen les rutes, no que la interfície estigui aixecada.

Mira com viatja una sol·licitud

Tria una destinació i pregunta al nucli quina interfície farà servir. Aquesta única ordre resol la majoria de discussions sobre si el túnel fa alguna cosa:

ip route get 203.0.113.7
ip -brief addr show
ip -4 addr show dev wg0

Si la sortida de la ruta anomena la interfície del túnel, el paquet s’embolcallarà. Si anomena la interfície física, no ho farà, i cap reinici del client ho canvia. La segona ordre mostra les dues interfícies costat a costat, i així és com detectes un túnel que s’ha aixecat sense adreça o amb una adreça de la família equivocada.

Després mira el primer salt des de dins del sobre i compara’l amb el primer salt de fora:

traceroute -n -m 3 203.0.113.7
sudo tcpdump -ni wg0 -c 5

Dins del túnel, el primer salt és l’adreça interior de l’igual, no el teu router. La captura a la interfície del túnel mostra els paquets interiors, que és el trànsit que l’aplicació creu que envia. Capturar alhora a la interfície física mostra els paquets exteriors, i les dues coses juntes són la demostració més clara del que fa realment un túnel.

Tres adreces, i el lloc només en veu una

La gent les confon constantment, i la confusió genera informes de fuita falsos. Són camps diferents en capçaleres diferents amb vides diferents.

El número que hi ha al costat de l’adaptador virtual és la segona fila. No és l’adreça que registra un lloc, i citar-lo com la teva IP pública és simplement un error. L’adreça que veu un lloc l’assigna la sortida, i en un túnel de xarxa privada pot no haver-hi cap sortida pública, perquè la destinació viu dins de l’organització i no a internet.

Un túnel entre seus és el mateix mecanisme amb extrems diferents. Dos routers embolcallen trànsit entre xarxes, i cap dispositiu individual té un client instal·lat. El sobre és idèntic en principi, i la frontera administrativa no.

On s’obre el sobre i què en sobreviu

El túnel acaba al seu igual. Si el xifratge propi de l’aplicació arriba més enllà, sobreviu a aquesta frontera, que és el cas normal a HTTPS: la sessió del navegador acaba al lloc, així que la sortida reenvia text xifrat que no pot llegir.

Res més no sobreviu per defecte. Una sol·licitud sense xifrar és llegible a la sortida exactament com era llegible a la Wi-Fi del cafè, i el túnel no afegeix una protecció que l’aplicació mai no havia tingut. Igualment, les regles de tallafoc i la política de reenviament de la sortida decideixen què passa després; un handshake correcte és un fet sobre la connexió amb l’igual, no sobre la resta del viatge.

La sobrecàrrega és l’altra conseqüència visible. Cada paquet porta una capçalera extra, i el transport exterior pot afegir-ne la seva, així que la càrrega útil per paquet es redueix. En un camí amb una unitat màxima de transmissió fixa, és exactament per això que un túnel pot passar un ping i encallar una càrrega gran.

Comprova el camí que l’aplicació ha fet realment

L’últim pas és confirmar l’aplicació concreta, no la màquina en general. Resol la destinació, mira la ruta per a aquesta adreça i després observa la connexió mentre és oberta:

getent hosts example.com
ip route get "$(getent hosts example.com | awk '{print $1; exit}')"
ss -tnp state established '( dport = :443 )'

Si la ruta anomena el túnel però la llista de sockets mostra una connexió amb una adreça d’origen de la interfície física, l’aplicació està lligada a alguna cosa concreta, o un segon túnel competeix per la ruta per defecte. Això és una qüestió d’encaminament, i es pot respondre amb aquestes tres sortides en lloc de la pantalla d’estat del client.

L’arquitectura de seguretat RFC 4301 descriu la versió de capa IP d’aquest embolcall per a IPsec, i la mateixa lògica de capes s’aplica a WireGuard i OpenVPN. Un cop pots assenyalar el paquet interior i el paquet exterior com a objectes separats, la majoria del comportament del túnel deixa de ser misteriós i es converteix en una taula d’encaminament que pots llegir.