OpenVPN Server mit statischer IP als "Schleuse" für Server hinter Privatanschluss

[bluestar]

Was ich nicht ganz verstehe, warum einem hier keiner konkret sagen kann, wie ich mein Problem nun genau löse.

Weil niemand hier dein Setup 1:1 nachbaut um deine Probleme zu verstehen und sie letztendlich zu lösen.

Wenn mir einer dabei helfen kann und sagen kann, wo ich konkret was anpassen muss, damit der Traffic ausgehend auch Fehlerfrei läuft, wäre das Top.

Advanced Routing Howto lesen, da steht exakt diese Thematik drinne...

[Mario885]

wie ich die entsprechenden Parameter wo genau setze, dass ich z.B. 80, 443, 993 und 587 (und ggf. 25) von eth0 wieder über tun0 raus route.

Wenn dem VPN-Client gewisse Ports verboten sind, dann deinstalliere auf dem Client die Prozesse, die diese Ports benutzen. Wenn die Ports (und Prozesse) notwendig sind, dann muss sich der VPN-Server auch nicht weiter drum kümmern, sondern er hat sie einfach nur ans Default-Gateway durchzuleiten. Zumal solche einfach nur ge'forward'eten Pakete sowieso keine Prozesse auf dem OpenVPN-Server erreichen.

Was du damit übrigens konkret meinst erschließt sich mir nicht. Ich will meinem Client keine Ports verbienten (und wenn, dann konfiguriere ich das per ufw) sondern es sollen vom internen Server hier bei mir die oben genannten Ports (mindestens) über den openVPN-Tunnel über den externen vServer bei 1und1 (der eigentlich eher nur als statische öffentliche IP dienen soll) ins Internet.
z.B. http --> vServer intern --> vServer extern --> Internet
Oder : "gesamter Traffic" --> vServer intern --> vServer extern --> Internet

Andersrum z.B. läuft es: http --> auf meine externe IP = Aufruf meines Webservers - OK

[Mario885]

Was ich nicht ganz verstehe, warum einem hier keiner konkret sagen kann, wie ich mein Problem nun genau löse.

Weil niemand hier dein Setup 1:1 nachbaut um deine Probleme zu verstehen und sie letztendlich zu lösen.

Das ist mir schon klar. Aber einen hinweis (konkreteren), wo ich ggf. genau schauen kann. Das ist doch sicher drin oder?

Wenn mir einer dabei helfen kann und sagen kann, wo ich konkret was anpassen muss, damit der Traffic ausgehend auch Fehlerfrei läuft, wäre das Top.

Advanced Routing Howto lesen, da steht exakt diese Thematik drinne...

Habe ich mir bereits angeschaut. Werde aber daraus nicht ganz schlau. Vor allem wo ich das was genau eintragen muss.

Ich Frage jetzt mal doof:
Konkret bräuchte ich einen Routing Befehl, der sagt:

route alles (oder die genannten Ports) von [interner ip/eth0] nach tun0 (tunnel IP des externen Servers)

Dies muss ich doch irgendwo angeben können oder?
Das sagt IP route show. Ist da ggf was falsch bzw. wie und wo kann ich da was anpassen?

ip route show
0.0.0.0/1 via 10.8.0.1 dev tun0 //10.8.0.1 (tun0 Adresse externer Server)
default via 192.168.XXX.[GW] dev eth0 onlink
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.2 //10.8.0.2 (tun0 Adresse interner Server)
82.XXX.XXX.XX via 192.168.XXX.[GW] dev eth0 // 82.XXX.XXX.XX = öffentliche IP dees externen Servers die andere ist mein Router
128.0.0.0/1 via 10.8.0.1 dev tun0 /// ??
192.168.XXX.0/24 dev eth0 proto kernel scope link src 192.168.XXX.[iSRV] // internes Netzwerk und 192.168.XXX.[iSRV] ist der interne Server
192.168.XXX.[iSRV] via 10.8.0.1 dev tun0 // interner Server via tun0 externer Server

Vielelicht erbarmt sich doch einer und kann mir da helfen. Weiß sonst im Moment grad echt nicht weiter und werde wie gesagt aus dem hier
"http://lartc.richb-hanover.com/howto/index.html" nicht recht schlau. Zumal ich da nicht konkret finde, was ich suche. Sorry.

