Mac VPN utun-gränssnitt aktivt men trafiken misslyckas? Kontrollera ifconfig

Du anslöt VPN:en, körde ifconfig och hittade en utun4-post med en adress på. Webbplatsen du behövde går fortfarande i timeout. Det glappet är normalt: listningen bevisar att ett virtuellt gränssnitt finns, inte att din klient äger det, att rutten du bryr dig om väljer det eller att paket passerar genom det. Jag slutade lita på gränssnittsnamnet efter en eftermiddag som jag ägnade åt att skylla på fel tunnel på en laptop som redan hade tre utun-poster innan jag installerade något.

Vad en utun-rad faktiskt innehåller

Kör ifconfig -a när du vill ha hela bilden. Anropad utan argument, ifconfig skriver bara ut gränssnitt som är aktiva just nu, och därför kan en tunnel som inte startade saknas i utdata som folk klistrar in i ärenden. ifconfig -l returnerar bara namnen, och det är det snabbaste sättet att se om en ny utun dök upp efter att du anslöt.

Att läsa ett enda gränssnitt är där den användbara detaljen bor, och en ansluten tunnel ser vanligtvis ut så här.

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 fält bär svaret. UP och RUNNING säger att kärnan är villig att använda gränssnittet. POINTOPOINT plus --> peer-adressen är signaturen för en tunnel och inte för en fysisk länk. mtu värdet förklarar en hel klass av "ansluter, sedan fastnar"-rapporter, eftersom utun-gränssnitt vanligtvis kommer upp med reducerad MTU, 1380 i flera macOS-byggen, och klienten kan skriva över den. Fältlistan är kort nog att skumma en gång i ifconfig-handboken som Apple levererar.

Hitta processen bakom gränssnittet

ifconfig har inget begrepp om en ägarapplikation. Två VPN-klienter, en systemtjänst och en kvarlämnad tunnel från förra veckan producerar alla poster som ser identiska ut på den här nivån. På min egen Mac fanns utun0 till utun3 redan innan jag konfigurerade något; Continuity och iCloud Private Relay använder också tunnlar, och ingen av dem är anslutningen du felsöker.

För tunnlar som registrerar en konfiguration hos systemet, scutil --nc list är den snabbaste korrelationen, den skriver ut varje konfiguration med status och tjänste-ID, och en ansluten markeras som sådan.

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

Klienter som kör sin egen tunnelprocess i stället för att registrera en konfiguration dyker aldrig upp där. Tunnelblick och en openvpn från kommandoraden faller i den gruppen, så kontrollera processtabellen också: ps -Ao pid,comm | grep -i openvpn. När en process äger tunneln tillhör utun-numret den processen och ingenting annat.

Testa adressen innan du testar rutten

Ett gränssnitt kan vara aktivt utan en användbar adress. En profil med bara IPv6 visar en link-local fe80::-post och ingenting i inet-raden, och en klient som inte lyckades tillämpa en påskjuten adress lämnar exakt samma form. Om ditt mål är IPv4 och tunneln inte har någon IPv4-adress är routingfrågan redan avgjord.

MTU förtjänar en separat kontroll, eftersom felet inte ser ut som ett storleksproblem. Det ser ut som en anslutning som autentiserar och sedan tystnar så snart en stor överföring börjar. Skicka en sond som inte får fragmenteras, dimensionerad så att paketet matchar gränssnittets MTU; för en MTU på 1400 är nyttolasten 1372 byte:

ping -D -s 1372 10.8.0.5

Ett svar betyder att paket av den storleken passerar genom tunneln. Tystnad medan små ping lyckas pekar på MTU:n eller på något som släpper ICMP på vägen, inte på autentisering, som redan var klar innan du ens fick ett gränssnitt.

Bevisa att målet väljer tunneln

Frågan som betyder något är inte om utun4 finns, utan om trafik till en specifik adress går ut genom den. route -n get svarar på det för en destination och skriver ut gatewayen och gränssnittet den skulle använda:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Om samma kommando rapporterar en0, gör din split tunneling-konfiguration det den blev tillsagd och ingen mängd gränssnittsinspektion ändrar det. Använd netstat -rn -f inet när du behöver standardrutten och hela tabellen i en vy.

Räknare avgör om paketen verkligen rör sig. netstat -ib rapporterar paket- och bytetotaler per gränssnitt, utun-poster inkluderade; siffrorna är kumulativa, så läs dem två gånger med en paus och jämför:

netstat -ib | grep utun4

Frusna räknare medan applikationen fortsätter att försöka betyder att kärnan aldrig lämnade ett paket till gränssnittet. Räknare som stiger i båda riktningarna medan applikationen fortfarande misslyckas flyttar undersökningen till tunnelns andra ände.

När ingen utun dyker upp alls

En tom gränssnittslista efter en inloggning som såg lyckad ut betyder oftast att tunneln aldrig startade, inte att ifconfig gömmer den. Kontrollera klientens egen status, sedan systemets: en Network Extension som aldrig godkändes, eller som macOS stängde av efter en uppdatering, lämnar inget gränssnitt. Godkännandet finns i Systeminställningar under Inloggningsobjekt och tillägg, och en inaktuell post där är värd att slå om innan du installerar om något.

utun-numreringen är inte stabil mellan återanslutningar. Du kan få utun5 där utun4 fanns för tio minuter sedan, eftersom det gamla gränssnittet rivs och kärnan delar ut nästa lediga index. Skript som hårdkodar ett namn går sönder tyst i det ögonblicket; matcha på adressen eller på rutten i stället.

Håll läs sidan skrivskyddad. sudo ifconfig utun4 down avbryter tunneln, och på en fulltunnelprofil tar den din fjärrsession med sig, vilket är ett dåligt byte när du bara försökte samla bevis. Inget du behöver här kräver root: läsning av flaggor, adresser och räknare fungerar som din vanliga användare.

Gör kontrollerna i ordning nästa gång en Mac-tunnel beter sig illa: bekräfta att en utun dök upp med ifconfig -l, läs dess flaggor, adresser och MTU, tillskriv den en process, fråga route -n get vilket gränssnitt målet använder, och titta sedan på netstat -ib när den rör sig. Varje steg utesluter ett annat lager, och det första som kommer tillbaka fel är där åtgärden hör hemma.