Openvpn Site to Site - Ports nur für vpn Verbindung öffnen

[lebernd]

Hallo Ulf,

vielen Dank für Deine Antwort, die meine Fragen schon fast vollständig beantwortet. Vielleicht macht es Sinn, die Conf-Dateien aus dem Beispiel zu nehmen und entsprechend anzupassen. Den Eintrag remote verstehe ich schon und der VPN Tunnel wird auch aufgebaut. Meine Frage nach dem ‘remote server’ war bzgl. des Kommentars vor route. Aber die hast Du ja beantwortet: über Kreuz. D.h. konkret auf dem jeweiligen Server steht das eigene Netzwerk als ‘route’ und die verwendet dann der ‘remote server’, also der andere.
Bei meinem vServer gibt es keine LAN IP-Adresse, braucht es da überhaupt eine Route? Z.B. also:

Server1:

• Master, hinter Firewall
• lokale ip: 10.210.237.171, Netzwerk: 10.210.237.0/24
• Erreichbar über remote.myucs.net (dyndns)

Server2:

• Slave, vServer im ‘Internet’
• öffentliche ip: x.x.35.y, Netzwerk: x.x.32.0/22
• Erreichbar über meine.domain.land

ergibt Server1 server2server.conf:

## die anderen Sachen

## The address used internally by OpenVPN
ifconfig 10.255.255.10 10.255.255.11

## Route traffic to remote network
## The network should be the one, used by the remote server
route 10.210.237.0 255.255.255.0

## und hier der Rest
...

Server2 server2server.conf:

## die anderen Sachen

## The external DNS name or IP of the other VPN
remote remote.myucs.net 1195

## The address used internally by OpenVPN
ifconfig 10.255.255.11 10.255.255.10

## Route traffic to remote network
## The network should be the one, used by the remote server
## ??? ist diese Route nötig ???
route x.x.32.0 255.255.252.0

## der Rest
...

Nun also zur Firewall. Ja, der vServer hat die ip-tables, bzw. liegt der Rest nicht in meiner Hand. Im Bsp. wird ja nur zusätzlich der vpn-Port auf dem Master freigegeben. Ich würde also alle Dienste auf dem Server2(Slave) auf $ sudo ucr set security/packetfilter/udp bzw. tcp/port-nr./tun=ACCEPT stellen (bis auf 443).
Die tun-IP auf dem Slave ist ja nun: 10.255.255.11 - d.h. der DNS-Server Eintrag auf Server1(master) wird so angepasst?

$ sudo ucr set nameserver2=10.255.255.11

oder doch so?

$ sudo ucr set nameserver2=x.x.35.y

und Server1 nimmt die angegebene Route durch den Tunnel - nur ist der Dienst dann über diese Adresse überhaupt noch erreichbar, wenn ich vorher die ip-tables auf tun stelle?

Vielen Dank vorab,
Bernd

[ulf.kosack]

Hallo Bernd,

das hier

The network should be the one, used by the remote server

route 10.210.237.0 255.255.255.0

muss in die Konfiguration des vServers (Server2), weil das interne Netzwerk des Server1 ist ja für Server2 das remote Netzwerk, deswegen soll er das über die VPN-Verbindung routen.

Auf dem internen Server1 würde ich als remote dann den Eintrag verwenden (bzw. nur die einzelne IP des Servers):

The network should be the one, used by the remote server

route x.x.32.0 255.255.252.0

Nun also zur Firewall. Ja, der vServer hat die ip-tables, bzw. liegt der Rest nicht in meiner Hand. Im Bsp. wird ja nur zusätzlich der vpn-Port auf dem Master freigegeben. Ich würde also alle Dienste auf dem Server2(Slave) auf $ sudo ucr set security/packetfilter/udp bzw. tcp/port-nr./tun=ACCEPT stellen (bis auf 443).

Ja

Die tun-IP auf dem Slave ist ja nun: 10.255.255.11 - d.h. der DNS-Server Eintrag auf Server1(master) wird so angepasst?