[bluestar]

Ich Frage jetzt mal doof:
Konkret bräuchte ich einen Routing Befehl, der sagt:

route alles (oder die genannten Ports) von [interner ip/eth0] nach tun0 (tunnel IP des externen Servers)

Code: Alles auswählen

ip rule add from a.b.c.d lookup nn

Dazu legst du ne zweite Routingtabelle „nn“ an, a.b.c.d ist deine IP auf tun0

Apropos ich würd es nicht so machen, sondern auf eth0 das gateway weglassen, eine Hostroute für deinen öffentlichen vServer setzen und das Default-GW einfach auf die IP 10.8.0.1 setzen.

[TomL]

Was du damit übrigens konkret meinst erschließt sich mir nicht.

Dieses Regel-Paket, was völlig unsinning ist:

Code: Alles auswählen

ptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 10.8.0.2:80
iptables -A FORWARD -d 10.8.0.2 -p tcp --dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to 10.8.0.2:443
iptables -A FORWARD -d 10.8.0.2 -p tcp --dport 443 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 993 -j DNAT --to 10.8.0.2:993
iptables -A FORWARD -d 10.8.0.2 -p tcp --dport 993 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 587 -j DNAT --to 10.8.0.2:587
iptables -A FORWARD -d 10.8.0.2 -p tcp --dport 587 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 18000 -j DNAT --to 10.8.0.2:18000
iptables -A FORWARD -d 10.8.0.2 -p tcp --dport 18000 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 4190 -j DNAT --to 10.8.0.2:4190
iptables -A FORWARD -d 10.8.0.2 -p tcp --dport 4190 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 110 -j DNAT --to 10.8.0.2:110
iptables -A FORWARD -d 10.8.0.2 -p tcp --dport 110 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 143 -j DNAT --to 10.8.0.2:1430
iptables -A FORWARD -d 10.8.0.2 -p tcp --dport 143 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 995 -j DNAT --to 10.8.0.2:995
iptables -A FORWARD -d 10.8.0.2 -p tcp --dport 995 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 25 -j DNAT --to 10.8.0.2:25
iptables -A FORWARD -d 10.8.0.2 -p tcp --dport 25 -j ACCEPT

Konkret bräuchte ich einen Routing Befehl, der sagt:

Nein, brauchst Du nicht... das ist durch das Masquerading automatisch geregelt. Die Client-Pakete (von außen) bekommen damit automatisch die IP des OpenVPN-Server und Pakete finden damit auch automatisch das Default-Gateway.

[bluestar]

TomL, du bist auf der falschen Fährte, der Te benötigt schon die Regeln...

Sein Setup hat mit VPN-Server/-Client nichts zu tun, er will über einen „wie auch immer schlecht/falsch konfigurierten“ OpenVPN Tunnel Dienste im LAN über DNAT vom Ende des Tunnels anbieten. Von Point-to-Point und von /32 Netzen hat er dabei noch nix gehört.

[Mario885]

Ich Frage jetzt mal doof:
Konkret bräuchte ich einen Routing Befehl, der sagt:

route alles (oder die genannten Ports) von [interner ip/eth0] nach tun0 (tunnel IP des externen Servers)

Code: Alles auswählen

ip rule add from a.b.c.d lookup nn

Dazu legst du ne zweite Routingtabelle „nn“ an, a.b.c.d ist deine IP auf tun0

Apropos ich würd es nicht so machen, sondern auf eth0 das gateway weglassen, eine Hostroute für deinen öffentlichen vServer setzen und das Default-GW einfach auf die IP 10.8.0.1 setzen.

Ok.
Schätze mal, gemäß deinem Link, muss das ganze unter /etc/iproute2.
Nur finde ich da zu den aktuellen Routen nichts und habe somit nicht mal einen Anhalt/Hinweis, wie das dann aussehen muss (muss die Datei dann nn.conf heißen (stzeht meine ich so in der howto, die Du verlinkt hast)).
in /etc/iproute2 ist folgendes:

ls
bpf_pinning ematch_map group nl_protos rt_dsfield rt_protos rt_realms rt_scopes rt_tables rt_tables.d

Und sorry für meine Dummheit, aber wie/wo meinst du das hier Konkret?:

Apropos ich würd es nicht so machen, sondern auf eth0 das gateway weglassen, eine Hostroute für deinen öffentlichen vServer setzen und das Default-GW einfach auf die IP 10.8.0.1 setzen.

In der IP-konfig am vServer intern das Gateway entfernen und eine Hostroute auf die 10.8.0.1 mit Gateway 10.8.0.1. Das kann ich jetzt nicht nachvollziehen oder verstehe ich dich falsch.

[bluestar]

In der IP-konfig am vServer intern das Gateway entfernen und eine Hostroute auf die 10.8.0.1 mit Gateway 10.8.0.1. Das kann ich jetzt nicht nachvollziehen oder verstehe ich dich falsch.

Die Hostroute für die externe Strato IP:

Code: Alles auswählen

/sbin/ip route add 82.xx.xx.xx via 192.168.178.1

Am besten in den Lan Abschnitt deiner network/interfaces als „up“ Command.

[Mario885]

Vielen vielen herzlichen Dank.

Es scheint nun zu funktionieren.
Endlich. Nach gut einer Woche probieren und basteln.
Webserver ist von außen erreichbar. Ping zwischen den Servern geht. Adressauflösung läuft und apt update und apt get am internen vServer funktioniert.

Herzlichsten Dank nochmal und einen schönen Abend.

PS: die überflüssigen iptables habe ich auskommentiert.
Danke auch für den Hinweis.

Jetzt muss nur noch alles umgezogen und abgesichert werden (bzw. anders rum ).

nochmal... Danke.

[Mario885]

Puh.

Leider zu früh gefreut.
Hatte ich vergessen. Das hatte ich in der Konstellation an sich so auch schon.
Scheinbar bringt der Hosteintrag in der interfaces leider nicht wirklich was oder ich habe es leider verbockt und da was falsch.

Es lag dran, dass ich leider die Webserverseite noch im Cache des Browsers hatte. Nach dem schließen des Browsers war kein Zugriff mehr möglich.

Ping und apt etc. am Client geht. ebenso ping vom Server zum Client.

Jedoch wie gesagt kein Webserver/Webseitenaufruf von Extern zum internen vServer. Das iegt daran (hatte ich auch schon rausgefunden), wenn ich die ipTables, wie von "TomL" vorgeschlagen lösche/auskommentiere. Dann tritt genau aktuelle Konstellation auf. Aktiviere ich das Ganze wieder, geht der zugriff auf den Webserver wieder etc., nur geht am vServer intern (Client) z.B. apt update und wget nicht. Bin also wieder am Anfang.

/etc/network/interfaces sieht nun so aus:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 192.168.178.11
netmask 255.255.255.0
gateway 192.168.178.XXX
dns.nameservers 10.8.0.1 192.168.178.XXX
/sbin/ip route add 82.XXX.XXX.XX via 192.168.178.11 up
# This is an autoconfigured IPv6 interface
iface eth0 inet6 auto

Hoffe ist so korrekt. Wie gesagt bzgl. Routing etc. hab ich leider kein so Plan.
Gateway da entfernen, wie vorgeschlagen wurde (wenn ich das korrekt verstanden habe) geht ja nicht, da ich dann keine Internetverbindung mehr habe, somit keinen Tunnel aufbauen kann.

Hoffe es hat noch einer ne Idee.
Werde echt langsam verrückt. Kann doch nicht so ein Hexenwerk sein verdammte Kac***

[bluestar]

1) Die Hostroute in deiner network/interfaces ist fehlerhaft eingetragen, hier must du die Doku lesen.

2) Gibt‘s auf deinem externen vServer eine Firewall-Regel, die Traffic im FORWARD-Chain von tun0 nach externes Device erlaubt?

3) Warum loggt deine Firewall nicht? So könntest du selbst sehen, ob‘s klemmt...

[TomL]

TomL, du bist auf der falschen Fährte, ...

Den Gedanken hatte ich auch schon ....

Sein Setup hat mit VPN-Server/-Client nichts zu tun, er will über einen „wie auch immer schlecht/falsch konfigurierten“ OpenVPN Tunnel Dienste im LAN über DNAT vom Ende des Tunnels anbieten. Von Point-to-Point und von /32 Netzen hat er dabei noch nix gehört.

