Router-Konfiguration! ENDGÜLTIGE ERKLÄRUNG

M

msb

Gast
PASSIV MODUS! ENDGÜLTIGE ERKLÄRUNG

so nachdem ja recht viele das problem haben mit routern und den passiv modus...habe ich mal in der gemeinde rummgestöbert!!!!!!!!! der text wurde von Otifant verfaßt im forum
www.netzwerkrouter.de
wie er schon sagt bzw schreibt....dies gilt für ALLE router!!! also lesen.....:D ................gruß msb.........
 
teil 1!

Vorweg : Lest ALLES. Der Text ist lang, ich weiss.

Ich beziehe mich bei diesem Text auf den Router SMC Barricade 7004BR. Das Problem mit dem FTP Protokoll ist allerdings, bis auf den P@SW Bug, bei allen NAT-Routern das gleiche und somit nicht nur für Besitzer dieses Routers interessant. Der einzige unterschied ist, dass der Router eben entsprechend anders Konfiguriert werden muss.

Weiterhin erwähne ich in dem Text nur FTP-Server, die unter Windows laufen, da ich mit anderen OS wenig Erfahrung habe. Für Linux und den rest gibt es aber 100%ig ebenfalls geeignete Server, patches sollten bei Open-Source Projekten sogar viel schneller herauskommen als bei den Windows-Servern.

Und jetzt geht's los.

Wie funktioniert das mit dem FTP...

- Allgemeines -

Das FTP Protokoll stammt noch aus einer Zeit, in der jeder vernetzte PC auch seine eigene IP Adresse hatte. Schickte man ein Paket an diese Adresse, konnte man sich sicher sein, daß dort ein einzelner Rechner stand, der (wenn er eingeschaltet war) das Paket annahm.

Aber Otto Normalverbraucher bekommt heute von (z.B.) T-Online nur eine einzige -öffentliche IP- (d.h. eine IP, unter der man im Internet erreichbar ist) zugewiesen, und die ist zudem bei jeder Einwahl noch eine andere.

DSL-Router-Besitzer sind nun wohl im Besitz ihres Routers, weil sie mit mehreren Rechnern gleichzeitig ins Internet wollen. Was ist also das Problem ? Wir haben -drei- Rechner, aber nur -eine- öffentliche IP.

Genau hier kommt der Router ins Spiel. Er übernimmt die Aufgabe, die Datenpakete von seinen Clients im Heim-LAN ins Internet weiterzuleiten, aber auch, die Pakete die zurückkommen, wieder an den richtigen Rechner zurückzuleiten.
 
teil 2!

Möchte man sich eine Webseite ansehen, 'merkt' der Router, von welchem Rechner die Anfrage nach der Information kam. Die Informationen, die dann von dem Webserver zurückkommen, werden an den Rechner zurückgeleitet, der die Anfrage gestellt hat. Dies nennt sich NAT (Network Address Translation), unter Linux IP-Masquerading.

Soweit so gut, aber was tut der Router, wenn Pakete eintreffen, die (so wie es für ihn aussieht) niemand angefordert hat ? Z.B. bei einem FTP server. Es kann zu jeder beliebigen Tageszeit irgendjemand der die Zugangsdaten zu meinem FTP hat auf die Idee kommen, diesen zu connecten. Der Router weiss aber in diesem Fall nicht, für wen diese sog. 'incoming connection' bestimmt ist.

Der SMC router reagiert in diesem Fall so:

1. Er schaut, ob der Port, auf den connected wird, standardmässig auf einen bestimmten Rechner umgeleitet werden soll (dies ist beim Barricade in den Einstellungen unter 'Virtual Server' einzustellen). Ist dies der Fall, tut es der Router auch brav und das Paket erreicht seinen Bestimmungsort.

2. Manche Internet Services funktionieren nicht nach dem 'Webserver-Prinzip'. Möchte ich sie nutzen, schickt ein Programm auf meinem Rechner eine Anfrage an einen Server im Internet 'raus (nennen wir ihn Server 1). Dieser schickt mir aber selber keine Daten zurück, sondern veranlasst, dass ich von einem anderen Server (Server 2) mit einer anderen IP Adresse meine Pakete zugeschickt bekomme. Der Router weiss in diesem Fall aber nicht, was er mit den Paketen von dem 2. Server anfangen soll, es hat ja niemand welche von diesem angefordert.