$ sudo ucr set nameserver2=10.255.255.11

Ja

Viele Grüße
Ulf

[lebernd]

Guten Abend,

eine kleine Rückmeldung zur Doku.

• Tatsächlich scheint die Univention-Blog-Anleitung im Falle der Routen einen Fehler zu haben und es ist wie @ulf.kosack gepostet hat. Der Server braucht jeweils die route des anderen Netzwerks.
• Ich habe es nicht geschafft alle UCS-Dienste über die tun Adresse auf dem Vserver anzusprechen. Mit der route zur öffentlichen IP-Adresse gab es immer wieder Probleme mit openvpn. Wenn hier also noch jmd. mehr weiß? Aber ich denke es gibt einfach Probleme mit den iptables bzw. einem Join auf dem tun Interface.
• Besser wurde es mit einer lokalen VLAN Schnittstelle auf dem Vserver und einer route zu dieser Adresse. Ich habe /31 als Netzwerk genommen und die x.y.z.1 als IP. Der Join trägt auch jetzt noch die Haupt-IP (also die öffentliche) des Vservers ins Rechnerobjekt (und verändert den externen DNS auf dem Vserver), aber das ist ja auch wieder leicht zu ändern. Würde das setzen der Primäre Netzwerkschnittstelle auf dem Vserver etwas ändern?
• Die Firewall habe ich auf ucr set security/packetfilter/use_packages=no gestellt, damit die öffentliche IP nicht die ganzen Ports offen hat. Danach die ganze Port-Reihe durch auf ucr set security/packetfilter/<prot>/<port>/tun=ACCEPT wieder freigegeben. Im Kommentar zu security/packetfilter/use_packages steht, was passiert, wenn diese Variable “disabled” ist. Klarer wäre, wenn dort auch steht, wie sie “disabled” wird. no und false gehen wohl, disabled eher nicht. Warum ich nicht auch noch die Vlan-IP freigeben musste, ist mir bisher ein Rätsel - evtl. geht es nach einem Neustart so ja auch nicht mehr?
• Die Ports, die nicht öffentlich offen sein sollen in 50_local.sh dank Tipp von @Moritz_Bunkus mit iptables -I INPUT -p "[tcp/udp]" -d w.x.y.z --dport [port-nr] -j DROP schließen.

Soweit einmal, Grüße,
Bernd

[fk22]

Hallo @lebernd,
ich möchte eine ähnlich verteilte Serverstruktur aufbauen:

Sever 1:
Master, hinter Fritzbox
Nextcloud
erreichbar über dyndns

Server 2:
Slave, vServer im ‘Internet’
öffentlich ip
erreichbar über meinedomain.de

Hast Du seit deinem letzten Post an der Lösung noch weiter gearbeitet und funktioniert es jetzt einwandfrei? Irgendwelche weiteren Fallstricke, etc.?

VG
FK

[lebernd]

Guten Morgen FK,

ja, das läuft so seit gut 9 Monaten.
Fallstricke eigentlich nicht. Nach einem Neujoin des Slave muss ich die Netzwerkeinstellungen/DNS korrigieren, damit nicht die öffentliche IP-Adresse genommen wird, aber das kam jetzt ja auch so gut wie nicht mehr vor, vielleicht einmal.

Viele Grüße,
Bernd

[fk22]

Hallo @lebernd,

ich versuche das so umzusetzten wie beschrieben, ich scheitere aber schon im Schritt davor: Wie hast Du den Slave installiert ohne, dass dieser eine Verbindung zum DNS Server aufbauen kann? Ich habe es mit der eigenen IP (die des Slaves) versucht als auch mit der dynamischen des Masters beides mal ohne den Domain Join anzustoßen. Letzteres scheint nicht zu klappen, da die Firewall (Fritzbox) die Verbindung blockiert, erstes gibt auch einen Fehler Rückmeldung. Das Ergebnis ist immer ein UCS in das ich mich nicht per Webinterface einloggen kann.
Ich habe diesen Thread noch gefunden, in dem einige Vorgehen genannt werden: Installation - späterer Join: Validierungsfehler

