OpenVPN TAP unter macOS: Prüfen Sie den Client, bevor Sie debuggen

Ein altes Profil landet auf einem aktuellen Mac, der Client importiert es ohne Beanstandung, und die Verbindung bricht ab oder überträgt nie Daten. Bevor Sie einen Nachmittag mit Zertifikaten verbringen, lesen Sie die Gerätezeile im Profil. Steht dort dev tap, verlangen Sie vom Client eine Schnittstelle nach Ethernet-Art, und unter macOS enden die meisten dieser Sitzungen genau bei dieser Anforderung.

Schritt 1: Bestätigen Sie, dass das Profil wirklich TAP verlangt

Profile werden umbenannt, eingepackt und neu exportiert, prüfen Sie also die Datei, die Sie tatsächlich importiert haben. Suchen Sie nach der Gerätedirektive und nach jedem Include, das sie überschreiben könnte. Zwei Zeilen Ausgabe entscheiden die Frage in den meisten Fällen. Wenn sowohl dev als auch dev-type auftauchen, gewinnt die spätere Direktive, und genau solche Details verbirgt ein kopiertes Profil.

grep -nE "^[[:space:]]*(dev|dev-type)[[:space:]]" client.ovpn
ls -l ~/Library/Application\ Support/ 2>/dev/null

Enthält die Datei dev tap oder dev tap0, muss der Client eine TAP-Schnittstelle bereitstellen. Enthält sie dev tun, gilt der Rest dieses Artikels nicht, und der Fehler liegt woanders.

Notieren Sie Clientname und -version, die macOS-Version und die Herkunft des Profils. Diese drei Fakten entscheiden, welcher der beiden folgenden Wege überhaupt möglich ist.

Schritt 2: Wissen, was der Gerätemodus tatsächlich ändert

Eine TUN-Schnittstelle überträgt IP-Pakete. Der Client liest und schreibt Pakete an einen IP-Peer, und das Betriebssystem leitet sie wie jede andere Schnittstelle weiter.

Eine TAP-Schnittstelle überträgt Ethernet-Frames, einschließlich Broadcast und ARP. Das ermöglicht einem gebrückten Server, Adressen per DHCP zu verteilen, und einem Client, Geräte durch Rufen zu entdecken, weshalb manche Altentwürfe darauf angewiesen sind.

Der Preis ist, dass TAP einen Treiber braucht, der dem System eine Ethernet-Schnittstelle präsentiert. Apple hat das Kernel-Erweiterungsmodell abgekündigt, auf dem ältere TAP-Treiber für den Mac beruhten, und seine Ersatz-API erscheint nicht wie von Zauberhand in Clients, die nie für ihre Nutzung aktualisiert wurden. Eine Plattformfähigkeit und ein ausgeliefertes Produkt sind zwei verschiedene Dinge.

Schritt 3: Wählen Sie zwischen einem kompatiblen Client und einer Migration

Es gibt zwei ehrliche Wege. Der erste ist ein Client, dessen Herausgeber für Ihre macOS-Version und Hardware erklärt, dass er die benötigte TAP-Konfiguration unterstützt. Kein Forumsbeitrag von vor vier Jahren und kein archivierter Installer: eine aktuelle Erklärung plus eine Testverbindung.

Der zweite ist der Umzug des Dienstes auf TUN, was ebenso eine Server- wie eine Clientänderung ist. Er braucht eine geroutete Topologie, einen Adresspool, gepushte Routen für die entfernten Netze und einen Rückweg von diesen Netzen zum Pool.

Was nicht funktioniert, ist, tap in Ihrer lokalen Kopie in tun zu ändern und zu hoffen. Der Server brückt weiterhin, der Client spricht jetzt IP, und nichts passt zusammen.

Schritt 4: Sammeln Sie die Fakten, bevor Sie einen laufenden Dienst ändern

Lassen Sie das Originalprofil unangetastet und legen Sie eine Kopie für Experimente an. Eine Datei, die Sie in einer Minute wiederherstellen können, ist mehr wert als ein aufgeräumter Ordner. Sobald der Ersatz funktioniert, löschen Sie die Kopie bewusst, statt zwei Profile zu hinterlassen, die in einer Liste identisch aussehen. Diese eine Gewohnheit verhindert den größten Teil der Verwirrung nach einer gescheiterten Migration. Halten Sie das aktuelle Verhalten fest, damit Sie beweisen können, was sich geändert hat: Kommt der Tunnel hoch, bekommt er eine Adresse, erreichen Sie einen bekannten Host, und funktioniert die Namensauflösung.

Stellen Sie dem Gateway-Besitzer drei Fragen. Läuft der Server in einer gebrückten oder gerouteten Topologie? Welche entfernten Präfixe sollen erreichbar sein? Und gibt es ein Wartungsfenster für eine Konfigurationsänderung, oder soll das ohne Eingriff am Server funktionieren?

Die Antworten darauf entscheiden, ob Sie heute Nachmittag ein Clientproblem lösen oder nächste Woche eine Netzwerkänderung planen.

Schritt 5: Überprüfen Sie die Migration von beiden Enden

Sobald der Server eine geroutete Konfiguration hat und Sie ein passendes Profil besitzen, testen Sie in dieser Reihenfolge: Der Tunnel baut sich auf, der Client erhält eine Adresse aus dem neuen Pool, ein Host auf der Gegenseite antwortet, und ein Name wird über die gepushte DNS-Einstellung aufgelöst.

Testen Sie dann, was früher von Ethernet-Verhalten abhing. Wenn eine Anwendung Geräte per Broadcast entdeckt hat, findet sie sie über einen gerouteten Tunnel nicht mehr, und keine Clientkonfiguration bringt das zurück. Diese Anwendung braucht eine bekannte Adresse, einen lokalen Hilfs-Host oder eine andere Entdeckungsmethode.

Schließen Sie mit einem einmaligen erneuten Verbinden und Neustart ab, denn ein Profil, das nur beim ersten Versuch funktioniert, bedeutet meist, dass die gepushten Routen oder die DNS-Einstellung beim Wiederverbinden nicht angewendet werden.

Wenn es weiterhin scheitert, lesen Sie den ersten Fehler

Ein Client, der die Schnittstelle nicht anlegen kann, sagt das in seinem Protokoll, meist in den ersten Zeilen. Ein Client, der sie anlegt und dann die Authentifizierung nicht schafft, ist längst über die Gerätefrage hinaus, und weiteres TAP-Jagen verschwendet die Sitzung.

Bewahren Sie das Originalprofil und die funktionierende Konfiguration, bis der Ersatz bewiesen ist. Eine Clientänderung zurückzurollen geht schnell; ein gebrücktes Netz wieder aufzubauen, das jemand auf Verdacht zerlegt hat, nicht.