Vielleicht kapier ich wirklich nicht, worums geht. Kannst Du mir denn kurz erklären, warum mein Setup anders ist... ?... bei dem irgendwelche Clients irgendwelche Dienste auf dem VPN-Server (der auch LAN-Server ist) nutzen? Also bei mir nutzen jedenfalls auch unsere VPN-Clients einzelne Dienste auf der anderen Seite des Tunnels... die andere Seite ist bei mir der VPN-Server. Welche laufenden (!) Dienste bietet denn der Server hier bei diesem Problem explizit an? Und warum braucht es so ein Heckmeck mit Routen und krusen Paketfilter-Regeln, wenn doch das VPN die Clients (via NAT) einfach ins Netz auf der anderen Seite des Tunnels integrieren kann? Ist das hier ein variables Roadwarrior-Setup oder eine konstante Site-to-Site-Installation? Oder ist es hier auf der Client-Seite ein Mischmasch mit prinzipieller Verwendung des lokalen Netzes, aber einzelne Services via VPN?

[Mario885]

TomL, du bist auf der falschen Fährte, ...

Den Gedanken hatte ich auch schon ....

Sein Setup hat mit VPN-Server/-Client nichts zu tun, er will über einen „wie auch immer schlecht/falsch konfigurierten“ OpenVPN Tunnel Dienste im LAN über DNAT vom Ende des Tunnels anbieten. Von Point-to-Point und von /32 Netzen hat er dabei noch nix gehört.

Vielleicht kapier ich wirklich nicht, worums geht. Kannst Du mir denn kurz erklären, warum mein Setup anders ist... ?... bei dem irgendwelche Clients irgendwelche Dienste auf dem VPN-Server (der auch LAN-Server ist) nutzen? Also bei mir nutzen jedenfalls auch unsere VPN-Clients einzelne Dienste auf der anderen Seite des Tunnels... die andere Seite ist bei mir der VPN-Server. Welche laufenden (!) Dienste bietet denn der Server hier bei diesem Problem explizit an? Und warum braucht es so ein Heckmeck mit Routen und krusen Paketfilter-Regeln, wenn doch das VPN die Clients (via NAT) einfach ins Netz auf der anderen Seite des Tunnels integrieren kann? Ist das hier ein variables Roadwarrior-Setup oder eine konstante Site-to-Site-Installation? Oder ist es hier auf der Client-Seite ein Mischmasch mit prinzipieller Verwendung des lokalen Netzes, aber einzelne Services via VPN?

@TomL:
Glaube nicht, dass du so auf der falschen Fährte bist.
@BlueStar:
Glaube her Du vertstehst was falsch. (Oder ich irre mich extrem).

Nochmal zum Verständnis:
Ich habe einen 1und1 vServer gemietet, der eine feste statische öffentliche IP hat.
Dieser stellt den OpenVPN-Server (bereit). Als weiterer einziger zusätzlicher Dienst (abgesehen von den Debian 9 Standard-Diensten)
ist ufw eingerichtet und aktiviert. Hier werden jedoch die benötigten Ports definitiv zugelassen (443, 80, 993, 587, 110 etc.), es sei denn ich müsste der Firewall noch irgendwo mitteilen, dass da z.B. auf dem "Rückweg" vom VPN-Client (tun0) zum ens192 (echtes LAN-Interface des vServers bei 1und1) auch entsprechend die Ports verwendet werden dürfen/müssen.
Für mich sieht es halt so aus, dass da irgendwie nur etwas blockiert wird, das traceroute etc. alles raus kommt und auch ping und Namensauflösung funktioniert. Es bleibt einfach irgendwie etwas auf der Strecke. Habe ich einen Port vergessen, der erforderlich wäre für Web. Aber wäre mir sehr neu...
Bezüglich Einrichtung des VPN:
Hier habe ich vorwiegend folgende Quelle verwendet:
https://www.cyberciti.biz/faq/howto-set ... 16-04-lts/
und zusätzlich hier:
https://www.df.eu/de/support/df-faq/clo ... an-ubuntu/
Gemäß der Quellen, ist der Client eingerichtet.
Hier läuft aktuell auch nur ufw als zusätzlicher Dienst, sowie der Mailserver (im Rohbau) mit dem entsprechenden Webserver (Roh).
Bis auf die statische IP-Konfiguration, die Einrichtung des OpenVPN am Client, die zuletzt gepostete Anpassung in network/interfaces und die Konfiguration der ufw mit den gleichen Ports, wie am vServer bei 1und1, ist da nichts weiter konfiguriert.

