Port forwarding

[marto]

Der erste Server bietet auf Port 80 http an. Nur er ist "von außen" erreichbar.

Ein zweiter Server soll https liefern. Der erste Server muss also POrt 443 an den 2. Server forwarden. Und vielleicht muss der 2. Server auch noch Dinge dazu wissen.

Ich habe das noch nie gemacht. Die Suche an einer Anleitung verwirrt mich eher als das die Suchergebnisse mir helfen.
Beide Server Debian wheezy, statische IP.

[GregorS]

...

Du möchtest eine kompetente Antwort, stimmt‘s?

Du schaffst es jedoch nicht, eine Frage zu stellen, die Hand und Fuß hat.
In Deinem Posting findet sich weit und breit kein Fragezeichen.
Du schreibst, dass Dich schon die Suche nach einer Antwort verwirrt.

Wieviel Lust habe ich wohl, Dir eine andere als diese Antwort zu geben?

Gruß

Gregor

[dufty2]

Das war aber jetzt keine nette Antwort.

Das einfachste duerfte ein Forwarding mittels iptables-rules sein, also etwas in der Art von

Code: Alles auswählen

# iptables -t nat -A PREROUTING  -i eth0 -p tcp -d ip_erster_server --dport 80  -j DNAT       --to ip_zweite_server:443
# iptables        -A FORWARD     -i eth0 -p tcp -d ip_zweite_server --dport 443 -j ACCEPT
# iptables -t nat -A POSTROUTING -o eth0 -p tcp -d ip_zweite_server --dport 443 -j MASQUERADE

Und "packet forwarding for IPv4"-einschalten in der /etc/sysctl.conf nicht vergessen

[GregorS]

Das war aber jetzt keine nette Antwort.

Dass Du etwas Anderes erwartet hast, kann ich mir denken.

Und "forwarding einschalten" nicht vergessen

... und das Handtuch erst recht nicht

Gruß

Gregor

[marto]

Das einfachste duerfte ein Forwarding mittels iptables-rules sein, also etwas in der Art von

Hierzu habe ich eine Nachfrage: Folgende Netzwerkschnittstellen liegen vor:
eth0 ist das interne Netz, hier befindet sich auch "zweiter Server".
eth1 ist der Weg zur bösen Welt, von dort kommen https-Requests.
ppp0 ist an eth1 gebunden (plugin rp-pppoe.so eth1).

Ändern sich insoweit Dir von Dir vorgestellten iptables-Regeln?

Falls ich etwas falsch mache: Wie lösche ich eine falsch übergebene Regel wieder?

[dufty2]

Yo, dann etwa so:

Code: Alles auswählen

# iptables -t nat -A PREROUTING  -i ppp0 -p tcp -d ip_erster_server --dport 80  -j DNAT       --to ip_zweite_server:443
# iptables        -A FORWARD     -i ppp0 -o eth0 -p tcp -d ip_zweite_server --dport 443 -j ACCEPT
# iptables        -A FORWARD     -i eth0 -o ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
# iptables -t nat -A POSTROUTING -o eth0 -p tcp -d ip_zweite_server --dport 443 -j MASQUERADE

Löschen per
# iptables -F

[orcape]

Hi marto,
ist zwar schön, das Dir @dufty2 so bereitwillig mit den Regeln hilft.

eth1 ist der Weg zur bösen Welt, von dort kommen https-Requests.
ppp0 ist an eth1 gebunden (plugin rp-pppoe.so eth1).

Du hast aber nicht wirklich, rein zufällig einen HTTP-Server in vorderster Front direkt am Netz hängen und nutzt den gleichzeitig als Firewall?
Wenn Du schon bei den Iptables-Rules nachfragen musst, hoffentlich bist Du auch in der Lage das Teil ordentlich abzusichern.
Wenn ich so etwas lese, zweifel ich schon etwas....

Ich habe das noch nie gemacht. Die Suche an einer Anleitung verwirrt mich eher als das die Suchergebnisse mir helfen.

Das ist fachliche Inkompetenz und Leichtfertigkeit am Stück.
Die Reaktion von @Gregor.S auf Deinen Thread wundert mich nun wirklich nicht mehr.
Gruß orcape

[marto]

