Mac VPN utun-interface actief maar verkeer mislukt? Controleer ifconfig

Je hebt de VPN verbonden, ifconfig uitgevoerd en een utun4 invoer met een adres erop gevonden. De site die je nodig had, loopt nog steeds in een time-out. Die kloof is normaal: de lijst bewijst dat er een virtuele interface bestaat, niet dat jouw client hem bezit, dat de route die jij belangrijk vindt hem kiest of dat pakketten erdoorheen gaan. Ik ben de interfacenaam niet meer gaan vertrouwen nadat ik een middag de verkeerde tunnel de schuld had gegeven op een laptop die al drie utun-invoeren had voordat ik iets installeerde.

Wat een utun-regel werkelijk bevat

Voer ifconfig -a uit als je het volledige beeld wilt. Zonder argumenten aangeroepen, ifconfig drukt alleen interfaces af die nu actief zijn, waardoor een tunnel die niet is gestart kan ontbreken in de uitvoer die mensen in tickets plakken. ifconfig -l geeft alleen de namen terug, en dat is de snelste manier om te zien of er na het verbinden een nieuwe utun verscheen.

Het lezen van één interface is waar de nuttige details zitten, en een verbonden tunnel ziet er meestal zo uit.

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

Drie velden dragen het antwoord. UP en RUNNING zeggen dat de kernel bereid is de interface te gebruiken. POINTOPOINT plus het --> peer-adres is de signatuur van een tunnel en niet van een fysieke verbinding. De mtu waarde verklaart een hele klasse van "verbindt, dan stokt"-meldingen, omdat utun-interfaces meestal opkomen met een verlaagde MTU, 1380 in verschillende macOS-builds, en de client kan die overschrijven. De veldenlijst is kort genoeg om één keer door te nemen in de ifconfig-handleiding die Apple meelevert.

Vind het proces achter de interface

ifconfig heeft geen begrip van een eigenaar-applicatie. Twee VPN-clients, een systeemservice en een achtergebleven tunnel van vorige week produceren allemaal invoeren die op dit niveau identiek lijken. Op mijn eigen Mac bestonden utun0 tot en met utun3 al voordat ik iets configureerde; Continuity en iCloud Private Relay gebruiken ook tunnels, en geen daarvan is de verbinding die je onderzoekt.

Voor tunnels die een configuratie bij het systeem registreren, scutil --nc list is de snelste correlatie, hij drukt elke configuratie af met zijn status en service-ID, en een verbonden configuratie is als zodanig gemarkeerd.

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

Clients die hun eigen tunnelproces draaien in plaats van een configuratie te registreren, verschijnen daar nooit. Tunnelblick en een openvpn vanaf de commandoregel vallen in die groep, dus controleer ook de procestabel: ps -Ao pid,comm | grep -i openvpn. Zodra een proces de tunnel bezit, hoort het utun-nummer bij dat proces en bij niets anders.

Test het adres voordat je de route test

Een interface kan actief zijn zonder bruikbaar adres. Een profiel met alleen IPv6 toont een link-local fe80:: invoer en niets in de inet regel, en een client die een gepusht adres niet kon toepassen laat precies dezelfde vorm achter. Als je bestemming IPv4 is en de tunnel heeft geen IPv4-adres, dan is de routeringsvraag al beslecht.

MTU verdient een aparte controle, omdat de fout niet op een grootteprobleem lijkt. Het lijkt op een verbinding die authenticeert en dan stil wordt zodra een grote overdracht begint. Stuur een probe die niet gefragmenteerd mag worden, zo groot dat het pakket bij de interface-MTU past; bij een MTU van 1400 is de payload 1372 bytes:

ping -D -s 1372 10.8.0.5

Een antwoord betekent dat pakketten van die grootte door de tunnel gaan. Stilte terwijl kleine pings slagen wijst op de MTU of op iets dat ICMP onderweg laat vallen, niet op authenticatie, die al klaar was voordat je überhaupt een interface had.

Bewijs dat de bestemming de tunnel kiest

De vraag die telt is niet of utun4 bestaat, maar of verkeer naar één specifiek adres erdoor naar buiten gaat. route -n get beantwoordt dat voor één bestemming en drukt de gateway en interface af die hij zou gebruiken:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Als hetzelfde commando en0 meldt, doet je split tunneling-configuratie wat haar is opgedragen en geen enkele inspectie van de interface zal dat veranderen. Gebruik netstat -rn -f inet wanneer je de standaardroute en de hele tabel in één overzicht nodig hebt.

Tellers beslissen of pakketten echt bewegen. netstat -ib rapporteert pakket- en bytetotalen per interface, utun-invoeren inbegrepen; de getallen zijn cumulatief, dus lees ze twee keer met een tussenpoos en vergelijk:

netstat -ib | grep utun4

Bevroren tellers terwijl de applicatie blijft herproberen betekenen dat de kernel nooit een pakket aan de interface heeft gegeven. Tellers die in beide richtingen stijgen terwijl de applicatie nog steeds faalt, verplaatsen het onderzoek naar het andere uiteinde van de tunnel.

Wanneer er helemaal geen utun verschijnt

Een lege interfacelijst na een login die geslaagd leek betekent meestal dat de tunnel nooit is gestart, niet dat ifconfig hem verbergt. Controleer de status van de client, dan die van het systeem: een Network Extension die nooit is goedgekeurd, of die macOS na een update heeft uitgeschakeld, laat geen interface achter. De goedkeuring staat in Systeeminstellingen onder Inlogitems en extensies, en een verouderde vermelding daar is het opnieuw omzetten waard voordat je iets herinstalleert.

De utun-nummering is niet stabiel tussen herverbindingen. Je kunt utun5 krijgen waar utun4 tien minuten geleden bestond, omdat de oude interface wordt afgebroken en de kernel de volgende vrije index uitgeeft. Scripts die een naam hardcoderen breken op dat moment stil; match in plaats daarvan op het adres of op de route.

Houd de leeskant alleen-lezen. sudo ifconfig utun4 down onderbreekt de tunnel, en op een full-tunnelprofiel neemt hij je externe sessie mee, wat een slechte ruil is als je alleen bewijs probeerde te verzamelen. Niets wat je hier nodig hebt vereist root: vlaggen, adressen en tellers lezen werkt als je normale gebruiker.

Werk de controles in volgorde af de volgende keer dat een Mac-tunnel zich misdraagt: bevestig dat er een utun verscheen met ifconfig -l, lees de vlaggen, adressen en MTU, schrijf hem toe aan een proces, vraag route -n get welke interface de bestemming gebruikt, en kijk dan hoe netstat -ib beweegt. Elke stap sluit een andere laag uit, en de eerste die verkeerd terugkomt is waar de oplossing hoort.