Portweiterleitung über iptables zeigt auf Webserver-Log nur die interne IP vom weitergeleitenden Server

[Andy81]

Hallo an alle,

nachdem ich gestern dank euch hier ein anderes Problem gelöst habe, habe ich heute ein neues festgestellt:

Ich habe eine Portweiterleitung von Server 1 (OpenVPN-Tunnel mit fester IPv4-Adresse) auf Server 2 via itables realisiert.

Leider wird mir im Log von Server 2 nur die interne IP-Adresse von Server 1 (IP xxx.49) der weitergeleiteten Verbindungen angezeigt, ich hätte aber gerne die externen IP-Adressen die auf Server 1 reinkommen und auf Server 2 (IP xxx.50) weitergeleitet werden.

Folgendes habe ich aktuell in der iptables rules.v4 stehen:

-A FORWARD -i tun0 -o eno1 -p tcp -m tcp --dport xxx --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -i tun0 -o eno1 -p tcp -m tcp --dport xxx --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -i tun0 -o eno1 -p tcp -m tcp --dport xxx --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -i tun0 -o eno1 -p tcp -m tcp --dport xx --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT

-A PREROUTING -i tun0 -p tcp -m tcp --dport xxx -j DNAT --to-destination 192.168.175.50
-A PREROUTING -i tun0 -p tcp -m tcp --dport xxx -j DNAT --to-destination 192.168.175.50
-A PREROUTING -i tun0 -p tcp -m tcp --dport xxx -j DNAT --to-destination 192.168.175.50
-A PREROUTING -i tun0 -p tcp -m tcp --dport xx- -j DNAT --to-destination 192.168.175.50
-A POSTROUTING -o tun0 -j MASQUERADE
-A POSTROUTING -o eno1 -j MASQUERADE

Was fehlt hier denn noch bzw. muss ich ändern?

 

[spcqike]

du darfst nicht maskieren. maskieren ist das ersetzen der ursprünglichen IP der Anfrage mit der eigenen.

der ROuter macht das bspw. nach extern, da kein externer Server deine interne IP Auflösen könnte. in deinem Fall verlierst du hier halt die originale IP vom Request.

btw. das ist auch der Grund, warum du die statische ROute in der FB brauchst. Damit der Mailserver die Daten wieder zurückschicken kann zum OpenVPN, muss er die Rückroute entweder selbst wissen (interne Routingtable), oder seinem Standardgateway zukommen lassen, was die Route dann kennt (statische Route der FB)

 

[Andy81]

OK, Maskierung für tun0 (OpenVPN) habe ich rausgenommen. Statische Route ist in der FritzBox angelegt und zeigt auf den Server mit dem OpenVPN-Client xxx.49.

Funktioniert aber trotzdem nicht, ich bekomme noch immer nur die interne IP angezeigt.

 

[Andy81]

Also wenn noch irgendjemand eine Idee hat, ich bekomme es einfach nicht hin, dass mir die externe IP der eingehenden Verbindungen angezeigt werden.

 

[spcqike]

Du musst beides Maskieren entfernen. Da du auf der .50 die .49 siehst (oder anders herum), weil die .50 auf ihrem LAN Interface maskiert. Das musst du löschen. Dann kommt die Anfrage von einer IP aus dem OpenVPN Bereich.

Je nachdem was du aber wirklich machen willst, wird das noch nicht reichen. Ggf ist es sogar der falsche Ansatz. Aber da du nicht mehr geschrieben hast kann man nur raten. Vielleicht reicht es für deinen Zweck ja wirklich.

 

[Andy81]

Wenn ich die Maskierung fürs LAN entferne, funktioniert die Weiterleitung der Ports zwischen beiden PCs nicht mehr...

Du kennst das Thema doch noch vom anderen Thread. Mini PC mit OpenVPN Client und fester IP Adresse muss bei eingehende Verbindungen einfach nur 4 Ports an einen zweiten Mini PC weiterleiten, mehr ist es nicht. Und das bekomme ich seit Stunden nicht hin, langsam verzweifel ich. Die Weiterleitung funktioniert mit der Maskierung von interner Netzwerkschnittstelle. Nehme ich diese neben der tun-Maskierung ebenfalls raus, funktioniert die Port-Weiterleitung nicht mehr.

 

