utun-Schnittstelle der Mac-VPN ist oben, aber der Verkehr scheitert? Prüfen Sie ifconfig

ifconfig zeigt einen utun-Namen, eine Adresse und die MTU, aber nicht, welche App ihn besitzt oder wohin Pakete gehen. Fünf reine Leseprüfungen, die die eigentliche Frage beantworten.

Sie haben die VPN verbunden, ifconfig ausgeführt und einen utun4-Eintrag mit einer Adresse darauf gefunden. Die Seite, die Sie brauchten, läuft weiterhin in einen Timeout. Diese Lücke ist normal: Die Auflistung beweist, dass eine virtuelle Schnittstelle existiert, nicht dass Ihr Client sie besitzt, dass die Route, die Sie interessiert, sie auswählt oder dass Pakete sie durchqueren. Ich habe aufgehört, dem Schnittstellennamen zu vertrauen, nachdem ich einen Nachmittag damit verbracht hatte, dem falschen Tunnel die Schuld zu geben – auf einem Laptop, der schon drei utun-Einträge hatte, bevor ich irgendetwas installierte.

Was eine utun-Zeile tatsächlich enthält

Führen Sie ifconfig -a aus, wenn Sie das ganze Bild wollen. Ohne Argumente aufgerufen, druckt ifconfig nur Schnittstellen, die gerade oben sind, weshalb ein Tunnel, der nicht startete, in der Ausgabe fehlen kann, die Leute in Tickets einfügen. ifconfig -l gibt nur die Namen zurück, und das ist der schnellste Weg zu sehen, ob nach dem Verbinden ein neues utun aufgetaucht ist.

Beim Lesen einer einzelnen Schnittstelle liegen die nützlichen Details. Ein verbundener Tunnel sieht typischerweise so aus:

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

Drei Felder tragen die Antwort. UP und RUNNING sagen, dass der Kernel bereit ist, die Schnittstelle zu benutzen. POINTOPOINT zusammen mit der Peer-Adresse --> ist die Signatur eines Tunnels und nicht einer physischen Verbindung. Der Wert mtu erklärt eine ganze Klasse von „verbindet, dann stockt“-Meldungen, weil utun-Schnittstellen üblicherweise mit einer reduzierten MTU hochkommen, 1380 in mehreren macOS-Builds, und der Client sie überschreiben kann. Die Feldliste ist kurz genug, um sie einmal im ifconfig-Handbuch, das Apple mitliefert, zu überfliegen.

Finden Sie den Prozess hinter der Schnittstelle

ifconfig kennt kein Konzept einer besitzenden Anwendung. Zwei VPN-Clients, ein Systemdienst und ein übrig gebliebener Tunnel von letzter Woche erzeugen alle Einträge, die auf dieser Ebene identisch aussehen. Auf meinem eigenen Mac existierten utun0 bis utun3, bevor ich irgendetwas konfigurierte; Continuity und iCloud Private Relay nutzen ebenfalls Tunnel, und keiner von ihnen ist die Verbindung, die Sie untersuchen.

Für Tunnel, die eine Konfiguration beim System registrieren, ist scutil --nc list die schnellste Zuordnung. Es druckt jede Konfiguration mit Status und Dienst-ID, und eine verbundene wird als solche markiert:

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

Clients, die einen eigenen Tunnelprozess ausführen, statt eine Konfiguration zu registrieren, erscheinen dort nie. Tunnelblick und eine openvpn-Instanz auf der Kommandozeile gehören zu dieser Gruppe, also prüfen Sie auch die Prozesstabelle: ps -Ao pid,comm | grep -i openvpn. Sobald ein Prozess den Tunnel besitzt, gehört die utun-Nummer diesem Prozess und niemandem sonst.

Testen Sie die Adresse, bevor Sie die Route testen

Eine Schnittstelle kann oben sein, ohne eine nutzbare Adresse zu haben. Ein reines IPv6-Profil zeigt einen link-lokalen fe80::-Eintrag und nichts in der inet-Zeile, und ein Client, dem es nicht gelang, eine geschobene Adresse anzuwenden, hinterlässt genau dieselbe Form. Wenn Ihr Ziel IPv4 ist und der Tunnel keine IPv4-Adresse hat, ist die Routing-Frage bereits entschieden.

