Interfața utun a VPN-ului pe Mac este activă, dar traficul eșuează? Verifică ifconfig

Ai conectat VPN-ul, ai rulat ifconfig și ai găsit o intrare utun4 cu o adresă pe ea. Site-ul de care aveai nevoie încă expiră. Acest gol este normal: listarea dovedește că există o interfață virtuală, nu că o deține clientul tău, că ruta care te interesează o alege sau că pachetele o traversează. Am încetat să mai am încredere în numele interfeței după o după-amiază petrecută dând vina pe tunelul greșit pe un laptop care avea deja trei intrări utun înainte să instalez ceva.

Ce conține de fapt o linie utun

Rulează ifconfig -a când vrei imaginea completă. Apelat fără argumente, ifconfig afișează doar interfețele care sunt active acum, motiv pentru care un tunel care nu a pornit poate lipsi din ieșirea pe care oamenii o lipesc în tichete. ifconfig -l returnează doar numele, iar acesta este cel mai rapid mod de a afla dacă a apărut un utun nou după conectare.

Citirea unei singure interfețe este locul unde stă detaliul util, iar un tunel conectat arată de obicei așa.

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

Trei câmpuri poartă răspunsul. UP și RUNNING spun că nucleul este dispus să folosească interfața. POINTOPOINT plus --> adresa perechii este semnătura unui tunel și nu a unei legături fizice. mtu valoarea explică o întreagă clasă de rapoarte „se conectează, apoi se blochează”, pentru că interfețele utun pornesc de obicei cu un MTU redus, 1380 în mai multe build-uri macOS, iar clientul îl poate suprascrie. Lista de câmpuri este destul de scurtă pentru a o parcurge o dată în manualul ifconfig pe care Apple îl livrează.

Găsește procesul din spatele interfeței

ifconfig nu are noțiunea de aplicație proprietară. Doi clienți VPN, un serviciu de sistem și un tunel rămas de săptămâna trecută produc intrări care arată identic la acest nivel. Pe Mac-ul meu, utun0 până la utun3 existau înainte să configurez ceva; Continuity și iCloud Private Relay folosesc și ele tuneluri, iar niciunul dintre ele nu este conexiunea pe care o diagnostichezi.

Pentru tunelurile care înregistrează o configurație la sistem, scutil --nc list este cea mai rapidă corelație, afișează fiecare configurație cu starea și ID-ul serviciului, iar una conectată este marcată ca atare.

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

Clienții care rulează propriul proces de tunel în loc să înregistreze o configurație nu apar niciodată acolo. Tunnelblick și o instanță openvpn din linia de comandă fac parte din acel grup, așa că verifică și tabelul de procese: ps -Ao pid,comm | grep -i openvpn. Odată ce un proces deține tunelul, numărul utun aparține acelui proces și nimic altceva.

Testează adresa înainte de rută

O interfață poate fi activă fără o adresă utilizabilă. Un profil doar IPv6 arată o intrare fe80:: link-local și nimic pe linia inet, iar un client care nu a reușit să aplice o adresă împinsă lasă exact aceeași formă. Dacă destinația ta este IPv4 și tunelul nu are adresă IPv4, întrebarea de rutare este deja rezolvată.

MTU merită o verificare separată, pentru că eșecul nu arată ca o problemă de dimensiune. Arată ca o conexiune care se autentifică și apoi tace de îndată ce începe un transfer mare. Trimite o sondă care nu trebuie fragmentată, dimensionată astfel încât pachetul să se potrivească cu MTU-ul interfeței; pentru un MTU de 1400, payload-ul este de 1372 bytes:

ping -D -s 1372 10.8.0.5

Un răspuns înseamnă că pachete de acea dimensiune traversează tunelul. Liniștea în timp ce ping-urile mici reușesc indică MTU-ul sau ceva care aruncă ICMP pe traseu, nu autentificarea, care era deja încheiată înainte să ai măcar o interfață.

Dovedește că destinația alege tunelul

Întrebarea care contează nu este dacă utun4 există, ci dacă traficul către o adresă anume iese prin ea. route -n get răspunde la asta pentru o singură destinație și afișează gateway-ul și interfața pe care le-ar folosi:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Dacă aceeași comandă raportează en0, configurația ta split tunneling face ce i s-a spus și nicio inspecție a interfeței nu va schimba asta. Folosește netstat -rn -f inet când ai nevoie de ruta implicită și de tot tabelul într-o singură vedere.

Contoarele decid dacă pachetele chiar se mișcă. netstat -ib raportează totaluri de pachete și bytes pe interfață, inclusiv intrările utun; numerele sunt cumulative, așa că citește-le de două ori cu o pauză și compară:

netstat -ib | grep utun4

Contoare înghețate în timp ce aplicația tot reîncearcă înseamnă că nucleul nu a predat niciodată un pachet interfeței. Contoare care urcă în ambele direcții în timp ce aplicația încă eșuează mută investigația la celălalt capăt al tunelului.

Când nu apare niciun utun

O listă de interfețe goală după o autentificare care a părut reușită înseamnă de obicei că tunelul nu a pornit niciodată, nu că ifconfig îl ascunde. Verifică starea clientului, apoi a sistemului: o Network Extension care nu a fost niciodată aprobată, sau pe care macOS a dezactivat-o după o actualizare, nu lasă nicio interfață. Aprobarea se află în System Settings la Login Items & Extensions, iar o intrare veche de acolo merită re-comutată înainte să reinstalezi ceva.

Numerotarea utun nu este stabilă între reconectări. Poți obține utun5 acolo unde utun4 exista acum zece minute, pentru că interfața veche este desființată și nucleul oferă următorul index liber. Scripturile care codifică dur un nume se strică silențios în acel moment; potrivește pe adresă sau pe rută în schimb.

Ține partea de citire doar-citire. sudo ifconfig utun4 down întrerupe tunelul, iar pe un profil de tunel complet ia cu el și sesiunea ta la distanță, ceea ce este un schimb prost când doar încercai să aduni dovezi. Nimic din ce ai nevoie aici nu cere root: citirea flag-urilor, adreselor și contoarelor funcționează cu utilizatorul tău normal.

Fă verificările în ordine data viitoare când un tunel pe Mac se poartă prost: confirmă că a apărut un utun cu ifconfig -l, citește-i flag-urile, adresele și MTU-ul, atribuie-l unui proces, întreabă route -n get ce interfață folosește destinația, apoi urmărește netstat -ib mișcându-se. Fiecare pas elimină alt strat, iar primul care revine greșit este locul unde trebuie aplicată corecția.