[spcqike]

Wie gesagt. Es fehlen noch ne Menge Infos zu deinem Anwendungsfall.

Ich kann nur raten aber vermute du möchtest die ursprüngliche IP bei der Anmeldung am smtp Server sehen?

Deine portweiteeleitung ohne Maskierung wird funktionieren. Allerdings passen dann deine Routen nicht mehr.

A (bspw dein Handy im mobilen Netzwerk) sendet die Anfrage an B (VPS mit statischer IP), der Leitet sie weiter an C (OpenVPN Server intern), der wiederum an D (Mailserver intern)

Ist das dein Szenario? Wenn ja, bewirkt die Maskierung bei C, dass D denkt, die Anfrage kommt von C und sendet sie an C zurück. Der wiederum an B und der an A. Das passt. Aber die ursprüngliche IP geht für D bei C verloren.

Entfernst du das Maskieren sendet D die Antwort an E (dein Router), der die externe Adresse wiederum ins Internet leitet (wie jeden Aufruf einer externen Adresse). Damit bekommt A die Antwort nicht mehr von B sondern von E. Er erwartet aber keine Antwort von E und verwirft sie.

So oder so ähnlich verstehe ich dein Problem.

Ob und wie du das umgehen kannst, kann ich dir nicht sagen. Eine Möglichkeit wäre, dass D (der Mail Server) alle externen Pakete über B sendet.

Bei einem NGinX Server kann man im Header (oder so, keine Ahnung wo genau) die ursprüngliche IP Adresse von request mitgeben. Und dennoch mit Maskieren arbeiten und eigene Routen erstellen. Dafür müsste auf B aber erstmal sowas laufen. Ob es sowas in der Art für smtp auch gibt kann ich dir nicht sagen. Mein Mailserver läuft direkt hinter dem Router, ohne VPS und VPN dazwischen, und kann entsprechend alle IPs direkt sehen und anfragen bearbeiten. Sei es intern oder extern.

Vielleicht hat @Raijin eine Idee dazu.

Warum du den Umweg über die statische IP unbedingt machen willst, diesen ganzen Aufwand mit VPN (auch noch OpenVPN …. Aber das ist ein anderen Thema), das hab ich immer noch nicht verstanden.

 

[Andy81]

Ich kann nur raten aber vermute du möchtest die ursprüngliche IP bei der Anmeldung am smtp Server sehen?

Genau so ist es, weil sonst fail2ban nicht mehr funktioniert... der sieht aktuell nur ständig die xxx.49 und keine externe IP...

A (bspw dein Handy im mobilen Netzwerk) sendet die Anfrage an B (VPS mit statischer IP), der Leitet sie weiter an C (OpenVPN Server intern), der wiederum an D (Mailserver intern)

Ist das dein Szenario? Wenn ja, bewirkt die Maskierung bei C, dass D denkt, die Anfrage kommt von C und sendet sie an C zurück. Der wiederum an B und der an A. Das passt. Aber die ursprüngliche IP geht für D bei C verloren.

Das hast du so richtig verstanden.

Deine portweiterleitung ohne Maskierung wird funktionieren. Allerdings passen dann deine Routen nicht mehr.

Was wären dann die benötigten? Ich kann im Linux Image auch direkt im VPN-Zugang noch eine Route hinterlegen... nur bin ich langsam echt ratlos welche ich brauche.

Warum du den Umweg über die statische IP unbedingt machen willst, diesen ganzen Aufwand mit VPN (auch noch OpenVPN …. Aber das ist ein anderen Thema), das hab ich immer noch nicht verstanden.

Wie sollte ich sonst einen Mailserver zuhause realisieren, wenn der Provider keine feste IP-Adresse für Privatkunden anbietet? DynDNS ist keine Lösung.

Ich habe jetzt folgende Einträge in der rules.v4 stehen, hier klappt zumindest jetzt die Weiterleitung der Ports ohne Maskierung. Ich habe jetzt nur mal die Einträge für einen Port aufgeführt, die anderen sind identisch. Aber leider noch immer ohne externe IP-Adresse.

