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.