Mac VPN utun-grensesnitt aktivt, men trafikken svikter? Sjekk ifconfig

Du koblet til VPN-en, kjørte ifconfig og fant en utun4-oppføring med en adresse på. Nettstedet du trengte går fortsatt i tidsavbrudd. Dette gapet er normalt: oppføringen beviser at et virtuelt grensesnitt finnes, ikke at klienten din eier det, at ruten du bryr deg om velger det, eller at pakker krysser det. Jeg sluttet å stole på grensesnittnavnet etter en ettermiddag med å skylde på feil tunnel på en laptop som allerede hadde tre utun-oppføringer før jeg installerte noe.

Hva en utun-linje faktisk inneholder

Kjør ifconfig -a når du vil ha hele bildet. Kalt uten argumenter, ifconfig skriver bare ut grensesnitt som er aktive akkurat nå, og derfor kan en tunnel som ikke startet mangle i utdataene folk limer inn i saker. ifconfig -l returnerer bare navnene, og det er den raskeste måten å se om en ny utun dukket opp etter at du koblet til.

Å lese ett enkelt grensesnitt er der den nyttige detaljen bor, og en tilkoblet tunnel ser vanligvis slik ut.

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 felt bærer svaret. UP og RUNNING sier at kjernen er villig til å bruke grensesnittet. POINTOPOINT pluss --> peer-adressen er signaturen til en tunnel og ikke til en fysisk lenke. mtu verdien forklarer en hel klasse av «kobler til, så stopper»-rapporter, fordi utun-grensesnitt vanligvis kommer opp med redusert MTU, 1380 i flere macOS-bygg, og klienten kan overstyre den. Feltlisten er kort nok til å skumme én gang i ifconfig-håndboken Apple leverer.

Finn prosessen bak grensesnittet

ifconfig har ikke noe begrep om en eierapplikasjon. To VPN-klienter, en systemtjeneste og en gjenglemt tunnel fra forrige uke gir alle oppføringer som ser identiske ut på dette nivået. På min egen Mac fantes utun0 til utun3 allerede før jeg konfigurerte noe; Continuity og iCloud Private Relay bruker også tunneler, og ingen av dem er tilkoblingen du feilsøker.

For tunneler som registrerer en konfigurasjon hos systemet, scutil --nc list er den raskeste korrelasjonen, den skriver ut hver konfigurasjon med status og tjeneste-ID, og en tilkoblet er merket som sådan.

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

Klienter som kjører sin egen tunnelprosess i stedet for å registrere en konfigurasjon, dukker aldri opp der. Tunnelblick og en openvpn fra kommandolinjen faller i den gruppen, så sjekk prosesstabellen også: ps -Ao pid,comm | grep -i openvpn. Når en prosess eier tunnelen, tilhører utun-nummeret den prosessen og ingenting annet.

Test adressen før du tester ruten

Et grensesnitt kan være aktivt uten en brukbar adresse. En IPv6-bare profil viser en link-local fe80::-oppføring og ingenting i inet-linjen, og en klient som ikke klarte å bruke en presset adresse etterlater nøyaktig samme form. Hvis målet ditt er IPv4 og tunnelen ikke har noen IPv4-adresse, er rutingspørsmålet allerede avgjort.

MTU fortjener en egen kontroll, fordi feilen ikke ser ut som et størrelsesproblem. Den ser ut som en tilkobling som autentiserer og deretter blir stille så snart en stor overføring starter. Send en sonde som ikke skal fragmenteres, dimensjonert slik at pakken passer til grensesnittets MTU; for en MTU på 1400 er nyttelasten 1372 byte:

ping -D -s 1372 10.8.0.5

Et svar betyr at pakker av den størrelsen går gjennom tunnelen. Stillhet mens små ping lykkes peker på MTU eller på noe som slipper ICMP på veien, ikke på autentisering, som allerede var fullført før du i det hele tatt fikk et grensesnitt.

Bevis at målet velger tunnelen

Spørsmålet som betyr noe er ikke om utun4 finnes, men om trafikk til én bestemt adresse går ut gjennom den. route -n get svarer på det for én destinasjon og skriver ut gatewayen og grensesnittet den ville brukt:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Hvis samme kommando rapporterer en0, gjør split tunneling-konfigurasjonen din det den ble bedt om, og ingen mengde grensesnittinspeksjon vil endre det. Bruk netstat -rn -f inet når du trenger standardruten og hele tabellen i én visning.

Tellere avgjør om pakker faktisk beveger seg. netstat -ib rapporterer pakke- og bytetotaler per grensesnitt, utun-oppføringer inkludert; tallene er kumulative, så les dem to ganger med et mellomrom og sammenlign:

netstat -ib | grep utun4

Frosne tellere mens applikasjonen fortsetter å prøve betyr at kjernen aldri ga en pakke til grensesnittet. Tellere som stiger i begge retninger mens applikasjonen fortsatt feiler, flytter undersøkelsen til den andre enden av tunnelen.

Når ingen utun dukker opp i det hele tatt

En tom grensesnittliste etter en innlogging som så vellykket ut betyr vanligvis at tunnelen aldri startet, ikke at ifconfig skjuler den. Sjekk klientens egen status, deretter systemets: en Network Extension som aldri ble godkjent, eller som macOS slo av etter en oppdatering, etterlater ikke noe grensesnitt. Godkjenningen ligger i Systeminnstillinger under Innloggingsobjekter og utvidelser, og en utdatert oppføring der er verdt å slå av og på igjen før du reinstalerer noe.

utun-nummereringen er ikke stabil mellom gjentilkoblinger. Du kan få utun5 der utun4 fantes for ti minutter siden, fordi det gamle grensesnittet rives ned og kjernen deler ut neste ledige indeks. Skript som hardkoder et navn bryter stille i det øyeblikket; match på adressen eller på ruten i stedet.

Hold lesesiden skrivebeskyttet. sudo ifconfig utun4 down avbryter tunnelen, og på en full-tunnelprofil tar den den eksterne økten din med seg, som er en dårlig bytte når du bare prøvde å samle bevis. Ingenting du trenger her krever root: lesing av flagg, adresser og tellere fungerer som din vanlige bruker.

Gå gjennom kontrollene i rekkefølge neste gang en Mac-tunnel oppfører seg dårlig: bekreft at en utun dukket opp med ifconfig -l, les flaggene, adressene og MTU-en, knytt den til en prosess, spør route -n get hvilket grensesnitt målet bruker, og se deretter netstat -ib bevege seg. Hvert steg utelukker et annet lag, og det første som kommer tilbake feil er der rettelsen hører hjemme.