*filter
-A FORWARD -i tun0 -o eno1 -p tcp -m tcp --dport 993 --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT
*nat
-A PREROUTING -i tun0 -p tcp -m tcp --dport 993 -j DNAT --to-destination 192.168.175.50
-A POSTROUTING -d 192.168.175.50/24 -o eno1 -p tcp -m tcp --dport 993 -j SNAT --to-source 192.168.175.49
-A POSTROUTING -d 192.168.175.49/24 -o eno1 -p tcp -m tcp --dport 993 -j SNAT --to-source 192.168.175.50

 

[spcqike]

Wie sollte ich sonst einen Mailserver zuhause realisieren, wenn der Provider keine feste IP-Adresse für Privatkunden anbietet? DynDNS ist keine Lösung.

Dann mache ich und viele andere seit Jahren etwas falsch. Warum soll das keine Lösung sein? Dafür ist es doch geschaffen wurden. (Also nicht ausschließlich für Mail Server aber generell für Server hinter wechselnden IP Adressen)

Wenn das ganze auf routing Ebene passieren muss (und nicht auf Anwendungsebene), sehe ich bei dir nur die Möglichkeit, dass das standardgateway des internen Mailservers der VPS Server wird. Also die Route 0.0.0.0/0 über die VPN IP vom VPS in der routing table eintragen.

 

[Andy81]

Ich hatte das Anfangs über DynDNS, jedoch wurde mir gesagt, dass das nicht empfehlenswert ist. Mir wurde bei der Vortragung der Idee beim Anbieter der die Domain hostet ebenfalls mitgeteilt, dass DynDNS nicht empfehlenswert ist (und nein, das ist nicht der Anbieter, die mir den OpenVPN Zugang verkauft hat, das bieten die garnicht an). Wenn sich die IP-Adresse ändert, ist der Server zuhause schon mal bis zu 10 Minuten über den mx bzw. A-Record Eintrag nicht erreichbar. Das ist auch ungut sowas. Wie hast du das gelöst? Wie sieht bei dir dein Aufbau aus?

Ich habe bei der Route hinzufügen "Adresse, Netzmaske, Gateway und Metrik" zum eintragen... was genau soll ich da jetzt reinschreiben? Einen Versuch mache ich noch, dann tritt Plan B in Kraft... OpenVPN und Mailserver auf einem PC laufen zu lassen, wenn es nicht anders geht. Irgendwann wird mir das zu zeitintensiv...

 

[spcqike]

Wie hast du das gelöst? Wie sieht bei dir dein Aufbau aus?

gar nicht. glaube ich. ich könnte beim Domainanbieter (Strato) zwar einen alternativen Mailserver hinterlegen, für den Fall, dass meiner nicht reagiert, aber das habe ich nicht.
ich hab auch nicht das Gefühl, dass mir Mails abhanden gekommen wären. Kann es aber nicht belegen.

Wenn einem Redundanz wichtig ist, braucht man in irgendeiner Art und Weise einen zweiten Mailserver, der ggf. mit angesprochen wird. (was machst du heute, wenn dein Mailserver ausfällt? oder dein Internet? dagegen hast du auch keine Absicherung. du hast mehrere Single-Point-of-Failure -> OpenVPN, VPS, dein Anschluss zu Hause, dein Netzwerk zu Hause, dein Gerät zu Hause. wenn eins der Glieder ausfällt, kommt die Mail nicht mehr an)

Computerbase bspw. hat 3 Mailserver



Mein Aufbau sieht so aus:
Router aktualisiert DNS und MX Record bei geänderter IP. damit zeigt alles direkt auf den Heimanschluss. Portweiterleitung (25, 143, 465, 587, 993) direkt zum Mailserver. fertig. damit kommen die Mails erst einmal an. und ich kann sie mit Apps / Programmen abrufen.

dazu habe ich einen nginx Server (Port 80/443) der auf den gleichen DNS reagiert (mail.domain.de). der wiederum arbeitet dann als reverse proxy und stellt, je nach angefragter Domain, die Seite dar. im Falle der Mail halt die Weboberfläche des Mailservers, damit ich mit, ähnlich web.de und co, auch am Browser anmelden kann.