Und ich weiß jetzt nicht, wie man auf "LAN-Server" kommt (vielleicht missversteh ich das gerade), aber mein 1und1 Server steht direkt im Netz, hat ne öffentliche IP und per OpenVPN über tun0 die einzige Verbindung zu meinem VPN-Client (vServer ( Hyper V) hier bei mir zu Hause). Wie man da dann auf "LAN-Server" kommt, weiß ich jetzt nicht.

Letzten Sachstand habe ich gestern Abend geschrieben. Mit den Tables an, geht Zugriff auf Webserver etc. jedoch wieder kein http-Zugriff vomVPN-Client (vServer bei mir). Also kein Ap update oder wget oder what ever.

Hoffe das war nun verständlich genug erläutert.

[TomL]

Nochmal zum Verständnis:
Ich habe einen 1und1 vServer gemietet, der eine feste statische öffentliche IP hat.
Dieser stellt den OpenVPN-Server (bereit). Als weiterer einziger zusätzlicher Dienst (abgesehen von den Debian 9 Standard-Diensten)
ist ufw eingerichtet und aktiviert. Hier werden jedoch die benötigten Porst definitiv zugelassen (443, 80, 993, 587, 110 etc.).

Das beantwortet aber nicht die Frage, ob das incomminig oder outgoing Traffic ist. Und ob diese Portfreigaben bei einem VPN-Tunnel in dieser Form überhaupt notwendig sind, ist für mich immer noch fragwürdig.

Bezüglich Einrichtung des VPN: Hier habe ich vorwiegend folgende Quelle verwendet:
https://www.cyberciti.biz/faq/howto-set ... 16-04-lts/
und zusätzlich hier:
https://www.df.eu/de/support/df-faq/clo ... an-ubuntu/

Ich halte von solchen Malen-nach-Zahlen-Anleitungen nicht sehr viel, weil sie nicht das für so ein Netz notwendige Wissen herstellen. Deshalb schick ich Dir mal einen Link zu meiner Anleitung von Paketfilter und OpenVPN per PN. Das ist ist nicht in 5 Minuten eingerichtet, aber ich hoffe, dass es das notwenige Hintergrundwissen vermittelt.

Und ich halte auch von der UFW nicht sehr viel. Wenn man kontrollieren kann, was sie tut, braucht man sie nicht, weil man dann direkt den Paketfilter einstellen kann. Und wenn mans nicht kontrollieren kann, hat man möglichweise auch keine Vorstellungen darüber, welche Faktoren diese FW völlig neutralisieren können.

Und ich weiß jetzt nicht, wie man auf "LAN-Server" kommt (vielleicht missversteh ich das gerade), aber mein 1und1 Server steht direkt im Netz, hat ne öffentliche IP und per OpenVPN über tun0 die einzige Verbindung zu meinem VPN-Client (vServer ( Hyper V) hier bei mir zu Hause). Wie man da dann auf "LAN-Server" kommt, weiß ich jetzt nicht.

Weil Du den Begriff LAN-Server zu eng defininierst. Ein LAN-Server definiert sich nicht durch einen Standort, sondern durch seine Funktionalität. Und sobald eine Maschine Clients mit Services versorgt und die Clients sich innerhalb des gleichen Subnetzes befinden oder via Bridge verbunden sind, ist er meiner Meinung nach ein LAN-Server. Der Unterschied von LAN zu WAN besteht darin, dass LAN-Services vom WAN isoliert sind und das man "Club-Mitglied" sein muss. Durch den VPN-Tunnel integriert sich ein entfernter Client-Host mehr oder weniger in das Subnetz des VPN-Server-Host.... wird damit also Club-Mitglied des LANs, in welchem der Server werkelt.

Hoffe das war nun verständlich genug erläutert.

Nicht wirklich, Du sprichst von 1&1-Server als VPN-Server und von VPN-Clients auf einem vServer zuhause. VPN-Clients laufen meiner Meinung nach auf Enduser-Geräten und weniger auf einem vServer. Sind 2 Server im Spiel würde ich jetzt vermuten, es ist eine site-2-site-Verbindung, wo sich hinter den VPN-Hosts noch weitere Clients verbergen.

