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

Du kopla til VPN-en, køyrde ifconfig og fann ein utun4-oppføring med ei adresse på. Nettstaden du trengde går framleis i tidsavbrot. Dette gapet er normalt: oppføringa beviser at eit virtuelt grensesnitt finst, ikkje at klienten din eig det, at ruta du bryr deg om vel det, eller at pakkar kryssar det. Eg slutta å stole på grensesnittnamnet etter ein ettermiddag med å skylde på feil tunnel på ein laptop som allereie hadde tre utun-oppføringar før eg installerte noko.

Kva ei utun-linje faktisk inneheld

Køyr ifconfig -a når du vil ha heile bildet. Kalla utan argument, ifconfig skriv berre ut grensesnitt som er aktive akkurat no, og difor kan ein tunnel som ikkje starta mangla i utdataa folk limer inn i saker. ifconfig -l returnerer berre namna, og det er den raskaste måten å sjå om ein ny utun dukka opp etter at du kopla til.

Å lese eitt enkelt grensesnitt er der den nyttige detaljen bur, og ein tilkopla tunnel ser vanlegvis 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 ber svaret. UP og RUNNING seier at kjernen er viljug til å bruke grensesnittet. POINTOPOINT pluss --> peer-adressa er signaturen til ein tunnel og ikkje til ei fysisk lenkje. mtu verdien forklarer ein heil klasse av «koplar til, så stoppar»-rapportar, fordi utun-grensesnitt vanlegvis kjem opp med redusert MTU, 1380 i fleire macOS-bygg, og klienten kan overstyre han. Feltlista er kort nok til å skumme ein gong i ifconfig-handboka Apple leverer.

Finn prosessen bak grensesnittet

ifconfig har ikkje noko omgrep om ein eigarapplikasjon. To VPN-klientar, ein systemteneste og ein gløymd tunnel frå førre veke gir alle oppføringar som ser identiske ut på dette nivået. På min eigen Mac fanst utun0 til utun3 allereie før eg konfigurerte noko; Continuity og iCloud Private Relay brukar også tunnelar, og ingen av dei er tilkoplinga du feilsøkjer.

For tunnelar som registrerer ein konfigurasjon hos systemet, scutil --nc list er den raskaste korrelasjonen, han skriv ut kvar konfigurasjon med status og teneste-ID, og ein tilkopla er merkt som sådan.

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

Klientar som køyrer sin eigen tunnelprosess i staden for å registrere ein konfigurasjon, dukkar aldri opp der. Tunnelblick og ein openvpn frå kommandolinja fell i den gruppa, så sjekk prosesstabellen òg: ps -Ao pid,comm | grep -i openvpn. Når ein prosess eig tunnelen, høyrer utun-nummeret til den prosessen og ingenting anna.

Test adressa før du testar ruta

Eit grensesnitt kan vere aktivt utan ei brukbar adresse. Ein IPv6-berre profil viser ei link-local fe80::-oppføring og ingenting i inet-linja, og ein klient som ikkje klarte å bruke ei pressa adresse etterlèt nøyaktig same forma. Viss målet ditt er IPv4 og tunnelen ikkje har noka IPv4-adresse, er rutingspørsmålet allereie avgjort.

MTU fortener ein eigen kontroll, fordi feilen ikkje ser ut som eit storleiksproblem. Han ser ut som ei tilkopling som autentiserer og deretter blir stille så snart ei stor overføring startar. Send ei sonde som ikkje skal fragmenterast, dimensjonert slik at pakken passar til grensesnittet sin MTU; for ein MTU på 1400 er nyttelasta 1372 byte:

ping -D -s 1372 10.8.0.5

Eit svar betyr at pakkar av den storleiken går gjennom tunnelen. Stille medan små ping lukkast peikar på MTU eller på noko som slepp ICMP på vegen, ikkje på autentisering, som allereie var fullført før du i det heile fekk eit grensesnitt.

Bevis at målet vel tunnelen

Spørsmålet som betyr noko er ikkje om utun4 finst, men om trafikk til éi bestemt adresse går ut gjennom han. route -n get svarar på det for éin destinasjon og skriv ut gatewayen og grensesnittet han ville brukt:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Viss same kommando rapporterer en0, gjer split tunneling-konfigurasjonen din det han vart beden om, og inga mengd grensesnittinspeksjon vil endre det. Bruk netstat -rn -f inet når du treng standardruta og heile tabellen i éin visning.

Tellarar avgjer om pakkar faktisk bevegar seg. netstat -ib rapporterer pakke- og bytetotalar per grensesnitt, utun-oppføringar inkluderte; tala er kumulative, så les dei to gonger med eit mellomrom og samanlikn:

netstat -ib | grep utun4

Frosne tellarar medan applikasjonen held fram med å prøve betyr at kjernen aldri gav ein pakke til grensesnittet. Tellarar som stig i begge retningar medan applikasjonen framleis feilar, flyttar undersøkinga til den andre enden av tunnelen.

Når ingen utun dukkar opp i det heile

Ei tom grensesnittliste etter ei innlogging som såg vellukka ut betyr vanlegvis at tunnelen aldri starta, ikkje at ifconfig skjuler han. Sjekk klienten sin eigen status, deretter systemet sin: ein Network Extension som aldri vart godkjend, eller som macOS slo av etter ei oppdatering, etterlèt ikkje noko grensesnitt. Godkjenninga ligg i Systeminnstillingar under Innloggingsobjekt og utvidingar, og ei utdatert oppføring der er verdt å slå av og på igjen før du reinstalerer noko.

utun-nummereringa er ikkje stabil mellom gjenoppkoplingar. Du kan få utun5 der utun4 fanst for ti minutt sidan, fordi det gamle grensesnittet blir rive ned og kjernen deler ut neste ledige indeks. Skript som hardkodar eit namn bryt stille i det augeblikket; match på adressa eller på ruta i staden.

Hald lesesida skriveverna. sudo ifconfig utun4 down avbryt tunnelen, og på ein full-tunnelprofil tek han den eksterne økta di med seg, som er eit dårleg bytte når du berre prøvde å samle bevis. Ingenting du treng her krev root: lesing av flagg, adresser og tellarar fungerer som din vanlege brukar.

Gå gjennom kontrollane i rekkjefølgje neste gong ein Mac-tunnel oppfører seg dårleg: stadfest at ein utun dukka opp med ifconfig -l, les flagga, adressene og MTU-en, knytt han til ein prosess, spør route -n get kva grensesnitt målet brukar, og sjå deretter netstat -ib bevege seg. Kvart steg utelukkar eit anna lag, og det første som kjem tilbake feil er der rettinga høyrer heime.