die Mail-Domain wird, wie jede externe Domain behandelt. also erst einmal extern aufgelöst. der Router (opnSense) managed das schon. denke ich.

das Einzige, wofür ich keine automatische Lösung gefunden habe, ist das erneuern des ssl Zertifikats. der nginx fragt das Zertifikat von Lets Encrypt ab. dieses muss ich dann aller 3 Monate manuell im Mailserver importieren. ein zentraler Speicher für das Zertifikat und ein automatisches Laden vom Mailserver wäre schön, hab ich aber nicht hinbekommen. (Mailserver ist MailPlus von Synology)

Ich habe bei der Route hinzufügen "Adresse, Netzmaske, Gateway und Metrik" zum eintragen... was genau soll ich da jetzt reinschreiben? Einen Versuch mache ich noch, dann tritt Plan B in Kraft... OpenVPN und Mailserver auf einem PC laufen zu lassen, wenn es nicht anders geht. Irgendwann wird mir das zu zeitintensiv...

wie gesagt, wenn du auf Routingebene die originale IP behalten willst (OSI Layer 2? Layer3?), musst du die Rückroute ebenso kennen und identisch halten. siehe mein Beispiel von Samstag. Dafür muss die Standardroute (0.0.0.0/0) für den Mailserver über das VPN laufen. nur dann sendet er Anfragen von/an externe IP Adressen über den Tunnel.

 

[Raijin]

wie gesagt, wenn du auf Routingebene die originale IP behalten willst (OSI Layer 2? Layer3?), musst du die Rückroute ebenso kennen und identisch halten. siehe mein Beispiel von Samstag. Dafür muss die Standardroute (0.0.0.0/0) für den Mailserver über das VPN laufen. nur dann sendet er Anfragen von/an externe IP Adressen über den Tunnel.

So sieht's aus. Wenn eine Verbindung über einen VPN-Tunnel zu einem VPN-Gateway reinkommt und von dort zu einem Server weitergeleitet wird, muss das VPN-Gateway die Verbindung mittels SNAT/Masquerade bearbeiten, wenn der Server die Antwort über die VPN-Verbindung wieder zurückschicken soll. Macht das VPN-Gateway kein SNAT/Masquerade, kommt beim Server eine Verbindung mit einer öffentlichern Absender-IP an und der Server schickt seine Antwort gemäß seiner Routingtabelle an sein Standardgateway, das mutmaßlich der lokale Router ist. Demnach geht die Antwort über eine andere Internetverbindung nach draußen und der Client bekommt die Antwort vermutlich gar nicht, weil sie vom dortigen Router geblockt wird, weil es ein eingehendes Paket ohne eindeutig dazugehörige ausgehende Verbindung ist.

Ohne SNAT/Masquerade am VPN-Gateway müsste man daher das Standardgateway des Servers auf die lokale IP des VPN-Gateways setzen. So antwortet der Server stets in Richtung VPN-Gateway, welches seinerseits alle öffentlichen IP-Adressen (mit Ausnahme der VPN-Gegenstelle) durch das VPN routen muss. Im Falle von OpenVPN wäre das dann die Konfigurationsoption "redirect-gateway def1", die zwei zusätzliche Routen in die Routingtabelle des VPN-Hosts einbaut und damit "Internet" über das VPN leitet.

 

[Andy81]

Das ganze läuft seit Samstag schon wie es sein soll. Externe IP habe ich jetzt auch hinbekommen. Es musste eigentlich nur noch über "route add" den Gateway auf die interne OpenVPN-IP ändern und jetzt läuft alles so wie es sein soll.

Um auf deine Frage bezüglich Ausfall der Hardware zurückzukommen:
Für 12,- € im Jahr habe ich hier zwei MX-Backup gebucht, die in den DNS-Einstellungen mit drin stehen. Sollte mein Mailserver nicht zur Verfügung stehen, werden die Mails bis zu 14 Tage gecached und in regelmäßigen Abständen (alle 5 Min) versucht meinem Mailserver zuzustellen. Das habe ich auch schon getestet in dem ich meinen Mailserver mal 1 Stunde abgeschalten habe, funktioniert wunderbar. Darauf zu vertrauen, dass hoffentlich keine Mails verschwinden, das tue ich nicht.