Hast Du einen von diese drei Möglichkeiten (Eine temporäre Verbindung zum DNS des Masters, Die Installation eines Test-Masters mit den passenden Daten (Domainname etc.), Die Verwendung eines Clones des Masters) genutzt oder geht das unkomplizierter?

VG
FK

[fk22]

Hallo,
ich bin in den letzten Tagen etwas weiter gekommen, scheitere aber immer noch am routing so scheint es mir.

Ausgangslage:

UCS Master, hinter Fritzbox
im Netwerk 192.168.178.0/24 255.255.255.0 mit lokaler ip 192.168.178.2
GW: 192.168.178.1
Tunnel IP: 10.0.0.1

UCS Slave auf einem vServer im ‘Internet’
im Netzwerk 46.x.x.0/21 255.255.248.0 mit ip 46.x.x.214
GW: x.x.232.1
Tunnel IP: 10.0.0.2

UCS Master server2server.conf

## Topology and protocol settings
dev tun
proto udp
management /var/run/management-udp unix
## the shared secret for the connection
secret /etc/openvpn/static.key
## Encryption Cypher to use for the VPN
cipher AES-256-CBC
## Compression algorithm to use
comp-lzo
## The port on which the VPN Server should listen on
port 1195
## The address used internally by OpenVPN
ifconfig 10.0.0.1 10.0.0.2
## Route traffic to remote network
## The network should be the one, used by the remote server
route 46.x.x.0 255.255.248.0
## Additional server configuration
keepalive 10 120
persist-key
persist-tun
## Configure the logfile and the verbosity
verb 1
mute 5
status /var/log/openvpn-status.log

UCS Slave server2server.conf

## Topology and protocol settings
dev tun
proto udp
management /var/run/management-udp unix
## the shared secret for the connection
secret /etc/openvpn/static.key
## Encryption Cypher to use for the VPN
cipher AES-256-CBC
## Compression algorithm to use
comp-lzo
## The external DNS name or IP of the other VPN
remote home.tld.de 1195
## The address used internally by OpenVPN
ifconfig 10.0.0.2 10.0.0.1
## Route traffic to remote network
## The network should be the one, used by the remote server
route 192.168.178.0 255.255.255.0
## Additional server configuration
keepalive 10 120
persist-key
persist-tun
## Configure the logfile and the verbosity
verb 1
mute 5
status /var/log/openvpn-status.log

wenn ich die beiden route zeilen auskommentiere, verbinden sich beide Server wunderbar und der ping von auf die gegenüberliegende Tunnel ip funktioniert. Wenn ich vom Slave den Master per ping home.tld.de pinge löst er auch auf die interne ip 192.168.178.2 auf, allerdings ist der ping nicht erfolgreich. Mit der route Angabe scheiter der VPN-aufbau komplett (Verbindung time-out).
Der UDP Port 1195 ist in beiden Firewalls (Master und Slave) und in der Fritzbox freigegeben.

Ich habe in anderen Tutorials noch gelesen, dass ich das routing per iptables einrichten muss, allerdings macht mit der scheiternde Aufbau der Verbindung schon stutzig.
Könnt ihr mir helfen meinen Denkfehler zu finden?

VG
FK

[lebernd]

Guten Abend FK,

so richtig hat es bei mir funktioniert, nachdem ich auf dem Slave eine virtuelle Netzwerkschnittstelle eingerichtet habe und die route zum Netzwerk dieser Schnittstelle eingetragen habe.
D.h. es gibt auf dem Slave etwas in der Art: eth0.xy@eth0 mit einer IP-Adresse 10.x.y.1/31
die Route auf dem Master geht dann zu 10.x.y.0 255.255.255.254

