La interfície utun de la VPN del Mac està activa però el trànsit falla? Comprova ifconfig

Vas connectar la VPN, vas executar ifconfig i vas trobar una entrada utun4 amb una adreça a sobre. El lloc que necessitaves continua sense respondre. Aquest buit és normal: el llistat demostra que existeix una interfície virtual, no que el teu client la posseeixi, que la ruta que t'interessa la triï o que els paquets la travessin. Vaig deixar de confiar en el nom de la interfície després d'una tarda passada culpant el túnel equivocat en un portàtil que ja tenia tres entrades utun abans que hi instal·lés res.

Què conté realment una línia utun

Executa ifconfig -a quan vulguis la imatge completa. Cridat sense arguments, ifconfig només imprimeix les interfícies que estan actives ara mateix, i per això un túnel que no s'ha iniciat pot faltar de la sortida que la gent enganxa als tiquets. ifconfig -l retorna només els noms, i aquesta és la manera més ràpida de saber si ha aparegut un utun nou després de connectar-te.

Llegir una sola interfície és on viu el detall útil. Un túnel connectat normalment té aquest aspecte:

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 camps porten la resposta. UP i RUNNING diuen que el nucli està disposat a fer servir la interfície. POINTOPOINT més l'adreça de l'extrem --> és la signatura d'un túnel i no d'un enllaç físic. El valor mtu explica tota una classe d'informes de «es connecta i s'atura», perquè les interfícies utun solen aixecar-se amb un MTU reduït, 1380 en diverses compilacions de macOS, i el client pot sobreescriure'l. La llista de camps és prou curta per fullejar-la una vegada al manual d'ifconfig que distribueix Apple.

Troba el procés que hi ha darrere la interfície

ifconfig no té cap concepte d'aplicació propietària. Dos clients de VPN, un servei del sistema i un túnel sobrant de la setmana passada produeixen entrades que en aquest nivell semblen idèntiques. Al meu Mac, utun0 fins a utun3 existien abans que configurés res; Continuity i iCloud Private Relay també fan servir túnels, i cap d'ells no és la connexió que estàs diagnosticant.

Per als túnels que registren una configuració al sistema, scutil --nc list és la correlació més ràpida. Imprimeix cada configuració amb el seu estat i l'ID de servei, i la connectada es marca així:

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

Els clients que executen el seu propi procés de túnel en lloc de registrar una configuració no hi apareixen mai. Tunnelblick i una instància d'openvpn de línia d'ordres cauen en aquest grup, així que revisa també la taula de processos: ps -Ao pid,comm | grep -i openvpn. Un cop un procés posseeix el túnel, el número utun pertany a aquest procés i a cap altre.

Prova l'adreça abans de provar la ruta

Una interfície pot estar activa sense cap adreça utilitzable. Un perfil només IPv6 mostra una entrada fe80:: local d'enllaç i res a la línia inet, i un client que no ha pogut aplicar una adreça empenyuda deixa exactament la mateixa forma. Si la teva destinació és IPv4 i el túnel no té cap adreça IPv4, la qüestió de l'encaminament ja està resolta.

L'MTU mereix una comprovació a part, perquè la fallada no sembla un problema de mida. Sembla una connexió que s'autentica i després queda en silenci així que comença una transferència gran. Envia una sonda que no s'hagi de fragmentar, dimensionada perquè el paquet encaixi amb l'MTU de la interfície; per a un MTU de 1400 la càrrega útil és de 1372 octets:

ping -D -s 1372 10.8.0.5

Una resposta vol dir que els paquets d'aquesta mida travessen el túnel. El silenci mentre els pings petits funcionen apunta a l'MTU o a alguna cosa que descarta ICMP pel camí, no a l'autenticació, que ja s'havia completat abans que tinguessis cap interfície.

Demostra que la destinació tria el túnel

La pregunta que importa no és si existeix utun4, sinó si el trànsit cap a una adreça concreta en surt. route -n get ho respon per a una sola destinació i imprimeix la porta d'enllaç i la interfície que faria servir:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Si la mateixa ordre informa d'en0, la teva configuració de túnel dividit fa el que se li ha dit i cap quantitat d'inspecció d'interfícies ho canviarà. Fes servir netstat -rn -f inet quan necessitis la ruta per defecte i tota la taula en una sola vista.

Els comptadors decideixen si els paquets es mouen de debò. netstat -ib informa dels totals de paquets i octets per interfície, entrades utun incloses; els números són acumulatius, així que llegeix-los dos cops amb un interval i compara:

netstat -ib | grep utun4

Comptadors congelats mentre l'aplicació continua reintentant volen dir que el nucli mai no ha lliurat cap paquet a la interfície. Comptadors que pugen en totes dues direccions mentre l'aplicació encara falla mouen la investigació a l'extrem oposat del túnel.

Quan no apareix cap utun

Una llista d'interfícies buida després d'un inici de sessió que semblava correcte normalment vol dir que el túnel no s'ha iniciat mai, no que ifconfig l'amagui. Comprova l'estat del client i després el del sistema: una extensió de xarxa que mai no s'ha aprovat, o que macOS ha desactivat després d'una actualització, no deixa cap interfície darrere. L'aprovació és als Ajustos del Sistema, a Login Items & Extensions, i val la pena tornar a commutar una entrada obsoleta d'allà abans de reinstal·lar res.

La numeració utun no és estable entre reconnexions. Pots obtenir utun5 on fa deu minuts hi havia utun4, perquè la interfície antiga es desmunta i el nucli lliura el següent índex lliure. Els scripts que fixen un nom al codi es trenquen en silenci en aquell moment; fes servir l'adreça o la ruta com a referència.

Mantén el costat de lectura només de lectura. sudo ifconfig utun4 down interromp el túnel, i en un perfil de túnel complet s'emporta la teva sessió remota, cosa que és un mal intercanvi quan només volies reunir proves. Res del que necessites aquí no requereix root: llegir indicadors, adreces i comptadors funciona com a usuari normal.

La propera vegada que un túnel del Mac es porti malament, fes les comprovacions en ordre: confirma que ha aparegut un utun amb ifconfig -l, llegeix-ne els indicadors, les adreces i l'MTU, atribueix-lo a un procés, pregunta a route -n get quina interfície fa servir la destinació i després mira com es mou netstat -ib. Cada pas descarta una capa diferent, i el primer que surti malament és on va la solució.