Genau für diese Programme lassen sich die sog. 'Special Applications' einrichten. Applikationen, von denen bekannt ist, dass sie diese Technik verwenden. Viele der Services, die nach diesem Prinzip funktionieren, versuchen, den client immer auf dem gleichen Port zu erreichen, und auch das Programm, das ich verwende, connected den ersten Server immer
auf dem gleichen Port. Was nun also bei einem korrekten 'Special AP' Eintrag passiert ist: Das Programm auf meinem PC connected Server 1 auf Port X. Dieser Port ist der sog. 'Trigger Port' und ist in den Special AP eingetragen. Unter 'incoming ports' müssen dann die Ports stehen, auf denen Server 2 versucht zurückzuconnecten. Die Pakete von Server 2 werden dann an den richtigen PC weitergeleitet. Der Router 'weiß' also jetzt, nach welchem Schema die von uns benutzte Applikation arbeitet, und reagiert entsprechend.

3. Greift keine der obigen Regeln, wird das Paket an den DMZ-Host weitergeleitet. Ist kein DMZ Host definiert, verwirft der Router das Paket. Es ist verloren.

- Zum FTP Transfer -

Wenn 2 Rechner über das FTP-Protokoll miteinander kommunizieren, teilt ein Rechner andauernd dem anderen mit, unter welcher IP Adresse und auf welchem Port er erreichbar ist (mit dem PORT-Kommando). Der andere Rechner schickt seine Daten dann an diese übermittelte Adresse.

-Welcher- Rechner dem anderen jetzt sagt welche IP er hat und auf welchem Port er hört, kommt darauf an, ob man im sog. 'active mode' oder 'passive mode' arbeitet. 'Active mode' bedeutet, dass der FTP-*Client* dem FTP-*Server* seine Adresse+Port schickt, beim 'passive mode' ist es genau umgekehrt. Der Passive mode wird erst dann aktiviert, wenn der Client dem Server das Kommando PASV schickt, dies passiert im Laufe der Kommunikation dann vor jedem Kommando bei dem ein Datentransfer geschieht. Der Server schickt auf dieses PASV Kommando hin dem Client den PORT Befehl, und dahinter IP+Port, unter denen er erreichbar ist (z.B. PORT 217,84,189,179,x,y wobei aus x und y hier die Portnummer errechnet wird, auf denen der Server hört - und ja, es sind Kommata, und keine Punkte). Datentransfers fließen dann zu dieser Adresse. Ob active oder passive mode verwendet wird, legt immer der *Client* fest, es sei denn, es wird durch einen Trick vom Server 'untersagt' (dazu später, siehe 'P@SW Bug/Feature').

- Einschub -
Es gibt 'öffentliche' und 'private' IP Adressen. Unter einer öffentlichen Adresse ist man im Internet erreichbar, unter einer privaten NICHT. Die Privaten IP Adressen wurden für LANs reserviert, die innerhalb dieses Adressraums untereinander kommunizieren, ohne dass der Datenverkehr über's Internet läuft.

Private IP Adressen sind:
1. 10.0.0.0 - 10.255.255.255
2. 172.16.0.0 - 172.31.255.255
3. 192.168.0.0 - 192.168.255.255
---

Hat man eine Netzwerkkarte im Rechner, ist dieser eine private IP zugeordnet. Tut man dies nicht manuell, tut es das Betriebssystem (kann nur mit Windows-Erfahrung sprechen, denke aber, andere Betriebssysteme werden dies genauso machen). Theoretisch kann man seinem Rechner sogar eine öffentliche IP zuordnen, unter dieser ist man dann aber nicht im Internet erreichbar (ausser man bekommt vom Provider eine gültige, feste öffentlich IP Adresse - aber ich gehen hier jetzt von T-DSL aus), und somit wäre dies schlichtweg eine falsche Einstellung, zum anderen kann es dadurch auch u.U. zu Verbindungsproblemen kommen.