Evtl. könnte man auch das komplete Systemrouting in den Netzwerkeinstellung von eth0 verändern - vielleicht ginge das auch. Kommt mir aber erst jetzt als Idee und ich habe das nicht verfolgt.

Grüße,
Bernd

[fk22]

Hallo Bernd,
danke für das Feedback. Wenn das mit einer virutelle Netwerkschnittstelle funktioniert, probiere ich das doch auch. Wie hast Du das denn unter UCS eingerichtet? Ich habe folgendes Tutorial gefunden: https://www.dinotools.de/2010/01/02/virtuelle-netzwerkkarten-unter-linux/
Klappt das genauso unter UCS ohne die Upgradefähigkeit zu gefährden, UCS arbeitet ja gerne und viel mit Templates…

VG
FK

[lebernd]

Guten Morgen,

das geht über die UMC: System - Netzwerkeinstellungen - hinzufügen… da dann eine Virtuelle Schnittstelle auswählen und mit den Wunschnummern versehen. Neustart würde ich in jedem Fall danach machen.

Schönes WE,
Bernd

[fk22]

Hallo @lebernd,
ich habe es nach vielen Versuchen und gedanklichen Änderungen nun soweit hinbekommen, dass ich den VPS als UCS Slave joinen kann. Ich habe den VPS als Road Warrior per Ipsec Tunnel in die Fritzbox einwählen lassen, wodurch er nun in meinem Heimnetz eine lokale ip hat. Alle Services lassen sich vom VPS zum Heimserver und umgekehrt problemlos ansprechen - Domain Join klappt.
Allerdings habe ich nach einer unbestimmten Zeitspanne das Problem, dass der Domänenbeitritt “verloren geht”. Die Systemdiagnose des Slave zeigt alle Fehler die es gibt, wenn das System nicht korrekt gejoint ist. Nach einem löschen des Slaves im LDAP des Masters und anschließendem neuen Join läuft wieder alles - bis zum erneuten Verlust.
Du schreibst:

Der Join trägt auch jetzt noch die Haupt-IP (also die öffentliche) des Vservers ins Rechnerobjekt (und verändert den externen DNS auf dem Vserver), aber das ist ja auch wieder leicht zu ändern. Würde das setzen der Primäre Netzwerkschnittstelle auf dem Vserver etwas ändern?

Das ist bei mir auch so und ich vermute, dass hier der Grund für mein Problem liegt. Leider waren meine Änderungen (Ich hatte alle öffentlichen IPs mit der internen IP des VPS ersetzt, dadurch aber nach einiger Zeit einen DNS Fehler als Rückmeldung bekommen) nicht erfolgreich.
Kannst Du mir erklären, welche Änderungen Du vorgenommen hast?

Anbei die meine Konfigurationen auf dem VPS:

Die LDAP Konfiguration auf dem Heimserver:

und die DNS Konfiguration auf dem Heimserver:

Vielen Dank im voraus!

[lebernd]

Hallo MK,

aaaaalso: zuerst einmal ohne meine Bilder - deine Bilder:
Bild 1: wie lautet deine

wodurch er nun in meinem Heimnetz eine lokale ip hat

lokale IP? Diese würde ich als ersten Domänen-DNS eintragen. Wird diese lokale IP denn mit ip a ausgegeben?

Bild 2: Es fehlt die ‘lokale IP’. Diese wird bei mir beim Join auf dem Master auch nicht eingetragen. Ich habe sie händisch eingetragen - und darauf bezog sich meine bisher unbeantwortete Frage.
Ob hier der DNS-Eintrag stimmt, kann ich durch die Schwärzung nicht sagen. Ich würde sagen, angesichts des nächsten Bildes, sie sollte home.geschwärzt.de heißen. So heißt die UCS-Domäne?! Ja? (Bei mir steht selbst für die öffentliche IP der UCS-Domänenname, das ist aber vielleicht falsch)

