SuSE Firewall Port öffnen / Port weiterleiten / Port testen

[stopsy]

Hei Ihr,

folgendes Problem:

- Ich habe eine Lan / IP Webcamera mit Dyndns-Funktionalitäten und Webserver welche zur Überwachungszwecken eingesetzt werden soll und über das Internet abrufbar sein soll.
- Ins Internet gehe ich über einen Linux Router (Suse 9.1) mit Squid als Proxy und SuseFirewall 2
- Damit ich von außen auf die Webcamera komme, muss ich einen bestimmten Port - in diesem Fall Port 80 - auf die IP der Webcamera leiten. Kann den Port aber auch ändern.
- Nun habe ich in der config /etc/sysconfig/SuseFirewall2 die Ports geöffnet mit dem Punkt:
FW_SERVICES_EXT_TCP="22 443 80 http https ssh"
- Danach habe ich eine Weiterleitungsregel erstellt wie folgt:
FW_FORWARD_MASQ="0/0,192.168.16.10,tcp,80"
(192.168.16.10 ist die interne IP meiner Webcam)

Nun war ich der Meinung das alles getan ist...

Nun testete ich ob die Ports offen sind mit:
nmap -sS XXX.dyndns.org

Er zeigte mir zwar das SSH offen ist aber sonst nix. Komisch dachte ich mir. Es sind doch mehr ports offen. Also testete ich das ganze mit
telnet XXX.dyndns.org 80 usw.
Immer kam "Connection refused" nur SSH ließ er durch.

Ich versteh jetzt prinzipiell nicht
1. Warum sagt er Connection refused wenn die Ports doch geöffnet sind - und warum zeigt mir nmap nicht alle offenen Ports??
2. Was mache ich falsch an meinem portforwarding.

Übrigens wenn ich mit XXX.dnydns.org meine Website der Camera aufrufen möchte kommt auch die Meldung "Connection refused" und manchmal auch mal "Die Seite kann nicht gefunden werden"

Vielen Dank für eure Hilfe

[framp]

FW_SERVICES_EXT_TCP="22 443 80 http https ssh"

Ist doppelt gemoppelt. Entweder die Portnummern oder die Portnamen. Aber das ist wohl nicht das Problem.

FW_FORWARD_MASQ="0/0,192.168.16.10,tcp,80"

FW_FORWARD_MASQ braucht auch noch andere enabled Settings, z.B. FORWARD_MASQUERADE="yes". Ausserdem solltest Du auch den https Port ebenso öffnen.

Nun testete ich ob die Ports offen sind mit:
nmap -sS XXX.dyndns.org

Hoffentlich von einem Rechner aus dem Internet . Ansonsten ist der TCP/IP Stack so intelligent und benutzt die lokale IP Adresse.

Er zeigte mir zwar das SSH offen ist aber sonst nix.

Eigentlich klar. Wenn Du nmap oder telnet auf einem lokalen Rechner laufen läßt geht er immer an die lokale IP - und kein Masquerading findet statt. Da Du lokal ssh offen hast findet das nmap. Die http und https Ports natürlich nicht. Für interne Zugriffstest kannst Du nmap 192.168.16.10 benutzen.

Ich glaube wenn Du den Test aus dem Internet machst funktioniert es Geht z.B. auch mit den diversen Portsscannern im Netz wie z.B. ShieldsUp.

[stopsy]

mmh - Schon mal interessant mit nmap. Soweit hab ich nicht gedacht.
Ich überleg bloß wie ich das jetzt vom Internet aus testen kann - aber dafür werde ich schon ne Lösung finden.

-----
FORWARD_MASQUERADE="yes" - ist eingestellt gewesen

-----
Habe das Portforwarding ergänzt wie folgt:
FW_FORWARD_MASQ="0/0,192.168.0.10,tcp,80 0/0,192.168.0.10,udp,80 0/0,192.168.0.10,tcp,443 0/0,192.168.0.10,udp,443"

Und?? - Es klappt

Ein Traum - super - ich bin begeistert
-->
Hoffentlich von einem Rechner aus dem Internet . Ansonsten ist der TCP/IP Stack so intelligent und benutzt die lokale IP Adresse.

Das war genau der richtige Tipp. Vielen Dank

Aber kannst du mir kurz erklären warum das so ist?? Er muss doch im Internet nach der IP meiner Dyndns... erfragen. Und dann verweist er doch von außen auf meinen Router, oder???

Thanx nochmal.... :-)

[framp]

Ich überleg bloß wie ich das jetzt vom Internet aus testen kann - aber dafür werde ich schon ne Lösung finden.

ShieldsUp (Steht oben Gibt ne Menge andere Portscanner im Netz.).

Aber kannst du mir kurz erklären warum das so ist?? Er muss doch im Internet nach der IP meiner Dyndns... erfragen. Und dann verweist er doch von außen auf meinen Router, oder???)

Technische Details kenne ich leider nicht. Würde mich auch mal interessieren warum. Könnte mir vorstellen, dass der TCP/IP Stack die dyndns Adresse auflöst (IP=4.7.1.1), dann feststellt, dass er diese Adresse selbst extern (dsl0) hat und da der Request aus dem inneren Netz kam (eth1), gleich die interne Adresse (1.2.3.4) benutzt. Macht ja irgendwie Sinn. Ansonsten ist es so, als würde man sich mit der rechten Hand am linken Ohr über den Kopf kratzen - obwohl das Kratzen mit der linken Hand am linken Ohr viel einfacher geht ;-)