Ich habe zwei Clients, die eine Verbindung zu einem OpenVPN-Server herstellen müssen. Ist es möglich, im ifconfig-Parameter für beide Clients dasselbe Gateway zu verwenden?
Client A config file
[...]
ifconfig 10.0.0.2 10.0.0.1
Client B config file
[...]
ifconfig 10.0.0.3 10.0.0.1
Die Situation auf dem Server ist folgende:
tun0
inet 10.10.0.1 destination 10.10.0.2
tun1
inet 10.10.0.1 destination 10.10.0.3
Jetzt funktioniert alles gut, aber könnte es mit der Zeit zu Problemen kommen?
Mir wurde gesagt, ich solle ein anderes Gateway verwenden, und zwar dieses:
Client A config file
[...]
ifconfig 10.0.0.2 10.0.0.1
Client B config file
[...]
ifconfig 10.0.1.2 10.0.1.1
Ich dachte jedoch, dass nur für Routing-Zwecke unterschiedliche Gateways erforderlich sind. Wenn ich eine Route hinzufügen und meinen Datenverkehr an eine bestimmte Tun-Schnittstelle weiterleiten möchte, brauche ich tatsächlich ein anderes Gateway, oder der Server weiß nicht, an welches er die Pakete senden soll. Kann ich aber meine erste Konfiguration verwenden, wenn ich keine bestimmte Route benötige?
Danke
Antwort1
Das ist möglich und richtig. Der Gateway-Parameter definiert die Konfiguration auf dem Client, der zum Senden von Daten an das VPN verwendet wird, damit das Routing wie bei IP üblich definiert werden kann. Sobald das Paket an den OpenVPN-Prozess gesendet wurde, kümmert sich dieser um dessen Routing (bis es einen anderen OpenVPN-Prozess verlässt).
Insbesondere definieren Sie:
ifconfig 10.10.0.3 10.10.0.1
DernurDas Ergebnis dieses Befehls ist, als würden Sie die folgenden Befehle auf dem Client ausführen:
ip address add 10.10.0.3 dev tun0
ip route add 10.10.0.1 dev tun0
Das ist alles. Andere Clients, ein Server, externe Systeme – niemand sonst weiß von dieser Client-Konfiguration.
Das Gateway wird nur zum Schreiben von Routen zum VPN verwendet, und zwar wie folgt:
ip route add 192.168.0.0/24 via 10.10.0.1
z. B. um dieses Netzwerk so einzurichten, dass es über VPN erreichbar ist. So wird beispielsweise die Route zum VPN-Server und zu anderen Clients erstellt. Wenn Sie mehrere Clients haben, können Sie natürlich dieselbe Gateway-Adresse für sie verwenden (und das tun Sie natürlich beispielsweise für benachbarte Computer im selben LAN).
Dasselbe gilt auch für einen Server. Ich betreibe beispielsweise mehrere VPNs auf einer einzigen Maschine (eines über UDP, das andere über TCP auf Port 443 mit Port-Share-Option – um durch Firewalls zu gelangen, die normale Ports blockieren, aber 443 zulassen, und sogar zu prüfen, ob ein Webserver vorhanden ist). Diese Server haben beide die gleichelokalAdresse konfiguriert und unterscheiden sich durchFernbedienung(dadurch kann ich festlegen, über welches VPN ich Pakete weiterleite).
Nun zu den Problemen, auf die Sie stoßen werden. Mit vollwertigem Linux OpenVPN gibt es natürlich keine Probleme. Wenn Sie „OpenVPN-Client“ verwenden, sei es Linux, Windows, iOS/iPadOS/macOS oder Android-Client, hängt es davon ab, was topologySie einstellen. In net30der Topologie werden sie eine solche Konfiguration als ungültig ablehnen. In diesem Fall sollten die Clientadresse und ihr Remote zum selben /30-Subnetz gehören.
Antwort2
Normalerweise benötigt eine Punkt-zu-Punkt-Schnittstelle wie tun0oder jede andere tunnelartige Schnittstelle eine lokale Adresse nur für Tunnelverwaltungszwecke oder eine bestimmte Tunnelidentifikation.
Stellen Sie sich eine Tunnelschnittstelle als einen Remote-Endpunkt vor. Diese Schnittstelle hat zwei Enden - Sie unddas andere Ende. Im Allgemeinen besteht keine Notwendigkeit,beliebigAdressen auf Schnittstellen wie dieser, wenn nur zwei verbundene Parteien am Datenaustausch beteiligt sind – Sie können einfach ein Paket über diese Schnittstelle senden und es wird an das andere Ende übermittelt, einen anderen Weg gibt es nicht.
Die Dinge werden etwas komplizierter, wenn ein Dritter in der Lage sein muss, Ihren Remote-Endpunkt zu erreichen. Um zu diesem Endpunkt zu gelangen, benötigen sie einenRemote-Adresseals Paketziel. Die Gegenseite hingegen verwendet Ihre lokale Adresse, um ihre Version desdas andere Endewenn es nötig ist, d. h. es installiert die Standardroute dorthin. Es könnte jedoch auch die Tunnelschnittstelle selbst als Routenziel verwenden, ohne Ihre lokale Adresse zu kennen, und es würde trotzdem funktionieren.
Sofern Sie Ihre Tunnelschnittstelle nicht über ihren lokalen Endpunkt identifizieren müssen (um sie also als Quelladresse für bestimmte dynamische Routing-Protokoll-Szenarien über den Tunnel zu verwenden), können Sie jede beliebige Adresse als lokale Adresse im Tunnel verwenden – sie muss sich nicht einmal im selben Subnetz wie die Remote-Adresse befinden.