Braucht jeder OpenVPN-Peer eine remote-Zeile? Nicht unbedingt
remote nennt, wohin das erste Paket geht; es legt nicht die Client-, Server- oder TLS-Rolle fest. Lesen Sie die Anordnung, bevor Sie sie auf beide Seiten kopieren.
Zwei Peer-Konfigurationen werden nebeneinander verglichen, die eine hat eine remote-Zeile und die andere nicht, und die Schlussfolgerung ist, dass eine von ihnen defekt ist. Diese Folgerung ist oft genug falsch, um sie auseinanderzunehmen. Die Direktive beschreibt, wohin das erste Paket gesendet werden soll. Sie wählt nicht aus, ob der Prozess als initiierender Client oder als wartendes Gateway agiert, und sie entscheidet nicht, welche Seite ihre Identität gegenüber der anderen nachweist.
Was remote tatsächlich festlegt
Ein remote-Eintrag nennt einen Host, optional einen Port und ein Transportprotokoll und optional mehrere solche Einträge, die der Reihe nach versucht werden.
Sein Fehlen hat eine definierte und keine undefinierte Bedeutung: Der Prozess wartet und reagiert nicht auf Pakete von einer Adresse, es sei denn, dieser Peer authentifiziert sich. Ein Gateway, das Roaming-Nutzer bedient, hat daher keinen Grund, einen von ihnen im Voraus zu nennen.
Lesen Sie den Eintrag als Adressbeziehung. Ob dem Gegenüber zu vertrauen ist, beantworten Zertifikate und die Verifikationsoptionen, nicht die Tatsache, dass eine Adresse niedergeschrieben wurde.
Drei Anordnungen entscheiden die Antwort
Ein Roaming-Client braucht ein Ziel, weil er initiieren muss und ohne eines nicht weiß, wo das Gateway ist. Ein Multi-Client-Gateway braucht kein Ziel pro Nutzer, weil Clients ankommen und sich authentifizieren. Eine bewusste Zwei-Peer-Verbindung mit bekannten Endpunkten kann auf einer Seite, auf beiden Seiten oder auf keiner ein Ziel haben, je nachdem, welche Seite initiiert.
Eine feste Client-Adresse in ein allgemeines Gateway einzufügen ist der Fehler, der aus dem Ignorieren dieser Kategorien folgt. Er funktioniert für den einen Peer, dessen Adresse erfasst wurde, und führt alle anderen in die Irre.
Nichts an der Direktive macht eine Konfiguration zu einem Multi-Client-Server, und nichts an ihrer Anwesenheit verhindert eine Serverrolle. Die OpenVPN-2.6-Referenz dokumentiert die optionalen Argumente und das Verhalten ohne remote getrennt, was ein Hinweis darauf ist, wie unabhängig sie sind.
| Arrangement | Needs a destination |
|---|---|
| Roaming client | Yes, which gateway to contact |
| Multi-client gateway | No, peers authenticate on arrival |
| Two known peers | Depends on which side initiates |
Transportrollen sind eine andere Achse
Bei TCP wartet die eine Seite und die andere wählt. Das sind getrennte Direktiven vom Ziel, und ihre Vermischung erzeugt ein Paar, bei dem beide warten oder beide wählen.
Es gibt auch eine TCP-Quellfilterrolle, weshalb die pauschale Aussage, ein Server dürfe niemals remote enthalten, falsch ist.
Bei UDP gibt es keine Verbindung aufzubauen, also nutzen beide Enden den entsprechenden UDP-Transport, und die Direktive sagt nur, wohin gezielt wird. Adressänderungen eines authentifizierten Peers werden durch eigenes Verhalten behandelt und nicht durch weitere Einträge. Den Transport richtig zu haben ist Voraussetzung dafür, dass das Ziel etwas bedeutet, und die beiden zu verwechseln erzeugt Konfigurationen, die plausibel aussehen und nie einen Handshake abschließen.
Warum ein fehlendes remote keine offene Tür ist
Ein Prozess ohne Ziel weist trotzdem Verkehr von Peers ab, die sich nicht authentifizieren, und das ist der Teil, den Leute übersehen, wenn sie die fehlende Zeile als einen für jeden offenen Listener lesen.
Authentifizierung und Ziel sind unabhängig, und ersteres ist das, was für Vertrauen zählt.
Der umgekehrte Fehler ist gefährlicher. Eine feste Quelladresse kann sich wie eine Zugangskontrolle anfühlen, weil sie konkret und leicht zu prüfen ist, aber sie beweist nichts darüber, wer am anderen Ende sitzt. Behalten Sie die Zertifikatsprüfung und die Identitätsprüfungen, die ein Zertifikat an seine Rolle binden. Sie durch einen Adressabgleich zu ersetzen tauscht eine echte Kontrolle gegen den Anschein einer solchen.
Schreiben Sie auf, was die Konfiguration voraussetzt
Notieren Sie für jede Seite drei Dinge: wie das erste Paket den Peer erreicht, welche Seite den Transport annehmen kann und was jede Seite über die andere prüft.
Diese Annahmen sind das Design. Die Direktiven sind nur ihre Schreibweise.
Wenn die beiden Dateien sich unterscheiden, prüfen Sie, ob sie unterschiedliche Annahmen ausdrücken, statt anzunehmen, dass eine falsch ist. Ein symmetrisches Dateipaar ist für einen funktionierenden Tunnel weder notwendig noch hinreichend, und die Asymmetrie ist oft der Teil, der eine Topologie funktionieren lässt.