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

Alle weiteren Dienste, die nicht in die drei oberen Foren gehören.
Benutzeravatar
bluestar
Beiträge: 2346
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

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

Beitrag von bluestar » 03.04.2019 14:39:45

Mario885 hat geschrieben: ↑ zum Beitrag ↑
03.04.2019 14:11:53
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.

Benutzeravatar
bluestar
Beiträge: 2346
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

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

Beitrag von bluestar » 03.04.2019 14:41:47

TomL hat geschrieben: ↑ zum Beitrag ↑
03.04.2019 14:32:52
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 :facepalm: Aber immerhin ist Mario Netzwerk-Experte im Windows Umfeld ...

TomL

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

Beitrag von TomL » 03.04.2019 14:43:57

bluestar hat geschrieben: ↑ zum Beitrag ↑
03.04.2019 14:34:13
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.
Zuletzt geändert von TomL am 03.04.2019 14:46:19, insgesamt 1-mal geändert.

Benutzeravatar
bluestar
Beiträge: 2346
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

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

Beitrag von bluestar » 03.04.2019 14:46:18

TomL hat geschrieben: ↑ zum Beitrag ↑
03.04.2019 14:43:57
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 :D
Zuletzt geändert von bluestar am 03.04.2019 14:47:34, insgesamt 2-mal geändert.

TomL

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

Beitrag von TomL » 03.04.2019 14:47:04

*boar* :lol:

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.
Zuletzt geändert von TomL am 03.04.2019 14:50:41, insgesamt 1-mal geändert.

Benutzeravatar
bluestar
Beiträge: 2346
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

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

Beitrag von bluestar » 03.04.2019 14:48:08

TomL hat geschrieben: ↑ zum Beitrag ↑
03.04.2019 14:47:04
*boar* :lol:
:hail: Den Knoten im Kopf und in der Denke gibt's frei Haus und umsonst dazu.

Mario885
Beiträge: 39
Registriert: 03.10.2018 22:47:39

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

Beitrag von Mario885 » 03.04.2019 15:17:54

Mario885 hat geschrieben: ↑ zum Beitrag ↑
03.04.2019 14:11:53
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.

Benutzeravatar
bluestar
Beiträge: 2346
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

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

Beitrag von bluestar » 03.04.2019 15:21:13

bluestar hat geschrieben: ↑ zum Beitrag ↑
03.04.2019 14:39:45
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
Beiträge: 39
Registriert: 03.10.2018 22:47:39

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

Beitrag von Mario885 » 03.04.2019 15:22:28

bluestar hat geschrieben: ↑ zum Beitrag ↑
03.04.2019 14:46:18
TomL hat geschrieben: ↑ zum Beitrag ↑
03.04.2019 14:43:57
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 :D
Genau :THX:
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
Beiträge: 39
Registriert: 03.10.2018 22:47:39

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

Beitrag von Mario885 » 03.04.2019 15:23:42

bluestar hat geschrieben: ↑ zum Beitrag ↑
03.04.2019 15:21:13
bluestar hat geschrieben: ↑ zum Beitrag ↑
03.04.2019 14:39:45
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.

Benutzeravatar
bluestar
Beiträge: 2346
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

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

Beitrag von bluestar » 03.04.2019 15:34:53

Mario885 hat geschrieben: ↑ zum Beitrag ↑
03.04.2019 15:23:42
bluestar hat geschrieben: ↑ zum Beitrag ↑
03.04.2019 15:21:13
bluestar hat geschrieben: ↑ zum Beitrag ↑
03.04.2019 14:39:45
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.
Was hast du in der UFW neben den Port-Freigaben noch konfiguriert? Wirf mal die Ausgabe von iptables-save hier ins Forum, damit wir dir helfen können.

Mario885
Beiträge: 39
Registriert: 03.10.2018 22:47:39

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

Beitrag von Mario885 » 03.04.2019 15:42:51

