Mehrere OpenVPN-Remotes: Failover-Liste, kein Link-Bonding
Ein zweites Remote ist ein zweiter Versuch, keine zweite Spur: was der Client mit einer Liste von Endpunkten macht und was echte Aggregation bräuchte.
Zwei Remote-Zeilen in einem Profil sehen wie eine zweite Spur aus; sie sind ein zweiter Versuch. Wenn der erste Endpunkt nicht mehr antwortet, geht der Client weiter, und die Sitzung wird nicht breiter. Nennen Sie die Liste früh Failover, sonst drehen Sie am falschen Regler.
Was eine Remote-Liste Ihnen bringt
Behandeln Sie das Profil als geordnete Menge von Versuchen, nicht als Kapazitätspool. Jeder Eintrag bekommt seine Runde, den Tunnel aufzubauen, und die Sitzung lebt auf dem, der geantwortet hat. Eine längere Liste verbessert Ihre Verbindungschancen, nicht die Größe der Leitung.
Echte Aggregation ist eine andere Maschine. Einen Fluss über mehrere Pfade zu verteilen erfordert Software an beiden Enden, die den Verkehr aufteilt und in Reihenfolge wieder zusammensetzt.
Ein Anbieter, der schnellere Tunnel aus mehr Servern verspricht, verkauft genau dieses zweite Modell, keine längere Liste. Wenn der Client Endpunkte nur der Reihe nach probiert, ändern fünf Einträge Ihre Chancen und sonst nichts. Beobachten Sie einen Ausfall: Die Sitzung fällt weg und kehrt anderswo zurück, was das Protokoll als neuen Endpunkt zeigt, nie als breitere Leitung.
Blöcke, die Einstellungen bei einem Endpunkt halten
Eine einfache remote-Zeile trägt eine Adresse, manchmal Port und Protokoll. Wenn ein Endpunkt einen Proxy braucht oder einen Transport, den der Rest der Datei nicht nutzt, legen Sie diese Einstellungen in einen Verbindungsblock, der sie bei ihm hält. Inline-Blöcke funktionieren auch in einer .ovpn-Datei, und so werden die meisten Profile ausgeliefert.
Alles außerhalb eines Blocks wirkt als Standard für Einträge, die ihn nicht überschreiben. Deshalb verhalten sich ein gebauter Block und vier einfache Remotes auf Arten, die die Adressliste nicht erklären kann.
Einen Block zu löschen, den Sie nicht erkennen, ist nicht kosmetisch. Der Endpunkt, zu dem er gehörte, fällt auf die Standards der Datei zurück, die ein anderer Transport sein können als der, auf dem er lauscht. Entfernen Sie die falsche Hülle, und ein Eintrag scheitert, während die übrigen funktionieren, also sieht es nach einem schlechten Server aus statt nach einem kaputten Profil. Lesen Sie jedes Remote mit seinem Transport, Port und Proxy, bevor Sie bearbeiten.
Wiederholungsreihenfolge und der Preis von remote-random
Die Reihenfolge zählt, weil jeder tote Eintrag Zeit kostet, bevor der nächste Versuch kommt. Setzen Sie den gewünschten Endpunkt nach vorn und behandeln Sie den Rest als gereihte Rückfallebenen.
remote-random mischt die Startreihenfolge, was Last über gleichwertige Server verteilt und sich rächt, wenn ein Endpunkt eindeutig primär ist. Protokollieren Sie in jedem Fall den Endpunkt, den der Client gewählt hat; der Profilname sagt nichts, wenn sich eine Verbindung langsam anfühlt. Die Link-Zeile aus einem ausführlichen Protokoll zu grepen zeigt, wo die Sitzung gelandet ist.
Betreiber zu mischen bricht die Vertrauensaussage
Ein Profil ist auch eine Aussage über Identität: Diese Adressen sind der Dienst, den Sie erreichen wollten, und das angeheftete Zertifikat gehört dazu. Kostenlose öffentliche Server in diese Datei zu werfen bricht die Aussage: Ihre Zertifikate und Ihres beschreiben verschiedene Dienste. Das übliche Ergebnis ist ein Identitätsfehler oder Anmeldedaten, die einem Host außerhalb des Netzes Ihres Anbieters angeboten werden. Halten Sie Alternativen im Satz, den Ihr Betreiber verteilt, mit passenden Anmeldedaten und Vertrauensmaterial.
Wenn Sie Endpunkte von zwei Anbietern brauchen, ist das Routing, keine Profilbearbeitung. Beantworten Sie es oberhalb des Tunnels, wo Sie sagen können, welcher Verkehr welchen Pfad nimmt.
Jeden Eintrag testen statt annehmen
Nach einer genehmigten Profilaktualisierung verbinden Sie sich bewusst mit jedem erforderlichen Endpunkt und bestätigen, welcher Transport hochkam. Ein ausführlicher Lauf macht das sichtbar. Starten Sie openvpn --config office.ovpn --verb 4 und lesen Sie die Link-Zeile für die erwartete Adresse. Prüfen Sie dann die Ressourcen hinter dem Tunnel; ein Eintrag kann den Handshake abschließen und Sie trotzdem nirgendwohin routen.
Failover braucht einen eigenen Test statt einer Hoffnung. Blockieren Sie den ersten Endpunkt im Labor, starten Sie den Client und messen Sie, wie lange er zum Weiterziehen braucht. Eine lange Liste hinter einem langsamen ersten Eintrag ist schlechter als eine kurze, die gut startet.
Prüfen Sie die Liste erneut, wann immer der Betreiber sie ändert. Ein importierter Satz ist nur nützlich, solange seine Einträge existieren und den Transport sprechen, den Ihre Blöcke beschreiben. Das OpenVPN-2.6-Handbuch deckt hier die Direktiven remote, connection und random-order ab, und es ist die Version, die Sie prüfen sollten, wenn die Syntax zweifelhaft ist.