Hi marto,
ist zwar schön, das Dir @dufty2 so bereitwillig mit den Regeln hilft.

Ich bin ihm sehr dankbar. Die anderen Beiträge waren weniger hilfreich.

Du hast aber nicht wirklich, rein zufällig einen HTTP-Server in vorderster Front direkt am Netz hängen und nutzt den gleichzeitig als Firewall?

Nein, nicht zufällig, gewollt. Das ist gatling(fefe), der wenige statische Dinge tut. Was tut das zur Sache?

Wenn Du schon bei den Iptables-Rules nachfragen musst, hoffentlich bist Du auch in der Lage das Teil ordentlich abzusichern.
Wenn ich so etwas lese, zweifel ich schon etwas....

Ich habe das noch nie gemacht. Die Suche an einer Anleitung verwirrt mich eher als das die Suchergebnisse mir helfen.

Das ist fachliche Inkompetenz und Leichtfertigkeit am Stück.

Wir alle sind in sehr vielen Dingen inkompetent. Wir alle haben nicht die Zeit diesen Zustand zu ändern. Manche haben diese Selbsterkenntnis, viele aber nicht. Durch Beschreibung des Problems und der Zielstellung (warum Fragen nicht immer nötig sind, wird GregorS sicher irgendwann auch verstehen) bekommt man möglicherweise sachorientierte Antworten. Auf alle Fälle bekommt man Antworten, die das Leben erklären. Das ist doch auch schön. Oder so. Jedenfalls lernt man Menschen kennen.

[The Hit-Man]

Du möchtest eine kompetente Antwort, stimmt‘s?

Du schaffst es jedoch nicht, eine Frage zu stellen, die Hand und Fuß hat.
In Deinem Posting findet sich weit und breit kein Fragezeichen.
Du schreibst, dass Dich schon die Suche nach einer Antwort verwirrt.

Wieviel Lust habe ich wohl, Dir eine andere als diese Antwort zu geben?

so was ist gemein zu schreiben !

[orcape]

Wir alle sind in sehr vielen Dingen inkompetent. Wir alle haben nicht die Zeit diesen Zustand zu ändern.

Wenn wir uns aber die Zeit schon nicht nehmen, dann sollten wir das wenigstens Leute tun lassen, die eben nicht inkompetent sind und wissen was Sie tun.
Wenn Du vor hast ein Spamschleuder zu produzieren, dann kannst Du es doch gleich sagen.

Du möchtest eine kompetente Antwort, stimmt‘s?

Du schaffst es jedoch nicht, eine Frage zu stellen, die Hand und Fuß hat.
In Deinem Posting findet sich weit und breit kein Fragezeichen.
Du schreibst, dass Dich schon die Suche nach einer Antwort verwirrt.

Wieviel Lust habe ich wohl, Dir eine andere als diese Antwort zu geben?

so was ist gemein zu schreiben !

...nun, Du hast nicht unrecht. Er hätte das etwas sensibler formulieren sollen.
Ich bin wohl hier aber nicht der einzige, der bei dieser Art Projekt, etwas zweifelt.
Gruß orcape

[wanne]

@dufty2: Hat -j DNAT --to nicht automatisch die -j MASQUERADE funktionalität inbegriffen, sodass die letzte Zeile überflüssig ist?

[dufty2]

@dufty2: Hat -j DNAT --to nicht automatisch die -j MASQUERADE funktionalität inbegriffen, sodass die letzte Zeile überflüssig ist?

Nö, denke ich nicht, denn dann müsste mensch im allgemeinen Fall (DNAT aber kein SNAT/MASQ) einige Verrenkungen anstellen.

Wo ich mir allerdings nicht so sicher bin, ist die Zeile

Code: Alles auswählen

# iptables        -A FORWARD     -i eth0 -o ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT

Ich gehe stillschweigend davon aus, dass
a) es auch noch mehr ethX als eth0 geben kann
b) FORWARD (und INPUT) die Policy DROP haben.
c) der "erste Server" nicht notwendigerweise das Gateway des 2. Server zum Internet ist
d) die Regeln so spezifisch wie möglich gelten sollen.
Also ein Rückpaket von Server 2 an eth1 bereits verworfen werden soll, so zum Bleistift.

