5
Speedport 400 P - Ports in Firewall öffnen für Kommunikation zwischen Shop-Server und Wawi-Server
Wir haben den DSL-Router Speedport 400 P. Der Internetzugang erfolgt über die Telekom. Dieser Router bereitet uns anscheinend Probleme bei der Kommunkation zwischen unserem Online-Shop, der auf einem Root-Server (Linux) bei einem Provider (1und1) eingerichtet ist, und unserem eigenen Warenwirtschaftsserver (Windows). Der Shop ist noch in der Testphase.
- Shop-Software und Wawi sind von ein und demselben Anbieter.
- Der Shop muss jederzeit auf die Wawi zugreifen können.
Dafür habe ich einige Ports in der Firewall des Routers öffnen müssen. Für diese Ports habe ich ein Port Forwarding an den Wawi-Server eingerichtet.
- Auf dem Wawi-Server und dem Root-Server ist keine Firewall aktiviert.
- Die Zwangsunterbrechung des DSL-Routers und unsere Datensicherung auf dem Wawi-Server erfolgen nachts. Damit es keine Prozesskonflikte gibt, haben wir eine automatische Sperrung des Shops für die Nachtstunden programmiert. Diese Lösung haben wir gewählt, um die hohen Kosten für eine Standleitung zu vermeiden. Die geplante Sperrung funktioniert.
Der Zugriff vom Shop auf den Wawi-Server funktioniert dahingehend, dass wir problemlos eine Datenreplikation für 25.000 Artikel durchführen können. Dennoch sperrt sich der Shop immer wieder unplanmäßig bei diversen anderen Zugriffsversuchen.
Alle Beteiligten sind der Auffassung, dass die Sperrung durch den DSL-Router verursacht wird.
Aber wie?
- Shop-Software und Wawi sind von ein und demselben Anbieter.
- Der Shop muss jederzeit auf die Wawi zugreifen können.
Dafür habe ich einige Ports in der Firewall des Routers öffnen müssen. Für diese Ports habe ich ein Port Forwarding an den Wawi-Server eingerichtet.
- Auf dem Wawi-Server und dem Root-Server ist keine Firewall aktiviert.
- Die Zwangsunterbrechung des DSL-Routers und unsere Datensicherung auf dem Wawi-Server erfolgen nachts. Damit es keine Prozesskonflikte gibt, haben wir eine automatische Sperrung des Shops für die Nachtstunden programmiert. Diese Lösung haben wir gewählt, um die hohen Kosten für eine Standleitung zu vermeiden. Die geplante Sperrung funktioniert.
Der Zugriff vom Shop auf den Wawi-Server funktioniert dahingehend, dass wir problemlos eine Datenreplikation für 25.000 Artikel durchführen können. Dennoch sperrt sich der Shop immer wieder unplanmäßig bei diversen anderen Zugriffsversuchen.
Alle Beteiligten sind der Auffassung, dass die Sperrung durch den DSL-Router verursacht wird.
Aber wie?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 103882
Url: https://administrator.de/forum/speedport-400-p-ports-in-firewall-oeffnen-fuer-kommunikation-zwischen-shop-server-und-wawi-server-103882.html
Ausgedruckt am: 26.12.2024 um 16:12 Uhr
5 Kommentare
Neuester Kommentar
Was meinst du genau mit Sperrung ??
Die Sperrung des Shops soll sicher bedeuten das du die Shop SW runterfährst oder deaktivierst, was ja wohl ein Prozess oder Script auf dem Shop Server selber ist.
So was kann nie und nimmer über eine Datenverbindung an sich ausgelöst werden, das ist klar !
Was der Router einzig und allein machen kann ist die von dir konfigurierte Port Weiterleitung oder virtueller Server, wie es im Handbuch auf Seite 148 beschrieben ist, nicht mehr korrekt auszuführen.
Resultat ist dann das vom Shop initiierte Verbindungen von außen auf das WaWi nicht mehr durchkommen...
Das ist aber auch schon der einzige Fehler den der Router an sich bewirken kann...
Das wäre dann in der Tat ein Bug in der Router SW.
Feststellen kannst du das mit einem Sniffer wie den Wireshark oder MS netMonitor vor dem WaWi Rechner ob diese freigegebenen Ports dann nicht mehr durchkommen (Traffic).
Hast du den Router auf das aktuellste Firmware Image upgedatet ??
Die Sperrung des Shops soll sicher bedeuten das du die Shop SW runterfährst oder deaktivierst, was ja wohl ein Prozess oder Script auf dem Shop Server selber ist.
So was kann nie und nimmer über eine Datenverbindung an sich ausgelöst werden, das ist klar !
Was der Router einzig und allein machen kann ist die von dir konfigurierte Port Weiterleitung oder virtueller Server, wie es im Handbuch auf Seite 148 beschrieben ist, nicht mehr korrekt auszuführen.
Resultat ist dann das vom Shop initiierte Verbindungen von außen auf das WaWi nicht mehr durchkommen...
Das ist aber auch schon der einzige Fehler den der Router an sich bewirken kann...
Das wäre dann in der Tat ein Bug in der Router SW.
Feststellen kannst du das mit einem Sniffer wie den Wireshark oder MS netMonitor vor dem WaWi Rechner ob diese freigegebenen Ports dann nicht mehr durchkommen (Traffic).
Hast du den Router auf das aktuellste Firmware Image upgedatet ??
Hallo aqui,
vielen Dank für die Hilfestellung.
Die Sperrung erfolgt, indem die Shop-SW beendet und nach ein paar Stunden wieder gestartet wird.
Die Firmware auf dem Router ist aktuell (Stand: 2006). Es gibt definitiv kein Update.
Das Port-Forwarding habe ich gemäß Handbuch konfiguriert.
Mit einem Sniffer habe ich mich - ehrlich gesagt - noch nicht befasst. Habe mir den Wireshark sowie ein Tutorial aus dem Internet besorgt und werde mich mal damit beschäftigen. Mal schauen, welche Erkenntnisse ich bekomme, wenn ich das Programm auf dem Wawi-Server laufen lasse.
vielen Dank für die Hilfestellung.
Die Sperrung erfolgt, indem die Shop-SW beendet und nach ein paar Stunden wieder gestartet wird.
Die Firmware auf dem Router ist aktuell (Stand: 2006). Es gibt definitiv kein Update.
Das Port-Forwarding habe ich gemäß Handbuch konfiguriert.
Mit einem Sniffer habe ich mich - ehrlich gesagt - noch nicht befasst. Habe mir den Wireshark sowie ein Tutorial aus dem Internet besorgt und werde mich mal damit beschäftigen. Mal schauen, welche Erkenntnisse ich bekomme, wenn ich das Programm auf dem Wawi-Server laufen lasse.
Der Router ist auch definitiv nicht das Problem. Er kann ja niemals aktiv mit irgendwelchen Paketen dem OS des Shopservers Kommandos erteilen und diesen bestimmten Prozess stoppen...das wäre Unsinn und gehört in den Bereich der Märchen...
Das einzige was er kann wäre die Ports trotz aktiviertem Forwarding blocken, was dann auf einen Fehler der Firmware zurückzuführen wäre....
Wie gesagt schleif einen Sniffer zwischen WaWi und Router und trace alles mit was vom Shop kommt, dann weist du sofort was los ist.
Ggf. hilft auch der NetMonitor von MS direkt auf dem WaWi sofern das WaWi ein Winblows Rechner ist...
Das einzige was er kann wäre die Ports trotz aktiviertem Forwarding blocken, was dann auf einen Fehler der Firmware zurückzuführen wäre....
Wie gesagt schleif einen Sniffer zwischen WaWi und Router und trace alles mit was vom Shop kommt, dann weist du sofort was los ist.
Ggf. hilft auch der NetMonitor von MS direkt auf dem WaWi sofern das WaWi ein Winblows Rechner ist...
Leider konnte ich unser Problem auch nicht durch den Einsatz eines Sniffers lösen. Der Shop sperrt sich nach wie vor UNGEWOLLT, ohne dass eine Logik erkennbar ist. Ich habe den Wireshark auf dem Wawi-Server installiert. Eine Datenreplikation, die ich auf unserem Shop-Server bei 1&1 starte, funktioniert immer ohne Probleme (wird erfolgreich abgeschlossen). Der Wireshark zeigt mir an, wie die IP-Adresse vom Shop-Server auf unseren Wawi-Server zugreift. Die Datenreplikation dauert immerhin ca. 40 Minuten. Bei einer einfachen Artikelsuche im (Test-) Shop erfolgt häufig eine sofortige Shop-Sperre.
Shop und Warenwirtschaft sind übrigens von der Fa. PARITY (AB 1000 und EC 1000).
Die Telekom rätselt ebenfalls. Die wollen eventuell einen Test mit einem anderen Router machen.
Auch wenn es mir nicht logisch erscheint:
Kann eventuell das Forwarding für den Port 80 auf den Router statt auf den Server die Ursache sein?
Einstellungen Router:
Für folgende Ports habe ich ein Forwarding eingerichtet:
Port 80 (Protokoll TCP) auf den Router (!)
Port 111 (Protokoll TCP/UDP) auf den Server
Port 4000-4005 (Protokoll TCP/UDP) auf den Server
Externer Port = umgeleiteter Port
Zeitplan: ständig verbunden
Sonstige Einstellungen:
Shopsperrung: 1-6 Uhr nachts
Datensicherung Wawi: 1:30-3:30 Uhr nachts (dauert ca. 2 Stunden), danach Neustart des Servers
Updates: automatisch um 4 Uhr nachts zugelassen
Disconnect des Routers: zw. 3-4 Uhr nachts (läuft nicht exakt synchron, startet jeden Tag eine Minute später -> normal?)
DSL 6000 (stabile gute bis sehr gute Geschwindigkeit) --> 500 kbit/s Uploadgeschwindigkeit ausreichend?
Shop und Warenwirtschaft sind übrigens von der Fa. PARITY (AB 1000 und EC 1000).
Die Telekom rätselt ebenfalls. Die wollen eventuell einen Test mit einem anderen Router machen.
Auch wenn es mir nicht logisch erscheint:
Kann eventuell das Forwarding für den Port 80 auf den Router statt auf den Server die Ursache sein?
Einstellungen Router:
Für folgende Ports habe ich ein Forwarding eingerichtet:
Port 80 (Protokoll TCP) auf den Router (!)
Port 111 (Protokoll TCP/UDP) auf den Server
Port 4000-4005 (Protokoll TCP/UDP) auf den Server
Externer Port = umgeleiteter Port
Zeitplan: ständig verbunden
Sonstige Einstellungen:
Shopsperrung: 1-6 Uhr nachts
Datensicherung Wawi: 1:30-3:30 Uhr nachts (dauert ca. 2 Stunden), danach Neustart des Servers
Updates: automatisch um 4 Uhr nachts zugelassen
Disconnect des Routers: zw. 3-4 Uhr nachts (läuft nicht exakt synchron, startet jeden Tag eine Minute später -> normal?)
DSL 6000 (stabile gute bis sehr gute Geschwindigkeit) --> 500 kbit/s Uploadgeschwindigkeit ausreichend?
Das Problem konnten wir Ende März durch den Einbau einer neuen TK-Anlage lösen. Die TK-Anlage ist von der Telekom und übernimmt nun wieder das Routing. Die Einstellungen in der Firewall und das Port-Forwarding hat ein freundlicher Mitarbeiter der Telekom durchgeführt.
Der Speedport 400 P ist nun zur Nutzlosigkeit verurteilt.
Ich vermute, dass das Problem in der alten TK-Anlage zu suchen ist. Die hat früher das Routing übernommen. Da diese nur für 1500er-DSL ausgelegt war, haben wir das Routing dann an einen externen Router (Speedport 400 P) übertragen. Die DSL-Geschwindigkeit entsprach anschließend 6000er-DSL.
Übrigens: Die neue TK--Anlage (ComfortPro), die wir gemietet haben, ist deutlich günstiger, als die alte TK-Anlage (Vorgängermodell). Der Mietvertrag für die alte Anlage wäre ohnehin im Oktober 2009 ausgelaufen. Somit haben wir zumindest hier keinen Verlust zu beklagen.
Der Speedport 400 P ist nun zur Nutzlosigkeit verurteilt.
Ich vermute, dass das Problem in der alten TK-Anlage zu suchen ist. Die hat früher das Routing übernommen. Da diese nur für 1500er-DSL ausgelegt war, haben wir das Routing dann an einen externen Router (Speedport 400 P) übertragen. Die DSL-Geschwindigkeit entsprach anschließend 6000er-DSL.
Übrigens: Die neue TK--Anlage (ComfortPro), die wir gemietet haben, ist deutlich günstiger, als die alte TK-Anlage (Vorgängermodell). Der Mietvertrag für die alte Anlage wäre ohnehin im Oktober 2009 ausgelaufen. Somit haben wir zumindest hier keinen Verlust zu beklagen.