Bezüglich Zertifikat:
Ich habe mir für eine Gültigkeitsdauer von 3 Jahren für einmalig 13,99 € ein GoGetSSL-Zertifikat gekauft. Das mit alle 3-Monate LetsEncrypt tue ich mir nicht an. Einmal im Jahr neu ausstellen geht schon.

 

[spcqike]

Sehr gut, dass es dann doch geklappt hat.

Für 12,- € im Jahr habe ich hier zwei MX-Backup gebucht, die in den DNS-Einstellungen mit drin stehen. Sollte mein Mailserver nicht zur Verfügung stehen, werden die Mails bis zu 14 Tage gecached und in regelmäßigen Abständen (alle 5 Min) versucht meinem Mailserver zuzustellen. Das habe ich auch schon getestet in dem ich meinen Mailserver mal 1 Stunde abgeschalten habe, funktioniert wunderbar. Darauf zu vertrauen, dass hoffentlich keine Mails verschwinden, das tue ich nicht.

hilft das denn nicht auch, wenn der DNS/MX Record nach einem WEchsel mal 5-10 Minuten nicht passen sollte? grade, wenn du sowas bereits hast, versteh ich den Sinn hinter dem VPS/VPN nicht.

Zum Glück sind Mails nicht kriegsentscheidend. 99% der Mails werden offen gesendet, sind überall mitlesbar. ist ne Email überhaupt rechtskräftig? im Zweifel (wenn einer der beiden Partner bestreitet die Email je erhalten zu haben) doch nicht, oder? Dann läuft es auf das gute alte Fax / Brief heraus.

Wenn du nur für deine Mail gut 25€-30€/Jahr zahlst (reicht das überhaupt? für das MX Backup, VPN, Zertifikat, dedizierte Hardware + Strom?) wäre da ein externer Anbieter nicht wieder günstiger?

in meinem Fall läuft der Mailserver auf dem NAS, das läuft so oder so 24/7. die Domain habe ich ebenfalls. da verbrauche ich nur eine Subdomain (von 10 möglichen). Das LE Zertifikat ist kostenlos. Ich glaube, wenn ich sowieso 25€ und mehr bezahlen würde, würd ich das ganz auslagern. Dann hat man auch kein Stress mit defekter Hardware/Internet/Einrichtung/etc. pp.

 

[Andy81]

Ich habe auch noch ein NAS, aber hast du schon mal gemessen was das verbraucht, wenn die Festplatten dauerhaft laufen (was diese sicher tun wenn ein Mailserver auf dem NAS läuft)?

Ich zahle für den ganzen Aufbau mit Domain, SSL und Strom (unabhängig von der einmaligen Hardwareanschaffung die gerade mal bei 250,- € lag für beide Mini-PCs) gerade mal 11,- € im Monat... für den Preis bekomme ich nichts bei einem Anbieter... im übrigen ist in den 11,- € nicht nur meine Domain mit drin, sondern auch ein DynDNS Account für meine Eltern und Schwiegereltern für die FritzBox.

Außerdem geht es mir darum, dass alle Mails bei mir zuhause auf dem Server liegen und nicht irgendwo bei einem Anbieter/Provider (von mx-Backup mal abgesehen falls dieser benötigt wird).

Ich verstehe deinen Gedanken schon... du meinst ich solle lieber DynDNS verwenden, weil ja sowieso das MX-Backup im Hintergrund läuft... da hast du schon recht, das MX-Backup kam jetzt erst danach dazu, da hat es die VPN-Geschichte schon gegeben und ist für ein halbes Jahr schon bezahlt... aber ich werde mal darüber nachdenken, dass evtl. wieder auf DynDNS aufgrund der MX-Backup-Geschichte ggf. zu ändern. Fragt sich nur, was dann wieder alles nicht geht und geändert werden muss. Muss ich mir mal nochmal genauer ansehen und überdenken.

 

[spcqike]

Ich habe auch noch ein NAS, aber hast du schon mal gemessen was das verbraucht, wenn die Festplatten dauerhaft laufen (was diese sicher tun wenn ein Mailserver auf dem NAS läuft)?