[marto]

Wir alle sind in sehr vielen Dingen inkompetent. Wir alle haben nicht die Zeit diesen Zustand zu ändern.

Wenn wir uns aber die Zeit schon nicht nehmen, dann sollten wir das wenigstens Leute tun lassen, die eben nicht inkompetent sind und wissen was Sie tun.

Was konkret passiert hier? Welchen Sinn und Zweck hat ein Fachforum? Ich habe eine präzise Problembeschreibung (Aufgabenbeschreibung) geliefert. Im nächsten Semester wird sicher gelehrt, warum eine solche ohne Fragezeichen auskommt.

Wenn Du vor hast ein Spamschleuder zu produzieren, dann kannst Du es doch gleich sagen.

Zeige mal etwas Fachkompetenz und erkläre, wie eine Portweiterleitung 443 für eine SPAM-Schleuder missbraucht werden kann - ich bin ganz Ohr.

Ich bin wohl hier aber nicht der einzige, der bei dieser Art Projekt, etwas zweifelt.

Vor allem lerne ich etwas über Sozialkompetenz sowie über offtopic-Toleranz verschiedener Fachforen: Meine Fachkompetenz kannst Du und Dein Vorredner mit Sicherheit nicht einschätzen. Die Hälfte aller Beiträge sind entbehrlich, da sie keinerlei Substanz beinhalten, lediglich ein implizites "ich bin schlauer" beinhalten; das trifft auch auf Deinen Beitrag zu. In diesem Forum wird das toleriert. Nur aus diesem Grund leiste auch ich mir ein offtopic als Antwort.

[marto]

Ich gehe stillschweigend davon aus, dass
a) es auch noch mehr ethX als eth0 geben kann
b) FORWARD (und INPUT) die Policy DROP haben.
c) der "erste Server" nicht notwendigerweise das Gateway des 2. Server zum Internet ist
d) die Regeln so spezifisch wie möglich gelten sollen.
Also ein Rückpaket von Server 2 an eth1 bereits verworfen werden soll, so zum Bleistift.

Ich hatte gestern Nacht Deine Hinweise in ferm.conf übernommen. Möglicherweise gibt es im Chain input eine zulässige Dopplung: 443 gebe ich explizit frei. Das Vorgehen funktioniert wunschgemäß.

Zu Deinen Anstrichen: eth0 adressiert das interne Netz. Es existiert eth1, über dieses Interface wird ppp0 (pppoe) aufgebaut, es gibt in meiner Konstellation keinen DSL-Router (!). Es gibt tatsächlich (noch) ein läßliches Problem, ich beschreibe in Anstrichen:

* Browser-böse-Seite->DNS->Router->Portweiterleitung und Rückweg funktioniert (danke!)
* Browser-internes-Netz->URI:IP->Ziel-WWW-Server funktioniert
* Browser-internes-Netz->DNS->Router->Portweiterleitung und Rückweg funktioniert nicht