[bluestar]

Vielleicht kapier ich wirklich nicht, worums geht. Kannst Du mir denn kurz erklären, warum mein Setup anders ist... ?... bei dem irgendwelche Clients irgendwelche Dienste auf dem VPN-Server (der auch LAN-Server ist) nutzen? Also bei mir nutzen jedenfalls auch unsere VPN-Clients einzelne Dienste auf der anderen Seite des Tunnels... die andere Seite ist bei mir der VPN-Server. Welche laufenden (!) Dienste bietet denn der Server hier bei diesem Problem explizit an? Und warum braucht es so ein Heckmeck mit Routen und krusen Paketfilter-Regeln, wenn doch das VPN die Clients (via NAT) einfach ins Netz auf der anderen Seite des Tunnels integrieren kann? Ist das hier ein variables Roadwarrior-Setup oder eine konstante Site-to-Site-Installation? Oder ist es hier auf der Client-Seite ein Mischmasch mit prinzipieller Verwendung des lokalen Netzes, aber einzelne Services via VPN?

Um es mal ganz einfach zu sagen, der Mario möchte dass sich Rechner vom Internet aus auf den VPN-Server connecten (z.B. IMAPS) und das diese Verbindung durch den VPN-Tunnel zum VPN-Client (grausiges Wording) per DNAT weitergeleitet wird, weil der VPN-Client ein IMAPS-Server ist.

[bluestar]

Hier werden jedoch die benötigten Ports definitiv zugelassen (443, 80, 993, 587, 110 etc.), es sei denn ich müsste der Firewall noch irgendwo mitteilen, dass da z.B. auf dem "Rückweg" vom VPN-Client (tun0) zum ens192 (echtes LAN-Interface des vServers bei 1und1) auch entsprechend die Ports verwendet werden dürfen/müssen.

Falsch du definierst nur Regeln von vServer im Internet in zu deinem vServer zu Hause .... Für mich sieht folgende Zeile falsch aus:

Code: Alles auswählen

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o ens192 -j MASQUERADE

Ändere sie mal dahingehend ab:

Code: Alles auswählen

iptables -t nat -A POSTROUTING -o ens192 -j MASQUERADE

Am Rande gefragt auf deinem vServer zu Hause läuft hoffentlich keine Firewall, oder? Falls ja könnte ggfs. auch hier der Hund noch weiter begraben liegen.

[bluestar]

Nicht wirklich, Du sprichst von 1&1-Server als VPN-Server und von VPN-Clients auf einem vServer zuhause. VPN-Clients laufen meiner Meinung nach auf Enduser-Geräten und weniger auf einem vServer. Sind 2 Server im Spiel würde ich jetzt vermuten, es ist eine site-2-site-Verbindung, wo sich hinter den VPN-Hosts noch weitere Clients verbergen.

Richtig das Wording in diesem Thread ist schwierig - Wir reden hier über einen Server-2-Server Tunnel über den Dienste bereitgestellt werden sollen .... Die Konfiguration von OpenVPN und von dem vServer zu Hause ist, um das Thema zu vereinfachen, komplett geheim und nicht Bestandteil dieses Threads Aber immerhin ist Mario Netzwerk-Experte im Windows Umfeld ...

[TomL]

Um es mal ganz einfach zu sagen, der Mario möchte dass sich Rechner vom Internet aus auf den VPN-Server connecten (z.B. IMAPS) und das diese Verbindung durch den VPN-Tunnel zum VPN-Client (grausiges Wording) per DNAT weitergeleitet wird, weil der VPN-Client ein IMAPS-Server ist.

Ich verstehe das nicht. Wo läuft denn der IMAP-Server? Auf dem OpenVPN-Server oder auf dem VPN-Client-Host (vServer)? Wer initiiert mit welcher Absicht eine Verbindung. Ich kenne das so, dass üblicherweise ein Server Funktionen zur Verfügung stellt, Samba, IMAP, Cal-DAV, etc. und das sich belieibige Clients über einen VPN-Tunnel an diesen Services anmelden. Das ist für mich eine reguläre OpenVPN-Funktion, neben dem Site-2-Site-Bridging, wo originäre TCP-Pakete transportiert werden.