iptables-save
# Generated by iptables-save v1.6.0 on Wed Apr 3 13:36:32 2019
*nat
:PREROUTING ACCEPT [6419:483824]
:INPUT ACCEPT [192:17072]
:OUTPUT ACCEPT [41:3863]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.8.0.2:80
-A PREROUTING -p tcp -m tcp --dport 443 -j DNAT --to-destination 10.8.0.2:443
-A PREROUTING -p tcp -m tcp --dport 993 -j DNAT --to-destination 10.8.0.2:993
-A PREROUTING -p tcp -m tcp --dport 587 -j DNAT --to-destination 10.8.0.2:587
-A PREROUTING -p tcp -m tcp --dport AAABB** -j DNAT --to-destination 10.8.0.2:AAABB**
-A PREROUTING -p tcp -m tcp --dport 110 -j DNAT --to-destination 10.8.0.2:110
-A PREROUTING -p tcp -m tcp --dport 143 -j DNAT --to-destination 10.8.0.2:143
-A PREROUTING -p tcp -m tcp --dport 995 -j DNAT --to-destination 10.8.0.2:995
-A PREROUTING -p tcp -m tcp --dport 25 -j DNAT --to-destination 10.8.0.2:25
-A POSTROUTING -s 10.8.0.0/24 -o ens192 -j MASQUERADE
-A POSTROUTING -o ens192 -j MASQUERADE
-A POSTROUTING -o tun0 -j MASQUERADE
COMMIT
# Completed on Wed Apr 3 13:36:32 2019
# Generated by iptables-save v1.6.0 on Wed Apr 3 13:36:32 2019
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:ufw-after-forward - [0:0]
:ufw-after-input - [0:0]
:ufw-after-logging-forward - [0:0]
:ufw-after-logging-input - [0:0]
:ufw-after-logging-output - [0:0]
:ufw-after-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-before-input - [0:0]
:ufw-before-logging-forward - [0:0]
:ufw-before-logging-input - [0:0]
:ufw-before-logging-output - [0:0]
:ufw-before-output - [0:0]
:ufw-logging-allow - [0:0]
:ufw-logging-deny - [0:0]
:ufw-not-local - [0:0]
:ufw-reject-forward - [0:0]
:ufw-reject-input - [0:0]
:ufw-reject-output - [0:0]
:ufw-skip-to-policy-forward - [0:0]
:ufw-skip-to-policy-input - [0:0]
:ufw-skip-to-policy-output - [0:0]
:ufw-track-forward - [0:0]
:ufw-track-input - [0:0]
:ufw-track-output - [0:0]
:ufw-user-forward - [0:0]
:ufw-user-input - [0:0]
:ufw-user-limit - [0:0]
:ufw-user-limit-accept - [0:0]
:ufw-user-logging-forward - [0:0]
:ufw-user-logging-input - [0:0]
:ufw-user-logging-output - [0:0]
:ufw-user-output - [0:0]
-A INPUT -j ufw-before-logging-input
-A INPUT -j ufw-before-input
-A INPUT -j ufw-after-input
-A INPUT -j ufw-after-logging-input
-A INPUT -j ufw-reject-input
-A INPUT -j ufw-track-input
-A INPUT -i ens192 -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -i ens192 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j ufw-before-logging-forward
-A FORWARD -j ufw-before-forward
-A FORWARD -j ufw-after-forward
-A FORWARD -j ufw-after-logging-forward
-A FORWARD -j ufw-reject-forward
-A FORWARD -j ufw-track-forward
-A FORWARD -j ACCEPT
-A FORWARD -i ens192 -o tun0 -j ACCEPT
-A FORWARD -i tun0 -o ens192 -j ACCEPT
-A FORWARD -d 10.8.0.2/32 -p tcp -m tcp --dport 80 -j ACCEPT
-A FORWARD -d 10.8.0.2/32 -p tcp -m tcp --dport 443 -j ACCEPT
-A FORWARD -d 10.8.0.2/32 -p tcp -m tcp --dport 993 -j ACCEPT
-A FORWARD -d 10.8.0.2/32 -p tcp -m tcp --dport 587 -j ACCEPT
-A FORWARD -d 10.8.0.2/32 -p tcp -m tcp --dport AAABB** -j ACCEPT
-A FORWARD -d 10.8.0.2/32 -p tcp -m tcp --dport 110 -j ACCEPT
-A FORWARD -d 10.8.0.2/32 -p tcp -m tcp --dport 143 -j ACCEPT
-A FORWARD -d 10.8.0.2/32 -p tcp -m tcp --dport 995 -j ACCEPT
-A FORWARD -d 10.8.0.2/32 -p tcp -m tcp --dport 25 -j ACCEPT
-A OUTPUT -j ufw-before-logging-output
-A OUTPUT -j ufw-before-output
-A OUTPUT -j ufw-after-output
-A OUTPUT -j ufw-after-logging-output
-A OUTPUT -j ufw-reject-output
-A OUTPUT -j ufw-track-output
-A ufw-after-input -p udp -m udp --dport 137 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 138 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 139 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 445 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 67 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 68 -j ufw-skip-to-policy-input
-A ufw-after-input -m addrtype --dst-type BROADCAST -j ufw-skip-to-policy-input
-A ufw-after-logging-forward -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-after-logging-input -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-forward -j ufw-user-forward
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP
-A ufw-before-input -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-input -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A ufw-before-input -j ufw-not-local
-A ufw-before-input -d 224.0.0.251/32 -p udp -m udp --dport 5353 -j ACCEPT
-A ufw-before-input -d 239.255.255.250/32 -p udp -m udp --dport 1900 -j ACCEPT
-A ufw-before-input -j ufw-user-input
-A ufw-before-output -o lo -j ACCEPT
-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -j ufw-user-output
-A ufw-logging-allow -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW ALLOW] "
-A ufw-logging-deny -m conntrack --ctstate INVALID -m limit --limit 3/min --limit-burst 10 -j RETURN
-A ufw-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN
-A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN
-A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-A ufw-not-local -j DROP
-A ufw-skip-to-policy-forward -j DROP
-A ufw-skip-to-policy-input -j DROP
-A ufw-skip-to-policy-output -j ACCEPT
-A ufw-track-output -p tcp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-track-output -p udp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport XXXYY* -j ACCEPT
-A ufw-user-input -p udp -m udp --dport XXXYY* -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 22 -j DROP
-A ufw-user-input -p udp -m udp --dport 22 -j DROP
-A ufw-user-input -p tcp -m tcp --dport 25 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 25 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 587 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 587 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 465 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 465 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 110 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 110 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 143 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 143 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 995 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 995 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 993 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 993 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 80 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 80 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 443 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 443 -j ACCEPT
-A ufw-user-limit -m limit --limit 3/min -j LOG --log-prefix "[UFW LIMIT BLOCK] "
-A ufw-user-limit -j REJECT --reject-with icmp-port-unreachable
-A ufw-user-limit-accept -j ACCEPT
COMMIT
# Completed on Wed Apr 3 13:36:32 2019

