ubuntuusers.de

Hallo,

…ich kann mir das nicht erklären. Ich versteh´s nicht.

Vorweg: Die IPs und Hostnames hier sind von mir verändert.

Ich habe Shorewall auf meinem separaten Gateway eingerichtet. Nun will ich in einem total simplen Zwei-Interfaces-Szenario ein paar Port von draussen nach innen umleiten und kriege einen Hirnschaden. Auf EINEM Rechner geht es, auf einem ANDEREN nicht?!

Das hier habe ich in „rules“, um von draussen zwei verschiedene Webserver ansprechen zu können:

DNAT	net	loc:192.168.167.13:80	tcp	58990
DNAT	net	loc:192.168.167.1:80	tcp	58991

Resultat: Die zweite Umleitung von Port 58991 auf die .1 (ein Mac OS X Server) geht. Die erste auf einen Linux-Server geht nicht.

Beide Maschinen lassen sich vom Gateway selbst aus ansprechen (w3m 192.168.167.1), die Apaches laufen.

Wenn ich das Problem auf meinen Apache schiebe und statt den Ports für http einfach mal die für ssh umleite (läuft auch auf beiden Kisten) - das gleiche Problem.

Wenn ich die Regeln vertausche, sowohl in der Reihenfolge als auch von den Portnummern her - immer das gleiche: .1 geht, .13 nicht.

Wenn ich die Regel für .1 mal weggkommentiere, geht die für .13 trotzdem nicht, aber die .1-Regel beweisst ja, das die Syntax prinzipiell korrekt ist.

Für keinen der Rechner ist irgendwie eine „Spezialregel“ definiert, beide sind im gleichen Netzwerk und unterliegen ansonsten dem gleichen Regelsatz.

Ich teste die Verbindung ordnungsgemäss „von draussen“.

Wenn ich einen Verbindungsversuch per tcpdump mittrace, dann sehe ich auch was ankommen:

tcpdump -i eth0 -l -q
IP h-213.61.96.99.host.de.example.com.43348 > intern13.intern.foo.www: tcp 0

Das stimmt. Genau das ist meine Verbindung. Aber wieso geht da nix zurück?

Auf dem anfragenden Rechner:

telnet 213.61.96.99 58990
Trying 213.61.96.99...

(wartet sich tot...)

Die Logfiles aller beteiligten Maschinen sind diesbezüglich leer.

Kann jemand was gegen das Summen in meinem Kopf tun? Ich rall´s nicht…

Solange die eine Zeile geht und die andere nicht verzichte ich mal auf das Posten von Configfiles. Das ist ja sinnlos. Ach ja, und: Ich habe beide Zeilen schon so oft neu geschrieben, vertauscht, etc,… da sind keine versteckten Steuerzeichen oder so enthalten.

Gruß, Jörg

Nachtrag:

Inzwischen habe ich auch einen zweiten Linux-Server dazugenommen, auch dieser will nicht antworten.

Ein Blick auf die von shorewall generierten Regeln offenbart keinen Unterschied zwischen geht-nicht-Servern und geht-Servern:

# iptables -L -n |grep 192
ACCEPT     udp  --  0.0.0.0/0            192.168.167.3       udp dpt:53 /* DNS */ 
ACCEPT     tcp  --  0.0.0.0/0            192.168.167.3       tcp dpt:53 /* DNS */ 
ACCEPT     tcp  --  0.0.0.0/0            192.168.167.13      tcp dpt:80 ctorigdstport 58990 
ACCEPT     tcp  --  0.0.0.0/0            192.168.167.12      tcp dpt:80 ctorigdstport 58992 
ACCEPT     tcp  --  0.0.0.0/0            192.168.167.1       tcp dpt:80 ctorigdstport 58991 

??????

…ich rede gerade mit mir selbst, ´schuldigung, dass mir immer noch was einfällt:

Ich habe nur das gateway neu aufgesetzt. An sich habe ich bei der Problembeschreibung das Gefühl, dass gar nicht shorewall „schuld“ ist, sondern die Ziel-Server (Weil die Linuxe nicht erreichbar sind, wohl aber der Mac), aber ich habe nur das Gateway neu aufgesetzt, die Veränderungen auf den Servern beschränken sich auf eine neue Adresse für Gateway und DNS.

Gruß, Jörg

OK, man muss nur öffentlich im Netz erzählen, dass man nix gebacken kriegt — dann bekommt man es gebacken. HMPF.

Für die Akten und nachfolgende Generationen: Man muss auf den „Zielservern“ das gateway gesetzt haben, von dem auch die umgeleitete Verbindung kommt. Da habe ich mich prompt ver-copy-paste-t, und deswegen gehen auch alle Linuxe nicht…

Danke für´s zuhören!

Solved.

Guten Rutsch, Jörg