25
Routing zw. 2 Tunneln auf EINEM openVPN-Server
Ich betreibe einen Server, auf dem zwei openVPN-Tunnel laufen. Hinter jedem Tunnel hängt ein lokales Netz, welches jeweils komplett durch den Tunnel ins Internet geleitet wird. Einmal der IP-Bereich 192.168.178.x (tun1) und einmal 192.168.179.X (tun0). Nach außen haben also beide lokalen Netze die gleiche IP.
Die Netzwerke hinter den beiden Tunneln sollen strikt getrennt sein und es soll von dem einen Netz kein Zugriff auf das andere möglich sein, was auch soweit klappt. Nun gibt es aber einen PC (192.168.178.12) auf den auf dem Port 5800 auch aus dem Netz 192.168.179.X zugegriffen werden soll. Das bekomme ich nicht auf die Reihe. Ich habe eine iptables-Regel ausprobiert, mit der es meiner Meinung nach klappen sollte, aber das klappt leider nicht:
iptables -I FORWARD -s 10.8.0.0/24 -p tcp --dport 5800 -d 192.168.178.12 -j ACCEPT
Mache ich traceroute 192.168.178.12, kommt folgendes bei raus:
Es scheint also so, als würde die Anfrage aus dem openVPN-Server heraus ins Internet gehen.
Für Hilfestellungen wäre ich sehr dankbar. Sorry, wenn die Informationen nicht ausreichen sollten. Wenn ihr mir sagt, was ihr braucht, liefere ich den Rest natürlich nach.
Die Netzwerke hinter den beiden Tunneln sollen strikt getrennt sein und es soll von dem einen Netz kein Zugriff auf das andere möglich sein, was auch soweit klappt. Nun gibt es aber einen PC (192.168.178.12) auf den auf dem Port 5800 auch aus dem Netz 192.168.179.X zugegriffen werden soll. Das bekomme ich nicht auf die Reihe. Ich habe eine iptables-Regel ausprobiert, mit der es meiner Meinung nach klappen sollte, aber das klappt leider nicht:
iptables -I FORWARD -s 10.8.0.0/24 -p tcp --dport 5800 -d 192.168.178.12 -j ACCEPT
Mache ich traceroute 192.168.178.12, kommt folgendes bei raus:
traceroute to 192.168.178.12 (192.168.178.12), 64 hops max, 52 byte packets
1 192.168.179.4 (192.168.179.4) 1.290 ms 0.617 ms 0.565 ms
2 10.8.0.1 (10.8.0.1) 5.238 ms 5.073 ms 4.968 ms
3 defra-pvz09.dnwx.de (134.255.237.19) 5.047 ms 5.131 ms 4.978 ms
4 ae0-483.fra10.core-backbone.com (81.95.2.225) 5.456 ms 5.495 ms 5.717 msEs scheint also so, als würde die Anfrage aus dem openVPN-Server heraus ins Internet gehen.
Für Hilfestellungen wäre ich sehr dankbar. Sorry, wenn die Informationen nicht ausreichen sollten. Wenn ihr mir sagt, was ihr braucht, liefere ich den Rest natürlich nach.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 665606
Url: https://administrator.de/contentid/665606
Ausgedruckt am: 22.11.2024 um 02:11 Uhr
25 Kommentare
Neuester Kommentar
Deine Regel kann ja nicht stimmen ! Sie besagt ja das alles was eine Absender IP 10.8.0.x mit Port TCP 5800 auf die Ziel IP 192..168.178.12 zugreifen kann.
Das steht ja im völligen Gegensatz zu dem was du oben schreibst, denn dort gibst du an das alle Rechner mit der Absender IP 192.168.179.x auf diesen Rechner zugreifen soll. Damit wäre dann die o.a. Regel unsinnig, denn sie definiert ja die völlig falsche Source IP. Was stimmt denn nun ??
Oder fummelst du in diesem Netz unnötigerweise mit NAT (IP Adress Translation) im Tunnel rum ?
Dort kann man sehen das die VPN Pakete gar nicht im Tunnel bleiben sondern ins öffentliche Internet gehen. Da stimmt also schon generell mal was mit deinem internen IP Routing nicht ! Interner Traffic sollte doch niemals ins Internet geroutet werden !! Aber ohne deine OVPN Konfig Files zu kennen ist das alles freie Raterei und "Shooting into the dark".... Weisst du auch selber.
Ansonsten einmal ins hiesige OpenVPN Tutorial sehen:
Merkzettel: VPN Installation mit OpenVPN
bzw. bei Site to Site:
OpenVPN - Erreiche Netzwerk hinter Client nicht
Dort steht alles was du zu dem Thema wissen musst.
Das steht ja im völligen Gegensatz zu dem was du oben schreibst, denn dort gibst du an das alle Rechner mit der Absender IP 192.168.179.x auf diesen Rechner zugreifen soll. Damit wäre dann die o.a. Regel unsinnig, denn sie definiert ja die völlig falsche Source IP. Was stimmt denn nun ??
Oder fummelst du in diesem Netz unnötigerweise mit NAT (IP Adress Translation) im Tunnel rum ?
Mache ich traceroute 192.168.178.12, kommt folgendes bei raus:
Uuuhhh wie gruselig... !!Dort kann man sehen das die VPN Pakete gar nicht im Tunnel bleiben sondern ins öffentliche Internet gehen. Da stimmt also schon generell mal was mit deinem internen IP Routing nicht ! Interner Traffic sollte doch niemals ins Internet geroutet werden !! Aber ohne deine OVPN Konfig Files zu kennen ist das alles freie Raterei und "Shooting into the dark".... Weisst du auch selber.
Ansonsten einmal ins hiesige OpenVPN Tutorial sehen:
Merkzettel: VPN Installation mit OpenVPN
bzw. bei Site to Site:
OpenVPN - Erreiche Netzwerk hinter Client nicht
Dort steht alles was du zu dem Thema wissen musst.
Hallo,
was mir nicht klar ist - hat der VPN-Server auch einen Client?
Grüße
lcer
was mir nicht klar ist - hat der VPN-Server auch einen Client?
Grüße
lcer
Anhand der (FritzBox) IP Adressierung und Schilderung mit dem Wort "Netze" würde ich mal auf ein Site-to-Site Design tippen...?!
Hallo,
danke für eure Rückmeldung. Ich versuche euch mal mit allen noch fehlenden Informationen zu versorgen.
- in jedem der beiden lokalen Netze befindet sich ein openVPN-Client (Raspberry Pi).
- Wenn ich Side-to Side richtig verstanden habe, ist das genau das, was ich gerade versuche umzusetzen.
- Bzgl. der IP in iptables habe ich dann wohl was falsch verstanden. Ich dachte, dass ich mit der IP 10.8.0.0/24 alle Rechner die tun0 benutzen auf dem entsprechenden Port auf den einen Rechner zugreifen lasse. Egal, welche lokale IP in dem Netz eingestellt ist. Denn hier war der Gedanke, wenn in dem lokalen Netz der IP-Raum umgestellt wird, muss ich nichts neu konfigurieren. Ziel ist es aus dem Netz 192.168.179.X auf den Rechner 192.168.178.12 zuzugreifen. NAT verwende ich auf dem VPN-Server wie folgt:
Im VPN-Client nutze ich nat so:
Das der interne Netzverkehr im Tunnel bleiben soll, ist mir klar. Hier mal die opvpn.conf beider Tunnel:
Bei traceroute hatte ich zuletzt vom falschen Rechner geprüft. traceroute vom richtige Rechner sieht so aus:
Mehr kommt nicht mehr. Also ich denke, es liegt daran, dass der Einstieg von dem einen in den anderen Tunnel nicht klappt, oder?
danke für eure Rückmeldung. Ich versuche euch mal mit allen noch fehlenden Informationen zu versorgen.
- in jedem der beiden lokalen Netze befindet sich ein openVPN-Client (Raspberry Pi).
- Wenn ich Side-to Side richtig verstanden habe, ist das genau das, was ich gerade versuche umzusetzen.
- Bzgl. der IP in iptables habe ich dann wohl was falsch verstanden. Ich dachte, dass ich mit der IP 10.8.0.0/24 alle Rechner die tun0 benutzen auf dem entsprechenden Port auf den einen Rechner zugreifen lasse. Egal, welche lokale IP in dem Netz eingestellt ist. Denn hier war der Gedanke, wenn in dem lokalen Netz der IP-Raum umgestellt wird, muss ich nichts neu konfigurieren. Ziel ist es aus dem Netz 192.168.179.X auf den Rechner 192.168.178.12 zuzugreifen. NAT verwende ich auf dem VPN-Server wie folgt:
iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source <ext. IP VPN-Server>
iptables -t nat -A POSTROUTING -o venet0 -s 10.8.1.0/24 -j SNAT --to-source <ext. IP VPN-Server>iptables -t nat -A POSTROUTING -o tun1 -j MASQUERADEDas der interne Netzverkehr im Tunnel bleiben soll, ist mir klar. Hier mal die opvpn.conf beider Tunnel:
tun0:
local xxx.xxx.xxx.xxx
port 443
proto udp
dev tun
ca ./easy-rsa2/keys/ca.crt
cert ./easy-rsa2/keys/server.crt
key ./easy-rsa2/keys/server.key
dh ./easy-rsa2/keys/dh4096.pem
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 77.109.148.136"
push "dhcp-option DNS 77.109.148.137"
keepalive 10 120
tls-auth ./easy-rsa2/keys/ta.key 0
cipher AES-256-CBC
comp-lzo
max-clients 15
user openvpn
group openvpn
persist-key
persist-tun
log-append /var/log/openvpn.log
verb 3
tun1:
local xxx.xxx.xxx.xxx
port 1194
proto udp
dev tun
ca ./easy-rsa2/keys/ca.crt
cert ./easy-rsa2/keys/server.crt
key ./easy-rsa2/keys/server.key
dh ./easy-rsa2/keys/dh4096.pem
server 10.8.1.0 255.255.255.0
client-config-dir ccd
ifconfig-pool-persist ./logs/ipp_2.txt
route 192.168.178.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 77.109.148.136"
push "dhcp-option DNS 77.109.148.137"
client-to-client
keepalive 10 120
tls-auth ./easy-rsa2/keys/ta.key 0
cipher AES-256-CBC
comp-lzo
max-clients 15
user openvpn
group openvpn
persist-key
persist-tun
log-append /var/log/openvpn_2.log
verb 0Bei traceroute hatte ich zuletzt vom falschen Rechner geprüft. traceroute vom richtige Rechner sieht so aus:
traceroute to 192.168.178.12 (192.168.178.12), 30 hops max, 60 byte packets
1 10.8.0.1 (10.8.0.1) 11.631 ms 16.576 ms 16.617 msMehr kommt nicht mehr. Also ich denke, es liegt daran, dass der Einstieg von dem einen in den anderen Tunnel nicht klappt, oder?
in jedem der beiden lokalen Netze befindet sich ein openVPN-Client (Raspberry Pi).
Also exakt das Setup hier, richtig ?!OpenVPN - Erreiche Netzwerk hinter Client nicht
Was etwas wirr ist deine OpenVPN Konfig. Normal lässt man die zentrale Site als Server laufen und die beiden Locations als Clients so wie es im obigen Beispiel zu sehen ist.
Was du da machst ist schon recht schräg, vermutlich 2 getrennte OpenVPN Instanzen laufen zu lassen ?!
Das ist recht unüblich und lässt so ein bischen vermuten das das eher ohne Plan und Kentniss der OVPN Gegebenheiten umgesetzt wurde.
Auch das beides mal mit einem Gateway Redirect gearbeitet wurde ist schon sehr fragwürdig.
So eine Konfig ist jedenfalls nicht der Weg wie man es richtig macht bzw. wie OpenVPN grundsätzlich designt ist...
Stell dir mal vor jemand hätte 10 Außenstellen. Da würdest du dann wirklich 10 separate Instanzen auf dem Server laufen lassen ??
Besser ist du überdenkst da nochmal dein gesamtes VPN Konzept ?!
Das ganze ist damals so entstanden, weil eine Instanz mit einem einzigen lokalen Netz lief, und ein zweites lokales Netz hinzu kommen musste. Von einem Netz sollte man nicht in das anderen gelangen.
Da erschien es am besten zwei Instanzen zu erstellen. Ich gebe dir Recht, damals waren wir komplett am Anfang mit solchen Sachen. Inzwischen ist der Background etwas gewachsen, aber noch nicht ausreichend groß, um zu verstehen, wie das mit einer Instanz getrennt aufgebaut werden kann.
Das von dir verlinkte Bild kommt in etwa hin. Der Unterschied besteht eigentlich nur darin, dass jedes lokale Netz einen im Grunde gleich konfigurierten VPN Client hat, und der VPN Server ein angemieteter Rechner irgendwo im Internet ist. Wir haben also links im lokalen Netz Client 1 und rechts Client 2. Dazwischen im Internet steht der Server.
Ich habe mir deine Anleitung durchgelesen. Das setzt voraus, dass alle lokalen Netze einen eigenen IP-Raum haben, oder? Bei uns hängt noch ein drittes Netzt in dem Tunnel mit drin, an dem das lokale Nutz mit dem IP-Raum 192.168.179.X angeschlossen ist. Dieses Netz spielte bei meinem ursprünglichen Problem keine Rolle, nutzt aber ebenfalls den IP-Raum 192.168.178.X. Dieses Netz müsste dann wahrscheinlich komplett umgebaut werden. Wie gesagt, das ganze ist über längere Zeit gewachsen und war in der Form so am Anfang natürlich nicht angedacht.
Da erschien es am besten zwei Instanzen zu erstellen. Ich gebe dir Recht, damals waren wir komplett am Anfang mit solchen Sachen. Inzwischen ist der Background etwas gewachsen, aber noch nicht ausreichend groß, um zu verstehen, wie das mit einer Instanz getrennt aufgebaut werden kann.
Das von dir verlinkte Bild kommt in etwa hin. Der Unterschied besteht eigentlich nur darin, dass jedes lokale Netz einen im Grunde gleich konfigurierten VPN Client hat, und der VPN Server ein angemieteter Rechner irgendwo im Internet ist. Wir haben also links im lokalen Netz Client 1 und rechts Client 2. Dazwischen im Internet steht der Server.
Ich habe mir deine Anleitung durchgelesen. Das setzt voraus, dass alle lokalen Netze einen eigenen IP-Raum haben, oder? Bei uns hängt noch ein drittes Netzt in dem Tunnel mit drin, an dem das lokale Nutz mit dem IP-Raum 192.168.179.X angeschlossen ist. Dieses Netz spielte bei meinem ursprünglichen Problem keine Rolle, nutzt aber ebenfalls den IP-Raum 192.168.178.X. Dieses Netz müsste dann wahrscheinlich komplett umgebaut werden. Wie gesagt, das ganze ist über längere Zeit gewachsen und war in der Form so am Anfang natürlich nicht angedacht.
Ich hab jetzt mal nach der Anleitung von aqui versucht eine config für den Server und zwei Clients umzusetzen. Ziel soll es sein, die Netze 192.168.178.X und 192.168.179.X auf eine Instanz zu bringen. Wenn das läuft, soll auch das andere Netz umgestellt werden. Hier mal ein Vorschlag für die config-files:
Ich hab die beiden configs mal getestet. Die config für Client1 (192.168.178.X) klappt, aber diese drei Zeilen machen auf dem Server Probleme:
In der syslog steht dann:
#Server:
local XXX.XXX.XXX.XXX
port XXX
proto udp4
dev tun
ca ./easy-rsa2/keys/ca.crt
cert ./easy-rsa2/keys/server.crt
key ./easy-rsa2/keys/server.key
dh ./easy-rsa2/keys/dh4096.pem
topology subnet
push "topology subnet"
explicit-exit-notify 1
server 10.8.1.0 255.255.255.0
client-config-dir ccd
ifconfig-pool-persist ./logs/ipp_2.txt
route 192.168.178.0 255.255.255.0
route 192.168.179.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 77.109.148.136"
push "dhcp-option DNS 77.109.148.137"
client-to-client
keepalive 10 120
tls-auth ./easy-rsa2/keys/ta.key 0
cipher AES-256-CBC
max-clients 15
user openvpn
group openvpn
persist-key
persist-tun
log-append /var/log/openvpn_2.log
verb 0
#Client 1 und 2:
client
dev tun
proto udp4
remote XXX.XXX.XXX.XXX XXX
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client-key1.crt #bzw. client-key2.crt
key client-key1.key #bzw. client-key2.key
remote-cert-tls server
auth-nocache
tls-auth ta.key 1
cipher AES-256-CBC
verb 3
script-security 2
setenv PATH /usr/bin
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
redirect-gatewayIch hab die beiden configs mal getestet. Die config für Client1 (192.168.178.X) klappt, aber diese drei Zeilen machen auf dem Server Probleme:
topology subnet
push "topology subnet"
explicit-exit-notify 1In der syslog steht dann:
Apr 11 23:18:50 openVPN systemd[1]: openvpn@server.service: Control process exited, code=exited status=1
Apr 11 23:18:50 openVPN systemd[1]: Failed to start OpenVPN connection to server.
Apr 11 23:18:50 openVPN systemd[1]: openvpn@server.service: Unit entered failed state.
Apr 11 23:18:50 openVPN systemd[1]: openvpn@server.service: Failed with result 'exit-code'.
Apr 11 23:18:50 openVPN ovpn-server[931]: Linux ip addr del failed: external program exited with error status: 2
Du willst doch eigentlich keine Client to Client Kommunikation. Warum aktivierst du das dann ?? Besser also weglassen.
Nochmal eine Frage vorab: Welchen Sinn hat es das du mit Gateway Redirect arbeitest und sämtlichen Traffic in den Tunnel routest ? Was ist da deine Intention ? Split Tunneling wäre doch viel sinnvoller, zumal ja sicher in den jeweiligen Locations eh bei allen Clients der Internet Router als Default Gateway eingetragen ist. Ein Gateway Redirect im OpenVPN wäre damit dann doch so oder so nutzlos ?!
Nur um Mal deine Intention dazu zu verstehen...
Der o.a. Fehler rührt vermutlich daher weil du vergessen hast für beide Client eine spezifische Konfig (Common Name) im Directory /etc/openvpn/ccd zu hinterlegen, kann das sein ? Jedenfalls erwähnst du es oben leider mit keinem Wort ?!
Im /ccd Verzeichnis müssen 2 Dateien stehen. Einmal "client1" und einmal "client2" wobei diese Namen immer identisch sein müssen zum konfigurierten Common Name des Clients.
"client 1" hat den Inhalt:
ifconfig-push 10.8.1.2 255.255.255.0
iroute 192.168.178.0 255.255.255.0
"client 2" hat den Inhalt:
ifconfig-push 10.8.1.3 255.255.255.0
iroute 192.168.179.0 255.255.255.0
Das bestimmt pro Client welche feste IP der im internen OVPN Netzwerk bekommt und welche Route zum lokalen IP Netz dahinter liegt. Bzw. das muss mit deinen Zuweiungen in der ipp2.txt übereinstimmen. Diese Pool Geschichte solltest du besser weglassen wenn du statisch routest.
Nur mal nebenbei: Hast du mal überlegt das mit WireGuard zu lösen ? Erheblich einfachere Konfig, bessere Filter Optionen und erheblich bessere VPN Performance:
Merkzettel: VPN Installation mit Wireguard
Nochmal eine Frage vorab: Welchen Sinn hat es das du mit Gateway Redirect arbeitest und sämtlichen Traffic in den Tunnel routest ? Was ist da deine Intention ? Split Tunneling wäre doch viel sinnvoller, zumal ja sicher in den jeweiligen Locations eh bei allen Clients der Internet Router als Default Gateway eingetragen ist. Ein Gateway Redirect im OpenVPN wäre damit dann doch so oder so nutzlos ?!
Nur um Mal deine Intention dazu zu verstehen...
Der o.a. Fehler rührt vermutlich daher weil du vergessen hast für beide Client eine spezifische Konfig (Common Name) im Directory /etc/openvpn/ccd zu hinterlegen, kann das sein ? Jedenfalls erwähnst du es oben leider mit keinem Wort ?!
Im /ccd Verzeichnis müssen 2 Dateien stehen. Einmal "client1" und einmal "client2" wobei diese Namen immer identisch sein müssen zum konfigurierten Common Name des Clients.
"client 1" hat den Inhalt:
ifconfig-push 10.8.1.2 255.255.255.0
iroute 192.168.178.0 255.255.255.0
"client 2" hat den Inhalt:
ifconfig-push 10.8.1.3 255.255.255.0
iroute 192.168.179.0 255.255.255.0
Das bestimmt pro Client welche feste IP der im internen OVPN Netzwerk bekommt und welche Route zum lokalen IP Netz dahinter liegt. Bzw. das muss mit deinen Zuweiungen in der ipp2.txt übereinstimmen. Diese Pool Geschichte solltest du besser weglassen wenn du statisch routest.
Nur mal nebenbei: Hast du mal überlegt das mit WireGuard zu lösen ? Erheblich einfachere Konfig, bessere Filter Optionen und erheblich bessere VPN Performance:
Merkzettel: VPN Installation mit Wireguard
Zunächst mal herzlichen dank für deine Hilfe!!
Stimmt, client-to-client ist Blödsinn. Hab ich rausgenommen.
Gateway Redirect ist wahrscheinlich ein Relict aus den Anfängen. Ziel war es, wie du schon richtig erkannt hast, automatisch allen Traffic durch den Tunnel zu schicken. Daher war das wohl eingestellt. Aber wie du auch richtig vermutest, ist der Raspberry mein DHCP-Server und auch das Default Gateway. Somit geht alles automatisch durch den Tunnel. Also fliegt Gateway Redirect ebenfalls raus. Ich habe also im Server "push "redirect-gateway def1 bypass-dhcp"" und im Client "redirect-gateway" entfernt. Wenn ich allerdings im Server "push "redirect-gateway def1 bypass-dhcp"" entferne startet der VPN nicht mehr, also ist das scheinbar notwendig.
Die Dateien in /etc/openvpn/ccd hatte ich schon angelegt, aber offenbar falsch. Dort stand statt "ifconfig-push 10.8.1.5 255.255.255.0" "ifconfig-push 10.8.1.5 10.8.1.4". Auf meinem Handy läuft auch OpenVPN, damit ich von unterwegs in mein Netz komme. Das heißt für jedes Gerät, dass sich außerhalb des Netzes befindet, und das über die Software in das lokale Netz will, muss ebenfalls einen solche Datei angelegt werden. Richtig?
Die Fehler:
Werden wohl von dieser Zeile ausgelöst:
Ich würde gerne bei OpenVPN bleiben, weil ich mich damit nun schon ein wenig auseinandergesetzt habe. Außerdem möchte ich es auch gerne etwas genauer verstehen.
Stimmt, client-to-client ist Blödsinn. Hab ich rausgenommen.
Gateway Redirect ist wahrscheinlich ein Relict aus den Anfängen. Ziel war es, wie du schon richtig erkannt hast, automatisch allen Traffic durch den Tunnel zu schicken. Daher war das wohl eingestellt. Aber wie du auch richtig vermutest, ist der Raspberry mein DHCP-Server und auch das Default Gateway. Somit geht alles automatisch durch den Tunnel. Also fliegt Gateway Redirect ebenfalls raus. Ich habe also im Server "push "redirect-gateway def1 bypass-dhcp"" und im Client "redirect-gateway" entfernt. Wenn ich allerdings im Server "push "redirect-gateway def1 bypass-dhcp"" entferne startet der VPN nicht mehr, also ist das scheinbar notwendig.
Die Dateien in /etc/openvpn/ccd hatte ich schon angelegt, aber offenbar falsch. Dort stand statt "ifconfig-push 10.8.1.5 255.255.255.0" "ifconfig-push 10.8.1.5 10.8.1.4". Auf meinem Handy läuft auch OpenVPN, damit ich von unterwegs in mein Netz komme. Das heißt für jedes Gerät, dass sich außerhalb des Netzes befindet, und das über die Software in das lokale Netz will, muss ebenfalls einen solche Datei angelegt werden. Richtig?
Die Fehler:
Apr 12 18:10:12 openVPN systemd[1]: openvpn@server2.service: Control process exited, code=exited status=1
Apr 12 18:10:12 openVPN systemd[1]: Failed to start OpenVPN connection to server2.
Apr 12 18:10:12 openVPN systemd[1]: openvpn@server2.service: Unit entered failed state.
Apr 12 18:10:12 openVPN systemd[1]: openvpn@server2.service: Failed with result 'exit-code'. explicit-exit-notify 1Ich würde gerne bei OpenVPN bleiben, weil ich mich damit nun schon ein wenig auseinandergesetzt habe. Außerdem möchte ich es auch gerne etwas genauer verstehen.
So, jetzt kommen beide Clients über den gleichen Tunnel online. Wie kann ich jetzt definieren, dass alle Rechner aus dem Netz 192.168.179.X den Rechner 192.168.178.12 auf dem Port 5800 erreichen? Alle anderen Zugriffe sollen geblockt werden. Auch das Netz 192.168.178.X soll nicht nach 192.168.179.X gelangen können.
Derzeit erreiche ich keinen Rechner aus dem anderen Netz.
Derzeit erreiche ich keinen Rechner aus dem anderen Netz.
Wenn ich allerdings im Server "push "redirect-gateway def1 bypass-dhcp"" entferne startet der VPN nicht mehr, also ist das scheinbar notwendig.
Nein, das ist NICHT notwendig aber ein Push Kommando fürs Routing entweder mit Gateway Redirect oder Split Tunneling musst du haben bei Site-to-Site sonst funktioniert das Routing nicht. Starten tut der Dienst aber auch ohne das Kommando.muss ebenfalls einen solche Datei angelegt werden. Richtig?
Nein, das ist NICHT richtig. Diese Dateien gelten rein nur für die Clients die eine Site-to-Site Kopplung machen. Logisch, denn die brauchen eine statische IP und die damit verbundene statische Route in ihr lokales Netz.Bei einem rein mobilen Client ist das natürlich nicht erforderlich und die werden dann normal, dynamisch aus dem /24 Pool des internen OVPN IP Netzes bedient. Ganz einfach und logisch...
Werden wohl von dieser Zeile ausgelöst:
Die ist auch nur kosmetisch und kannst du auskommentieren oder entfernen.Derzeit erreiche ich keinen Rechner aus dem anderen Netz.
Die Frage ist wie nach der "Gateway Redirect" Änderung jetzt deine finale Server Konfig aussieht ?? Es ist gut möglich das du die "push route.." Kommandos vergessen hast, damit ist dann kein Routing möglich.Ob das Routing sauber rennt kannst du in den beiden Clients immer selber sehen wenn du dort ip route show eingibst oder netstat -r -n.
In den Clients sollten die Routen für jeweils das Server Netz und das andere Client LAN in den Tunnel gehen.
Die Server Konfig sollte so aussehen (Auszug und Annahme das das OVPN Server Netz im IP Netz 192.168.1.0 /24 liegt !!):
server 10.8.1.0 255.255.255.0
client-config-dir ccd
route 192.168.178.0 255.255.255.0
route 192.168.179.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"
push "dhcp-option DNS 77.109.148.136"
push "dhcp-option DNS 77.109.148.137"
In den Client Konfig Dateien musst du jeweils das remote Netz "pushen" lassen
ifconfig-push 10.8.1.2 255.255.255.0
iroute 192.168.178.0 255.255.255.0
push "route 192.168.179.0 255.255.255.0"
Bzw. bei Client 2
ifconfig-push 10.8.1.3 255.255.255.0
iroute 192.168.179.0 255.255.255.0
push "route 192.168.178.0 255.255.255.0"
Wenn du nun an jedem Client mit ip route show oder netstat -r -n die Routen kontrollierst solltest du sehen das jeder Client sowohl das lokale Server LAN als auch jeweils das LAN des gegenüberliegenden Clients in der Routing Tabelle hat.
Damit ist dann erstmal eine Any zu Any Kommunikation möglich und du kanns den Zugriff sauber testen.
Gut, es ist nicht das was du willst, da du ja eine gesamte Kommunikation der Clientnetze verhindern willst. Das ist dann kein Problem wenn du die Netzwerk Routen in den Clients in Hostrouten veränderst so das nur einzig die beteiligten Rechner in den Client Netzen kommunizieren können niemand anders aber sonst.
Die Client Konfig Dateien sehen dann so aus:
ifconfig-push 10.8.1.2 255.255.255.0
iroute 192.168.178.0 255.255.255.0
push "route 192.168.179.0 255.255.255.0"
Bzw. bei Client 2
ifconfig-push 10.8.1.3 255.255.255.0
iroute 192.168.179.0 255.255.255.0
push "route 192.168.178.12 255.255.255.255"
Du siehst dann mit ip route show oder netstat -r -n jetzt das die Clients im .179er Netz nur noch den .12er Host im .178er Netz kennen...
Das wars...
Danke für die weiteren Hinweise. Ich habe das soweit angepasst. Es bleiben nur noch zwei Fragen:
In der server.conf hast du das eingetragen, weil du angenommen hast, dass der Server im Netz 192.168.1.0 steht:
Mein Server ist aber ein im Internet angemieteter. Welchen IP-Raum statt 192.168.1.0 muss ich dann eintragen? Er gehört ja zu keinem lokalen Netz.
Kann ich den Clients eigene Subnetze zuweisen?
Client1: 10.8.1.0
Client2: 10.8.2.0
Client3: 10.8.3.0
Der Server ist ja eingestellt auf 10.8.1.0
In der server.conf hast du das eingetragen, weil du angenommen hast, dass der Server im Netz 192.168.1.0 steht:
push "route 192.168.1.0 255.255.255.0" Mein Server ist aber ein im Internet angemieteter. Welchen IP-Raum statt 192.168.1.0 muss ich dann eintragen? Er gehört ja zu keinem lokalen Netz.
Kann ich den Clients eigene Subnetze zuweisen?
Client1: 10.8.1.0
Client2: 10.8.2.0
Client3: 10.8.3.0
Der Server ist ja eingestellt auf 10.8.1.0
Hallo,
sonst wird das hier glaube ich nix.
Grüße
lcer
Zitat von @Gerdchen07:
Mein Server ist aber ein im Internet angemieteter. Welchen IP-Raum statt 192.168.1.0 muss ich dann eintragen? Er gehört ja zu keinem lokalen Netz.
Also vielleicht nimmst Du mal den besten Freund des Netzwerkadmins - den Bleistift - und zeichnest Deine Netzwerktopologie mal auf.Mein Server ist aber ein im Internet angemieteter. Welchen IP-Raum statt 192.168.1.0 muss ich dann eintragen? Er gehört ja zu keinem lokalen Netz.
- alle Router
- alle Netzwerksegmente
- alle vergebenen IP-Adressen
sonst wird das hier glaube ich nix.
Grüße
lcer
Bzgl. der getrennten IP-Räume. Das geht doch wahrscheinlich wie folgt:
In den Clientdateien das das folgende:
Bzw. bei Client 2
server 10.8.1.0 255.255.255.0
route 10.8.2.0 255.255.255.0
route 10.8.3.0 255.255.255.0In den Clientdateien das das folgende:
ifconfig-push 10.8.1.1 255.255.255.0
iroute 192.168.178.0 255.255.255.0
push "route 192.168.179.0 255.255.255.0" Bzw. bei Client 2
ifconfig-push 10.8.2.1 255.255.255.0
iroute 192.168.179.0 255.255.255.0
push "route 192.168.178.12 255.255.255.255"
Hallo,
da fehlt jetzt nur noch das OS des Servers. Aber egal, bei Deinem Setup fehlen womöglich die iroute Anweisungen: https://docs.netgate.com/pfsense/en/latest/troubleshooting/openvpn-irout ...
Wenn Du verschiedene Subnetze für mehrere OpenVPN Server verwendest, musst Du auch die Routen für die Tunnel-Subnetze auf die Clients bringen.
Grüße
lcer
da fehlt jetzt nur noch das OS des Servers. Aber egal, bei Deinem Setup fehlen womöglich die iroute Anweisungen: https://docs.netgate.com/pfsense/en/latest/troubleshooting/openvpn-irout ...
Wenn Du verschiedene Subnetze für mehrere OpenVPN Server verwendest, musst Du auch die Routen für die Tunnel-Subnetze auf die Clients bringen.
Grüße
lcer
Betriebsystem ist Ubuntu 16.04.7 LTS.
Du meinst mit fehlender iroute die in der Client Config?
Hier mal noch mal meine aktuelle server.conf:
Eine Client.conf:
Und die dazugehörige Client Config:
Du meinst mit fehlender iroute die in der Client Config?
ifconfig-push 10.8.2.1 255.255.255.0
iroute 10.8.2.0 255.255.255.0
iroute 192.168.179.0 255.255.255.0
push "route 192.168.178.0 255.255.255.0" Wenn Du verschiedene Subnetze für mehrere OpenVPN Server verwendest, musst Du auch die Routen für die Tunnel-Subnetze auf die Clients bringen.
Ich hab doch nur einen Server und aktuell zwei Clients. Du meinst, dass dann auch ein push in die Client Config muss? So?ifconfig-push 10.8.2.1 255.255.255.0
iroute 10.8.2.0 255.255.255.0
push "route 10.8.1.0 255.255.255.0"
iroute 192.168.179.0 255.255.255.0
push "route 192.168.178.0 255.255.255.0" Hier mal noch mal meine aktuelle server.conf:
local XXX.XXX.XXX.XXX
port XXX
proto udp
dev tun
ca ./easy-rsa2/keys/ca.crt
cert ./easy-rsa2/keys/server.crt
key ./easy-rsa2/keys/server.key
dh ./easy-rsa2/keys/dh4096.pem
topology subnet
push "topology subnet"
server 10.8.1.0 255.255.255.0
client-config-dir ccd
route 10.8.2.0 255.255.255.0
route 192.168.178.0 255.255.255.0
route 192.168.179.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 77.109.148.136"
push "dhcp-option DNS 77.109.148.137"
#client-to-client
keepalive 10 120
tls-auth ./easy-rsa2/keys/ta.key 0
cipher AES-256-CBC
max-clients 15
user openvpn
group openvpn
persist-key
persist-tun
log-append /var/log/openvpn_2.log
verb 0 Eine Client.conf:
client
dev tun
proto udp
remote XXX.XXX.XXX.XXX XXX
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client-T-key1.crt
key client-T-key1.key
remote-cert-tls server
auth-nocache
tls-auth ta.key 1
cipher AES-256-CBC
verb 3Und die dazugehörige Client Config:
ifconfig-push 10.8.2.1 255.255.255.0
iroute 10.8.2.0 255.255.255.0
push "route 10.8.1.0 255.255.255.0"
iroute 192.168.179.0 255.255.255.0
push "route 192.168.178.0 255.255.255.0" Mein Server ist aber ein im Internet angemieteter.
OK hattest du leider nicht erwähnt. Dann lässt du das Kommando natürlich komplett weg. Dann gibts nur die push Route Kommandos in den Client spezifischen Konfigs.push "route 10.8.1.0 255.255.255.0"
Das ist Blödsinn, denn das internen OVPN Netz wird immer automatisch gepusht. Den Unsinn kannst du löschen.dass dann auch ein push in die Client Config muss? So?
Wenn du damit die Client spezifische Konfig auf dem Server meinst ist das richtig. Diese beiden Konfig Dateien stehen auf dem Server im Verzeichnis /ccd und NICHT auf dem Client ! Nur das es da keine Missverständnisse gibt...!Die 10.8.2.1 an die Clients zu pushen ist Blödsinn, denn das ist immer die IP die der Server selber hast. Damit schaffst du also heilloses Adress Chaos im internen OVPN Netz. Richtig ist
Client 1 Konfig mit lokalem LAN 192.168.178.0 /24 im Server Verz. /ccd :
ifconfig-push 10.8.1.2 255.255.255.0
iroute 192.168.178.0 255.255.255.0
push "route 192.168.179.0 255.255.255.0"
Client 2 Konfig mit lokalem LAN 192.168.179.0 /24 im Server Verz. /ccd :
ifconfig-push 10.8.1.3 255.255.255.0
iroute 192.168.179.0 255.255.255.0
push "route 192.168.178.0 255.255.255.0"
Denk dran das der Name der Konfig Datei dem des Common Names des Clients entsprechen muss das du im Zertifikat angegeben hast.
Die Datei sorgt dann dafür das der Client 1 mit Common Name xyz die feste interne OVPN IP 10.8.1.2 erhält, die OVPN Route ins lokale .178er Netz im Server aktiviert wird auf die .2er IP und gleichzeitig das .179.0er netz an den Client gepusht wird. Analog dann das gleiche bei Client 2. Fertisch...
Eigentlich doch ein ganz einfaches Prinzip ?!
Noch mal vielen Dank für die Hilfe!! Sorry, ich war sicher erwähnt zu haben, dass der Server im Internet steht. Aber du hast recht, hatte ich nicht. Wenn ich die Regel "push "redirect-gateway def1"" ganz rausnehme, kommen die Rechner hinter dem Client 10.8.2.1 nicht auf meinen Rechner 192.168.178.12 hinter dem Client 10.8.1.1. Also irgendein push muss wohl drin bleiben.
Die Client Configs im ccd-Verzeichnis habe ich genauso angelegt, wie du es beschrieben hast.
Eine Frage hast du wahrscheinlich überlesen. Ich würde die Clients gerne aufteilen in verschiedene IP-Räume.
Server 10.8.1.1
Client1 10.8.1.2
Client2 10.8.2.1
Client3 10.8.3.1
Geht das? Wenn ja, wie?
Die Client Configs im ccd-Verzeichnis habe ich genauso angelegt, wie du es beschrieben hast.
Eine Frage hast du wahrscheinlich überlesen. Ich würde die Clients gerne aufteilen in verschiedene IP-Räume.
Server 10.8.1.1
Client1 10.8.1.2
Client2 10.8.2.1
Client3 10.8.3.1
Geht das? Wenn ja, wie?
Hallo,
So nicht. Aber mit je einem Server(Instanz) pro Client (Server und Client müssen im gleichen/gemeinsamen Tunnel-Subnetz liegen). Dann musst Du aber die Route 10.8.0.0/16 -> 10.8.X.1 auf die Clients pushen. Aber wie @aqui oben schon ausführte - eigentlich so nicht gedacht und wozu auch?
Grüße
lcer
Zitat von @Gerdchen07:
Eine Frage hast du wahrscheinlich überlesen. Ich würde die Clients gerne aufteilen in verschiedene IP-Räume.
Server 10.8.1.1
Client1 10.8.1.2
Client2 10.8.2.1
Client3 10.8.3.1
Geht das? Wenn ja, wie?
Eine Frage hast du wahrscheinlich überlesen. Ich würde die Clients gerne aufteilen in verschiedene IP-Räume.
Server 10.8.1.1
Client1 10.8.1.2
Client2 10.8.2.1
Client3 10.8.3.1
Geht das? Wenn ja, wie?
So nicht. Aber mit je einem Server(Instanz) pro Client (Server und Client müssen im gleichen/gemeinsamen Tunnel-Subnetz liegen). Dann musst Du aber die Route 10.8.0.0/16 -> 10.8.X.1 auf die Clients pushen. Aber wie @aqui oben schon ausführte - eigentlich so nicht gedacht und wozu auch?
Grüße
lcer
OK, danke. Ich dachte, es wird so übersichtlicher. Vor allem zum definieren der iptables.
Kann man alternativ sagen, alle Rechner hinter Client1 haben einen IP-Bereich von 10.8.1.1 bis 10.8.1.10, hinter Client2 von 10.8.1.11 bis 10.8.1.20?
Kann man alternativ sagen, alle Rechner hinter Client1 haben einen IP-Bereich von 10.8.1.1 bis 10.8.1.10, hinter Client2 von 10.8.1.11 bis 10.8.1.20?
Zitat von @Gerdchen07:
OK, danke. Ich dachte, es wird so übersichtlicher. Vor allem zum definieren der iptables.
Das ist Quatsch. Für die Firewall ist nur die Quell-IP (Deine beiden LANs) oder die Ziel-IP relevant. Nicht die IP des Tunnelnetzwerks.OK, danke. Ich dachte, es wird so übersichtlicher. Vor allem zum definieren der iptables.
Oder aber das eingehende Interface. Das ist aber abhängig vom OS des Servers nicht immer komplett für routing und Firewall verfügbar.
https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4 ...
tun devices encapsulate IPv4 or IPv6 (OSI Layer 3) while tap devices encapsulate Ethernet 802.3 (OSI Layer 2).
Mit TAP sollte das Interface routbar und für die Firewall verfügbar sein, mit TUN nicht unbedingt.
Grüße
lcer
PS: wo hast Du eigentlich überall das NAT aktiviert?
NAT nutze ich im Server:
und im Client:
iptables habe ich so formuliert:
iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source <ext. IP VPN-Server>
iptables -t nat -A POSTROUTING -o venet0 -s 10.8.1.0/24 -j SNAT --to-source <ext. IP VPN-Server>und im Client:
iptables -t nat -A POSTROUTING -o tun1 -j MASQUERADEiptables habe ich so formuliert:
iptables -I FORWARD -i tun0 -j ACCEPT
iptables -I FORWARD -o tun0 -j ACCEPT
iptables -I FORWARD -s 10.8.1.0/24 -o tun0 -j DROP
iptables -I FORWARD -s 10.8.1.0/24 -d 192.168.178.0/24 -j DROP
iptables -I FORWARD -s 10.8.1.0/24 -d 192.168.179.0/24 -j DROP
iptables -I FORWARD -s 10.8.1.0/24 -d 192.168.1.0/24 -j DROP
iptables -I FORWARD -s 10.8.1.0/24 -p tcp --dport 5008 -d 192.168.178.12 -j ACCEPT
iptables -I FORWARD -s 10.8.1.5 -d 192.168.178.0/24 -j ACCEPT
iptables -I FORWARD -s 10.8.1.7 -d 192.168.178.0/24 -j ACCEPT
iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source <ext. IP VPN-Server>
iptables -t nat -A POSTROUTING -o venet0 -s 10.8.1.0/24 -j SNAT --to-source <ext. IP VPN-Server>
Hallo,
Das NAT gehört an die Schnittstelle, an der Dein privates Netz in das Öffentliche Netz übergeht. Das wäre das Internet-Interface des Servers. Wozu soll das NAT am Client sein? Du Routest ohne NAT bis zum Server und nur dort brauchst Du NAT.
Deine iptable-Rules in Zeile 8 und 9 passen nicht zu Zeile 4 (First match wins).
Grüße
lcer
Das NAT gehört an die Schnittstelle, an der Dein privates Netz in das Öffentliche Netz übergeht. Das wäre das Internet-Interface des Servers. Wozu soll das NAT am Client sein? Du Routest ohne NAT bis zum Server und nur dort brauchst Du NAT.
Deine iptable-Rules in Zeile 8 und 9 passen nicht zu Zeile 4 (First match wins).
Grüße
lcer
Danke für die weiteren Hinweise!
Die iptables sind doch hierarchisch aufgebaut. Das heißt die Regel in Zeile 4 verbietet erst mal alles. Dann wird in Zeile 8 und 9 explizit definiert, was erlaubt ist. Zumindest funktioniert es auch so, dass nur diese beiden Geräte in das 178er Netz kommen.
Die iptables sind doch hierarchisch aufgebaut. Das heißt die Regel in Zeile 4 verbietet erst mal alles. Dann wird in Zeile 8 und 9 explizit definiert, was erlaubt ist. Zumindest funktioniert es auch so, dass nur diese beiden Geräte in das 178er Netz kommen.
Das NAT gehört an die Schnittstelle, an der Dein privates Netz in das Öffentliche Netz übergeht. Das wäre das Internet-Interface des Servers. Wozu soll das NAT am Client sein? Du Routest ohne NAT bis zum Server und nur dort brauchst Du NAT.
venet0 ist ja das Internet-Interface des Servers. Und da gehts doch ins öffentliche Netz. Was ist falsch? Sorry, steh evtl auf dem Schlauch. Die Regel im Client hatte ich von jemandem so übernommen. Ohne die kommen meine Rechner hinter dem Client nicht onlineOhne die kommen meine Rechner hinter dem Client nicht online
Zeigt das da grundlegend was falsch läuft mit dem Routing ! NAT sollte man nicht im internen Netz machen, denn damit schaffst du dir immer eine Einbahnstrasse, da Endgeräte die NAT Firewall ja nicht überwinden können. NAT ist überflüssig und meist auch kontraproduktiv im internen Netz besonders bei einer Site-to-Site Kopplung.