*=SSH-Port
**=WebminPort

Benutzeravatar
bluestar
Beiträge: 2346
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

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

Beitrag von bluestar » 03.04.2019 15:54:42

Mario885 hat geschrieben: ↑ zum Beitrag ↑
03.04.2019 15:42:51

Code: Alles auswählen

# Generated by iptables-save v1.6.0 on Wed Apr  3 13:36:32 2019
*nat
:PREROUTING ACCEPT [6419:483824]
:INPUT ACCEPT [192:17072]
:OUTPUT ACCEPT [41:3863]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.8.0.2:80
-A PREROUTING -p tcp -m tcp --dport 443 -j DNAT --to-destination 10.8.0.2:443
-A PREROUTING -p tcp -m tcp --dport 993 -j DNAT --to-destination 10.8.0.2:993
-A PREROUTING -p tcp -m tcp --dport 587 -j DNAT --to-destination 10.8.0.2:587
-A PREROUTING -p tcp -m tcp --dport AAABB** -j DNAT --to-destination 10.8.0.2:AAABB**
-A PREROUTING -p tcp -m tcp --dport 110 -j DNAT --to-destination 10.8.0.2:110
-A PREROUTING -p tcp -m tcp --dport 143 -j DNAT --to-destination 10.8.0.2:143
-A PREROUTING -p tcp -m tcp --dport 995 -j DNAT --to-destination 10.8.0.2:995
-A PREROUTING -p tcp -m tcp --dport 25 -j DNAT --to-destination 10.8.0.2:25
okay du leitest jeglichen HTTP/HTTP Traffic deines Server auf die 10.8.0.2 Port 80 bzw. 443 um -> Willst du das wirklich?
Deshalb funktioniert auch apt update nicht.
Mario885 hat geschrieben: ↑ zum Beitrag ↑
03.04.2019 15:42:51