Er müsste das mal logisch dem Ablauf entsprechend skizzieren, damit man überhaupt versteht, welche Systeme genau welche Aufgaben erfüllen sollen, wie die Verbindungen aussehen, persistent oder on-the-fly, und von wem wann wodurch wie lange mit welchen Absichten initiiert.

[bluestar]

Ich verstehe das nicht. Wo läuft denn der IMAP-Server? Auf dem OpenVPN-Server oder auf dem VPN-Client-Host? Wer initiiert mit welcher Absicht eine Verbindung.

Er müsste das mal logisch dem Ablauf entsprechend skizzieren, damit man überhaupt versteht, welche System genau welche Aufgaben erfüllen sollen, wie die Verbindungen aussehen, persistent oder on-the-fly, und von wem wann wodurch wie lange mit welchen Absichten initiiert.

Ganz einfach:
1) Mario hat einen vServer mit öffentlicher IP bei Strato
2) Mario hat einen vServer zu Hause, dieser ist der IMAP Server mit privater IP.
3) Mario baut einen Tunnel von Strato zu seinem vServer zu Hause.
4) Mario leitet den IMAP Port der öffentlichen IP bei Strato per DNAT auf die private IP zu Hause.
5) Somit kann Gott und die Welt sich per IMAP auf die öffentliche IP "verbinden" und erreicht darüber den IMAP-Server bei Mario im Keller

[TomL]

*boar*

Ich passe.... das ist ne Nummer zu groß für mich... und ich würde das auch so nicht lösen. Dabei wird die Beschreibung meiner Lösung auch nicht helfen, sondern eher nur weiter Chaos stiften.

[bluestar]

*boar*

Den Knoten im Kopf und in der Denke gibt's frei Haus und umsonst dazu.

[Mario885]

Nochmal zum Verständnis:
Ich habe einen 1und1 vServer gemietet, der eine feste statische öffentliche IP hat.
Dieser stellt den OpenVPN-Server (bereit). Als weiterer einziger zusätzlicher Dienst (abgesehen von den Debian 9 Standard-Diensten)
ist ufw eingerichtet und aktiviert. Hier werden jedoch die benötigten Porst definitiv zugelassen (443, 80, 993, 587, 110 etc.).

Das beantwortet aber nicht die Frage, ob das incomminig oder outgoing Traffic ist. Und ob diese Portfreigaben bei einem VPN-Tunnel in dieser Form überhaupt notwendig sind, ist für mich immer noch fragwürdig.

Konkret soll der in den iptables konfigurierte Fraffic eigentlich in beide Richtungen. HTTP, HTTPs, IMAP etc. soll ja in beide Richtugnen möglich sein.

Bezüglich Einrichtung des VPN: Hier habe ich vorwiegend folgende Quelle verwendet:
https://www.cyberciti.biz/faq/howto-set ... 16-04-lts/
und zusätzlich hier:
https://www.df.eu/de/support/df-faq/clo ... an-ubuntu/

Ich halte von solchen Malen-nach-Zahlen-Anleitungen nicht sehr viel, weil sie nicht das für so ein Netz notwendige Wissen herstellen. Deshalb schick ich Dir mal einen Link zu meiner Anleitung von Paketfilter und OpenVPN per PN. Das ist ist nicht in 5 Minuten eingerichtet, aber ich hoffe, dass es das notwenige Hintergrundwissen vermittelt.

Danke im Voraus. Hoffe damit kann ich das Problem endlich lösen.

Und ich halte auch von der UFW nicht sehr viel. Wenn man kontrollieren kann, was sie tut, braucht man sie nicht, weil man dann direkt den Paketfilter einstellen kann. Und wenn mans nicht kontrollieren kann, hat man möglichweise auch keine Vorstellungen darüber, welche Faktoren diese FW völlig neutralisieren können.

Bin wie gesagt kein wirklicher Linux Crack, versuche mir aber soweit es möglich ist, mir das Wissen zu beschaffen bzw. anzueignen. Hier und da tuhe ich mich aber etwas schwer (wie man im konkreten Fall merkt). Sorry

