A interface utun da VPN do Mac está activa pero o tráfico falla? Comproba ifconfig

ifconfig mostra un nome utun, un enderezo e a MTU, pero non que aplicación o posúe nin a onde van os paquetes. Cinco comprobacións só de lectura que responden á pregunta real.

Conectaches a VPN, executaches ifconfig e atopaches unha entrada utun4 cun enderezo enriba. O sitio que necesitabas segue sen responder. Esa fenda é normal: a listaxe demostra que existe unha interface virtual, non que a posúa o teu cliente, que a ruta que te importa a seleccione ou que os paquetes a atravesen. Deixei de confiar no nome da interface despois de pasar unha tarde culpando ao túnel equivocado nun portátil que xa tiña tres entradas utun antes de instalar nada.

Que contén realmente unha liña utun

Executa ifconfig -a cando queiras a imaxe completa. Chamado sen argumentos, ifconfig só imprime as interfaces que están activas nese momento, e por iso un túnel que non arrincou pode faltar na saída que a xente pega nos tíckets. ifconfig -l devolve só os nomes, e esa é a forma máis rápida de saber se apareceu un utun novo despois de conectarte.

Ler unha soa interface é onde vive o detalle útil. Un túnel conectado adoita verse así:

utun4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
    inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff
    inet6 fe80::ce81:b1c:bd2c:69e%utun4 prefixlen 64 scopeid 0x15

Tres campos levan a resposta. UP e RUNNING din que o núcleo está disposto a usar a interface. POINTOPOINT máis o enderezo do par --> é a sinatura dun túnel e non dun enlace físico. O valor mtu explica toda unha clase de informes de «conecta e logo atasca», porque as interfaces utun adoitan levantarse cunha MTU reducida, 1380 en varias compilacións de macOS, e o cliente pode sobrescribila. A lista de campos é o bastante curta para follala unha vez no manual de ifconfig que distribúe Apple.

Atopa o proceso detrás da interface

ifconfig non ten ningún concepto de aplicación propietaria. Dous clientes de VPN, un servizo do sistema e un túnel sobrante da semana pasada producen entradas que a este nivel parecen idénticas. No meu propio Mac, utun0 ata utun3 existían antes de que configurase nada; Continuity e iCloud Private Relay tamén usan túneles, e ningún deles é a conexión que estás diagnosticando.

Para os túneles que rexistran unha configuración no sistema, scutil --nc list é a correlación máis rápida. Imprime cada configuración co seu estado e o seu ID de servizo, e a conectada márcase así:

scutil --nc list
* (Connected)   5F2A9C10-...   VPN  Work IKEv2

Os clientes que executan o seu propio proceso de túnel en lugar de rexistrar unha configuración nunca aparecen aí. Tunnelblick e unha instancia de openvpn desde a liña de ordes caen nese grupo, así que revisa tamén a táboa de procesos: ps -Ao pid,comm | grep -i openvpn. Unha vez que un proceso posúe o túnel, o número utun pertence a ese proceso e a ninguén máis.

Proba o enderezo antes de probar a ruta

Unha interface pode estar activa sen un enderezo utilizábel. Un perfil só IPv6 mostra unha entrada fe80:: local de enlace e nada na liña inet, e un cliente que non logrou aplicar un enderezo empurrado deixa exactamente a mesma forma. Se o teu destino é IPv4 e o túnel non ten enderezo IPv4, a cuestión do encamiñamento xa está resolta.

A MTU merece unha comprobación á parte, porque o fallo non parece un problema de tamaño. Parece unha conexión que se autentica e logo queda en silencio en canto comeza unha transferencia grande. Envía unha sonda que non deba fragmentarse, dimensionada para que o paquete encaixe coa MTU da interface; para unha MTU de 1400 a carga útil é de 1372 bytes:

ping -D -s 1372 10.8.0.5

Unha resposta significa que os paquetes dese tamaño atravesan o túnel. O silencio mentres os pings pequenos funcionan apunta á MTU ou a algo que descarta ICMP polo camiño, non á autenticación, que xa rematara antes de que tiveses unha interface.

Demostra que o destino escolle o túnel

A pregunta importante non é se existe utun4, senón se o tráfico cara a un enderezo concreto sae por el. route -n get responde a iso para un só destino e imprime a pasarela e a interface que usaría:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Se a mesma orde informa de en0, a túa configuración de túnel dividido fai o que se lle dixo e ningunha cantidade de inspección de interfaces o cambiará. Usa netstat -rn -f inet cando necesites a ruta predeterminada e toda a táboa nunha soa vista.

Os contadores deciden se os paquetes se moven de verdade. netstat -ib informa dos totais de paquetes e bytes por interface, entradas utun incluídas; os números son acumulativos, así que leos dúas veces cun intervalo e compara:

netstat -ib | grep utun4

Contadores conxelados mentres a aplicación segue reintentando significan que o núcleo nunca entregou un paquete á interface. Contadores que soben en ambas as dúas direccións mentres a aplicación aínda falla trasladan a investigación ao extremo oposto do túnel.

Cando non aparece ningún utun

Unha lista de interfaces baleira tras un inicio de sesión que parecía correcto adoita significar que o túnel nunca arrincou, non que ifconfig o esconda. Revisa o estado do propio cliente e despois o do sistema: unha extensión de rede que nunca se aprobou, ou que macOS desactivou tras unha actualización, non deixa ningunha interface atrás. A aprobación vive nos Axustes do Sistema, en Login Items & Extensions, e unha entrada obsoleta alí merece volver conmutarse antes de reinstalar nada.

A numeración utun non é estábel entre reconexións. Podes obter utun5 onde hai dez minutos existía utun4, porque a interface antiga desmóntase e o núcleo entrega o seguinte índice libre. Os scripts que fixan un nome en duro rompen en silencio nese momento; mellor compara polo enderezo ou pola ruta.

Mantén o lado de lectura como só lectura. sudo ifconfig utun4 down interrompe o túnel, e nun perfil de túnel completo leva consigo a túa sesión remota, o que é un mal intercambio cando só intentabas reunir probas. Nada do que necesitas aquí require root: ler indicadores, enderezos e contadores funciona co teu usuario normal.

Percorre as comprobacións en orde a próxima vez que un túnel de Mac se comporte mal: confirma que apareceu un utun con ifconfig -l, le os seus indicadores, enderezos e MTU, atribúeo a un proceso, pregunta a route -n get que interface usa o destino e despois observa como se move netstat -ib. Cada paso descarta unha capa distinta, e o primeiro que saia mal é onde vai a solución.

Artigos relacionados