O tráfico pasa realmente pola VPN? Como verificalo

Dous fallos vense idénticos desde a icona da bandexa: o tráfico que entra no túnel e o tráfico que o rodea en silencio. O cliente mostra Connected en ambos os casos, porque Connected só significa que a interface do túnel existe e que o cliente instalou as rutas que quería. Se un paquete dunha aplicación usou esas rutas é unha pregunta aparte, que se responde noutro punto da pila. Catro medicións resolven a maior parte — a consulta de ruta, o primeiro salto, unha captura no adaptador físico e unha observación desde fóra — e a vista de sesión do servidor cobre o resto.

Comece pola ruta que tomará o paquete

A táboa de encamiñamento é a decisión, así que pregúntelle por un destino en lugar de lela enteira e adiviñar. En Linux, ip route get nomea a interface e o enderezo de orixe que escolleu o núcleo:

ip route get 203.0.113.10
ip route get 10.20.5.7

En Windows, Find-NetRoute -RemoteIPAddress 203.0.113.10 é máis útil que route print -4 polo mesmo motivo: informa da ruta que gañou, non de todas as rutas que existen. Aínda así, lea a táboa unha vez pola súa fila 0.0.0.0. Un par /1 alí significa que un cliente de túnel completo reescribiu a ruta predeterminada: a opción redirect-gateway def1 de OpenVPN instala 0.0.0.0/1 e 128.0.0.0/1 polo túnel, o que gaña á 0.0.0.0/0 existente pola coincidencia de prefixo máis longa sen borrar a ruta predeterminada física. Por iso dúas rutas predeterminadas poden convivir mentres todo segue entrando no túnel.

Dous detalles fan que a táboa mente. Primeiro, mire o prefixo que coincidiu e non o número de rutas predeterminadas, porque a métrica da interface ou un par /1 deciden o gañador. Segundo, unha conexión que xa existe conserva o camiño co que se estableceu; tras levantar o túnel, unha sesión aberta pode seguir usando a ruta antiga ata que se reinicie, e por iso reconectar parece arranxar un problema de encamiñamento. Un cliente en execución — ps ax | grep openvpn — só demostra que o proceso arrincou.

Rastree un nome interno e un nome público

A consulta de ruta mostra a intención; o camiño mostra a entrega. Rastree un nome que debe ser interno e un que non debe selo, mentres está conectado, e compare o primeiro salto:

traceroute intranet.corp.example
traceroute 1.1.1.1

O mesmo primeiro salto para ambos significa que o nome interno nunca entrou no túnel e que o fallo está por riba, normalmente un nome que resolve a un enderezo público ou unha ruta que nunca se instalou. Se o tráfico interno sae por 10.8.0.1 mentres o público sae por 192.168.1.1, o túnel dividido fai exactamente aquilo para o que se configurou. Un trazado que chega á pasarela da VPN e despois só devolve tempos de espera adoita ser un problema de camiño de volta ou da devasa do servidor, non unha ruta de reenvío ausente.

O ICMP filtrado fai que esta comprobación menta: estrelas en ambos os trazados parecen un túnel morto e normalmente son unha devasa. Probe un porto TCP onde poida — traceroute -T -p 443 en Linux — e lembre que o trazado non di que resolutor respondeu: un nome pode resolverse localmente e seguir sendo alcanzable polo túnel.

Capture no adaptador físico, non no túnel

A ligazón física é o único lugar que mostra o que ve realmente a rede. Co túnel levantado, unha sesión á oficina debería aparecer como carga cifrada dirixida ao servidor VPN, non como unha conexión a 10.20.5.7:

sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5

O primeiro filtro captura a resolución de nomes que sae localmente, que é a fuga máis común e a máis silenciosa — a páxina segue cargando, o resolutor só viu a consulta. O segundo captura tráfico simple cara a un enderezo interno que só debería existir dentro do túnel. En Windows, pktmon fai o mesmo traballo sen controlador: pktmon filter add -p 53, despois pktmon start --capture --pkt-size 128, despois pktmon stop e pktmon format pktmon.etl -o capture.txt. Eses indicadores varían un pouco entre versións de Windows, así que comprobe pktmon filter add /? antes de confiar na sintaxe.