Bei letzterem ist grundsätzlich der Punkt, was man überhaupt will. Will man überhaupt, dass ein Brwoser des internen Netzes den externen Weg nimmt? (Basis: Kein DNS für das interne Netz, statische IP dort) - Eigentlich will man das nicht, man will, dass der interne Browser-Request https:ddnsip.meinhaus.de von erster-server INTERN auf zweiter-server umgebogen wird. (Das Problem wird in den Kommentaren hier angedeutet: http://www.karlrupp.net/de/computer/nat_tutorial

Allgemein: Da es offenbar für diese nicht völlig unübliche Problematik kein sinnvolles deutschsprachiges ToDo im Web gibt, können wir gern an Hand meiner ferm.conf diskutieren. Sfern das gewünscht ist, würde ich mit Dir per PN vorab die Vorgehensweise klären wollen.

[dufty2]

* Browser-internes-Netz->DNS->Router->Portweiterleitung und Rückweg funktioniert nicht

Und das ist gut so! Daran sieht man, dass unser Konstrukt "scharf" ist, sprich, die Firewall nur den vorgegebenen Weg zulässt und nicht irgendwelche Hintertürchen/Umwege.

Bei letzterem ist grundsätzlich der Punkt, was man überhaupt will. Will man überhaupt, dass ein Brwoser des internen Netzes den externen Weg nimmt?

Naja, was heisst hier externen Weg? Wenn wir die 4 obigen Regel ergänzen mit folgenden Zeilen

Code: Alles auswählen

# iptables -t nat -A PREROUTING  -i eth0 -p tcp -d ip_erster_server --dport 80  -j DNAT       --to ip_zweite_server:443
# iptables        -A FORWARD     -i eth0 -o eth0 -p tcp -d ip_zweite_server --dport 443 -j ACCEPT
# iptables        -A FORWARD     -i eth0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

könnte es evtl. auch von intern funktionieren (mit der im Browser angesprochenen "externen" IP.)
Dabei würde dann wohl das böse "ppp0" gar nicht "berührt" werden, weil die Pakte quasi zuvor "umgebogen" wurden.

Das einfachste duerfte aber sein, in der /etc/hosts (der internen Linux-/Windows-Clients) einen Eintrag

Code: Alles auswählen

ip_zweiter_server  ddnsip.meinhaus.de

hinzuzufügen und damit braucht es auch keine zusätzlichen iptables-rules mehr, weil die Einträge in /etc/hosts vor der DNS-Auflösung greifen.

[marto]

Das einfachste duerfte aber sein, in der /etc/hosts (der internen Linux-/Windows-Clients) einen Eintrag

Code: Alles auswählen

ip_zweiter_server  ddnsip.meinhaus.de

hinzuzufügen und damit braucht es auch keine zusätzlichen iptables-rules mehr, weil die Einträge in /etc/hosts vor der DNS-Auflösung greifen.

Bei den Clients wäre das nicht wartbar. Bei "erster-Server" würde das gehen, er gibt den primary für alle Clients, er würde dieses Wissen durchreichen. Aber das wäre ein schwerer Fehler, so oder so: Der kanonische Eintrag ist ja wirklich der Router "erster-Server" und lediglich 443 geht zu "zweiter-Server". Wenn ich das kompette DNS umbiege, passiert genau das, was die Grünschnäbel mir voraussagen.

[orcape]

Hi marto,
macht sich übrigens gut, so ein Gruß...

....passiert genau das, was die Grünschnäbel mir voraussagen.

Auch wenn Du da vielleicht etwas in den "falschen Hals" bekommen hast.
Mittlerweile habe ich auch feststellen können, das Du nicht in die Kategorie ganz unwissend einzuordnen bist....
Du solltest bei neuen Fragestellungen dann doch nicht ganz so "lax" daher kommen.
Gehe davon aus, das nur Du selbst, wirklich in Dein Projekt involviert bist.
Dann sieh Deinen erste Post mal aus fremder Sicht.
Ich kenne da Foren, da hätte man auf Deinen ersten Post noch ganz anders reagiert.
Auch wenn ich hiermit nicht zur Lösung Deines Problems beitrage.
Mein Netzaufbau würde wohl etwas anders aussehen. Das muss aber jeder selbst wissen und dann auch verantworten.
Gruß orcape

[dufty2]

Das einfachste duerfte aber sein, in der /etc/hosts (der internen Linux-/Windows-Clients) einen Eintrag

Code: Alles auswählen

ip_zweiter_server  ddnsip.meinhaus.de

hinzuzufügen und damit braucht es auch keine zusätzlichen iptables-rules mehr, weil die Einträge in /etc/hosts vor der DNS-Auflösung greifen.

Bei den Clients wäre das nicht wartbar. Bei "erster-Server" würde das gehen, er gibt den primary für alle Clients, er würde dieses Wissen durchreichen. Aber das wäre ein schwerer Fehler, so oder so: Der kanonische Eintrag ist ja wirklich der Router "erster-Server" und lediglich 443 geht zu "zweiter-Server". Wenn ich das kompette DNS umbiege, passiert genau das, was die Grünschnäbel mir voraussagen.

Huch? Also entweder reden wir aneinander vorbei, oder ich verstehe Deinen kompletten Abschnitt nicht

Zur besseren Verständnis das Ganze mal mit (frei erfundenen) IPs:

Code: Alles auswählen

ppp0@erster_server: 213.x.y.z (statisch oder von mir aus alle 24 h neu).
eth0@erster_server: 192.168.0.1 (statisch)
eth0@zweiter_server: 192.168.0.100 (statisch)
eth0@clients: 192.168.0.x/24 (dynamisch; bei windows-kisten statt eth0 entsprechends Lan-interface)

So, am DNS (ddnsip.meinhaus.de => 213.x.y.z) ändert sich gar nichts (ggf. höchsten bei dynDNS alle 24 h).
Der Eintrag in der /etc/hosts (entsprechende Datei bei Windows) der internen clients

Code: Alles auswählen

192.168.0.100   ddnsip.meinhaus.de

wird genau einmal (pro client) durchgeführt und danach nicht mehr geändert.

Damit greifen die (internen) clients per https://ddnsip.meinhaus.de direkt zu, nämlich

Code: Alles auswählen

192.168.0.x:>1023 <=> 192.168.0.100:443

und nicht - wie über die ergänzten NAT-Regeln - via

Code: Alles auswählen

192.168.0.x:>1023 <=> 213.x.y.z:80||192.168.0.1:>1023 <=> 192.168.0.100:443

Das ganz klappt solange, solange Du auf keine weiteren (externen) Dienste (z. B. ftp) intern auf z. B. 192.168.0.200 (oder auf dem erster_server direkt) laufen hast und jenen extern wie intern per
ftp://ddnsip.meinhaus.de
ansprechen willst.
DHCP/DNS-Auflösung sollte für die (internen) clients eh' über die 192.168.0.1 laufen.

[marto]

....passiert genau das, was die Grünschnäbel mir voraussagen.

Auch wenn Du da vielleicht etwas in den "falschen Hals" bekommen hast.
Mittlerweile habe ich auch feststellen können, das Du nicht in die Kategorie ganz unwissend einzuordnen bist....

Dann darf ich Dir eine Lebensweisheit mitgeben: Man muss nicht an jeden Baum pinkeln.

Du solltest bei neuen Fragestellungen dann doch nicht ganz so "lax" daher kommen.

Wirf einen vorsichtigen Blick auf meinen ersten Beitrag: Er war im Sinne der Fragestellung extrem präzise. Noch präziser geht nicht. - Die Wahrnehmung meines fragenden Beitrags wurde durch den zweiten Beitrag verändert, Deine Wahrnehmung wurde durch den zweiten Beitrag gesteuert, dieses klugscheißerische offtopic-Gelabere eines Helden an der Tastatur.

Ich kenne da Foren, da hätte man auf Deinen ersten Post noch ganz anders reagiert.

Bei ubuntuusers wäre gekommen: "Gib mal iptables -l" und "Nutzt Du ferm? Gib mal ferm.conf".
Kinderforen frequentiere ich nicht, ich weiß nicht, welche Foren Du meinen könntest.

Auch wenn ich hiermit nicht zur Lösung Deines Problems beitrage.
Mein Netzaufbau würde wohl etwas anders aussehen. Das muss aber jeder selbst wissen und dann auch verantworten.

Ich habe mir eine Antwort auf Deinen vorletzten Beitrag verkniffen - ok, es soll so sein:
Du urteilst über etwas was Du nicht kennst und nicht kennen kannst. Ich habe keinerlei Beschreibung des internen Netzes gegeben. Und das aus sehr gutem Grund. Ich war gezwungen, eine Sonderheit meines Routing anzudeuten, selbst das wollte ich nicht - es war aber im Sinne der Fragestellung zwingend. (Nicht überall in Deutschland kann man sich seinen Provider frei aussuchen ...)

@dufty2: Ich halte die Idee mit den lokalen /etc/hosts nicht für wartbar. Kurz hatte ich die Idee, dem DNS-forwarder auf dem Router das beizubiegen - aber dafür wäre mein zeitlicher Einarbeitugnsaufwand wohl zu groß. Der eigentliche Hintergrund liegt in einer anderen Schichtebene: Jeder Zugriff auf "zweiter_Server:443" soll ausnehmend genau protokolliert und ausgewertet werden. Da wäre ganz schön, wenn in access.log der gerufene Domainname stehen würde.

Nein, es ist kein Angebot an die Öffentlichkeit, die Auswertung ist ok.