Bild 3: für den 1. Eintrag nur die offiziellen VPS-DNS Server eintragen / für den 2. Eintrag beide Rechner (Heim und VPS) und für den 3. Eintrag??? ich schätze auf die öffentlich auflösbare Domain geschwärzt.de also auch hier die Netcup-DNS Server und dann fehlt aber 4. Eintrag: home.geschwärzt.de wieder mit den beiden Rechnern (wie bei 2.)

Soweit meine Analyse, beste Grüße
Bernd

[lebernd]

Und nun noch meine Einstellungen - ein bisschen anders, da ich eben drei lokale Netzwerke habe:

• Master Netzwerk
• Virtuelle Schnittstelle auf dem VPS Slave
• OpenVPN Tunnel
  Sieht dann so aus (ich hab’s nun mal als Anlass genommen eine Doku zu machen:-)

Voila:

Netzwerk-Einstellungen
	Heimserver - Master
IP Netzwerkgeräte
eth0	Ethernet	10.20.30.10/24
Globale Netzwerk-Einstellungen
	Primäres Netzwerkgerät	leer
	Gateway	10.20.30.1
	Domänen-DNS-Server	10.20.30.10	eigene IP
	Domänen-DNS-Server	10.20.31.1	IP VPS: virtuelle Schnittstelle
	Externer DNS-Server	10.20.30.1	Gateway
	VPS – Slave
IP Netzwerkgeräte
eth0	Ethernet	178.254.x.y/22	Öffentliche IP
eth0.2031	Virtuelles LAN	10.20.31.1/31	Selbst erstellte Schnittstelle
Globale Netzwerk-Einstellungen
	Primäres Netzwerkgerät	eth0
	Gateway	178.254.z.1
	Domänen-DNS-Server	10.20.31.1	eigene IP
	Domänen-DNS-Server	10.20.30.10	IP Heimserver
	Externer DNS-Server	178.254.a.b
	Externer DNS-Server	178.254.a.c
	Externer DNS-Server	10.20.30.10
Rechner
	ucs-master
Netzwerk-Einstellungen
	IP-Adresse	10.20.30.10
	IP-Adresse	10.20.255.10	OpenVPN-IP
DNS Forward und Reverse Lookup Zone
	DNS-Forward-Zone	intern.DOMAIN.de	IP-Adresse	10.20.30.10
	DNS-Forward-Zone	intern.DOMAIN.de	IP-Adresse	10.20.255.10
	DNS-Reverse-Zone	10.20.30	IP-Adresse	10.20.30.10
	DNS-Reverse-Zone	10.20.255	IP-Adresse	10.20.255.10
	ucs-slave
Netzwerk-Einstellungen
	IP-Adresse	10.20.31.1
	IP-Adresse	178.254.x.y
	IP-Adresse	10.20.255.11	OpenVPN-IP
DNS Forward und Reverse Lookup Zone
	DNS-Forward-Zone	intern.DOMAIN.de	IP-Adresse	10.20.31.1
	DNS-Forward-Zone	intern.DOMAIN.de	IP-Adresse	178.254.x.y
	DNS-Forward-Zone	intern.DOMAIN.de	IP-Adresse	10.20.255.11
	DNS-Reverse-Zone	10.20.31	IP-Adresse	10.20.31.1
	DNS-Reverse-Zone	178.254	IP-Adresse	178.254.x.y
	DNS-Reverse-Zone	10.20.255	IP-Adresse	10.20.255.11
DNS
	Name	Wert
	10.20.30	ucs-master.intern.DOMAIN.de., ucs-slave.intern.DOMAIN.de.
	10.20.31	ucs-master.intern.DOMAIN.de., ucs-slave.intern.DOMAIN.de.
	10.20.255	ucs-master.intern.DOMAIN.de., ucs-slave.intern.DOMAIN.de.
	178.254	VPS-DNS1., VPS-DNS2.
	intern.DOMAIN.de	ucs-master.intern.DOMAIN.de., ucs-slave.intern.DOMAIN.de.
	DOMAIN.de	VPS-DNS1., VPS-DNS2.

[fk22]