Capture a interface física para atopar fugas; unha captura no túnel contén os paquetes que xa cre que están alí, e nun servidor contén paquetes externos ilexibles cuxa orixe é a pasarela. Os contadores de bytes de calquera interface describen paquetes, non programas; atribuír tráfico a un proceso require un monitor que asocie sockets con procesos.

Pregunte a un servizo externo e volva preguntar por aplicación

A única comprobación que demostra a saída é unha resposta desde fóra: un servizo que devolve o enderezo de orixe que viu. Execúteo desde unha consola, onde pode escoller a interface, e execúteo dúas veces:

sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ip

Respostas distintas danlle proba de ambos os camiños e unha forma de probar unha aplicación concreta: vincúlea, ou execútea nun espazo de nomes de rede cunha soa ruta, e vexa que enderezo rexistra o extremo remoto. Respostas idénticas son o fallo interesante: ou a vinculación non surtiu efecto, ou algo entre o equipo e o extremo remoto reescribe o enderezo de orixe antes de que chegue. En Windows, curl --interface quere o enderezo do adaptador e non o seu nome.

Un navegador que informa do enderezo da VPN demostra o navegador. Un cliente de correo, un xestor de paquetes, un axente de copias de seguridade ou un segundo perfil de navegador poden tomar cada un un camiño distinto, sobre todo cando un axuste de proxy ou unha ruta de túnel dividido cobre un deles. Un cambio de enderezo non é proba de fuga por si mesmo: un balanceador pode responder distinto segundo a saída que viu, así que compare o enderezo de orixe rexistrado, non a páxina.

Use a vista do servidor para confirmar o par

O servidor responde a outra pregunta: se un par está conectado, canto transportou e se a sesión se reiniciou. Un par activo no servidor mentres os contadores do cliente apenas se moven significa que o tráfico da aplicación non entra no túnel, diga o que diga a táboa do cliente. Un par que move moitos datos para un usuario que informa de que nada funciona é outra investigación.

Aquí hai dúas trampas. Un túnel enmascarado fai que cada fluxo pareza vir da pasarela, así que os rexistros e a contabilidade por cliente colapsan nun só enderezo. E o cliente trátase como un equipo local, así que a pregunta sobre se alguén copia ficheiros pola VPN respóndese co tráfico de compartición de ficheiros no servidor ou coa auditoría do equipo no servidor — vixiar o túnel dá extremos e volume, non nomes de ficheiro.

Distinga unha decisión de deseño dunha fuga

Non todo o que está fóra do túnel é unha fuga. O tráfico de ligazón local e de difusión queda local por deseño, unha impresora descuberta por multicast segue anunciándose na LAN, e DHCP ten que saír localmente. Unha aplicación vinculada a unha interface concreta evita a táboa de encamiñamento a propósito, e só unha regra de devasa, un espazo de nomes ou unha ruta de política o cambian.

IPv6 merece a súa propia liña na lista de comprobación. Un túnel que só transporta IPv4 deixa un equipo de dobre pila cun segundo camiño utilizable, e un destino de dobre pila preferirao — incluído DNS, se o resolutor é alcanzable por IPv6. Desactive IPv6 no adaptador ou confirme que o túnel o transporta antes de considerar completo un resultado IPv4.

Cando as comprobacións non coinciden, a discrepancia adoita sinalar o fallo:

Unha orde que funciona: garde a táboa de encamiñamento antes e despois de conectar, rastree un nome interno e un público, capture DNS no adaptador físico, devolva o enderezo de saída desde a consola para a aplicación concreta e despois lea o servidor polo volume. Se as catro primeiras coinciden, o túnel transporta o que vostede cre e o problema restante está por riba. Se dúas delas non coinciden, o par que discrepa é o fallo, non a icona.