105
Email Homeserver auf Dedicated Server Tunneln
Hey zusammen!
Ich hab zuhause nen Mailserver (Mailcow) am Laufen und bei Hetzner nen Dedicated Server. Jetzt überleg ich, ob es Sinn macht, den Traffic vom Home-Mailserver über den Dedi zu tunneln, um die Public IP vom Server zu nutzen. Der Dedi hat zwei Public IPs, und ich dachte, ich könnte die zweite IP dafür verwenden. Irgendeine VPN-Lösung wie WireGuard oder IPsec wäre ja denkbar.
Macht das Ganze Sinn?
Ich möchte den Mailserver Zuhause betreiben (Private Mails)
Danke schon mal!
Ich hab zuhause nen Mailserver (Mailcow) am Laufen und bei Hetzner nen Dedicated Server. Jetzt überleg ich, ob es Sinn macht, den Traffic vom Home-Mailserver über den Dedi zu tunneln, um die Public IP vom Server zu nutzen. Der Dedi hat zwei Public IPs, und ich dachte, ich könnte die zweite IP dafür verwenden. Irgendeine VPN-Lösung wie WireGuard oder IPsec wäre ja denkbar.
Macht das Ganze Sinn?
Ich möchte den Mailserver Zuhause betreiben (Private Mails)
Danke schon mal!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 670984
Url: https://administrator.de/forum/email-homeserver-auf-dedicated-server-tunneln-670984.html
Ausgedruckt am: 29.01.2025 um 18:01 Uhr
105 Kommentare
Neuester Kommentar
Hallo,
was für einen Vorteil hast Du wenn Du über den Server getunnelt auf Mailcow zugreifst?
Es ist nur eine Fehlerquelle mehr.
Dann würde ich den Mailcow eher auf dem Server in der Cloud laufen lassen wegen der schnelleren Anbindung.
Und Zuhause über die IP vom Server surfen macht keinen Spass.
Die meiste IPs in Rechenzentren haben Probleme bei Zugriff auf viele Webseiten. Reddit, Youtube, Microsoft, etc.
Ich tippe gerade auf so einem mittels RDP und nutzen einige Seite am Client bei mir zu Hause.
Stefan
was für einen Vorteil hast Du wenn Du über den Server getunnelt auf Mailcow zugreifst?
Es ist nur eine Fehlerquelle mehr.
Dann würde ich den Mailcow eher auf dem Server in der Cloud laufen lassen wegen der schnelleren Anbindung.
Und Zuhause über die IP vom Server surfen macht keinen Spass.
Die meiste IPs in Rechenzentren haben Probleme bei Zugriff auf viele Webseiten. Reddit, Youtube, Microsoft, etc.
Ich tippe gerade auf so einem mittels RDP und nutzen einige Seite am Client bei mir zu Hause.
Stefan
Naja, so gesehen surfe ich nicht drüber.
Nur der Homeserver baut einen Tunnel auf; und da auch nur für den benötigten Traffic.
Aber vielleicht ists in der Cloud doch besser. Wollte das eben zuhause Hosten und die IP per Tunnel vom Server am Heimserver verwenden
- Fabi
Nur der Homeserver baut einen Tunnel auf; und da auch nur für den benötigten Traffic.
Aber vielleicht ists in der Cloud doch besser. Wollte das eben zuhause Hosten und die IP per Tunnel vom Server am Heimserver verwenden
- Fabi
Moin,
ginge mit einer DNAT-Regel. Ports 25, 465 und 587 (SMTP) sowie 143 und 993 (IMAP) dann auf die IP deines int. Mailservers umleiten.
https://www.elektronik-kompendium.de/sites/net/0812111.htm
Würde aber entweder den Mail-Server direkt auf den Cloud-Server umziehen ODER auf dem Cloud-Server einen MTA einsetzen, der ggf. die Mails noch zwischenpuffern könnte.
ginge mit einer DNAT-Regel. Ports 25, 465 und 587 (SMTP) sowie 143 und 993 (IMAP) dann auf die IP deines int. Mailservers umleiten.
https://www.elektronik-kompendium.de/sites/net/0812111.htm
Würde aber entweder den Mail-Server direkt auf den Cloud-Server umziehen ODER auf dem Cloud-Server einen MTA einsetzen, der ggf. die Mails noch zwischenpuffern könnte.
1
Hmmm, das klingt nach einer Lösung.
Dann kann ich mir das ganze VPN Zeug ja sparen, denke ich (wobei ich da trotzdem einen Sicherheitsaspekt auf dem Verbindungsweg sehe)
Danke dir schonmal, ich teste das demnächst mal aus; nehme aber gerne weitere Ideen an
Dann kann ich mir das ganze VPN Zeug ja sparen, denke ich (wobei ich da trotzdem einen Sicherheitsaspekt auf dem Verbindungsweg sehe)
Danke dir schonmal, ich teste das demnächst mal aus; nehme aber gerne weitere Ideen an
Hallo,
die Milchkuh läuft vermutlich unter Linux?
Dann kannst Du aus der Cloud, mit einem IP-Filter, per SSH darauf zugreifen.
Ist einfacher als VPN, sicher verschlüsselt, nur 1 TCP Port und durch den IP-Filter vor Hackern ziemlich sicher
Stefan
die Milchkuh läuft vermutlich unter Linux?
Dann kannst Du aus der Cloud, mit einem IP-Filter, per SSH darauf zugreifen.
Ist einfacher als VPN, sicher verschlüsselt, nur 1 TCP Port und durch den IP-Filter vor Hackern ziemlich sicher
Stefan
brauchst Du alles nicht.
Dein Mailserver kann prima zuhause stehen und bekommt alle Mails der Welt. Nur versenden ist ja Dein Problem. Dazu brauchst Du den Server im RZ (bzw. dessen IP) als Mail-Relay. Wenn Du dort einen Mini-Postfix (o.ä.) einsetzt und die beiden so miteinander connectest, dass der RZ-Server die Mails vom Homeserver entgegen nimmt und von dort sendet, ist alles im Lot.
Mache ich seit vielen Jahren so. Ich fahre den Homeserver sogar nachts herunter, alles kein Problem. Die eingehenden Mails werden zurückgestellt, die sendenden Server versuchen es später und morgens, wenn Du hochfährst kommt alles rein.
Prinzip:
https://thomas-leister.de/zentralen-mailserver-mit-weiteren-servern-nutz ...
https://legacy.thomas-leister.de/postfix-als-smarthost-mail-relay-fuer-a ...
Für die Mailkuh:
https://community.mailcow.email/d/1163-interner-mail-relay
Noch simpler ist es natürlich, die Mails gleich über einen Provider (als "Smarthost") zu leiten. Dann werden sie dort aber auch zunächst empfangen, können aber z.B. per POP3 so heruntergeladen werden, dass sie nicht dort liegen bleiben.
https://wiki.ubuntuusers.de/Postfix/
Ich denke aber, die von Dir angedachte Lösung lässt sich auch umsetzen. Sinngemäß wie oben vom Kollegen @em-pie beschrieben, aber nur für den Versand, also IMO nur Port 25 denn nur für den Versand brauchst Du die IP des Hosters und 465 und/oder 587 sind Ports, mit denen Deine Clients an Deinem Server angebunden werden, nicht aber Ports mit denen Dein Server sendet.
Ob das alles sinnvoll ist, ist fraglich, ich hab' das damals mal als "Spielprojekt" gemacht, weil viele hier im Forum immer gesagt haben, Mailserver zu hause geht nicht, aber das Projekt hat lange gehalten
Man lernt eine Menge dabei, daher mach es 
Viele Grüße, commodity
Dein Mailserver kann prima zuhause stehen und bekommt alle Mails der Welt. Nur versenden ist ja Dein Problem. Dazu brauchst Du den Server im RZ (bzw. dessen IP) als Mail-Relay. Wenn Du dort einen Mini-Postfix (o.ä.) einsetzt und die beiden so miteinander connectest, dass der RZ-Server die Mails vom Homeserver entgegen nimmt und von dort sendet, ist alles im Lot.
Mache ich seit vielen Jahren so. Ich fahre den Homeserver sogar nachts herunter, alles kein Problem. Die eingehenden Mails werden zurückgestellt, die sendenden Server versuchen es später und morgens, wenn Du hochfährst kommt alles rein.
Prinzip:
https://thomas-leister.de/zentralen-mailserver-mit-weiteren-servern-nutz ...
https://legacy.thomas-leister.de/postfix-als-smarthost-mail-relay-fuer-a ...
Für die Mailkuh:
https://community.mailcow.email/d/1163-interner-mail-relay
Noch simpler ist es natürlich, die Mails gleich über einen Provider (als "Smarthost") zu leiten. Dann werden sie dort aber auch zunächst empfangen, können aber z.B. per POP3 so heruntergeladen werden, dass sie nicht dort liegen bleiben.
https://wiki.ubuntuusers.de/Postfix/
Ich denke aber, die von Dir angedachte Lösung lässt sich auch umsetzen. Sinngemäß wie oben vom Kollegen @em-pie beschrieben, aber nur für den Versand, also IMO nur Port 25 denn nur für den Versand brauchst Du die IP des Hosters und 465 und/oder 587 sind Ports, mit denen Deine Clients an Deinem Server angebunden werden, nicht aber Ports mit denen Dein Server sendet.
Ob das alles sinnvoll ist, ist fraglich, ich hab' das damals mal als "Spielprojekt" gemacht, weil viele hier im Forum immer gesagt haben, Mailserver zu hause geht nicht, aber das Projekt hat lange gehalten
Man lernt eine Menge dabei, daher mach es Viele Grüße, commodity
1
Läuft bei mir seid mehr als einem Jahr. Der Mailcow ist bei mir Zuhause auf dem Server installiert und geht über einen SSL Tunnel zum Hetzner Server(Wobei meine Firewall die VPN Verbindung aufbaut). Der Hetzner Server ist der VPN Server, meine Firewall ist der VPN Client. Alle Mail relevanten Ports werden an den eigenen Server weitergeleitet. In meiner Firewall sind Regeln angelegt worden, die dafür sorgen das der ausgehende Traffic des Mailcows auch über den Tunnel und schließlich über die Internet Verbindung des Hetzner Servers raus gehen.
Funktioniert einwandfrei und ohne Probleme.
Dein vorhaben ist daher umsetzbar und auch von mir empfohlen. Somit umgehst du als Privater Nutzer die dynamische ISP IP oder gar CGNAT IP.
Liebe Grüße
Üba3ba
Funktioniert einwandfrei und ohne Probleme.
Dein vorhaben ist daher umsetzbar und auch von mir empfohlen. Somit umgehst du als Privater Nutzer die dynamische ISP IP oder gar CGNAT IP.
Liebe Grüße
Üba3ba
Hi, danke für deinen Input. Klingt soweit schonmal gut
Hast du dazu ne grobe Konfiguration?
Weil dann möchte ich das auch so bei mir aufsetzen
Denke ein direkter WireGuard Tunnel sollte anstatt deiner Firewall Config auch möglich sein.
Also dass mein Heimserver 10.0.0.2 im WireGuard hat und der RZ Server 10.0.0.1
In meinem Testsetup hat der Tunnel auch funktioniert, mir geht's nur primär um die Weiterleitungen. Werde da wahrscheinlich mit iptables arbeiten müssen.
- Fabi
Hast du dazu ne grobe Konfiguration?
Weil dann möchte ich das auch so bei mir aufsetzen
Denke ein direkter WireGuard Tunnel sollte anstatt deiner Firewall Config auch möglich sein.
Also dass mein Heimserver 10.0.0.2 im WireGuard hat und der RZ Server 10.0.0.1
In meinem Testsetup hat der Tunnel auch funktioniert, mir geht's nur primär um die Weiterleitungen. Werde da wahrscheinlich mit iptables arbeiten müssen.
- Fabi
In meinem Testsetup hat der Tunnel auch funktioniert, mir geht's nur primär um die Weiterleitungen. Werde da wahrscheinlich mit iptables arbeiten müssen.
Richtig! Das kannst du mit iptables lösen. Habe ich auch so gemacht.
Ich habe einen openvpn Server installiert und eingerichtet. Wird aber mit Wireguard auch funktionieren.
Ich kann dir meine iptables rules mal geben:
-A PREROUTING -i eth0 -p tcp -m tcp --dport 443 -j DNAT --to-destination 172.16.20.5:443
-A PREROUTING -i eth0 -p tcp -m tcp --dport 993 -j DNAT --to-destination 172.16.20.6:993
-A PREROUTING -i eth0 -p tcp -m tcp --dport 587 -j DNAT --to-destination 172.16.20.6:587
#-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 172.16.20.6:80
-A PREROUTING -i eth0 -p tcp -m tcp --dport 25 -j DNAT --to-destination 172.16.20.6:25
-A POSTROUTING -o eth0 -j MASQUERADEWichtig ist hierbei folgende Zeile:
-A POSTROUTING -o eth0 -j MASQUERADESie sorgt dafür dass nur Verkehr der über das eth0 rausgeht, mit der public ip des vservers maskiert wird. Verkehr der über das vpn interface geht, wollen wir nicht maskieren, da wir ja die public ip's am Mailcow Server sehen wollen, die sich mit diesem verbinden.
Das war mir wichtig, da ich alles aktiv monitore.
Port 25 muss auch weitergeleitet werden. Für die Mail Server zu Mail Server Kommunikation
Viel Spaß bei der Umsetzung.
1
Das sieht super aus und spart dann den zweiten Mailserver.
IMO sind die regeln in Zeile 16-17 aber überflüssig, weil sie Clients betreffen. Interne Clients connecten direkt mit dem Mailserver, können also die Umleitung gar nicht verwenden. Externe Clients verwenden sie auch nicht, denn sie kommen ja von extern und müssen von dort auf den heimischen Server zugreifen können. Dafür müssen die Ports für IMAP und Submission natürlich geöffnet und zum heimischen Server weitergeleitet werden, damit sie connecten können.
Viele Grüße, commodity
IMO sind die regeln in Zeile 16-17 aber überflüssig, weil sie Clients betreffen. Interne Clients connecten direkt mit dem Mailserver, können also die Umleitung gar nicht verwenden. Externe Clients verwenden sie auch nicht, denn sie kommen ja von extern und müssen von dort auf den heimischen Server zugreifen können. Dafür müssen die Ports für IMAP und Submission natürlich geöffnet und zum heimischen Server weitergeleitet werden, damit sie connecten können.
Viele Grüße, commodity
Also, zwei Aspekte:
1. es macht Sinn, wenn du als Roadwarrior ohne VPN-Aufbau auf deinen heimischen IMAP zugreifen können willst. Dann kannst du z.B. auf dem Hetzner-Ding einen Webmailer installieren, fertig. Portweiterleitung würde ich ungeschützt nicht machen.
2. wenn es um Mailversand geht, ist das Problem ja häufig, dass Dialup-IPs auf vielen RBLS sind. Man kriegt also kaum was los.
Ein VPN kann hier eine mögliche Lösung dafür sein. Eine andere ganz einfach auf dem Hetzner-System einen kleinen Postfix laufen lassen, und diesen im Homeserver als Smarthost eintragen, fertig. Das geht dann auch ohne VPN.
Für eingehende Mails gilt dasselbe: man könnte auf dem Hetzner ein Store+Forward-Postfach einrichten, dein Homeserver holt regelmäßig die Sache ab, fertig. Das geht dann völlig ohne VPN.
Wenn aber natürlich beide Server miteinander sprechen sollen, dann VPN.
1. es macht Sinn, wenn du als Roadwarrior ohne VPN-Aufbau auf deinen heimischen IMAP zugreifen können willst. Dann kannst du z.B. auf dem Hetzner-Ding einen Webmailer installieren, fertig. Portweiterleitung würde ich ungeschützt nicht machen.
2. wenn es um Mailversand geht, ist das Problem ja häufig, dass Dialup-IPs auf vielen RBLS sind. Man kriegt also kaum was los.
Ein VPN kann hier eine mögliche Lösung dafür sein. Eine andere ganz einfach auf dem Hetzner-System einen kleinen Postfix laufen lassen, und diesen im Homeserver als Smarthost eintragen, fertig. Das geht dann auch ohne VPN.
Für eingehende Mails gilt dasselbe: man könnte auf dem Hetzner ein Store+Forward-Postfach einrichten, dein Homeserver holt regelmäßig die Sache ab, fertig. Das geht dann völlig ohne VPN.
Wenn aber natürlich beide Server miteinander sprechen sollen, dann VPN.
Um Clients die sich aus dem LAN auf den Mailserver zugreifen wollen, habe ich splitt DNS eingerichtet.
Vergessen zu erwähnen.
@Gentooist
Du hast recht mit der Sicherheit. Ohne Firewall ist das nicht zu empfehlen.
Den Rest finde ich zu umständlich.
Wenn alles richtig eingerichtet ist, DNS, DKIM, SPF und Reverse DNS, dann kann der Server auch zuverlässig Mails versenden. Ist bei mir zumindest der Fall.
Ach ja. Falls dein vServer auch bei Hetzner ist, musst die mit einem Ticket beantragen das Port 25 geöffnet werden soll. Sonst bleibt dieser geschlossen.
@commodity
Was meinst du genau bitte? Das verwirrt mich jetzt.
Kannst du das näher erläutern?
Vergessen zu erwähnen.
@Gentooist
Du hast recht mit der Sicherheit. Ohne Firewall ist das nicht zu empfehlen.
Den Rest finde ich zu umständlich.
Wenn alles richtig eingerichtet ist, DNS, DKIM, SPF und Reverse DNS, dann kann der Server auch zuverlässig Mails versenden. Ist bei mir zumindest der Fall.
Ach ja. Falls dein vServer auch bei Hetzner ist, musst die mit einem Ticket beantragen das Port 25 geöffnet werden soll. Sonst bleibt dieser geschlossen.
@commodity
Was meinst du genau bitte? Das verwirrt mich jetzt.
Kannst du das näher erläutern?
@commodity
Die Weiterleitung sind ganz sicher nötig. Klar, in der Hetzner Firewall müssen die Ports für IMAP,SMTP und HTTP geöffnet werden. Dann werde diese Ports über den Tunnel zum Server im LAN weitergeleitet mit iptables.
SOmit können externe Clients sich auf dem Mailserver verbinden und MAils via IMAP abrufen und über SMTP versenden. Der Webmailer und die Mailcow Admin UI sind auch erreichbar über HTTPS.
Interne Clients können sich auch auf den Mailserver verbinden, wenn in den Clients die Ip's korrekt eingetragen werden oder man ein splitt DNS Setup fährt.
Splitt DNS ist meiner Meinung nach zu bevorzugen.
MO sind die regeln in Zeile 16-17 aber überflüssig, weil sie Clients betreffen. Interne Clients connecten direkt mit dem Mailserver, können also die Umleitung gar nicht verwenden. Externe Clients verwenden sie auch nicht, denn sie kommen ja von extern und müssen von dort auf den heimischen Server zugreifen können. Dafür müssen die Ports für IMAP und Submission natürlich geöffnet und zum heimischen Server weitergeleitet werden, damit sie connecten können.
Die Weiterleitung sind ganz sicher nötig. Klar, in der Hetzner Firewall müssen die Ports für IMAP,SMTP und HTTP geöffnet werden. Dann werde diese Ports über den Tunnel zum Server im LAN weitergeleitet mit iptables.
SOmit können externe Clients sich auf dem Mailserver verbinden und MAils via IMAP abrufen und über SMTP versenden. Der Webmailer und die Mailcow Admin UI sind auch erreichbar über HTTPS.
Interne Clients können sich auch auf den Mailserver verbinden, wenn in den Clients die Ip's korrekt eingetragen werden oder man ein splitt DNS Setup fährt.
Splitt DNS ist meiner Meinung nach zu bevorzugen.
Vielleicht verstehe ich Deinen Aufbau falsch, aber an sich "versenden" Clients keine Mails. Das macht der Mailserver. Die Clients übergeben ihm diese und der schickt sie ins Netz (zum Zielserver). Diesese Kommunikation findet allein über Port 25 statt.
Wenn sich interne oder externe Clients per IMAP bzw. SMTP-Submission verbinden, verbinden sie sich auf Port 143,465,587,993. In Deinem Fall also auf Port 993 und 587 Deines Homeservers. Von dort werden die Mails dann über Port 25 ins Netz geschickt (s.o.). Wozu also solle das in Zeile 16/17 stehende DST-NAT für Port 587,993 zum Hetzner-Server dienen? Da wird nie ein Bit drüberlaufen.
Edit: Wahrscheinlich nutzt Du die IP des Hetzner auch eingehend (was nicht nötig wäre)? Dann brauchst Du natürlich Weiterleitungen von dort auf Deinen internen Server. Ich bin davon ausgegangen, dass die o.b. Konfiguration aber die Deiner heimischen Firewall ist.
Viele Grüße, commodity
Wenn sich interne oder externe Clients per IMAP bzw. SMTP-Submission verbinden, verbinden sie sich auf Port 143,465,587,993. In Deinem Fall also auf Port 993 und 587 Deines Homeservers. Von dort werden die Mails dann über Port 25 ins Netz geschickt (s.o.). Wozu also solle das in Zeile 16/17 stehende DST-NAT für Port 587,993 zum Hetzner-Server dienen? Da wird nie ein Bit drüberlaufen.
Edit: Wahrscheinlich nutzt Du die IP des Hetzner auch eingehend (was nicht nötig wäre)? Dann brauchst Du natürlich Weiterleitungen von dort auf Deinen internen Server. Ich bin davon ausgegangen, dass die o.b. Konfiguration aber die Deiner heimischen Firewall ist.
Viele Grüße, commodity
Wozu also solle das in Zeile 16/17 stehende DST-NAT für Port 587,993 zum Hetzner-Server dienen? Da wird nie ein Bit drüberlaufen.
Mein vServer ist die zentralle Anlaufstelle für alle eingehenden Verbindungen.
A und MX Records zeigen auf die public ip des vServers.
@fabichan
Habe etwas vergessen. Wenn du auf dem vServer mit iptables Ports weiterleiten möchtest, musst du auch das ip forwarding aktivieren.
Füge oder ändere die folgende Zeile:
Lade die Konfiguration neu:
Habe etwas vergessen. Wenn du auf dem vServer mit iptables Ports weiterleiten möchtest, musst du auch das ip forwarding aktivieren.
sudo nano /etc/sysctl.confnet.ipv4.ip_forward = 1Lade die Konfiguration neu:
sudo sysctl -p
Danke euch soweit. Ich werd das vielleicht heute noch versuchen und gebe bescheid, wie ich es jetzt hinbekommen habe.
Danke soweit für den ganzen Input
Danke soweit für den ganzen Input
hmmm, ich hab das jetzt versucht mit dem Setup.
Die VPN verbindung zwischen den hosts ist absolut kein Problem; die hosts können sich auch gegenseitig pingen.
Aber die Port weiterleitung funktionert scheinbar nicht.
Hab testweise einen http server auf port 25 auf dem Heimserver und dann die Public IP angesprochen auf Port 25... leider ohne erfolg
Die VPN verbindung zwischen den hosts ist absolut kein Problem; die hosts können sich auch gegenseitig pingen.
Aber die Port weiterleitung funktionert scheinbar nicht.
Hab testweise einen http server auf port 25 auf dem Heimserver und dann die Public IP angesprochen auf Port 25... leider ohne erfolg
Der Hetzner Server hat über die VPN dir 10.0.0.1 und der heim Server die 10.0.0.2
Meine iptables soweit
Am VPN Server hab ich das so:
Meine iptables soweit
iptables -t nat -A PREROUTING -p tcp --dport 25 -j DNAT --to-destination 10.0.0.2:25
iptables -t nat -A PREROUTING -p tcp --dport 465 -j DNAT --to-destination 10.0.0.2:465
iptables -t nat -A PREROUTING -p tcp --dport 587 -j DNAT --to-destination 10.0.0.2:587
iptables -t nat -A PREROUTING -p tcp --dport 993 -j DNAT --to-destination 10.0.0.2:993
iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination 10.0.0.2:443Am VPN Server hab ich das so:
[Interface]
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = key
PostUp = iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o enp5s0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -s 10.0.0.0/24 -o enp5s0 -j MASQUERADEZitat von @Ueba3ba:
Mein vServer ist die zentralle Anlaufstelle für alle eingehenden Verbindungen.
A und MX Records zeigen auf die public ip des vServers.
Mein vServer ist die zentralle Anlaufstelle für alle eingehenden Verbindungen.
A und MX Records zeigen auf die public ip des vServers.
Ah, dann ist das oben Deine Firewall-Config für den Hetzner-Server. Dann brauchst Du die Weiterleitungen natürlich. Ich bin davon ausgegangen, dass es die Config für die Weiterleitung des Home-Servers ist (darum ging es dem TO ja eigentlich). Geklärt.
Dann ist das aber nur die halbe Miete, denn der Homeserver braucht ja auch noch ein DST-NAT für P25 zum Hetzner-Server, um versenden zu können.
Viele Grüße, commodity
Dann ist das aber nur die halbe Miete, denn der Homeserver braucht ja auch noch ein DST-NAT für P25 zum Hetzner-Server, um versenden zu können.
Hab ich. Der Mailcow geht über die VPN ins Internet, über den VPS.
@fabichan
Hast du bei Hetzner eine Firewall angelegt und die entsprechenden Ports dort geöffnet?
@Ueba3ba
Nein, hab keine Hetzner Firewall an, hab nur ufw am Debian im RZ an
Die ports hatte ich entsprechend geöffnet
Aber irgendwie kann ich nichts ansprechen
Nein, hab keine Hetzner Firewall an, hab nur ufw am Debian im RZ an
Die ports hatte ich entsprechend geöffnet
Aber irgendwie kann ich nichts ansprechen
Du kannst deshalb nicht ansprechen, da du in deinem Hetzner Portal keine Firewall erstellt hast . Du musst eine erstellen, Ports öffnen und die Firewall deinem VPS zuweisen.
Hetzner Firewall
Hetzner Firewall
@Ueba3ba ich kann aber alle anderen Dienste am Server ansprechen, ist ja kein VPS ist ein Dedizierter Server. Nur meine forwarded ports funktioniert nicht richtig.
Auch sind laut nmap die ports offen
state closed da ja jetzt erstmal nix mehr lauscht
Hab auch testweise versucht, dass 2222 an intern 22 geforwarded wird, auch das klappte leider nicht
Auch sind laut nmap die ports offen
Host is up (0.0070s latency).
Not shown: 989 filtered tcp ports (no-response)
PORT STATE SERVICE
22/tcp open ssh
25/tcp closed smtp
80/tcp open http
110/tcp closed pop3
143/tcp closed imap
443/tcp open https
465/tcp closed smtps
587/tcp closed submission
993/tcp closed imaps
995/tcp closed pop3s
2222/tcp closed EtherNetIP-1state closed da ja jetzt erstmal nix mehr lauscht
Hab auch testweise versucht, dass 2222 an intern 22 geforwarded wird, auch das klappte leider nicht
Kannst du das VPN/WG Interface auf deinem Heimserver pingen?
Request und Response gehen durch?
Kannst du die IP deines Ethernet Interfaces deines Heimservers pingen?
Sind Client und Servernetzwerk in deiner WG Config eingetragen?
Zeig uns mal deine WG und IP Konfiguration des Heim und Ded. Servers
Request und Response gehen durch?
Kannst du die IP deines Ethernet Interfaces deines Heimservers pingen?
Sind Client und Servernetzwerk in deiner WG Config eingetragen?
Zeig uns mal deine WG und IP Konfiguration des Heim und Ded. Servers
Zitat von @Ueba3ba:
Kannst du das VPN/WG Interface auf deinem Heimserver pingen?
Request und Response gehen durch?
Ja das gehtKannst du das VPN/WG Interface auf deinem Heimserver pingen?
Request und Response gehen durch?
Kannst du die IP deines Ethernet Interfaces deines Heimservers pingen?
Sind Client und Servernetzwerk in deiner WG Config eingetragen?
Zeig uns mal deine WG und IP Konfiguration des Heim und Ded. Servers
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 10:7c:61:49:f7:7c brd ff:ff:ff:ff:ff:ff
inet 46.4.xxx.xxx/27 brd 46.4.80.191 scope global enp5s0
valid_lft forever preferred_lft forever
inet 46.4.xxx.xxx/27 scope global enp5s0
valid_lft forever preferred_lft forever
inet6 2a01:4f8:202:20c4::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::127c:61ff:fe49:f77c/64 scope link
valid_lft forever preferred_lft forever
22: mailconnect: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 10.0.0.1/24 scope global mailconnect
valid_lft forever preferred_lft forever$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 6c:4b:90:c0:e9:a8 brd ff:ff:ff:ff:ff:ff
inet 192.168.178.251/24 brd 192.168.178.255 scope global enp1s0f0
valid_lft forever preferred_lft forever
inet6 fe80::6e4b:90ff:fec0:e9a8/64 scope link
valid_lft forever preferred_lft forever
23: mailconnect: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 10.0.0.2/24 scope global mailconnect
valid_lft forever preferred_lft foreverDann hier einmal die Wireguard Konfiguration am Server:
[Interface]
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = key
PostUp = iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o enp5s0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -s 10.0.0.0/24 -o enp5s0 -j MASQUERADE
[Peer]
PublicKey = key
AllowedIPs = 10.0.0.2/32WG Config am Heimserver:
[Interface]
Address = 10.0.0.2/24
PrivateKey = key
[Peer]
PublicKey = key
Endpoint = xxx.xxx.xxx.xxx:51820
AllowedIPs = 10.0.0.1/32
PersistentKeepalive = 25
Danke. Anonymisiere mal bitte noch deine beiden public ip's vom dedicated Server.
Dannbitte noch von beiden Serven die routing Tabelle mit
Dannbitte noch von beiden Serven die routing Tabelle mit
ip route
Heimserver:
Am RZ Server:
@Ueba3ba oh danke, hatte ich nicht bedacht mit dem anonymisieren, danke dir
von den routing tables sieht mir das soweit korrekt aus, raus soll der mail traffic auch über die 2. pub ip am interface, denke da muss ich noch n SNAT machen, aber soweit ging ja schon nix auch auf der haupt IP
$ ip route
default via 192.168.178.1 dev enp1s0f0 onlink
10.0.0.0/24 dev mailconnect proto kernel scope link src 10.0.0.2
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.18.0.0/16 dev br-66c0dcb3fcc6 proto kernel scope link src 172.18.0.1 linkdown
172.19.0.0/16 dev br-e55074d68672 proto kernel scope link src 172.19.0.1
192.168.178.0/24 dev enp1s0f0 proto kernel scope link src 192.168.178.251 Am RZ Server:
# ip route
default via 46.4.xxx.xxx dev enp5s0 onlink
10.0.0.0/24 dev mailconnect proto kernel scope link src 10.0.0.1
46.4.xxx.xxx/27 dev enp5s0 proto kernel scope link src 46.4.xxx.xxx
46.4.xxx.xxx via 46.4.xxx.xxx dev enp5s0
46.4.xxx.xxx/27 via 46.4.xxx.xxx dev enp5s0
46.4.xxx.xxx/27 dev enp5s0 proto kernel scope link src 46.4.xxx.xxx
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.18.0.0/16 dev br-47be1b9c568b proto kernel scope link src 172.18.0.1@Ueba3ba oh danke, hatte ich nicht bedacht mit dem anonymisieren, danke dir
von den routing tables sieht mir das soweit korrekt aus, raus soll der mail traffic auch über die 2. pub ip am interface, denke da muss ich noch n SNAT machen, aber soweit ging ja schon nix auch auf der haupt IP
Die forwarding Regel mach mal bitte auf die 192.168.178.251, dann sollte es eigentlich funktionieren.
Wobei, ich sehe in der Routingtabelle am RZ Server dein Heimnetzwerk nicht.
Da scheint etwas nicht richtig eingerichtet zu sein.
Wobei, ich sehe in der Routingtabelle am RZ Server dein Heimnetzwerk nicht.
Da scheint etwas nicht richtig eingerichtet zu sein.
Zitat von @Ueba3ba:
Die forwarding Regel mach mal bitte auf die 192.168.178.251, dann sollte es eigentlich funktionieren.
Wobei, ich sehe in der Routingtabelle am RZ Server dein Heimnetzwerk nicht.
Da scheint etwas nicht richtig eingerichtet zu sein.
Die forwarding Regel mach mal bitte auf die 192.168.178.251, dann sollte es eigentlich funktionieren.
Wobei, ich sehe in der Routingtabelle am RZ Server dein Heimnetzwerk nicht.
Da scheint etwas nicht richtig eingerichtet zu sein.
Also denke, dann sollte ein
ip route add 192.168.178.0/24 via 10.0.0.2reichen, dann sollte die route stehen, richtig?
wobei er ja nicht direkt ins heimnetz muss glaube. auf 10.0.0.2 kommt man direkt an den server, wo der mailserver laufen soll
Nein, das wird nichts bringen. Du musst in der Peer Section der WG Config auf dem Client deine lokale ip 192.168.178.251 zu AllowedIPs hinzufügen.
Ich denke mal das dein Heimserver der WG Cleint(Peer) ist.
Ich denke mal das dein Heimserver der WG Cleint(Peer) ist.
Zitat von @Ueba3ba:
Nein, das wird nichts bringen. Du musst in der Peer Section der WG Config auf dem Client deine lokale ip 192.168.178.251 zu AllowedIPs hinzufügen.
Nein, das wird nichts bringen. Du musst in der Peer Section der WG Config auf dem Client deine lokale ip 192.168.178.251 zu AllowedIPs hinzufügen.
[Interface]
Address = 10.0.0.2/24
PrivateKey = key
[Peer]
PublicKey = key
Endpoint = 46.4.xxx.xxx:51820
AllowedIPs = 10.0.0.1/32, 192.168.178.251/24
PersistentKeepalive = 25so dann in der heimserver config, oder soll die am RZ server gesetzt sein die IP?
Ich denke mal das dein Heimserver der WG Cleint(Peer) ist.
Ja der RZ Server ist der Wireguard server und der Heimserver der Peer
So schaut der Peer gut aus. Jetzt noch WG auf beiden Seiten neu starten und noch mal die Routingtabelle beider Server posten bitte.
Zitat von @Ueba3ba:
So schaut der Peer gut aus. Jetzt noch WG auf beiden Seiten neu starten und noch mal die Routingtabelle beider Server posten bitte.
So schaut der Peer gut aus. Jetzt noch WG auf beiden Seiten neu starten und noch mal die Routingtabelle beider Server posten bitte.
Heimserver:
default via 192.168.178.1 dev enp1s0f0 onlink
10.0.0.0/24 dev mailconnect proto kernel scope link src 10.0.0.2
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.18.0.0/16 dev br-66c0dcb3fcc6 proto kernel scope link src 172.18.0.1 linkdown
172.19.0.0/16 dev br-e55074d68672 proto kernel scope link src 172.19.0.1
192.168.178.0/24 dev enp1s0f0 proto kernel scope link src 192.168.178.251
192.168.178.251 dev mailconnect scope linkRZ Server:
default via 46.4.xxx.xxx dev enp5s0 onlink
10.0.0.0/24 dev mailconnect proto kernel scope link src 10.0.0.1
46.4.xxx.xxx/27 dev enp5s0 proto kernel scope link src 46.4.xxx.xxx
46.4.xxx.xxx via 46.4.xxx.xxx dev enp5s0
46.4.xxx.xxx/27 via 46.4.xxx.xxx dev enp5s0
46.4.xxx.xxx/27 dev enp5s0 proto kernel scope link src 46.4.xxx.xxx
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.18.0.0/16 dev br-47be1b9c568b proto kernel scope link src 172.18.0.1
Es fehlt die Route vom RZ Server zu deinem Heimserver.
Hast du auf dem RZ Server auch ip forwarding aktiviert?
Das ist natürlich völliger Quatsch. Kommt davon wenn ich während meiner Arbeit noch im Forum helfe. Sorry.
Es muss natürlich dort stehen
oder nur für den Host
Hast du auf dem RZ Server auch ip forwarding aktiviert?
AllowedIPs = 10.0.0.1/32, 192.168.178.251/24 Das ist natürlich völliger Quatsch. Kommt davon wenn ich während meiner Arbeit noch im Forum helfe. Sorry.
Es muss natürlich
192.168.178.0/24oder nur für den Host
192.168.178.251/32Zitat von @Ueba3ba:
Es fehlt die Route vom RZ Server zu deinem Heimserver.
Hast du auf dem RZ Server auch ip forwarding aktiviert?
Es fehlt die Route vom RZ Server zu deinem Heimserver.
Hast du auf dem RZ Server auch ip forwarding aktiviert?
Ja ist aktiv
AllowedIPs = 10.0.0.1/32, 192.168.178.251/24 Das ist natürlich völliger Quatsch. Kommt davon wenn ich während meiner Arbeit noch im Forum helfe. Sorry.
Alles gut. Ich bin so schon sehr dankbar für die hilfe!
Es muss natürlich
192.168.178.0/24oder nur für den Host
192.168.178.251/32# wg-quick up mailconnect
[#] ip link add mailconnect type wireguard
[#] wg setconf mailconnect /dev/fd/63
[#] ip -4 address add 10.0.0.2/24 dev mailconnect
[#] ip link set mtu 1420 up dev mailconnect
[#] ip -4 route add 192.168.178.0/24 dev mailconnect
RTNETLINK answers: File exists
[#] ip link delete dev mailconnectKommt jetzt n fehler, dass die route bereits existiert am heimserver
Sicher, dass die route nicht irgendwie am RZ Server muss?
Füge die route einmal manuell hinzu auf dem RZ Server
Passe das Interface gegebenenfalls an dein Interface an.
route add -net 192.168.178.0/24 dev mailconnect- wg-quick up mailconnect
[#] wg setconf mailconnect /dev/fd/63
[#] ip -4 address add 10.0.0.2/24 dev mailconnect
[#] ip link set mtu 1420 up dev mailconnect
[#] ip -4 route add 192.168.178.251/32 dev mailconnect
gut, mit .251/32 geht das WG Interface wieder zu starten
Zitat von @Ueba3ba:
Füge die route einmal manuell hinzu auf dem RZ Server
Passe das Interface gegebenenfalls an dein Interface an.
Füge die route einmal manuell hinzu auf dem RZ Server
route add -net 192.168.178.0/24 dev mailconnect~ # route add -net 192.168.178.0/24 dev mailconnect
~ # ping 192.168.178.251
PING 192.168.178.251 (192.168.178.251) 56(84) bytes of data.
From 10.0.0.1 icmp_seq=1 Destination Host Unreachable
ping: sendmsg: Required key not available
From 10.0.0.1 icmp_seq=2 Destination Host Unreachable
ping: sendmsg: Required key not available
From 10.0.0.1 icmp_seq=3 Destination Host Unreachable
ping: sendmsg: Required key not available
^C
--- 192.168.178.251 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2025mshab ich soweit, aber jetzt bin ich da echt überfragt, ich sollte doch mit der route jetzt pingen können, da mailconnect ja das interface ist
10.0.0.2 zu pingen klappt aber
Kommt jetzt n fehler, dass die route bereits existiert am heimserver
Sicher, dass die route nicht irgendwie am RZ Server muss?
Sicher, dass die route nicht irgendwie am RZ Server muss?
Ich habe noch nie einen WG Tunnel gebaut. Immer nur oVPN.
Du hast natürlich recht, die Route zu deinem Heimserver muss im RZ Server definiert werden. Füge einmal der WG Config auf dem RZ Server in der Peer Section die ip deines Heim Servers hinzu. Bei AloowedIPs. WG setzt Routen automatisch für IP's die in AllowedIPs stehen.
Entferne also in der WG Config deines Heimservers die ip wieder(192.168.178.251/23)
10.0.0.2 zu pingen klappt aber
Ping auf 192.168.178.251 muss funktionieren
Zitat von @Ueba3ba:
Ich habe noch nie einen WG Tunnel gebaut. Immer nur oVPN.
Du hast natürlich recht, die Route zu deinem Heimserver muss im RZ Server definiert werden. Füge einmal der WG Config auf dem RZ Server in der Peer Section die ip deines Heim Servers hinzu. Bei AloowedIPs. WG setzt Routen automatisch für IP's die in AllowedIPs stehen.
Entferne also in der WG Config deines Heimservers die ip wieder(192.168.178.251/23)
Kommt jetzt n fehler, dass die route bereits existiert am heimserver
Sicher, dass die route nicht irgendwie am RZ Server muss?
Sicher, dass die route nicht irgendwie am RZ Server muss?
Ich habe noch nie einen WG Tunnel gebaut. Immer nur oVPN.
Du hast natürlich recht, die Route zu deinem Heimserver muss im RZ Server definiert werden. Füge einmal der WG Config auf dem RZ Server in der Peer Section die ip deines Heim Servers hinzu. Bei AloowedIPs. WG setzt Routen automatisch für IP's die in AllowedIPs stehen.
Entferne also in der WG Config deines Heimservers die ip wieder(192.168.178.251/23)
Gut, das klappt jetzt. Ich kann vom RZ Server 192.168.178.251 pingen und es kommt eine Antwort. Jetzt sollte doch auch das Port forwarding klappen, muss ich gleich testen, aber vorweg hab ich die anmerkung, dass der ausgangstraffic des mailservers über die 2. IP soll, der rest aber über die erste im RZ server. Denke wird dann etwas mit SNAT sein(?)
SSH Beispiel sollte also
sein, richtig?
iptables -t nat -D PREROUTING -p tcp --dport 2222 -j DNAT --to-destination 192.168.178.251:22Gut, das klappt jetzt. Ich kann vom RZ Server 192.168.178.251 pingen und es kommt eine Antwort.
Freut mich das es funktioniert.Jetzt sollte doch auch das Port forwarding klappen
Richtig, jetzt sollte es funktionieren.Willst du nur Verbindungen zu port 25 über den Tunnel nach drau0en schicken, oder soll alles über den Tunnel gehen?
Zitat von @Ueba3ba:
Willst du nur Verbindungen zu port 25 über den Tunnel nach drau0en schicken, oder soll alles über den Tunnel gehen?
Gut, das klappt jetzt. Ich kann vom RZ Server 192.168.178.251 pingen und es kommt eine Antwort.
Freut mich das es funktioniert.Jetzt sollte doch auch das Port forwarding klappen
Richtig, jetzt sollte es funktionieren.Willst du nur Verbindungen zu port 25 über den Tunnel nach drau0en schicken, oder soll alles über den Tunnel gehen?
Ich möchte nur den mail traffic über das RZ schicken, der rest soll alles lokal übers Internet zuhause rauslaufen.
Dann musst du Policy-Based Routing auf deinem Heim-Server einrichten.
Willst du IMAP und SMTP Verbindungen an deinem Heim-Server oder am RZ Server entgegennehmen?
Wenn es nur um den Mailversand geht(Port25), dann musst du nur sicherstellen das alle Verbindungen an Port 25 über den Tunnel gesendet werden und mit MASQUERADE
mit einer deiner beiden public ips maskiert wird. SNAT.
Willst du IMAP und SMTP Verbindungen an deinem Heim-Server oder am RZ Server entgegennehmen?
Wenn es nur um den Mailversand geht(Port25), dann musst du nur sicherstellen das alle Verbindungen an Port 25 über den Tunnel gesendet werden und mit MASQUERADE
mit einer deiner beiden public ips maskiert wird. SNAT.
Zitat von @Ueba3ba:
Dann musst du Policy-Based Routing auf deinem Heim-Server einrichten.
Willst du IMAP und SMTP Verbindungen an deinem Heim-Server oder am RZ Server entgegennehmen?
Wenn es nur um den Mailversand geht(Port25), dann musst du nur sicherstellen das alle Verbindungen an Port 25 über den Tunnel gesendet werden und mit MASQUERADE
mit einer deiner beiden public ips maskiert wird. SNAT.
Dann musst du Policy-Based Routing auf deinem Heim-Server einrichten.
Willst du IMAP und SMTP Verbindungen an deinem Heim-Server oder am RZ Server entgegennehmen?
Wenn es nur um den Mailversand geht(Port25), dann musst du nur sicherstellen das alle Verbindungen an Port 25 über den Tunnel gesendet werden und mit MASQUERADE
mit einer deiner beiden public ips maskiert wird. SNAT.
Also konkret will den gesamten Mail traffic in und out über den RZ server leiten. Also das komplette Programm einmal. Gesamter Traffic soll übers RZ, aber nur mail-related
Hab aber mal das forwarding anhand SSH getestet, leider scheint es kein erfolg zu haben
iptables -t nat -A PREROUTING -p tcp --dport 2222 -j DNAT --to-destination 192.168.178.251:22und dort dann ssh name@rzIp -p 2222 sollte doch gehen? oder lieg ich falsch?
SSH läuft ja ofc, aber bekomme keine verbindung
Poste bitte einmal die Ausgabe von auf dem RZ Server
sysctl net.ipv4.ip_forward~ # sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1wie erwartet auf 1, komisch
OK. IP Forwarding ist aktiv.
Hast du mit beiden public ips des RZ Servers versucht eine SSh Verbindung aufzubauen?
Hast du iptables neu gestartet nach dem du die Regel hinzugefügt hast?
Und installiere noch
um deine iptables Config speichern zu können
Lass mal ein tcpdump auf dem RZ Server laufen wenn du die SSH Verbindung aufbaust.
und poste ein paar Zeilen der Ausgabe
Hast du mit beiden public ips des RZ Servers versucht eine SSh Verbindung aufzubauen?
Hast du iptables neu gestartet nach dem du die Regel hinzugefügt hast?
systemctl restart iptablesUnd installiere noch
apt install iptables-persistentLass mal ein tcpdump auf dem RZ Server laufen wenn du die SSH Verbindung aufbaust.
tcpdump -i any port 2222und poste ein paar Zeilen der Ausgabe
Zitat von @Ueba3ba:
OK. IP Forwarding ist aktiv.
Hast du mit beiden public ips des RZ Servers versucht eine SSh Verbindung aufzubauen?
Hast du iptables neu gestartet nach dem du die Regel hinzugefügt hast?
OK. IP Forwarding ist aktiv.
Hast du mit beiden public ips des RZ Servers versucht eine SSh Verbindung aufzubauen?
Hast du iptables neu gestartet nach dem du die Regel hinzugefügt hast?
systemctl restart iptablesEs gibt bei mir kein Service mit dem namen (Debian 12)
Und installiere noch
apt install iptables-persistentDas will scheinbar ufw löschen, was ich ungerne möchte, scheint aber mit iptables-save > /etc/iptables/rules.v4 manuell zu gehen
Lass mal ein tcpdump auf dem RZ Server laufen wenn du die SSH Verbindung aufbaust.
und poste ein paar Zeilen der Ausgabe
kann ich gleich mal machentcpdump -i any port 2222und poste ein paar Zeilen der Ausgabe
tcpdump -i any port 2222
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
11:35:57.643113 enp5s0 In IP xxxxx.dynamic.kabel-deutschland.de.60156 > mail.host.me.2222: Flags [S], seq 2149412195, win 64860, options [mss 1380,sackOK,TS val 2469993696 ecr 0,nop,wscale 7], length 0
11:35:58.661657 enp5s0 In IP xxxxx.dynamic.kabel-deutschland.de.60156 > mail.host.me.2222: Flags [S], seq 2149412195, win 64860, options [mss 1380,sackOK,TS val 2469994716 ecr 0,nop,wscale 7], length 0
11:35:59.675687 enp5s0 In IP xxxxx.dynamic.kabel-deutschland.de.60156 > mail.host.me.2222: Flags [S], seq 2149412195, win 64860, options [mss 1380,sackOK,TS val 2469995729 ecr 0,nop,wscale 7], length 0
11:36:00.693111 enp5s0 In IP xxxxx.dynamic.kabel-deutschland.de.60156 > mail.host.me.2222: Flags [S], seq 2149412195, win 64860, options [mss 1380,sackOK,TS val 2469996743 ecr 0,nop,wscale 7], length 0
11:36:01.699977 enp5s0 In IP xxxxx.dynamic.kabel-deutschland.de.60156 > mail.host.me.2222: Flags [S], seq 2149412195, win 64860, options [mss 1380,sackOK,TS val 2469997756 ecr 0,nop,wscale 7], length 0
11:36:02.712988 enp5s0 In IP xxxxx.dynamic.kabel-deutschland.de.60156 > mail.host.me.2222: Flags [S], seq 2149412195, win 64860, options [mss 1380,sackOK,TS val 2469998769 ecr 0,nop,wscale 7], length 0
11:36:04.875093 enp5s0 In IP xxxxx.dynamic.kabel-deutschland.de.60156 > mail.host.me.2222: Flags [S], seq 2149412195, win 64860, options [mss 1380,sackOK,TS val 2470000929 ecr 0,nop,wscale 7], length 0
Passe bitte diese Regel noch an. Das Interface muss mit angegeben werden.
enp5s0 ist es glaub ich.
iptables -t nat -A PREROUTING -i deinInterface -p tcp --dport 2222 -j DNAT --to-destination 192.168.178.251:22enp5s0 ist es glaub ich.
~ # iptables -t nat -A PREROUTING -i enp5s0 -p tcp --dport 2222 -j DNAT --to-destination 192.168.178.251:22ist jetzt drin, aber es geht weiterhin keine ssh verbindung testweise
ich mach mal einen tcp dump am heimserver
~# tcpdump -i any port 22
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
11:50:10.972049 enp1s0f0 Out IP debian-tc1.fritz.box.ssh > raspberrypi.fritz.box.60946: Flags [P.], seq 858799672:858799748, ack 2185231474, win 501, options [nop,nop,TS val 3268630133 ecr 249058368], length 76
11:50:10.975312 enp1s0f0 Out IP debian-tc1.fritz.box.ssh > raspberrypi.fritz.box.60946: Flags [P.], seq 76:280, ack 1, win 501, options [nop,nop,TS val 3268630137 ecr 249058368], length 204
11:50:10.995213 enp1s0f0 In IP raspberrypi.fritz.box.60946 > debian-tc1.fritz.box.ssh: Flags [.], ack 280, win 136, options [nop,nop,TS val 249058408 ecr 3268630133], length 0
11:50:11.051018 enp1s0f0 Out IP debian-tc1.fritz.box.ssh > raspberrypi.fritz.box.60946: Flags [P.], seq 280:900, ack 1, win 501, options [nop,nop,TS val 3268630212 ecr 249058408], length 620
11:50:11.112102 enp1s0f0 In IP raspberrypi.fritz.box.60946 > debian-tc1.fritz.box.ssh: Flags [.], ack 900, win 136, options [nop,nop,TS val 249058525 ecr 3268630212], length 0
11:50:11.152012 enp1s0f0 Out IP debian-tc1.fritz.box.ssh > raspberrypi.fritz.box.60946: Flags [P.], seq 900:1304, ack 1, win 501, options [nop,nop,TS val 3268630313 ecr 249058525], length 404
11:50:11.170122 enp1s0f0 In IP raspberrypi.fritz.box.60946 > debian-tc1.fritz.box.ssh: Flags [.], ack 1304, win 133, options [nop,nop,TS val 249058583 ecr 3268630313], length 0
11:50:11.255823 enp1s0f0 Out IP debian-tc1.fritz.box.ssh > raspberrypi.fritz.box.60946: Flags [P.], seq 1304:1716, ack 1, win 501, options [nop,nop,TS val 3268630417 ecr 249058583], length 412
11:50:11.335815 enp1s0f0 In IP raspberrypi.fritz.box.60946 > debian-tc1.fritz.box.ssh: Flags [.], ack 1716, win 136, options [nop,nop,TS val 249058748 ecr 3268630417], length 0
11:50:11.359688 enp1s0f0 Out IP debian-tc1.fritz.box.ssh > raspberrypi.fritz.box.60946: Flags [P.], seq 1716:2128, ack 1, win 501, options [nop,nop,TS val 3268630521 ecr 249058748], length 412
11:50:11.378991 enp1s0f0 In IP raspberrypi.fritz.box.60946 > debian-tc1.fritz.box.ssh: Flags [.], ack 2128, win 136, options [nop,nop,TS val 249058792 ecr 3268630521], length 0
11:50:11.463993 enp1s0f0 Out IP debian-tc1.fritz.box.ssh > raspberrypi.fritz.box.60946: Flags [P.], seq 2128:2540, ack 1, win 501, options [nop,nop,TS val 3268630625 ecr 249058792], length 412
11:50:11.539145 enp1s0f0 In IP raspberrypi.fritz.box.60946 > debian-tc1.fritz.box.ssh: Flags [.], ack 2540, win 136, options [nop,nop,TS val 249058952 ecr 3268630625], length 0
11:50:11.567946 enp1s0f0 Out IP debian-tc1.fritz.box.ssh > raspberrypi.fritz.box.60946: Flags [P.], seq 2540:2952, ack 1, win 501, options [nop,nop,TS val 3268630729 ecr 249058952], length 412
11:50:11.587340 enp1s0f0 In IP raspberrypi.fritz.box.60946 > debian-tc1.fritz.box.ssh: Flags [.], ack 2952, win 136, options [nop,nop,TS val 249059000 ecr 3268630729], length 0
11:50:11.672008 enp1s0f0 Out IP debian-tc1.fritz.box.ssh > raspberrypi.fritz.box.60946: Flags [P.], seq 2952:3364, ack 1, win 501, options [nop,nop,TS val 3268630833 ecr 249059000], length 412
11:50:11.744513 enp1s0f0 In IP raspberrypi.fritz.box.60946 > debian-tc1.fritz.box.ssh: Flags [.], ack 3364, win 136, options [nop,nop,TS val 249059157 ecr 3268630833], length 0
^C
17 packets captured
20 packets received by filter
0 packets dropped by kernel
root@debian-tc1:~# interessant
zur anmerkung, ich bin grade von der arbeit per vpn zuhause, was auf dem rapsberrypi läuft (Der vpn hat nix mit dem mail zu tun
Starte tcpdump bitte noch mal mit -nn
tcpdump -i any port 22 host 10.0.0.1 -nn~# tcpdump -i any port 22 -nn
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
11:53:35.819930 enp1s0f0 Out IP 192.168.178.251.22 > 192.168.178.250.60946: Flags [P.], seq 858842320:858842396, ack 2185231774, win 501, options [nop,nop,TS val 3268834981 ecr 249263226], length 76
11:53:35.822021 enp1s0f0 Out IP 192.168.178.251.22 > 192.168.178.250.60946: Flags [P.], seq 76:280, ack 1, win 501, options [nop,nop,TS val 3268834983 ecr 249263226], length 204
11:53:35.840875 enp1s0f0 In IP 192.168.178.250.60946 > 192.168.178.251.22: Flags [.], ack 76, win 136, options [nop,nop,TS val 249263253 ecr 3268834981], length 0
11:53:35.847599 enp1s0f0 In IP 192.168.178.250.60946 > 192.168.178.251.22: Flags [.], ack 280, win 135, options [nop,nop,TS val 249263260 ecr 3268834983], length 0
11:53:35.904167 enp1s0f0 Out IP 192.168.178.251.22 > 192.168.178.250.60946: Flags [P.], seq 280:860, ack 1, win 501, options [nop,nop,TS val 3268835065 ecr 249263260], length 580
11:53:35.904262 enp1s0f0 Out IP 192.168.178.251.22 > 192.168.178.250.60946: Flags [P.], seq 860:1064, ack 1, win 501, options [nop,nop,TS val 3268835066 ecr 249263260], length 204
11:53:35.927521 enp1s0f0 In IP 192.168.178.250.60946 > 192.168.178.251.22: Flags [.], ack 860, win 131, options [nop,nop,TS val 249263338 ecr 3268835065], length 0
11:53:35.927522 enp1s0f0 In IP 192.168.178.250.60946 > 192.168.178.251.22: Flags [.], ack 1064, win 130, options [nop,nop,TS val 249263338 ecr 3268835066], length 0
11:53:36.007984 enp1s0f0 Out IP 192.168.178.251.22 > 192.168.178.250.60946: Flags [P.], seq 1064:1628, ack 1, win 501, options [nop,nop,TS val 3268835169 ecr 249263338], length 564
11:53:36.008080 enp1s0f0 Out IP 192.168.178.251.22 > 192.168.178.250.60946: Flags [P.], seq 1628:1832, ack 1, win 501, options [nop,nop,TS val 3268835169 ecr 249263338], length 204
11:53:36.026218 enp1s0f0 In IP 192.168.178.250.60946 > 192.168.178.251.22: Flags [.], ack 1628, win 130, options [nop,nop,TS val 249263439 ecr 3268835169], length 0
11:53:36.026466 enp1s0f0 In IP 192.168.178.250.60946 > 192.168.178.251.22: Flags [.], ack 1832, win 136, options [nop,nop,TS val 249263439 ecr 3268835169], length 0
11:53:36.111901 enp1s0f0 Out IP 192.168.178.251.22 > 192.168.178.250.60946: Flags [P.], seq 1832:2404, ack 1, win 501, options [nop,nop,TS val 3268835273 ecr 249263439], length 572
11:53:36.111965 enp1s0f0 Out IP 192.168.178.251.22 > 192.168.178.250.60946: Flags [P.], seq 2404:2608, ack 1, win 501, options [nop,nop,TS val 3268835273 ecr 249263439], length 204
11:53:36.132161 enp1s0f0 In IP 192.168.178.250.60946 > 192.168.178.251.22: Flags [.], ack 2608, win 136, options [nop,nop,TS val 249263543 ecr 3268835273], length 0
11:53:36.216010 enp1s0f0 Out IP 192.168.178.251.22 > 192.168.178.250.60946: Flags [P.], seq 2608:3180, ack 1, win 501, options [nop,nop,TS val 3268835377 ecr 249263543], length 572
11:53:36.235531 enp1s0f0 In IP 192.168.178.250.60946 > 192.168.178.251.22: Flags [.], ack 3180, win 136, options [nop,nop,TS val 249263648 ecr 3268835377], length 0
11:53:36.320021 enp1s0f0 Out IP 192.168.178.251.22 > 192.168.178.250.60946: Flags [P.], seq 3180:3568, ack 1, win 501, options [nop,nop,TS val 3268835481 ecr 249263648], length 388
11:53:36.424192 enp1s0f0 Out IP 192.168.178.251.22 > 192.168.178.250.60946: Flags [P.], seq 3568:3788, ack 1, win 501, options [nop,nop,TS val 3268835585 ecr 249263648], length 220
11:53:36.442973 enp1s0f0 In IP 192.168.178.250.60946 > 192.168.178.251.22: Flags [.], ack 3568, win 136, options [nop,nop,TS val 249263855 ecr 3268835481], length 0
11:53:36.446296 enp1s0f0 In IP 192.168.178.250.60946 > 192.168.178.251.22: Flags [.], ack 3788, win 136, options [nop,nop,TS val 249263856 ecr 3268835585], length 0
^C
21 packets captured
25 packets received by filter
0 packets dropped by kernel.250 ist mein raspberry, ist nur VPN Traffic, oder?
Ist irgendwas auffälliges da?
Wir sehen hier nur die SSH Verbindung von deinem Pi zu deinem Heim Server.
Es ist keine Anfrage vom RZ Server zu sehen.
Überprüfe noch einmal die Firewall auf deinem RZ Server.
Es ist keine Anfrage vom RZ Server zu sehen.
Überprüfe noch einmal die Firewall auf deinem RZ Server.
Zitat von @Ueba3ba:
Wir sehen hier nur die SSH Verbindung von deinem Pi zu deinem Heim Server.
Es ist keine Anfrage vom RZ Server zu sehen.
Überprüfe noch einmal die Firewall auf deinem RZ Server.
Wir sehen hier nur die SSH Verbindung von deinem Pi zu deinem Heim Server.
Es ist keine Anfrage vom RZ Server zu sehen.
Überprüfe noch einmal die Firewall auf deinem RZ Server.
Port 2222 ist erlaubt
~ # ufw status
Status: active
To Action From
-- ------ ----
22/tcp ALLOW Anywhere
80/tcp ALLOW Anywhere
443/tcp ALLOW Anywhere
5432 ALLOW 144.76.xxx.xxx
51820/udp ALLOW Anywhere
2222 ALLOW Anywhere
25/tcp ALLOW Anywhere
465/tcp ALLOW Anywhere
587/tcp ALLOW Anywhere
143/tcp ALLOW Anywhere
993/tcp ALLOW Anywhere
110/tcp ALLOW Anywhere
995/tcp ALLOW Anywhere
4190/tcp ALLOW Anywhere
22/tcp (v6) ALLOW Anywhere (v6)
80/tcp (v6) ALLOW Anywhere (v6)
443/tcp (v6) ALLOW Anywhere (v6)
51820/udp (v6) ALLOW Anywhere (v6)
2222 (v6) ALLOW Anywhere (v6)
25/tcp (v6) ALLOW Anywhere (v6)
465/tcp (v6) ALLOW Anywhere (v6)
587/tcp (v6) ALLOW Anywhere (v6)
143/tcp (v6) ALLOW Anywhere (v6)
993/tcp (v6) ALLOW Anywhere (v6)
110/tcp (v6) ALLOW Anywhere (v6)
995/tcp (v6) ALLOW Anywhere (v6)
4190/tcp (v6) ALLOW Anywhere (v6)
Hast du auf dem HeimServer auch eine ufw am laufen?
Check diese gegebenenfalls auch mal ab.
Check diese gegebenenfalls auch mal ab.
Zitat von @Ueba3ba:
Hast du auf dem HeimServer auch eine ufw am laufen?
Check diese gegebenenfalls auch mal ab.
Hast du auf dem HeimServer auch eine ufw am laufen?
Check diese gegebenenfalls auch mal ab.
Am heimserver ist keine UFW, nicht installiert, da alles ja hinter einem Router ist
Hätte gedacht, das ganze ist einfacher. Aber irgendwo muss doch der wurm sein...
Zitat von @Ueba3ba:
Hast du auf dem HeimServer auch eine ufw am laufen?
Check diese gegebenenfalls auch mal ab.
Hast du auf dem HeimServer auch eine ufw am laufen?
Check diese gegebenenfalls auch mal ab.
Hab jetzt alle steps nochmal überprüft.. ich komm da echt nicht weiter.
Es scheint echt nur irgendwas mit dem forwarding nicht zu klappen..
Ping vom RZ Server zur Ip des Heim-Servers funktioniert?
Roten auf beiden Servern stimmen? Bitte noch mal posten.
Ping auf die WG Interfaces funktionieren?
Die iptables Rules sind korrekt eingerichet?
Zeig mal die Ausgabe von
auf dem RZ Server und entferne folgende Einträge:
in der WG Server Config.
Roten auf beiden Servern stimmen? Bitte noch mal posten.
Ping auf die WG Interfaces funktionieren?
Die iptables Rules sind korrekt eingerichet?
Zeig mal die Ausgabe von
iptables -t nat -vnLPostUp = iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o enp5s0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -s 10.0.0.0/24 -o enp5s0 -j MASQUERADEin der WG Server Config.
Ja klappt , ein ping von 192.168.178.251 kommt an und auch eine antwort
Heimserver:
Der output von iptables
und die einträge hab ich jetzt entfernt mit PostUp und PostDown
Roten auf beiden Servern stimmen? Bitte noch mal posten.
RZ Server:~ # ip r s
default via 46.4.80.161 dev enp5s0 onlink
10.0.0.0/24 dev mailconnect proto kernel scope link src 10.0.0.1
46.4.xxx.xxx/27 dev enp5s0 proto kernel scope link src 46.4.xxx.xxx
46.4.xxx.xxx via 46.4.xxx.xxx dev enp5s0
46.4.xxx.xxx/27 via 46.4.xxx.xxx dev enp5s0
46.4.xxx.xxx/27 dev enp5s0 proto kernel scope link src 46.4.xxx.xxx
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.18.0.0/16 dev br-47be1b9c568b proto kernel scope link src 172.18.0.1
192.168.178.0/24 dev mailconnect scope linkHeimserver:
~# ip r s
default via 192.168.178.1 dev enp1s0f0 onlink
10.0.0.0/24 dev mailconnect proto kernel scope link src 10.0.0.2
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.18.0.0/16 dev br-66c0dcb3fcc6 proto kernel scope link src 172.18.0.1 linkdown
172.19.0.0/16 dev br-e55074d68672 proto kernel scope link src 172.19.0.1
192.168.178.0/24 dev enp1s0f0 proto kernel scope link src 192.168.178.251Ping auf die WG Interfaces funktionieren?
Ja, kann von außen auf die pub IP pingen und über die WG VPN 10.0.0.x auchDie iptables Rules sind korrekt eingerichet?
Zeig mal die Ausgabe von
auf dem RZ Server und entferne folgende Einträge:
in der WG Server Config.
Zeig mal die Ausgabe von
iptables -t nat -vnLPostUp = iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o enp5s0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -s 10.0.0.0/24 -o enp5s0 -j MASQUERADEin der WG Server Config.
Der output von iptables
~ # iptables -t nat -vnL
Chain PREROUTING (policy ACCEPT 53300 packets, 2937K bytes)
pkts bytes target prot opt in out source destination
53202 2927K DOCKER 0 -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type LOCAL
106 6240 DNAT 6 -- enp5s0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:2222 to:10.0.0.2:22
0 0 DNAT 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:2222 to:192.168.178.251:22
0 0 DNAT 6 -- enp5s0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:2222 to:192.168.178.251:22
Chain INPUT (policy ACCEPT 28299 packets, 1614K bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 11609 packets, 713K bytes)
pkts bytes target prot opt in out source destination
2636 158K DOCKER 0 -- * * 0.0.0.0/0 !127.0.0.0/8 ADDRTYPE match dst-type LOCAL
Chain POSTROUTING (policy ACCEPT 11609 packets, 713K bytes)
pkts bytes target prot opt in out source destination
196 13010 MASQUERADE 0 -- * !br-47be1b9c568b 172.18.0.0/16 0.0.0.0/0
0 0 MASQUERADE 0 -- * !docker0 172.17.0.0/16 0.0.0.0/0
0 0 MASQUERADE 6 -- * * 172.18.0.5 172.18.0.5 tcp dpt:80
0 0 MASQUERADE 0 -- * enp5s0 10.0.0.0/24 0.0.0.0/0
Chain DOCKER (2 references)
pkts bytes target prot opt in out source destination
0 0 RETURN 0 -- br-47be1b9c568b * 0.0.0.0/0 0.0.0.0/0
0 0 RETURN 0 -- docker0 * 0.0.0.0/0 0.0.0.0/0
0 0 DNAT 6 -- !br-47be1b9c568b * 0.0.0.0/0 127.0.0.1 tcp dpt:8080 to:172.18.0.5:80und die einträge hab ich jetzt entfernt mit PostUp und PostDown
Entferne die beiden Rules aus der iptables ipv4.conf
und poste dann noch mal bitte die ausgabe von
und starte iptables und wg neu
106 6240 DNAT 6 -- enp5s0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:2222 to:10.0.0.2:22
0 0 DNAT 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:2222 to:192.168.178.251:22und poste dann noch mal bitte die ausgabe von
iptables -t nat -vnL --line-numberund starte iptables und wg neu
Zitat von @Ueba3ba:
Entferne die beiden Rules aus der iptables ipv4.conf
und poste dann noch mal bitte die ausgabe von
und starte iptables und wg neu
Entferne die beiden Rules aus der iptables ipv4.conf
106 6240 DNAT 6 -- enp5s0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:2222 to:10.0.0.2:22
0 0 DNAT 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:2222 to:192.168.178.251:22und poste dann noch mal bitte die ausgabe von
iptables -t nat -vnL --line-numberund starte iptables und wg neu
~ # iptables -t nat -vnL --line-number
Chain PREROUTING (policy ACCEPT 10 packets, 504 bytes)
num pkts bytes target prot opt in out source destination
1 10 504 DOCKER 0 -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type LOCAL
2 0 0 DNAT 6 -- enp5s0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:2222 to:192.168.178.251:22
Chain INPUT (policy ACCEPT 4 packets, 240 bytes)
num pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 2 packets, 117 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 DOCKER 0 -- * * 0.0.0.0/0 !127.0.0.0/8 ADDRTYPE match dst-type LOCAL
Chain POSTROUTING (policy ACCEPT 2 packets, 117 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 MASQUERADE 0 -- * !br-47be1b9c568b 172.18.0.0/16 0.0.0.0/0
2 0 0 MASQUERADE 0 -- * !docker0 172.17.0.0/16 0.0.0.0/0
3 0 0 MASQUERADE 6 -- * * 172.18.0.5 172.18.0.5 tcp dpt:80
4 0 0 MASQUERADE 0 -- * enp5s0 10.0.0.0/24 0.0.0.0/0
Chain DOCKER (2 references)
num pkts bytes target prot opt in out source destination
1 0 0 RETURN 0 -- br-47be1b9c568b * 0.0.0.0/0 0.0.0.0/0
2 0 0 RETURN 0 -- docker0 * 0.0.0.0/0 0.0.0.0/0
3 0 0 DNAT 6 -- !br-47be1b9c568b * 0.0.0.0/0 127.0.0.1 tcp dpt:8080 to:172.18.0.5:80Und nebenbei tut mir leid, dass das so aufhaltend ist
Entferne bitte mit
die Rule für Port 2222 und füge diese neu hinzu mit
und starte iptables neu. Dann versuche bitte eine SSH Verbindung an Port 2222 aufzubauen.
Und dann bitte noch mal die Ausgabe von
iptables -t nat -D PREROUTING 1die Rule für Port 2222 und füge diese neu hinzu mit
iptables -t nat -A PREROUTING -i deinInterface -p tcp --dport 2222 -j DNAT --to-destination 192.168.178.251:22 Und dann bitte noch mal die Ausgabe von
iptables -t nat -vnL --line-numbersUnd nebenbei tut mir leid, dass das so aufhaltend ist
Passt schon, ist eine nette Abwechslung und ich kann dem Forum auch mal etwas zurück geben.Hmm, es gibt keine möglichkeit unter debian die iptables neuzustarten.. wird das nicht direkt angewendet?
Moin.
Wundert mich nicht das das so nicht funktioniert. Der Grund liegt darin das die Pakete mit einer öffentlichen SRC IP am Mailserver ankommen und dieser die Antwort nicht zurück über den Tunnel schickt sondern wie gewohnt bei solchen IPs über sein Default-GW! Es kommt also zu asymmetrischem Routing und damit auch zu keiner Verbindung.
Um das zu umgehen gibt es drei Möglichkeiten:
Die erste besteht darin den Traffic auf dem Server des Rechenzentrums der in den Tunnel weitergeleitet wird ausgehend zum Mailserver zu Masqueraden so das für den Mailserver der Traffic von der Wireguard-Tunnel-IP des Servers im Rechenzentrum kommt:
Der Nachteil bei dieser Methode besteht darin das der Mailserver immer nur die Tunnel-IP als Absender sieht und niciht die externe IP des anderern Mailservers.
Außerdem ist das Masquerading mehr Arbeit für den Server im Rechenzentrum und macht dass ganze langsamer.
Die zweite besteht darin am Mailserver eingehenden Traffic in der Firewall mit einer Maskierung zu versehen (Firewall-Mark) und dann per Routing-Rule und einer separaten Routing-Tabelle den Traffic über den Wireguard Tunnel zu schicken. Alternativ kann man sich die Markierung auch sparen wenn man die Routing-Rule anhand der Ports definiert so dass sämtlicher Traffic von diesen Ports per Default über den Tunnel geschickt werden.
Die Variante mit der Routing-Rule ist die bevorzugte da der Mailserver dann auch die externe IP des anderen Mailservers sehen kann und das performance fressende NAT über den Tunnel entfällt.
Bsp. on the fly auf dem Mailserver (hier nur als bsp. Port 25), dauerhafte Config kommt auf deinen genutzten Network Manager an.
Die dritte ist das man am Mailserver einen Gateway Redirect macht so das dessen sämtlicher Traffic ausschließlich über den Tunnel geht. Das erreicht man indem man den AllowedIPs 0.0.0.0/0 hinzufügt. Dann entfallen sämtliches NAT im Tunnel oder Routing-Marks.
Bitte beachten das man bei der zweiten Variante in der Wireguard-Client-Config in den AllowediPs 0.0.0.0/0 setzen muss und das Erstellen der Routen mittels Table = off deaktivieren muss. Sonst werden Pakete mit Public IPs durch das Cryptokey-Routing blockiert.
Gruß goldcap
Wundert mich nicht das das so nicht funktioniert. Der Grund liegt darin das die Pakete mit einer öffentlichen SRC IP am Mailserver ankommen und dieser die Antwort nicht zurück über den Tunnel schickt sondern wie gewohnt bei solchen IPs über sein Default-GW! Es kommt also zu asymmetrischem Routing und damit auch zu keiner Verbindung.
Um das zu umgehen gibt es drei Möglichkeiten:
Die erste besteht darin den Traffic auf dem Server des Rechenzentrums der in den Tunnel weitergeleitet wird ausgehend zum Mailserver zu Masqueraden so das für den Mailserver der Traffic von der Wireguard-Tunnel-IP des Servers im Rechenzentrum kommt:
iptables -t nat -A POSTROUTING -o mailconnect -d 10.0.0.2 -j MASQUERADEAußerdem ist das Masquerading mehr Arbeit für den Server im Rechenzentrum und macht dass ganze langsamer.
Die zweite besteht darin am Mailserver eingehenden Traffic in der Firewall mit einer Maskierung zu versehen (Firewall-Mark) und dann per Routing-Rule und einer separaten Routing-Tabelle den Traffic über den Wireguard Tunnel zu schicken. Alternativ kann man sich die Markierung auch sparen wenn man die Routing-Rule anhand der Ports definiert so dass sämtlicher Traffic von diesen Ports per Default über den Tunnel geschickt werden.
Die Variante mit der Routing-Rule ist die bevorzugte da der Mailserver dann auch die externe IP des anderen Mailservers sehen kann und das performance fressende NAT über den Tunnel entfällt.
Bsp. on the fly auf dem Mailserver (hier nur als bsp. Port 25), dauerhafte Config kommt auf deinen genutzten Network Manager an.
echo 200 to_wireguard >> /etc/iproute2/rt_tables
ip route add default via 10.0.0.1 table 200
ip rule add ipproto tcp from 10.0.0.2 sport 25 lookup 200Die dritte ist das man am Mailserver einen Gateway Redirect macht so das dessen sämtlicher Traffic ausschließlich über den Tunnel geht. Das erreicht man indem man den AllowedIPs 0.0.0.0/0 hinzufügt. Dann entfallen sämtliches NAT im Tunnel oder Routing-Marks.
Bitte beachten das man bei der zweiten Variante in der Wireguard-Client-Config in den AllowediPs 0.0.0.0/0 setzen muss und das Erstellen der Routen mittels Table = off deaktivieren muss. Sonst werden Pakete mit Public IPs durch das Cryptokey-Routing blockiert.
Gruß goldcap
Zitat von @Ueba3ba:
und starte iptables neu. Dann versuche bitte eine SSH Verbindung an Port 2222 aufzubauen.
Und dann bitte noch mal die Ausgabe von
SSH Verbindung geht weiterhin nichtund starte iptables neu. Dann versuche bitte eine SSH Verbindung an Port 2222 aufzubauen.
Und dann bitte noch mal die Ausgabe von
iptables -t nat -vnL --line-numbersOutput:
~ # iptables -t nat -vnL --line-numbers
Chain PREROUTING (policy ACCEPT 891 packets, 48489 bytes)
num pkts bytes target prot opt in out source destination
1 4 240 DNAT 6 -- enp5s0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:2222 to:192.168.178.251:22
2 0 0 DNAT 6 -- enp5s0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:2222 to:192.168.178.251:22
Chain INPUT (policy ACCEPT 420 packets, 25072 bytes)
num pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 428 packets, 26061 bytes)
num pkts bytes target prot opt in out source destination
1 84 5040 DOCKER 0 -- * * 0.0.0.0/0 !127.0.0.0/8 ADDRTYPE match dst-type LOCAL
Chain POSTROUTING (policy ACCEPT 428 packets, 26061 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 MASQUERADE 0 -- * !br-47be1b9c568b 172.18.0.0/16 0.0.0.0/0
2 0 0 MASQUERADE 0 -- * !docker0 172.17.0.0/16 0.0.0.0/0
3 0 0 MASQUERADE 6 -- * * 172.18.0.5 172.18.0.5 tcp dpt:80
4 0 0 MASQUERADE 0 -- * enp5s0 10.0.0.0/24 0.0.0.0/0
Chain DOCKER (1 references)
num pkts bytes target prot opt in out source destination
1 0 0 RETURN 0 -- br-47be1b9c568b * 0.0.0.0/0 0.0.0.0/0
2 0 0 RETURN 0 -- docker0 * 0.0.0.0/0 0.0.0.0/0
3 0 0 DNAT 6 -- !br-47be1b9c568b * 0.0.0.0/0 127.0.0.1 tcp dpt:8080 to:172.18.0.5:80Hmm, es gibt keine möglichkeit unter debian die iptables neuzustarten.. wird das nicht direkt angewendet?
Doch, die gibt es
systemctl restart iptables@Goldcap
Danke. Da war ich wohl total auf dem Holzweg. Hatte ich komplett übersehen.
Zitat von @Ueba3ba:
Doch, die gibt es
Hmm, es gibt keine möglichkeit unter debian die iptables neuzustarten.. wird das nicht direkt angewendet?
Doch, die gibt es
systemctl restart iptables~ # systemctl restart iptables
Failed to restart iptables.service: Unit iptables.service not found.
kommt da auf dem debian 12 leider
Zitat von @Goldcap:
Die zweite besteht darin am Mailserver eingehenden Traffic in der Firewall mit einer Maskierung zu versehen (Firewall-Mark) und dann per Routing-Rule und einer separaten Routing-Tabelle den Traffic über den Wireguard Tunnel zu schicken. Alternativ kann man sich die Markierung auch sparen wenn man die Routing-Rule anhand der Ports definiert so dass sämtlicher Traffic von diesen Ports per Default über den Tunnel geschickt werden.
Die Variante mit der Routing-Rule ist die bevorzugte da der Mailserver dann auch die externe IP des anderen Mailservers sehen kann und das performance fressende NAT über den Tunnel entfällt.
Die zweite besteht darin am Mailserver eingehenden Traffic in der Firewall mit einer Maskierung zu versehen (Firewall-Mark) und dann per Routing-Rule und einer separaten Routing-Tabelle den Traffic über den Wireguard Tunnel zu schicken. Alternativ kann man sich die Markierung auch sparen wenn man die Routing-Rule anhand der Ports definiert so dass sämtlicher Traffic von diesen Ports per Default über den Tunnel geschickt werden.
Die Variante mit der Routing-Rule ist die bevorzugte da der Mailserver dann auch die externe IP des anderen Mailservers sehen kann und das performance fressende NAT über den Tunnel entfällt.
da benötige ich dann aber leider hilfe bei, weil das leider über mein wissen hinausgeht
Google mal policy routing linux ...z.B.
https://blog.scottlowe.org/2013/05/29/a-quick-introduction-to-linux-poli ...
https://blog.scottlowe.org/2013/05/29/a-quick-introduction-to-linux-poli ...
Zeig mal die Ausgabe von
und gib mal ein
dann solltest du mit iptables neu starten können
Heißt also:
Auf deinem Heim-Server Routing Tabelle anlegen:
Dann fügst du eine Regel hinzu, die besagt: "Jeder Traffic, der über Port 22 läuft, soll über den WireGuard-Tunnel gesendet werden."
Masquerading/NAT auf dem Hetzner-Server einrichten
Nun muss sichergestellt werden, dass ausgehender Traffic nach draußen mit der öffentlichen IP des Hetzner-Servers maskiert wird:
systemctl status iptablesund gib mal
systemctl enable iptables.service dann solltest du mit
systemctl restart iptablesHeißt also:
Auf deinem Heim-Server Routing Tabelle anlegen:
echo "200 wireguard" >> /etc/iproute2/rt_tables Dann fügst du eine Regel hinzu, die besagt: "Jeder Traffic, der über Port 22 läuft, soll über den WireGuard-Tunnel gesendet werden."
ip rule add ipproto tcp dport 22 table wireguard
ip route add default via <WireGuard-Gateway> dev wg0(dein wg interface name) table wireguardMasquerading/NAT auf dem Hetzner-Server einrichten
Nun muss sichergestellt werden, dass ausgehender Traffic nach draußen mit der öffentlichen IP des Hetzner-Servers maskiert wird:
iptables -t nat -A POSTROUTING -o enp5s0 -p tcp --dport 22 -j SNAT --to-source 1.2.3.4(einer deiner beiden public ips)~ # systemctl status iptables
Unit iptables.service could not be found.gibts nicht
aber apt install iptables sagt es sei installiert
Dann gib ein und versuche erneut
mit iptables neu zu starten
systemctl enable iptables.service mit
systemctl rrestart iptablesZitat von @Ueba3ba:
Dann gib ein und versuche erneut
mit iptables neu zu starten
Dann gib
systemctl enable iptables.service mit
systemctl rrestart iptables~ # systemctl enable iptables.service
Failed to enable unit: Unit file iptables.service does not exist.
~ # systemctl restart iptables
Failed to restart iptables.service: Unit iptables.service not found.
gibts nicht. hab jetzt einfach den server neugestartet.. das sollte auch gehen
~ # iptables -t nat -vnL --line-numbers
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 142 19310 DOCKER 0 -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type LOCAL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 30 1800 DOCKER 0 -- * * 0.0.0.0/0 !127.0.0.0/8 ADDRTYPE match dst-type LOCAL
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 MASQUERADE 0 -- * !docker0 172.17.0.0/16 0.0.0.0/0
2 0 0 MASQUERADE 0 -- * !br-47be1b9c568b 172.18.0.0/16 0.0.0.0/0
Chain DOCKER (2 references)
num pkts bytes target prot opt in out source destination
1 0 0 RETURN 0 -- docker0 * 0.0.0.0/0 0.0.0.0/0
2 0 0 RETURN 0 -- br-47be1b9c568b * 0.0.0.0/0 0.0.0.0/0ah, jetzt ist die regel ja wieder weg, hatte nicht gespeichert
iptables -t nat -vnL --line-numbers
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 278 33169 DOCKER 0 -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type LOCAL
2 4 240 DNAT 6 -- enp5s0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:2222 to:192.168.178.251:22
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 45 2700 DOCKER 0 -- * * 0.0.0.0/0 !127.0.0.0/8 ADDRTYPE match dst-type LOCAL
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 MASQUERADE 0 -- * !docker0 172.17.0.0/16 0.0.0.0/0
2 0 0 MASQUERADE 0 -- * !br-47be1b9c568b 172.18.0.0/16 0.0.0.0/0
3 0 0 SNAT 6 -- * enp5s0 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 to:46.4.xxx.xxx
Chain DOCKER (2 references)
num pkts bytes target prot opt in out source destination
1 0 0 RETURN 0 -- docker0 * 0.0.0.0/0 0.0.0.0/0
2 0 0 RETURN 0 -- br-47be1b9c568b * 0.0.0.0/0 0.0.0.0/0 masquerading ist jetzt jedenfalls eingerichtet
Gut.
Also weiter.
Auf dem Heim-Server:
Routing Tabelle anlegen
Die 200 ist einfach eine ID für eine benutzerdefinierte Routing-Tabelle
Rule anlegen
Wenn Pakete von Port 22 kommen, sollen sie die Tabelle wireguard nutzen.
Neue default Route anlegen
In dieser Tabelle leiten wir alles über WireGuard (wg0). Passe wg0 an dein Interface Namen des WG an.
Am RZ Server:
Also weiter.
Auf dem Heim-Server:
Routing Tabelle anlegen
echo "200 wireguard" >> /etc/iproute2/rt_tables Rule anlegen
ip rule add ipproto tcp dport 22 table wireguardNeue default Route anlegen
ip route add default via 10.0.0.1 dev wg0(dein wg interface name) table wireguardAm RZ Server:
iptables -t nat -A POSTROUTING -o enp5s0 -p tcp --dport 22 -j SNAT --to-source 1.2.3.4(einer deiner beiden public ips)
Die iptables gibt es unter Debian/ Ubuntu nicht.
Es handelt sich um eine Komponente, die im Kernel verankert ist (eigentlich beteiligter, iptables ist nur das Frontend). Das OS hat keinen Dienst dafür implementiert.
Sucht mal nach dem Fehler oben, da wird man fündig
Es handelt sich um eine Komponente, die im Kernel verankert ist (eigentlich beteiligter, iptables ist nur das Frontend). Das OS hat keinen Dienst dafür implementiert.
Sucht mal nach dem Fehler oben, da wird man fündig
Zitat von @Ueba3ba:
Gut.
Also weiter.
Auf dem Heim-Server:
Routing Tabelle anlegen
Die 200 ist einfach eine ID für eine benutzerdefinierte Routing-Tabelle
Rule anlegen
Wenn Pakete von Port 22 kommen, sollen sie die Tabelle wireguard nutzen.
Neue default Route anlegen
In dieser Tabelle leiten wir alles über WireGuard (wg0). Passe wg0 an dein Interface Namen des WG an.
Am RZ Server:
Gut.
Also weiter.
Auf dem Heim-Server:
Routing Tabelle anlegen
echo "200 wireguard" >> /etc/iproute2/rt_tables Rule anlegen
ip rule add ipproto tcp dport 22 table wireguardNeue default Route anlegen
ip route add default via 10.0.0.1 dev wg0(dein wg interface name) table wireguardAm RZ Server:
iptables -t nat -A POSTROUTING -o enp5s0 -p tcp --dport 22 -j SNAT --to-source 1.2.3.4(einer deiner beiden public ips)Alles erledigt, weiterhin keine verbindung mit
ssh name@pubIP2 -p 2222
Heimserver routen
~# ip r
default via 192.168.178.1 dev enp1s0f0 onlink
10.0.0.0/24 dev mailconnect proto kernel scope link src 10.0.0.2
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.18.0.0/16 dev br-66c0dcb3fcc6 proto kernel scope link src 172.18.0.1 linkdown
172.19.0.0/16 dev br-e55074d68672 proto kernel scope link src 172.19.0.1
192.168.178.0/24 dev enp1s0f0 proto kernel scope link src 192.168.178.251 ip rule add ipproto tcp dport 22 table wireguard
Das kann so nicht laufen ...Wir wollen ja die Antwortpakete auf die andere Table umleiten nicht die eingehenden ...Muss also so lauten
ip rule add ipproto tcp sport 22 from 10.0.0.2 table wireguardHabe ein bsp. oben ergänzt.
Zitat von @Goldcap:
Muss also so lauten
Habe ein bsp. oben ergänzt.
ip rule add ipproto tcp dport 22 table wireguard
Das kann so nicht laufen ...Wir wollen ja die Antwortpakete auf die andere Table umleiten nicht die eingehenden ...Muss also so lauten
ip rule add ipproto tcp sport 22 from 10.0.0.2 table wireguardHabe ein bsp. oben ergänzt.
Hab das jetzt ausprobiert, leider weiterhin keine verbindung möglich
Klappt hier einwandfrei.
Deine Config ist wohl schon zu sehr Durcheinander geraten.
Deine Config ist wohl schon zu sehr Durcheinander geraten.
Zitat von @Goldcap:
Klappt hier einwandfrei.
Deine Config ist wohl schon zu sehr Durcheinander geraten.
Klappt hier einwandfrei.
Deine Config ist wohl schon zu sehr Durcheinander geraten.
Gut, dann setz ich mal meine rules und alles zurück und mach das nochmal
hättest du eventuell ein kleines step by step wie man das macht, und nicht so ein wirrwar
ich will das nochmal sauber replizieren, komme hier auch nicht mehr mit.. bin leider in dem ganzen iptables und forwarding zeugs nicht so fit
Ach ja noch als wichtige Ergänzung, du musst in der Wireguard Config noch in der AllowedIPs 0.0.0.0/0 ergänzen sonst nimmt der Pakete mit öffentlichen IPs durch das Cryptokey-Routing gar nicht erst an!
Zusätzlich das Erstellen der Routen abschalten, damit nicht sämtlicher Traffic über den Tunnel geht (Table=off).
Die Client-Config sollte also so aussehen
Zum Thema
Zusätzlich das Erstellen der Routen abschalten, damit nicht sämtlicher Traffic über den Tunnel geht (Table=off).
Die Client-Config sollte also so aussehen
[Interface]
Address = 10.0.0.2/24
PrivateKey = key
Table = off
[Peer]
PublicKey = key
Endpoint = 46.4.xxx.xxx:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25Zum Thema
Ich würde dir raten beide Server mit Ubuntu Server neu aufzusetzen.
Wenn du das erledigt hast, können wir weiter machen.
Wenn du das erledigt hast, können wir weiter machen.
@Ueba3ba
Neu aufsetzen würde ich ungerne, auf dem einen RZ Server sind bereits dienste am laufen;
Ich kann jedoch die ganzen Tables soweit wieder bereinigen, dass ich das in den anfangszustand bringen kann
Neu aufsetzen würde ich ungerne, auf dem einen RZ Server sind bereits dienste am laufen;
Ich kann jedoch die ganzen Tables soweit wieder bereinigen, dass ich das in den anfangszustand bringen kann
Steht doch alles schon oben wie es geht.
Als erstes solltest du den Rat von em-pi befolgen.
Damit wir iptables als service neu starten und den status prüfen können.
Und gib mir mal 1-2 Tage. Dann würde ich dein Setup einmal in meinem Lab nachstellen.
Die iptables gibt es unter Debian/ Ubuntu nicht.
Es handelt sich um eine Komponente, die im Kernel verankert ist (eigentlich beteiligter, iptables ist nur das Frontend). Das OS hat keinen Dienst dafür implementiert.
Sucht mal nach dem Fehler oben, da wird man fündig
Es handelt sich um eine Komponente, die im Kernel verankert ist (eigentlich beteiligter, iptables ist nur das Frontend). Das OS hat keinen Dienst dafür implementiert.
Sucht mal nach dem Fehler oben, da wird man fündig
Damit wir iptables als service neu starten und den status prüfen können.
Und gib mir mal 1-2 Tage. Dann würde ich dein Setup einmal in meinem Lab nachstellen.
1Zitat von @Ueba3ba:
Und gib mir mal 1-2 Tage. Dann würde ich dein Setup einmal in meinem Lab nachstellen.
Das wäre sehr lieb. Ich Versuch das auch nochmal Clean alles
Nochmal vielen Dank!
Dann eben mal wieder zu Fuß.
Das das Forwarding aktiviert ist, gehe ich mal von aus, das ist ja sowieso mandatory.
Daten innerhalb von "<>" bitte durch eigene Werte ersetzen.
Klappt hier im TestLab wie erwartet einwandfrei.
Alternativ zur letzten Routing Rule arbeitet man mit Firewall-Marks, da hat man mehr Kontrolle als mit einfachen Routing Rules
Für das obige Beispiel sähe das Marking auf dem Server daheim so aus
und die passende Routing-Rule dafür dann so
Achtung, ausgeführte Routing Table entry und routing rule und iptables Befehle sind natürlich non persistent, sind also nach einem Neustart wieder weg! Für eine persistente Config natürlich die Regeln auf deinem bei dir verwendeten Network Manager übertragen.
Happy networking!
Das das Forwarding aktiviert ist, gehe ich mal von aus, das ist ja sowieso mandatory.
Daten innerhalb von "<>" bitte durch eigene Werte ersetzen.
Server im Rechenzentrum:
SRCNAT am WAN
iptables -t nat -A POSTROUTING -o <WANINTERFACE> -j MASQUERADEDSTNAT Portweiterleitung WAN :2222 > Tunnel > Server :22
iptables -t nat -A PREROUTING -p tcp --dport 2222 -i <WANINTERFACE> -d <WAN-IP> -j DNAT --to-destination 10.0.0.2:22Firewall Forwarding der DSTNAT Weiterleitung akzeptieren
iptables -I FORWARD -i <WAN-INTERFACE> -o <WIREGUARD-INTERFACE> -d 10.0.0.2 -p tcp --dport 22 -j ACCEPTWireguard Config am Server
[Interface]
Address = 10.0.0.1/24
PrivateKey = <PrivateKey Server>
[Peer]
PublicKey = <Public Key Client>
AllowedIPs = 10.0.0.2/32Server daheim
Wireguard Client-Config
[Interface]
Address = 10.0.0.2/24
PrivateKey = <PrivateKey Client>
Table = off
[Peer]
PublicKey = <Public Key Server>
Endpoint = <WAN-IP-SERVER>:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25Custom Routing Table erstellen
echo 200 wireguard >> /etc/iproute2/rt_tablesDefault-Route in Table hinzufügen die über den Tunnel führt
ip route add default via 10.0.0.1 dev <WIREGUARD-INTERFACE> table wireguardRouting Rule erstellen damit Traffic Ausgehend von Port 22 wieder zurück über den Tunnel geleitet wird
ip rule add ipproto tcp from 10.0.0.2 sport 22 lookup wireguardKlappt hier im TestLab wie erwartet einwandfrei.
Alternativ zur letzten Routing Rule arbeitet man mit Firewall-Marks, da hat man mehr Kontrolle als mit einfachen Routing Rules
Für das obige Beispiel sähe das Marking auf dem Server daheim so aus
iptables -t mangle -A INPUT -j CONNMARK --restore-mark
iptables -t mangle -A INPUT -m mark --mark 0 -p tcp --dport 22 -i <WIREGUARD-INTERFACE> -j MARK --set-mark 5
iptables -t mangle -A INPUT -j CONNMARK --save-markip rule add fwmark 0x5 lookup wireguardAchtung, ausgeführte Routing Table entry und routing rule und iptables Befehle sind natürlich non persistent, sind also nach einem Neustart wieder weg! Für eine persistente Config natürlich die Regeln auf deinem bei dir verwendeten Network Manager übertragen.
Happy networking!
Danke Goldcap.
Also kann --to-destination auch die Tunnel IP sein. Dachte es müsste auf die LAN IP geforwarded werden. Aber klar, wenn der SSH Server auf 0.0.0.0 /0 lauscht, dann geht das auch mit der Tunnel IP.
Und da er zwei public IP's an seinem Eth Interface anliegen hat, muss noch -d <WANINTERFACE IP> mit angegeben werden. Korrigiere mich wenn ich falsch liege.
Wenn keine any any Regel vorhanden ist, muss er natürlich auch noch den Traffic vom WAN Interface zum WG Interface zur IP x.x.x.x. auf Port 22 erlauben mit
Danke für deine Mühe
iptables -t nat -A PREROUTING -p tcp --dport 2222 -i <WANINTERFACE> -d <WAN-IP> -j DNAT --to-destination 10.0.0.2:22Also kann --to-destination auch die Tunnel IP sein. Dachte es müsste auf die LAN IP geforwarded werden. Aber klar, wenn der SSH Server auf 0.0.0.0 /0 lauscht, dann geht das auch mit der Tunnel IP.
Und da er zwei public IP's an seinem Eth Interface anliegen hat, muss noch -d <WANINTERFACE IP> mit angegeben werden. Korrigiere mich wenn ich falsch liege.
Wenn keine any any Regel vorhanden ist, muss er natürlich auch noch den Traffic vom WAN Interface zum WG Interface zur IP x.x.x.x. auf Port 22 erlauben mit
iptables -I FORWARD -i <WAN-INTERFACE> -o <WIREGUARD-INTERFACE> -d 10.0.0.2 -p tcp --dport 22 -j ACCEPTDanke für deine Mühe
Zitat von @Ueba3ba:
Danke Goldcap.
Also kann --to-destination auch die Tunnel IP sein. Dachte es müsste auf die LAN IP geforwarded werden. Aber klar, wenn der SSH Server auf 0.0.0.0 /0 lauscht, dann geht das auch mit der Tunnel IP.
Danke Goldcap.
iptables -t nat -A PREROUTING -p tcp --dport 2222 -i <WANINTERFACE> -d <WAN-IP> -j DNAT --to-destination 10.0.0.2:22Also kann --to-destination auch die Tunnel IP sein. Dachte es müsste auf die LAN IP geforwarded werden. Aber klar, wenn der SSH Server auf 0.0.0.0 /0 lauscht, dann geht das auch mit der Tunnel IP.
Ja klar. So lange er auch auf dem Wireguard IF lauscht kein Problem.
Und da er zwei public IP's an seinem Eth Interface anliegen hat, muss noch -d <WANINTERFACE IP> mit angegeben werden. Korrigiere mich wenn ich falsch liege.
Wenn du zwei IPs hast und nur eine davon weiterleiten willst, ja korrekt.Wenn keine any any Regel vorhanden ist, muss er natürlich auch noch den Traffic vom WAN Interface zum WG Interface zur IP x.x.x.x. auf Port 22 erlauben mit
iptables -I FORWARD -i <WAN-INTERFACE> -o <WIREGUARD-INTERFACE> -d 10.0.0.2 -p tcp --dport 22 -j ACCEPTJepp, aber bitte bitte keine Any To Any in der FORWARD Chain an einem öffentlichen erreichbaren Server! Die gehört per Default dicht gemacht und nur das durchgelassen was man explizit erlaubt! Alles andere ist grob fahrlässig.
Zitat von @Goldcap:
Dann eben mal wieder zu Fuß.
Das das Forwarding aktiviert ist, gehe ich mal von aus, das ist ja sowieso mandatory.
Daten innerhalb von "<>" bitte durch eigene Werte ersetzen.
---
Alternativ arbeitet man mit Firewall-Marks, da hat man mehr Kontrolle als mit einfachen Routing Rules
Für das obige Beispiel sähe das Marking auf dem Server daheim so aus
und die passende Routing-Rule dafür dann so
Klappt hier im TestLab wie erwartet einwandfrei.
Achtung, ausgeführte Routing Table entry und routing rule und iptables Befehle sind natürlich non persistent, sind also nach einem Neustart wieder weg! Für eine persistente Config natürlich die Regeln auf deinem bei dir verwendeten Network Manager übertragen.
Happy networking!
Dann eben mal wieder zu Fuß.
Das das Forwarding aktiviert ist, gehe ich mal von aus, das ist ja sowieso mandatory.
Daten innerhalb von "<>" bitte durch eigene Werte ersetzen.
Server im Rechenzentrum:
SRCNAT am WAN
iptables -t nat -A POSTROUTING -o <WANINTERFACE> -j MASQUERADEDSTNAT Portweiterleitung WAN :2222 > Tunnel > Server :22
iptables -t nat -A PREROUTING -p tcp --dport 2222 -i <WANINTERFACE> -d <WAN-IP> -j DNAT --to-destination 10.0.0.2:22Firewall Forwarding der DSTNAT Weiterleitung akzeptieren
iptables -I FORWARD -i <WAN-INTERFACE> -o <WIREGUARD-INTERFACE> -d 10.0.0.2 -p tcp --dport 22 -j ACCEPTWireguard Config am Server
[Interface]
Address = 10.0.0.1/24
PrivateKey = <PrivateKey Server>
[Peer]
PublicKey = <Public Key Client>
AllowedIPs = 10.0.0.2/32Server daheim
Wireguard Client-Config
[Interface]
Address = 10.0.0.2/24
PrivateKey = <PrivateKey Client>
Table = off
[Peer]
PublicKey = <Public Key Server>
Endpoint = <WAN-IP-SERVER>:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25Custom Routing Table erstellen
echo 200 wireguard >> /etc/iproute2/rt_tablesDefault-Route in Table hinzufügen die über den Tunnel führt
ip route add default via 10.0.0.1 dev <WIREGUARD-INTERFACE> table wireguardRouting Rule erstellen damit Traffic Ausgehend von Port 22 wieder zurück über den Tunnel geleitet wird
ip rule add ipproto tcp from 10.0.0.2 sport 22 lookup wireguard---
Alternativ arbeitet man mit Firewall-Marks, da hat man mehr Kontrolle als mit einfachen Routing Rules
Für das obige Beispiel sähe das Marking auf dem Server daheim so aus
iptables -t mangle -A INPUT -j CONNMARK --restore-mark
iptables -t mangle -A INPUT -m mark --mark 0 -p tcp --dport 22 -j MARK --set-mark 5
iptables -t mangle -A INPUT -j CONNMARK --save-markip rule add fwmark 0x5 lookup wireguardKlappt hier im TestLab wie erwartet einwandfrei.
Achtung, ausgeführte Routing Table entry und routing rule und iptables Befehle sind natürlich non persistent, sind also nach einem Neustart wieder weg! Für eine persistente Config natürlich die Regeln auf deinem bei dir verwendeten Network Manager übertragen.
Happy networking!
Hab das jetzt mal nachgebaut, leider ohne erfolg...
tcpdump kommt auch nichts an..
kann man das irgendwie debuggen um zu schauen, wo der wurm ist? Die IPTables waren vor dem jetzigen versuch auch wie vorher.... ich verstehs nicht....
Ich hab das gefühl, dass der fehler bei was einfachem oder so ist..
Am RZ Server ist IP Forwarding auch an, daran liegts nicht...
Tja ohne jegliche aktuelle Config von dir vorliegen zu haben kann man nur raten, dazu habe ich heute Abend ehrlich gesagt keine Böcke mehr. Da musst du dir auch was mühe geben deine gesamte Config des Firewall-Regelwerks und Wireguard zu posten, nebst Routing Table Ausgaben.
Denn wie gesagt läuft das obige so im Lab.
Und mit dem tcpdump siehst du eigentlich detailliert was wie weit kommt, mehr braucht es nicht.
Denn wie gesagt läuft das obige so im Lab.
Und mit dem tcpdump siehst du eigentlich detailliert was wie weit kommt, mehr braucht es nicht.
Zitat von @Goldcap:
Tja ohne jegliche aktuelle Config von dir vorliegen zu haben kann man nur raten, dazu habe ich heute Abend ehrlich gesagt keine Böcke mehr. Da musst du dir auch was mühe geben deine gesamte Config des Firewall-Regelwerks und Wireguard zu posten, nebst Routing Table Ausgaben.
Denn wie gesagt läuft das obige so im Lab.
Und mit dem tcpdump siehst du eigentlich detailliert was wie weit kommt, mehr braucht es nicht.
Tja ohne jegliche aktuelle Config von dir vorliegen zu haben kann man nur raten, dazu habe ich heute Abend ehrlich gesagt keine Böcke mehr. Da musst du dir auch was mühe geben deine gesamte Config des Firewall-Regelwerks und Wireguard zu posten, nebst Routing Table Ausgaben.
Denn wie gesagt läuft das obige so im Lab.
Und mit dem tcpdump siehst du eigentlich detailliert was wie weit kommt, mehr braucht es nicht.
Dann geb ich mal die ganze Konfiguration.
Routing Table Zuhause:
~# ip r s
default via 192.168.178.1 dev enp1s0f0 onlink
10.0.0.0/24 dev mailconnect proto kernel scope link src 10.0.0.2
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.18.0.0/16 dev br-66c0dcb3fcc6 proto kernel scope link src 172.18.0.1 linkdown
172.19.0.0/16 dev br-e55074d68672 proto kernel scope link src 172.19.0.1
192.168.178.0/24 dev enp1s0f0 proto kernel scope link src 192.168.178.251
root@debian-tc1:~# ip r s
default via 192.168.178.1 dev enp1s0f0 onlink
10.0.0.0/24 dev mailconnect proto kernel scope link src 10.0.0.2
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.18.0.0/16 dev br-66c0dcb3fcc6 proto kernel scope link src 172.18.0.1 linkdown
172.19.0.0/16 dev br-e55074d68672 proto kernel scope link src 172.19.0.1
192.168.178.0/24 dev enp1s0f0 proto kernel scope link src 192.168.178.251Routing Table RZ Server:
~ # ip r s
default via 46.4.80.161 dev enp5s0 onlink
10.0.0.0/24 dev mailconnect proto kernel scope link src 10.0.0.1
46.4.xxx.xxx/27 dev enp5s0 proto kernel scope link src 46.4.xxx.xxx
46.4.xxx.xxx via 46.4.xxx.xxx dev enp5s0
46.4.xxx.xxx/27 via 46.4.xxx.xxx dev enp5s0
46.4.xxx.xxx/27 dev enp5s0 proto kernel scope link src 46.4.xxx.xxx
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.18.0.0/16 dev br-47be1b9c568b proto kernel scope link src 172.18.0.1
192.168.178.0/24 dev mailconnect scope link iptables zuhause
~# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy DROP)
target prot opt source destination
DOCKER-USER all -- anywhere anywhere
DOCKER-ISOLATION-STAGE-1 all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain DOCKER (3 references)
target prot opt source destination
ACCEPT tcp -- anywhere 172.17.0.2 tcp dpt:9001
ACCEPT tcp -- anywhere 172.19.0.6 tcp dpt:8000
Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target prot opt source destination
DOCKER-ISOLATION-STAGE-2 all -- anywhere anywhere
DOCKER-ISOLATION-STAGE-2 all -- anywhere anywhere
DOCKER-ISOLATION-STAGE-2 all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain DOCKER-ISOLATION-STAGE-2 (3 references)
target prot opt source destination
DROP all -- anywhere anywhere
DROP all -- anywhere anywhere
DROP all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain DOCKER-USER (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere iptables RZ Server:
~ # iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
ufw-before-logging-input all -- anywhere anywhere
ufw-before-input all -- anywhere anywhere
ufw-after-input all -- anywhere anywhere
ufw-after-logging-input all -- anywhere anywhere
ufw-reject-input all -- anywhere anywhere
ufw-track-input all -- anywhere anywhere
Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT tcp -- anywhere 10.0.0.2 tcp dpt:ssh
ACCEPT tcp -- anywhere 10.0.0.2 tcp dpt:ssh
DOCKER-USER all -- anywhere anywhere
DOCKER-ISOLATION-STAGE-1 all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ufw-before-logging-forward all -- anywhere anywhere
ufw-before-forward all -- anywhere anywhere
ufw-after-forward all -- anywhere anywhere
ufw-after-logging-forward all -- anywhere anywhere
ufw-reject-forward all -- anywhere anywhere
ufw-track-forward all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ufw-before-logging-output all -- anywhere anywhere
ufw-before-output all -- anywhere anywhere
ufw-after-output all -- anywhere anywhere
ufw-after-logging-output all -- anywhere anywhere
ufw-reject-output all -- anywhere anywhere
ufw-track-output all -- anywhere anywhere
Chain DOCKER (2 references)
target prot opt source destination
Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target prot opt source destination
DOCKER-ISOLATION-STAGE-2 all -- anywhere anywhere
DOCKER-ISOLATION-STAGE-2 all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain DOCKER-ISOLATION-STAGE-2 (2 references)
target prot opt source destination
DROP all -- anywhere anywhere
DROP all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain DOCKER-USER (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
Chain ufw-after-forward (1 references)
target prot opt source destination
Chain ufw-after-input (1 references)
target prot opt source destination
ufw-skip-to-policy-input udp -- anywhere anywhere udp dpt:netbios-ns
ufw-skip-to-policy-input udp -- anywhere anywhere udp dpt:netbios-dgm
ufw-skip-to-policy-input tcp -- anywhere anywhere tcp dpt:netbios-ssn
ufw-skip-to-policy-input tcp -- anywhere anywhere tcp dpt:microsoft-ds
ufw-skip-to-policy-input udp -- anywhere anywhere udp dpt:bootps
ufw-skip-to-policy-input udp -- anywhere anywhere udp dpt:bootpc
ufw-skip-to-policy-input all -- anywhere anywhere ADDRTYPE match dst-type BROADCAST
Chain ufw-after-logging-forward (1 references)
target prot opt source destination
LOG all -- anywhere anywhere limit: avg 3/min burst 10 LOG level warn prefix "[UFW BLOCK] "
Chain ufw-after-logging-input (1 references)
target prot opt source destination
LOG all -- anywhere anywhere limit: avg 3/min burst 10 LOG level warn prefix "[UFW BLOCK] "
Chain ufw-after-logging-output (1 references)
target prot opt source destination
Chain ufw-after-output (1 references)
target prot opt source destination
Chain ufw-before-forward (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere icmp destination-unreachable
ACCEPT icmp -- anywhere anywhere icmp time-exceeded
ACCEPT icmp -- anywhere anywhere icmp parameter-problem
ACCEPT icmp -- anywhere anywhere icmp echo-request
ufw-user-forward all -- anywhere anywhere
Chain ufw-before-input (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ufw-logging-deny all -- anywhere anywhere ctstate INVALID
DROP all -- anywhere anywhere ctstate INVALID
ACCEPT icmp -- anywhere anywhere icmp destination-unreachable
ACCEPT icmp -- anywhere anywhere icmp time-exceeded
ACCEPT icmp -- anywhere anywhere icmp parameter-problem
ACCEPT icmp -- anywhere anywhere icmp echo-request
ACCEPT udp -- anywhere anywhere udp spt:bootps dpt:bootpc
ufw-not-local all -- anywhere anywhere
ACCEPT udp -- anywhere mdns.mcast.net udp dpt:mdns
ACCEPT udp -- anywhere 239.255.255.250 udp dpt:1900
ufw-user-input all -- anywhere anywhere
Chain ufw-before-logging-forward (1 references)
target prot opt source destination
Chain ufw-before-logging-input (1 references)
target prot opt source destination
Chain ufw-before-logging-output (1 references)
target prot opt source destination
Chain ufw-before-output (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ufw-user-output all -- anywhere anywhere
Chain ufw-logging-allow (0 references)
target prot opt source destination
LOG all -- anywhere anywhere limit: avg 3/min burst 10 LOG level warn prefix "[UFW ALLOW] "
Chain ufw-logging-deny (2 references)
target prot opt source destination
RETURN all -- anywhere anywhere ctstate INVALID limit: avg 3/min burst 10
LOG all -- anywhere anywhere limit: avg 3/min burst 10 LOG level warn prefix "[UFW BLOCK] "
Chain ufw-not-local (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere ADDRTYPE match dst-type LOCAL
RETURN all -- anywhere anywhere ADDRTYPE match dst-type MULTICAST
RETURN all -- anywhere anywhere ADDRTYPE match dst-type BROADCAST
ufw-logging-deny all -- anywhere anywhere limit: avg 3/min burst 10
DROP all -- anywhere anywhere
Chain ufw-reject-forward (1 references)
target prot opt source destination
Chain ufw-reject-input (1 references)
target prot opt source destination
Chain ufw-reject-output (1 references)
target prot opt source destination
Chain ufw-skip-to-policy-forward (0 references)
target prot opt source destination
DROP all -- anywhere anywhere
Chain ufw-skip-to-policy-input (7 references)
target prot opt source destination
DROP all -- anywhere anywhere
Chain ufw-skip-to-policy-output (0 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
Chain ufw-track-forward (1 references)
target prot opt source destination
Chain ufw-track-input (1 references)
target prot opt source destination
Chain ufw-track-output (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere ctstate NEW
ACCEPT udp -- anywhere anywhere ctstate NEW
Chain ufw-user-forward (1 references)
target prot opt source destination
Chain ufw-user-input (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere tcp dpt:https
ACCEPT tcp -- srv.some.host anywhere tcp dpt:postgresql
ACCEPT udp -- srv.some.host anywhere udp dpt:5432
ACCEPT udp -- anywhere anywhere udp dpt:51820
ACCEPT tcp -- anywhere anywhere tcp dpt:smtp
ACCEPT tcp -- anywhere anywhere tcp dpt:submissions
ACCEPT tcp -- anywhere anywhere tcp dpt:submission
ACCEPT tcp -- anywhere anywhere tcp dpt:imap2
ACCEPT tcp -- anywhere anywhere tcp dpt:imaps
ACCEPT tcp -- anywhere anywhere tcp dpt:pop3
ACCEPT tcp -- anywhere anywhere tcp dpt:pop3s
ACCEPT tcp -- anywhere anywhere tcp dpt:sieve
ACCEPT tcp -- anywhere anywhere tcp dpt:2222
Chain ufw-user-limit (0 references)
target prot opt source destination
LOG all -- anywhere anywhere limit: avg 3/min burst 5 LOG level warn prefix "[UFW LIMIT BLOCK] "
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
Chain ufw-user-limit-accept (0 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
Chain ufw-user-logging-forward (0 references)
target prot opt source destination
Chain ufw-user-logging-input (0 references)
target prot opt source destination
Chain ufw-user-logging-output (0 references)
target prot opt source destination
Chain ufw-user-output (1 references)
target prot opt source destination 
Hab das jetzt mal nachgebaut, leider ohne erfolg...
Vielleich nochmal in aller Ruhe das Wireguard Tutorial gewissenhaft lesen und umsetzen. Oder...gleich IPsec (Strongswan) dafür verwenden.
Als internes VPN Netz das 10.0er Banalnetz zu wählen ist keine gute Idee. Siehe hier.
Zitat von @aqui:
gleich IPsec (Strongswan) dafür verwenden.
Hab das jetzt mal nachgebaut, leider ohne erfolg...
Vielleich nochmal in aller Ruhe das Wireguard Tutorial gewissenhaft lesen und umsetzen. Oder...gleich IPsec (Strongswan) dafür verwenden.
Hi, der Tunnel steht ja soweit. Der RZ Server kommt ja an den Heimserver ran. Vom Tunnel her ist ja kein Problem, sondern eher im korrekten IP Forwarding
Ich weiß nicht, was IPsec da anders machen wird
Ich würde es aber dennoch umsetzen, wenn es einen vorteil gäbe
@ Goldcap
Ist jetz bei mir hängengebliben
Auch das ist jetzt hängengebliben
Da ich zum Beispiel nur einen VPS in Betrieb habe, und dieser eh schon durch die FW von Hetzner etwas geschützt ist,
habe ich das bei mir vernachlässigt.
Zu meiner Verteidigung: Ich nutze meinen VPS nur als forwarder, auf diesem werden keine Dienste zur Verfügung gestellt. Abgesehen von ssh. Auf der Gegenseite ist eine UTM in Betrieb.
Mir war auch nicht klar dass es bei dem Dedicated Servern keine FW vom Hoster gab, die noch vorgeschaltet wird.
Diese scheint es nur für VPS zu geben.
@fabichan
Am besten du machst mal Pause bis morgen. Glaub mir...
Kannst du es verkraften den RZ Server neu aufzusetzten? Den Heim Server eventuell auch??
Es scheint dass deine Konfig wirklich, wie schon erwähnt von Goldcap, ziemlich verfummelt ist.
Am besten du fängst von vorne, mit einem sauberen Systen an.
Ich bin mir sicher das du es dann zum fliegen bringst.
Gn8 und liebe Grüße
Ja klar. So lange er auch auf dem Wireguard IF lauscht kein Problem.
Der sshd Dienst scheint standardmässig auf allen Interfaces zu lauschen.sysadmin@docker-vm01:~$ sudo ss -tulnp | grep sshd
[sudo] password for sysadmin:
tcp LISTEN 0 128 127.0.0.1:6010 0.0.0.0:* users:(("sshd",pid=2093172,fd=9))
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=958,fd=3))
tcp LISTEN 0 128 [::1]:6010 [::]:* users:(("sshd",pid=2093172,fd=7))
tcp LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=958,fd=4))
sysadmin@docker-vm01:~$Ist jetz bei mir hängengebliben
Wenn du zwei IPs hast und nur eine davon weiterleiten willst, ja korrekt.
Hatte ich die ganze Zeit über total übersehen.Auch das ist jetzt hängengebliben
Jepp, aber bitte bitte keine Any To Any in der FORWARD Chain an einem öffentlichen erreichbaren Server! Die gehört per Default dicht gemacht und nur das durchgelassen was man explizit erlaubt! Alles andere ist grob fahrlässig.
Versteht sich eigentlich von selbst.Da ich zum Beispiel nur einen VPS in Betrieb habe, und dieser eh schon durch die FW von Hetzner etwas geschützt ist,
habe ich das bei mir vernachlässigt.
Zu meiner Verteidigung: Ich nutze meinen VPS nur als forwarder, auf diesem werden keine Dienste zur Verfügung gestellt. Abgesehen von ssh. Auf der Gegenseite ist eine UTM in Betrieb.
Mir war auch nicht klar dass es bei dem Dedicated Servern keine FW vom Hoster gab, die noch vorgeschaltet wird.
Diese scheint es nur für VPS zu geben.
Hetzner bietet eine eigene Firewall-Lösung nur für Cloud-Server (VPS) an, nicht für Dedicated Server.
Für Dedicated Server musst du die Firewall selbst verwalten, z. B. mit:
iptables oder nftables unter Linux
pf unter FreeBSD@fabichan
Am besten du machst mal Pause bis morgen. Glaub mir...
Kannst du es verkraften den RZ Server neu aufzusetzten? Den Heim Server eventuell auch??
Es scheint dass deine Konfig wirklich, wie schon erwähnt von Goldcap, ziemlich verfummelt ist.
Am besten du fängst von vorne, mit einem sauberen Systen an.
Ich bin mir sicher das du es dann zum fliegen bringst.
Gn8 und liebe Grüße
