OpenVPN über TCP und UDP von einem Host aus bedienen
Vor 2.7 bindet ein Prozess genau einen Transport. Vergleichen Sie ein gebrücktes TAP-Paar, zwei TUN-Subnetze und einen gemeinsamen Pool und ordnen Sie dann jedes Profil seinem Listener zu.
Netze, die nur TCP 443 zulassen, bestehen neben Netzen, die UDP problemlos durchlassen, und ein Server muss beide bedienen. Ein Profil mit proto udp bedient die zweite Gruppe und scheitert bei der ersten, und dieselbe Konfiguration auf proto tcp umzuschreiben erzeugt keinen zweiten Listener. Die Direktive wählt einen Transport für einen Prozess. Alles Weitere folgt aus dieser Einschränkung.
Entweder betreiben Sie mehr als einen Prozess, oder Sie betreiben eine Version, die mehrere Sockets gleichzeitig binden kann.
Vor 2.7 bindet ein Prozess einen Transport
Die Community-Version von OpenVPN bindet den Socket, den proto beschreibt, und diese Direktive wählt einen einzigen Transport für die Instanz. TCP und UDP sind getrennte Stapel, daher kann dieselbe Portnummer gleichzeitig von beiden belegt werden, aber nicht von einem Prozess. Die 2.6-Reihe gibt Ihnen also einen Transport pro Daemon. OpenVPN 2.7 hob diese Beschränkung für Server auf, die mehrere Sockets über mehrere --local in einem Prozess binden können.
Prüfen Sie die Version, bevor Sie um eine der beiden Antworten herum planen, denn die 2.7-Anordnung ist ein anderes Betriebsmodell mit eigener Konfigurationssyntax. Eine für 2.6 geschriebene Anleitung beschreibt zwei Prozesse, auch wenn sie es nicht sagt.
Drei Wege, zwei Instanzen zu betreiben
Mit TAP-Schnittstellen betreiben Sie eine Instanz pro Transport und brücken die beiden tap-Geräte auf dem Host. Beide Clientgruppen landen in derselben Broadcast-Domäne, wodurch ein Adresspool sie abdecken kann und broadcastabhängige Protokolle weiterlaufen. Mit TUN ist Brücken nicht möglich, daher gibt die einfachste Aufteilung jeder Instanz ihr eigenes Subnetz und überlässt dem Routing die Trennung der beiden Clientgruppen. Eine dritte Option behält einen Pool, indem jede Instanz ein learn-address -Skript aufruft, das eine /32-Route für den Client über das Gerät dieser Instanz installiert.
Genau diese dritte Anordnung wird häufig verlangt und braucht die meiste Sorgfalt, weil das Skript Teil des Datenpfads wird und Ereignisse zum Hinzufügen, Aktualisieren und Löschen korrekt verarbeiten muss.
| Arrangement | Interfaces | Address pool | Cost |
|---|---|---|---|
| Bridged TAP pair | Two tap devices joined by a bridge | One shared pool | Broadcast traffic and bridge maintenance |
| Two TUN subnets | Two tun devices, no bridge | One pool per instance | Routing rules and two plans |
| Shared pool with routes | Two tun devices plus a hook | One pool across both | A script on the data path |
Halten Sie die beiden Instanzen getrennt
Jede Instanz braucht außerdem einen eigenen Port oder eine eigene Adresse, eine eigene Statusdatei und ein eigenes Logziel. Zwei Daemons, die in dieselbe Statusdatei schreiben, erzeugen eine Ausgabe, die sich während eines Vorfalls nicht lesen lässt – genau dann, wenn Sie sie brauchen. Bindet eine zweite Instanz eine bestimmte Adresse, muss diese Adresse beim Start des Prozesses auf dem Host vorhanden sein; sonst endet er mit einem Bindefehler, bevor er etwas über Schlüssel sagt.
Benennen Sie die Units und Profile so, dass der Transport am Dateinamen erkennbar ist . Der nächste Betreiber sollte keine Konfiguration öffnen müssen, um zu erfahren, welche TCP ist.
Ordnen Sie das Profil dem Listener zu
Ein Server, der proto tcp betreibt, erwartet ein Clientprofil mit proto tcp-client , und ein Profil, das weiterhin proto udp trägt, läuft gegen diesen Listener in eine Zeitüberschreitung, ohne einen Fehler, auf den der Nutzer reagieren kann . Behalten Sie zwei Profile, wenn das Deployment beide Transporte anbietet, und kennzeichnen Sie sie, damit der Support erkennt, welches versucht wurde. Die Portnummer allein beschreibt den Transport nicht.
Firewall-Regeln folgen derselben Trennung: Eine Regel für UDP 1194 sagt nichts über TCP 1194, und eine Regel für eine Adresse deckt den anderen Listener nicht ab.
Lesen Sie zuerst die Sicht des Servers
Beginnen Sie mit ss -lntup auf dem Server und bestätigen Sie, dass sowohl ein TCP- als auch ein UDP-Listener erscheinen. Verbinden Sie dann je einen Client beider Arten und prüfen Sie die Statusausgabe auf zwei Einträge mit unterschiedlichen Adressen. Existieren die Sockets und kommt kein Client, weist der Pfad oder die Firewall Pakete ab, bevor der Daemon sie sieht.
Ein Socket, der nie erscheint, ist ein Konfigurations- oder Bindeproblem, und ein Socket, der erscheint, aber nie eine Verbindung protokolliert, ist ein Filterproblem. Vom Client aus sehen beide identisch aus, deshalb kommt die Sicht des Servers zuerst. Beachten Sie, dass TCP Head-of-Line-Blocking mitbringt, sodass sein Angebot eine Erreichbarkeitsmaßnahme ist und kein Upgrade für Clients mit sauberem UDP-Pfad.