Ich habe jetzt eine Weile hier gesucht, aber fand leider keine Lösung…
Ich suche einen Weg, wie ich den Server aus dem Lan, mit dem DYN DNS Domain Namen aufrufen kann, früher nannte man so etwas NAT LOOPBACK, mein Draytec konnte das und viele Router schaffen das immernoch, aber mit Bitswitcher schaffe ich es nicht, also wie nennt sich die Option oder die Programmierung für die Tabelle.
In die dnsmasq schaffe ich es nicht es einzugeben und mit IP Tables verstehe ich nur Bahnhof.
Mit der vi kann ich umgehen.
Also wie schaffe ich es, das ich meinen Webserver aus dem Lan, über den externen Domainnamen erreiche, ohne dabei die etc/hosts verändern zu müssen? Eine Lösung auf dem Router wäre mir liebsten, überhaupt verstehe ich den Sinn nicht, warum ich zwar mein Routermenu über den umgelegten Port 82 erreiche, aber der Port 80 nicht für Anfragen aus dem LAN durchgeleitet wird, von außen über einen Proxy kann ich problemlos meine Seite erreichen, aber nicht aus dem LAN. Für Hilfe wäre ich sehr dankbar
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Habe die drei Scripte wie beschrieben ausgetauscht.
Hier erste Erfahrungen: Nach dem Aktivieren des Loopbacks kann ich den Router auf seiner externen Adresse pingen:
xyz@abc:~$ ping xyz.dyndns.biz
PING xyz.dyndns.biz (externe IP) 56(84) bytes of data.
64 bytes from xyz.adsl.alicedsl.de (externe IP): icmp_seq=1 ttl=64 time=20.4 ms
…
Port-Forwardings funktionieren allerdings noch nicht - und das ist aus meiner Sicht wertvoller als der o.g. Ping. Wäre super, wenn Du das noch implementieren könntest.
Mein Use Case ist folgender:
Ich habe in meinem Netz ein NAS stehen. Wenn ich unterwegs bin und nur eine GPRS-Anbindung auf meinem Netbook habe, dann übernimmt das NAS den Download größerer Dateien. Hierfür habe ich ein kleines Firefox-Addon. Von außen, funktioniert das mit dyndns + Portforwarding aufs NAS super. Wenn ich dann wieder daheim bin, muss ich das Addon umkonfigurieren. Dies würde entfallen, wenn das Portforwarding auch für Verbindungen von "innen" funktionieren würde.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Damit kann ich dann per dyndns-Name über port 8081 auf den 2. httpd Server zugreifen. Damit man 'echt' von außen zugreifen kann, muß noch eine Port-Forward-Regel eingerichtet werden.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hast Du noch weitere Änderungen an firewall.sh vorgenommen? Bcast durch P-t-P zu ersetzen reicht bei mir nicht; der Loopback funktioniert bei mir weiterhin nicht.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Mein thttpd lief auf 192.168.254.1. Wenn er auf einer anderen Adresse läuft funktionierts auch nicht. In firewall.sh gibts in setup_nat_lopback() folgende Zeile:
exec_cmd "iptables -t nat -A NAT_LOOPBACK_PRE_NAT -m mark --mark $NAT_LOOPBACK_MARK -j DNAT --to-destination $lan_ip"
Die muß auch noch raus. Dann sollte es funktionieren.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Auch das Auskommentieren dieser Zeile (mit anschließendem Router-Neustart) führt bei mir zu keinem Fortschritt :(
Zum besseren Nachvollziehen: Das firewall.sh Script auf meinem Router sieht im Augenblick so aus: http://pastebin.com/z3yqZ9JJ
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ich habe es bei mir nochmal gestestet. Es funktioniert. Meine firewall.sh (http://pastebin.com/4YJrWrQj) sieht zwar anders aus. Die entscheidenten Regel sind aber gleich.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In der Tat funktioniert das Loopback für Services, die auf dem Router selbst laufen: Der SSH-Daemon ist nun vom LAN aus sowohl über die interne, als auch über die externe IP erreichbar.
Port-Forwardings auf dem WAN-Interface sind für mich vom LAN aus weiterhin nicht erreichbar (Use Case: siehe Post #3); vom WAN aus schon. Kannst Du das reproduzieren?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Bei mir funktioniert das. Ich habe auf einer Windows-Büchse einen thttpd-Server laufen. Im Router ist NAT und Port-Forwarding auf die IP der Windows-Büchse aktiviert. Der Port vom thttpd ist 8080, damit es keine Konflikte mit dem Web-Interface vom Router gibt. Ich kann den thttpd-Server über die dyndns-Adresse bzw. meine WAN-IP aus dem lokalen LAN erreichen. Im Log vom thttpd-Server sehe ich dann die WAN-IP. Der thttpd-Server ist auch vom WAN aus erreichbar. Im Log sehe ich dann eine fremde WAN-IP. Wenn Du die Weiterleitung per DMZ machst, wird das nicht funktionieren. Für die DMZ werden die benötigten Loopback-Einträge nicht erzeugt.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Habe Rev. 169 von firewall.sh installiert. Zunächst besten Dank, dass ihr an diesem Thema dranbleibt.
Bei mir ist die Situation weiterhin unverändert:
- Pings aus dem LAN an die WAN-Adresse funktionieren.
- NAT-Loopback funktioniert für Services, die direkt auf dem Router laufen (z.B. thttpd, dropbear)
- NAT-Loopback funktioniert nicht für Services, die aus dem WAN per Portforwarding erreichbar sind und eigentlich auf einem anderen Server im LAN laufen. @amd-65: Danke für den Hinweis zur DMZ; bei mir ist keine DMZ eingerichtet.
Welche Informationen würden weiterhelfen?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Du solltest mal in die Firewall-Statistic schauen, ob die entsprechenden Regeln existieren und Pakete weitergereicht werden. Bei mir sieht es so aus (gekürzt);
Firewall Settings / Statistics
NAT table
Chain PREROUTING (policy ACCEPT 7 packets, 496 bytes)
pkts bytes target prot opt in out source destination
19 1120 DNS_NAT all -- * * 0.0.0.0/0 0.0.0.0/0
12 624 WAN_PORTFW_NAT all -- * * 0.0.0.0/0 0.0.0.0/0 MARK match 0x4d
0 0 WAN_PROTFW_NAT all -- * * 0.0.0.0/0 0.0.0.0/0 MARK match 0x4d
0 0 WAN_PORTFW_NAT all -- ppp_1_32_1 * 0.0.0.0/0 0.0.0.0/0 0 0 WAN_PROTFW_NAT all -- ppp_1_32_1 * 0.0.0.0/0 0.0.0.0/0
0 0 WAN_DMZ_NAT all -- ppp_1_32_1 * 0.0.0.0/0 0.0.0.0/0 Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 12 624 NAT_LOOPBACK_POST_NAT all -- * !ppp_1_32_1 0.0.0.0/0 0.0.0.0/0
7 499 MASQUERADE all -- * ppp_1_32_1 0.0.0.0/0 0.0.0.0/0 Chain NAT_LOOPBACK_POST_NAT (1 references) pkts bytes target prot opt in out source destination 12 624 SNAT all -- ** 0.0.0.0/0 0.0.0.0/0 MARK match 0x4d to:87.x.y.z 0 0 RETURN all -- ** 0.0.0.0/0 0.0.0.0/0 Chain WAN_PORTFW_NAT (2 references) pkts bytes target prot opt in out source destination 12 624 DNAT tcp -- ** 0.0.0.0/0 0.0.0.0/0 tcp dpt:8081 to:192.168.a.b:8081 0 0 RETURN all -- ** 0.0.0.0/0 0.0.0.0/0 Mangle tableChain PREROUTING (policy ACCEPT 280K packets, 181M bytes) pkts bytes target prot opt in out source destination 174 83022 NAT_LOOPBACK_MANGLE all -- !ppp_1_32_1 * 0.0.0.0/0 0.0.0.0/0
Chain NAT_LOOPBACK_MANGLE (1 references)
pkts bytes target prot opt in out source destination
167 82526 MARK all -- * * 0.0.0.0/0 87.x.y.z MARK set 0x4d
174 83022 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Danke für den Hinweis, nun kommen wir der Sache schon näher. Die Regeln scheinen nicht vollständig angelegt zu werden. Gekürzt sieht meine FIrewall-Statistik so aus:
Chain INPUT (policy DROP 273 packets, 17661 bytes)
pkts bytes target prot opt in out source destination
2 152 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 5086 554K ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- wl0 * 0.0.0.0/0 0.0.0.0/0 2412 355K ACCEPT all -- ** 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT all -- ** 0.0.0.0/0 0.0.0.0/0 MARK match 0x4d 325 19117 SERVICES_INPUT all -- ppp_1_32_1 * 0.0.0.0/0 0.0.0.0/0
325 19117 SIP_INPUT all -- ppp_1_32_1 * 0.0.0.0/0 0.0.0.0/0 325 19117 PORTFW_INPUT all -- ppp_1_32_1 * 0.0.0.0/0 0.0.0.0/0
325 19117 PROTFW_INPUT all -- ppp_1_32_1 * 0.0.0.0/0 0.0.0.0/0 52 1456 ACCEPT icmp -- ppp_1_32_1 * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
8558 463K TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
95859 7748K PORT_AND_WEB_FILTER all -- * ppp_1_32_1 0.0.0.0/0 0.0.0.0/0 441K 622M PORT_AND_WEB_FILTER all -- ppp_1_32_1 * 0.0.0.0/0 0.0.0.0/0
532K 629M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT all -- br0 br0 0.0.0.0/0 0.0.0.0/0
5210 339K ACCEPT all -- br0 ppp_1_32_1 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 ACCEPT all -- wl0 wl0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- wl0 ppp_1_32_1 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 ACCEPT all -- br0 wl0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- wl0 br0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 MARK match 0x4d
5 252 PORTFW_FORWARD all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 PROTFW_FORWARD all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 DMZ_FORWARD all -- * * 0.0.0.0/0 0.0.0.0/0
Chain PORTFW_FORWARD (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.a.b tcp dpt:n state NEW
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
NAT table
Chain PREROUTING (policy ACCEPT 7276 packets, 686K bytes)
pkts bytes target prot opt in out source destination
7267 684K DNS_NAT all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 WAN_PORTFW_NAT all -- * * 0.0.0.0/0 0.0.0.0/0 MARK match 0x4d
0 0 WAN_PROTFW_NAT all -- * * 0.0.0.0/0 0.0.0.0/0 MARK match 0x4d
329 19297 WAN_PORTFW_NAT all -- ppp_1_32_1 * 0.0.0.0/0 0.0.0.0/0 325 19117 WAN_PROTFW_NAT all -- ppp_1_32_1 * 0.0.0.0/0 0.0.0.0/0
325 19117 WAN_DMZ_NAT all -- ppp_1_32_1 * 0.0.0.0/0 0.0.0.0/0 6919 659K NAT_LOOPBACK_PRE_NAT all -- !ppp_1_32_1 * 0.0.0.0/0 0.0.0.0/0
Chain POSTROUTING (policy ACCEPT 42 packets, 12274 bytes)
pkts bytes target prot opt in out source destination
41 11942 NAT_LOOPBACK_POST_NAT all -- * !ppp_1_32_1 0.0.0.0/0 0.0.0.0/0 5169 335K MASQUERADE all -- * ppp_1_32_1 0.0.0.0/0 0.0.0.0/0
Chain NAT_LOOPBACK_POST_NAT (1 references)
pkts bytes target prot opt in out source destination
Chain NAT_LOOPBACK_PRE_NAT (1 references)
pkts bytes target prot opt in out source destination
Chain WAN_DMZ_NAT (1 references)
pkts bytes target prot opt in out source destination
325 19117 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
Chain WAN_PORTFW_NAT (2 references)
pkts bytes target prot opt in out source destination
0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:n to:192.168.a.b:n
325 19117 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
Chain WAN_PROTFW_NAT (2 references)
pkts bytes target prot opt in out source destination
325 19117 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
Mangle table
Chain PREROUTING (policy ACCEPT 545K packets, 630M bytes)
pkts bytes target prot opt in out source destination
101K 8415K NAT_LOOPBACK_MANGLE all -- !ppp_1_32_1 * 0.0.0.0/0 0.0.0.0/0
Chain POSTROUTING (policy ACCEPT 544K packets, 630M bytes)
pkts bytes target prot opt in out source destination
Chain NAT_LOOPBACK_MANGLE (1 references)
pkts bytes target prot opt in out source destination
fw_statistic.cgi fehlte in meinem Firmware-Image, fw_dmz.cgi ebenso. Habe die Versionen aus dem Repository verwendet und nach /opt/mini_io/webs … kopiert. Ist das ein bekannter Fehler, oder habe ich ein korruptes Firmware-Image erwischt?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
aktuelles Firmware-Image Version 0.3.8 von bitswitcher.sourceforge.net heruntergeladen (Telekom-Treiber, kein OpenVPN, kein Radius, DSL Annex B, mit VOIP)
das Image über das Not-Web-Interface eingespielt
(dabei wurde das NVRAM zurückgesetzt)
Überprüft, ob fw_dmz.cgi und fw_statistic.cgi über das Web-Interface erreichbar sind. Dem war nicht so, also aktuelle Versionen nach /opt/mini_fo/etc/webs/cgi-bin/ kopiert.
NAT Loopback aktiviert
Ein Portforwarding eingerichtet
Das Ergebnis ist unverändert:
NAT-Loopback funktioniert für Ping
NAT-Loopback funktioniert für Services, die auf dem Router selbst laufen (dropbear, tftpd)
NAT-Loopback funktioniert nicht für Portforwardings
NAT-Loopback Regeln werden fw_statistic.cgi zu Folge nicht vollständig angelegt (siehe vorheriges Posting)
Sollte ich ein anderes Firmware-Image herunterladen? Fehlen fw_statistic.cgi und fw_dmz.cgi bei euch auch? Muss eventuell noch ein weiteres Script mit einer neueren Version im mini_fo überdeckt werden?
Danke im Voraus!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Du benötigst noch eine aktuellere Version von fw_portfw.cgi. Alternativ sollte ein Ausführen von firewall.sh restart ausreichen.
Wenn Du Files ins Image kopierst, solltest Du das originale File überschreiben. Die Kopie landet dann auch in /opt/mini_fo. Beim direkten Schreiben nach /opt/mini_fo hatte ich gelegentlich Probleme. Da wurde dann scheinbar doch das alte Script aus dem Image ausgeführt. Ein Reboot hat das Problem dann beseitigt.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Im mini_fo befinden sich nun die aktuellen Versionen folgender Dateien aus dem Repository:
functions.sh, fw_general.cgi, fw_portfw.cgi, fw_statistic.cgi, fw_dmz.cgi, fw_index.cgi, fw_protfw.cgi
Bei jeder Änderung starte ich den Router neu; die Situation ist die gleiche wie zuvor: Die NAT_LOOPBACK*-Chains bleiben leer.
fw_portfw.cgi ist im Repository Revision 40, die schon zwei Jahre alt ist. Meintest Du diese Version, oder gibt es eine aktuellere?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Im letzten commit ist glaube ich leider ein Fehler im Firewall-Skript, deshalb werden die Regeln auch nicht vollständig angelegt. Ich hab das ganze jetzt nochmal modifiziert und die Regeln auf CONNMARK umgestellt, da das normale Markieren nicht den gewuenschten Effekt hatte (war auch logisch, aber mein Denkfehler).
Dazu musste ich das CONNMARK-Modul allerdings ersteinmal in den Kernel einpflegen, da es bisher nicht drin ist. Deshalb bringt ein runterladen des neuen firewall-Skripts aus dem trunk gerade nichts weil in der 0.3.8 eben das Modul fehlt.
Achja vergessen, ich habs natürlich auch selbst getestet und bei mir funktionieren sowohl die Portumleitungen auf den Router selbst als auch auf andere Rechner.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Nach dem Flashen des Images geht der Router nicht mehr online: Die DSL-LED blinkt rot; der DSL-Status im Web-Interface bleibt auf "idle". Ist der DSL-Treiber nicht mit dem Targa von LIDL kompatibel?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Nach dem Flashen des Images geht der Router nicht mehr online: Die DSL-LED blinkt rot; der DSL-Status im Web-Interface bleibt auf "idle". Ist der DSL-Treiber nicht mit dem Targa von LIDL kompatibel?
Ich habe jetzt eine Weile hier gesucht, aber fand leider keine Lösung…
Ich suche einen Weg, wie ich den Server aus dem Lan, mit dem DYN DNS Domain Namen aufrufen kann, früher nannte man so etwas NAT LOOPBACK, mein Draytec konnte das und viele Router schaffen das immernoch, aber mit Bitswitcher schaffe ich es nicht, also wie nennt sich die Option oder die Programmierung für die Tabelle.
In die dnsmasq schaffe ich es nicht es einzugeben und mit IP Tables verstehe ich nur Bahnhof.
Mit der vi kann ich umgehen.
Also wie schaffe ich es, das ich meinen Webserver aus dem Lan, über den externen Domainnamen erreiche, ohne dabei die etc/hosts verändern zu müssen? Eine Lösung auf dem Router wäre mir liebsten, überhaupt verstehe ich den Sinn nicht, warum ich zwar mein Routermenu über den umgelegten Port 82 erreiche, aber der Port 80 nicht für Anfragen aus dem LAN durchgeleitet wird, von außen über einen Proxy kann ich problemlos meine Seite erreichen, aber nicht aus dem LAN. Für Hilfe wäre ich sehr dankbar
Ich habe die firewall-Skripte modifiziert und NAT-loopback implementiert. Vielleicht könntest du das Ganze mal testen. Dazu einfach das Startskript http://bitswitcher.svn.sourceforge.net/viewvc/bitswitcher/trunk/dev_tree/bs_extra/start_scripts/firewall.sh?revision=165 runterladen und auf den Router nach '/etc/start_scripts/' kopieren.
Dann die beiden cgi-Skripte http://bitswitcher.svn.sourceforge.net/viewvc/bitswitcher/trunk/dev_tree/bs_extra/webs_extra/cgi-bin/fw_index.cgi?revision=165 und http://bitswitcher.svn.sourceforge.net/viewvc/bitswitcher/trunk/dev_tree/bs_extra/webs_extra/cgi-bin/fw_general.cgi?revision=165 runterladen und nach '/webs/cgi-bin/' kopieren. Da sollte dann über das Web-Interface das NAT-loopback aktivierbar sein.
Ich wäre dankbar für Rückmeldung.
Habe die drei Scripte wie beschrieben ausgetauscht.
Hier erste Erfahrungen: Nach dem Aktivieren des Loopbacks kann ich den Router auf seiner externen Adresse pingen:
xyz@abc:~$ ping xyz.dyndns.biz
PING xyz.dyndns.biz (externe IP) 56(84) bytes of data.
64 bytes from xyz.adsl.alicedsl.de (externe IP): icmp_seq=1 ttl=64 time=20.4 ms
…
Port-Forwardings funktionieren allerdings noch nicht - und das ist aus meiner Sicht wertvoller als der o.g. Ping. Wäre super, wenn Du das noch implementieren könntest.
Mein Use Case ist folgender:
Ich habe in meinem Netz ein NAS stehen. Wenn ich unterwegs bin und nur eine GPRS-Anbindung auf meinem Netbook habe, dann übernimmt das NAS den Download größerer Dateien. Hierfür habe ich ein kleines Firefox-Addon. Von außen, funktioniert das mit dyndns + Portforwarding aufs NAS super. Wenn ich dann wieder daheim bin, muss ich das Addon umkonfigurieren. Dies würde entfallen, wenn das Portforwarding auch für Verbindungen von "innen" funktionieren würde.
Ich hab noch eine Kleinigkeit am firewall-Skript geändert, versuch jetzt mal bitte ob deine Portforwardings wie gewünscht funktionieren. Dazu bitte das neue Skript hier http://bitswitcher.svn.sourceforge.net/viewvc/bitswitcher/trunk/dev_tree/bs_extra/start_scripts/firewall.sh?revision=167 runterladen und wie gehabt auf den Router kopieren.
Gib mir Bescheid obs geht…
Die neue Änderung zeigt keine Wirkungen - meine Beschreibungen aus Posting #3 treffen immer noch zu. Wie kann ich beim Debugging unterstützen?
http://opensimulator.org/wiki/NAT_Loopback_Routers#SETTING_UP_A_LINUX_COMPUTER_TO_ACT_AS_A_ROUTER sieht nach nem guten Ausgangspunkt aus.
Hi,
ich habe mich auch mal dran versucht (Quelle: http://opensimulator.org/wiki/NAT_Loopback_Routers). Auf dem Router habe ich einen zweiten httpd gestartet:
Dann habe ich diese beiden Regeln hinzugefügt:
Damit kann ich dann per dyndns-Name über port 8081 auf den 2. httpd Server zugreifen. Damit man 'echt' von außen zugreifen kann, muß noch eine Port-Forward-Regel eingerichtet werden.
Da ist ein Fehler in firewall.sh. In folgener Zeile:
muß 'Bcast' durch 'P-t-P' ersetzt werden:
Dann funktionier NAT-Loopback.
Hast Du noch weitere Änderungen an firewall.sh vorgenommen? Bcast durch P-t-P zu ersetzen reicht bei mir nicht; der Loopback funktioniert bei mir weiterhin nicht.
Mein thttpd lief auf 192.168.254.1. Wenn er auf einer anderen Adresse läuft funktionierts auch nicht. In firewall.sh gibts in setup_nat_lopback() folgende Zeile:
Die muß auch noch raus. Dann sollte es funktionieren.
Auch das Auskommentieren dieser Zeile (mit anschließendem Router-Neustart) führt bei mir zu keinem Fortschritt :(
Zum besseren Nachvollziehen: Das firewall.sh Script auf meinem Router sieht im Augenblick so aus:
http://pastebin.com/z3yqZ9JJ
Ich habe es bei mir nochmal gestestet. Es funktioniert. Meine firewall.sh (http://pastebin.com/4YJrWrQj) sieht zwar anders aus. Die entscheidenten Regel sind aber gleich.
In der Tat funktioniert das Loopback für Services, die auf dem Router selbst laufen: Der SSH-Daemon ist nun vom LAN aus sowohl über die interne, als auch über die externe IP erreichbar.
Port-Forwardings auf dem WAN-Interface sind für mich vom LAN aus weiterhin nicht erreichbar (Use Case: siehe Post #3); vom WAN aus schon. Kannst Du das reproduzieren?
Bei mir funktioniert das. Ich habe auf einer Windows-Büchse einen thttpd-Server laufen. Im Router ist NAT und Port-Forwarding auf die IP der Windows-Büchse aktiviert. Der Port vom thttpd ist 8080, damit es keine Konflikte mit dem Web-Interface vom Router gibt. Ich kann den thttpd-Server über die dyndns-Adresse bzw. meine WAN-IP aus dem lokalen LAN erreichen. Im Log vom thttpd-Server sehe ich dann die WAN-IP. Der thttpd-Server ist auch vom WAN aus erreichbar. Im Log sehe ich dann eine fremde WAN-IP. Wenn Du die Weiterleitung per DMZ machst, wird das nicht funktionieren. Für die DMZ werden die benötigten Loopback-Einträge nicht erzeugt.
Kann mal bitte einer von euch testen ob die aktuelle trunk-Version vom firewall-Skript in punkto NAT-loopback nun funktioniert: http://bitswitcher.svn.sourceforge.net/viewvc/bitswitcher/trunk/dev_tree/bs_extra/start_scripts/firewall.sh?revision=169
Bei mir funktioniert NAT-Loopback mit dem aktuellen firewall-Skript und meiner Testmethode.
Habe Rev. 169 von firewall.sh installiert. Zunächst besten Dank, dass ihr an diesem Thema dranbleibt.
Bei mir ist die Situation weiterhin unverändert:
- Pings aus dem LAN an die WAN-Adresse funktionieren.
- NAT-Loopback funktioniert für Services, die direkt auf dem Router laufen (z.B. thttpd, dropbear)
- NAT-Loopback funktioniert nicht für Services, die aus dem WAN per Portforwarding erreichbar sind und eigentlich auf einem anderen Server im LAN laufen.
@amd-65: Danke für den Hinweis zur DMZ; bei mir ist keine DMZ eingerichtet.
Welche Informationen würden weiterhelfen?
Du solltest mal in die Firewall-Statistic schauen, ob die entsprechenden Regeln existieren und Pakete weitergereicht werden. Bei mir sieht es so aus (gekürzt);
Danke für den Hinweis, nun kommen wir der Sache schon näher. Die Regeln scheinen nicht vollständig angelegt zu werden. Gekürzt sieht meine FIrewall-Statistik so aus:
fw_statistic.cgi fehlte in meinem Firmware-Image, fw_dmz.cgi ebenso. Habe die Versionen aus dem Repository verwendet und nach /opt/mini_io/webs … kopiert. Ist das ein bekannter Fehler, oder habe ich ein korruptes Firmware-Image erwischt?
Um eine inkonsistente Firmware bzw. eine inkonsistente Konfiguration auszuschließen, bin ich nun folgende Schritte gegangen:
sichergestellt, dass in /opt/mini_fo/ außer folgenden aktuellen Scripts nichts enthalten ist:
aktuelles Firmware-Image Version 0.3.8 von bitswitcher.sourceforge.net heruntergeladen (Telekom-Treiber, kein OpenVPN, kein Radius, DSL Annex B, mit VOIP)
das Image über das Not-Web-Interface eingespielt
(dabei wurde das NVRAM zurückgesetzt)
Überprüft, ob fw_dmz.cgi und fw_statistic.cgi über das Web-Interface erreichbar sind. Dem war nicht so, also aktuelle Versionen nach /opt/mini_fo/etc/webs/cgi-bin/ kopiert.
NAT Loopback aktiviert
Ein Portforwarding eingerichtet
Das Ergebnis ist unverändert:
NAT-Loopback funktioniert für Ping
NAT-Loopback funktioniert für Services, die auf dem Router selbst laufen (dropbear, tftpd)
NAT-Loopback funktioniert nicht für Portforwardings
NAT-Loopback Regeln werden fw_statistic.cgi zu Folge nicht vollständig angelegt (siehe vorheriges Posting)
Sollte ich ein anderes Firmware-Image herunterladen? Fehlen fw_statistic.cgi und fw_dmz.cgi bei euch auch? Muss eventuell noch ein weiteres Script mit einer neueren Version im mini_fo überdeckt werden?
Danke im Voraus!
Du benötigst noch eine aktuellere Version von fw_portfw.cgi. Alternativ sollte ein Ausführen von firewall.sh restart ausreichen.
Wenn Du Files ins Image kopierst, solltest Du das originale File überschreiben. Die Kopie landet dann auch in /opt/mini_fo. Beim direkten Schreiben nach /opt/mini_fo hatte ich gelegentlich Probleme. Da wurde dann scheinbar doch das alte Script aus dem Image ausgeführt. Ein Reboot hat das Problem dann beseitigt.
@amd-65: Danke für Deine Geduld…
Im mini_fo befinden sich nun die aktuellen Versionen folgender Dateien aus dem Repository:
functions.sh, fw_general.cgi, fw_portfw.cgi, fw_statistic.cgi, fw_dmz.cgi, fw_index.cgi, fw_protfw.cgi
Bei jeder Änderung starte ich den Router neu; die Situation ist die gleiche wie zuvor: Die NAT_LOOPBACK*-Chains bleiben leer.
fw_portfw.cgi ist im Repository Revision 40, die schon zwei Jahre alt ist. Meintest Du diese Version, oder gibt es eine aktuellere?
Danke fuer eure emsige Mithilfe!
Im letzten commit ist glaube ich leider ein Fehler im Firewall-Skript, deshalb werden die Regeln auch nicht vollständig angelegt. Ich hab das ganze jetzt nochmal modifiziert und die Regeln auf CONNMARK umgestellt, da das normale Markieren nicht den gewuenschten Effekt hatte (war auch logisch, aber mein Denkfehler).
Dazu musste ich das CONNMARK-Modul allerdings ersteinmal in den Kernel einpflegen, da es bisher nicht drin ist. Deshalb bringt ein runterladen des neuen firewall-Skripts aus dem trunk gerade nichts weil in der 0.3.8 eben das Modul fehlt.
Ich habe deshalb eine prebuilt-Version hier: http://sourceforge.net/projects/bitswitcher/files/bitswitcher/0.3.9-prebuilt/BS-v0.3.9-prebuilt_bcm96348GWV_VOIP_ANNEX_B-06.11.2011_19_18_39.img/download zur Verfügung gestellt, die ihr bitte mal testen sollt. Bitte nicht vergessen vor oder nach dem Einspielen das mini_fo zu löschen damit auch die neuen Dateien gelten.
Achja vergessen, ich habs natürlich auch selbst getestet und bei mir funktionieren sowohl die Portumleitungen auf den Router selbst als auch auf andere Rechner.
Nach dem Flashen des Images geht der Router nicht mehr online: Die DSL-LED blinkt rot; der DSL-Status im Web-Interface bleibt auf "idle". Ist der DSL-Treiber nicht mit dem Targa von LIDL kompatibel?
Da war doch was.. https://sourceforge.net/projects/bitswitcher/forums/forum/799260/topic/4578545
https://sourceforge.net/projects/bitswitcher/forums/forum/799260/topic/4578545