utun-grænsefladen i Mac VPN er oppe, men trafikken fejler? Se ifconfig

Du koblede VPN'et til, kørte ifconfig og fandt en utun4-post med en adresse på. Siden, du havde brug for, svarer stadig ikke. Det hul er normalt: listen beviser, at en virtuel grænseflade findes, ikke at din klient ejer den, at den rute, du bekymrer dig om, vælger den, eller at pakker krydser den. Jeg holdt op med at stole på grænsefladenavnet efter en eftermiddag brugt på at bebrejde den forkerte tunnel på en bærbar, der allerede havde tre utun-poster, før jeg installerede noget.

Hvad en utun-linje egentlig indeholder

Kør ifconfig -a, når du vil have hele billedet. Kaldt uden argumenter udskriver ifconfig kun grænseflader, der er oppe lige nu, og derfor kan en tunnel, der ikke startede, mangle i det output, folk indsætter i sager. ifconfig -l returnerer kun navnene, og det er den hurtigste måde at se, om en ny utun dukkede op, efter du koblede til.

Det er ved at læse én grænseflade, at de nyttige detaljer bor. En tilsluttet tunnel ser typisk sådan ud:

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

Tre felter bærer svaret. UP og RUNNING siger, at kernen er villig til at bruge grænsefladen. POINTOPOINT plus modpartens adresse --> er signaturen på en tunnel frem for et fysisk link. Værdien mtu forklarer en hel klasse af rapporter om «forbinder, så går i stå», fordi utun-grænseflader normalt kommer op med en reduceret MTU, 1380 i flere macOS-builds, og klienten kan tilsidesætte den. Feltlisten er kort nok til at skimme én gang i ifconfig-manualen, som Apple leverer.

Find processen bag grænsefladen

ifconfig har ingen forestilling om en ejerapplikation. To VPN-klienter, en systemtjeneste og en resttunnel fra sidste uge producerer alle poster, der ser identiske ud på dette niveau. På min egen Mac fandtes utun0 til utun3, før jeg konfigurerede noget; Continuity og iCloud Private Relay bruger også tunneller, og ingen af dem er den forbindelse, du fejlfinder.

For tunneller, der registrerer en konfiguration i systemet, er scutil --nc list den hurtigste sammenkobling. Den udskriver hver konfiguration med status og tjeneste-ID, og en tilsluttet markeres som sådan:

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

Klienter, der kører deres egen tunnelproces i stedet for at registrere en konfiguration, dukker aldrig op der. Tunnelblick og en openvpn-instans fra kommandolinjen hører til den gruppe, så tjek også procestabellen: ps -Ao pid,comm | grep -i openvpn. Når først en proces ejer tunnellen, tilhører utun-nummeret den proces og ikke noget andet.

Test adressen, før du tester ruten

En grænseflade kan være oppe uden en brugbar adresse. En profil med kun IPv6 viser en link-local fe80::-post og intet i inet-linjen, og en klient, der ikke kunne anvende en skubbet adresse, efterlader præcis samme form. Hvis din destination er IPv4, og tunnellen ikke har nogen IPv4-adresse, er routing-spørgsmålet allerede afgjort.

MTU fortjener et særskilt tjek, fordi fejlen ikke ligner et størrelsesproblem. Den ligner en forbindelse, der godkender og derefter bliver tavs, så snart en stor overførsel starter. Send en sonde, der ikke må fragmenteres, dimensioneret så pakken passer til grænsefladens MTU; ved en MTU på 1400 er nyttelasten 1372 byte:

ping -D -s 1372 10.8.0.5

Et svar betyder, at pakker af den størrelse passerer tunnellen. Tavshed, mens små ping lykkes, peger på MTU eller på noget, der dropper ICMP på vejen, ikke på godkendelsen, som allerede var færdig, før du overhovedet fik en grænseflade.

Bevis, at destinationen vælger tunnellen

Det afgørende spørgsmål er ikke, om utun4 findes, men om trafik til én bestemt adresse forlader gennem den. route -n get svarer på det for en enkelt destination og udskriver gatewayen og den grænseflade, den ville bruge:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Hvis samme kommando rapporterer en0, gør din split-tunnel-konfiguration, hvad den fik besked på, og ingen mængde grænsefladeinspektion ændrer det. Brug netstat -rn -f inet, når du har brug for standardruten og hele tabellen i ét overblik.

Tællere afgør, om pakkerne faktisk flytter sig. netstat -ib rapporterer pakke- og bytetotaler for hver grænseflade, utun-poster inkluderet; tallene er kumulative, så læs dem to gange med en pause og sammenlign:

netstat -ib | grep utun4

Frosne tællere, mens applikationen bliver ved med at prøve igen, betyder, at kernen aldrig overdrog en pakke til grænsefladen. Tællere, der stiger i begge retninger, mens applikationen stadig fejler, flytter undersøgelsen til den anden ende af tunnellen.

Når ingen utun dukker op

En tom grænsefladeliste efter et login, der så ud til at lykkes, betyder normalt, at tunnellen aldrig startede, ikke at ifconfig skjuler den. Tjek klientens egen status, derefter systemets: en netværksudvidelse, der aldrig blev godkendt, eller som macOS deaktiverede efter en opdatering, efterlader ingen grænseflade. Godkendelsen ligger i Systemindstillinger under Login Items & Extensions, og en forældet post der er værd at slå til og fra igen, før du geninstallerer noget.

utun-nummerering er ikke stabil mellem genforbindelser. Du kan få utun5, hvor utun4 fandtes for ti minutter siden, fordi den gamle grænseflade rives ned, og kernen uddeler det næste ledige indeks. Scripts, der hardcoder et navn, brækker stille på det tidspunkt; match i stedet på adressen eller på ruten.

Hold læsesiden skrivebeskyttet. sudo ifconfig utun4 down afbryder tunnellen, og på en full-tunnel-profil tager den din fjernsession med sig, hvilket er en dårlig handel, når du kun forsøgte at samle beviser. Intet af det, du har brug for her, kræver root: at læse flag, adresser og tællere fungerer som din normale bruger.

Kør tjekkene i rækkefølge næste gang en Mac-tunnel driller: bekræft, at en utun dukkede op med ifconfig -l, læs dens flag, adresser og MTU, henfør den til en proces, spørg route -n get hvilken grænseflade destinationen bruger, og se så netstat -ib bevæge sig. Hvert trin udelukker et forskelligt lag, og det første, der kommer forkert tilbage, er der, hvor rettelsen hører til.