Code: Alles auswählen

-A FORWARD -j ACCEPT
Dein Forward Chain ist komplett vermurkst ... Sorry, aber du wirst dich wohl oder übel einmal mit dem Thema Firewall unter Linux beschäftigen müssen, so wird das nicht funktionieren.

Mario885
Beiträge: 39
Registriert: 03.10.2018 22:47:39

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

Beitrag von Mario885 » 03.04.2019 16:31:28

Es soll der Traffic (wegen mir komplett) vom 1und1 vServer zu meinem vServer zu Hause (also konkret die 10.8.0.2).
Der Traffic soll aber auch anders rum funktionieren.

Also kann/mag mir hier keiner helfen oder kann mir konkret keiner verraten, wo ich da den Fehler drin habe? Versteh ich das richtig. Ich will ja nicht, dass mir einer meine komplette Konfiguration macht, aber es ist doch sicher an einer der bereits geposteten stellen oder in einer Datei der Zwirrl drin, weshalb ich von intern (also meinem vServer zu Hause) z.B. kein Apt-Get update etc. verwenden kann. So ne kleine "Vorlage".....? :?: :oops:

Wie ich schon schrieb. Es funktioniert ja zu, ich sage mal 80%, aber der Rest soll halt auch. Irgendwas blockt das ganze irgendwo. Zumindestens ausgehend.

Benutzeravatar
bluestar
Beiträge: 2346
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

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

Beitrag von bluestar » 03.04.2019 16:51:56

Mario885 hat geschrieben: ↑ zum Beitrag ↑
03.04.2019 16:31:28
Also kann/mag mir hier keiner helfen oder kann mir konkret keiner verraten, wo ich da den Fehler drin habe?
Ich habe dir eine Frage gestellt, ob du das was du dort konfiguriert hast, auch wirklich so möchtest und dir sogar erklärt was deine Konfiguration bewirkt ....
bluestar hat geschrieben: ↑ zum Beitrag ↑
03.04.2019 15:54:42
okay du leitest jeglichen HTTP/HTTP Traffic deines Server auf die 10.8.0.2 Port 80 bzw. 443 um -> Willst du das wirklich?
Deshalb funktioniert auch apt update nicht.
Mario885 hat geschrieben: ↑ zum Beitrag ↑
03.04.2019 16:31:28
Ich will ja nicht, dass mir einer meine komplette Konfiguration macht, aber es ist doch sicher an einer der bereits geposteten stellen oder in einer Datei der Zwirrl drin, weshalb ich von intern (also meinem vServer zu Hause) z.B. kein Apt-Get update etc. verwenden kann.
Auch wenn deine Konfiguration mit dem Weglassen der PREROUTING Zeilen nachher augenscheinlich zu 100% funktioniert, es sind noch einige Sicherheitslücken in deiner Firewall enthalten... Live gehen solltest du so keinesfalls.

dirk11
Beiträge: 2818
Registriert: 02.07.2013 11:47:01

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

Beitrag von dirk11 » 04.04.2019 12:53:48

Mario885 hat geschrieben: ↑ zum Beitrag ↑
03.04.2019 16:31:28
Es soll der Traffic (wegen mir komplett) vom 1und1 vServer zu meinem vServer zu Hause (also konkret die 10.8.0.2).
Der Traffic soll aber auch anders rum funktionieren.

Also kann/mag mir hier keiner helfen oder kann mir konkret keiner verraten, wo ich da den Fehler drin habe? Versteh ich das richtig.
Ich verfolge das hier interessiert lesend. Meine unmaßgebliche Meinung: es wurde schon diverse Male und von diversen Personen geschrieben, dass das, was Du willst, so nicht funktioniert. Außerdem gibst Du oft nur nach mehrfacher Aufforderung Infos heraus, und das auch nur unvollständig. Wer Hilfe will, der sollte aber nicht labern, sondern Fragen zum Problem konkret und präzise beantworten.
Wenn Du unbedingt mit dem Kopf durch die Wand willst, musst Du wohl noch öfter vor selbige laufen.

Also: alles über Bord werfen, einen konkreten Anforderungskatalog aufstellen und aufschreiben und danach und darauf basierend hier erfragen, wie Du das am besten umsetzt. So wird das jedenfalls nix. Oder dilettantisch.

Antworten