SoftEther-Virtual-Adapter erscheint, sendet aber keinen Datenverkehr

Ein virtueller SoftEther-Adapter erscheint in der Netzwerkliste des Betriebssystems, meldet sich als nicht angeschlossen und führt keinen Datenverkehr. Diese Kombination ist für ein Gerät ohne angehängte Sitzung normal, und es ist auch der Zustand, den Sie sehen, wenn ein falsches Profil daran gebunden ist. Der Adapter ist ein Gerät, das das Betriebssystem besitzt; die Sitzung ist es, was ihn mit Leben füllt. Gehen Sie diese vier Prüfungen der Reihe nach durch und halten Sie bei der ersten an, die fehlschlägt.

Trennen Sie Gerät und Sitzung

Das Erstellen des Adapters installiert ein Netzwerkgerät; es authentifiziert sich gegenüber keinem Server. Prüfen Sie, was die Verbindungsliste des Clients sagt, bevor Sie etwas aus dem Zustand der Schnittstelle ableiten. Ein Profil, das nicht verbunden ist, erklärt den getrennten Status ohne weitere Untersuchung.

Der Adapter und die physische Schnittstelle haben unterschiedliche Aufgaben. Die eine führt den entschlüsselten Datenverkehr, den die Anwendungen sehen, die andere führt die verschlüsselte äußere Verbindung zum Server. Wer beides verwechselt, wendet Firewallregeln und Routen auf das falsche Gerät an. Regeln für die physische Schnittstelle passen nicht zum Datenverkehr des Tunnels, und Regeln für den Tunnel wirken nicht auf die äußere Verbindung.

Ordnen Sie einen Adapter genau einem Profil zu

Jeder Adapter sollte an das vorgesehene Verbindungsprofil gebunden sein, und die Bindung sollte im Client sichtbar und nicht nur erinnert werden. Wenn mehrere Adapter vorhanden sind, notieren Sie, welches Profil welches Gerät besitzt, bevor Sie eines davon anfassen. Einen Adapter über mehrere Profile hinweg wiederzuverwenden ist der Grund, warum eine veraltete Adresse einen erneuten Verbindungsaufbau überlebt.

Bietet der Client einen unterstützten Weg, die Bindung neu zu erstellen, nutzen Sie ihn, statt die Konfiguration des Betriebssystems direkt zu bearbeiten. Der Client schreibt die Einstellungen des Adapters beim Verbinden, sodass manuelle Änderungen häufig verschwinden oder in der nächsten Sitzung kollidieren.

Lesen Sie nach dem Verbinden die wirksamen Einstellungen

Sobald eine Sitzung steht, lesen Sie Adresse, Route und Resolver aus dem System. Das Statusfenster des Clients beschreibt, was er angefordert hat, während der Kernel beschreibt, was tatsächlich geschehen ist.

ip -brief address show
ip route get 10.20.30.41
resolvectl status | head -20

Die Adressliste zeigt, ob der Adapter überhaupt etwas erhalten hat, und ein Adapter ohne Adresse nach erfolgreicher Anmeldung deutet auf die Konfiguration des Profils und nicht auf den Treiber hin. Die Routenabfrage zeigt, welche Schnittstelle ein privates Ziel führen würde, und dort wird eine fehlende Route sichtbar. Die Ausgabe des Resolvers zeigt, ob DNS der Sitzung gefolgt ist, denn eine funktionierende Verbindung mit lokalem DNS ergibt immer noch eine halb kaputte Verbindung.

Ein erstellter Adapter ohne brauchbare Einstellungen kann neben einer erfolgreichen Verwaltungsanmeldung anderswo im Client bestehen. Die beiden Fenster beantworten verschiedene Fragen, sodass das eine nie ein Beweis für das andere ist. Wenn sie sich widersprechen, ist die Sicht des Systems die, die die Anwendungen erleben.

Halten Sie inne, bevor Sie brücken oder löschen

Das Brücken des virtuellen Adapters auf einen physischen ist eine Designänderung und keine Reparatur. Es verschmilzt zwei Netzgrenzen und ist kein Weg, eine fehlende Route zu beheben. Braucht die Bereitstellung diese Anordnung, braucht sie ein genehmigtes Design und einen Testplan.

Das Löschen eines Adapters ist ebenso destruktiv, wenn ein anderer Dienst ihn nutzt. Ermitteln Sie zuerst den Eigentümer, einschließlich jedes anderen Clients oder Virtualisierungsprodukts auf dem Rechner, das eine Schnittstelle mit ähnlichem Namen erstellt hat. Ein Gerät, das nach dem Entfernen wieder auftaucht, sagt Ihnen, dass etwas es neu erzeugt.

Schließen Sie ab, indem Sie die Anwendung testen, nicht den Adapter. Eine Dateifreigabe oder Intranetseite, die durch den Tunnel lädt, ist der Beleg dafür, dass Gerät, Sitzung und Route übereinstimmen.