Sie starten den Client beim Booten, die Unit meldet aktiv, und der Tunnel fehlt. Die naheliegende Schlussfolgerung ist, dass der Dienst nicht starten konnte, und die naheliegende Lösung ist, ihn erneut zu starten. Beides ist oft genug falsch, um eine Regel zu rechtfertigen: Ein laufender Client, der es erneut versucht, sieht von außen genau wie ein defekter aus. Der Unterschied liegt darin, was der Prozess tut, nicht im Zustand der Unit.

Mythos: ein gestarteter Dienst bedeutet einen funktionierenden Tunnel

Eine aktive Unit belegt, dass der Prozess gestartet wurde und nicht beendet ist. Sie belegt nicht, dass das Profil geladen, das Zertifikat akzeptiert oder die Gegenseite geantwortet hat. Ein paketierter Client kann minutenlang in einer Wiederholungsschleife hängen, während systemd nur Erfolg meldet. Diese Lücke zwischen Zustand und Verhalten ist das ganze Thema.

Der umgekehrte Fall ist genauso häufig. Der Prozess kann beendet sein, nachdem er einen Schlüssel nicht lesen konnte, und die Unit meldet dann einen Fehlerzustand, der nichts über den Grund sagt. Beide Zustände brauchen das Protokoll, um sie zu unterscheiden.

Lesen Sie das Journal für die Instanz statt den Zustand der Unit. Die Begründungszeile steht im Protokoll, nicht im Statusetikett.

Mythos: Wiederholungseinstellungen decken jeden Fehler ab

Namensauflösung und Transportwiederholungen sind getrennte Einstellungen mit getrennten Standardwerten. resolv-retry steuert wiederholte Auflösungen eines entfernten Hostnamens, und der dokumentierte Standard versucht es unbegrenzt weiter. connect-retry legt den Abstand zwischen Versuchen fest, während connect-retry-max begrenzen kann, wie oft jeder entfernte Eintrag versucht wird. Prüfen Sie, welche Stufe das Protokoll nennt, bevor Sie eine davon ändern.

Nichts davon gilt für ein beschädigtes Profil, einen unlesbaren privaten Schlüssel oder ein abgelehntes Konto. Diese brauchen eine Korrektur, und ein Client, der sie weiter versucht, kommt nicht voran.

Ein nicht genehmigtes Zertifikat endlos zu wiederholen ist kein Grund, die Prüfung zu entfernen. Es ist ein Grund, den Fehler zu lesen.

Mythos: ein Starter reicht, also fügen Sie einen weiteren hinzu

Eine Verbindung, die bereits von NetworkManager oder einer paketierten Unit verwaltet wird, braucht keinen zweiten Starter. Zwei Prozesse, die um dieselben Routen konkurrieren, erzeugen doppelte Schnittstellen, verwirrende Protokolle und einen Tunnel, der aus Gründen flattert, die niemand sieht. Die zweite Kopie kommt meist als Umgehung dafür, dass die erste langsam ist.

Entscheiden Sie, welche Komponente den Tunnel besitzt, bevor Sie etwas hinzufügen. Entfernen Sie dann den anderen Starter, statt ihn zu deaktivieren und zu hoffen.

Der Eigentümer bestimmt auch, woher Wiederholungen und Anmeldedaten kommen, deshalb kommt diese Entscheidung vor jeder Feinabstimmung. Die Eigentümerschaft kommt genau aus diesem Grund zuerst.

Was tatsächlich eine Reihenfolge braucht

Die Reihenfolge kann auf eine konfigurierte Adresse warten, und das ist alles, was sie garantiert. network-online.target verzögert die Aktivierung, bis der Manager das Netzwerk als oben ansieht, und die Definition von oben hängt vom Manager ab. Es sagt nichts darüber, ob der VPN-Hostname aufgelöst wird, ob der Listener antwortet oder ob ein Captive Portal das Gerät zugelassen hat.

Lesen Sie die installierte Unit und alle Drop-ins, bevor Sie Abhängigkeiten hinzufügen. Ein breites After= auf jedem Netzwerkdienst verzögert den Start, ohne die Verbindung herzustellen, die Sie eigentlich brauchen.

Ordnen Sie die Abhängigkeit, die Sie testen können, und prüfen Sie alles andere mit einer Bereitschaftssonde. Eine Sonde, die den Tunnel öffnet, schlägt einen Timer, der rät.

Was nach dem ersten Hochkommen des Tunnels passiert

Der Start ist ein Ereignis unter vielen. Der Zugangslink wechselt, eine Portalsitzung läuft ab, der Peer startet neu. Unterscheiden Sie eine interne Wiederverbindung von einem Prozessende, das der Dienstmanager behandelt, weil beide unterschiedliche Eigentümer haben und unterschiedliche Spuren hinterlassen.

Interaktive Authentifizierung beschränkt die unbeaufsichtigte Wiederherstellung. Eine Hintergrund-Unit entsperrt keinen Desktop-Schlüsselbund und beantwortet keine MFA-Abfrage, folgen Sie daher der genehmigten Anmeldedatenregelung für den Dienstkontext.

Entscheiden Sie getrennt, was Anwendungen tun dürfen, während der Tunnel unten ist. Wiederholung stellt eine Verbindung wieder her, während eine Sperrrichtlinie entscheidet, ob direkter Verkehr in der Lücke erlaubt ist.

Ähnliche Artikel