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

german
firewall
openvpn

#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


UCS Master (with dynamic IP) <-> UCS Backup/Slave connection
Absicherung von UCS
#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