Die MTU verdient eine eigene Prüfung, weil der Fehler nicht wie ein Größenproblem aussieht. Er sieht aus wie eine Verbindung, die sich authentifiziert und dann still wird, sobald eine große Übertragung beginnt. Senden Sie eine Sonde, die nicht fragmentiert werden darf, so bemessen, dass das Paket zur MTU der Schnittstelle passt; bei einer MTU von 1400 sind es 1372 Byte Nutzlast:

ping -D -s 1372 10.8.0.5

Eine Antwort bedeutet, dass Pakete dieser Größe den Tunnel durchqueren. Schweigen, während kleine Pings gelingen, deutet auf die MTU oder auf etwas hin, das ICMP auf dem Pfad verwirft, nicht auf die Authentifizierung, die längst abgeschlossen war, bevor Sie überhaupt eine Schnittstelle hatten.

Beweisen Sie, dass das Ziel den Tunnel wählt

Die entscheidende Frage ist nicht, ob utun4 existiert, sondern ob Verkehr zu einer bestimmten Adresse ihn verlässt. route -n get beantwortet das für ein einzelnes Ziel und druckt das Gateway und die Schnittstelle, die es verwenden würde:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Wenn derselbe Befehl en0 meldet, tut Ihre Split-Tunnel-Konfiguration, was ihr gesagt wurde, und keine noch so gründliche Schnittstellenprüfung ändert das. Verwenden Sie netstat -rn -f inet, wenn Sie die Standardroute und die ganze Tabelle in einer Ansicht brauchen.

Zähler entscheiden, ob sich Pakete tatsächlich bewegen. netstat -ib meldet Paket- und Bytesummen pro Schnittstelle, utun-Einträge eingeschlossen; die Zahlen sind kumulativ, also lesen Sie sie zweimal mit Abstand und vergleichen Sie:

netstat -ib | grep utun4

Eingefrorene Zähler, während die Anwendung weiter versucht, bedeuten, dass der Kernel der Schnittstelle nie ein Paket übergeben hat. Zähler, die in beide Richtungen steigen, während die Anwendung weiter scheitert, verlagern die Untersuchung an das andere Ende des Tunnels.

Wenn gar kein utun auftaucht

Eine leere Schnittstellenliste nach einem Login, der erfolgreich aussah, bedeutet meist, dass der Tunnel nie startete, nicht dass ifconfig ihn verbirgt. Prüfen Sie den Status des Clients selbst, dann den des Systems: Eine Netzwerkerweiterung, die nie genehmigt wurde oder die macOS nach einem Update deaktiviert hat, hinterlässt keine Schnittstelle. Die Genehmigung liegt in den Systemeinstellungen unter Login Items & Extensions, und ein veralteter Eintrag dort ist es wert, erneut umgeschaltet zu werden, bevor Sie irgendetwas neu installieren.

Die utun-Nummerierung ist über Wiederverbindungen hinweg nicht stabil. Sie können utun5 bekommen, wo vor zehn Minuten utun4 existierte, weil die alte Schnittstelle abgebaut wird und der Kernel den nächsten freien Index vergibt. Skripte, die einen Namen hart kodieren, brechen in diesem Moment still; gleichen Sie stattdessen auf die Adresse oder die Route ab.

Halten Sie die Leseseite schreibgeschützt. sudo ifconfig utun4 down unterbricht den Tunnel, und bei einem Full-Tunnel-Profil nimmt es Ihre Remote-Sitzung mit, ein schlechter Tausch, wenn Sie nur Beweise sammeln wollten. Nichts, was Sie hier brauchen, verlangt root: Flags, Adressen und Zähler zu lesen funktioniert als normaler Benutzer.

Arbeiten Sie die Prüfungen der Reihe nach ab, wenn sich ein Mac-Tunnel das nächste Mal danebenbenimmt: Bestätigen Sie mit ifconfig -l, dass ein utun aufgetaucht ist, lesen Sie Flags, Adressen und MTU, ordnen Sie ihn einem Prozess zu, fragen Sie route -n get, welche Schnittstelle das Ziel nutzt, und beobachten Sie dann, wie sich netstat -ib bewegt. Jeder Schritt schließt eine andere Schicht aus, und der erste, der falsch zurückkommt, ist die Stelle für die Reparatur.

Ähnliche Artikel