Que é un túnel VPN e onde remata a protección
Un túnel envolve paquetes seleccionados nun segundo sobre por riba da ligazón que xa tiñas. Segue unha solicitude e descobre que dirección rexistra realmente un sitio.
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.
| Address | Where it appears | Who can see it |
|---|---|---|
| Endpoint address | Outer header, the peer you connect to | Your access network and the path to it |
| Inner tunnel address | Inside the envelope, on the virtual interface | The peer, and anything the peer routes to |
| Exit address | Source of the packet that reaches the website | The 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.