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

UCS - Univention Corporate Server
, ,
#1

Guten Morgen,

ich versuche gerade nach Anleitung https://www.univention.de/2017/10/schritt-fuer-schritt-zur-verteilten-serverumgebung/ einen UCS-Slave auf einem vServer im Internet zu installieren und mit einem Master hinter einer Firewall zu verbinden. Das klappt soweit ganz gut, auch wenn mich die route Einträge grübeln lassen, was denn nun jeweils der remote server ist. Im Text steht, dass man die route tauschen soll, im den config-Dateien jedoch zweimal dieselbe route…

Die eigentliche Frage ist jedoch, ob ich auf dem vServer im Internet wirklich diese ganzen Standard-Slave-Ports offen haben sollte, also 22, 80, 88, 111, 389…?
Wie sage ich dem Slave am Besten, dass er an diesen Stellen doch bitte nur VPN-Verbindungen akzeptiert?
Und wie spreche ich den Slave vom Master aus am Besten an? Dann nicht über die öffentliche IP-Adresse, sondern die VPN-IP? (in der Anleitung werden wahrscheinlich zwei Netzwerke miteinander verbunden, die jeweils auch eine lokale Adresse haben?)
Oder reicht es wenn der Master den VPN-Tunnel zur öffentlichen IP wählt, damit sich die Ports dann öffnen?

Im Moment sind lediglich ein paar Webanwendungen geplant, so dass ein offener Port 443 eigentlich reichen sollte.

Vielleicht hat jemand Ideen, Erfahrungen. Grüße,
Bernd

Absicherung von UCS
UCS on vServer(netcup) as 2nd Server via VPN Tunnel - Ideas
UCS Master (with dynamic IP) <-> UCS Backup/Slave connection
#2

Hallo Bernd,

Erfahrungen mit dem UCS-Aufbau über VPN habe ich noch nicht, aber zumindestens die einzelnen Komponenten habe ich schon mal aufgebaut.

Die route- und ifconfig-Einträge der ovpn-Konfiguration erhalten ja das eigene und das entfernte Netz. Dementsprechend müssen diese auf den zwei Servern genau über Kreuz konfiguriert werden, damit der vServer weiß, welches Netz er über das VPN erreicht. Der Remote-Server ist die öffentliche IP des OVPN-Servers, der die Verbindungen annimmt. Das hängt davon ab, welcher Deiner zwei Server die Verbindung aufbaut. Der andere Server ist dann der remote Server.

Die Ports sollte aus Sicherheitsgründen natürlich nur über VPN erreichbar sein, aber sie müssen alle offen sein, damit die Domain-Controller-Dienste miteinander kommunizieren können. Wenn Du keine separate Firewall vor dem vServer hast, musst Du das mit Univention Firewall erledigen. Das ist auch nur iptables, wird aber über die Config-Variablen gesteuert. Das im HowTo angegebene Beispiel gibt die Ports über alle Schnittstellen frei. Du kannst hier dann auch das tun-Device angeben, dann erfolgt die Freigabe nur über VPN.

Die Kommunikation sollte nur über die internen IP-Adressen funktionieren. Das Routing erfolgt durch die ovpn-Konfiguration mit der route-Option. Wenn Du ein separates Standard-Gateway hast, musst Du dort natürlich eine statische Route für das entfernte Netz über den Server setzen, der OVPN installiert hat.

Viel Erfolg
Ulf

#3

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

#4

Hallo Bernd,

das hier

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):

Ja

Ja

Viele Grüße
Ulf

#5

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

#6

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

#7

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

#8

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

#9

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

#10

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

#11

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

#12

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

#13

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:

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:
grafik

Die LDAP Konfiguration auf dem Heimserver:
grafik

und die DNS Konfiguration auf dem Heimserver:
grafik

Vielen Dank im voraus!

#14

Hallo MK,

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

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

#15

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.






#16

Hallo @lebernd,

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

#17

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!

#18

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

#19

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

#20

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 :disappointed_relieved:

Mastodon