Und ich weiß jetzt nicht, wie man auf "LAN-Server" kommt (vielleicht missversteh ich das gerade), aber mein 1und1 Server steht direkt im Netz, hat ne öffentliche IP und per OpenVPN über tun0 die einzige Verbindung zu meinem VPN-Client (vServer ( Hyper V) hier bei mir zu Hause). Wie man da dann auf "LAN-Server" kommt, weiß ich jetzt nicht.

Weil Du den Begriff LAN-Server zu eng defininierst. Ein LAN-Server definiert sich nicht durch einen Standort, sondern durch seine Funktionalität. Und sobald eine Maschine Clients mit Services versorgt und die Clients sich innerhalb des gleichen Subnetzes befinden oder via Bridge verbunden sind, ist er meiner Meinung nach ein LAN-Server. Der Unterschied von LAN zu WAN besteht darin, dass LAN-Services vom WAN isoliert sind und das man "Club-Mitglied" sein muss. Durch den VPN-Tunnel integriert sich ein entfernter Client-Host mehr oder weniger in das Subnetz des VPN-Server-Host.... wird damit also Club-Mitglied des LANs, in welchem der Server werkelt.

Sag ich doch. missverstanden. Ich rede da dann halt doch eher von VPN-Client und VPN-Server. Ist für die Unterscheidung besser 8zumal wir bei der Verbindugn an sich von virtuellen Adaptern reden). Aber grundsätzlich gebe ich Dir Recht.

Hoffe das war nun verständlich genug erläutert.

Nicht wirklich, Du sprichst von 1&1-Server als VPN-Server und von VPN-Clients auf einem vServer zuhause. VPN-Clients laufen meiner Meinung nach auf Enduser-Geräten und weniger auf einem vServer. Sind 2 Server im Spiel würde ich jetzt vermuten, es ist eine site-2-site-Verbindung, wo sich hinter den VPN-Hosts noch weitere Clients verbergen.

1und1 = vServer auf einem virtualisierer (z.B. VMWAre) bei 1und1 (= der VPN-Server)
Mein Server zu Hause ist ein Debian 9 Server (=der VPN-Client) der als virtuelle Maschine in Hyper V auf einem Server 2016 Host läuft, welcher wiederum Bare-Metall auf einem HP Microserver läuft.

[bluestar]

Am Rande gefragt auf deinem vServer zu Hause läuft hoffentlich keine Firewall, oder? Falls ja könnte ggfs. auch hier der Hund noch weiter begraben liegen.

Hast du für meine Frage auch einen Roman als Antwort ?

[Mario885]

Ich verstehe das nicht. Wo läuft denn der IMAP-Server? Auf dem OpenVPN-Server oder auf dem VPN-Client-Host? Wer initiiert mit welcher Absicht eine Verbindung.

Er müsste das mal logisch dem Ablauf entsprechend skizzieren, damit man überhaupt versteht, welche System genau welche Aufgaben erfüllen sollen, wie die Verbindungen aussehen, persistent oder on-the-fly, und von wem wann wodurch wie lange mit welchen Absichten initiiert.

Ganz einfach:
1) Mario hat einen vServer mit öffentlicher IP bei Strato
2) Mario hat einen vServer zu Hause, dieser ist der IMAP Server mit privater IP.
3) Mario baut einen Tunnel von Strato zu seinem vServer zu Hause.
4) Mario leitet den IMAP Port der öffentlichen IP bei Strato per DNAT auf die private IP zu Hause.
5) Somit kann Gott und die Welt sich per IMAP auf die öffentliche IP "verbinden" und erreicht darüber den IMAP-Server bei Mario im Keller

Genau
So in etwa. Nur verbindet sich mein Server zu Hause zu dem (nicht Strato) 1und1 - Server
Also mein Server zu Hause ist der Client (genauer siehe letzen Post von mir).
Ansonsten ist deine Schilderung korrekt.
Es soll von außen http, https und die Mailports bei mir am Server zu Hause über den erreichbar sein. ABER: Es soll auch andersrum möglich sein und da ist mein Problem (u.a. http und https wie bereits geschildert).

[Mario885]

Am Rande gefragt auf deinem vServer zu Hause läuft hoffentlich keine Firewall, oder? Falls ja könnte ggfs. auch hier der Hund noch weiter begraben liegen.

Hast du für meine Frage auch einen Roman als Antwort ?

Doch. Wie geschrieben. UFW. Aber mit den identischen Portfreigaben, wie am vServer bei 1und1.