OpenVPN Server mit statischer IP als "Schleuse" für Server hinter Privatanschluss
Re: OpenVPN Server mit statischer IP als "Schleuse" für Server hinter Privatanschluss
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...
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...
Re: OpenVPN Server mit statischer IP als "Schleuse" für Server hinter Privatanschluss
Den Gedanken hatte ich auch schon ....
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?bluestar hat geschrieben:02.04.2019 21:49:04Sein 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.
Re: OpenVPN Server mit statischer IP als "Schleuse" für Server hinter Privatanschluss
@TomL:TomL hat geschrieben:03.04.2019 10:27:02Den Gedanken hatte ich auch schon ....
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?bluestar hat geschrieben:02.04.2019 21:49:04Sein 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.
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...
![Question :?:](./images/smilies/icon_question.gif)
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.
Re: OpenVPN Server mit statischer IP als "Schleuse" für Server hinter Privatanschluss
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.Mario885 hat geschrieben:03.04.2019 14:11:53Nochmal 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.).
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.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/
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.
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.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.
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.Hoffe das war nun verständlich genug erläutert.
Zuletzt geändert von TomL am 03.04.2019 14:36:35, insgesamt 1-mal geändert.
Re: OpenVPN Server mit statischer IP als "Schleuse" für Server hinter Privatanschluss
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.TomL hat geschrieben:03.04.2019 10:27:02Vielleicht 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?
Re: OpenVPN Server mit statischer IP als "Schleuse" für Server hinter Privatanschluss
Falsch du definierst nur Regeln von vServer im Internet in zu deinem vServer zu Hause .... Für mich sieht folgende Zeile falsch aus:Mario885 hat geschrieben:03.04.2019 14:11:53Hier 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.
Code: Alles auswählen
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o ens192 -j MASQUERADE
Code: Alles auswählen
iptables -t nat -A POSTROUTING -o ens192 -j MASQUERADE
Re: OpenVPN Server mit statischer IP als "Schleuse" für Server hinter Privatanschluss
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 ThreadsTomL hat geschrieben:03.04.2019 14:32:52Nicht 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.
![Facepalm :facepalm:](./images/smilies/icon_ochmann.gif)
Re: OpenVPN Server mit statischer IP als "Schleuse" für Server hinter Privatanschluss
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.bluestar hat geschrieben:03.04.2019 14:34:13Um 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.
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.
Re: OpenVPN Server mit statischer IP als "Schleuse" für Server hinter Privatanschluss
Ganz einfach:TomL hat geschrieben:03.04.2019 14:43:57Ich 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.
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
![Very Happy :D](./images/smilies/icon_biggrin.gif)
Zuletzt geändert von bluestar am 03.04.2019 14:47:34, insgesamt 2-mal geändert.
Re: OpenVPN Server mit statischer IP als "Schleuse" für Server hinter Privatanschluss
*boar* ![Laughing :lol:](./images/smilies/icon_lol.gif)
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.
![Laughing :lol:](./images/smilies/icon_lol.gif)
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.
Re: OpenVPN Server mit statischer IP als "Schleuse" für Server hinter Privatanschluss
![Hail :hail:](./images/smilies/icon_hail.gif)
Re: OpenVPN Server mit statischer IP als "Schleuse" für Server hinter Privatanschluss
Mario885 hat geschrieben:03.04.2019 14:11:53Nochmal 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.).
Konkret soll der in den iptables konfigurierte Fraffic eigentlich in beide Richtungen. HTTP, HTTPs, IMAP etc. soll ja in beide Richtugnen möglich sein.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/
Danke im Voraus. Hoffe damit kann ich das Problem endlich lösen.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.
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). SorryUnd 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.
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.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.
1und1 = vServer auf einem virtualisierer (z.B. VMWAre) bei 1und1 (= der VPN-Server)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.
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.
Re: OpenVPN Server mit statischer IP als "Schleuse" für Server hinter Privatanschluss
Hast du für meine Frage auch einen Roman als Antwort ?bluestar hat geschrieben:03.04.2019 14:39:45Am 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.
Re: OpenVPN Server mit statischer IP als "Schleuse" für Server hinter Privatanschluss
Genaubluestar hat geschrieben:03.04.2019 14:46:18Ganz einfach:TomL hat geschrieben:03.04.2019 14:43:57Ich 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.
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![]()
![Thumbs Up :THX:](./images/smilies/thumbup.gif)
So in etwa. Nur verbindet sich mein Server zu Hause zu dem (nicht Strato) 1und1 - Server
![Wink ;-)](./images/smilies/icon_wink.gif)
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).
Re: OpenVPN Server mit statischer IP als "Schleuse" für Server hinter Privatanschluss
Doch. Wie geschrieben. UFW. Aber mit den identischen Portfreigaben, wie am vServer bei 1und1.bluestar hat geschrieben:03.04.2019 15:21:13Hast du für meine Frage auch einen Roman als Antwort ?bluestar hat geschrieben:03.04.2019 14:39:45Am 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.
Re: OpenVPN Server mit statischer IP als "Schleuse" für Server hinter Privatanschluss
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 hat geschrieben:03.04.2019 15:23:42Doch. Wie geschrieben. UFW. Aber mit den identischen Portfreigaben, wie am vServer bei 1und1.bluestar hat geschrieben:03.04.2019 15:21:13Hast du für meine Frage auch einen Roman als Antwort ?bluestar hat geschrieben:03.04.2019 14:39:45Am 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.
Re: OpenVPN Server mit statischer IP als "Schleuse" für Server hinter Privatanschluss
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
# 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
Re: OpenVPN Server mit statischer IP als "Schleuse" für Server hinter Privatanschluss
okay du leitest jeglichen HTTP/HTTP Traffic deines Server auf die 10.8.0.2 Port 80 bzw. 443 um -> Willst du das wirklich?Mario885 hat geschrieben:03.04.2019 15:42:51Code: 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
Deshalb funktioniert auch apt update nicht.
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.
Re: OpenVPN Server mit statischer IP als "Schleuse" für Server hinter Privatanschluss
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".....?
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.
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".....?
![Question :?:](./images/smilies/icon_question.gif)
![Redface :oops:](./images/smilies/icon_redface.gif)
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.
Re: OpenVPN Server mit statischer IP als "Schleuse" für Server hinter Privatanschluss
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 ....Mario885 hat geschrieben:03.04.2019 16:31:28Also kann/mag mir hier keiner helfen oder kann mir konkret keiner verraten, wo ich da den Fehler drin habe?
bluestar hat geschrieben:03.04.2019 15:54:42okay 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.
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.Mario885 hat geschrieben:03.04.2019 16:31:28Ich 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.
Re: OpenVPN Server mit statischer IP als "Schleuse" für Server hinter Privatanschluss
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.Mario885 hat geschrieben:03.04.2019 16:31:28Es 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.
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.