Sowohl FTP-Clients als auch FTP-Server, die auf einem Rechner hinter einem DSL-Router laufen, können nur 'sehen', dass ihr Rechner die private IP Adresse der Netzwerkkarte 'besitzt'. Von der öffentlichen IP 'wissen' sie nichts. Dies hat u.U. fatale folgen, Beispiel FTP Server:

Der Client connected den Server und wechselt per PASV Kommando in den PASSIVE mode. Wie oben geschrieben, sendet im Passive Mode der FTP-*Server* dem *Client*, unter welcher Adresse+Port er erreichbar ist. Nach dem PASV Kommando des Clients schickt ein FTP Server, der hinter dem DSL Router ist, aber seine PRIVATE IP Adresse 'raus (z.B. PORT 192,168,100,3,x,y) - dies ist schlichtweg die falsche IP Adresse. Unter dieser wird er keine Daten aus dem Internet empfangen können. Der Client versucht also nun, zu dieser IP Adresse eine Verbindung aufzubauen und scheitert. Nach einiger Zeit wird diese FTP-Verbindung einen Timeout bekommen und zusammenbrechen.

Da also Transfers im Passive Mode (nach diesem Schema) sowieso nicht funktionieren, hat SMC in älteren Firmware Versionen einen Filter eingebaut, der, sobald jemand auf Port 21 das PASV Kommando schickte, dieses in P@SW umgewandelt hat. Der FTP Server bekam also statt PASV P@SW zugeschickt, konnte mit diesem Kommando nichts anfangen und reagierte mit einer Fehlermeldung. Die einzige Auswirkung war allerdings, dass die Transfers weiterhin im Active Mode fortgeführt wurden, was dann auch (sofern nicht irgendwo eine nicht ensprechend konfigurierte Firewall Pakete blockte, oder der Client selber hinter einem NAT-Router war, dazu später mehr) funktionierte.

In den letzten Firmware Versionen scheint SMC dieses 'P@SW'-Feature aber wieder entfernt zu haben, zumindest bei mir ist es nicht mehr vorhanden (Firmware 1.94a).

- Die Lösung(en) -

Es gibt verschiedene Lösungsansätze für das FTP-Problem. Die sauberste ist, bzw. wäre, dass der FTP-Server eben nicht seine -private-, sondern seine -öffentliche- Adresse nach Erhalt des PASV Kommandos sendet. Es gibt FTP-Programme, die genau für diesen Fall ausgelegt sind. Mir sind Serv-U und Crush-FTP bekannt, die beide einen dyndns Provider benutzen, um ihre öffentliche IP zu ermitteln und somit das oben beschriebene Problem elegant umgehen.

Bei anderen Servern wie z.B. G6 FTP Server aka Bulletproof FTP Server kann man die IP, die im Passive mode gesendet werden soll, manuell festlegen. Dazu muss man diese (z.B.) im webinterface des Routers ablesen und von Hand im FTP-Server eintragen.

Bei diesen beiden Lösungen müssen allerdings, wenn der FTP-Server-Rechner nicht als DMZ Host eingetragen ist, noch weitere Eintellungen im FTP-Server vorgenommen werden (listen ports, dazu später mehr).

Die dritte Möglichkeit ist im Prinzip das, was SMC mit seinem P@SW Konverter getan hat. Man verhindert einfach, dass der Server in den Passive Mode wechselt. Dazu kann man z.B. mit einem Hex-Editor das PASV Kommando aus dem Exe-File des FTP Servers umschreiben, so dass der Server wenn er das PASV Kommando bekommt, dieses nicht mehr erkennt.
Dies habe ich schon erfolgreich bei WAR-FTP 1.67 gemacht.

- Dies ist aber die schlechteste Lösung, da bei einer bestimmten Clientkonfiguration (Firewall, ebenfalls hinter NAT-Router etc.) keine Verbindung zustande kommt. -

- DMZ Host, listen Ports, Special APs -