Hallo @lebernd,

danke für die Daten. Ich werde das mal mit meiner Konfiguration abgleichen.

[fk22]

Hallo @lebernd,

kurze Rückmeldung: bei mir läuft es jetzt 1,5 Wochen ohne Probleme. Ich habe allerdings keine virtuelle Schnittstelle eingerichtet und mit der öffentlichen IP des VPS gearbeitet. Die Verbindung zwischen Master und Slave läuft trotzdem. Was noch nicht klappt ist der Ping vom Slave auf Geräte im Heimnetz (außer auf den UCS Master). Das mag aber an nicht richtig gesetzten statischen Routen in der Fritzbox liegen. Momentan kann ich damit leben, da die Verbindung (noch) nicht brauche.
Ich erhalte auf dem Slave allerdings noch immer den Fehler “KDC Erreichbarkeit”. Hatte hier KDC Erreichbarkeit kritisch in einm Beitrag von dir gelesen, dass es möglicherweise am Diagnoseskript liegt. Da alles funktioniert, kann ich damit leben.

Vielen Dank für die Unterstützung!

[lebernd]

Hallo @fk22,

ja, prima - die Fehlermeldung habe ich weiterhin, das stört allerdings nicht. Kannst Du in diesem Setup denn auch die Firewall-Ports auf dem VPS (bis auf http/https) schließen? Oder sind alle Domänendienste dann auf den entsprechenden Ports übers Internet erreichbar?

Grüße,
Bernd

[fk22]

Hallo @lebernd,
ich befürchte wenn ich die Ports schließe klappt das Setup so nicht. Wenn ich per traceroute meinen slave / VPS ansteuere geht die Anfrage per Internet / außerhalb des Openvpn Tunnels dorthin. Ich vermute meine statische Route ist nicht richtig konfiguriert. Da muss ich die Tage nochmal ran…

BG
fk

[fk22]

Hallo @lebernd,
hat etwas gedauert bis ich wieder Zeit für das Porjekt hatte. Ich habe jetzt alle nicht für die Außenwelt benötigten Ports per iptables nur für den UCS Master geöffnet.

Löschen der vorhandenen Regel:

iptables -D INPUT -p tcp -m tcp --dport [Port] -j ACCEPT

Öffnen nur für die ip des UCS im VPN Netzwerk:

iptables -I INPUT -p tcp -s 10.255.255.11 --dport [Port] -j ACCEPT

Danach noch:

iptables-save > /etc/iptables.up.rules

das klappt soweit und sollte genügend Sicherheit gegen unbefugtes Eindrigen bringen!? Dies wäre ein Weg ohne die Einrichtung einer weiteren Lan-Schnittstelle…

Danke für die Unterstützung. Mein Set-up sollte damit (vorerst) fertig sein.

VG
FK

Edit: spechern der Regel hat nicht geklappt

[lebernd]

Hallo @fk22

hast Du es mit dieser Datei versucht?

Die Ports, die nicht öffentlich offen sein sollen in 50_local.sh dank Tipp von @Moritz_Bunkus mit iptables -I INPUT -p "[tcp/udp]" -d w.x.y.z --dport [port-nr] -j DROP schließen.

Der ganze Pfad ist dann /etc/security/packetfilter.d/50_local.sh
Danke für die Idee mit dem öffnen einer einzigen IP-Adresse. Das sieht so aus als könnte man das hin und wieder mal gebrauchen

VG,
Bernd

[fk22]

Hallo @lebernd
danke für den Tipp, das hat prima geklappt.
Weil ich Angst hatte mir den Rückweg zu verbauen haben ich die security/packetfilter/package/ Regeln erstmal nur auf REJECT gesetzt. Dabei habe ich Kopano4UCS Variablen ausgelassen.

Danach meldete der UCS Master, dass er die öffentliche IP des Slaves nicht mehr als Namensserver erreichen kann. Habe den dann auf die VPN IP geändert und alles sieht grün aus.

VG
FK