natürlich. ich hab sogar ne WLAN Steckdose dran und sehe live (und mit Monitoring auch historisch), wie viel Watt gezogen werden.

an der gesamten Steckdose sind es 110W-120W idle. (dran hängen 2 Mini PCs mit Proxmox (NUC7i3 und ein Optiplex mit i7 4700K oder so, auf einem davon läuft auch meine OPNSense Firewall), mein 24 Port Switch, die DS2415+ mit ihren 8 HDDs und 2 SSDs, ein Laserdrucker und ein ESP8266 zur Temperaturaufzeichnung, alles zusätzlich an der USV)

wie gesagt, das NAS und auch die Platten da drin laufen eh 24/7. anfangs hatte ich noch Hibernation aktiviert und noch früher auch ein auto shutdown, aber das war mir alles zu fummelig.... das NAS soll laufen. ich brauch die Daten, wenn ich sie brauche. da soll es nicht erst starten. für die Festplatten ist ein Spindown und -Up aller ~30 Minuten ebenso blöd. das NAS ist ja mein zentraler Punkt für alles. Backups (Fotos, Kontakte, VMs, LXCs, ....) und natürlich für all meine Geräte und ihre Nutzdaten. Auf Rechnern und Laptops habe ich schon seit Jahren keine / kaum noch Daten gespeichert.

na klar, nur für n Mailserver würde ich das ganze so auch nicht betreiben aber, der Mailserver ist halt nur 1 zusätzlicher Dienst auf Hardware, die in meinem Fall sowieso läuft.

Außerdem geht es mir darum, dass alle Mails bei mir zuhause auf dem Server liegen und nicht irgendwo bei einem Anbieter/Provider (von mx-Backup mal abgesehen falls dieser benötigt wird).

fair point. kann ich nachvollziehen und mache es ja genauso zusätzlich hat man bei self hosting halt keine limits. keine "nur 50GB Speicher" oder "nur 10 Alias", keine Begrenzung der Anhangsgröße oder oder. im Gegenteil, ein Konto mit Catch-All und ich kann Mailadressen verteilen wie ich möchte. jede Seite bekommt ihre eigene. kommt auf einer Adresse SPAM rein, wird die Adresse samt Seite einfach geblockt. Das Versenden einer Mail aus dem lokalen Netz mit größerem Anhang geht, für das Endgerät, in wenigen Sekunden. (wie auch die lokalen FotoBackups)

du meinst ich solle lieber DynDNS verwenden, weil ja sowieso das MX-Backup im Hintergrund läuft... da hast du schon recht, das MX-Backup kam jetzt erst danach dazu, da hat es die VPN-Geschichte schon gegeben und ist für ein halbes Jahr schon bezahlt... aber ich werde mal darüber nachdenken, dass evtl. wieder auf DynDNS aufgrund der MX-Backup-Geschichte ggf. zu ändern. Fragt sich nur, was dann wieder alles nicht geht und geändert werden muss. Muss ich mir mal nochmal genauer ansehen und überdenken.

Naja, es ist nur ne Überlegung. Wenn du für dich eine Lösung gefunden hast, die nun funktioniert, ist sie ja erst mal nicht verkehrt. Aber du verlässt dich halt zusätlich auf einen Dritten, dessen Hardware und Konditionen du nicht beeinflussen kannst. Zusätzlich geht nun der gesamte Traffic des Mailservers über das VPN (wird nicht viel sein, aber naja) Du hast dir quasi unnötigerweise eine zusätzliche Fehlerquelle eingebaut (wie groß oder klein die Wahrscheinlichkeit für einen Ausfall an dieser Stelle auch immer sein mag) und auch Kosten erzeugt.

 

[Andy81]

Hab das ganze jetzt wieder auf DynDNS umgebaut (aber nur weil das MX-Backup im Hintergrund zuverlässig läuft, was ich bis vor ein paar Tagen noch nicht hatte). Bis Ende März läuft der IP-Tunnel eh noch, wenn es mit DynDNS doch Probleme gibt, kann ich die Kündigung dafür immer noch zurückziehen.