O cliente di conectado, o cadeado está pechado e, aínda así, un sitio rexistra a dirección do teu piso. Nada fallou. Un túnel non substitúe o teu Wi-Fi nin a túa conexión móbil; coloca un segundo sobre arredor de determinados paquetes e envía ese sobre pola rede que xa tiñas. Entender o truco consiste sobre todo en seguir unha solicitude e fixarse en onde se abre o sobre, porque case todos os síntomas confusos, desde unha dirección de casa que se filtra ata unha gran descarga atascada, veñen desa fronteira.

Dous sobres, unha ligazón física

O teu portátil mantén a súa conexión normal co router, e o router mantén a súa conexión normal co provedor. Nada dese camiño cambia cando se levanta un túnel. O que cambia é que determinados paquetes se entregan a unha interface virtual, se envolven dentro dun paquete novo dirixido ao par de VPN e se envía como tráfico ordinario pola ligazón física.

O extremo receptor é un dispositivo que desembrulha o sobre e reenvía o paquete orixinal cara ao seu destino. Entre os dous extremos, un observador ve a cabeceira exterior e nada da interior, salvo que o protocolo a cifre, cousa que fan a maioría dos protocolos de consumo e que a técnica xeral non esixe.

Por iso a interface virtual é á vez real e enganosa. Existe como obxecto do núcleo cunha dirección e unha unidade máxima de transmisión, e o sistema operativo encamiña o tráfico cara a ela como cara a calquera outra interface. Non é un cable, e a súa existencia só demostra que hai un compoñente instalado. Se o teu navegador a usa decídeno as rutas, non que a interface estea levantada.

Observa unha solicitude de viaxe

Escolle un destino e pregúntalle ao núcleo que interface usará. Esta única orde resolve a maioría das discusións sobre se o túnel fai algo:

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

Se a saída da ruta nomea a interface do túnel, o paquete envolverase. Se nomea a interface física, non se envolverá, e ningún reinicio do cliente cambia iso. A segunda orde mostra ambas as interfaces unha xunto á outra, e así é como detectas un túnel que se levantou sen dirección ou cunha dirección da familia equivocada.

Despois mira o primeiro salto desde dentro do sobre e compárao co primeiro salto desde fóra:

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

Dentro do túnel o primeiro salto é a dirección interior do par, non o teu router. A captura na interface do túnel mostra os paquetes interiores, que é o tráfico que a aplicación cre que envía. Capturar á vez na interface física mostra os paquetes exteriores, e as dúas cousas xuntas son a demostración máis clara do que fai realmente un túnel.

Tres direccións, e o sitio só ve unha

A xente confúndeas constantemente, e a confusión xera informes de fuga falsos. Son campos distintos en cabeceiras distintas con vidas distintas.

AddressWhere it appearsWho can see it
Endpoint addressOuter header, the peer you connect toYour access network and the path to it
Inner tunnel addressInside the envelope, on the virtual interfaceThe peer, and anything the peer routes to
Exit addressSource of the packet that reaches the websiteThe website and its upstream

O número xunto ao adaptador virtual é a segunda fila. Non é a dirección que rexistra un sitio, e citarlo como a túa IP pública é simplemente un erro. A dirección que ve un sitio asígnaa a saída, e nun túnel de rede privada pode non haber ningunha saída pública, porque o destino vive dentro da organización e non en internet.

Un túnel entre sedes é o mesmo mecanismo con outros extremos. Dous routers envolven tráfico entre redes, e ningún dispositivo individual ten un cliente instalado. O sobre é idéntico en principio, e a fronteira administrativa non.

Onde se abre o sobre e que sobrevive a el

O túnel remata no seu par. Se o cifrado propio da aplicación chega máis lonxe, sobrevive a esa fronteira, que é o caso normal de HTTPS: a sesión do navegador remata no sitio, así que a saída reenvía texto cifrado que non pode ler.

Nada máis sobrevive por defecto. Unha solicitude sen cifrar é lexible na saída exactamente como o era na Wi-Fi do café, e o túnel non engade unha protección que a aplicación nunca tivo. Do mesmo xeito, as regras de devasas e a política de reenvío da saída deciden que ocorre despois; un aperto de mans correcto é un feito sobre a conexión co par, non sobre o resto da viaxe.

A sobrecarga é a outra consecuencia visible. Cada paquete leva unha cabeceira extra, e o transporte exterior pode engadir a súa, así que a carga útil por paquete redúcese. Nun camiño cunha unidade máxima de transmisión fixa, é exactamente por iso polo que un túnel pode pasar un ping e atascar unha carga grande.

Comproba o camiño que a aplicación tomou de verdade

O último paso é confirmar a aplicación concreta, non a máquina en xeral. Resolve o destino, mira a ruta para esa dirección e logo observa a conexión mentres está aberta:

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

Se a ruta nomea o túnel pero a lista de sockets mostra unha conexión cunha dirección de orixe da interface física, a aplicación está ligada a algo concreto, ou un segundo túnel compite pola ruta por defecto. É unha cuestión de encamiñamento, e pódese responder con estas tres saídas en lugar da pantalla de estado do cliente.

A arquitectura de seguridade RFC 4301 describe a versión de capa IP deste envolvemento para IPsec, e a mesma lóxica de capas aplícase a WireGuard e OpenVPN. Unha vez que podes sinalar o paquete interior e o paquete exterior como obxectos separados, a maior parte do comportamento do túnel deixa de ser misterioso e convértese nunha táboa de encamiñamento que podes ler.

Artigos relacionados