Der eine oder andere wird sich vielleicht Fragen, warum die im Forum geposteten (und sogar in der FAQ zitierten) Router-Einstellungen bei ihm manchmal funktionieren, manchmal nicht, oder auch überhaupt nicht. Ich lese immer wieder, wie einige leute mit vehemenz behaupten, man soll Ports 20 und 21 unter Special AP eintragen (und das war's) - und diverse andere Vorschläge. Dies stimmt so aber nicht.

Man muss bei der Konfiguration des Routers und des FTP-Servers mehrere Fälle unterscheiden. Zum einen, ob der Client im active oder passive mode arbeiten will, zum anderen, ob der FTP-Server-Rechner als DMZ Host eingetragen ist, oder nicht. An den DMZ (DeMilitarized Zone)-Host werden standardmässig alle Pakete aus dem Internet übertragen, für die keine der Regeln unter 'Virtual Server' oder 'Special AP' greifen.

1. Fall: Client will im active Mode arbeiten (FTP-Server ist NICHT DMZ)

Der Client connectet unsere öffentliche IP-Adresse auf Port 21 und will im active mode arbeiten. In diesem Fall wird der Server lediglich auf den Ports 20 und 21 connected, und es reicht, diese unter virtual server einzutragen.

2. Fall: Wie Fall 1, aber der Server ist DMZ HOST

In diesem Fall muss unter Virual Server / Special APs überhaupt nichts eingetragen werden. Alle Verbindungen werden automatisch an den FTP-Server weitergeleitet.

3. Fall: Client will im Passive Mode arbeiten, FTP-Server ist NICHT DMZ

Etwas verzwickter. Wir benötigen zunächst einen FTP-Server, der es uns ermöglicht, die zu sendende (öffentliche) IP für den Passive Mode manuell festzulegen, oder diese sogar automatisch herausfindet. Wie schonmal genannt, funktioniert dies mit Serv-U, CrushFTP und G6 FTP aka Bulletproof FTP (diese sind mir bekannt, es gibt bestimmt noch mehr). Im Passive Mode wird unser FTP Server dem Client den Port, auf dem dieser für die Datenverbindung zurückconnecten soll, vorgeben. Wird dieser Bereich nicht vom User bzw. Server eingeschränkt, wird irgendein Port dynamisch ausgewählt. Unser FTP-Server-Rechner ist aber nicht DMZ Host, und somit werden Connections, die an einen nicht unter Virtual Server aufgeführten Port gehen, geblockt. Die FTP Verbindung bricht zusammen. Wir müssen also dem Client einen bestimmten Portbereich vorgeben, auf dem dieser connecten soll (sog. 'listen ports' für den Server (der Server 'horcht'(=listen) auf diesen Ports nach einer neuen Verbindung)), und -gleichzeitig- genau diesen Portbereich unter 'virtual server' eintragen, so dass eingehende Verbindungen auf diese Ports auch bei unserem FTP Server ankommen und nicht vom Router geblockt werden. Zusätzlich muss natürlich der Port 21 im Virtual Server eingetragen werden, wie es sich mit Port 20 verhält weiss ich in diesem Fall nicht, da mein Rechner immer DMZ Host ist und ich gerade keine Lust habe es auszuprobieren *G* - notfalls probieren. Diese Lösung lässt sich auf jeden Fall mit G6 FTP aka Bulletproof FTP durchführen, dort habe ich es getestet. Zu anderen FTP Servern kann ich in der Beziehung nichts sagen.

4. Fall: Client will im Passive Mode arbeiten und FTP-Server ist DMZ

Hier muss man 'lediglich' den Server dazu bringen, die richtige öffentliche IP an den Client zu senden (s.o.) - die listen ports fallen weg, da sowieso alle portconnections auf den DMZ Host weitergeleitet werden.

Wir sehen also, es gibt verschiedne Möglichkeiten, allerdings kann der Server wirklich nur von ALLEN Clients connectet werden, wenn die in 3 bzw. 4 beschriebenen Einstellungen vorgenommen wurden. Mit ALLE clients meine ich allerdings nur diejenigen, bei denen Netzwerktechnisch alles richtig funktioniert, die entweder keine Firewall installiert oder diese eben richtig Konfiguriert haben (und ich kenne allein schon GENUG Leute, die zwar der festen Überzeugung sind, dass dies bei ihnen der Fall ist, bei denen aber nichts läuft...), und bei denen, sofern sie selbst hinter einem NAT-Router sitzen, der Client richtig Konfiguriert ist (dazu später mehr).

- P@SW Bug / Feature -

Wie oben genannt, hat SMC versucht, mit der Konvertierung des Befehls PASV nach P@SW auf Port 21 den Passive Mode zu verhindern, da dieser sowieso nicht funktionieren würde. Löblich, allerings lässt sich, wie wir gesehen haben, mit den entsprechenden Einstellungen der Passive Mode ja doch verwenden, und ist auch in gewissen Situationen die einzige Möglichkeit den FTP Transfer zum Laufen zu bringen. In der neuen Firmware 1.94a ist dieser Bug / dieses Feature ohnehin entfernt worden, und ich meine sogar, in der Vorgängerversion wäre dies auch schon so gewesen, aber wenn jemand aus bestimmten Gründen eine ältere Firmware benutzt (Stabilität, Access Control z.B.), möchte er dieses Problem bestimmt umgehen. Witzigerweise ist die Lösung recht einfach: Entweder man lässt den FTP-Server auf einem anderen Port laufen als 21 (diese 'überwacht' der Barricade nämlich nicht), oder aber man trägt Port 21 unter Virtual Server ein, was ja bei vielen sowieso schon der Fall sein dürfte.

Eine andere, 'unkonventionellere' Möglichkeit ist es auch hier wieder, den FTP Server zu patchen, d.h. mit einem HEX-Editor im Programmfile des Servers die Zeichenfolge PASV durch P@SW zu ersetzen, so dass der Server das Kommando P@SW als Befehl interpretiert, in den Passive Mode zu wechseln. Der Bug wird hiermit also ausgehebelt. Ich habe dies lediglich in anderer Form an WAR-FTP 1.67 getestet (s.o.) - es sollte aber problemlos funktionieren. Dabei darf man aber nicht vergessen, dass der Server/Router trotzdem noch wie oben beschrieben konfiguriert werden muss. Dies hier hebelt lediglich den P@SW bug aus.

- Client Konfiguration / Firewall -

Wenn man hinter einem NAT-Router sitzt, kann man dieses Problem nicht nur beim Aufsetzen eines FTP-Servers bekommen, sondern auch bei der Benutzung eines FTP-Clients. Hierbei befinden wir uns zwar auf der 'anderen Seite', aber rein technisch gesehen in genau der gleichen Problemsituation. Arbeitet man im Active Mode, sendet der Client per PORT Kommando seine IP+Port - und macht genau den gleichen Fehler wie der Server, er nimmt nämlich die private IP Adresse, unter der man keine Daten aus dem Internet empfangen kann. Auch hier sollte die Verbindung theoretisch abbrechen, allerdings habe ich in der Praxis festgestellt, dass bei vielen (gerade großen FTPs von Firmen etc.) trotz der 'fehlerhaft' übermittelten IP die Verbindung einwandfrei funktioniert. Erklären kann ich mir das lediglich so, dass der FTP-Server auf der anderen seite das PORT Kommando (zumindest die IP) ignoriert, und die Daten ganz einfach an die IP weiterleitet, von der aus die Verbindung hergestellt wurde. Auch beim FTP-Client muss man u.U. listenports einrichten (ein Client, bei dem dies geht ist z.B. Flash-FXP) und diese im DSL-Router unter Virtual Server eintragen, sofern man nicht DMZ Host ist.

Man sieht, es muss also nicht immer ausschliesslich am Server liegen, wenn etwas nicht funktioniert, sondern es kann durchaus auch der Client falsch konfiguriert sein. Ausserdem gibt es spezialisten, die eine Firewall installieren die durch das Blocken von Ports die FTP-Verbindung von vornherein zum scheitern verurteilt. Eine Firewall muss richtig konfiguriert sein, sonst schadet sie u.U. mehr als sie nützt.
 
Vielen Dank für diesen Text, msb!
Ich habe mir erlaubt den Betreff ein wenig zu modifizieren, ich hoffe es stört Dich nicht.
 
gute neuigkeiten!!!!!

smc unterstüzt jezt pasv mode.... mit der fa 1.94a !!!!!!!!!
genauso die router von d-link..........fa unbekannt....!!!!!

bei fragen hier posten........ich bemühe mich euch dann zu helfen.....

gruß msb.........und gut download.........
 
ok
ich habe im G6 für passive die ports 202-206 eingestellt, und die auch im router weitergeleitet.

wenn ich das richtig verstanden habe muß ich jetzt jewails meine aktuelle internet ip auch dort eintragen richtig?

geht das irgendwie auch einfacher ich nutze no-ip.com
 
hmm also wie date ich den die frimware ab???
Dabei sollte aber dann auch kein rechner auf's netz zugreifen oder ist das egal???

und damit mit no-ip würd ich auch gerne mal wissen.
Also wie ich das anbekomme.
Ich habe den SMC 7004ABR


MfG
 
Zum Firmware-Update: Keine Ahnung wie das geht, aber grundsätzliche sollte bei einem Firmware-Update das verwendete Gerät grundsätzlich im Ruhezustand sein.
Das mit der passive Mode IP ist ab der aktuellen Version 2.21 kein Problem mehr, dort kann man dann auch den no-ip-Namen eingeben.
 
hmm ok hab jetzt das update durch geführt. Alles bestens geklappt und nach dem ich wieder die virtuellen server eingetragen habe läuft auch alles wieder wie gewohnt.
Ansonsten werd ich weiter schauen müssen.



MfG
 
ok alles bestens, hab jetzt mit dem direcupdate von dyndns keine probs mehr, jetzt läuft einfach alles. Also noch mal besten dank für die hilfe.



MfG
 
hmm ich bekommen das nich hin, ich habn netgear r114 bpftp , directupdate (ka wie das läuft, habs einfah) und zonealarm

bei bpftp hab ich eigentlich alles eingestellt, ich kann von meinem pc aus darauf zu greifen aber is ja nur localhost, aber anders nich! das geht auch nut mit nem ftp programm, wenn ich das im ie versuche kommt entweder "seite nich gefunden" oder er will nen benutzernamen und pw für r114 (mein ruter) aber da geht nix was ich bisher versucht hab!

leider hab ich ka ob netgear auch "virtual server" hat, ich hab bei ddns mein ddns eingetragen :) und versucht port 21 und 20 mit meiner priv. ip freizugeben:

start port: end prot: ip:
20 20 192.168.0.3
21 21 192.168.0.3

mehr hab ich nicht gefunden was ich beim router noch einstellen könnte. vileicht könnt ihr mir ja helfen :) jedenfalls hab ich das was da ganz oben steht nich so richtig begriffen (ich kann auch im passiv mode aufn localhost zugreifen.)
 
Hast du mal versucht per http://www2ftp.de einzuloggen? Ich vermute, wenn du alles rivhtig eingestellt hast, dass dein Router (wie beinahe alle) kein sog. loop-back unterstützt.
Hat irgendjemand anders mal versucht von außen (also außerhalb deines Netzwerkes darauf zuzugreifen?
 
ich hab bisher nur versucht nen gamevoice server zu starten, aber wenn ich beim ftp prog meine dynadresse angebe dann is das ja eigentlich von ausssen, und das geht nicht
 
Ut Server aufmachen!

Hallo,

wenn jemand sich mit UT2k3 auskennt, dann bitte ich um Hilfe!
Ich weiss nicht was ich bei Virtual Server eingeben soll, damit ich bei UT2k3 einen Server aufmachen kann(Um zu Hosten als Admin.)
Ich habe einen DSL Router von SMC, ich habe leider keine Ahnung welche Ports und sonst noch mehr eingeben soll.
Ich weiss wie das geht aber nicht was ich da eingeben soll.

MfG »XMAN«
 
Oben