151
Experte für VPN - VPN-Verbindung herstellen
Hallo
Ich bin am sammeln von ersten VPN Erfahrungen und habe paar Fragen.
Ausgangslage:
Ich habe einen Windows Server 2012 R2 und habe dort die Rolle RRAS installiert, damit ich vom Computer meiner Mutter (liegt in einem anderen Netzwerk) verbinden kann und meine IP-Adresse nutzen kann etc. Das funktioniert nun alles soweit der Haken dahinter ist leider, dass ich jedes mal die Firewall vom Router deaktivieren muss damit eine Verbindung zum VPN-Server hergestellt werden kann.
Problem:
Nach langer Recherche und das Auslesen von Logs fand ich heraus, dass das GRE das Problem verursacht und die Firewall diese Pakete verwirft.
Was ich nun komisch finde ist dass, der RRAS-Dienst auf Windows Server 2012 R2 als VPN-Protokoll SSTP verwendet welches auf dem TCP/IP-Modell Anwendung stattfindet und die darunterliegenden Protokolle wie SSL/TLS verwendet. Das obwohl GRE, PPTP und SSTP zwei ganz unterschiedliche Arten sind um eine Verbindung mit VPN herzustellen. Ich habe ich mich schlau gemacht und habe herausgefunden das es da noch andere Protokolle fürs Herstellen von VPN-Verbindung gibt:
1.) L2TP darunterliegenden Protokoll IPsec
2.) PPTP darunterliegenden GRE-Protokoll
3.) SSTP darunterliegenden TLS-Protokoll (habe ich oben ja bereits erwähnt)
Nun wenn ich über den Client eine VPN-Verbindung herstellen zu versuche, versucht er mit "WAN Miniport SSTP" und "L2TP" eine Verbindung herzustellen. Wieso mit unterschiedlichen Methoden (SSTP und L2TP)? Der VPN-Server arbeitet doch mit dem SSTP-Protokoll und weiter habe ich auf dem NAT-Router den PPTP Port 1789 freigegeben. Wieso kann eine VPN-Verbindung über diesen Port 1789 hergestellt werden wenn mein VPN-Server über SSTP (443) arbeitet? Weiter kommt ja auch noch hinzu das der Router GRE ständig blockiert wenn ich Firewall deaktiviert ist.
Ziel:
Mein Ziel wäre nur noch SSTP zu verwenden bei Google steht ja immerhin das damit NAT-Router und Firewall Probleme umgangen sollen. Weiter müsste ich nicht die Firewall deaktivieren. Wie erreiche ich das? Kann mir da jemand helfen dieses Wirrwar von Netzwerkprotokollen zu lösen?
Liebe Grüsse
Nicolas
Ich bin am sammeln von ersten VPN Erfahrungen und habe paar Fragen.
Ausgangslage:
Ich habe einen Windows Server 2012 R2 und habe dort die Rolle RRAS installiert, damit ich vom Computer meiner Mutter (liegt in einem anderen Netzwerk) verbinden kann und meine IP-Adresse nutzen kann etc. Das funktioniert nun alles soweit der Haken dahinter ist leider, dass ich jedes mal die Firewall vom Router deaktivieren muss damit eine Verbindung zum VPN-Server hergestellt werden kann.
Problem:
Nach langer Recherche und das Auslesen von Logs fand ich heraus, dass das GRE das Problem verursacht und die Firewall diese Pakete verwirft.
Was ich nun komisch finde ist dass, der RRAS-Dienst auf Windows Server 2012 R2 als VPN-Protokoll SSTP verwendet welches auf dem TCP/IP-Modell Anwendung stattfindet und die darunterliegenden Protokolle wie SSL/TLS verwendet. Das obwohl GRE, PPTP und SSTP zwei ganz unterschiedliche Arten sind um eine Verbindung mit VPN herzustellen. Ich habe ich mich schlau gemacht und habe herausgefunden das es da noch andere Protokolle fürs Herstellen von VPN-Verbindung gibt:
1.) L2TP darunterliegenden Protokoll IPsec
2.) PPTP darunterliegenden GRE-Protokoll
3.) SSTP darunterliegenden TLS-Protokoll (habe ich oben ja bereits erwähnt)
Nun wenn ich über den Client eine VPN-Verbindung herstellen zu versuche, versucht er mit "WAN Miniport SSTP" und "L2TP" eine Verbindung herzustellen. Wieso mit unterschiedlichen Methoden (SSTP und L2TP)? Der VPN-Server arbeitet doch mit dem SSTP-Protokoll und weiter habe ich auf dem NAT-Router den PPTP Port 1789 freigegeben. Wieso kann eine VPN-Verbindung über diesen Port 1789 hergestellt werden wenn mein VPN-Server über SSTP (443) arbeitet? Weiter kommt ja auch noch hinzu das der Router GRE ständig blockiert wenn ich Firewall deaktiviert ist.
Ziel:
Mein Ziel wäre nur noch SSTP zu verwenden bei Google steht ja immerhin das damit NAT-Router und Firewall Probleme umgangen sollen. Weiter müsste ich nicht die Firewall deaktivieren. Wie erreiche ich das? Kann mir da jemand helfen dieses Wirrwar von Netzwerkprotokollen zu lösen?
Liebe Grüsse
Nicolas
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: 268663
Url: https://administrator.de/forum/experte-fuer-vpn-vpn-verbindung-herstellen-268663.html
Ausgedruckt am: 22.12.2024 um 14:12 Uhr
151 Kommentare
Neuester Kommentar
Hallo,
Gruß
Weiter müsste ich nicht die Firewall deaktivieren
Warum deaktivieren? Warum schaltest du nicht einfach GRE (47) frei auf der Firewall?Gruß
Wenn man sowas wie GRE nicht am Router direkt "freischalten" kann, gibt es meist eine Option "VPN Passthrough" oÄ, mit der man die üblichen Verdächtigen freischalten kann.
Um was für einen Router handelt es sich denn?
Um was für einen Router handelt es sich denn?
Die entsprechenden Foren Tutorials zum Themnnkomplex VPN Grundlagen und Installation hast du dir mal alle gründlich durchgelesen ??
PPTP:
VPNs einrichten mit PPTP
OpenVPN:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
IPsec:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Das wäre der erste wichtige Schritt damit du wenigstesn die Basics im Hinterkopf hast !
Nur kurz vorab zu den Fragen:
Jeder Netzwerker weiss das PPTP aus den Protokoll Komponenten TCP 1723 und dem GRE Protokoll (IP Nummer 47) besteht:
http://de.wikipedia.org/wiki/Point-to-Point_Tunneling_Protocol
TCP 1789 ist völlig falsch, kein VPN Protokoll nutzt diesen Port ! Mal ganz abgesehen davon ist der ofiziell keinerlei VPN Funktion zugeordnet:
http://www.iana.org/assignments/service-names-port-numbers/service-name ...
Wie kommst du also auf so einen Unsinn ?!
Vermutlich liegt das aber nur schlicht und einfach daran das du für PPTP den falschen Port benutzt hast. Wenn du TCP 1723 einträgst forwarden intelligente Router das GRE Protokoll gleich mit.
Bei anderen wie der FritzBox (siehe Screenshot im o.a. PPTP Tutorial !) musst du das GRE Protokoll noch zusätzlich eintragen damit es klappt !
PPTP:
VPNs einrichten mit PPTP
OpenVPN:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
IPsec:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Das wäre der erste wichtige Schritt damit du wenigstesn die Basics im Hinterkopf hast !
Nur kurz vorab zu den Fragen:
Wieso mit unterschiedlichen Methoden (SSTP und L2TP)?
Das ist ein Default Setting des Clients (siehe PPTP Tutorial). Wenn man nix macht und nicht dediziert das VPN Protokoll wählt wie es sich gehört macht der Winblows Client erstmal der Reihe nach alles... Andere Clients fragen sowas sinnigerweise vorher ab im Setup.auf dem NAT-Router den PPTP Port 1789 freigegeben.
Völliger Blödsinn und kann man eher deiner totalen Unkenntniss der VPN Protokolle zuschreiben. Deshalb auch der dringende Apell an dich wenigstens das kleinen Einmaleins des VPNs zu lernen und zu recherchieren !Jeder Netzwerker weiss das PPTP aus den Protokoll Komponenten TCP 1723 und dem GRE Protokoll (IP Nummer 47) besteht:
http://de.wikipedia.org/wiki/Point-to-Point_Tunneling_Protocol
TCP 1789 ist völlig falsch, kein VPN Protokoll nutzt diesen Port ! Mal ganz abgesehen davon ist der ofiziell keinerlei VPN Funktion zugeordnet:
http://www.iana.org/assignments/service-names-port-numbers/service-name ...
Wie kommst du also auf so einen Unsinn ?!
Weiter kommt ja auch noch hinzu das der Router GRE ständig blockiert wenn ich Firewall deaktiviert ist.
Das liegt aber an deinem Router wenn du solch üble HW hast die nichtmal sowas supportet was jeder 20 Euro Baumarkt Router kann !Vermutlich liegt das aber nur schlicht und einfach daran das du für PPTP den falschen Port benutzt hast. Wenn du TCP 1723 einträgst forwarden intelligente Router das GRE Protokoll gleich mit.
Bei anderen wie der FritzBox (siehe Screenshot im o.a. PPTP Tutorial !) musst du das GRE Protokoll noch zusätzlich eintragen damit es klappt !
Zitat von @michi1983:
Hallo,
> Weiter müsste ich nicht die Firewall deaktivieren
Warum deaktivieren? Warum schaltest du nicht einfach GRE (47) frei auf der Firewall?
Gruß
Hallo,
> Weiter müsste ich nicht die Firewall deaktivieren
Warum deaktivieren? Warum schaltest du nicht einfach GRE (47) frei auf der Firewall?
Gruß
Leider war ich auch da nicht erfolgreich. Als ich die Freigeschaltet habe stand im LOG weiterhin GRE -> droped
Zitat von @SeaStorm:
Wenn man sowas wie GRE nicht am Router direkt "freischalten" kann, gibt es meist eine Option "VPN Passthrough"
oÄ, mit der man die üblichen Verdächtigen freischalten kann.
Um was für einen Router handelt es sich denn?
Wenn man sowas wie GRE nicht am Router direkt "freischalten" kann, gibt es meist eine Option "VPN Passthrough"
oÄ, mit der man die üblichen Verdächtigen freischalten kann.
Um was für einen Router handelt es sich denn?
Es handelt sich um einen ZyXEL NBG460N. Ist halt nur ein Home-Router... Vermutlich gibt das dort nicht mal.
Zitat von @aqui:
Die entsprechenden Foren Tutorials zum Themnnkomplex VPN Grundlagen und Installation hast du dir mal alle gründlich
durchgelesen ??
PPTP:
VPNs einrichten mit PPTP
OpenVPN:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
IPsec:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Das wäre der erste wichtige Schritt damit du wenigstesn die Basics im Hinterkopf hast !
Die entsprechenden Foren Tutorials zum Themnnkomplex VPN Grundlagen und Installation hast du dir mal alle gründlich
durchgelesen ??
PPTP:
VPNs einrichten mit PPTP
OpenVPN:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
IPsec:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Das wäre der erste wichtige Schritt damit du wenigstesn die Basics im Hinterkopf hast !
Danke werde mir die Links anschauen und bei Fragen nochmals melden.
Nur kurz vorab zu den Fragen:
> Wieso mit unterschiedlichen Methoden (SSTP und L2TP)?
Das ist ein Default Setting des Clients (siehe PPTP Tutorial). Wenn man nix macht und nicht dediziert das VPN Protokoll wählt
wie es sich gehört macht der Winblows Client erstmal der Reihe nach alles... Andere Clients fragen sowas sinnigerweise vorher
ab im Setup.
> auf dem NAT-Router den PPTP Port 1789 freigegeben.
Völliger Blödsinn und kann man eher deiner totalen Unkenntniss der VPN Protokolle zuschreiben. Deshalb auch der
dringende Apell an dich wenigstens das kleinen Einmaleins des VPNs zu lernen und zu recherchieren !
Jeder Netzwerker weiss das PPTP aus den Protokoll Komponenten TCP 1723 und dem GRE Protokoll (IP Nummer 47) besteht:
http://de.wikipedia.org/wiki/Point-to-Point_Tunneling_Protocol
TCP 1789 ist völlig falsch, kein VPN Protokoll nutzt diesen Port ! Mal ganz abgesehen davon ist der ofiziell keinerlei
VPN Funktion zugeordnet:
http://www.iana.org/assignments/service-names-port-numbers/service-name ...
Wie kommst du also auf so einen Unsinn ?!
> Wieso mit unterschiedlichen Methoden (SSTP und L2TP)?
Das ist ein Default Setting des Clients (siehe PPTP Tutorial). Wenn man nix macht und nicht dediziert das VPN Protokoll wählt
wie es sich gehört macht der Winblows Client erstmal der Reihe nach alles... Andere Clients fragen sowas sinnigerweise vorher
ab im Setup.
> auf dem NAT-Router den PPTP Port 1789 freigegeben.
Völliger Blödsinn und kann man eher deiner totalen Unkenntniss der VPN Protokolle zuschreiben. Deshalb auch der
dringende Apell an dich wenigstens das kleinen Einmaleins des VPNs zu lernen und zu recherchieren !
Jeder Netzwerker weiss das PPTP aus den Protokoll Komponenten TCP 1723 und dem GRE Protokoll (IP Nummer 47) besteht:
http://de.wikipedia.org/wiki/Point-to-Point_Tunneling_Protocol
TCP 1789 ist völlig falsch, kein VPN Protokoll nutzt diesen Port ! Mal ganz abgesehen davon ist der ofiziell keinerlei
VPN Funktion zugeordnet:
http://www.iana.org/assignments/service-names-port-numbers/service-name ...
Wie kommst du also auf so einen Unsinn ?!
Mein Fehler im Router ist es 1723 hatte mich halt verschrieben...
Trotzdem ist es komisch wieso verwendet der Router PPTP und der Server SSTP zwei unterschiedliche Modelle..
> Weiter kommt ja auch noch hinzu das der Router GRE ständig blockiert wenn ich Firewall deaktiviert ist.
Das liegt aber an deinem Router wenn du solch üble HW hast die nichtmal sowas supportet was jeder 20 Euro Baumarkt Router
kann !
Vermutlich liegt das aber nur schlicht und einfach daran das du für PPTP den falschen Port benutzt hast. Wenn du TCP 1723
einträgst forwarden intelligente Router das GRE Protokoll gleich mit.
Bei anderen wie der FritzBox (siehe Screenshot im o.a. PPTP Tutorial !) musst du das GRE Protokoll noch zusätzlich eintragen
damit es klappt !
Das liegt aber an deinem Router wenn du solch üble HW hast die nichtmal sowas supportet was jeder 20 Euro Baumarkt Router
kann !
Vermutlich liegt das aber nur schlicht und einfach daran das du für PPTP den falschen Port benutzt hast. Wenn du TCP 1723
einträgst forwarden intelligente Router das GRE Protokoll gleich mit.
Bei anderen wie der FritzBox (siehe Screenshot im o.a. PPTP Tutorial !) musst du das GRE Protokoll noch zusätzlich eintragen
damit es klappt !
Ich habe keine Fritzbox. Ich habe einen ZyXEL-Router.
Trotzdem ist es komisch wieso verwendet der Router PPTP und der Server SSTP zwei unterschiedliche Modelle..
Das liegt doch rein nur an DIR !!DU bestimmst doch WAS für ein VPN Protokoll du einsetzt.
Wenn du den VPN Server mit SSTP konfigurierst die Infrastruktur aber mit PPTP konfigurierst wird auch jedem Azubi im ersten Lehrjahr klar das das in die Hose gehen kann.
Das ist so als wenn du in einen Diesel KFZ Super tankst...macht auch kein normal denkender Mensch !
Wenn du also SSTP als VPN Protokoll einrichtest, dann musst du auch auf der Infrastruktur, sprich dem Router die SSTP Protokollkomponenten im Port Forwarding einrichten, logisch.
Wenn du PPTP benutzt dann passend eben PPTP mit seinen Komponenten ! So einfach ist das !
Das eine Mischung NICHT funktionieren kann sagt einem ja schon der gesunde Menschenverstand ohne das man IT Ahnung haben muss, sorry !
Ich habe keine Fritzbox. Ich habe einen ZyXEL-Router.
Das tut rein gar nix zur Sache.Zyxel ist ja nun auch ein renomierter Mittelklasse Hersteller. Da kann man davon ausgehen das all dieses simplen Standardfunktionen wie Port Forwarding und VPN Passthough fehlerlos funktionieren.
Das du natürlich deinen Zyxel Router mit der aktuellsten Firmware geflasht haben solltest, sollte ebenfalls klar sein !!
Zitat von @aqui:
> Trotzdem ist es komisch wieso verwendet der Router PPTP und der Server SSTP zwei unterschiedliche Modelle..
Das liegt doch rein nur an DIR !!
DU bestimmst doch WAS für ein VPN Protokoll du einsetzt.
Wenn du den VPN Server mit SSTP konfigurierst die Infrastruktur aber mit PPTP konfigurierst wird auch jedem Azubi im ersten
Lehrjahr klar das das in die Hose gehen kann.
Das ist so als wenn du in einen Diesel KFZ Super tankst...macht auch kein normal denkender Mensch !
> Trotzdem ist es komisch wieso verwendet der Router PPTP und der Server SSTP zwei unterschiedliche Modelle..
Das liegt doch rein nur an DIR !!
DU bestimmst doch WAS für ein VPN Protokoll du einsetzt.
Wenn du den VPN Server mit SSTP konfigurierst die Infrastruktur aber mit PPTP konfigurierst wird auch jedem Azubi im ersten
Lehrjahr klar das das in die Hose gehen kann.
Das ist so als wenn du in einen Diesel KFZ Super tankst...macht auch kein normal denkender Mensch !
Achso.
Wenn du also SSTP als VPN Protokoll einrichtest, dann musst du auch auf der Infrastruktur, sprich dem Router die SSTP
Protokollkomponenten im Port Forwarding einrichten, logisch.
Wenn du PPTP benutzt dann passend eben PPTP mit seinen Komponenten ! So einfach ist das !
Das eine Mischung NICHT funktionieren kann sagt einem ja schon der gesunde Menschenverstand ohne das man IT Ahnung haben muss,
sorry !
Von diesen Protokollen für VPN gibs ja wie Sand am Meer in deinen Tuts steht ja wieder ein anderes OPENSSL. Kann man die beliebig kombinieren? Normalerweise benutzt ja PPTP ja GRE kann ich das PPTP z.B mit einem anderen Protokoll der gleichen TCP/IP Schicht verwenden?
Wenn ich nun statt 1723 den Port für SSTP verwende (443) bekomm ich auf dem Client erneut ein Fehler Code 800 dort steht erneut das über L2TP/IPSec keine Verbindung zum VPN-Server hergestellt werden kann. Obwohl ich nun auf dem Router den Port 443 forwarded habe. Er versucht mit allen drei Methoden auch mit SSTP über jenes Protokoll welches der NAT-Router forwarded und auch der VPN-Server unterstützt trotzdem klappts nicht.
> Ich habe keine Fritzbox. Ich habe einen ZyXEL-Router.
Das tut rein gar nix zur Sache.
Zyxel ist ja nun auch ein renomierter Mittelklasse Hersteller. Da kann man davon ausgehen das all dieses simplen
Standardfunktionen wie Port Forwarding und VPN Passthough fehlerlos funktionieren.
Das du natürlich deinen Zyxel Router mit der aktuellsten Firmware geflasht haben solltest, sollte ebenfalls klar sein !!
Das tut rein gar nix zur Sache.
Zyxel ist ja nun auch ein renomierter Mittelklasse Hersteller. Da kann man davon ausgehen das all dieses simplen
Standardfunktionen wie Port Forwarding und VPN Passthough fehlerlos funktionieren.
Das du natürlich deinen Zyxel Router mit der aktuellsten Firmware geflasht haben solltest, sollte ebenfalls klar sein !!
By default, RRAS in this version of Windows supports 128 each of Internet Key Exchange version 2 (IKEv2), Layer Two Tunneling Protocol (L2TP), Point-to-Point Tunneling Protocol (PPTP), and Secure Socket Tunneling Protocol (SSTP) connections. If you enable VPN after installing RRAS, then the VPN ports are disabled and Windows only creates five of each connection type. Enable the ports and configure the number you need by following this procedure.
https://technet.microsoft.com/en-us/library/dd458965.aspx
Hier steht eigentlich alles beschrieben.
Gruß
Zitat von @michi1983:
Tunneling Protocol (L2TP), Point-to-Point Tunneling Protocol (PPTP), and Secure Socket Tunneling Protocol (SSTP) connections. If
you enable VPN after installing RRAS, then the VPN ports are disabled and Windows only creates five of each connection type.
Enable the ports and configure the number you need by following this procedure.
https://technet.microsoft.com/en-us/library/dd458965.aspx
Hier steht eigentlich alles beschrieben.
Gruß
By default, RRAS in this version of Windows supports 128 each of Internet Key Exchange version 2 (IKEv2), Layer Two
Tunneling Protocol (L2TP), Point-to-Point Tunneling Protocol (PPTP), and Secure Socket Tunneling Protocol (SSTP) connections. Ifyou enable VPN after installing RRAS, then the VPN ports are disabled and Windows only creates five of each connection type.
Enable the ports and configure the number you need by following this procedure.
https://technet.microsoft.com/en-us/library/dd458965.aspx
Hier steht eigentlich alles beschrieben.
Gruß
Danke für die Antwort ich wüsste nicht was da zu konfigurieren wäre ist doch bereits alles konfiguriert? Die Anleitung zeit ja wie ich die Ports für ein oder ausgehende Verbindungen konfiguieren kann. SSTP geht nur für eingehende.
Die Anleitung für OPEN-VPN passt ja nicht zu meinem Netzwerk da ich weder DD_WRT -Router noch eine fPSense habe.
Screenshot -> http://img9.myimg.de/screen4394f.jpg
Ich habe gelesen, dass nur PPTP ohne weitere Client-Software auskommt um eine VPN-Verbindung herzustellen. Aber wieso versucht dann der Client über diverse Protokolle wie TTPT, SSTP.... herzustellen also wird doch keine weitere Software benötigt?
Hallo osze90,
ich würde mal sagen das Du Dir einfach eine AVM Fritz!Box in der Bucht (eBay) schießt und
dann einfach mittels IPSec VPN von überall auf das gesamte Netzwerk Deiner Mutter zugreifen
kannst, das ist das einfachste und vor allem das sicherste!! Denn mit geöffneten Ports vorne am
WAN Interface kann natürlich auch jeder andere in das Netzwerk rein und an dem Server herum
spielen, klar oder? Und für Android und iPhone, ebenso wie für Windows Laptops gibt es dazu
Apps von AVM und in deutscher Sprache gehaltene gut bebilderte Anleitungen dazu.
Gruß
Dobby
ich würde mal sagen das Du Dir einfach eine AVM Fritz!Box in der Bucht (eBay) schießt und
dann einfach mittels IPSec VPN von überall auf das gesamte Netzwerk Deiner Mutter zugreifen
kannst, das ist das einfachste und vor allem das sicherste!! Denn mit geöffneten Ports vorne am
WAN Interface kann natürlich auch jeder andere in das Netzwerk rein und an dem Server herum
spielen, klar oder? Und für Android und iPhone, ebenso wie für Windows Laptops gibt es dazu
Apps von AVM und in deutscher Sprache gehaltene gut bebilderte Anleitungen dazu.
Gruß
Dobby
Zitat von @osze90:
Ich habe gelesen, dass nur PPTP ohne weitere Client-Software auskommt um eine VPN-Verbindung herzustellen. Aber wieso versucht
dann der Client über diverse Protokolle wie TTPT, SSTP.... herzustellen also wird doch keine weitere Software benötigt?
Ich habe gelesen, dass nur PPTP ohne weitere Client-Software auskommt um eine VPN-Verbindung herzustellen. Aber wieso versucht
dann der Client über diverse Protokolle wie TTPT, SSTP.... herzustellen also wird doch keine weitere Software benötigt?
Kann mir bitte jemand diese Frage beantworten?
Zitat von @108012:
Hallo osze90,
ich würde mal sagen das Du Dir einfach eine AVM Fritz!Box in der Bucht (eBay) schießt und
dann einfach mittels IPSec VPN von überall auf das gesamte Netzwerk Deiner Mutter zugreifen
kannst, das ist das einfachste und vor allem das sicherste!! Denn mit geöffneten Ports vorne am
WAN Interface kann natürlich auch jeder andere in das Netzwerk rein und an dem Server herum
spielen, klar oder? Und für Android und iPhone, ebenso wie für Windows Laptops gibt es dazu
Apps von AVM und in deutscher Sprache gehaltene gut bebilderte Anleitungen dazu.
Gruß
Dobby
Hallo osze90,
ich würde mal sagen das Du Dir einfach eine AVM Fritz!Box in der Bucht (eBay) schießt und
dann einfach mittels IPSec VPN von überall auf das gesamte Netzwerk Deiner Mutter zugreifen
kannst, das ist das einfachste und vor allem das sicherste!! Denn mit geöffneten Ports vorne am
WAN Interface kann natürlich auch jeder andere in das Netzwerk rein und an dem Server herum
spielen, klar oder? Und für Android und iPhone, ebenso wie für Windows Laptops gibt es dazu
Apps von AVM und in deutscher Sprache gehaltene gut bebilderte Anleitungen dazu.
Gruß
Dobby
Die Fritzbox hat funktionen die ich nicht benötige das ganze VOIP dazu habe ich mich an ZYXEL gewohnt und würde ungerne auf ein anderes Modell umsteigen da AVM auch hauptsächlich in Deutschland (bin Schweizer) auf dem Markt ist bevorzuge ich lieber ein anderes Modell.
Kann mir bitte jemand diese Frage beantworten?
Was SSTP betrifft, ist es ein von Microsoft eingeführter "Standard". Bei Windows basierten Clients kannst du das also mit Boardmitteln erledigen.
TTPT habe ich noch nie gehört, aber ich bin auch ein Noob was das angeht.
Gruß
Edit: TO, bitte unterlasse es private Nachrichten zu schicken NUR um eine Antwort in einem von dir erstellten Thread zu bitten.
Wir machen das hier alle für lau und in unserer Frei- bzw. Arbeitszeit. Wenn wir Zeit finden, dann antworten wir. Da finde ich es etwas unverschämt auch noch zusätzlich PMs zu schicken mit der Bitte um Antwort auf den Thread. Wenn du möchtest, dass das ganze schnell und sicher funktioniert, dann engagiere einen Dienstleister und bezahle ihn dafür. Nix für ungut, aber sowas mag ich gar nicht.
Zitat von @michi1983:
> Kann mir bitte jemand diese Frage beantworten?
Was SSTP betrifft, ist es ein von Microsoft eingeführter "Standard". Bei Windows basierten Clients kannst du das
also mit Boardmitteln erledigen.
TTPT habe ich noch nie gehört, aber ich bin auch ein Noob was das angeht.
Gruß
Edit: TO, bitte unterlasse es private Nachrichten zu schicken NUR um eine Antwort in einem von dir erstellten Thread zu bitten.
Wir machen das hier alle für lau und in unserer Frei- bzw. Arbeitszeit. Wenn wir Zeit finden, dann antworten wir. Da finde
ich es etwas unverschämt auch noch zusätzlich PMs zu schicken mit der Bitte um Antwort auf den Thread. Wenn du
möchtest, dass das ganze schnell und sicher funktioniert, dann engagiere einen Dienstleister und bezahle ihn dafür. Nix
für ungut, aber sowas mag ich gar nicht.
> Kann mir bitte jemand diese Frage beantworten?
Was SSTP betrifft, ist es ein von Microsoft eingeführter "Standard". Bei Windows basierten Clients kannst du das
also mit Boardmitteln erledigen.
TTPT habe ich noch nie gehört, aber ich bin auch ein Noob was das angeht.
Gruß
Edit: TO, bitte unterlasse es private Nachrichten zu schicken NUR um eine Antwort in einem von dir erstellten Thread zu bitten.
Wir machen das hier alle für lau und in unserer Frei- bzw. Arbeitszeit. Wenn wir Zeit finden, dann antworten wir. Da finde
ich es etwas unverschämt auch noch zusätzlich PMs zu schicken mit der Bitte um Antwort auf den Thread. Wenn du
möchtest, dass das ganze schnell und sicher funktioniert, dann engagiere einen Dienstleister und bezahle ihn dafür. Nix
für ungut, aber sowas mag ich gar nicht.
Ich meine PPTP nicht TTPT. Mein Fehler.
Man sieht nicht immer wenn hier jemand schreibt auch nicht wenn ich einen Beitrag zitiere. Deshalb habe ich dich über PM angeschrieben. Soll nicht den Eindruck erwecken dass ich dich hetzen wollte.
Ich meine PPTP nicht TTPT. Mein Fehler.
PPTP ist von so gut wie allen OSs unterstützt. Allerdings wird PPTP aus gutem Grund nicht mehr als sicher bezeichnet.Man sieht nicht immer wenn hier jemand schreibt auch nicht wenn ich einen Beitrag zitiere. Deshalb habe ich dich über PM angeschrieben. Soll nicht den Eindruck erwecken dass ich dich hetzen wollte.
Du kannst aber einstellen, dass jedesmal wenn jemand etwas in einem Thread kommentiert (an dem du beteiligt bist) du eine E-Mail erhältst.Und wenn du auf der Forumsseite bist wird dir auch ein "Counter" neben deinem Usernamen angezeigt wenn das passiert.
Also wenn ich mittels SSTP auf den VPN-Server zugreifen will bei NAT ist 433 konfiguriert erscheint auf dem Client die Fehlermeldung 0x80072746; Eine vorhandene Verbindung wurde vom Remotehost geschlossen.
Was soll das heissen wieso kann ich keine Verbindung mit dem VPN-Server herstellen? Über PPTP ging es immerhin noch wenn ich die Firewall deaktivierte.
Weiter ist mir auf dem VPN-Server aufgefallen das PPTP zugelassen ist für Eingehende wie auch Ausgehenden Datenverkehr. Bei SSTP nur Eingehender aktiviert den Ausgehende lässt sich nicht mal aktivieren über die Checkbox.
Unter Routing und RAS -> TESTSRV2 -> Ports -> dort über rechtsklick auf Ports
Was soll das heissen wieso kann ich keine Verbindung mit dem VPN-Server herstellen? Über PPTP ging es immerhin noch wenn ich die Firewall deaktivierte.
Weiter ist mir auf dem VPN-Server aufgefallen das PPTP zugelassen ist für Eingehende wie auch Ausgehenden Datenverkehr. Bei SSTP nur Eingehender aktiviert den Ausgehende lässt sich nicht mal aktivieren über die Checkbox.
Unter Routing und RAS -> TESTSRV2 -> Ports -> dort über rechtsklick auf Ports
Also wenn ich mittels SSTP auf den VPN-Server zugreifen will bei NAT ist 433 konfiguriert
Wenn das wirklich der Fall ist, hast du dem Client den geänderten Port bei der Hostadresse mitgegeben?Wie wärs wenn du mal einen Screenshot deiner Client Einstellungen hier mitpostest?
Edit: ich bin wirkich kein Windows Server Experte aber hier wäre noch ein nettes Tutorial.
Zitat von @michi1983:
> Also wenn ich mittels SSTP auf den VPN-Server zugreifen will bei NAT ist 433 konfiguriert
Wenn das wirklich der Fall ist, hast du dem Client den geänderten Port bei der Hostadresse mitgegeben?
Wie wärs wenn du mal einen Screenshot deiner Client Einstellungen hier mitpostest?
> Also wenn ich mittels SSTP auf den VPN-Server zugreifen will bei NAT ist 433 konfiguriert
Wenn das wirklich der Fall ist, hast du dem Client den geänderten Port bei der Hostadresse mitgegeben?
Wie wärs wenn du mal einen Screenshot deiner Client Einstellungen hier mitpostest?
Ich habe nur die IP-Adresse eingegeben über die der Server erreichbar ist also 83.219.XX.XX so wie ich das auch beim PPTP gemacht hatte.
Hier der Screenshot: http://img3.myimg.de/screen4fc8b.jpg
Laut Fehlermeldung liegt das Problem beim Server?
Vielleicht hilft dir die Fehlermeldung weiter:
Der SSTP-Dienst (Secure Socket Tunneling-Protokoll) konnte entweder den SHA256-Zertifikathash aus der Registrierung nicht lesen, oder die Daten sind ungültig. Der SHA256-Zertifikathash ist nur gültig, wenn er den Typ REG_BINARY aufweist und 32 Bytes lang ist. SSTP kann den Wert möglicherweise aufgrund eines anderen Systemfehlers nicht aus der Registrierung abrufen. Die detaillierte Fehlermeldung wird unten angezeigt. SSTP-Verbindungen werden auf diesem Server nicht akzeptiert. Beheben Sie das Problem, und wiederholen Sie den Vorgang.
Das System kann die angegebene Datei nicht finden.
1. Bitte keine externen Bildhoster verwenden. Man kann hier einfach Bilder einfügen, auch im Nachhinein. Einfach einen neuen "fake" Thread eröffnen, dann auf Bilder Upload klicken, das Bild hochladen und den erstellten Link kopieren und hier einfügen.
2. Wenn ich das richtig verstanden habe, muss man bei SSTP zwingend (kann auch eine Fehlinfo sein von mir, bitte um Nachsicht) einen DNS Namen verwenden und keine IP Adresse.
2. Wenn ich das richtig verstanden habe, muss man bei SSTP zwingend (kann auch eine Fehlinfo sein von mir, bitte um Nachsicht) einen DNS Namen verwenden und keine IP Adresse.
Zitat von @michi1983:
1. Bitte keine externen Bildhoster verwenden. Man kann hier einfach Bilder einfügen, auch im Nachhinein. Einfach einen neuen
"fake" Thread eröffnen, dann auf Bilder Upload klicken, das Bild hochladen und den erstellten Link kopieren und
hier einfügen.
1. Bitte keine externen Bildhoster verwenden. Man kann hier einfach Bilder einfügen, auch im Nachhinein. Einfach einen neuen
"fake" Thread eröffnen, dann auf Bilder Upload klicken, das Bild hochladen und den erstellten Link kopieren und
hier einfügen.
Hoffentlich liesst das noch jemand wo das bestätigen kann sonst muss ich halt über IPsec versuchen eine VPN-Verbindung herzustellen.
Was spricht denn dagegen? Auch L2TP/IPsec kann mittlerweile jedes OS ohne third-party-software.
Anleitungen gibts ja zu Hauf im Internet.
Zitat von @michi1983:
> Hoffentlich liesst das noch jemand wo das bestätigen kann sonst muss ich halt über IPsec versuchen eine
VPN-Verbindung herzustellen.
Was spricht denn dagegen? Auch L2TP/IPsec kann mittlerweile jedes OS ohne third-party-software.
Anleitungen gibts ja [https://technet.microsoft.com/en-us/library/ff687761%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396 zu
Hauf] im Internet.
> Hoffentlich liesst das noch jemand wo das bestätigen kann sonst muss ich halt über IPsec versuchen eine
VPN-Verbindung herzustellen.
Was spricht denn dagegen? Auch L2TP/IPsec kann mittlerweile jedes OS ohne third-party-software.
Anleitungen gibts ja [https://technet.microsoft.com/en-us/library/ff687761%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396 zu
Hauf] im Internet.
Oh man das ist doch ein SCh*** nicht mal Prbleme kein einziges vernünftiges Protokoll welches funktioniert.... Frage mich wieso nicht aqui sagte das es nur über einen DNS-Namen geht.
Oh man das ist doch ein SCh*** nicht mal Prbleme kein einziges vernünftiges Protokoll welches funktioniert.... Frage mich wieso nicht aqui sagte das es nur über einen DNS-Namen geht.
Wie gesagt, es MUSS ja nicht sein, sagte ich doch dazu. Ich habe aber 2 Tutorials gesehen wo darauf hingewiesen wurde.
Funktionieren tuen übrigens ALLE Protokolle wenn man sie korrekt einsetzt ;)
Zitat von @michi1983:
> Oh man das ist doch ein SCh*** nicht mal Prbleme kein einziges vernünftiges Protokoll welches funktioniert.... Frage
mich wieso nicht aqui sagte das es nur über einen DNS-Namen geht.
Wie gesagt, es MUSS ja nicht sein, sagte ich doch dazu. Ich habe aber 2 Tutorials gesehen wo darauf hingewiesen wurde.
Funktionieren tuen übrigens ALLE Protokolle wenn man sie korrekt einsetzt ;)
> Oh man das ist doch ein SCh*** nicht mal Prbleme kein einziges vernünftiges Protokoll welches funktioniert.... Frage
mich wieso nicht aqui sagte das es nur über einen DNS-Namen geht.
Wie gesagt, es MUSS ja nicht sein, sagte ich doch dazu. Ich habe aber 2 Tutorials gesehen wo darauf hingewiesen wurde.
Funktionieren tuen übrigens ALLE Protokolle wenn man sie korrekt einsetzt ;)
Schon klar nur überall legen Steine im Weg. Hier ein Router der was nicht unterstützt dann ein DNS-Name wo man benötigt dann ein Zertifikat wo man benötigt usw.
Nun habe ich es mit IPsec versucht auch hier ohne Erfolg:
Ports habe ich alle drei " UDP500, UDP4500 und TCP10.000" im NAT- Freigegeben. Auch auf dem VPN-Server sind genügend Ports frei.
Als Fehle auf dem Client erhalte ich 809 das heisst Remoteserver antwortet nicht möglicherweise verursacht NAT, Firewall usw. einen Fehler. Firewall ist aus. NAT sind alle drei Ports forwarded auf den VPN-Server
Kann mir jemand sagen was nun das Problem ist?
Weiter kommt bei Client unter Windows das für IKE ein Zertifikat brauche. Zudem gibt L2TP / IPsec und IKE / IPSEC welches ist den das richtige?
Ports habe ich alle drei " UDP500, UDP4500 und TCP10.000" im NAT- Freigegeben. Auch auf dem VPN-Server sind genügend Ports frei.
Als Fehle auf dem Client erhalte ich 809 das heisst Remoteserver antwortet nicht möglicherweise verursacht NAT, Firewall usw. einen Fehler. Firewall ist aus. NAT sind alle drei Ports forwarded auf den VPN-Server
Kann mir jemand sagen was nun das Problem ist?
Weiter kommt bei Client unter Windows das für IKE ein Zertifikat brauche. Zudem gibt L2TP / IPsec und IKE / IPSEC welches ist den das richtige?
Vertan und daneben gelegen!
Gruß
Dobby
Gruß
Dobby
Zitat von @108012:
> Kann mir jemand sagen was nun das Problem ist?
Protokoll ESP 50 nicht TCP/UDP Port 50, sondern ESP Protokoll Nr. 50
muss wohl für IPSec auch noch freigegeben werden, oder?
Gruß
Dobby
> Kann mir jemand sagen was nun das Problem ist?
Protokoll ESP 50 nicht TCP/UDP Port 50, sondern ESP Protokoll Nr. 50
muss wohl für IPSec auch noch freigegeben werden, oder?
Gruß
Dobby
Versteh ich nicht wie kommst du noch auf Port 50 in der Anleitung IPSEC Protokoll - Einsatz, Aufbau, benötigte Ports und Begriffserläuterungen steht davon nichts.
IPSEc hat doch Port UDP4500?
Ports habe ich alle drei " UDP500, UDP4500 und TCP10.000" im NAT- Freigegeben. Auch auf dem VPN-Server sind genügend Ports frei.
Für eine L2TP/IPsec Verbindung benötigst du UDP 500, UDP 4500 und UDP 1701, zudem noch ESP 50Versteh ich nicht wie kommst du noch auf Port 50 in der Anleitung IPSEC Protokoll - Einsatz, Aufbau, benötigte Ports und Begriffserläuterungen steht davon nichts.
Aus deiner Anleitung:ESP (Encapsulating Security Payload). (Protokoll-Type 50 auf Layer 3), welches verschlüsselt Daten zwischen zwei VPN Partnern überträgt. ESP hat mit NAT keine Probleme - mit PAT allerdings schon. ESP ist das Transportmedium, das letztendlich die Daten zwischen den VPN Partnern transportiert, basierend auf den in IKE Phase2 ausgehandelten Verschlüsselungs- und Hashparametern. Die aus der IKE Phase2-Aushandlung resultierenden SAs werden im SPI (Security Parameter Index) in jedem ESP Paket mitgesendet.
ESP ist das IP Protokoll Nummer 50 ! Es hat nichts mit den TCP Ports 50 zu tun, da es ein eigenständiges portloses IP Protokoll ist.
Daher kam vermutlich die Verwirrung mit Port 50, der natürlich Unsinn ist in diesem Zusammenhang.
Daher kam vermutlich die Verwirrung mit Port 50, der natürlich Unsinn ist in diesem Zusammenhang.
Zitat von @michi1983:
> Ports habe ich alle drei " UDP500, UDP4500 und TCP10.000" im NAT- Freigegeben. Auch auf dem VPN-Server sind
genügend Ports frei.
Für eine L2TP/IPsec Verbindung benötigst du UDP 500, UDP 4500 und UDP 1701, zudem noch ESP 50
> Versteh ich nicht wie kommst du noch auf Port 50 in der Anleitung
> Ports habe ich alle drei " UDP500, UDP4500 und TCP10.000" im NAT- Freigegeben. Auch auf dem VPN-Server sind
genügend Ports frei.
Für eine L2TP/IPsec Verbindung benötigst du UDP 500, UDP 4500 und UDP 1701, zudem noch ESP 50
> Versteh ich nicht wie kommst du noch auf Port 50 in der Anleitung
Soviele Ports zu öffnen... Meine NAT-Tabelle ist voll dann scheidet dieses Variante auch aus. Eigentlich wollte ich ja IPSec benutzen und zwar nicht via L2TP. IPSec mit ESP und IKE dort muss ich doch nur die von mir oben genannten Ports öffnen?
IPSEC Protokoll - Einsatz, Aufbau, benötigte Ports und Begriffserläuterungen ... steht davon nichts.
Aus deiner Anleitung:
ESP (Encapsulating Security Payload). (Protokoll-Type 50 auf Layer 3), welches verschlüsselt Daten zwischen zwei VPN Partnern
überträgt. ESP hat mit NAT keine Probleme - mit PAT allerdings schon. ESP ist das Transportmedium, das letztendlich die
Daten zwischen den VPN Partnern transportiert, basierend auf den in IKE Phase2 ausgehandelten Verschlüsselungs- und
Hashparametern. Die aus der IKE Phase2-Aushandlung resultierenden SAs werden im SPI (Security Parameter Index) in jedem ESP Paket
mitgesendet.
Aus deiner Anleitung:
ESP (Encapsulating Security Payload). (Protokoll-Type 50 auf Layer 3), welches verschlüsselt Daten zwischen zwei VPN Partnern
überträgt. ESP hat mit NAT keine Probleme - mit PAT allerdings schon. ESP ist das Transportmedium, das letztendlich die
Daten zwischen den VPN Partnern transportiert, basierend auf den in IKE Phase2 ausgehandelten Verschlüsselungs- und
Hashparametern. Die aus der IKE Phase2-Aushandlung resultierenden SAs werden im SPI (Security Parameter Index) in jedem ESP Paket
mitgesendet.
Versteh nicht was Protokoll-Typ 50 heissen solll...
Zitat von @aqui:
ESP ist das IP Protokoll Nummer 50 ! Es hat nichts mit den TCP Ports 50 zu tun, da es ein eigenständiges portloses IP
Protokoll ist.
Daher kam vermutlich die Verwirrung mit Port 50, der natürlich Unsinn ist in diesem Zusammenhang.
ESP ist das IP Protokoll Nummer 50 ! Es hat nichts mit den TCP Ports 50 zu tun, da es ein eigenständiges portloses IP
Protokoll ist.
Daher kam vermutlich die Verwirrung mit Port 50, der natürlich Unsinn ist in diesem Zusammenhang.
Versteh ich nun jetzt nicht michi1983 sagt ESP benutzt Port ESP 50 und du sagst es existiert kein Port für ESP? "Was meinst du mit ESP ist das IP Protokoll Nummer 50?"
Versteh nicht was Protokoll-Typ 50 heissen solll...
Protokoll Type 50 = ESPVersteh ich nun jetzt nicht michi1983 sagt ESP benutzt Port ESP 50
Nein ESP ist das Protokoll Type 50und du sagst es existiert kein Port für ESP?
"Was meinst du mit ESP ist das IP Protokoll Nummer 50?"
Das es ein Protokoll ist und kein Port."Was meinst du mit ESP ist das IP Protokoll Nummer 50?"
Gruß
Dobby
Versteh ich nun jetzt nicht michi1983 sagt ESP benutzt Port ESP 50 und du sagst es existiert kein Port für ESP?
Bitte tue uns allen den Gefallen und lese die Threads genau !!Die 50 bedeitet bei ESP Das das das IP Protokoll Nummer 50 ist !!! Es wird auch schlicht und einfach nur als ESP bezeichnet ohne die 50.
Es ist KEINE Port Angabe, da ESP wie bereits gesagt portlos ist als Protokoll !
Siehe auch hier:
http://de.wikipedia.org/wiki/IPsec#Encapsulating_Security_Payload_.28ES ...
und
http://www.networksorcery.com/enp/protocol/esp.htm
So schwer kann das doch nicht sein....?!
Zitat von @aqui:
> Versteh ich nun jetzt nicht michi1983 sagt ESP benutzt Port ESP 50 und du sagst es existiert kein Port für ESP?
Bitte tue uns allen den Gefallen und lese die Threads genau !!
Die 50 bedeitet bei ESP Das das das IP Protokoll Nummer 50 ist !!! Es wird auch schlicht und einfach nur als ESP bezeichnet
ohne die 50.
Es ist KEINE Port Angabe, da ESP wie bereits gesat portlos ist !
Siehe auch hier:
http://de.wikipedia.org/wiki/IPsec#Encapsulating_Security_Payload_.28ES ...
und
http://www.networksorcery.com/enp/protocol/esp.htm
So schwer kann das doch nicht sein....?!
> Versteh ich nun jetzt nicht michi1983 sagt ESP benutzt Port ESP 50 und du sagst es existiert kein Port für ESP?
Bitte tue uns allen den Gefallen und lese die Threads genau !!
Die 50 bedeitet bei ESP Das das das IP Protokoll Nummer 50 ist !!! Es wird auch schlicht und einfach nur als ESP bezeichnet
ohne die 50.
Es ist KEINE Port Angabe, da ESP wie bereits gesat portlos ist !
Siehe auch hier:
http://de.wikipedia.org/wiki/IPsec#Encapsulating_Security_Payload_.28ES ...
und
http://www.networksorcery.com/enp/protocol/esp.htm
So schwer kann das doch nicht sein....?!
Danke nun habe ich es verstanden.
War ja eine schwere (und mit einem Monat recht lange) Geburt.... 
Ich möchte weiter auf der schiene VPN mittels IPsec bleiben und habe mir da ein kostenloses Zertifikat von startssl.com besorgt. Taugt dieses etwas kann IPsec damit funktionieren?
Ich möchte weiter auf der schiene VPN mittels IPsec bleiben
Okund habe mir da ein kostenloses Zertifikat von startssl.com besorgt.
OkTaugt dieses etwas kann IPsec damit funktionieren?
??? Man kann sicherlich eine VPN mittels Zertifikaten absichernund auch mittels eines Radius Servers wenn man denn möchte
nur dazu braucht man kein SSL Zertifikat, das wäre dann wohl eher
der Fall wenn man SSL VPN macht!
Gruß
Dobby
Zitat von @108012:
> Taugt dieses etwas kann IPsec damit funktionieren?
??? Man kann sicherlich eine VPN mittels Zertifikaten absichern
und auch mittels eines Radius Servers wenn man denn möchte
nur dazu braucht man kein SSL Zertifikat, das wäre dann wohl eher
der Fall wenn man SSL VPN macht!
> Taugt dieses etwas kann IPsec damit funktionieren?
??? Man kann sicherlich eine VPN mittels Zertifikaten absichern
und auch mittels eines Radius Servers wenn man denn möchte
nur dazu braucht man kein SSL Zertifikat, das wäre dann wohl eher
der Fall wenn man SSL VPN macht!
Ich habe mich entschieden keine Zertifikate verwenden zu wollen ich will lieber mit einem Pre-Shared-Key arbeiten.
Nun dieser Router (https://www.digitec.ch/de/s1/product/asus-rt-ac66u-ac1300n450-router-330 ..) ist bisjetzt mein Favorit da ich damit auch einen RADIUS-Server betreiben könnte.
Nun bietet der Router IPsec an was ja schonmal gut ist. Der Router bietet allerdings IPsec Passthrough an ich habe mich informiert und es ist mal wieder nicht ganz einfach, als Laie zuverstehen was dieses zu bedeuten hat.
Soweit ist verstehe muss beim IPsec mit Passthrough wie im Artikel von Spacyfreak (IPSEC Protokoll - Einsatz, Aufbau, benötigte Ports und Begriffserläuterungen) beschrieben folgende Ports öffnen -> UDP Port 500 und UDP Port 4500 (Wenn ESP via NAT-T in UDP gekapselt wird) verstehe ich das richtig? Anderes geht es wohl nicht so dass ich nur den TCP Port 10.000 öffnen müsste damit IKE und ESP in ein TCP-Datenpaket gekapselt wird?
Infoquelle:
Bei IPsec-Passthrough wird die Port-Zuordnung (IKE) nicht verändert. Die IP-Adresse der ESP-Pakete wird dabei für einen Client umgeschrieben. Das bedeutet, die mit ESP behandelten Pakete können nur einer Verbindung und einem Client zugeordnet werden. Deshalb funktioniert IPsec-Passthrough hinter einem NAT-Router nur mit einem einzigen Client.
Weil in der Regel immer mehr als ein Client eine IPsec-Verbindung betreiben möchte, ist IPsec-Passthrough kaum noch in Gebrauch. Man setzt auf die IPsec-Erweiterung NAT-Traversal. Dabei werden die ESP-Pakete in UDP-Pakete verpackt und über den Port 4500 verschickt. Dann können NAT-Router IP-Adressen und Ports umschreiben.
ESP ist Portlos weshalb kann nur eine Verbindung hergestellt werden? Via NAT werden ja die IP-Adressen der Clients umgeschrieben. Warum sollte dann nur eine Verbindung gehalten werden können? Bei PAT werden die Ports umgeschrieben. Wie muss man den oberen Text verstehen wie funktioniert Passthrough?
Zitat von @osze90:
Ich habe mich entschieden keine Zertifikate verwenden zu wollen ich will lieber mit einem Pre-Shared-Key arbeiten.
Wenn der lang ist und nicht 12345... sollte dem nichts entgegensprechen.Ich habe mich entschieden keine Zertifikate verwenden zu wollen ich will lieber mit einem Pre-Shared-Key arbeiten.
Nun dieser Router (https://www.digitec.ch/de/s1/product/asus-rt-ac66u-ac1300n450-router-330 ..) ist bisjetzt mein Favorit
da ich damit auch einen RADIUS-Server betreiben könnte.
Nun bietet der Router IPsec an was ja schonmal gut ist. Der Router bietet allerdings IPsec Passthrough an ich habe mich informiert
und es ist mal wieder nicht ganz einfach, als Laie zuverstehen was dieses zu bedeuten hat.
Mit diesem Router kannst du nur per PPTP ein VPN aufbauen.da ich damit auch einen RADIUS-Server betreiben könnte.
Nun bietet der Router IPsec an was ja schonmal gut ist. Der Router bietet allerdings IPsec Passthrough an ich habe mich informiert
und es ist mal wieder nicht ganz einfach, als Laie zuverstehen was dieses zu bedeuten hat.
Die anderen beschriebenen VPN-Protokoll kann er durchlassen (Passthrough), zu anderen VPN-Gegenstellen.
Asus RTAC66U specifications
Zum Thema Sicherheit bei PPTP hat aqui bestimmt schon diesen Beitrag verlinkt.
Zitat von @goscho:
> Zitat von @osze90:
> Ich habe mich entschieden keine Zertifikate verwenden zu wollen ich will lieber mit einem Pre-Shared-Key arbeiten.
> Zitat von @osze90:
> Ich habe mich entschieden keine Zertifikate verwenden zu wollen ich will lieber mit einem Pre-Shared-Key arbeiten.
Höchstwahrscheinlich werde ich nicht 12345 nehmen
Wenn der lang ist und nicht 12345... sollte dem nichts entgegensprechen.
> Nun dieser Router (https://www.digitec.ch/de/s1/product/asus-rt-ac66u-ac1300n450-router-330 ..) ist bisjetzt mein
Favorit
> da ich damit auch einen RADIUS-Server betreiben könnte.
>
> Nun bietet der Router IPsec an was ja schonmal gut ist. Der Router bietet allerdings IPsec Passthrough an ich habe mich
informiert
> und es ist mal wieder nicht ganz einfach, als Laie zuverstehen was dieses zu bedeuten hat.
Mit diesem Router kannst du nur per PPTP ein VPN aufbauen.
Die anderen beschriebenen VPN-Protokoll kann er durchlassen (Passthrough), zu anderen VPN-Gegenstellen.
Asus RTAC66U specifications
Na toll klappt das auch nicht.Muss ich also einen Router kaufen der IPsec als Server Dienst anbietet? Mein alter Zyxel Router bietet VPN Passthrough an dort lassen sich im Menupunkt VPN zahlreiche Einstellungen konfigurieren wieso geht das nicht? Was brauche ich den einen VPN IPsec Server welcher den VPN Client in das Netzwerk des IPsec Server holt?> Nun dieser Router (https://www.digitec.ch/de/s1/product/asus-rt-ac66u-ac1300n450-router-330 ..) ist bisjetzt mein
Favorit
> da ich damit auch einen RADIUS-Server betreiben könnte.
>
> Nun bietet der Router IPsec an was ja schonmal gut ist. Der Router bietet allerdings IPsec Passthrough an ich habe mich
informiert
> und es ist mal wieder nicht ganz einfach, als Laie zuverstehen was dieses zu bedeuten hat.
Mit diesem Router kannst du nur per PPTP ein VPN aufbauen.
Die anderen beschriebenen VPN-Protokoll kann er durchlassen (Passthrough), zu anderen VPN-Gegenstellen.
Asus RTAC66U specifications
VPN Passthrough heisst doch nur das eine gewisse Art von IPsec über einen gewissen Protokoll unterstützt wird:
Bei IPsec-Passthrough wird die Port-Zuordnung (IKE) nicht verändert. Die IP-Adresse der ESP-Pakete wird dabei für einen Client umgeschrieben. Das bedeutet, die mit ESP behandelten Pakete können nur einer Verbindung und einem Client zugeordnet werden. Deshalb funktioniert IPsec-Passthrough hinter einem NAT-Router nur mit einem einzigen Client.
Weil in der Regel immer mehr als ein Client eine IPsec-Verbindung betreiben möchte, ist IPsec-Passthrough kaum noch in Gebrauch. Man setzt auf die IPsec-Erweiterung NAT-Traversal. Dabei werden die ESP-Pakete in UDP-Pakete verpackt und über den Port 4500 verschickt. Dann können NAT-Router IP-Adressen und Ports umschreiben.
(Quelle:http://www.elektronik-kompendium.de/sites/net/0906191.htm)
Da steht doch nicht das nur VPN-Verbindungen als Client aufgebaut werden können so wie du es sagst.
Zitat von @osze90:
> Zitat von @goscho:
>
> > Zitat von @osze90:
> > Ich habe mich entschieden keine Zertifikate verwenden zu wollen ich will lieber mit einem Pre-Shared-Key arbeiten.
Höchstwahrscheinlich werde ich nicht 12345 nehmen
> Wenn der lang ist und nicht 12345... sollte dem nichts entgegensprechen.
> > Nun dieser Router (https://www.digitec.ch/de/s1/product/asus-rt-ac66u-ac1300n450-router-330 ..) ist bisjetzt
mein
> Favorit
> > da ich damit auch einen RADIUS-Server betreiben könnte.
> >
> > Nun bietet der Router IPsec an was ja schonmal gut ist. Der Router bietet allerdings IPsec Passthrough an ich habe mich
> informiert
> > und es ist mal wieder nicht ganz einfach, als Laie zuverstehen was dieses zu bedeuten hat.
> Mit diesem Router kannst du nur per PPTP ein VPN aufbauen.
> Die anderen beschriebenen VPN-Protokoll kann er durchlassen (Passthrough), zu anderen VPN-Gegenstellen.
> Asus RTAC66U specifications
>
Na toll klappt das auch nicht. Kann ich damit nur eine IPsec Verbindung zu einem anderen Router herstellen welcher IPsec auch
anbietet so wie ich dich verstehe? Muss ich also einen Router kaufen der IPsec als Server Dienst anbietet? Mein alter Zyxel Router
bietet VPN Passthrough an dort lassen sich im Menupunkt VPN zahlreiche Einstellungen konfigurieren wieso geht das nicht? Was
brauche ich den einen VPN IPsec Server welcher den VPN Client in das Netzwerk des IPsec Server holt?
> Zum Thema Sicherheit bei PPTP hat aqui bestimmt schon
[http://www.heise.de/security/artikel/Der-Todesstoss-fuer-PPTP-1701365.html
> diesen Beitrag] verlinkt.
PPTP habe ich bereits benutzt und will weiterhin auf der Schiene von IPsec bleiben.
> Zitat von @goscho:
>
> > Zitat von @osze90:
> > Ich habe mich entschieden keine Zertifikate verwenden zu wollen ich will lieber mit einem Pre-Shared-Key arbeiten.
Höchstwahrscheinlich werde ich nicht 12345 nehmen
> Wenn der lang ist und nicht 12345... sollte dem nichts entgegensprechen.
> > Nun dieser Router (https://www.digitec.ch/de/s1/product/asus-rt-ac66u-ac1300n450-router-330 ..) ist bisjetzt
mein
> Favorit
> > da ich damit auch einen RADIUS-Server betreiben könnte.
> >
> > Nun bietet der Router IPsec an was ja schonmal gut ist. Der Router bietet allerdings IPsec Passthrough an ich habe mich
> informiert
> > und es ist mal wieder nicht ganz einfach, als Laie zuverstehen was dieses zu bedeuten hat.
> Mit diesem Router kannst du nur per PPTP ein VPN aufbauen.
> Die anderen beschriebenen VPN-Protokoll kann er durchlassen (Passthrough), zu anderen VPN-Gegenstellen.
> Asus RTAC66U specifications
>
Na toll klappt das auch nicht. Kann ich damit nur eine IPsec Verbindung zu einem anderen Router herstellen welcher IPsec auch
anbietet so wie ich dich verstehe? Muss ich also einen Router kaufen der IPsec als Server Dienst anbietet? Mein alter Zyxel Router
bietet VPN Passthrough an dort lassen sich im Menupunkt VPN zahlreiche Einstellungen konfigurieren wieso geht das nicht? Was
brauche ich den einen VPN IPsec Server welcher den VPN Client in das Netzwerk des IPsec Server holt?
> Zum Thema Sicherheit bei PPTP hat aqui bestimmt schon
[http://www.heise.de/security/artikel/Der-Todesstoss-fuer-PPTP-1701365.html
> diesen Beitrag] verlinkt.
PPTP habe ich bereits benutzt und will weiterhin auf der Schiene von IPsec bleiben.
Kauf dir eine pfSense und du hast alles was dein Herz begehrt
Zitat von @michi1983:
> Zitat von @osze90:
>
> > Zitat von @goscho:
> >
> > > Zitat von @osze90:
> > > Ich habe mich entschieden keine Zertifikate verwenden zu wollen ich will lieber mit einem Pre-Shared-Key arbeiten.
>
> Höchstwahrscheinlich werde ich nicht 12345 nehmen
> > Wenn der lang ist und nicht 12345... sollte dem nichts entgegensprechen.
> > > Nun dieser Router (https://www.digitec.ch/de/s1/product/asus-rt-ac66u-ac1300n450-router-330 ..) ist
bisjetzt
> mein
> > Favorit
> > > da ich damit auch einen RADIUS-Server betreiben könnte.
> > >
> > > Nun bietet der Router IPsec an was ja schonmal gut ist. Der Router bietet allerdings IPsec Passthrough an ich habe
mich
> > informiert
> > > und es ist mal wieder nicht ganz einfach, als Laie zuverstehen was dieses zu bedeuten hat.
> > Mit diesem Router kannst du nur per PPTP ein VPN aufbauen.
> > Die anderen beschriebenen VPN-Protokoll kann er durchlassen (Passthrough), zu anderen VPN-Gegenstellen.
> > Asus RTAC66U specifications
> >
> Na toll klappt das auch nicht. Kann ich damit nur eine IPsec Verbindung zu einem anderen Router herstellen welcher IPsec
auch
> anbietet so wie ich dich verstehe? Muss ich also einen Router kaufen der IPsec als Server Dienst anbietet? Mein alter Zyxel
Router
> bietet VPN Passthrough an dort lassen sich im Menupunkt VPN zahlreiche Einstellungen konfigurieren wieso geht das nicht? Was
> brauche ich den einen VPN IPsec Server welcher den VPN Client in das Netzwerk des IPsec Server holt?
>
> > Zum Thema Sicherheit bei PPTP hat aqui bestimmt schon
> [http://www.heise.de/security/artikel/Der-Todesstoss-fuer-PPTP-1701365.html
> > diesen Beitrag] verlinkt.
>
> PPTP habe ich bereits benutzt und will weiterhin auf der Schiene von IPsec bleiben.
Kauf dir eine pfSense und du hast alles was dein Herz begehrt
> Zitat von @osze90:
>
> > Zitat von @goscho:
> >
> > > Zitat von @osze90:
> > > Ich habe mich entschieden keine Zertifikate verwenden zu wollen ich will lieber mit einem Pre-Shared-Key arbeiten.
>
> Höchstwahrscheinlich werde ich nicht 12345 nehmen
> > Wenn der lang ist und nicht 12345... sollte dem nichts entgegensprechen.
> > > Nun dieser Router (https://www.digitec.ch/de/s1/product/asus-rt-ac66u-ac1300n450-router-330 ..) ist
bisjetzt
> mein
> > Favorit
> > > da ich damit auch einen RADIUS-Server betreiben könnte.
> > >
> > > Nun bietet der Router IPsec an was ja schonmal gut ist. Der Router bietet allerdings IPsec Passthrough an ich habe
mich
> > informiert
> > > und es ist mal wieder nicht ganz einfach, als Laie zuverstehen was dieses zu bedeuten hat.
> > Mit diesem Router kannst du nur per PPTP ein VPN aufbauen.
> > Die anderen beschriebenen VPN-Protokoll kann er durchlassen (Passthrough), zu anderen VPN-Gegenstellen.
> > Asus RTAC66U specifications
> >
> Na toll klappt das auch nicht. Kann ich damit nur eine IPsec Verbindung zu einem anderen Router herstellen welcher IPsec
auch
> anbietet so wie ich dich verstehe? Muss ich also einen Router kaufen der IPsec als Server Dienst anbietet? Mein alter Zyxel
Router
> bietet VPN Passthrough an dort lassen sich im Menupunkt VPN zahlreiche Einstellungen konfigurieren wieso geht das nicht? Was
> brauche ich den einen VPN IPsec Server welcher den VPN Client in das Netzwerk des IPsec Server holt?
>
> > Zum Thema Sicherheit bei PPTP hat aqui bestimmt schon
> [http://www.heise.de/security/artikel/Der-Todesstoss-fuer-PPTP-1701365.html
> > diesen Beitrag] verlinkt.
>
> PPTP habe ich bereits benutzt und will weiterhin auf der Schiene von IPsec bleiben.
Kauf dir eine pfSense und du hast alles was dein Herz begehrt
Dazu muss ich ja extra einen neuen Computer kaufen? Das Kostet ja 10 Mal soviel wie ein normaler Router. Zudem wüsste ich nicht wie ich einen Computer Hardwaremässig zu einem Router ausrüste. Das übersteigt meine Kompetenzen nochmals.
Wie muss ich das mit Passthough nun verstehen?
VPN Passthrough heisst doch soviel wie dass nur ein Port geöffnet ist und somit mittels NAT Traversal gearbeitet muss und keine andere Möglichkeit besteht. Z.B nur mittels Port 10.000 sodass IKE und ESP in ein TCP Datenpaket gekapselt wird.
Bei IPsec-Passthrough wird die Port-Zuordnung (IKE) nicht verändert. Die IP-Adresse der ESP-Pakete wird dabei für einen Client umgeschrieben. Das bedeutet, die mit ESP behandelten Pakete können nur einer Verbindung und einem Client zugeordnet werden. Deshalb funktioniert IPsec-Passthrough hinter einem NAT-Router nur mit einem einzigen Client.
Weil in der Regel immer mehr als ein Client eine IPsec-Verbindung betreiben möchte, ist IPsec-Passthrough kaum noch in Gebrauch. Man setzt auf die IPsec-Erweiterung NAT-Traversal. Dabei werden die ESP-Pakete in UDP-Pakete verpackt und über den Port 4500 verschickt. Dann können NAT-Router IP-Adressen und Ports umschreiben.
(Quelle:http://www.elektronik-kompendium.de/sites/net/0906191.htm)
Was benötige ich einen Router mit IPsec Server Funktion und einen IPsec Router mit Client Funktion oder wie geht ich da vor? Oder solange IPsec unterstützt wird auf dem Router kann er als Server wie auch Client agieren?
Da steht doch nicht das nur VPN-Verbindungen als Client aufgebaut werden können so wie du es sagst.
Dazu muss ich ja extra einen neuen Computer kaufen? Das Kostet ja 10 Mal soviel wie ein normaler Router.
Wie immer laienhafter Blödsinn und zeugt von Unkenntniss der Materie !Guckst du hier:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
Zitat von @aqui:
> Dazu muss ich ja extra einen neuen Computer kaufen? Das Kostet ja 10 Mal soviel wie ein normaler Router.
Wie immer laienhafter Blödsinn und zeugt von Unkenntniss der Materie !
Guckst du hier:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
> Dazu muss ich ja extra einen neuen Computer kaufen? Das Kostet ja 10 Mal soviel wie ein normaler Router.
Wie immer laienhafter Blödsinn und zeugt von Unkenntniss der Materie !
Guckst du hier:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
Habe mir die Anleitung durchgelesen.
Das Gerät sieht ja spannend aus jedoch kenne ich das überhaupt nicht wie die Leistung des WLAN sein wird.
Wie ist es wenn ich einen Router kaufe mit Unterstützung fremder Firmware. Ich bin momentan an diesem Router interessiert https://www.digitec.ch/de/s1/product/asus-rt-ac66u-ac1300n450-router-330 ... dort jedoch wird nur Passthough supportet (was das genau ist, wie es funktioniert, hoffe ich dass mir da noch irgend genauer erklärt). Soviel ich weiss geht IPSEC damit nicht. Was ist wenn ich also eine andere open Firmware auf den Router draufspiele müsste das ja gehen. Wäre wohl die beste Idee einfach einen Router zu kaufen, welcher wenn nicht VPN IPSEC supportet wird wenigstens für den Router eine open Firmware existiert mit welcher IPsec funktioniert?
Wenn das so geht wie von mir beschrieben kläre ich ab, ob femde Firmware Unterstüzt wird auf dem Router und wenn ja welche und ob dort IPsec supportet wird.
Die Frage wegen Passthrogh wurde mir noch nicht erklärt das ist das genau? Wie funktioniert es? Warum klappt ein IPsec Passthough nicht? Die einzigen Infos die ich kenne sind, dass über Passthrough nur ein Client eine Verbindung aufbauen könnte weil ESP Portlos ist und somit nicht mehrere Ports öffnen könnte mehr weiss ich nicht. Aber wenn ESP in TCP gekapselt wird funktioniert das doch wiederrum?
Das Gerät sieht ja spannend aus jedoch kenne ich das überhaupt nicht wie die Leistung des WLAN sein wird.
Das WLAN sollterst du immer mit einem externen AP oder mit einem zum reinen AP gemachten WLAN Router dort anschliessen.Das bietet eine bessere Performance als das integrierte und die zudem flexibler was die Position des WLAN APs und die Einschätzung der Leistungsfähigkeit anbetrifft !
Was die IPsec Funktionen anbetrifft trifft das zu was du oben zu alternativer Firmware sagst !
Zurück vom Urlaub, sorry
Ok!
Sollte die Default installierte Firmware kein IPsec unterstützten brauch ich eine Firmware aus offener Quelle die diese Funktion von IPsec anbietet. Und was muss diese Firmware den genau unterstützten? Da komme ich wieder zum Punkt IPsec Passthough was hat es damit auf sich, die Frage bitte ich noch zu beantworten damit ich weiterkomme.
Zitat von @aqui:
> Das Gerät sieht ja spannend aus jedoch kenne ich das überhaupt nicht wie die Leistung des WLAN sein wird.
Das WLAN sollterst du immer mit einem externen AP oder mit einem zum reinen AP gemachten WLAN Router dort anschliessen.
Das bietet eine bessere Performance als das integrierte und die zudem flexibler was die Position des WLAN APs und die
Einschätzung der Leistungsfähigkeit anbetrifft !
> Das Gerät sieht ja spannend aus jedoch kenne ich das überhaupt nicht wie die Leistung des WLAN sein wird.
Das WLAN sollterst du immer mit einem externen AP oder mit einem zum reinen AP gemachten WLAN Router dort anschliessen.
Das bietet eine bessere Performance als das integrierte und die zudem flexibler was die Position des WLAN APs und die
Einschätzung der Leistungsfähigkeit anbetrifft !
Ok!
Was die IPsec Funktionen anbetrifft trifft das zu was du oben zu alternativer Firmware sagst !
Sollte die Default installierte Firmware kein IPsec unterstützten brauch ich eine Firmware aus offener Quelle die diese Funktion von IPsec anbietet. Und was muss diese Firmware den genau unterstützten? Da komme ich wieder zum Punkt IPsec Passthough was hat es damit auf sich, die Frage bitte ich noch zu beantworten damit ich weiterkomme.
Zitat von @osze90:
Da komme ich wieder zum Punkt IPsec
Passthough was hat es damit auf sich, die Frage bitte ich noch zu beantworten damit ich weiterkomme.
Da komme ich wieder zum Punkt IPsec
Passthough was hat es damit auf sich, die Frage bitte ich noch zu beantworten damit ich weiterkomme.
Also wenn ich ipsec passthrough richtig verstehe, ist es ein veraltetes Protokoll (heute von NAT Traversal abgelöst).
ipsec passthrough ermöglicht es dir eine VPN Verbindung zu exakt einem Client aufzubauen, da die Port Zuordnung nicht geändert werden kann.
Gruß
Sollte die Default installierte Firmware kein IPsec unterstützten brauch ich eine Firmware aus offener Quelle die diese Funktion von IPsec anbietet.
Na ja wenn man einen VPN Router beschafft sollte die default Firmware das logischerweise auch supporten !Hier empfiehlt sich allerdings IMMER der Blick in Kleingedruckte !!! Viele Hersteller supporten lediglich nur ein einziges VPN Protokoll.
Wenn du dann einen Router beschaffst der einzig nur PPTP kann bist du gekniffen.
Fazit: Achte darauf das im VPN Protokollsupport "IPsec" im Datenblatt steht ! Mehr ist nicht zu machen.
Die pfSense supportet natürlich von sich aus schon IPsec vollständig. Wie auch diverse andere VPN Protokolle wie SSL und PPTP.
Passthrough ist KEIN aktiver VPN Support ! Auch hier Vorsicht was in der Werbund steht.
Das bedeutet lediglich das der Router IPsec Packet nicht blockt sondern einfach nur an Clients durchreichen kann wie andere Traffic auch.
Das ist KEIN VPN bzw. was man unter VPN versteht !
Zitat von @michi1983:
> Zitat von @osze90:
> Da komme ich wieder zum Punkt IPsec
> Passthough was hat es damit auf sich, die Frage bitte ich noch zu beantworten damit ich weiterkomme.
Also wenn ich ipsec passthrough richtig verstehe, ist es ein veraltetes Protokoll (heute von NAT Traversal abgelöst).
ipsec passthrough ermöglicht es dir eine VPN Verbindung zu exakt einem Client aufzubauen, da die Port Zuordnung nicht
geändert werden kann.
Gruß
> Zitat von @osze90:
> Da komme ich wieder zum Punkt IPsec
> Passthough was hat es damit auf sich, die Frage bitte ich noch zu beantworten damit ich weiterkomme.
Also wenn ich ipsec passthrough richtig verstehe, ist es ein veraltetes Protokoll (heute von NAT Traversal abgelöst).
ipsec passthrough ermöglicht es dir eine VPN Verbindung zu exakt einem Client aufzubauen, da die Port Zuordnung nicht
geändert werden kann.
Gruß
Das habe ich auch noch verstanden. Diese beiden Punkte: 1. Nur ein Client kann einen VPN Tunnel aufbauen. 2. Port Zuordnung kann nicht geändert werden.
Mein Problem ist, dass ich nicht verstehe welche Unterschiede zwischen Passthrough und NAT-Traversal bestehen. Um genauer zu sein wie diese Portnummer änderung zustande kommt wieso bei NAT-Traversal mehrere Ports verwendet werden können somit mehrere Verbindungen die zu einem VPN-Server hergestellt werden können und bei Passthough nur ein Port somit eine Verbindung die zu einem VPN-Server hergestellt werden kann. Die Unterschiede zwischen NAT und PAT verstehe ich auch nicht ganz. NAT = Schreibt einen IP um z.B 83.123.123.123 zu 192.168.0.10 und PAT von Port 80 zu 8080 ist alles was ich weiss.
Diesen Text da meine ich dieser Verstehe ich nicht.
Bei IPsec-Passthrough wird die Port-Zuordnung (IKE) nicht verändert. Die IP-Adresse der ESP-Pakete wird dabei für einen Client umgeschrieben. Das bedeutet, die mit ESP behandelten Pakete können nur einer Verbindung und einem Client zugeordnet werden. Deshalb funktioniert IPsec-Passthrough hinter einem NAT-Router nur mit einem einzigen Client.
Weil in der Regel immer mehr als ein Client eine IPsec-Verbindung betreiben möchte, ist IPsec-Passthrough kaum noch in Gebrauch. Man setzt auf die IPsec-Erweiterung NAT-Traversal. Dabei werden die ESP-Pakete in UDP-Pakete verpackt und über den Port 4500 verschickt. Dann können NAT-Router IP-Adressen und Ports umschreiben.
(Quelle:http://www.elektronik-kompendium.de/sites/net/0906191.htm)
Portzuordnungen hat doch nichts mit IKE und Passthough zu tun. Portnummer werden doch immer mit PAT verwaltet. In einem Datagramm ist doch eine Portnummer und diese wird von PAT dann umgeschrieben von 80 zu 81. Wenn ich z.B einen Webserver habe der unter dem Port 80 und läuft und nun ein zweiter Webserver benutzten will muss ich diesen so patten, dass er auf 81 umgeschrieben wird.
Kann es auch sein, dass es technisch möglich ist bei IKE eine Port-Zuordnung zu veranlassen sodass mit Passthough doch mehrere Verbindungen hergestellt werden können? Also das es einfach so als standard gesetzt wurde? Existiert somit im IKE Protokoll kein Eintrag in welchem eine Portnummer zulässt?
Zitat von @aqui:
Na ja wenn man einen VPN Router beschafft sollte die default Firmware das logischerweise auch supporten !
Hier empfiehlt sich allerdings IMMER der Blick in Kleingedruckte !!! Viele Hersteller supporten lediglich nur ein einziges VPN
Protokoll.
Na ja wenn man einen VPN Router beschafft sollte die default Firmware das logischerweise auch supporten !
Hier empfiehlt sich allerdings IMMER der Blick in Kleingedruckte !!! Viele Hersteller supporten lediglich nur ein einziges VPN
Protokoll.
Gut zu wissen.
Fazit: Achte darauf das im VPN Protokollsupport "IPsec" im Datenblatt steht ! Mehr ist nicht zu machen.
Passthrough ist KEIN aktiver VPN Support ! Auch hier Vorsicht was in der Werbund steht.
Das bedeutet lediglich das der Router IPsec Packet nicht blockt sondern einfach nur an Clients durchreichen kann wie andere
Traffic auch.
Passthrough ist KEIN aktiver VPN Support ! Auch hier Vorsicht was in der Werbund steht.
Das bedeutet lediglich das der Router IPsec Packet nicht blockt sondern einfach nur an Clients durchreichen kann wie andere
Traffic auch.
Also durchreichen im Sinn von nur einem Client? Mehrere Verbindungen sind ja soviel ich weiss nicht möglich. Kannst du bitte noch Stellung zum oberen Beitrag nehmen, möchte gerne noch etwas mehr über die Funktionsweise von Passthough erfahren. Danke.
Mehrere Verbindungen sind ja soviel ich weiss nicht möglich.
Falsch ! Bessere Router können auch ein sauberes Session Handling bei multiplen IPsec oder PPTP Clients mit Passthrough. Die Grenezn sind da aber fliessen.Durchreiben meint das der Router kein VPN Router ist der aktiv am VPN teilnimmt also z.B. VPN Server ist in der regel.
Passthrough bedeutet nur das dieses System IPsec wie ganz normalen IP Traffic routet.
IPsec nutzt mit ESP und Protokollnummer 50 ein eigenständiges IP Protokoll was einige Billigrouter einfach ignorieren also wegschmeissen und nicht weiterleiten.
Das soll Passthrough ausdrücken.
Hier erfährst du z.B. mehr:
http://www.tp-link.us/FAQ-558.html
Kopplung von 2 Routern am DSL Port
Googel einfach nach "VPN Passthrough"
Zitat von @aqui:
> Mehrere Verbindungen sind ja soviel ich weiss nicht möglich.
Falsch ! Bessere Router können auch ein sauberes Session Handling bei multiplen IPsec oder PPTP Clients mit Passthrough.
> Mehrere Verbindungen sind ja soviel ich weiss nicht möglich.
Falsch ! Bessere Router können auch ein sauberes Session Handling bei multiplen IPsec oder PPTP Clients mit Passthrough.
Ok ist mir neu.
Durchreiben meint das der Router kein VPN Router ist der aktiv am VPN teilnimmt also z.B. VPN Server ist in der regel.
Wenn ich dich richtig verstehe heisst das also es gibt spezielle Router die mit VPN umgehen können und normale Router die halt nur Daten durchreichen können? Finde ich etwas irritierend was nun die genauen Funktionen einem VPN Routers oder eines normalen Routers betrifft. Schon beim Wort "durchreichen". Was ist gemeint mit "das der Router kein VPN Router ist der aktiv am VPN teilnimmt also z.B. VPN Server ist in der regel."
Passthrough bedeutet nur das dieses System IPsec wie ganz normalen IP Traffic routet.
Mehr nicht? Kann der IPsec Passthough Router also kein richtiges IPsec machen indem man auswählen kann welches Verfahren, Methode und Algorythmus verwendet werden soll? Ist das also schon der Unterschied?IPsec nutzt mit ESP und Protokollnummer 50 ein eigenständiges IP Protokoll was einige Billigrouter einfach ignorieren also
wegschmeissen und nicht weiterleiten.
Das soll Passthrough ausdrücken.
Hier erfährst du z.B. mehr:
http://www.tp-link.us/FAQ-558.html
Kopplung von 2 Routern am DSL Port
Googel einfach nach "VPN Passthrough"
wegschmeissen und nicht weiterleiten.
Das soll Passthrough ausdrücken.
Hier erfährst du z.B. mehr:
http://www.tp-link.us/FAQ-558.html
Kopplung von 2 Routern am DSL Port
Googel einfach nach "VPN Passthrough"
Wenn ich dich nun richtig verstehe soll das Heissen, wenn Router die Funktion IPsec Passthough verwenden, lassen sie Datenverkehr von IPsec durch und wird nicht geblockt? Jedoch proffesionelle VPN Router die nicht Passthough sind sondern richtig IPsec ohne Passthough anbieten lassen sich konfigurieren? Verfahren,. Methode und welcher Algorythmus?
Ich habe doch bereits Gegoogelt verstehe nur nicht was die Funktionsweise ist da es ziemlich kompliziert geschrieben ist.
eventuell ist es so einfacher erklärt:
Nimm an, du hast einen Router mit 3 Schnittstellen.
1 davon ist das WAN, 1 ist dein LAN und am 3. hängt ein AP welcher WLAN bereitstellt.
Wenn der Router nun ein VPN Router ist ist er im Stande zu einer Gegenstelle (welche auch VPN beherrscht) einen Tunnel aufzubauen.
Des Weiteren ist er im Stande jeglichen Verkehr der über diesen VPN Tunnel reinkommt auch dementsprechend zu routen.
Das heißt:
Wenn von der Gegenstelle auf einen Netzwerkdrucker - der z.B. mittels WLAN mit dem AP an Schnittstelle 3 verbunden ist - zugegriffen werden möchte, weiß der Router genau wohin er die Pakete schicken muss.
Wenn der Router aber nur IPSEC-Passthrough unterstützt weiß er das eben nicht.
Da kann ich dem Router nur sagen, dass Pakete die auf einem gewissen Port reinkommen an eine fixe statische IP durchgereicht werden sollen und dort muss dann der Tunnel aufgebaut werden.
Ich hoffe ich erzähle jetzt keinen Blödsinn und habe es verständlich beschrieben.
Falls doch Blödsinn wird mich aqui schon wieder zurecht stutzen
Gruß
Nimm an, du hast einen Router mit 3 Schnittstellen.
1 davon ist das WAN, 1 ist dein LAN und am 3. hängt ein AP welcher WLAN bereitstellt.
Wenn der Router nun ein VPN Router ist ist er im Stande zu einer Gegenstelle (welche auch VPN beherrscht) einen Tunnel aufzubauen.
Des Weiteren ist er im Stande jeglichen Verkehr der über diesen VPN Tunnel reinkommt auch dementsprechend zu routen.
Das heißt:
Wenn von der Gegenstelle auf einen Netzwerkdrucker - der z.B. mittels WLAN mit dem AP an Schnittstelle 3 verbunden ist - zugegriffen werden möchte, weiß der Router genau wohin er die Pakete schicken muss.
Wenn der Router aber nur IPSEC-Passthrough unterstützt weiß er das eben nicht.
Da kann ich dem Router nur sagen, dass Pakete die auf einem gewissen Port reinkommen an eine fixe statische IP durchgereicht werden sollen und dort muss dann der Tunnel aufgebaut werden.
Ich hoffe ich erzähle jetzt keinen Blödsinn und habe es verständlich beschrieben.
Falls doch Blödsinn wird mich aqui schon wieder zurecht stutzen
Gruß
Ok ist mir neu.
Na ja, ist ja auch verständlich wenn dir der Horizont im Bereich professioneller Router fehlt und du nur billiges Consumer Equipemnt kennst.es gibt spezielle Router die mit VPN umgehen können und normale Router die halt nur Daten durchreichen können?
Ja so könnte man es sagen. Nur die Router die einfach nur den Traffic durchreichen sind genau genommen keine VPN Router !Als VPN Router bezeichnet man eigentlich nur solche die AKTIV am VPN Traffic teilnehmen, die also selber eins oder mehrere der diversen VPN Protokolle wie IPsec, L2TP, SSL oder PPTP sprechen und so als aktive VPN Server dienen können.
Passthrough heisst wie der Name schon sagt nur "durchlassen". Das ist ein Router mit einem Feature aber kein VPN Router !
Übrigens ist nicht jeder VPN Router ein professioneller Router.
Billige Consumer Plastik Kisten wie die FritzBox oder die Cisco RV Serie oder andere sind vollwertige VPN Router da sie ja aktiv wenigstens ein VPN protokoll sprechen.
Billige Speedports oder Vodafone Easy Boxen können das nicht sind also keine VPN Router sondern "nur" Router und das auch noch sehr schlechte weil ihnen oft auch noch die simple Passthrough Funktion fehlt und sie ESP (Teil von IPsec) deshalb nicht forwarden weil dieses Pakete im Ethernet Paket ein anderes Type Field haben als IP (0x800).
Ist aber verständlich, denn das sind Give Away Router an provider und die dürfen eben nix kosten denn man will seine Kunden nicht beschenken sondern will nur ihr Geld und das zu möglichst den geringsten Unkosten. Ökonomie funktioniert eben so !
Ich habe doch bereits Gegoogelt verstehe nur nicht was die Funktionsweise ist da es ziemlich kompliziert geschrieben ist.
Genau deshalb gibts ja Administrator.de 
1Zitat von @michi1983:
eventuell ist es so einfacher erklärt:
Nimm an, du hast einen Router mit 3 Schnittstellen.
1 davon ist das WAN, 1 ist dein LAN und am 3. hängt ein AP welcher WLAN bereitstellt.
Wenn der Router nun ein VPN Router ist ist er im Stande zu einer Gegenstelle (welche auch VPN beherrscht) einen Tunnel aufzubauen.
Des Weiteren ist er im Stande jeglichen Verkehr der über diesen VPN Tunnel reinkommt auch dementsprechend zu routen.
Das heißt:
Wenn von der Gegenstelle auf einen Netzwerkdrucker - der z.B. mittels WLAN mit dem AP an Schnittstelle 3 verbunden ist - zugegriffen werden möchte, weiß der Router genau wohin er die Pakete schicken muss.
Wenn der Router aber nur IPSEC-Passthrough unterstützt weiß er das eben nicht.
Da kann ich dem Router nur sagen, dass Pakete die auf einem gewissen Port reinkommen an eine fixe statische IP durchgereicht werden sollen und dort muss dann der Tunnel aufgebaut werden.
eventuell ist es so einfacher erklärt:
Nimm an, du hast einen Router mit 3 Schnittstellen.
1 davon ist das WAN, 1 ist dein LAN und am 3. hängt ein AP welcher WLAN bereitstellt.
Wenn der Router nun ein VPN Router ist ist er im Stande zu einer Gegenstelle (welche auch VPN beherrscht) einen Tunnel aufzubauen.
Des Weiteren ist er im Stande jeglichen Verkehr der über diesen VPN Tunnel reinkommt auch dementsprechend zu routen.
Das heißt:
Wenn von der Gegenstelle auf einen Netzwerkdrucker - der z.B. mittels WLAN mit dem AP an Schnittstelle 3 verbunden ist - zugegriffen werden möchte, weiß der Router genau wohin er die Pakete schicken muss.
Wenn der Router aber nur IPSEC-Passthrough unterstützt weiß er das eben nicht.
Da kann ich dem Router nur sagen, dass Pakete die auf einem gewissen Port reinkommen an eine fixe statische IP durchgereicht werden sollen und dort muss dann der Tunnel aufgebaut werden.
Mh... einfach ist es nicht zu verstehen was du meinst. Soviel ich verstehe ist, dass zwei VPN Router genau Routen können woher und wohin das Paket muss und ein VPN Passthough reicht es nur an den Ziel-Client für wen das Paket bestimmt ist.
Vorallem der letzte Abschnitt verstehe ich nicht fixe IP? und wo dort einen Tunnel aufgebaut werden muss? Verstehe nichts mehr in diesem Abschnitt.
Ich hoffe ich erzähle jetzt keinen Blödsinn und habe es verständlich beschrieben.
Falls doch Blödsinn wird mich aqui schon wieder zurecht stutzen
Gruß
Falls doch Blödsinn wird mich aqui schon wieder zurecht stutzen
Gruß
Zitat von @aqui:
Als VPN Router bezeichnet man eigentlich nur solche die AKTIV am VPN Traffic teilnehmen, die also selber eins oder mehrere der diversen VPN Protokolle wie IPsec, L2TP, SSL oder PPTP sprechen und so als aktive VPN Server dienen können.
Passthrough heisst wie der Name schon sagt nur "durchlassen". Das ist ein Router mit einem Feature aber kein VPN Router !
Übrigens ist nicht jeder VPN Router ein professioneller Router.
Billige Consumer Plastik Kisten wie die FritzBox oder die Cisco RV Serie oder andere sind vollwertige VPN Router da sie ja aktiv wenigstens ein VPN protokoll sprechen.
Billige Speedports oder Vodafone Easy Boxen können das nicht sind also keine VPN Router sondern "nur" Router und das auch noch sehr schlechte weil ihnen oft auch noch die simple Passthrough Funktion fehlt und sie ESP (Teil von IPsec) deshalb nicht forwarden weil dieses Pakete im Ethernet Paket ein anderes Type Field haben als IP (0x800).
Ist aber verständlich, denn das sind Give Away Router an provider und die dürfen eben nix kosten denn man will seine Kunden nicht beschenken sondern will nur ihr Geld und das zu möglichst den geringsten Unkosten. Ökonomie funktioniert eben so !
es gibt spezielle Router die mit VPN umgehen können und normale Router die halt nur Daten durchreichen können?
Ja so könnte man es sagen. Nur die Router die einfach nur den Traffic durchreichen sind genau genommen keine VPN Router !Als VPN Router bezeichnet man eigentlich nur solche die AKTIV am VPN Traffic teilnehmen, die also selber eins oder mehrere der diversen VPN Protokolle wie IPsec, L2TP, SSL oder PPTP sprechen und so als aktive VPN Server dienen können.
Passthrough heisst wie der Name schon sagt nur "durchlassen". Das ist ein Router mit einem Feature aber kein VPN Router !
Übrigens ist nicht jeder VPN Router ein professioneller Router.
Billige Consumer Plastik Kisten wie die FritzBox oder die Cisco RV Serie oder andere sind vollwertige VPN Router da sie ja aktiv wenigstens ein VPN protokoll sprechen.
Billige Speedports oder Vodafone Easy Boxen können das nicht sind also keine VPN Router sondern "nur" Router und das auch noch sehr schlechte weil ihnen oft auch noch die simple Passthrough Funktion fehlt und sie ESP (Teil von IPsec) deshalb nicht forwarden weil dieses Pakete im Ethernet Paket ein anderes Type Field haben als IP (0x800).
Ist aber verständlich, denn das sind Give Away Router an provider und die dürfen eben nix kosten denn man will seine Kunden nicht beschenken sondern will nur ihr Geld und das zu möglichst den geringsten Unkosten. Ökonomie funktioniert eben so !
Was heisst den dieses Durchreichen? Ich kann mir immer noch kein genaues Bild machen wie ein Router mit Passthough funktioniert. Dieser Passthough Router kann höchwahrscheinlich schonmal im gegensatz zu einem VPN Router keine Verschlüsselungsverfahren, Methoden oder Hashes mit welchen die Daten übertragen werden definieren und mit einem VPN Router kommunizieren?!
Wenn ich zwei VPN Router habe Netz A und Netz B. Aus dem Netz A soll der gesamte Traffic zu Netz B geroutet werden da dort die DCs und File Server sich befinden.
Wenn nun ein Client aus Netz A auf den File-Server bei Netz B zugreifen möchte wird der Router aus Netz A das Paket zu Netz B routen und von dort gelangt es zum File-Server.
Benötigt es hierfür nun einen oder zwei VPN Router? Was würde passieren wenn nun anstelle von Netz B ein normales Passthough verwende würde er den Traffic trotzdem ans Ziel also der File-Server weiterreichen? Oder wofür benötige ich im Netz B einen VPN Router?
Wenn ich nochmals überlege heisst VPN Passthough, dass nur eine Verbindung aufgebaut werden kann also wenn nun aus Netz A mehrere Anfragen kommen und alle zu Netz B geroutet werden kann ein Passthough VPN diese Verbindungen nicht aufbauen ausser alle Verbindungen sollen zum File-Server da diese den gleichen Port benutzten??? Jede Anfrage an den File-Server müsste doch auch einen anderen Port benutzten es können ja keine mehrere offene Verbindungen von verschiedenen Client existieren.
Somit brauchts meiner Meinung nach 2 VPN Router? Wozu dient den nun Pasthrough und wofür wird es benutzt? Wenn nur eine Verbindung (wenn es kein Session Handling gibt) zu einem Client geöffnet werden soll und der Router nicht mit dem VPN Router kommunizieren kann weil er in meinem Fall keine IPsec versteht?
Was heisst den dieses Durchreichen?
Das bedeutet das IP Pakete mit ESP 51 Protokollnummer wie Standard IP Pakete (IP hat Protokollnummer 80) geroutet werden. Manche Router schmeissen nicht IP Protokoll 80 Pakete manchmal schlicht und einfach weg...Macht er das, kommt keinerlei IPsec (ESP) oder z.B. PPTP (GRE) Protokollsession zustande.
Dieser Passthough Router kann höchwahrscheinlich schonmal im gegensatz zu einem VPN Router keine Verschlüsselungsverfahren, Methoden
Absolut richtig, das fehlt dem völlig !Wenn nun ein Client aus Netz A auf den File-Server bei Netz B zugreifen möchte wird der Router aus Netz A das Paket zu Netz B routen und von dort gelangt es zum File-Server.
Ja, ganz genau richtig !Aus Client Sicht ist der zwischen beiden Routern A und B aufgebaute VPN Tunnel wie eine Standleitung zu sehen die beide Netze A und B fest verbindet.
Benötigt es hierfür nun einen oder zwei VPN Router?
Na ja, das kannst du dir ja selber benatworten. Es muss ja einen geben der den Tunnel aufbaut (z.B. A) und einen der den Tunnel terminiert (z.B. B)Folglich ist also "2" die richtige Antwort wenn du 2 Lokaltionen hast. Bei 3 Lokationen sind es 3 Router bei 4 dann 4 usw.
Was würde passieren wenn nun anstelle von Netz B ein normales Passthough verwende würde
Gar nichts.... der Router an B der nur passthrough kann würde das VPN Paket versuchen zu seiner Ziel IP Adresse, sprich dem Tunnelendpunkt weiterzurouten wenn er denn Passthrough kann.Wäre er selber das Ziel schmeisst er diese Paket weg, da er mit dem VPN Protokoll selber nichts anfangen kann. Die Folge davon ist das die VPN Verbindung niemals zustande kommt....logisch !
Könnte er noch nichteinmal passthrough würde er nichtmal diese VPN Pakete weiterrouten sondern sie schlicht ignorieren und wäre damit sogar ein Filter für diesen Traffic. Dahinter käme keinerlei VPN mehr an da nicht geroutet.... Eigentlich ganz einfach
Jede Anfrage an den File-Server
Dazu kommt es logischerweise gar nicht erst. Kein VPN Tunnelendpunkt oder nicht erreichbar, kein VPN und damit kein File Server...klar !Somit brauchts meiner Meinung nach 2 VPN Router?
Bingo ! Du hast es erfasst. Oder eben einen Client mit einem VPN Client drauf der den Router connecten kann. Das wäre dann aber immer nur ein Einzelrechner.Für eine LAN zu LAN Kopplung braucht es immer 2 Router. Wie gesagt Tunneleingang und Tunnelausgang....
Wozu dient den nun Pasthrough
Wenn zwischen Internetrouter (der z.B. nur NAT mit Passthrough kann) und dem Tunnelrouter ein Router dazwischen ist, dann MUSS dieser ja die VPN Protokolle "durchreichen" (sprich passthrough) an den Tunnelrouter.Klassiker z.B. einen Routerkaskade mit einem billigen Provider Zwangsrouter der kein VPN kann der Kunde direkt dahinter aber einen VPN Router kaskadiert hat.
Dann muss der Billigrouter Passthrough über sein NAT supporten, sonst kein VPN !
Du verstehst vermutlich die "Passthrough" Logik nun, oder ?
1Zitat von @aqui:
Macht er das, kommt keinerlei IPsec (ESP) oder z.B. PPTP (GRE) Protokollsession zustande.
Was heisst den dieses Durchreichen?
Manche Router schmeissen nicht IP Protokoll 80 Pakete manchmal schlicht und einfach weg...Macht er das, kommt keinerlei IPsec (ESP) oder z.B. PPTP (GRE) Protokollsession zustande.
Also kann ein normaler Router mit Passthough zwar einge Pakete von VPN Protokollen lesen aber nicht alle? Was mich noch interessiert ist weshalb den über Passthough nur eine Verbindung mittels VPN hergestellt werden kann ausser es wird Session Handling unterstützt? Weshalb also kann nur eine Sitzung mittels Passthough aufgebaut werden?
Wenn Router Pakete wegwerfen kann keine Verbindung erfolgen, dass tönt logisch. Als ich VPN mittels PPTP machte hat mir die Firewall ständig Pakete von GRE gedrop dadurch konnte der Tunnel nicht hergestellt werden sobald die Firewall deaktiviert war ging es.
Benötigt es hierfür nun einen oder zwei VPN Router?
Na ja, das kannst du dir ja selber benatworten. Es muss ja einen geben der den Tunnel aufbaut (z.B. A) und einen der den Tunnel terminiert (z.B. B)Folglich ist also "2" die richtige Antwort wenn du 2 Lokaltionen hast. Bei 3 Lokationen sind es 3 Router bei 4 dann 4 usw.
Achsoo ok. Wie muss ich mir das den Praktisch vorstellen wie stelle ich ein, wer den Tunnel aufbauen soll und wer den Tunnel wieder terminiert? Muss ich also beim Router der den Tunnel aufbaut die WAN-IP-Adresse des Router eingeben der den Tunnel terminiert und beim Router der Terminiert die WAN-IP-Adresse des Router der den Tunnel aufbaut eingeben?
Jede Anfrage an den File-Server
Dazu kommt es logischerweise gar nicht erst. Kein VPN Tunnelendpunkt oder nicht erreichbar, kein VPN und damit kein File Server...klar !Das ist mir klar. In meiner Frage ging es vielmehr darum, weshalb bei Passthrough nur eine offene Verbindung existieren kann, ausser der Router kann Session Handling. Das hat ja irgendeinen Zusammenhang mit Ports die umgeschrieben werden aber wie das genau funktioniert verstehe ich leider nicht. Hat das mit NAT oder PAT zu tun?
Somit brauchts meiner Meinung nach 2 VPN Router?
Oder eben einen Client mit einem VPN Client drauf der den Router connecten kann. Das wäre dann aber immer nur ein Einzelrechner.Also das soll heissen ich habe einen Windows Server mit RRAS-Server dieser RRAS kann ja Routen und auch diverse VPN-Protokolle verwenden?
Wozu dient den nun Pasthrough
Wenn zwischen Internetrouter (der z.B. nur NAT mit Passthrough kann) und dem Tunnelrouter ein Router dazwischen ist, dann MUSS dieser ja die VPN Protokolle "durchreichen" (sprich passthrough) an den Tunnelrouter.Klassiker z.B. einen Routerkaskade mit einem billigen Provider Zwangsrouter der kein VPN kann der Kunde direkt dahinter aber einen VPN Router kaskadiert hat.
Dann muss der Billigrouter Passthrough über sein NAT supporten, sonst kein VPN !
Du verstehst vermutlich die "Passthrough" Logik nun, oder ?
Super verstehe nun
Also kann ein normaler Router mit Passthough zwar einge Pakete von VPN Protokollen lesen aber nicht alle?
Fast...ohne Passthrough kann er sie nicht lesen und schmeisst sie weg.weshalb den über Passthough nur eine Verbindung mittels VPN hergestellt werden kann
Das kann man pauschal nicht so sagen. Manche Router verstehen ein GRE oder ESP Session Handling und können mehrere Sessions. Die meisten Billigrouter aber nicht, die supporten nur eine. Sieht man meist daran das ein VPN Client im Netz einen Tunnel aufbauen kann andere aber nicht.Bootet man dann den Router können es wieder andere aber immer nur einer zur Zeit.
Als ich VPN mittels PPTP machte hat mir die Firewall ständig Pakete von GRE gedrop dadurch konnte der Tunnel nicht hergestellt werden
Richtig...das ist dann das was passiert.Du hättest aber die Firewall nicht deaktivieren müssen, denn das ist meist kontraproduktiv aus Sicherheitsgründen. Es hätte Gereicht GRE (Prot. 47) passieren zu lassen
Hat das mit NAT oder PAT zu tun?
Ja ! GRE und ESP hat keine Ports wie TCP und UDP deshalb ist NAT damit problembehaftet. mit RRAS-Server dieser RRAS kann ja Routen und auch diverse VPN-Protokolle verwenden?
Wenn der Router Pakete mit anderen Protokoll IDs forwarden kann dann ja ...Zitat von @aqui:
Also kann ein normaler Router mit Passthough zwar einge Pakete von VPN Protokollen lesen aber nicht alle?
Fast...ohne Passthrough kann er sie nicht lesen und schmeisst sie weg.Du hast mich wohl falsch verstanden, die Frage war nicht ob Router ohne Passthrough sondern Router mit Passthrough. Ich denke der Passthrough Router wird wohl alle VPN Protokolle weiterleiten können.
weshalb den über Passthough nur eine Verbindung mittels VPN hergestellt werden kann
Das kann man pauschal nicht so sagen. Manche Router verstehen ein GRE oder ESP Session Handling und können mehrere Sessions. Die meisten Billigrouter aber nicht, die supporten nur eine. Sieht man meist daran das ein VPN Client im Netz einen Tunnel aufbauen kann andere aber nicht.Bootet man dann den Router können es wieder andere aber immer nur einer zur Zeit.
Ich habe unter "http://www.elektronik-kompendium.de/sites/net/0906191.htm -> Passthrough" gelesen weshalb mit Passthrough nur eine Verbindung ohne Session Handling möglich ist, jedoch verstehe ich nicht genau wie das gemeint ist. Das Problem liegt daran, das NAT welches ja mit IP-Adressen arbeitet und nicht wie bei PAT (arbeitet mit Ports) nur ein Port zur Verfügung hat und so keine zweite Verbindung hergestellt werden kann; ausser man benutzt NAT-Traversal dort können auf einmal Ports umgeschrieben warum verstehe ich nun auch nicht. Vielleicht verstehst du das ja besser als ich?
Wofür dient das Session Handling wenn Passthrough nur zum Durchlassen von VPN-Verbindungen dient und nicht aktiv am VPN teilnimmt?
Hat das mit NAT oder PAT zu tun?
Ja ! GRE und ESP hat keine Ports wie TCP und UDP deshalb ist NAT damit problembehaftet.Problembehaftet weil? Der Router nicht unterscheiden kann welcher Port für welchen Client geöffnet ist? Darum ist auch nur eine Verbindung zu einem einzigen Client möglich?
Ich habe mir auf den beiden Seiten die Beispiele mal angesehen:
PAT - https://de.wikipedia.org/wiki/Port_Address_Translation
NAT - https://de.wikipedia.org/wiki/Network_Address_Translation
Wie muss ich das verstehen? Wenn ein Client eine Verbindung zum Passthrough Router herstellen will öffnet er mal irgend einen freien Port z. B 5000 sendet das Datenpaket an den Router. Der Router öffnet nun ein weiteren Port z. B 80 (HTTP) nun kann PAT den Port 80 umschreiben weil der Server von HTTP auf den Port 81 konfiguriert ist, der Server öffnet auch wieder irgendeinen Port z.B 5003 und die Verbindung ist hergestellt. Funktioniert NAT-Traversal auch so? Da wird ja ESP anschliessend in ein UDP-Datagramm gepackt und kann so auch gepattet werden.
Hat NAT und PAT überhaupt etwas zu tun mit dem erstellen einer Session sodass mehrere VPN Verbindungen hergestellt werden können bei Passthrough?
Ich denke der Passthrough Router wird wohl alle VPN Protokolle weiterleiten können.
Ja, richtig, das ist so.Wofür dient das Session Handling wenn Passthrough nur zum Durchlassen von VPN-Verbindungen dient
Du hast schon recht. Nur Passthrough kann nur eine einzige Session. Aber auch nur dann wenn der Router überhaupt GRE oder ESP Protokolle weiterleiten kann.Multiple VPN Sessions kann man nur mit intelligentem Session Handlich machen. GRE oder ESP haben keine Ports, deshalb muss der Router etwas tiefer in diese Pakete "reinsehen" um multiple Sessions zu handeln.
Das wiederum erfordert eine potente CPU. Voraussetzungen die billige Consumer Systeme oft nicht haben.
Der Router nicht unterscheiden kann welcher Port für welchen Client geöffnet ist?
Ja. Nur umso schwerer denn GRE und ESP haben keine Ports.Hat NAT und PAT überhaupt etwas zu tun mit dem erstellen einer Session
NAT nicht nur PAT. Bei NAT hast du ja eine statische Beziehung. Bei PAT nicht, da ist die Session Tabelle von Absender IP und Zielport abhängig.Zitat von @aqui:
Multiple VPN Sessions kann man nur mit intelligentem Session Handlich machen. GRE oder ESP haben keine Ports, deshalb muss der Router etwas tiefer in diese Pakete "reinsehen" um multiple Sessions zu handeln.
Also kann ein Passthrough Router keine Multiple Sessions machen, sondern nur richtige VPN Router?Wofür dient das Session Handling wenn Passthrough nur zum Durchlassen von VPN-Verbindungen dient
Du hast schon recht. Nur Passthrough kann nur eine einzige Session. Aber auch nur dann wenn der Router überhaupt GRE oder ESP Protokolle weiterleiten kann.Multiple VPN Sessions kann man nur mit intelligentem Session Handlich machen. GRE oder ESP haben keine Ports, deshalb muss der Router etwas tiefer in diese Pakete "reinsehen" um multiple Sessions zu handeln.
Ich möchte es gerne etwas genauer wissen, warum genau mehrere Verbindungen mit Passthrough nicht möglich sind. Ich habe dir einen Link im letzten Beitrag zugeschickt.
Nur verstehe ich da nicht genau den Zusammenhang von NAT und Passthrough und wie das mit diesem Ports funktioniert. Kannst du mir das bitte etwas genauer erklären? Warum über Passthrough nur eine Verbindung möglich ist. Mit NAT und PAT hat das doch nichts zu tun? Sonst könnte auf meinem Webserver ja auch nur eine Person online sein weil Port 80 besetzt ist durch den einen User der online ist.
Der Router nicht unterscheiden kann welcher Port für welchen Client geöffnet ist?
Ja. Nur umso schwerer denn GRE und ESP haben keine Ports.ESP hat mit NAT und PAT Probleme da es keine Ports gibt. ESP hat mit NAT ja nichts zu tun. NAT dient ja nur um eine IP-Adresse in eine andere zu "umzuschreiben"?
Kannst du mir PAT und NAT mal genau erklären, auch wenn wir etwas von eigentlichen Thema abdriften? Meine Frage bezieht sich auf diese Funktionsweise (siehe Screenshot). Wie muss ich mir das vorstellen wie funktioniert PAT und NAT?
Hat NAT und PAT überhaupt etwas zu tun mit dem erstellen einer Session
NAT nicht nur PAT. Bei NAT hast du ja eine statische Beziehung. Bei PAT nicht, da ist die Session Tabelle von Absender IP und Zielport abhängig.Verstehe nicht den unterschied von PAT zu NAT und was die Funktionsweise davon ist. Vielleicht kannst du das anhand meiner NAT und PAT genauer erklären. Bei Wikipedia steht das die Zuordnung der IP-Adressen und Ports in einer NAT-Tabelle gespeichert werden und diese Zuordnung PAT heisst. Nun verstehe ich gar nichts mehr sind das nicht zwei ganz unterschiedliche Sachen?
Also kann ein Passthrough Router keine Multiple Sessions machen, sondern nur richtige VPN Router?
Nein, es gibt auch gute Router die nur Passthrough können und dabei mit multiplen GRE oder ESP Sessions umgehen können. Es sind meust nur die Billigheimer die das nicht können oder billige Zwangsrouter die die Provider verschenken.Warum über Passthrough nur eine Verbindung möglich ist.
NAT bzw. PAT in den Standardroutern führt eine Session Tabelle nach Ports. GRE oder ESP sind eigene IP Protokolle die KEINE Ports haben, folglich scheitert dann eine statische Zuweisung bei mutliplen Sessions, weil der Router aufgrund der fehlenden Ports diese nicht mehr zuordnen kann.Folglich gilt bei den billigen Passthrough systemen dann First come, first serve.
Bei den besseren "sehen" diese in den Packet Header und erkennen GRE oder ESP Pakete und triggern dann einen internen Counter. Wird oft auch Application Gateway Funktion genannt.
Verstehe nicht den unterschied von PAT zu NAT und was die Funktionsweise davon ist.
Google ist dein Freund...!http://www.cisco.com/c/en/us/td/docs/security/asa/asa80/configuration/g ...
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_nat/configurati ...
usw.
Statische NAT oder Pool NAT setzt alles um egal welches Protokoll. PAT setzt multiple IPs auf eine IP um und ist voll Portabhängig. Bei Protokollen ohne Ports gibts dann die o.g. Probleme und dies scheitern dann logischerweise am NAT.
Zitat von @aqui:
Also kann ein Passthrough Router keine Multiple Sessions machen, sondern nur richtige VPN Router?
Nein, es gibt auch gute Router die nur Passthrough können und dabei mit multiplen GRE oder ESP Sessions umgehen können. Es sind meust nur die Billigheimer die das nicht können oder billige Zwangsrouter die die Provider verschenken.
Aha ok und wozu dienen den Passthrough Router die Multiple Session können. Passthrough dient ja nur zum Weiterleiten auf den Router der auch richtig VPN-Tunnels aufbauen kann. Wozu dann multiple Sessions?
Warum über Passthrough nur eine Verbindung möglich ist.
NAT bzw. PAT in den Standardroutern führt eine Session Tabelle nach Ports. GRE oder ESP sind eigene IP Protokolle die KEINE Ports haben, folglich scheitert dann eine statische Zuweisung bei mutliplen Sessions, weil der Router aufgrund der fehlenden Ports diese nicht mehr zuordnen kann.
Folglich gilt bei den billigen Passthrough systemen dann First come, first serve.
Folglich gilt bei den billigen Passthrough systemen dann First come, first serve.
Die Session Tabelle ist die jenige welche unsichbar ist? Im Router lässt sich ja eine eigene NAT-Tabelle erstellen anhand der Eingabe von IP-Adresse und Port.
Da also ESP und GRE keine Ports haben ist auch nur eine Verbindung möglich mit Passthrough? Liegts somit daran, dass ESP Portlos ist? Was ich aber nicht verstehe ist, weshalb dann überhaupt eine Verbindung hergestellt werden kann wenn es keine Ports gibt bei ESP? Wenn ESP Ports hätte, könnten es so viele Zugriffe auf einen Client geben bis die NAT-Tabelle voll ist aber wenn es gar keine Ports gibt kann es doch zu keiner Verbindung kommen?
Spielt NAT überhaupt bei einem Site-to-Site VPN eine Rolle? Ich kenne NAT nur von meinem Webserver dort habe ich die IP-Adresse und den Port vom Webserver in die NAT eingetragen somit werden ja nun alle Pakete mit Port 80 von der NAT zum Webserver geleitet. Also spielt NAT auch bei Site-to-Site VPN eine Rolle?.
Bei den besseren "sehen" diese in den Packet Header und erkennen GRE oder ESP Pakete und triggern dann einen internen Counter. Wird oft auch Application Gateway Funktion genannt.
Das heisst also, die NAT-Tabelle kann ESP Pakete unterschiedlichen Clients zuordnen und diese ESP-Pakete gezielt den Clients zukommen lassen obwohl ESP keine Ports hat.
Verstehe nicht den unterschied von PAT zu NAT und was die Funktionsweise davon ist.
Google ist dein Freund...!http://www.cisco.com/c/en/us/td/docs/security/asa/asa80/configuration/g ...
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_nat/configurati ...
usw.
Statische NAT oder Pool NAT setzt alles um egal welches Protokoll.
Habe mir bereits folgende Seiten studiert: https://de.wikipedia.org/wiki/Network_Address_Translation & https://de.wikipedia.org/wiki/Port_Address_Translation. Aber leider ist es nicht so einfach zu verstehen da das alles andere als einfach zu verstehen ist.
Statische NAT = Die NAT welche ich im Router selber einstellen kann richtig?
Zu Pool NAT konnte ich keine hilfreichen Infos finden. Was ist das?
PAT setzt multiple IPs auf eine IP um und ist voll Portabhängig. Bei Protokollen ohne Ports gibts dann die o.g. Probleme und dies scheitern dann logischerweise am NAT.
Das verstehe den ganzen Satz nicht kannst du mir das bitte nochmals etwas genauer erklären wie das gemeint ist? Das ist doch meine PAT Tabelle mit den verschiedenen Ports die man da konfigurieren kann:
Wie meinst du das mit "PAT setzt multiple IP zu IP um" LAN-IP zu WAN-IP? Also so wie bei meinem Webserver 83.123.123.12 zu 192.168.1.39?
Aha ok und wozu dienen den Passthrough Router die Multiple Session können.
Stell dir ein Büro vor wo 10 Leute sitzen die zu unterschiedlichen Lokationen VPN Tunnel von ihren Arbeitsplatz PCs aufmachen müssen.Ohne Session Handling kann das nur der der morgens der Erste ist und alle anderen gucken in die Röhre und können nicht arbeiten.
Mit Session Handling können alle 10 arbeiten....
Kommt man mit etwas Nachdenken aber auch von selber drauf, oder ?
Liegts somit daran, dass ESP Portlos ist?
Jepp, Bingo ! Du hast es erfasst !weshalb dann überhaupt eine Verbindung hergestellt werden kann wenn es keine Ports gibt bei ESP?
Der Router sieht auf den Ethertype im header und erkennt GRE oder ESP anhand der Protokollnummer. Macht ein einziges Forwarding nur für die betreffende IP und schmeisst andere weg.Multiple Passthrough Router führen aus IP und Protokoll eine eigene Liste und können so mehrere Sessions verwalten.
Spielt NAT überhaupt bei einem Site-to-Site VPN eine Rolle?
Das kommt darauf an....Wenn die Endgeräte die NAT machen auch gleichzeitig die VPN Tunnelendpunkte sind dann nicht !
Befinden sich die Tunnelendpunkte allerdings HINTER dem NAT Router dann sehr wohl, denn dann muss man mit Passthrough die VPN Protokolle zu den Endgeräten hinter dem NAT Router per Port Forwarding weiterleiten.
Letzteres ist immer die allerschlechteste Lösung. Grund ist die schlechte Performance und die Frickelei mit Port Forwarding, was auch gleichzeitig ein Durchlöchern der Firewall mit sich bringt.
Besser also immer die erste Variante.
Aber leider ist es nicht so einfach zu verstehen da das alles andere als einfach zu verstehen ist.
Mmmmhhh. Das ist wie immer ein höchst relative Aussage. Meiner Meinung nach ist das sehr einfach zu verstehen und sehr gut dargestellt. Fast sogar ein bischen zu banal...Statische NAT = Die NAT welche ich im Router selber einstellen kann richtig?
Richtig, Router oder Firewall.Zu Pool NAT konnte ich keine hilfreichen Infos finden. Was ist das?
Dort wird aus einem Pool dynmaisch eine Adresse verwendet die nach einer Zeit der nichtbenutzung wieder in den Pool zurückgeht.Die Cisco Seite hat detailierte Infos dazu. Such einfach mal nach "NAT Pool".
Das ist doch meine PAT Tabelle mit den verschiedenen Ports die man da konfigurieren kann:
Nein, bei PAT kann man nichts konfigurieren. PAT ist PAT.Was du da zeigst ist deine Port Forwarding Konfig Seite. Das hat mit PAT als solchem rein gar nichts zu tun ! Denkfehler !
Wie meinst du das mit "PAT
War vielleicht etwas konfus ausgedrückt.Pat setzt multiple IPs auf eine einzige IP um auf Basis der IP Adresse und Port.
http://www.tcp-ip-info.de/tcp_ip_und_internet/ip_masquerading.htm
https://de.wikipedia.org/wiki/Port_Address_Translation
Zitat von @aqui:
Ohne Session Handling kann das nur der der morgens der Erste ist und alle anderen gucken in die Röhre und können nicht arbeiten.
Mit Session Handling können alle 10 arbeiten....
Kommt man mit etwas Nachdenken aber auch von selber drauf, oder ?
Aha ok und wozu dienen den Passthrough Router die Multiple Session können.
Stell dir ein Büro vor wo 10 Leute sitzen die zu unterschiedlichen Lokationen VPN Tunnel von ihren Arbeitsplatz PCs aufmachen müssen.Ohne Session Handling kann das nur der der morgens der Erste ist und alle anderen gucken in die Röhre und können nicht arbeiten.
Mit Session Handling können alle 10 arbeiten....
Kommt man mit etwas Nachdenken aber auch von selber drauf, oder ?
Mh. Und das Tunnelende macht der VPN Router mit Session Handling? Soweit ich das Verstehe, müsste der Router mit Session Handling auch mit der Gegenstelle die SA's austauschen das kann ja Passthrough nicht. Wie soll das gehen? Verstehe den Sinn unter Passthrough mit Multiplen Sessions nicht.
weshalb dann überhaupt eine Verbindung hergestellt werden kann wenn es keine Ports gibt bei ESP?
Der Router sieht auf den Ethertype im header und erkennt GRE oder ESP anhand der Protokollnummer. Macht ein einziges Forwarding nur für die betreffende IP und schmeisst andere weg.Die Protokollnummer sagt also aus ob Protokoll Portlos ist und welches Protokoll es ist?
Welches Protokoll hat den einen Ethertyp? Bei TCP konnte ich den Ethertyp nicht finden. Das ESP-Paket kommt ja beim Router als TCP-Datensegement an, darin befindet sich das ESP im ESP wiederrum ein IPsec-Datenpaket in diesem das Ethernet-Frame habe ich das richtig verstanden?
Multiple Passthrough Router führen aus IP und Protokoll eine eigene Liste und können so mehrere Sessions verwalten.
Wie kommen diese verschiedenen Sessions den zustande wenns keine Ports gibt? Verstehe nicht wie Anhand von einer IP-Adresse und einem Protokoll wie ESP unterschieden werden kann vom welcher Traffic kommt und an wen wieder gehen muss.
Bei den besseren "sehen" diese in den Packet Header und erkennen GRE oder ESP Pakete und triggern dann einen internen Counter. Wird oft auch Application Gateway Funktion genannt.
Das heisst also, die NAT-Tabelle kann ESP Pakete unterschiedlichen Clients zuordnen und diese ESP-Pakete gezielt den Clients zukommen lassen obwohl ESP keine Ports hat? Wie ist das Möglich?
Zu Pool NAT konnte ich keine hilfreichen Infos finden. Was ist das?
Dort wird aus einem Pool dynmaisch eine Adresse verwendet die nach einer Zeit der nichtbenutzung wieder in den Pool zurückgeht.Die Cisco Seite hat detailierte Infos dazu. Such einfach mal nach "NAT Pool".
Was bringt den NAT POOL?
Leider nur in Englisch, die Google Übersetzung taugt da wenig. Darf ich dich bitten kurz Zusammenzufassen was es ist? Vielen Dank.
Das ist doch meine PAT Tabelle mit den verschiedenen Ports die man da konfigurieren kann:
Nein, bei PAT kann man nichts konfigurieren. PAT ist PAT.Was du da zeigst ist deine Port Forwarding Konfig Seite. Das hat mit PAT als solchem rein gar nichts zu tun ! Denkfehler !
Und was ist den Port Forwarding? Was mache ich dort? Etwas mit Ports wie weitergeleitet werden? PAT = Port Adressen Übersetzung?
Wie meinst du das mit "PAT
War vielleicht etwas konfus ausgedrückt.Pat setzt multiple IPs auf eine einzige IP um auf Basis der IP Adresse und Port.
Also 192.168.1.2:80 zu 83.123.123.123:80 oder 192.168.1.3.81 zu 83.123.123.123:81? Wenn ja basiert also PAT auf den Einstellung in meiner Statischen NAT-Tabelle?
http://www.tcp-ip-info.de/tcp_ip_und_internet/ip_masquerading.htm
https://de.wikipedia.org/wiki/Port_Address_Translation
https://de.wikipedia.org/wiki/Port_Address_Translation
tcp-ip-info.de ist sehr verständlich. Also liege ich wohl doch nicht so falsch. NAT = IP-Adressen basiertes übersetzten und PAT = Port basiert. Mein Router ist also ein PAT-Router den ich über NAT konfiguriert habe. NAT-Router sind wohl nur für den Firmen Einsatz gedacht, da man mehrere öffentliche IP-Adresse haben muss was als private Person kaum möglich ist.
So gut wie jeder Router macht NAT
Wie soll das gehen? Verstehe den Sinn unter Passthrough mit Multiplen Sessions nicht.
Wie bereits mehrfach gesagt kann Passthrouh KEIN VPN Terminieren, kann also NICHT aktiv einen Tunnel aufbauen usw. sprich also eine komplette VPN Session behanden wie ein VPN Server. Ein VPN Router ist ja quasi ein Router mit eingebautem VPN Server.Ein Passthrough Router kann sowas alles nicht. Er kann die VPN Pakete nur routen wie ein einfacher Router.
Gesetzt also du hast den Fall und hast einen solchen Billigrouter im Einsatz im Büro.
Dort soll Lieschen Müller remote per VPN etwas in SAP erfassen, Oma Grete sieht sich per VPN Bilder auf dem NAS des Enkels an und der Cheffe zieht sich via VPN ein Video von seinem NAS zuhause rein.
Der Passthrough Router kann nur eine Session handeln....
Oma Grete ist die Erste im Büro morgens, macht das VPN zum Enkel auf, der Passthrough Router hat seine Passthrough Session belegt und blockiert alle weiteren weil er ja nicht mehr kann.
Lieschen Müller dreht jetzt Däumchen und der Cheffe ruft wütend bei der IT an und verpasst dem Netzwerk Admin einen Einlauf weil nix geht bei ihm.
Du verstehst nun hoffentlich warum es sinnvoll sein kann multiple Sessions im Passthrough handeln zu können und wo der Nachteil von Billigroutern ist die nur eine einzige können ?!
Ist ja ne schwere Geburt mit dir....
Die Protokollnummer sagt also aus ob Protokoll Portlos ist und welches Protokoll es ist?
Nein, das tut sich nicht. Sie sagt lediglich was für ein Protokoll es ist nicht aber wie das strukturiert ist. Das beschreibt dann wie immer der zugehörige RFC zum Protokoll. Die Spezifikationen sind unterschiedlich.Bei einem Autokennzeichen kannst du auch nicht direkt erkennen ob die Stadt am Wasser liegt oder nicht.
Bei TCP konnte ich den Ethertyp nicht finden.
Ist auch logisch. Gehört zur IPv4 Famile mit dem Type 0x800Wie kommen diese verschiedenen Sessions den zustande wenns keine Ports gibt?
Lieschen Müller, Oma Grete, der Cheffe....das sind schon 3 Sessions und so kommen sie zustande.... Für den Router ja 3 mal ESP oder GRE Sessions, je nach VPN Protokoll.wie Anhand von einer IP-Adresse und einem Protokoll wie ESP unterschieden werden kann vom welcher Traffic kommt und an wen wieder gehen muss.
Genau DAS ist oben erklärt. Bessere Router "sehen" in höhere Layer (OSI) solcher Pakete und erkennen das.Das heisst also, die NAT-Tabelle kann ESP Pakete unterschiedlichen Clients zuordnen
Nein, das heist es nicht genrell. Hier muss man nun sehr fein zwischen NAT und PAT unterscheiden.Ja, lautet die Antwort für PAT, denn das ist Port basierend und ohne Ports funktioniert das nicht. Bei statischem NAT ist das anders. Da zahlt nur die IP mehr nicht. Deshalb funktioniert ESP und GRE mit statischem NAT fehlerfrei.
Was bringt den NAT POOL?
Das du quasi wie mit 1:1 NAT arbeiten kannst mit einem Verhalten wie PAT aber kein PAT machst. Das hat Riesenvorteile für große statische NAT Szenarien mit begrenztem IP Adress Space. Ein Aspekt zum Beispiel...es gibt zig mehr würde aber hier den Rahmen sprengen.Und was ist den Port Forwarding? Was mache ich dort? Etwas mit Ports wie weitergeleitet werden?
Ja, das bezieht sich nur auf PAT. Sofern ein Paket von außen kommt was keinen gültigen Eintrag in der PAT Sessiontabelle hat wird dieses gedropt (weggeschmissen). Fazit: Man kommt von außen nicht durch eine NAT Firewall.Viele Protokolle nutzen dynmaische Ports wie PPTP, SIP, RTP usw. die scheitern ohne STUN an NAT oder genauer gesagt PAT.
Beispiel GRE mit PPTP VPN. Der Client öffnet outbound die PPTP Session über TCP 1723 und der PPTP VPN Server antwortet mit einer GRE Session. Zu dieser gibt es keinen PAT Session Eintrag, der GRE Tunnel scheitert also am NAT / PAT...Ergebnis: Kein VPN.
Mit Port Forwarding für GRE kommt er aber durch... Gleichzeitig hat man aber ein Loch in der Firewall.
Wenn ja basiert also PAT auf den Einstellung in meiner Statischen NAT-Tabelle?
Oha...nein ! Hier musst du unterscheiden zwischen PAT und NAT...das sind 2 unterschieldiche Baustellen. Satisches NAT arbeitet NICHT mit Ports wie PAT !Also liege ich wohl doch nicht so falsch. NAT = IP-Adressen basiertes übersetzten und PAT = Port basiert.
Jepp...genau richtig !Mein Router ist also ein PAT-Router
Ja, das sind 99% aller billigen Consumer DSL, Kabel, Sat und LTE Router. Die nutzen immer PAT und niemals bis sehr selten statisches NAT. Das gibts meistens nur im Business und Provider Bereich.den ich über NAT konfiguriert habe
Nein, das sicher nicht. Das könne die meisten Billigrouter gar nicht.NAT-Router sind wohl nur für den Firmen Einsatz gedacht, da man mehrere öffentliche IP-Adresse haben muss was als private Person kaum möglich ist.
So könnte man es sagen... Es git aber noch zig andere Einsatzmöglichkeiten.Denk an den dummen Admin der 2 Lokationen hat mit den gleichen dümmlichen 192.168.1.0 /24 IP Netzen die er im Rahmen einer Fusion per VPN zusammenbringen muss.
Ohne eine IP Adress änderung kann er das nur mit statischem oder Pool NAT realisieren....
Die Liste der Anwendung liesse sich belibig fortführen...
@michi1983
Man muss aber fairerweise schon zw. NAT und PAT dann unterscheiden. Ja...PAT können 99% der billigen Consumer Router aber static NAT oder NAT Pooling nur Business Router oder etwas professionellere Systeme wie der Mikrotik z.B.
Wie bereits mehrfach gesagt kann Passthrouh KEIN VPN Terminieren, kann also NICHT aktiv einen Tunnel aufbauen usw. sprich also eine komplette VPN Session behanden wie ein VPN Server. Ein VPN Router ist ja quasi ein Router mit eingebautem VPN Server.
Ein Passthrough Router kann sowas alles nicht. Er kann die VPN Pakete nur routen wie ein einfacher Router.
Gesetzt also du hast den Fall und hast einen solchen Billigrouter im Einsatz im Büro.
Dort soll Lieschen Müller remote per VPN etwas in SAP erfassen, Oma Grete sieht sich per VPN Bilder auf dem NAS des Enkels an und der Cheffe zieht sich via VPN ein Video von seinem NAS zuhause rein.
Der Passthrough Router kann nur eine Session handeln....
Oma Grete ist die Erste im Büro morgens, macht das VPN zum Enkel auf, der Passthrough Router hat seine Passthrough Session belegt und blockiert alle weiteren weil er ja nicht mehr kann.
Lieschen Müller dreht jetzt Däumchen und der Cheffe ruft wütend bei der IT an und verpasst dem Netzwerk Admin einen Einlauf weil nix geht bei ihm.
Du verstehst nun hoffentlich warum es sinnvoll sein kann multiple Sessions im Passthrough handeln zu können und wo der Nachteil von Billigroutern ist die nur eine einzige können ?!
Ist ja ne schwere Geburt mit dir....
Ein Passthrough Router kann sowas alles nicht. Er kann die VPN Pakete nur routen wie ein einfacher Router.
Gesetzt also du hast den Fall und hast einen solchen Billigrouter im Einsatz im Büro.
Dort soll Lieschen Müller remote per VPN etwas in SAP erfassen, Oma Grete sieht sich per VPN Bilder auf dem NAS des Enkels an und der Cheffe zieht sich via VPN ein Video von seinem NAS zuhause rein.
Der Passthrough Router kann nur eine Session handeln....
Oma Grete ist die Erste im Büro morgens, macht das VPN zum Enkel auf, der Passthrough Router hat seine Passthrough Session belegt und blockiert alle weiteren weil er ja nicht mehr kann.
Lieschen Müller dreht jetzt Däumchen und der Cheffe ruft wütend bei der IT an und verpasst dem Netzwerk Admin einen Einlauf weil nix geht bei ihm.
Du verstehst nun hoffentlich warum es sinnvoll sein kann multiple Sessions im Passthrough handeln zu können und wo der Nachteil von Billigroutern ist die nur eine einzige können ?!
Ist ja ne schwere Geburt mit dir....
Den Unterschied verstehe ich schon aber nicht wie der Einsatzort dafür ist. Ein richtiger VPN Router sollte / muss doch auch mehrere Sessions können, wie sonst sollen wie in deinem Beispiel erklärt, mehrere Verbindung geöffnet werden oder?
Wozu sollte man den einen Passthrough Router kaufen, der mehreren Sessions aufbauen kann, wenn es richtige VPN-Router gibt? Ganz am Anfang von Thema war ja die Rede, dass Passthrough nur für Router Kaskaden ist und so als Weiterleitung dienen soll. Wozu dann Passthrough mit multiplen Sessions?
Verstehen tu ich nicht, wenn benötige ich den einen Passthrough Router der mehrere Sessions kann und wenn einen richtigen VPN Router? In deinem Beispiel reicht doch ein einziger richtiger VPN Router? Wenn würde in deinem Beispiel ein Router mit Passthrough der multiplen Sessions kann zum Einsatz kommen? Müsste da ein 1 Session Passthrough Router sein der den VPN Traffic zum Passthrough Router mit multiplen Sessions weiterleitet am Router mit den multiplen Session hängt wiederrum das Tunnelende mit dem richtigen VPN Router?
Wie kommen diese verschiedenen Sessions den zustande wenns keine Ports gibt?
Lieschen Müller, Oma Grete, der Cheffe....das sind schon 3 Sessions und so kommen sie zustande.... Für den Router ja 3 mal ESP oder GRE Sessions, je nach VPN Protokoll.Du hast gesagt Passthrough Router führen eine eigene Tabelle mit der Zuordnung von IP-Adresse und Protokoll. Also z. B 192.168.1.10 und Protokollnummer 50 für (ESP). Wie soll das funktionieren? Wenn mehrere verbinden zu 192.168.1.10 mit ESP-Protokoll hergestellt werden kann ja nicht mehr unterschieden werden von welchem Client das Paket kam? Wie muss ich mir die Funktionsweise davon vorstellen?
wie Anhand von einer IP-Adresse und einem Protokoll wie ESP unterschieden werden kann vom welcher Traffic kommt und an wen wieder gehen muss.
Genau DAS ist oben erklärt. Bessere Router "sehen" in höhere Layer (OSI) solcher Pakete und erkennen das.Aber das ist doch nur dann der Fall wenn ein Protokoll einen Port hat wie z. B HTTP, dann kann erkennt werden welcher Server gemeint ist. Ich habe einen Server am Laufen auf Port 80 und einen zweiten NAS-Server der über den Port 81 erreichbar ist. Das hat ja mit einem Portlosen Protokoll wie ESP keine Gemeinsamkeiten?
Das heisst also, die NAT-Tabelle kann ESP Pakete unterschiedlichen Clients zuordnen
Nein, das heist es nicht genrell. Hier muss man nun sehr fein zwischen NAT und PAT unterscheiden.Ja, lautet die Antwort für PAT, denn das ist Port basierend und ohne Ports funktioniert das nicht. Bei statischem NAT ist das anders. Da zahlt nur die IP mehr nicht. Deshalb funktioniert ESP und GRE mit statischem NAT fehlerfrei.
Du meinst wohl eher Nein, lautet die Antwort für PAT? Ja für NAT.
Was bringt den NAT POOL?
Das du quasi wie mit 1:1 NAT arbeiten kannst mit einem Verhalten wie PAT aber kein PAT machst. Das hat Riesenvorteile für große statische NAT Szenarien mit begrenztem IP Adress Space. Ein Aspekt zum Beispiel...es gibt zig mehr würde aber hier den Rahmen sprengen.Wie kompliziert. Also die NAT Pool ist also ein NAT Router der auch gleichzeitig PAT kann?
Und was ist den Port Forwarding? Was mache ich dort? Etwas mit Ports wie weitergeleitet werden?
Ja, das bezieht sich nur auf PAT. Sofern ein Paket von außen kommt was keinen gültigen Eintrag in der PAT Sessiontabelle hat wird dieses gedropt (weggeschmissen). Fazit: Man kommt von außen nicht durch eine NAT Firewall.Viele Protokolle nutzen dynmaische Ports wie PPTP, SIP, RTP usw. die scheitern ohne STUN an NAT oder genauer gesagt PAT.
Beispiel GRE mit PPTP VPN. Der Client öffnet outbound die PPTP Session über TCP 1723 und der PPTP VPN Server antwortet mit einer GRE Session. Zu dieser gibt es keinen PAT Session Eintrag, der GRE Tunnel scheitert also am NAT / PAT...Ergebnis: Kein VPN.
Mit Port Forwarding für GRE kommt er aber durch... Gleichzeitig hat man aber ein Loch in der Firewall.
PPTP scheitert an PAT weil in der PAT-Sessiontabelle ein anderer Port steht, dass weil PPTP dynamische Ports nutzt und somit bei jeder Verbindung einen anderen Port hat? Warum nutzt PPTP jedesmal einen anderen Port? Damit mehrere Verbindungen hergestellt werden können zum VPN, richtig?
Was hat STUN und NAT mit Port Fordwarding für ein Problem? Die NAT interessiert sich doch nicht für dynamische Ports?
Mein erster VPN versuch war mit PPTP dort hat wie du sagst mein Router alle GRE gedropt, ich musste jedesmal die Firewall deaktivieren, dass ein Tunnel zustande kam. Mit Port Forwarding kann ich das also umgehen und die Firewall aktiviert lassen. Wie konfiguriere ich das? In der Port Forwarding Tabelle muss ich irgend eingehende Ports und auslösende Ports eingeben.
Wenn ja basiert also PAT auf den Einstellung in meiner Statischen NAT-Tabelle?
Oha...nein ! Hier musst du unterscheiden zwischen PAT und NAT...das sind 2 unterschieldiche Baustellen. Satisches NAT arbeitet NICHT mit Ports wie PAT !Gibt also PAT-Sessiontabellen die statische sind und dynamische? Genauso wie bei NAT?
Wozu dann Passthrough mit multiplen Sessions?
Das wird Dir erst klar wenn man hinter dem ersten Router keinen zweiten Routersondern einen VPN Server stehen hat und mehrere Sessions aufgebaut werden
müssen!
Gruß
Dobby
aber nicht wie der Einsatzort dafür ist.
Willentlich wird wohl auch keiner solch eine HW einsetzen. Es sollte dir nur mal mit Oma Grete vor Augen führen das viele unwissentlich solche Systeme einsetzen und sich dann wundern das das nicht klappt.Meist sind das Firmen die aus Unwisseneheit billige Consumer Hardware einsetzen.
Kein normaler Netzwerker kauft natürlich willentlich so einen Schrott. In der Beziehung ist die Frage des "Einsatzortes" natürlich obsolet.
Wozu sollte man den einen Passthrough Router kaufen, der mehreren Sessions aufbauen kann, wenn es richtige VPN-Router gibt?
Na ja...sehr viele betreiben den VPN Server auf einem Server hinter dem NAT Router im lokalen Netz und nicht auf dem Router.Damit hast du dann den klassischen und weut verbreiteten Einsatzfall eines VPN Passthrough Routers.
Letztlich ein schlechtes Design aber leider sehr weit verbreitet.
Verstehen tu ich nicht, wenn benötige ich den einen Passthrough Router der mehrere Sessions kann und wenn einen richtigen VPN Router?
Siehe oben !! Einmal wenn man es richtig macht und das VPN direkt auf dem Router oder Firewall terminiert. Einmal wenn man es hinter dem NAT Router terminiert !werden kann ja nicht mehr unterschieden werden von welchem Client das Paket kam?
Das ist richtig wenn ein Client mehrere Sessions aufbaut. Kommt selten vor aber solche Router "sehen" tiefer in so ein ESP Paket Header rein um einen wasserdichte Sessiontabelle zu führen. Sie werten also weitaus mehr aus als nur IP und Protokollnummer.Aber das ist doch nur dann der Fall wenn ein Protokoll einen Port hat wie z. B HTTP,
Nein ! Das klappt auch für portlose Protokolle.Also die NAT Pool ist also ein NAT Router der auch gleichzeitig PAT kann?
Ja und nein. Wenn du kein PAT machst dann macht er aber nur NAT Pooling. Ist immer ne Frage was du konfigurierst auf dem System und was nicht.PPTP scheitert an PAT weil in der PAT-Sessiontabelle ein anderer Port steht, dass weil PPTP dynamische Ports nutzt und somit bei jeder Verbindung einen anderen Port hat?
Nein, das ist komplett falsch oder du hast es falsch verstanden.Der Client (hinter PAT Router) triggert per TCP 1723 den VPN Server. Der antwortet und will aber gleich einen GRE Tunnel aufbauen zum Client. Der Client hat aber keine gültige Outbound GRE Session, deshalb wird die inbound GRE geblockt.
Identisch zu active FTP über PAT. Geht auch nicht weil der FTP Server eine inbound Data Port Session aufbauen will zu der es keine Session ID gibt. Folglich scheitert auch active FTP über NAT.
Hier siehst du einen schönen Paket Flow der das erklärt:
http://slacksite.com/other/ftp.html --> "Active FTP"
Was hat STUN und NAT mit Port Fordwarding für ein Problem?
Gar keins ! Im Gegenteil...Genau das ist es ja, das mit STUN das NAT bzw. PAT Problem mit dynmischen inbound Sessions umgangen wird !
mein Router alle GRE gedropt, ich musste jedesmal die Firewall deaktivieren, dass ein Tunnel zustande kam
Der typische Klassiker bei der Fehlkonfiguration des Routers bei PPTP !! Siehe hier:VPNs einrichten mit PPTP
Kapitel "hinter NAT Firewall".
Wie konfiguriere ich das?
Guckst du PPTP-Tutorial !GRE Forwarding auf die lokale IP des VPN Clients. Das Tutorial hat eine Beispielkonfig für eine FritzBox. Bei allen anderen Routern ist das vollkommen identisch.
Gibt also PAT-Sessiontabellen die statische sind und dynamische? Genauso wie bei NAT?
Nee, bei PAT ist das immer dynmaisch. Bei NAT kann es dynamisch sein (NAT Pooling) oder statisch (Static 1:1 NAT)Zitat von @108012:
sondern einen VPN Server stehen hat und mehrere Sessions aufgebaut werden
müssen!
Wozu dann Passthrough mit multiplen Sessions?
Das wird Dir erst klar wenn man hinter dem ersten Router keinen zweiten Routersondern einen VPN Server stehen hat und mehrere Sessions aufgebaut werden
müssen!
Also ich versuche mir das als Bild vorzustellen:
Clients aus Netz A -> Passthrough Router mit multiplen Sessions ->VPN Router aus Netz A ---- INTERNET ---- VPN Router als Netz B -> Passthrough Router mit multiplen Sessions -> Clients aus Netz B.
Ob der VPN Server nun ein Server (Computer) ist oder ein Router spielt wohl keine Rolle?
Am meisten Sinn machts wohl wenn der VPN Router auch gleich multiple Sessions kann dann spart man sich einen Router?
Zitat von @aqui:
Meist sind das Firmen die aus Unwisseneheit billige Consumer Hardware einsetzen.
Kein normaler Netzwerker kauft natürlich willentlich so einen Schrott. In der Beziehung ist die Frage des "Einsatzortes" natürlich obsolet.
aber nicht wie der Einsatzort dafür ist.
Willentlich wird wohl auch keiner solch eine HW einsetzen. Es sollte dir nur mal mit Oma Grete vor Augen führen das viele unwissentlich solche Systeme einsetzen und sich dann wundern das das nicht klappt.Meist sind das Firmen die aus Unwisseneheit billige Consumer Hardware einsetzen.
Kein normaler Netzwerker kauft natürlich willentlich so einen Schrott. In der Beziehung ist die Frage des "Einsatzortes" natürlich obsolet.
Ein guter richtiger VPN Router kann und muss auch mehrere Sessions unterstützten? Dein Beispiel mit Oma Grete versuche ich mir folgendermassen als Bild darzustellen:
Clients aus Netz A ---> Passthrough Router mit multiplen Sessions -> VPN Router (macht den Tunnel anfang) ---------- INTERNET --------- VPN Router (Tunnelende) -> Passthrough Router mit multiplen Sessions -> Client aus Netz B.
Habe ich das richtig aus deinem Beispiel interpretiert? Macht ja mehr Sinn nur einen richtigen VPN Router mit multiplen Sessions statt noch einen zweiten mit Passthrough oder?
Wozu sollte man den einen Passthrough Router kaufen, der mehreren Sessions aufbauen kann, wenn es richtige VPN-Router gibt?
Na ja...sehr viele betreiben den VPN Server auf einem Server hinter dem NAT Router im lokalen Netz und nicht auf dem Router.Damit hast du dann den klassischen und weut verbreiteten Einsatzfall eines VPN Passthrough Routers.
Letztlich ein schlechtes Design aber leider sehr weit verbreitet.
Verstehe ich nicht. Wieso VPN Router hinter einem NAT-Router betreiben statt hinter dem richtigen Router? Gibts Router die nur NAT machen und Routen? Wo hinter dem NAT-Router ist den jetzt der Passthrough Router mit multiplen Sessions? Kann mir das nicht als Bild vorstellen.
Verstehen tu ich nicht, wenn benötige ich den einen Passthrough Router der mehrere Sessions kann und wenn einen richtigen VPN Router?
Siehe oben !! Einmal wenn man es richtig macht und das VPN direkt auf dem Router oder Firewall terminiert. Einmal wenn man es hinter dem NAT Router terminiert !Ich kann mir das einfach nicht vorstellen wie das funktionieren soll... Wie meinst du das mit vor oder nach dem NAT Router?
werden kann ja nicht mehr unterschieden werden von welchem Client das Paket kam?
Das ist richtig wenn ein Client mehrere Sessions aufbaut. Kommt selten vor aber solche Router "sehen" tiefer in so ein ESP Paket Header rein um einen wasserdichte Sessiontabelle zu führen. Sie werten also weitaus mehr aus als nur IP und Protokollnummer.Aber wenn in der Sessiontabelle nur notiert wird welche IP-Adresse und welches Protokoll mehr nicht also kann auch nur anhand dieser Infos rückschluss über den Absender des Paket aus der Sessiontabelle gemacht werden.
Aber das ist doch nur dann der Fall wenn ein Protokoll einen Port hat wie z. B HTTP,
Nein ! Das klappt auch für portlose Protokolle.Ja aber wie soll den das gehen. Jetzt wo ich das Prinzip von NAT verstanden habe. Wenn es kein Protokoll gibt kann ja nur eine Session existieren. Wenn 192.168.1.2 nun ein VPN Server ist werden diverse Clients ihre Pakete an den VPN Server schicken die Sessiontabelle vom Passthrough Router mit multiplen Sessions listet nun auf:
192.168.1.3 -> ESP
192.168.1.4 -> ESP
192.168.1.6 -> ESP
Also die NAT Pool ist also ein NAT Router der auch gleichzeitig PAT kann?
Ja und nein. Wenn du kein PAT machst dann macht er aber nur NAT Pooling. Ist immer ne Frage was du konfigurierst auf dem System und was nicht.Verstehe nicht. Also NAT Pool heisst er kann beides also PAT und NAT man muss nur konfigurieren was wo eingesetzt werden soll?
PPTP scheitert an PAT weil in der PAT-Sessiontabelle ein anderer Port steht, dass weil PPTP dynamische Ports nutzt und somit bei jeder Verbindung einen anderen Port hat?
Nein, das ist komplett falsch oder du hast es falsch verstanden.Der Client (hinter PAT Router) triggert per TCP 1723 den VPN Server. Der antwortet und will aber gleich einen GRE Tunnel aufbauen zum Client. Der Client hat aber keine gültige Outbound GRE Session, deshalb wird die inbound GRE geblockt.
Identisch zu active FTP über PAT. Geht auch nicht weil der FTP Server eine inbound Data Port Session aufbauen will zu der es keine Session ID gibt. Folglich scheitert auch active FTP über NAT.
Hier siehst du einen schönen Paket Flow der das erklärt:
http://slacksite.com/other/ftp.html --> "Active FTP"
Also besteht GRE wie bei FTP aus zwei verschiedenen Ports? Einen Port fürs herstellen der Sitzung (Port 20) und einen für die Datenübertragung (Port 21)? In der Sessiontabelle wird also nur Port 20 geöffnet und somit schlägt die Verbindung fehl? Verstehe ich dich richtig?
Mit Port Forwarding lässt sich also das verhindern, dass aufgrund dieser Problematik keine Verbindung hergestellt werden kann? Finde nur komisch, dass ich auf meinen NAS-Server über FTP zugreifen kann obwohl ich einen PAT-Router habe und dort nur eingetragen habe in der statischen PAT-Tabelle welche IP-Adresse der Server hat und auf welchen Port er hört.
Wie sieht den das Beispiel nun aus? Was müsste ich bei mir im Router unter der Port Fordwarding eintragen um nehmen wir FTP als Beispiel?
mein Router alle GRE gedropt, ich musste jedesmal die Firewall deaktivieren, dass ein Tunnel zustande kam
Der typische Klassiker bei der Fehlkonfiguration des Routers bei PPTP !! Siehe hier:VPNs einrichten mit PPTP
Kapitel "hinter NAT Firewall".
Aha, dann bin ich ja mal gespannt ob das Funktionieren wird. Wieso heisst das überhaupt NAT Firewall? Das hat doch nichts damit zu tun? Wieso NAT Firewall wenn ich einen PAT Router habe?
Wie konfiguriere ich das?
Guckst du PPTP-Tutorial !GRE Forwarding auf die lokale IP des VPN Clients. Das Tutorial hat eine Beispielkonfig für eine FritzBox. Bei allen anderen Routern ist das vollkommen identisch.
Also reicht das Eintragen von Server IP-Adresse des VPN Server und Port nicht aus damit PPTP geht. Also war das mein Fehler das noch GRE Forwarding einstellen muss.
Habe ich das richtig aus deinem Beispiel interpretiert?
Ja, alles richtig !Verstehe ich nicht. Wieso VPN Router hinter einem NAT-Router betreiben statt hinter dem richtigen Router? Gibts Router die nur NAT machen und Routen?
Leider ja ! Das sind z.B. alle Provider Kunden die vom provider einen Zwangsrouter bekommen und nicht selber über ihre HW bestimmen können.Solche billigen Zwangsrouter vom Provider ist sehr oft der allerbilligste Schrott der nur NAT und routen kann. Durch den Zwang dann zu kaskadieren kommt es zu soclehn Konstellation...und es gibt nicht gerade sehr wenige Zwangsrouter Opfer.
Glücklicherweise ist das durch die geplante Gesetzänderung bald vorbei:
http://www.heise.de/netze/meldung/Wirtschaftsministerium-legt-Gesetzese ...
Wie meinst du das mit vor oder nach dem NAT Router?
Stell dir die Router Kaskade vor mit einem Zwangsrouter...das solltest auch du verstehen ?!Kopplung von 2 Routern am DSL Port
Ja aber wie soll den das gehen. Jetzt wo ich das Prinzip von NAT verstanden habe.
Solche Router können bei diesen Protokollen in höhere Schichten des Pakets "sehen" (OSI Schicht 4-7) und Informationen dort auswerten die eine Session bestimmen. Welche Informationen das sind sind dann Protokoll abhängig.Das können aber nur "bessere" Router.
Verstehe nicht. Also NAT Pool heisst er kann beides also PAT und NAT
Nein ! Bei NAT Pooling ist das ein dynmaisches 1:1 NAT. D.h. die 1:1 NAT Beziehungen werden nicht statisch definiert in der Konfig sondern nur ein Template. Das nimmt sich dann aus einem IP Adresspool eine freie IP für eigehende Client Sessions nach dem prizip first come first serve und macht dann 1:1 NAT. Pooling macht man wenn man wenige NAT Adressen hat und dafpür ein 1:1 NAT für sehr viele Clients machen muss. Es ist kein PAT !PAT kann aber mit 1:1 NAT oder auch NAT Pooling zusammen immer koexistieren auf einem Router auf unterschiedlichen Interfaces !
Also besteht GRE wie bei FTP aus zwei verschiedenen Ports?
Nein, GRE selber nicht. aber PPTP ! PPTP nutzt immer GRE und TCP 1723 zusammen. Wie L2TP was IPsec mit ESP, UDP 500 und TCP 1701 benutzt zusammen.Mit Port Forwarding lässt sich also das verhindern, dass aufgrund dieser Problematik keine Verbindung hergestellt werden kann?
Nein, das hast du vollkommen falsch verstanden !!!PAT verhindert soclhe Verbindungen und mit Port Forwarding bekommt man sie zum Laufen, da mit Port Forwarding die relevanten Protokolle wie GRE oder ESP durch die NAT(PAT) Firewall passieren können.
Andersrum wird also ein Schuh draus !
nur komisch, dass ich auf meinen NAS-Server über FTP zugreifen kann
Generell kann man das mit PAT und active FTP de facto NICHT !!! Warum ist ja ganz klar. FTP nutzt 2 Ports TCP 20 und 21 und kann damit niemals einen PAT Router passieren.Die meisten Router sind aber intelliegent und wenn sie eine outgoing TCP 20 Session "sehen" dann öffnen sie gleichzeitig inbound den Port TCP 21 für die Daten. Das sind dann "mitdenkende" Router und das nennt man Application aware Firewall.
Ist aber alles obsolet wenn man PASSIVE FTP benutzt, also FTP im Passive Modus, dann stellt sich die problematik gar nicht erst. Die meisten FTP Clients machen das per Default oder werden vom FTP Server per Kommandoport in diesen Mode gezwungen, deshalb klappt es wohl auch bei dir.
Auch möglich das dein NAS z.B. per UPnP automatisch mit dem Router spricht und sich die Firewall selber öffnet mit UPnP.
Ein sehr wichtiger Grund warum man UPnP immer zwingend deaktivieren sollte, da fast alle Trojaner und Viren UPnP nutzen um soclhce Router für den Zugriff von außen frei zu machen !
Es gibt da mehrere Wege. Leider hat man das alles gemacht damit auch der letzte DAU möglichst einfach von außen auf sein Heimnetz zugreifen kann. Was aber immer fatale Folgen hat....
Wieso heisst das überhaupt NAT Firewall?
Du hast recht. Ist technisch falsch und müsste richtig eigentlich PAT Firewall heissen. Hat sich halt leider so eingebürgert die Schreibweise. Genau so unsäglich wie Modem und Router...Also reicht das Eintragen von Server IP-Adresse des VPN Server und Port nicht aus damit PPTP geht.
Nein, normal nicht ! Der Screenshot der FritzBox zeigt dir ja klar das da GRE und TCP 1723 steht !!Einige Router interpretieren aber sowei man "TCP 1723" ins PFW einträgt das da nur PPTP mit gemeint sein kann und geben still und heimlich gleich GRE mit frei. Meistens fehlt diesen Routern dann auch die Option GRE dediziert auch freizugeben.
Wenn man Pech hat hat man aber einen doofen Router der das nicht macht und dann ist das der Tod vom PPTP.
Zitat von @aqui:
Glücklicherweise ist das durch die geplante Gesetzänderung bald vorbei:
http://www.heise.de/netze/meldung/Wirtschaftsministerium-legt-Gesetzese ...
Najaaaaaaaa Glücklicherweise ist das durch die geplante Gesetzänderung bald vorbei:
http://www.heise.de/netze/meldung/Wirtschaftsministerium-legt-Gesetzese ...
http://www.heise.de/newsticker/meldung/Gesetz-gegen-Router-Zwang-droht- ...
Kann man nur hoffen das unsere Volksvertreter sich nicht wieder irgendwelchen Lobbyverbänden beugen und an die denken die sie wählen !! Aber vermutlich ist das wieder weltfremd...
Zitat von @aqui:
Das können aber nur "bessere" Router.
Ja aber wie soll den das gehen. Jetzt wo ich das Prinzip von NAT verstanden habe.
Solche Router können bei diesen Protokollen in höhere Schichten des Pakets "sehen" (OSI Schicht 4-7) und Informationen dort auswerten die eine Session bestimmen. Welche Informationen das sind sind dann Protokoll abhängig.Das können aber nur "bessere" Router.
Was für Infos sind den das? Wie kann den das Entschieden werden? Bei ESP oder GRE beide sind portlos wie kann anhand dieser Protokolle entschieden werden von wem die Session ist?
Angenommen:
1 x Windows Server mit installierter Rolle "Remotezugriff" dort will ich PPTP VPN machen. Ich habe fünf Freunde alle fünf sollen gleichzeitig auf meinen Windows Server zugreiffen können um über meinen VPN Tunnel surfen zu können.
Wie kann ich sowas realisieren? Was geschieht in der NAT vom meinem Router? Wie verhält sich das mit dem Unterscheiden der Sessions auf dem NAT Router?
Verstehe nicht. Also NAT Pool heisst er kann beides also PAT und NAT
Nein ! Bei NAT Pooling ist das ein dynmaisches 1:1 NAT. D.h. die 1:1 NAT Beziehungen werden nicht statisch definiert in der Konfig sondern nur ein Template. Das nimmt sich dann aus einem IP Adresspool eine freie IP für eigehende Client Sessions nach dem prizip first come first serve und macht dann 1:1 NAT. Pooling macht man wenn man wenige NAT Adressen hat und dafpür ein 1:1 NAT für sehr viele Clients machen muss. Es ist kein PAT !Also Pooling ist ein dynamisches NAT und ist nicht fest konfiguriert. Verstehe nicht wie du das meinst mit
"Das nimmt sich dann aus einem IP Adresspool eine freie IP für eigehende Client Sessions"
Ist damit gemeint die IP-Adresse eines Client der eine Verbindung herstellen will? Bei NAT ist ja eine Private IP mit einer öffentlichen IP verknüpft.
Was meinst du mit wenige NAT Adressen? Adresse aus dem LAN oder WAN?
192.168.1.2 -> 83.134.123.12
192.168.1.38 -> 83.134.123.12
192.168.1.4 -> 83.134.123.12
192.168.1.5 -> 83.134.123.12
Sowas vielleicht? Also wenn man wenige private IPs hat? Man könnte ja auch in ein B Klassen Netz wechseln wenn man mehr IPs benötigt.
PAT kann aber mit 1:1 NAT oder auch NAT Pooling zusammen immer koexistieren auf einem Router auf unterschiedlichen Interfaces !
Wie soll ich das verstehen? Also können NAT-Router gleichzeitig PAT machen das heisst also das Übersetzten von IP-Adresse mit Port gleichzeitig? Also 192.168.1.3:80 -> 89.123.12.12:80. Was meinst du mit den verschiedenen Interfaces?
Also besteht GRE wie bei FTP aus zwei verschiedenen Ports?
Nein, GRE selber nicht. aber PPTP ! PPTP nutzt immer GRE und TCP 1723 zusammen. Wie L2TP was IPsec mit ESP, UDP 500 und TCP 1701 benutzt zusammen.Zwei Protokolle aber nicht zwei Ports? GRE ist ja portlos. FTP hat aber zwei Protokolle 20 und 21. IKE benutzt ja UDP 500 wofür ist dann TCP 1701?
Mit Port Forwarding lässt sich also das verhindern, dass aufgrund dieser Problematik keine Verbindung hergestellt werden kann?
Nein, das hast du vollkommen falsch verstanden !!!PAT verhindert soclhe Verbindungen und mit Port Forwarding bekommt man sie zum Laufen, da mit Port Forwarding die relevanten Protokolle wie GRE oder ESP durch die NAT(PAT) Firewall passieren können.
Andersrum wird also ein Schuh draus !
Also PAT verhindert Verbindung die zwei Ports haben wie z. B FTP? Mit Port Forwarding verhindert man das Problem indem man sie durch die NAT und PAT lässt. ESP ist also wichtiger als die beiden von dir genannten Port wie IKE? Ohne IKE auch kein IPsec VPN? Ohne TCP 1701 doch auch kein ESP?
Wie sieht es anhand eines Beispiels meines Router aus [[]]
nur komisch, dass ich auf meinen NAS-Server über FTP zugreifen kann
Generell kann man das mit PAT und active FTP de facto NICHT !!! Warum ist ja ganz klar. FTP nutzt 2 Ports TCP 20 und 21 und kann damit niemals einen PAT Router passieren.Die meisten Router sind aber intelliegent und wenn sie eine outgoing TCP 20 Session "sehen" dann öffnen sie gleichzeitig inbound den Port TCP 21 für die Daten. Das sind dann "mitdenkende" Router und das nennt man Application aware Firewall.
Ist aber alles obsolet wenn man PASSIVE FTP benutzt, also FTP im Passive Modus, dann stellt sich die problematik gar nicht erst. Die meisten FTP Clients machen das per Default oder werden vom FTP Server per Kommandoport in diesen Mode gezwungen, deshalb klappt es wohl auch bei dir.
Auch möglich das dein NAS z.B. per UPnP automatisch mit dem Router spricht und sich die Firewall selber öffnet mit UPnP.
Ein sehr wichtiger Grund warum man UPnP immer zwingend deaktivieren sollte, da fast alle Trojaner und Viren UPnP nutzen um soclhce Router für den Zugriff von außen frei zu machen !
Es gibt da mehrere Wege. Leider hat man das alles gemacht damit auch der letzte DAU möglichst einfach von außen auf sein Heimnetz zugreifen kann. Was aber immer fatale Folgen hat....
Wie muss ich das mit Outgoing TCP 20 Session und Inbound TCP 21 verstehen? Das ist sowie ich das verstehe die dynamische PAT welches das macht oder?
Was hat das mit Firewall zu tun? Wieso sollte es im passiven Modus von FTP zu keinen Problemen kommen. Es existieren ja zwei Ports auch wenn es passiv ist.
Wieso heisst das überhaupt NAT Firewall?
Du hast recht. Ist technisch falsch und müsste richtig eigentlich PAT Firewall heissen. Hat sich halt leider so eingebürgert die Schreibweise. Genau so unsäglich wie Modem und Router...Wieso den PAT Firewall? Was hat eine Firewall mit PAT oder NAT zu tun? Merkwürdig ist auch wenn ich eine NAT-Regel im Router einstelle steht im Log das es per NAT forwarded wurde. Wenn ich glaube diese Regel lösche wird die Verbindung vom Router blockiert.
Aber Modem und Router sind auch zwei unterschiedliche Geräte aber oft wie FritzBox alles in einem. Früher war das Modem im PC eingebaut
Also reicht das Eintragen von Server IP-Adresse des VPN Server und Port nicht aus damit PPTP geht.
Nein, normal nicht ! Der Screenshot der FritzBox zeigt dir ja klar das da GRE und TCP 1723 steht !!Einige Router interpretieren aber sowei man "TCP 1723" ins PFW einträgt das da nur PPTP mit gemeint sein kann und geben still und heimlich gleich GRE mit frei. Meistens fehlt diesen Routern dann auch die Option GRE dediziert auch freizugeben.
Wenn man Pech hat hat man aber einen doofen Router der das nicht macht und dann ist das der Tod vom PPTP.
Was heisst PFW? Also bei meiner ZyXEL kann ich sowie es aussieht keinen GRE oder ESP freigeben. Weiter verlangt er immer, dass ein Port angegeben wird ohne gehts nicht.
Also heisst das wiederrum bleibt mir nur übrig Firewall deaktivieren?
Was hat STUN und NAT mit Port Fordwarding für ein Problem?
Gar keins ! Im Gegenteil...Genau das ist es ja, das mit STUN das NAT bzw. PAT Problem mit dynmischen inbound Sessions umgangen wird !
STUN erkennt auf irgendeine unbekannte weise welchen NAT-Art verwendet wird (was auch immer mit NAT-Art gemeint ist) denke aber an Source-NAT oder Destination-NAT. Was und wie funktioniert das?
Bei ESP oder GRE beide sind portlos wie kann anhand dieser Protokolle entschieden werden von wem die Session ist?
Indem man ins datenfeld des Pakets sieht und dort Session relevante Infos auswertet.Wie kann ich sowas realisieren? Was geschieht in der NAT vom meinem Router? Wie verhält sich das mit dem Unterscheiden der Sessions auf dem NAT Router?
Bei einem PAT Router sind das 3 Punkte:- Gar nicht wenn du einen dummen Router hast der kein Session Handling hat für GRE
- Mit nur einem User zur Zeit inkl. Timeout Wartezeit wenn du einen dummen Router hast der PFW kann aber nur für eine einzige Session
- Mit einem guten Router der multiples Session Handling kann bei GRE
- Statisches 1:1 NAT einrichten
- Du hast 5 IP Adressen im NAT Pool und gibst jedem deiner 5 Kumpel eine
st damit gemeint die IP-Adresse eines Client der eine Verbindung herstellen will?
Ja, ganz genau. Ein lokaler Clinet mit lokaler IP bekommt eine 1:1 NAT IP für die Outbound Session, die nach einer gewissen Inaktivitätszeit wieder in den Pool zurückfällt.Wie soll ich das verstehen? Also können NAT-Router gleichzeitig PAT machen
Ja, klar. Stell dir nicht immer billige Dummrouter für DSL vor. Es gint auch professionelle Router die 20 oder mehr Interfaces haben ! Pro Interface kannst dudann das NAT machen was du willst.Oh oh...nun machst du aber freien Fall....
Würfel bitte nicht alle protokolle durcheinander. JEDES Protokoll hat andere Verhaltensweisen beim NAT !!Ordne erstmal deinen Gedanken und sieh dir das Sessionhandling hier im FTP Diagram an dann wird dir das sofort klar:
http://slacksite.com/other/ftp.html
Wie muss ich das mit Outgoing TCP 20 Session und Inbound TCP 21 verstehen?
Bitte sieh dir dzu das Diagram unter "Active FTP" und "Passive FTP" an !! das erklärt alles !Also können NAT-Router gleichzeitig PAT machen
Ja, wenn man multiple IP Adressen auf dem Interface hat oder der Router mit sog. secondary IP Adressen arbeiten kann !Wieso den PAT Firewall? Was hat eine Firewall mit PAT oder NAT zu tun?
Nicht wirklich was, da hast du Recht. Eine PAT verhält sich aber in einer Richtung genau wie eine Firewall daher der landläufige Ausdruck. Technisch sind das aber 2 Paar Schuhe.Was heisst PFW?
Port ForwardingZyXEL kann ich sowie es aussieht keinen GRE oder ESP freigeben
Tja...häufig so bei Billigen Chinaböllern STUN erkennt auf irgendeine unbekannte weise welchen NAT-Art verwendet wird
Das ist natürlich Blödsinn...weisst du selber. In der IT ist nix "unbekannt" !https://de.wikipedia.org/wiki/Session_Traversal_Utilities_for_NAT
Zitat von @aqui:
Wie kann ich sowas realisieren? Was geschieht in der NAT vom meinem Router? Wie verhält sich das mit dem Unterscheiden der Sessions auf dem NAT Router?
Bei einem PAT Router sind das 3 Punkte:- Gar nicht wenn du einen dummen Router hast der kein Session Handling hat für GRE
Ich verstehe immer noch nicht wie der Router mit PAT diese verschiedenen Session unterscheiden kann wenn es gar keine Ports gibt. Ich kann mir das nicht vorstellen wie er in diese Pakete *schaut* und sowas herauslesen kann.
Ohne Pooling mit 1:1 NAT bei statischen IPs:
- Statisches 1:1 NAT einrichten
Bei statischem NAT ohne Pooling sagte ich die IP-Adresse 83.123.123.12 soll zu IP-Adresse 192.168.1.112 weitergeleitet werden.
und weiter IP 83.123.124.12 soll zu 192.168.1.112 weitergeleitet werden? Ist das so gemeint?
Bei einem NAT Router der NAT Pooling kann:
- Du hast 5 IP Adressen im NAT Pool und gibst jedem deiner 5 Kumpel eine
Und beim Pooling (ich stells mir wie ein DHCP-Server vor) verteilt er (dynamische NAT) jedem Kumpel eine WAN-IP welche zum Windows-Server der PPTP macht weiterleitet?
Was bringt mir das Pooling den im Unterschied zwischen ohne Pooling?
Mit Pooling ist es dynamisches NAT?
Ohne Pooling statisches NAT?
Also jeder Kumpel hat eine öffentliche WAN IP-Adresse wenn ich dich richtig verstehe die aus dem NAT Pool verteilt wird? Alle diese 5 IP-Adressen haben dann die IP 192.168.1.3 als Weiterleitung hinterlegt zum Webserver?
st damit gemeint die IP-Adresse eines Client der eine Verbindung herstellen will?
Ja, ganz genau. Ein lokaler Clinet mit lokaler IP bekommt eine 1:1 NAT IP für die Outbound Session, die nach einer gewissen Inaktivitätszeit wieder in den Pool zurückfällt.Also wie jetzt? Die 5 Kumpel wollen eine PPTP Verbindung mit meinem Windows-Server herstellen. Beim NAT Pooling werden nun fünf LAN-IP-Adressen an alle fünf Clients verteilt welche alle zur öffentlichen WAN-IP vom Windows-Server weitergeleitet werden? Dieses NAT-Pooling wird eingesetzt wenn es wenige LAN- oder WAN-IP-Adressen gibt?
Oh oh...nun machst du aber freien Fall....
Würfel bitte nicht alle protokolle durcheinander. JEDES Protokoll hat andere Verhaltensweisen beim NAT !!Ordne erstmal deinen Gedanken und sieh dir das Sessionhandling hier im FTP Diagram an dann wird dir das sofort klar:
http://slacksite.com/other/ftp.html
Ich meinte PAT hat dann Probleme wenn zwei Ports verwendet werden also z.B FTP mit Port 20 und 21 oder GRE mit TCP (1723 glaub) dann muss Port Forwarding eingesetzt werden damit das wichtige weitergeleitet werden kann damit der Server danach eine Verbindung aufbauen kann.
Wie muss ich das mit Outgoing TCP 20 Session und Inbound TCP 21 verstehen?
Bitte sieh dir dzu das Diagram unter "Active FTP" und "Passive FTP" an !! das erklärt alles !Also öffnet PAT diese Ports. Was ich noch nicht verstehe ist Client fragt beim Server an um ein FTP-Verbindung herstellen zu dürfen der Server öffnet mit PAT den Port 21. Das wird nun in der PAT-Tabelle gespeichert. Du hast nun gesagt schlaue Router öffnen gleichzeitig auch noch Port 20 wo wird das hingeschrieben in der PAT-Sessiontabelle stehen doch nur ein Port pro offener Verbindung. Was passiert wenn ich jetzt gleichzetig noch ein Port Forwarding konfiguriere? Kann ich dort eine Weiterleitung vom Port 21 zum wichtigen Port 20 machen oder?
Also können NAT-Router gleichzeitig PAT machen
Ja, wenn man multiple IP Adressen auf dem Interface hat oder der Router mit sog. secondary IP Adressen arbeiten kann !Das heisst was? Hätte mein Router mehrere WAN-Schnittstellen und auf jeder Schnittstelle habe ich eine andere WAN-IP-Adresse meinst du das so? Was ist mit secondary IP-Adresse gemeint?
ZyXEL kann ich sowie es aussieht keinen GRE oder ESP freigeben
Tja...häufig so bei Billigen Chinaböllern Also bleibt mir somit nichts anders übrig als Firewall deaktivieren? Bei deaktivierter Firewall leitet er GRE richtig weiter. Darum klappt auch dann der PPTP. Wie verhält sich das wenn ich anstelle der statischen NAT Weiterleitung von TCP 1123 für einen PPTP mit Port Forwarding auf GRE weiterleite? Oder klappt das auch nicht weil er halt kein GRE weiterleitet? ....Zwar bei Port Forwarding kann ich nur Ports eingeben da GRE keine hat klappt ja das auch nicht um die Problematik zu umgehen.....
STUN erkennt auf irgendeine unbekannte weise welchen NAT-Art verwendet wird
Das ist natürlich Blödsinn...weisst du selber. In der IT ist nix "unbekannt" !https://de.wikipedia.org/wiki/Session_Traversal_Utilities_for_NAT
Habe mir den Wiki Artikel durchgelesen dort steht STUN erkennt anhand der NAT-"ART" was ist mit NAT-ART gemeint? Etwa Destination-NAT oder Source-NAT? Mehr verstehe ich nicht wie das genau erkennt wird und was da geschieht.
Ich verstehe immer noch nicht wie der Router mit PAT diese verschiedenen Session unterscheiden kann wenn es gar keine Ports gibt.
Der Router identifiziert diese Pakte an seiner IP Protokoll Nummer und sieht tiefer in die Pakete rein und verwendet dort Session spezifische Informationen aus dem Dateninhalt.Wie gesagt, das erfordert erheblich CPU Performance. Ein Grund warum billige SoC Router sowas nicht können.
Static NAT: Ist das so gemeint?
Ja, genau so.Und beim Pooling
Nein, das ist schlciht falsch, denne s hat spzifisch mit PPTP und anderen protokollen nicht das Geringste zutun. NAT ist NAT und PPTP ist PPTP. NAT arebeitet rein nur auf Layer 3. Das im Paket transportiert wird ist NAT vollkommen egal.Um bei deinem Beispiel zu bleiben....
192.168.1.112 inbound soll outbound 83.123.123.12 haben, das wäre statisches NAT. Braucht für jede inbound IP einen zugewiesene Outbound IP.
Jetzt hast du aber nur 4 Outbound IPs aber ein /24 Netz intern. Da kann man dann Pooling machen.
Sessions aus dem 192.168.1.0 /24 Netz schnappen sich eine IP aus dem 83.123.123.12-15 Pool und agieren nach first come first serve wie statisches NAT.
Setzt natürlich voraus das nicht mehr als 4 User gleichzeitig irgendwohin NAT müssen, klar.
Was bringt mir das Pooling den im Unterschied zwischen ohne Pooling?
Den Vorteil einer "Mangelverwaltung" das du quasi statisches NAT auch bei sehr limitierten IP Adressen über ein Pool Profile machen kanst.Ich meinte PAT hat dann Probleme wenn zwei Ports verwendet werden
Nein, nicht gernell.Was aber bei FTP passiert ist das ein inbound Client per TCP 21 rausgeht an einen Server hinterm NAT und eine FTP Session requested. Der FTP Server bestätigt das öffnet dann aber von sich aus eine TCP 20 Session auf die NAT outbound IP am Router.
Da dieser aber keine gültige inbound TCP 20 Session hat der er das zuordnen kann blockt er diesen Zugriff mit dem Ergebnis das normales FTP nicht funktioniert ! Logisch und versteht jeder wenn man sich mal die Mühe macht und in der zitierten Webseite den Paket Flow ansieht ! :-o
Also öffnet PAT diese Ports.
Nein, auch wieder falsch weil du den Paket Flow nicht angesehen hast. Client sagt dem Server über TCP 21 Command Port das er den passive Mode will. Server sagt ACK und öffnet keinen TCP 20 Port und wartet von sich aus auf den Client der dann TCP 20 öffnet. Nun gibt es auch eine gültige inbound NAT TCP 20 Session und alles ist gut.
Der Server wartet passiv, deshalb auch der Name passive Mode ! Groschen gefallen...??
Hätte mein Router mehrere WAN-Schnittstellen und auf jeder Schnittstelle habe ich eine andere WAN-IP-Adresse meinst du das so?
Jau, genau so !Was ist mit secondary IP-Adresse gemeint?
Wenn ein Router mehrere unterschiedliche IP Netze bzw. Adressen auf einem Port supportet:http://www.cisco.com/c/en/us/td/docs/ios/12_2/ip/configuration/guide/fi ...
Ist nicht Standard konform aber manche Hersteller supporten das um IP Adress Migrationen einfacher zu machen.
Also bleibt mir somit nichts anders übrig als Firewall deaktivieren?
Wenn du so einen billigen Schrottrouter hast dann ja. Ohne Firewall ist das aber ein Himmelfahrtskommando ! Kein normaler Mensch arbeitet so ungeschützt direkt am Internet !Zyxel kann mit Sicherheit passthrough. Ob Multisession oder nicht ist wieder einen andere Frage aber passthrough macht er mit Sicherheit. Das machen heutzutage sogar 12 Euro Router von TP-Link aus China.
Wie verhält sich das wenn ich anstelle der statischen NAT Weiterleitung von TCP 1123 für einen PPTP mit Port Forwarding auf GRE weiterleite?
Das geht gar nicht....Zuerstmal benutzt PPTP TCP 1723 und nicht 1123. Und du musst zwingend beide Protokollkomponenten weiterleiten, denn sonst kann PPTP logischerweise nicht funktionieren...klar !
Wie gesagt. Manche Dummrouter sind wenigstens so intelligent das sie, sofern du TCP 1723 weiterleitest, sie automatisch auch GRE auch weiterleiten. Ob das bei dir der Fall ist sagt dir das Handbuch oder...Versuch macht klug...
GRE ist wie gesagt ein eigenes Protokoll was man beim Port Forwarding entsprechend auswählen kann statt UDP oder TCP.
Hier mal ein Screenshot von der Einrichtung des Port Forwarding bei einer pfSense Firewall an der du sehen kannst welche Protokolle zur Auswahl stehen:
Jeder Router der das kann hat immer auch genau diese Auswahl Optionen !
was ist mit NAT-ART gemeint?
Damit ist PAT oder NAT gemeint. Anderes wäre unsinnig.Zitat von @aqui:
Wie gesagt, das erfordert erheblich CPU Performance. Ein Grund warum billige SoC Router sowas nicht können.
Ich verstehe immer noch nicht wie der Router mit PAT diese verschiedenen Session unterscheiden kann wenn es gar keine Ports gibt.
Der Router identifiziert diese Pakte an seiner IP Protokoll Nummer und sieht tiefer in die Pakete rein und verwendet dort Session spezifische Informationen aus dem Dateninhalt.Wie gesagt, das erfordert erheblich CPU Performance. Ein Grund warum billige SoC Router sowas nicht können.
Habe bei Wikipedia nochmals über die IP Protokollnummern informiert. Diese Protokollnummer dient dazu, einen andere OSI-Schicht zu informieren was in deren IP-Paket geliefert wird also welches Protokoll? Da hat aber dann mit NAT nichts zu tun im Gegensatz zu Protokollen die eine Portnummer besitzen dort geht alles über NAT bzw. PAT. Als Beispiel HTTP
Steht den in diesem Dateninhalt z. B die IP-Adresse des Clients an welche die Session zugeteilt ist und somit weiss der Router an wen es muss? Ist wohl eine andere Technik als NAT (PAT)?
Und beim Pooling
Nein, das ist schlciht falsch, denne s hat spzifisch mit PPTP und anderen protokollen nicht das Geringste zutun. NAT ist NAT und PPTP ist PPTP. NAT arebeitet rein nur auf Layer 3. Das im Paket transportiert wird ist NAT vollkommen egal.Um bei deinem Beispiel zu bleiben....
192.168.1.112 inbound soll outbound 83.123.123.12 haben, das wäre statisches NAT. Braucht für jede inbound IP einen zugewiesene Outbound IP.
Jetzt hast du aber nur 4 Outbound IPs aber ein /24 Netz intern. Da kann man dann Pooling machen.
Sessions aus dem 192.168.1.0 /24 Netz schnappen sich eine IP aus dem 83.123.123.12-15 Pool und agieren nach first come first serve wie statisches NAT.
Setzt natürlich voraus das nicht mehr als 4 User gleichzeitig irgendwohin NAT müssen, klar.
Also das verstehe ich schon das NAT und PPTP nicht das Gleiche ist.
Ich weiss ja vorher, dass ich z. B 4 Private IP-Adressen habe und diese zu den WAN-IP-Adressen weiterleiten will, sodass meine 4 Server online sein können das Gleichzeitig. Somit kann ich das doch auch gleich als statisches NAT also ohne Pooling realisieren? Die vier Server haben ja eine statische IP-Adresse somit wird auch die Zuordnung der Sessions immer gleich bleiben wie beim statischen NAT?
Was bringt mir das Pooling den im Unterschied zwischen ohne Pooling?
Den Vorteil einer "Mangelverwaltung" das du quasi statisches NAT auch bei sehr limitierten IP Adressen über ein Pool Profile machen kanst.Verstehe nicht genau was du meinst. Eine Idee habe ich, meinst du eventuell das aus dem IP-Bereich 192.168.1.X /24 (existieren 253) Host-IDs bei WAN sind es jedoch nur 4 und darum Pooling das jeder dieser 253 Clients (von Oben) die Chance erhält eine dieser 4 WAN-IP-Adressen zu erhalten?
Aber was bringt das wenn jeder dieser 253 Clients mal eine Session zu den 4 WAN-IP-Adressen herstellen darf? Diese 253 Client sind doch nicht im gleichen Netzwerk das sind doch z.B meine 4 Freunde die versuchen durch die NAT Pooling auf meine 4 Server zu verbinden? Pooling heisst es weil die WAN-IP-Adressen aus dem Pool genommen wird oder sind damit die LAN-IPs gemeint?
Ich meinte PAT hat dann Probleme wenn zwei Ports verwendet werden
Nein, nicht gernell.Was aber bei FTP passiert ist das ein inbound Client per TCP 21 rausgeht an einen Server hinterm NAT und eine FTP Session requested. Der FTP Server bestätigt das öffnet dann aber von sich aus eine TCP 20 Session auf die NAT outbound IP am Router.
Da dieser aber keine gültige inbound TCP 20 Session hat der er das zuordnen kann blockt er diesen Zugriff mit dem Ergebnis das normales FTP nicht funktioniert ! Logisch und versteht jeder wenn man sich mal die Mühe macht und in der zitierten Webseite den Paket Flow ansieht ! :-o
Achso so funktioniert das. Client öffnet TCP 21 und der Server antwortet gleich mit TCP 20. Eigentlich müsste der Server erst TCP 21 bestätigen wie im Flow geschrieben und dann erst TCP 20 öffnen was wiederrum der Client bestätigen muss. Wieso "kein gültiger inbound TCP 20 Session"? Der Server bestätigt doch dies und somit weiss die NAT auch das diese Session offen ist? (Also ist die Funktionsweise ähnlich wie beim TCP Handshake dort sind noch Sequenzennummern und ACK etc. mit im Spiel das hat ja bei NAT ja wiederrum keine Bedeutung.)
Richtig muss also bei NAT eigentlich PAT zwei Session pro Verbindung existieren:
Sind also beide NATs des Router von Client Netz und Server Netz in der Kommunikation beteiligt?!
Session des Router aus Client Netz:
öffnet für Client 192.168.1.5 den Port 1005 um eine Verbindung zu 89.123.123.123 zum Port 20 herzustellen
Session des Router aus Server Netz:
öffnet für Client 192.168.1.5 den Port 1006 (da dieser frei ist) und stellt eine Verbindung zu 89.123.123.123 mit Port 20 her. Nun ist die Verbindung hergestellt. Jetzt beginnt das Spiel von Vorne aber mit Port 21 und da die internen Router Ports 1005 und 1006 belegt sind wird einfach inkrementiert und so einfach immer weiter um eines erhöht?
Den Paket Flow habe ich mir angesehen aber wohl einfach nicht verstanden wo dort die Problematik ist bei FTP.
Also öffnet PAT diese Ports.
Nein, auch wieder falsch weil du den Paket Flow nicht angesehen hast. Client sagt dem Server über TCP 21 Command Port das er den passive Mode will. Server sagt ACK und öffnet keinen TCP 20 Port und wartet von sich aus auf den Client der dann TCP 20 öffnet. Nun gibt es auch eine gültige inbound NAT TCP 20 Session und alles ist gut.
Der Server wartet passiv, deshalb auch der Name passive Mode ! Groschen gefallen...??
Achso jetzt kennen ich den Weg vom passivem Mode. Du sagst der Server öffnet keinen TCP 20 Port aber damit ist der Router gemeint, nur so damit es zu keinen Missverständnissen kommt...
Die Sessiontabelle auf der NAT (PAT) ist somit nur mit einem einzigen Eintrag belegt bei aktiven Mode mit 2 da beide Client und Server über beide Ports gemeinsam kommunizieren?
Du sagtest weiter oben mal Port Forwarding wird bei FTP eingesetzt wo kommt den das zum Einsatz? Klar, im aktiven Mode aber wo und wie sieht der aus?
Also bleibt mir somit nichts anders übrig als Firewall deaktivieren?
Wenn du so einen billigen Schrottrouter hast dann ja. Ohne Firewall ist das aber ein Himmelfahrtskommando ! Kein normaler Mensch arbeitet so ungeschützt direkt am Internet !Zyxel kann mit Sicherheit passthrough. Ob Multisession oder nicht ist wieder einen andere Frage aber passthrough macht er mit Sicherheit. Das machen heutzutage sogar 12 Euro Router von TP-Link aus China.
Bisher habe ich halt nur um PPTP VPN zu machen die Firewall deaktiviert... Halt als Workarround
Du denkst also ich könnte mit Passthrough den VPN PPTP Traffic zu einem Router weiterleiten mit NAT (PAT) der GRE kann? Das habe ich ja eigentlich schon erster Zyxel Router der kein GRE kann und dann die Fritz.Box der kann das. Mein Windows-Server mit PPTP VPN fängt an der Fritz.Box.
Wie richte ich den dieses Passthrough ein?
Wie verhält sich das wenn ich anstelle der statischen NAT Weiterleitung von TCP 1123 für einen PPTP mit Port Forwarding auf GRE weiterleite?
Das geht gar nicht....Zuerstmal benutzt PPTP TCP 1723 und nicht 1123. Und du musst zwingend beide Protokollkomponenten weiterleiten, denn sonst kann PPTP logischerweise nicht funktionieren...klar !
Wie gesagt. Manche Dummrouter sind wenigstens so intelligent das sie, sofern du TCP 1723 weiterleitest, sie automatisch auch GRE auch weiterleiten. Ob das bei dir der Fall ist sagt dir das Handbuch oder...Versuch macht klug...
GRE ist wie gesagt ein eigenes Protokoll was man beim Port Forwarding entsprechend auswählen kann statt UDP oder TCP.
Hier mal ein Screenshot von der Einrichtung des Port Forwarding bei einer pfSense Firewall an der du sehen kannst welche Protokolle zur Auswahl stehen:
Jeder Router der das kann hat immer auch genau diese Auswahl Optionen !
Naja bei meinem Port Forwarding kann ich nur von Port zu Port da GRE keinen Port hat ist das ja gar nicht möglich das Stimmt. Also ich habe ja vor einigen Monaten mal den TCP Port 1723 geöffnet gehabt um PPTP VPN zu machen mit aktivierter Firewall stand im Logfile immer droped GRE. Als ich die Firewall deaktivierte klappte der Tunnel problemlos. Für mich heisst das er leitet GRE nicht weiter. Du siehst das, nehme ich an gleich wie ich oder?
Bei mir im Port Forwarding steht weder TCP noch UDP halt nur:
Da hat aber dann mit NAT nichts zu tun im Gegensatz zu Protokollen die eine Portnummer besitzen dort geht alles über NAT bzw. PAT. Als Beispiel HTTP
Per se richtig wenn du einzig nur die Outbound Richtung betrachtest.Inbound bleibt das Paket aber genauso an einem PAT Router hängen wie alle anderen auch.
Wie gesagt das betrifft natürlich nur die Passthrough Option wenn du mit Port Forwarding dursch NAT bzw. PAT Inbound durch willst, klar !
Steht den in diesem Dateninhalt z. B die IP-Adresse des Clients an welche die Session zugeteilt ist
Nein, nicht im Datenfeld aber im IP (L3) Header.die Chance erhält eine dieser 4 WAN-IP-Adressen zu erhalten?
Jepp...du hast es richtig erfasst !Aber was bringt das
Wenn z.B. 253 Mitarbeiter im Büro sitzen und jeder braucht hie und da mal ne 1:1 NAT Session aus welchem Grund auch immer.Man verhindert so lediglich ein Nailing dieser NAT Adressen wenn man derer nur wenige hat und die z.B. öffentlich sind.
Sowas kommt so gut wie immer nur bei sehr begrenzten öffentlichen IPs zum Einsatz.
Achso so funktioniert das.
Hättest du nur ein einziges Mal auf das Session Diagramm gesehen wären die Romane hier überflüssig gewesen und dann erst TCP 20 öffnen was wiederrum der Client bestätigen muss. Wieso "kein gültiger inbound TCP 20 Session"? Der Server bestätigt doch dies
Oh man...du bist aber schwer von KaPe...Er bestätigt das logischerweise auf dem Kommando Port 21 wo er auch das Kommando erhalten hat. Dann öffnet er den TCP 20 Datenport zum Client der dann an der PAT Firewall scheitert....siehe ==> Sessiondiagramm !!!
Richtig muss also bei NAT eigentlich PAT zwei Session pro Verbindung existieren:
Nein, das ist nur eine Besonderheit des FTP Protokolls. Protokolle die nur eine Session benutzen haben auch nur eine PAT Session.Guckst du hier:
http://kohnlehome.de/netz/Masquerading.swf
Es ist gaaanz einfach die Sache mit den 2 Ports bei FTP. Nur FTP (oder andere Protokolle die 2 Ports benutzen wie PPTP, IPsec, L2TP) kommt deshalb nicht über PAT wenn man denn den active Mode (FTP) nutzt. Eigentlich kinderleicht...
Für alle "normalen" Protokollen mit einem Port gilt das logischerweise nicht !Du sagst der Server öffnet keinen TCP 20 Port aber damit ist der Router gemeint,
Nein, Unsinn ! Siehe ==> Sessiondiagramm passive !!Client sagt dem Server das er den Datenport auf 2024 öffnent und initiert die Session (nicht der Server !) Da das ja wieder PAT Outbound ist..kein Problem.
Server akzeptiert eingehende Data Session auf 2024... Datentransfer beginnt...alles gut !
Wie gesagt....ganz einfach !
Bisher habe ich halt nur um PPTP VPN zu machen die Firewall deaktiviert...
Uuuuhhhh gruselig ! Da kann als normaler Internet User aber nicht mehr schlafen. Da machst du ja allen Hackern und Skript Kiddies Tür und Tor auf...sogar noch mit Einladung !Wie gesagt es muss nicht sein, es reicht wenn man in der FW einfach nur GRE Inbound zulässt und dem PAT zusätzlich ein Port Forwarding auf den PPTP Client konfiguriert.
2 ganz simple Konfig Schritte die in 1 Minute erledigt sind und PPTP MIT Firewall zum Fliegen bringen. Das GRE Forwarding kann man sich sogar ersparen wenn der Router bzw. die Firewall eben GRE Passthrough supportet was heute jeder Baumarkt Router kann.
erster Zyxel Router der kein GRE kann und dann die Fritz.Box der kann das. Mein Windows-Server mit PPTP VPN
Oha...das ist aber recht krank mit einer Router Kaskade.Logisch das du da 2mal GRE erlauben und Forwarden musst auf den Winblows Server.
Fragt man sich warum du so einen Unsinn machst und nicht gleich ein VPN auf deiner FritzBox einrichtest.
Die kann doch wunderbar VPN:
http://avm.de/service/vpn/uebersicht/
Bei dir hört sich das so ein bischen nach "Warum einfach machen wenns megaumständlich auch geht.." an ?!
Wenn du auch noch die überflüssige Kaskade entsorgst (was soll der tiefere Sinn davon sein ?) kann das ja ein gutes Netzwerk werden
Wie richte ich den dieses Passthrough ein?
Bei der FB ist das Kinderleicht: (siehe Screenshot hierVPNs einrichten mit PPTP
Beim Zyxel müsstest du mal das Modell posten, damit wir dann für dich das Handbuch lesen können
Naja bei meinem Port Forwarding kann ich nur von Port zu Port
Dann bist du Opfer einen Billigrouters...da kann dann auch ein noch so tolles Forum nix mehr machen.Wie bereits gesagt: Warum der Unsinn und nicht VPN auf die FB und alles ist gut ! Keep it simple stupid !
den TCP Port 1723 geöffnet gehabt um PPTP VPN zu machen mit aktivierter Firewall stand im Logfile immer droped GRE
Klarer Fall von billigem Dummrouter... Besser schnell entsorgen sowas.Als ich die Firewall deaktivierte klappte der Tunnel problemlos.
Welch Wunder... !! Wenn du bei der Burg die Klappbrücke runterlässt kann auch jeder passieren !! Nachdenken...! Customize die Firewall und dann klappt das. Kannst du sie nicht customizen Firmware Update. Hilft das nix Router wegschmeissen.
Eigentlich doch einfach, oder ?!
Bei mir im Port Forwarding steht weder TCP noch UDP
Klarer Fall von ganz billigem Dummrouter... ==> Sofort entsorgen.Fazit: Du hast ja als Vorbild die FB. Die kanns ja als einfacher Plaste Elaste Consumerrouter auch und das sollte immer der Maßstab für gute andere System sein.
Zitat von @aqui:
Inbound bleibt das Paket aber genauso an einem PAT Router hängen wie alle anderen auch.
Wie gesagt das betrifft natürlich nur die Passthrough Option wenn du mit Port Forwarding dursch NAT bzw. PAT Inbound durch willst, klar !
Da hat aber dann mit NAT nichts zu tun im Gegensatz zu Protokollen die eine Portnummer besitzen dort geht alles über NAT bzw. PAT. Als Beispiel HTTP
Per se richtig wenn du einzig nur die Outbound Richtung betrachtest.Inbound bleibt das Paket aber genauso an einem PAT Router hängen wie alle anderen auch.
Wie gesagt das betrifft natürlich nur die Passthrough Option wenn du mit Port Forwarding dursch NAT bzw. PAT Inbound durch willst, klar !
Also NAT kann und wird immer eingesetzt ob jetzt ein Port oder Protokollnummer existiert oder nicht spielt doch keine Rolle? Bei PAT brauchts einen Port wenn ein Datenpaket ohne Port durch einen PAT-Router will wird PAT ausserkraft gesetzt dann kommt Sessionhandling nach Protokollnummer zum Einsatz? Wie stellt man das ein das Pakete ohne Port nicht durch PAT Router sollen sondern direkt ankommen?
Verstehe nicht wieso bleibt Inbound das Paket hängen? Was hat das jetzt mit Passthrough zu tun?
Weiter verstehe ich nicht genau wenn Port Forwarding eingesetzt werden muss z.B bei aktivem FTP? Port Forwarding ist doch eine Sicherheitslücke da dann ständig ein Port offen ist wie du sagst. Wie löst man das? Aber VPN mit PPTP besitzt doch auch zwei Protokolle wieso also nur bei aktivem FTP wo man Port Forwarding benutzten muss?
Steht den in diesem Dateninhalt z. B die IP-Adresse des Clients an welche die Session zugeteilt ist
Nein, nicht im Datenfeld aber im IP (L3) Header.Die Informationen sind doch bereits in der PAT-Tabelle welches die Quell bzw. Ziel IP ist. Wozu dann die Unterscheidung zwischen NAT oder PAT und Sessionhandling bei Portlosen Protokollen? Versteh einfach nicht wie das funktionieren soll....
Kannst du mir bitte noch die Fragen zum Thema "mit Pooling" beantworten:
Also das verstehe ich schon das NAT und PPTP nicht das Gleiche ist.
Ich weiss ja vorher, dass ich z. B 4 Private IP-Adressen habe und diese zu den WAN-IP-Adressen weiterleiten will, sodass meine 4 Server online sein können das Gleichzeitig. Somit kann ich das doch auch gleich als statisches NAT also ohne Pooling realisieren? Die vier Server haben ja eine statische IP-Adresse somit wird auch die Zuordnung der Sessions immer gleich bleiben wie beim statischen NAT?
Aber was bringt das
Wenn z.B. 253 Mitarbeiter im Büro sitzen und jeder braucht hie und da mal ne 1:1 NAT Session aus welchem Grund auch immer.Man verhindert so lediglich ein Nailing dieser NAT Adressen wenn man derer nur wenige hat und die z.B. öffentlich sind.
Sowas kommt so gut wie immer nur bei sehr begrenzten öffentlichen IPs zum Einsatz.
Verstehe ich immer noch nicht. Es sind doch nur Server die eine 1:1 NAT habe müssen um so übers Internet bzw. zwei Netzte miteinander verbunden zu sein wozu gibt Pooling? Jeder Server braucht ja eine private IP-Adresse und eine öffentliche IP-Adresse beim Pooling bekommt ja mal Server A eine WAN-IP um durch die NAT gehen zu dürfen mal Server B während dieser Zeit ist ja Server A nicht erreichbar da die WAN-IP-Adresse für Server B reserviert ist.
So stelle ich mir Pooling vor:
Pooling stell ich mir wie ein DHCP-Server vor der Adresse verteilt statt ein DHCP-Server kann ich ja auch statische IP-Adresse verteilen was dann wie statisches NAT wäre?
und dann erst TCP 20 öffnen was wiederrum der Client bestätigen muss. Wieso "kein gültiger inbound TCP 20 Session"? Der Server bestätigt doch dies
Oh man...du bist aber schwer von KaPe...Er bestätigt das logischerweise auf dem Kommando Port 21 wo er auch das Kommando erhalten hat. Dann öffnet er den TCP 20 Datenport zum Client der dann an der PAT Firewall scheitert....siehe ==> Sessiondiagramm !!!
Habe mir das Diagramm nochmals angesehen auch noch eine andere Seite zur Hilfe genommen https://faq.hosteurope.ch/?cpid=2123
Das Problem beim aktivem FTP ist, dass auf Seite des Clients eine eingehende Verbindung von der NAT-Firewall abgelehnt wird. Wieso ist das so? Beim passiven FTP baut nicht der Server sondern der Client die Verbindung zum Server her. Wieso klappts auch diesen Weg? In deinem Diagramm wird im passivem Mode ein neuer Port auf der Seite des Servers geöffnet "2024".
Eventuell weil zwei Verbindungen bestehen?
Richtig muss also bei NAT eigentlich PAT zwei Session pro Verbindung existieren:
Nein, das ist nur eine Besonderheit des FTP Protokolls. Protokolle die nur eine Session benutzen haben auch nur eine PAT Session.Guckst du hier:
http://kohnlehome.de/netz/Masquerading.swf
Verstehe ich dich richtig, dass nur FTP in der PAT 2 Sessions Einträge haben alle anderen z.B Verbindung mit PPTP VPN nicht? Obwohl dort auch GRE und TCP zum Einsatz kommt?
Das Diagramm von kohnlehome.de habe ich mir letzte Woche bereits angesehen. Nun erst verstehe ich wie das genau Funktioniert mit dem Diagramm... Sieht spannend aus
.Bei NAT ist es die genau gleiche Funktionsweise oder?
Es ist gaaanz einfach die Sache mit den 2 Ports bei FTP. Nur FTP (oder andere Protokolle die 2 Ports benutzen wie PPTP, IPsec, L2TP) kommt deshalb nicht über PAT wenn man denn den active Mode (FTP) nutzt. Eigentlich kinderleicht...
Für alle "normalen" Protokollen mit einem Port gilt das logischerweise nicht !Wieso ist das den so müsste doch auch gehen halt mit zwei statt einer PAT-Session? Wie umgehe ich das den? Ich erinnere mich, dass in einer deiner Anleitungen stand, man müsste unter der Fritz.Box GRE und TCP freigeben für PPTP dann geht alles wenn ich mich richtig erinnere. Mit Port Forwarding kann ich das Wichtigere der beiden Protokolle durchreichen lassen auch das habe ich mir gemerkt.
Du sagst der Server öffnet keinen TCP 20 Port aber damit ist der Router gemeint,
Nein, Unsinn ! Siehe ==> Sessiondiagramm passive !!Client sagt dem Server das er den Datenport auf 2024 öffnent und initiert die Session (nicht der Server !) Da das ja wieder PAT Outbound ist..kein Problem.
Server akzeptiert eingehende Data Session auf 2024... Datentransfer beginnt...alles gut !
Wie gesagt....ganz einfach !
Was ich noch nicht verstehe ist wieso die Verbindung klappt wenn der Client die Daten-Verbindung zum Server initalisiert also (passiv Mode) im Aktiven Mode sollte der der Server die Data-Initalisierung machen dort klappt ja nicht wieso auch immer?...
Bisher habe ich halt nur um PPTP VPN zu machen die Firewall deaktiviert...
Uuuuhhhh gruselig ! Da kann als normaler Internet User aber nicht mehr schlafen. Da machst du ja allen Hackern und Skript Kiddies Tür und Tor auf...sogar noch mit Einladung !Wie gesagt es muss nicht sein, es reicht wenn man in der FW einfach nur GRE Inbound zulässt und dem PAT zusätzlich ein Port Forwarding auf den PPTP Client konfiguriert.
2 ganz simple Konfig Schritte die in 1 Minute erledigt sind und PPTP MIT Firewall zum Fliegen bringen. Das GRE Forwarding kann man sich sogar ersparen wenn der Router bzw. die Firewall eben GRE Passthrough supportet was heute jeder Baumarkt Router kann.
Ja, ich kenne die Auswirkungen einer deaktivierten Firewall bei einem Router nicht.
Ok, ich kann in meiner Firewall nur Dienste blockieren aber explizit zulassen leider nicht. Das verunmöglicht mal wieder PPTP VPN
Du sagst es reicht ein Port Forwarding einzurichten auf den PPTP Client. Dann muss ich jeden einzelnen Client welcher mit PPTP VPN arbeiten soll in die Port Forwarding tun. Kann mir nicht vorstellen wie ich das mache. Meine Vorstellung:
Anhand meiner Konfig wie würde ich Port Forwarding einstellen?
Eingehender Anschluss: IP des Clients und öffentliche Port z.B 6000 Auslösender Anschluss IP-Adresse des PPTP VPN Servers und dort wiederrum den Port 5000?
Du sagtest weiter oben mal Port Forwarding wird bei FTP eingesetzt wo kommt den das zum Einsatz? Klar, im aktiven Mode aber wo und wie sieht der aus?
erster Zyxel Router der kein GRE kann und dann die Fritz.Box der kann das. Mein Windows-Server mit PPTP VPN
Oha...das ist aber recht krank mit einer Router Kaskade.Logisch das du da 2mal GRE erlauben und Forwarden musst auf den Winblows Server.
Fragt man sich warum du so einen Unsinn machst und nicht gleich ein VPN auf deiner FritzBox einrichtest.
Die kann doch wunderbar VPN:
http://avm.de/service/vpn/uebersicht/
Bei dir hört sich das so ein bischen nach "Warum einfach machen wenns megaumständlich auch geht.." an ?!
Wenn du auch noch die überflüssige Kaskade entsorgst (was soll der tiefere Sinn davon sein ?) kann das ja ein gutes Netzwerk werden
VPN von Server ZyXel zu Fritz.Box ist auch eine Idee. Wieso klappt das den nicht mit zwei normalen Router die hintereinander geschallten sind das ist doch schnell erledigt wieso soviele Probleme? Ist mir einfach unverständlich...
Du schlägst vor intern im Netzwerk VPN zu benutzten? Somit ohne Kaskade? Aber der Router muss ja so oder so eine Kaskade sein sonst kann keine Verbindung zum Gerät hergestellt werden. Die Fritz.Box braucht ja zwingend eine Verbindung zum Core Router (Zyxel) somit eine Kaskade.
Wie richte ich den dieses Passthrough ein?
Bei der FB ist das Kinderleicht: (siehe Screenshot hierVPNs einrichten mit PPTP
Beim Zyxel müsstest du mal das Modell posten, damit wir dann für dich das Handbuch lesen können
Du sagst ich könnte mit PPTP VPN Traffic auch weiterleiten? Aber das klappt ja nicht wenn der ZYXEL kein Port Forwarding für GRE akzeptiert wie auch
die Firewall kein GRE durchlassen kann? Modell ZYXEL NBG460N
Naja bei meinem Port Forwarding kann ich nur von Port zu Port
Dann bist du Opfer einen Billigrouters...da kann dann auch ein noch so tolles Forum nix mehr machen.Wie bereits gesagt: Warum der Unsinn und nicht VPN auf die FB und alles ist gut ! Keep it simple stupid !
VPN soll ja auf mein Fritz.Box (Mein Testnetz) dahinter befindet sich mein produktives Netz mit der ZYXEL Router. Aber dort ist ja das Problem?!
Als ich die Firewall deaktivierte klappte der Tunnel problemlos.
Welch Wunder... !! Wenn du bei der Burg die Klappbrücke runterlässt kann auch jeder passieren !! Nachdenken...! Customize die Firewall und dann klappt das. Kannst du sie nicht customizen Firmware Update. Hilft das nix Router wegschmeissen.
Eigentlich doch einfach, oder ?!
customizen Firmware meinst du wohl eine open Firmware wie DD-WRT das kann die natürlich auch wieder nicht habe ich schon abgeklärt.
"Customize" heist sie richtig und sicher EINRICHTEN sprich konfigurieren !
Wäre dem nicht so könnte ja jeder Hansel von außen alle deinen lokalen Geräte erreichen !
Nur wenn du von innen was initiert hast kann auch was zurückkommen. Von außen kann man nichts initiieren...das bleibt hängen..ganz einfach
Keine Session, keine Kekse...
Andere Dienste wie Telnet, SSH, HTTP usw. haben nur einen TCP Port.
Baut der Server aber ohne Inbound Session die Session selber auf, bleibt er an der NAT Firewall hängen da ja keine bestehende Client Session besteht...schon mehrfach gesagt oben.
Sprich überall wo von außen FTP Zugriff über das NAT gemacht werden soll.
Aber...es gibt ja noch OpenVPN. Nutzt nur einen Port UDP 1194 und ist ein SSL Protokoll was alle diese Probleme von PPTP nicht hat !!!
Du sagst ich könnte mit PPTP VPN Traffic auch weiterleiten? Aber das klappt ja nicht wenn der ZYXEL kein Port Forwarding für GRE akzeptiert
Dann hast du die falsche HW gekauft !! Dein Fehler !eine eingehende Verbindung von der NAT-Firewall abgelehnt wird. Wieso ist das so?
Ist doch logisch. Zu der eingehenden TCP 20 Session gibt es keine korrespondierende Outbound Session mit gesetztem ACK Bit. Deshalb sagt der PAT Prozess: Njet...du kommst hier nicht rein.Wäre dem nicht so könnte ja jeder Hansel von außen alle deinen lokalen Geräte erreichen !
Nur wenn du von innen was initiert hast kann auch was zurückkommen. Von außen kann man nichts initiieren...das bleibt hängen..ganz einfach
Keine Session, keine Kekse...
Verstehe ich dich richtig, dass nur FTP in der PAT 2 Sessions Einträge haben alle anderen z.B Verbindung mit PPTP VPN nicht? Obwohl dort auch GRE und TCP zum Einsatz kommt?
Ja, FTP besteht ja aus 2 Ports TCP 20 und 21. PPTP nur aus einem TCP 1723 und dem sessionlosen GRE Protokoll.Andere Dienste wie Telnet, SSH, HTTP usw. haben nur einen TCP Port.
wieso die Verbindung klappt wenn der Client die Daten-Verbindung zum Server initalisiert also (passiv Mode)
Ist doch klar.... Baut der Client auf gibt es eine valide Session im PAT und der Server der antwortet wird durchgelassen.Baut der Server aber ohne Inbound Session die Session selber auf, bleibt er an der NAT Firewall hängen da ja keine bestehende Client Session besteht...schon mehrfach gesagt oben.
Ja, ich kenne die Auswirkungen einer deaktivierten Firewall bei einem Router nicht.
Willst du wohl auch besser nie kennenlernen...?!Port Forwarding wird bei FTP eingesetzt wo kommt den das zum Einsatz?
Z.B. wenn Oma Grete bei Enkel Willi die Fotos vom Geburtstag von Willis NAS runterladen will von außen.Sprich überall wo von außen FTP Zugriff über das NAT gemacht werden soll.
VPN von Server ZyXel zu Fritz.Box ist auch eine Idee. Wieso klappt das den nicht mit zwei normalen Router die hintereinander geschallten sind das ist doch schnell erledigt wieso soviele Probleme? Ist mir einfach unverständlich...
Weil wie mehrfach oben gesagt viele Router Schritt sind und GRE nicht forwarden könne, damit scheitert dann PPTP sofort.Aber...es gibt ja noch OpenVPN. Nutzt nur einen Port UDP 1194 und ist ein SSL Protokoll was alle diese Probleme von PPTP nicht hat !!!
Du schlägst vor intern im Netzwerk VPN zu benutzten?
Igitt...nee das wäre ja Blödsinn. Da hast du was missverstanden.
Hat NAT die gleiche Funktionsweise wie PAT anstatt Ports halt nur externe IP-Adressen? Kennst du ein Diagramm das den Weg aufzeigt wie bei IP-Masquarading?
Inbound bleibt das Paket aber genauso an einem PAT Router hängen wie alle anderen auch.
Wie gesagt das betrifft natürlich nur die Passthrough Option wenn du mit Port Forwarding dursch NAT bzw. PAT Inbound durch willst, klar !
Also NAT kann und wird immer eingesetzt ob jetzt ein Port oder Protokollnummer existiert oder nicht spielt doch keine Rolle? Bei PAT brauchts einen Port wenn ein Datenpaket ohne Port durch einen PAT-Router will wird PAT ausserkraft gesetzt dann kommt Sessionhandling nach Protokollnummer zum Einsatz? Wie stellt man das ein das Pakete ohne Port nicht durch PAT Router sollen sondern direkt ankommen?
Verstehe nicht wieso bleibt Inbound das Paket hängen? Was hat das jetzt mit Passthrough zu tun?
Die Informationen sind doch bereits in der PAT-Tabelle welches die Quell bzw. Ziel IP ist. Wozu dann die Unterscheidung zwischen NAT oder PAT und Sessionhandling bei Portlosen Protokollen? Versteh einfach nicht wie das funktionieren soll....
Kannst du mir bitte noch die Fragen zum Thema "mit Pooling" beantworten:
Also das verstehe ich schon das NAT und PPTP nicht das Gleiche ist.
Ich weiss ja vorher, dass ich z. B 4 Private IP-Adressen habe und diese zu den WAN-IP-Adressen weiterleiten will, sodass meine 4 Server online sein können das Gleichzeitig. Somit kann ich das doch auch gleich als statisches NAT also ohne Pooling realisieren? Die vier Server haben ja eine statische IP-Adresse somit wird auch die Zuordnung der Sessions immer gleich bleiben wie beim statischen NAT?
Man verhindert so lediglich ein Nailing dieser NAT Adressen wenn man derer nur wenige hat und die z.B. öffentlich sind.
Sowas kommt so gut wie immer nur bei sehr begrenzten öffentlichen IPs zum Einsatz.
Verstehe ich immer noch nicht. Es sind doch nur Server die eine 1:1 NAT habe müssen um so übers Internet bzw. zwei Netzte miteinander verbunden zu sein wozu gibt Pooling? Jeder Server braucht ja eine private IP-Adresse und eine öffentliche IP-Adresse beim Pooling bekommt ja mal Server A eine WAN-IP um durch die NAT gehen zu dürfen mal Server B während dieser Zeit ist ja Server A nicht erreichbar da die WAN-IP-Adresse für Server B reserviert ist.
So stelle ich mir Pooling vor:
Pooling stell ich mir wie ein DHCP-Server vor der Adresse verteilt statt ein DHCP-Server kann ich ja auch statische IP-Adresse verteilen was dann wie statisches NAT wäre?
Du meinst mit Passthrough die eigentliche Router konfiguration für PPTP VPN? Also das geht ja nur bei einem Router der auch Port Forwarding kann oder die richtigen Ports bei PAT (NAT) durchreichen?!
Wäre dem nicht so könnte ja jeder Hansel von außen alle deinen lokalen Geräte erreichen !
Nur wenn du von innen was initiert hast kann auch was zurückkommen. Von außen kann man nichts initiieren...das bleibt hängen..ganz einfach
Keine Session, keine Kekse...
Verstehe ich nicht, wie meinst du das mit "zu der eingehenden TCP 20 Session gibt es keine korrespondierende Outbound Session"...? Das ist doch so weil der Server Outbound eine Session aufbaut (Server will von Client was) und der Server nur noch ACK (alles ok ich bestätige die Verbindung) muss? Also ist doch eine gültige Session vorhanden? Verstehe nicht wieso du sagst es gäbe kein outbound Session?
Beim Aktiven FTP will der Server beim Client eine Verbindung um die Daten zu übertragen initiieren. Beim Passiven FTP initiiert der Client und der Server akzeptiert? Ich glaube so läuft das oder? Aber nun wird ja auf der Seite des Servers von aussen eine Verbindung initiiert wie du sagst das ist ja nicht gut?
Baut der Server aber ohne Inbound Session die Session selber auf, bleibt er an der NAT Firewall hängen da ja keine bestehende Client Session besteht...schon mehrfach gesagt oben.
Also muss immer erst eine eingehende Verbindung existieren bevor es eine ausgehende gibt? Aber im aktiven FTP gibt auf der Seite des Client auch zuerst eine eingehende dann eine Ausgehende Verbindung? Also existiert doch eine gültige Session? Also hat der PAT-Router beim Client eine gültige Session und der PAT-Router auf dem Server eine ungültige?
Sprich überall wo von außen FTP Zugriff über das NAT gemacht werden soll.
Also im aktiven Mode ist dieses Szenario gedacht? Da ja im passiven eine Verbindung ohne Umwege funktioniert? Mir ist nur noch nicht ganz klar wie dieses Port Forwarding funktioniert.... Ist das ein statischer Ersatz für das PAT? Damit will ich sagen statt, dass die PAT eine Session aufbaut wird diejenige genommen welche im Port Forwarding konfiguriert wurde?
Anhand meiner Konfig wie würde ich Port Forwarding einstellen?
Eingehender Anschluss: IP des Clients und öffentliche Port z.B 6000 Auslösender Anschluss IP-Adresse des PPTP VPN Servers und dort wiederrum den Port 5000?
Aber...es gibt ja noch OpenVPN. Nutzt nur einen Port UDP 1194 und ist ein SSL Protokoll was alle diese Probleme von PPTP nicht hat !!!
Mein Problem bezieht sich ja auch darauf auf diese Router-Kaskade. Am ZyXEL Router hängt die Fritz.Box nun bevor ich diese Kaskade hatte konnte ich per RDP auf meinen Windows-Server zugreifen seit ich diese Router Kaskade habe geht nix mehr. Ich kann aus dem Internet nicht mehr auf RDP zugreifen. Ich weiss nicht wie ich dieses Problem lösen soll? Du sagtest ja ich müsste bei der Fritz.Box NAT deaktivieren dann würde alles wieder gehen oder? Oder irgend ein verbindungsloses Routing statt NAT. Ich weiss nur nicht was du damit meinst.
Wie hast du den das gemeint?
"
Oha...das ist aber recht krank mit einer Router Kaskade.
Logisch das du da 2mal GRE erlauben und Forwarden musst auf den Winblows Server.
Fragt man sich warum du so einen Unsinn machst und nicht gleich ein VPN auf deiner FritzBox einrichtest.
Die kann doch wunderbar VPN:
http://avm.de/service/vpn/uebersicht/
Bei dir hört sich das so ein bischen nach "Warum einfach machen wenns megaumständlich auch geht.." an ?!
Wenn du auch noch die überflüssige Kaskade entsorgst (was soll der tiefere Sinn davon sein ?) kann das ja ein gutes Netzwerk werden
"
Da hat aber dann mit NAT nichts zu tun im Gegensatz zu Protokollen die eine Portnummer besitzen dort geht alles über NAT bzw. PAT. Als Beispiel HTTP
Per se richtig wenn du einzig nur die Outbound Richtung betrachtest.Inbound bleibt das Paket aber genauso an einem PAT Router hängen wie alle anderen auch.
Wie gesagt das betrifft natürlich nur die Passthrough Option wenn du mit Port Forwarding dursch NAT bzw. PAT Inbound durch willst, klar !
Also NAT kann und wird immer eingesetzt ob jetzt ein Port oder Protokollnummer existiert oder nicht spielt doch keine Rolle? Bei PAT brauchts einen Port wenn ein Datenpaket ohne Port durch einen PAT-Router will wird PAT ausserkraft gesetzt dann kommt Sessionhandling nach Protokollnummer zum Einsatz? Wie stellt man das ein das Pakete ohne Port nicht durch PAT Router sollen sondern direkt ankommen?
Verstehe nicht wieso bleibt Inbound das Paket hängen? Was hat das jetzt mit Passthrough zu tun?
Steht den in diesem Dateninhalt z. B die IP-Adresse des Clients an welche die Session zugeteilt ist
Nein, nicht im Datenfeld aber im IP (L3) Header.Die Informationen sind doch bereits in der PAT-Tabelle welches die Quell bzw. Ziel IP ist. Wozu dann die Unterscheidung zwischen NAT oder PAT und Sessionhandling bei Portlosen Protokollen? Versteh einfach nicht wie das funktionieren soll....
Kannst du mir bitte noch die Fragen zum Thema "mit Pooling" beantworten:
Also das verstehe ich schon das NAT und PPTP nicht das Gleiche ist.
Ich weiss ja vorher, dass ich z. B 4 Private IP-Adressen habe und diese zu den WAN-IP-Adressen weiterleiten will, sodass meine 4 Server online sein können das Gleichzeitig. Somit kann ich das doch auch gleich als statisches NAT also ohne Pooling realisieren? Die vier Server haben ja eine statische IP-Adresse somit wird auch die Zuordnung der Sessions immer gleich bleiben wie beim statischen NAT?
Aber was bringt das
Wenn z.B. 253 Mitarbeiter im Büro sitzen und jeder braucht hie und da mal ne 1:1 NAT Session aus welchem Grund auch immer.Man verhindert so lediglich ein Nailing dieser NAT Adressen wenn man derer nur wenige hat und die z.B. öffentlich sind.
Sowas kommt so gut wie immer nur bei sehr begrenzten öffentlichen IPs zum Einsatz.
Verstehe ich immer noch nicht. Es sind doch nur Server die eine 1:1 NAT habe müssen um so übers Internet bzw. zwei Netzte miteinander verbunden zu sein wozu gibt Pooling? Jeder Server braucht ja eine private IP-Adresse und eine öffentliche IP-Adresse beim Pooling bekommt ja mal Server A eine WAN-IP um durch die NAT gehen zu dürfen mal Server B während dieser Zeit ist ja Server A nicht erreichbar da die WAN-IP-Adresse für Server B reserviert ist.
So stelle ich mir Pooling vor:
Pooling stell ich mir wie ein DHCP-Server vor der Adresse verteilt statt ein DHCP-Server kann ich ja auch statische IP-Adresse verteilen was dann wie statisches NAT wäre?
Du sagst ich könnte mit PPTP VPN Traffic auch weiterleiten? Aber das klappt ja nicht wenn der ZYXEL kein Port Forwarding für GRE akzeptiert
Dann hast du die falsche HW gekauft !! Dein Fehler !Du meinst mit Passthrough die eigentliche Router konfiguration für PPTP VPN? Also das geht ja nur bei einem Router der auch Port Forwarding kann oder die richtigen Ports bei PAT (NAT) durchreichen?!
eine eingehende Verbindung von der NAT-Firewall abgelehnt wird. Wieso ist das so?
Ist doch logisch. Zu der eingehenden TCP 20 Session gibt es keine korrespondierende Outbound Session mit gesetztem ACK Bit. Deshalb sagt der PAT Prozess: Njet...du kommst hier nicht rein.Wäre dem nicht so könnte ja jeder Hansel von außen alle deinen lokalen Geräte erreichen !
Nur wenn du von innen was initiert hast kann auch was zurückkommen. Von außen kann man nichts initiieren...das bleibt hängen..ganz einfach
Keine Session, keine Kekse...
Verstehe ich nicht, wie meinst du das mit "zu der eingehenden TCP 20 Session gibt es keine korrespondierende Outbound Session"...? Das ist doch so weil der Server Outbound eine Session aufbaut (Server will von Client was) und der Server nur noch ACK (alles ok ich bestätige die Verbindung) muss? Also ist doch eine gültige Session vorhanden? Verstehe nicht wieso du sagst es gäbe kein outbound Session?
Beim Aktiven FTP will der Server beim Client eine Verbindung um die Daten zu übertragen initiieren. Beim Passiven FTP initiiert der Client und der Server akzeptiert? Ich glaube so läuft das oder? Aber nun wird ja auf der Seite des Servers von aussen eine Verbindung initiiert wie du sagst das ist ja nicht gut?
wieso die Verbindung klappt wenn der Client die Daten-Verbindung zum Server initalisiert also (passiv Mode)
Ist doch klar.... Baut der Client auf gibt es eine valide Session im PAT und der Server der antwortet wird durchgelassen.Baut der Server aber ohne Inbound Session die Session selber auf, bleibt er an der NAT Firewall hängen da ja keine bestehende Client Session besteht...schon mehrfach gesagt oben.
Also muss immer erst eine eingehende Verbindung existieren bevor es eine ausgehende gibt? Aber im aktiven FTP gibt auf der Seite des Client auch zuerst eine eingehende dann eine Ausgehende Verbindung? Also existiert doch eine gültige Session? Also hat der PAT-Router beim Client eine gültige Session und der PAT-Router auf dem Server eine ungültige?
Port Forwarding wird bei FTP eingesetzt wo kommt den das zum Einsatz?
Z.B. wenn Oma Grete bei Enkel Willi die Fotos vom Geburtstag von Willis NAS runterladen will von außen.Sprich überall wo von außen FTP Zugriff über das NAT gemacht werden soll.
Also im aktiven Mode ist dieses Szenario gedacht? Da ja im passiven eine Verbindung ohne Umwege funktioniert? Mir ist nur noch nicht ganz klar wie dieses Port Forwarding funktioniert.... Ist das ein statischer Ersatz für das PAT? Damit will ich sagen statt, dass die PAT eine Session aufbaut wird diejenige genommen welche im Port Forwarding konfiguriert wurde?
Wie gesagt es muss nicht sein, es reicht wenn man in der FW einfach nur GRE Inbound zulässt und dem PAT zusätzlich ein Port Forwarding auf den PPTP Client konfiguriert.
2 ganz simple Konfig Schritte die in 1 Minute erledigt sind und PPTP MIT Firewall zum Fliegen bringen. Das GRE Forwarding kann man sich sogar ersparen wenn der Router bzw. die Firewall eben GRE Passthrough supportet was heute jeder Baumarkt Router kann.
2 ganz simple Konfig Schritte die in 1 Minute erledigt sind und PPTP MIT Firewall zum Fliegen bringen. Das GRE Forwarding kann man sich sogar ersparen wenn der Router bzw. die Firewall eben GRE Passthrough supportet was heute jeder Baumarkt Router kann.
Anhand meiner Konfig wie würde ich Port Forwarding einstellen?
Eingehender Anschluss: IP des Clients und öffentliche Port z.B 6000 Auslösender Anschluss IP-Adresse des PPTP VPN Servers und dort wiederrum den Port 5000?
VPN von Server ZyXel zu Fritz.Box ist auch eine Idee. Wieso klappt das den nicht mit zwei normalen Router die hintereinander geschallten sind das ist doch schnell erledigt wieso soviele Probleme? Ist mir einfach unverständlich...
Weil wie mehrfach oben gesagt viele Router Schritt sind und GRE nicht forwarden könne, damit scheitert dann PPTP sofort.Aber...es gibt ja noch OpenVPN. Nutzt nur einen Port UDP 1194 und ist ein SSL Protokoll was alle diese Probleme von PPTP nicht hat !!!
Mein Problem bezieht sich ja auch darauf auf diese Router-Kaskade. Am ZyXEL Router hängt die Fritz.Box nun bevor ich diese Kaskade hatte konnte ich per RDP auf meinen Windows-Server zugreifen seit ich diese Router Kaskade habe geht nix mehr. Ich kann aus dem Internet nicht mehr auf RDP zugreifen. Ich weiss nicht wie ich dieses Problem lösen soll? Du sagtest ja ich müsste bei der Fritz.Box NAT deaktivieren dann würde alles wieder gehen oder? Oder irgend ein verbindungsloses Routing statt NAT. Ich weiss nur nicht was du damit meinst.
Du schlägst vor intern im Netzwerk VPN zu benutzten?
Igitt...nee das wäre ja Blödsinn. Da hast du was missverstanden.Wie hast du den das gemeint?
"
Oha...das ist aber recht krank mit einer Router Kaskade.
Logisch das du da 2mal GRE erlauben und Forwarden musst auf den Winblows Server.
Fragt man sich warum du so einen Unsinn machst und nicht gleich ein VPN auf deiner FritzBox einrichtest.
Die kann doch wunderbar VPN:
http://avm.de/service/vpn/uebersicht/
Bei dir hört sich das so ein bischen nach "Warum einfach machen wenns megaumständlich auch geht.." an ?!
Wenn du auch noch die überflüssige Kaskade entsorgst (was soll der tiefere Sinn davon sein ?) kann das ja ein gutes Netzwerk werden
"
Wozu dann die Unterscheidung zwischen NAT oder PAT und Sessionhandling bei Portlosen Protokollen? Versteh einfach nicht wie das funktionieren soll....
Es gibt dort die Unterscheidung auch nicht. PAT kann ja logischerweise niemals mit portlosen Protokollen funktionieren, denn es basiert ja selber auf Ports. Da klappt also nur NAT.Also das verstehe ich schon das NAT und PPTP nicht das Gleiche ist.
Puuhhh, jetzt schwadronierst du im freien Fall !! Das eine hat mit dem anderen nicht das Geringste zu tun. Eine verfahren und ein Protokoll ist so wie Fisch und Fahrrad...Du meinst mit Passthrough die eigentliche Router konfiguration für PPTP VPN? Also das geht ja nur bei einem Router der auch Port Forwarding kann oder die richtigen Ports bei PAT (NAT) durchreichen?!
Exakt richtig !Verstehe ich nicht, wie meinst du das mit "zu der eingehenden TCP 20 Session gibt es keine korrespondierende Outbound Session"...?
Ohh mann du bist aber auch schwer von Kapee !!- Client öffnet auf TCP 21 (Kommando Port) eine Session zum Server. Da outbound geht die sauber durchs PAT und hat einen Session Table eintrag.
- Das ACK Paket des Servers kommt so auch zurück zum Client (TCP 21)
- Nun sagt der Client über TCP 21 der Server soll ihm eine Datei schicken (GET Kommando)
- Der Server bestätigt das wieder über den Kommando Port 21
- Jetzt sendet der Server die Datei über eine TCP 20 Session die ER zum Client eröffnet.
- Da der Client aber niemals eine TCP 20 Session eröffnet hat gibts auch logischerweise kein in der PAT Session Table. Folglich weist der PAT Prozess diese TCP 20 inbound Session ab. Aus die Maus.. Wie auch ALLE anderen Sessions die von außen initiiert werden.
Also muss immer erst eine eingehende Verbindung existieren bevor es eine ausgehende gibt?
Aus Sichtweise lokales LAN nach WAN/Internet ja, genau so ist es. Siehe oben...Anhand meiner Konfig wie würde ich Port Forwarding einstellen?
Frage kann man nicht beantworten wenn du nicht sagst für WAS (Protokoll der Anwendung) !bevor ich diese Kaskade hatte konnte ich per RDP auf meinen Windows-Server zugreifen seit ich diese Router Kaskade habe geht nix mehr.
Klar weil du vermutlich das Port Forwarding falsch eingestellt hast.Du sagtest ja ich müsste bei der Fritz.Box NAT deaktivieren dann würde alles wieder gehen oder?
Nein, Unsinn, muss man nicht und geht bei der FB auch gar nicht weil nicht supportet dort.Ohne VPN geht das so:
- Port Forwarding an der Fritzbox eingehend (Internet) Port TCP 3389 auf die WAN IP des Zyxels forwarden (diese sollte statisch sein)
- Port Forwarding am Zyxel eingehend WAN Port TCP 3389 auf die IP des Servers forwarden.
- Firewall im Server so einstellen das die fremde IPs für TCP 3389 passieren lässt
- Fertisch
- Port Forwarding an der Fritzbox eingehend (Internet) Port TCP 1723 und GRE Protokoll 47 auf die WAN IP des Zyxels forwarden (diese sollte statisch sein)
- Port Forwarding am Zyxel eingehend WAN Port TCP 1723 und GRE Protokoll 47 auf die IP des Servers forwarden.
- Firewall im Server so einstellen das die fremde IPs für TCP 1723 und GRE Protokoll 47 passieren lässt
- Fertisch
- Besser: VPN per Port Forwarding durch die FB schleifen und auf dem Zyxel terminieren wenn der VPNs terminieren kann wie die FB. Auf der FB terminieren geht auch aber dann musst du wieder Port Forwarden auf dem Zyxel...zu umständlich.
Kannst du mir bitte folgende Frage beantworten:
Hat NAT die gleiche Funktionsweise wie PAT anstatt Ports halt nur externe IP-Adressen? Kennst du ein Diagramm das den Weg aufzeigt wie bei IP-Masquarading?
Ich verstehe immernoch nicht wie Portlose Protokollen mit Sessionhandling durch eine PAT-Router können und so unterschieden werden kann an wen das Datenpaket muss. Wie wird das erkennt wie funktioniert das?
Bei PAT brauchts einen Port wenn ein Datenpaket ohne Port durch einen PAT-Router will merkt das der Router und es wird PAT ausserkraft gesetzt dann kommt Sessionhandling nach Protokollnummer zum Einsatz? Wie funktioniert das ganze?
Weiter verstehe ich immernoch nicht was du mit folgendem sagen willst:
"
Per se richtig wenn du einzig nur die Outbound Richtung betrachtest.
Inbound bleibt das Paket aber genauso an einem PAT Router hängen wie alle anderen auch.
Wie gesagt das betrifft natürlich nur die Passthrough Option wenn du mit Port Forwarding dursch NAT bzw. PAT Inbound durch willst, klar !
"
Ich habe doch geschrieben das NAT und PPTP *NICHTS* miteinander zu tun haben Darum stelle ich meine Frage nochmals:
Ich weiss ja vorher, dass ich z. B 4 Private IP-Adressen habe und diese zu den WAN-IP-Adressen weiterleiten will, sodass meine 4 Server online sein können das Gleichzeitig. Somit kann ich das doch auch gleich als statisches NAT also ohne Pooling realisieren? Die vier Server haben ja eine statische IP-Adresse somit wird auch die Zuordnung der Sessions immer gleich bleiben wie beim statischen NAT?
Man verhindert so lediglich ein Nailing dieser NAT Adressen wenn man derer nur wenige hat und die z.B. öffentlich sind.
Sowas kommt so gut wie immer nur bei sehr begrenzten öffentlichen IPs zum Einsatz.
Verstehe ich immer noch nicht. Es sind doch nur Server die eine 1:1 NAT habe müssen um so übers Internet bzw. zwei Netzte miteinander verbunden zu sein wozu gibt Pooling? Jeder Server braucht ja eine private IP-Adresse und eine öffentliche IP-Adresse beim Pooling bekommt ja mal Server A eine WAN-IP um durch die NAT gehen zu dürfen mal Server B während dieser Zeit ist ja Server A nicht erreichbar da die WAN-IP-Adresse für Server B reserviert ist.
So stelle ich mir Pooling vor:
Pooling stell ich mir wie ein DHCP-Server vor der Adresse verteilt statt ein DHCP-Server kann ich ja auch statische IP-Adresse verteilen was dann wie statisches NAT wäre?
Also wird auf Seiten des Servers beim PAT-Router das Problem verursacht, um das zu umgehen, stellt der Client eine Verbindung zum Server über TCP 20 her. Also eine eingehende Verbindung beim Server und dieser bestätigt wiederrum Outbound somit ein gültige Session? = Passiv FTP! Habe ich das richtig Richtig?????? Für ein NAT-Router würde das ja keine Rolle spielen der kann ja Aktives FTP auch richtig?
Kann also ein PAT-Router keine ausgehende Verbindung initiieren wie das auf dem PAT-Router auf Seiten des Clients geschieht? Kann er der PAT-Router nur eingehende akzeptieren, ausgehend bestätigen = eine gültige Session?
Das irritiert mich... LAN nach WAN / Internet, Also es muss zuerst eine eingehende Verbindung aus dem WAN existieren (Server der was vom Client möchte), anschliessend wird von LAN zu WAN ausgehend bestätigt. = Session Eintrag? Stimmt das so?
Port Forwarding wird bei FTP nur im aktivem FTP eingesetzt beim passiven geht ja das ohne Umwege oder? Mir ist nur noch nicht ganz klar wie dieses Port Forwarding funktioniert.... Ist das ein statischer Ersatz für das PAT?
Protokoll der Anwendung: FTP (21) / 20 oder eben RDP default Port 3389
Wie meine Port Forwarding aussieht:
Ich habe zurzeit kein Port Forwarding eingestellt weil ich nicht weiss was es ist und wie es funktioniert. Weiter weiss ich nicht was ich dort eingeben muss.
Ohne VPN geht das so:
Ok, von der Theorie zum Praktischen...
Ich scheitere bereits am ersten Punkt:
Ich wollte bei der Fritz.Box unter Freigaben -> Port Forwarding die WAN-IP der des ZyXEL-Router eingeben. Laut der Fehlermeldung kann ich dort nur IP-Adressen eingeben die im 192.168.0.X Netz liegen (FritzBox).
Siehe Screenshot:
Auch erscheint die Fehlermeldung wenn ich die WAN-IP des ZyXel's welche ich vom ISP erhalte eingebe 83.219.*.*.
Hat NAT die gleiche Funktionsweise wie PAT anstatt Ports halt nur externe IP-Adressen? Kennst du ein Diagramm das den Weg aufzeigt wie bei IP-Masquarading?
Zitat von @aqui:
Wozu dann die Unterscheidung zwischen NAT oder PAT und Sessionhandling bei Portlosen Protokollen? Versteh einfach nicht wie das funktionieren soll....
Es gibt dort die Unterscheidung auch nicht. PAT kann ja logischerweise niemals mit portlosen Protokollen funktionieren, denn es basiert ja selber auf Ports. Da klappt also nur NAT.Ich verstehe immernoch nicht wie Portlose Protokollen mit Sessionhandling durch eine PAT-Router können und so unterschieden werden kann an wen das Datenpaket muss. Wie wird das erkennt wie funktioniert das?
Bei PAT brauchts einen Port wenn ein Datenpaket ohne Port durch einen PAT-Router will merkt das der Router und es wird PAT ausserkraft gesetzt dann kommt Sessionhandling nach Protokollnummer zum Einsatz? Wie funktioniert das ganze?
Weiter verstehe ich immernoch nicht was du mit folgendem sagen willst:
"
Per se richtig wenn du einzig nur die Outbound Richtung betrachtest.
Inbound bleibt das Paket aber genauso an einem PAT Router hängen wie alle anderen auch.
Wie gesagt das betrifft natürlich nur die Passthrough Option wenn du mit Port Forwarding dursch NAT bzw. PAT Inbound durch willst, klar !
"
Also das verstehe ich schon das NAT und PPTP nicht das Gleiche ist.
Puuhhh, jetzt schwadronierst du im freien Fall !! Das eine hat mit dem anderen nicht das Geringste zu tun. Eine verfahren und ein Protokoll ist so wie Fisch und Fahrrad...Ich habe doch geschrieben das NAT und PPTP *NICHTS* miteinander zu tun haben
Darum stelle ich meine Frage nochmals:Ich weiss ja vorher, dass ich z. B 4 Private IP-Adressen habe und diese zu den WAN-IP-Adressen weiterleiten will, sodass meine 4 Server online sein können das Gleichzeitig. Somit kann ich das doch auch gleich als statisches NAT also ohne Pooling realisieren? Die vier Server haben ja eine statische IP-Adresse somit wird auch die Zuordnung der Sessions immer gleich bleiben wie beim statischen NAT?
Aber was bringt das
Wenn z.B. 253 Mitarbeiter im Büro sitzen und jeder braucht hie und da mal ne 1:1 NAT Session aus welchem Grund auch immer.Man verhindert so lediglich ein Nailing dieser NAT Adressen wenn man derer nur wenige hat und die z.B. öffentlich sind.
Sowas kommt so gut wie immer nur bei sehr begrenzten öffentlichen IPs zum Einsatz.
Verstehe ich immer noch nicht. Es sind doch nur Server die eine 1:1 NAT habe müssen um so übers Internet bzw. zwei Netzte miteinander verbunden zu sein wozu gibt Pooling? Jeder Server braucht ja eine private IP-Adresse und eine öffentliche IP-Adresse beim Pooling bekommt ja mal Server A eine WAN-IP um durch die NAT gehen zu dürfen mal Server B während dieser Zeit ist ja Server A nicht erreichbar da die WAN-IP-Adresse für Server B reserviert ist.
So stelle ich mir Pooling vor:
Pooling stell ich mir wie ein DHCP-Server vor der Adresse verteilt statt ein DHCP-Server kann ich ja auch statische IP-Adresse verteilen was dann wie statisches NAT wäre?
Verstehe ich nicht, wie meinst du das mit "zu der eingehenden TCP 20 Session gibt es keine korrespondierende Outbound Session"...?
* Jetzt sendet der Server die Datei über eine TCP 20 Session die ER zum Client eröffnet.- Da der Client aber niemals eine TCP 20 Session eröffnet hat gibts auch logischerweise kein in der PAT Session Table. Folglich weist der PAT Prozess diese TCP 20 inbound Session ab. Aus die Maus.. Wie auch ALLE anderen Sessions die von außen initiiert werden.
Also wird auf Seiten des Servers beim PAT-Router das Problem verursacht, um das zu umgehen, stellt der Client eine Verbindung zum Server über TCP 20 her. Also eine eingehende Verbindung beim Server und dieser bestätigt wiederrum Outbound somit ein gültige Session? = Passiv FTP! Habe ich das richtig Richtig?????? Für ein NAT-Router würde das ja keine Rolle spielen der kann ja Aktives FTP auch richtig?
Kann also ein PAT-Router keine ausgehende Verbindung initiieren wie das auf dem PAT-Router auf Seiten des Clients geschieht? Kann er der PAT-Router nur eingehende akzeptieren, ausgehend bestätigen = eine gültige Session?
Also muss immer erst eine eingehende Verbindung existieren bevor es eine ausgehende gibt?
Aus Sichtweise lokales LAN nach WAN/Internet ja, genau so ist es. Siehe oben...Das irritiert mich... LAN nach WAN / Internet, Also es muss zuerst eine eingehende Verbindung aus dem WAN existieren (Server der was vom Client möchte), anschliessend wird von LAN zu WAN ausgehend bestätigt. = Session Eintrag? Stimmt das so?
Anhand meiner Konfig wie würde ich Port Forwarding einstellen?
Frage kann man nicht beantworten wenn du nicht sagst für WAS (Protokoll der Anwendung) !Port Forwarding wird bei FTP nur im aktivem FTP eingesetzt beim passiven geht ja das ohne Umwege oder? Mir ist nur noch nicht ganz klar wie dieses Port Forwarding funktioniert.... Ist das ein statischer Ersatz für das PAT?
Protokoll der Anwendung: FTP (21) / 20 oder eben RDP default Port 3389
Wie meine Port Forwarding aussieht:
bevor ich diese Kaskade hatte konnte ich per RDP auf meinen Windows-Server zugreifen seit ich diese Router Kaskade habe geht nix mehr.
Klar weil du vermutlich das Port Forwarding falsch eingestellt hast.Ich habe zurzeit kein Port Forwarding eingestellt weil ich nicht weiss was es ist und wie es funktioniert. Weiter weiss ich nicht was ich dort eingeben muss.
Du sagtest ja ich müsste bei der Fritz.Box NAT deaktivieren dann würde alles wieder gehen oder?
Nein, Unsinn, muss man nicht und geht bei der FB auch gar nicht weil nicht supportet dort.Ohne VPN geht das so:
- Port Forwarding an der Fritzbox eingehend (Internet) Port TCP 3389 auf die WAN IP des Zyxels forwarden (diese sollte statisch sein)
- Port Forwarding am Zyxel eingehend WAN Port TCP 3389 auf die IP des Servers forwarden.
- Firewall im Server so einstellen das die fremde IPs für TCP 3389 passieren lässt
- Fertisch
- Port Forwarding an der Fritzbox eingehend (Internet) Port TCP 1723 und GRE Protokoll 47 auf die WAN IP des Zyxels forwarden (diese sollte statisch sein)
- Port Forwarding am Zyxel eingehend WAN Port TCP 1723 und GRE Protokoll 47 auf die IP des Servers forwarden.
- Firewall im Server so einstellen das die fremde IPs für TCP 1723 und GRE Protokoll 47 passieren lässt
- Fertisch
- Besser: VPN per Port Forwarding durch die FB schleifen und auf dem Zyxel terminieren wenn der VPNs terminieren kann wie die FB. Auf der FB terminieren geht auch aber dann musst du wieder Port Forwarden auf dem Zyxel...zu umständlich.
Ok, von der Theorie zum Praktischen...
Ich scheitere bereits am ersten Punkt:
Ich wollte bei der Fritz.Box unter Freigaben -> Port Forwarding die WAN-IP der des ZyXEL-Router eingeben. Laut der Fehlermeldung kann ich dort nur IP-Adressen eingeben die im 192.168.0.X Netz liegen (FritzBox).
Siehe Screenshot:
Auch erscheint die Fehlermeldung wenn ich die WAN-IP des ZyXel's welche ich vom ISP erhalte eingebe 83.219.*.*.
Hat NAT die gleiche Funktionsweise wie PAT anstatt Ports halt nur externe IP-Adressen?
Nein ! NAT ist NICHT Portbezogen wie PAT:http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_nat/configurati ...
Die Cisco Seiten erklären auch das NAT Pooling etc.
Ich verstehe immernoch nicht wie Portlose Protokollen mit Sessionhandling durch eine PAT-Router können
Das ist auch Blödsinn was du schreibst. Portlose Protokolle haben keine Sessions.Hier wird einfach dem PAT mit Port Forwatding gesagt: "Wenn hier IP Protokoll 47 reinkommt forwarde das auf die interne IP.
Somit kann ich das doch auch gleich als statisches NAT also ohne Pooling realisieren? Die vier Server haben ja eine statische IP-Adresse somit wird auch die Zuordnung der Sessions immer gleich bleiben wie beim statischen NAT?
Ja, da hast du Recht ! Pooling macht nur Sinn wenn du weniger WAN Adressen hast als interne die darauf mappen. Dann kannst du diese 2 im Pooling für alle freigeben es können aber immer nur 2 zur Zeit benutzt werden. Das macht natürlich nur Sinn wenn die NAT Anforderungen nicht permanent auf eine interne IP gebunden sein muss...klar !um das zu umgehen, stellt der Client eine Verbindung zum Server über TCP 20 her.
Ja, genau richtig. Das ist passive FTP. Groschen endlich gefallen LAN nach WAN / Internet, Also es muss zuerst eine eingehende Verbindung aus dem WAN existieren
Nein, das wäre ja Blödsinn. Aus dem WAN (Internet) kann niemals eine Session initiiert werden nach intern. Das verhindert die PAT Firewall. Keinen gültige Outbound Session...gleiches Thema wie oben beim FTP.Es muss IMMER eine LAN nach WAN Session bestehen damit Traffic auch in die andere Richtung fliessen kann.
Wäre es anders wäre jeglicher Zugriff vom Internet ins lokale LAN möglich was ja logischerweise keiner will !
Port Forwarding wird bei FTP nur im aktivem FTP eingesetzt beim passiven geht ja das ohne Umwege oder?
Nein ! Port Forwarding braucht man NUR wenn man von außen aufs interne Netz will ohne VPN. Dann ist ein Port Forwarding immer zwingend für jegliches Protokoll ! Ohne Port Forwrding blockiert es der PAT Prozess.Wie meine Port Forwarding aussieht:
OK das gar kein Port Forwarding ! Ich habe zurzeit kein Port Forwarding eingestellt weil ich nicht weiss was es ist und wie es funktioniert.
Nach sage und schreibe 88 Antworten solltest du das aber langsam endlich mal wissen.Mit Port Forwarding bohrst du ein Loch in die PAT Firewall und sagst (Beispiel RDP):
"Wenn hier irgendwas reinkommt, egal woher (Absender IP) und das den Port TCP 3389 hat dann ignoriere das PAT und die Firewall und forwarde das direkt an die interne IP Adresse 1.2.3.4 !"
Du machst also dein Burgtor einen Spalt weit auf....
ch wollte bei der Fritz.Box unter Freigaben -> Port Forwarding die WAN-IP der des ZyXEL-Router eingeben. Laut der Fehlermeldung kann ich dort nur IP-Adressen eingeben die im 192.168.0.X Netz liegen (FritzBox).
Ohhh Mann....denk doch bitte mal logisch !!!Deine FB hängt direkt am Internet...am internen LAN Netz der FB hängt der WAN Port des Zyxel und daran dann final dein internes LAN.
Folglich musst also ein RDP Paket aus dem Internet auf das lokale LAN genau die lokale LAN IP Adresse des Zyxel WAN Ports im FB LAN geforwardet werden !
Dann kommt dieses TCP Paket am WAN Port des Zyxels an und auch hier muss dieses TCP 3389 Paket dann wieder final auf die IP Adresse des Servers im finalen loaklen LAN geforwardet werden.
Diese Logik erschliesst sich doch jedem Erstklässler wenn man mal nachdenkt...sorry !
Also alles richtig mit der FB und dem Port Forwarding Setup da !
Oder.....ist das bei dir andersrum ??? Der Zyxel hängt im Internet und dahinter die FB und dann dein lokales LAN ??
Ist aber auch egal...das Port Forwarding Setting ist gleich...immer Hop für Hop !!
Zitat von @aqui:
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_nat/configurati ...
Die Cisco Seiten erklären auch das NAT Pooling etc.
Hat NAT die gleiche Funktionsweise wie PAT anstatt Ports halt nur externe IP-Adressen?
Nein ! NAT ist NICHT Portbezogen wie PAT:http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_nat/configurati ...
Die Cisco Seiten erklären auch das NAT Pooling etc.
Das sagte ich doch der einzige Unterschied ist das NAT nicht Portbezogen ist. Aber wie funktioniert NAT lautet meine Frage wie muss ich mir das vorstellen? Das anstatt die Ports stehen dort nur IP-Adressen?
Ich kann nur begrenzt englisch bei so einem komplexen Thema macht eine Google Translation nur noch mehr Chaos bei mir.
Ich verstehe immernoch nicht wie Portlose Protokollen mit Sessionhandling durch eine PAT-Router können
Das ist auch Blödsinn was du schreibst. Portlose Protokolle haben keine Sessions.Hier wird einfach dem PAT mit Port Forwatding gesagt: "Wenn hier IP Protokoll 47 reinkommt forwarde das auf die interne IP.
Ja, aber (folgendes betrifft nur PAT-Router) wir hatten doch darüber gesprochen, dass es ein Sessionhandling gibt für Protokolle die keine Ports haben wie z. B GRE oder ESP dort existieren keine Ports aber der z. B Router kann Sessions erkennen auch wenns keine Ports gibt. Wie das funktioniert würde ich gerne wissen.
Kannst du mir bitte sagen was du damit meinst:
Weiter verstehe ich immernoch nicht was du mit folgendem sagen willst (hast du weiter oben mal geschrieben):
"
Per se richtig wenn du einzig nur die Outbound Richtung betrachtest.
Inbound bleibt das Paket aber genauso an einem PAT Router hängen wie alle anderen auch.
Wie gesagt das betrifft natürlich nur die Passthrough Option wenn du mit Port Forwarding dursch NAT bzw. PAT Inbound durch willst, klar !
"
Somit kann ich das doch auch gleich als statisches NAT also ohne Pooling realisieren? Die vier Server haben ja eine statische IP-Adresse somit wird auch die Zuordnung der Sessions immer gleich bleiben wie beim statischen NAT?
Ja, da hast du Recht ! Pooling macht nur Sinn wenn du weniger WAN Adressen hast als interne die darauf mappen. Dann kannst du diese 2 im Pooling für alle freigeben es können aber immer nur 2 zur Zeit benutzt werden. Das macht natürlich nur Sinn wenn die NAT Anforderungen nicht permanent auf eine interne IP gebunden sein muss...klar !Also nochmals als Zusammenfassung zum NAT-Pooling: Pooling wird dann eingesetzt wenn Clients dynamisch eine WAN-IP-Adressen brauchen (z. B für die Kommunikation ins Internet) und es nicht soviele WAN-IP-Adressen gibt um jedem Server eine statische WAN-IP zu vergeben. Als Lösung bezieht nur der jenige Server eine WAN-IP der gerade ins Internet kommunizieren möchte? Habe ich das so richtig verstanden?
Aber wo z. B ist ein Einsatzort für NAT-Pooling? NAT wird doch nur eingesetzt bei Servern und da ein Server im normal Fall eine statische WAN-IP-Adresse haben muss / sollte wozu dann das Pooling? Oder ist Pooling mehr als Outbound Kommunikation gedacht?
Jeder Server braucht ja eine private IP-Adresse und eine öffentliche IP-Adresse beim Pooling bekommt ja mal Server A eine WAN-IP um durch die NAT gehen zu dürfen mal Server B während dieser Zeit ist ja Server A nicht erreichbar da die WAN-IP-Adresse für Server B reserviert ist.
um das zu umgehen, stellt der Client eine Verbindung zum Server über TCP 20 her.
Ja, genau richtig. Das ist passive FTP. Groschen endlich gefallen Kannst du mir die weiteren Fragen noch bestätigen und die Feststellungen die ich gemacht habe, bitte:
Für ein NAT-Router würde das ja keine Rolle spielen der kann ja Aktives FTP auch richtig? Oder wozu sonst würde es aktives FTP sonst geben?
Kann also ein PAT-Router keine ausgehende Verbindung initiieren wie das auf dem PAT-Router auf Seiten des Clients geschieht? Kann er der PAT-Router nur eingehende akzeptieren, ausgehend bestätigen = eine gültige Session?
LAN nach WAN / Internet, Also es muss zuerst eine eingehende Verbindung aus dem WAN existieren
Nein, das wäre ja Blödsinn. Aus dem WAN (Internet) kann niemals eine Session initiiert werden nach intern. Das verhindert die PAT Firewall. Keinen gültige Outbound Session...gleiches Thema wie oben beim FTP.Es muss IMMER eine LAN nach WAN Session bestehen damit Traffic auch in die andere Richtung fliessen kann.
Wäre es anders wäre jeglicher Zugriff vom Internet ins lokale LAN möglich was ja logischerweise keiner will !
Oh Mann!
Dann habe ich das immer noch nicht verstanden.Also muss von Inbound (LAN) nach Outbound (WAN)? Also Client aus Netz A schickt dem Server aus Netz B Daten über FTP 20 (Sessionaufbau), beim PAT-Router wo sich der Server aus Netz B befindet kommt die Anfrage rein. Der PAT-Router aus Netz B akzeptiert oder lehnt die Verbindung zu Netz A ab oder zu. Wenn der PAT-Router aus Netz B die Verbindung akzeptiert bestätigt er noch mit ACK dann besteht die Session. - Nun besteht eine Session auf den PAT-Routern bei Netz A und Netz B. Das ist jetzt passives FTP da der Client mit dem Verbindungsaufbau von FTP 20 anfängt oder?
Das Problem beim aktiven FTP ist doch dass aus dem WAN zu LAN eine Verbindung aufgebaut werden soll oder? Und darum eine ungültige Session? Wozu existiert dann aktives FTP? Bei NAT wird doch auch keine WAN zu LAN Session zugelassen?
Port Forwarding wird bei FTP nur im aktivem FTP eingesetzt beim passiven geht ja das ohne Umwege oder?
Nein ! Port Forwarding braucht man NUR wenn man von außen aufs interne Netz will ohne VPN. Dann ist ein Port Forwarding immer zwingend für jegliches Protokoll ! Ohne Port Forwrding blockiert es der PAT Prozess.Denke es gibt da ein grosses Missverständnis. Ich möchte wissen dieses "Port-Triggering-Regeln" bedeutet welches ich als Port Forwarding angesehen habe. Das Port Forwarding habe ich bisher als statische PAT-Tabelle angesehen. (Siehe Screenshot) . Bild unten ist also Port Forwarding wo bei ZYXEL Anwendungsregeln heisst.
Wie meine Port Forwarding aussieht:
OK das gar kein Port Forwarding ! Wie oben geschrieben gabs ein Missverständnis. Ich möchte aus diesem Screenshot wissen was das obere Bild ist dieses "Port Triggering" welches ich als PAT Forwarding angesehen habe.
PAT Forwarding siehst du ja im Screenshot das ist konfiguriert! (unteres Bild)
ch wollte bei der Fritz.Box unter Freigaben -> Port Forwarding die WAN-IP der des ZyXEL-Router eingeben. Laut der Fehlermeldung kann ich dort nur IP-Adressen eingeben die im 192.168.0.X Netz liegen (FritzBox).
Ohhh Mann....denk doch bitte mal logisch !!!Deine FB hängt direkt am Internet...am internen LAN Netz der FB hängt der WAN Port des Zyxel und daran dann final dein internes LAN.
Folglich musst also ein RDP Paket aus dem Internet auf das lokale LAN genau die lokale LAN IP Adresse des Zyxel WAN Ports im FB LAN geforwardet werden !
Dann kommt dieses TCP Paket am WAN Port des Zyxels an und auch hier muss dieses TCP 3389 Paket dann wieder final auf die IP Adresse des Servers im finalen loaklen LAN geforwardet werden.
Diese Logik erschliesst sich doch jedem Erstklässler wenn man mal nachdenkt...sorry !
Also alles richtig mit der FB und dem Port Forwarding Setup da !
Oder.....ist das bei dir andersrum ??? Der Zyxel hängt im Internet und dahinter die FB und dann dein lokales LAN ??
Ist aber auch egal...das Port Forwarding Setting ist gleich...immer Hop für Hop !!
Cool
es hat geklappt. Habe verstanden wie ich die Einstellungen machen muss. Also RDP funktioniert schonmal bei PPTP wird wohl erst klappen wenn ich den ZYXEL durch einen Router ersetzte der auch GRE oder sonstige portlosen Protokolle forwarden kann. Somit ein Problem weniger )Hier mal die Screenshots:
Im Port Forwarding von ZyXEL müsste der dc-srv01 eigentlich testsrv1 heissen.
Cool es hat geklappt.
Ächz....das war ja aber ne schwere Geburt mit dir !Ja, kannst du mir trotzdem noch die anderen Fragen beantworten. Es geht mir ja nicht nur darum, dass über die Router Kaskade RDP und VPN geht sondern noch wie PAT und NAT etc. funktioniert.
Danke
Ist doch oben eigentlich alles schon umfassend und auch noch mit Beispielen beantwortet...
Zitat von @aqui:
Ist doch oben eigentlich alles schon umfassend und auch noch mit Beispielen beantwortet...
Ist doch oben eigentlich alles schon umfassend und auch noch mit Beispielen beantwortet...
Also ich habe ja neue Fragen gestellt die doch noch nicht beantwortet wurden. Weiter verstehe ich nicht alles und darum meine Nachfragen... Wäre froh wenn du mir weiterhilfst
Fass die am besten nochmal kurz knapp und präzise zusammen. Langsam verliert man hier den Überblick
Zitat von @aqui:
Fass die am besten nochmal kurz knapp und präzise zusammen. Langsam verliert man hier den Überblick
Fass die am besten nochmal kurz knapp und präzise zusammen. Langsam verliert man hier den Überblick
Nicht nur du verlierst den Überblickt
Ich werde mich nächste Woche wieder damit beschäftigen hoffe du kannst warten. Schönes Weekend.
Zitat von @aqui:
Fass die am besten nochmal kurz knapp und präzise zusammen. Langsam verliert man hier den Überblick
Fass die am besten nochmal kurz knapp und präzise zusammen. Langsam verliert man hier den Überblick
1. Frage
Ich verstehe noch nicht wie NAT funktioniert. Anhand dieser Grafik http://kohnlehome.de/netz/Masquerading.swf habe ich verstanden wie PAT funktioniert. Kennst du auch so eine Grafik für NAT? Wie funktioniert den NAT?
2. Frage
So wie ich dich verstanden habe, gibts nur Session bei Protokollen die Ports haben. Bei GRE oder ESP (die Protokolle haben ja keine Ports) kann nur anhand einer höheren OSI-Schicht die Session zugeordnet werden und mit Hilfe der Protokollnummer. Möchte wissen wie das der Router einer Session zuordnen kann wenn das Protokoll keine Ports benutzt.
3. Frage
Verstehe noch nicht ganz das NAT-Pooling.
Also nochmals als Zusammenfassung zum NAT-Pooling: Pooling wird dann eingesetzt wenn Clients dynamisch eine WAN-IP-Adressen brauchen (z. B für die Kommunikation ins Internet) und es nicht soviele WAN-IP-Adressen gibt um jedem Server eine statische WAN-IP zu vergeben. Als Lösung bezieht nur der jenige Server eine WAN-IP der gerade ins Internet kommunizieren möchte? Habe ich das so richtig verstanden?
Aber wo z. B ist ein Einsatzort für NAT-Pooling? NAT wird doch nur eingesetzt bei Servern und da ein Server im normal Fall eine statische WAN-IP-Adresse haben muss / sollte wozu dann das Pooling? Oder ist Pooling mehr als Outbound Kommunikation gedacht?
Jeder Server braucht ja eine private IP-Adresse und eine öffentliche IP-Adresse beim Pooling bekommt ja mal Server A eine WAN-IP um durch die NAT gehen zu dürfen mal Server B während dieser Zeit ist ja Server A nicht erreichbar da die WAN-IP-Adresse für Server B reserviert ist.
4. Frage
Wieso gibt es aktives und passives FTP. Es gibt ja nur einen kleinen Unterschied. Das aktive FTP verursacht ja nur Probleme weil aus dem WAN zu LAN eine Verbindung versucht wird herzustellen oder?
Was ich weiter nicht verstehe diese beiden Grafiken mit aktivem und passivem FTP unter http://slacksite.com/other/ftp.html dort die Datenübertragungs-Session. Einmal stellt der Server die Anfrage um Daten zusenden zu dürfen (aktives FTP). Das klappt nicht wie du sagst weil keine gültige Session zustande kommt.
Beim passivem FTP initiiert der Client auf einem anderen Port "2024" die Verbindung dort klappt dann die Kommunikation. Lag es an diesem 2024 Port oder wieso klappt im passivem Mode die Kommunikation? Weiter im passivem Mode stellt auch ein Client im LAN zu WAN (Server) eine Verbindung obwohl es dazu keine Session gibt und trotzdem klappt die Verbindung. Du hast gesagt die Kommunikation muss immer vom LAN ausgehend zu WAN sein. Genau das Gegenteil macht doch der passive Mode aus Sicht des Servers.
5. Frage
Ich möchte gerne wissen was dieses "Port-Triggering-Regeln" bedeutet.
Zitat von @osze90:
1. Frage
Ich verstehe noch nicht wie NAT funktioniert. Anhand dieser Grafik http://kohnlehome.de/netz/Masquerading.swf habe ich verstanden wie PAT funktioniert. Kennst du auch so eine Grafik für NAT? Wie funktioniert den NAT?
http://computer.howstuffworks.com/nat.htmZitat von @aqui:
Fass die am besten nochmal kurz knapp und präzise zusammen. Langsam verliert man hier den Überblick
Fass die am besten nochmal kurz knapp und präzise zusammen. Langsam verliert man hier den Überblick
1. Frage
Ich verstehe noch nicht wie NAT funktioniert. Anhand dieser Grafik http://kohnlehome.de/netz/Masquerading.swf habe ich verstanden wie PAT funktioniert. Kennst du auch so eine Grafik für NAT? Wie funktioniert den NAT?
4. Frage
Wieso gibt es aktives und passives FTP. Es gibt ja nur einen kleinen Unterschied.
Weil früher alles egal war und nicht so auf Sicherheit geschaut wurde vielleicht?!Wieso gibt es aktives und passives FTP. Es gibt ja nur einen kleinen Unterschied.
Das aktive FTP verursacht ja nur Probleme weil aus dem WAN zu LAN eine Verbindung versucht wird herzustellen oder?
Nicht ganz richtig, der Client stellt eine Verbindung zum Server her und sagt ihm auf welchem Port er lauscht.Der Server versucht nur auf diesem Port zu antworten, die Firewall des Clients verwirft diese Pakete aber sofort.
Was ich weiter nicht verstehe diese beiden Grafiken mit aktivem und passivem FTP unter http://slacksite.com/other/ftp.html dort die Datenübertragungs-Session. Einmal stellt der Server die Anfrage um Daten zusenden zu dürfen (aktives FTP). Das klappt nicht wie du sagst weil keine gültige Session zustande kommt.
Beim passivem FTP initiiert der Client auf einem anderen Port "2024" die Verbindung dort klappt dann die Kommunikation. Lag es an diesem 2024 Port oder wieso klappt im passivem Mode die Kommunikation?
Es klappt jetzt weil der Client dem Server sagt, mach bitte noch einen Port zwischen 1024 und 5000 auf und wir wickeln den rest über diesen Port ab. Der Server erlaubt die Anfragen dann auch auf diesem Port vom Client.Beim passivem FTP initiiert der Client auf einem anderen Port "2024" die Verbindung dort klappt dann die Kommunikation. Lag es an diesem 2024 Port oder wieso klappt im passivem Mode die Kommunikation?
Weiter im passivem Mode stellt auch ein Client im LAN zu WAN (Server) eine Verbindung obwohl es dazu keine Session gibt und trotzdem klappt die Verbindung. Du hast gesagt die Kommunikation muss immer vom LAN ausgehend zu WAN sein. Genau das Gegenteil macht doch der passive Mode aus Sicht des Servers.
Nein, auch hier startet der Client die Kommunikation auf Port 21. Nur sagt er dem Server eben zusätzlich: Mach bitte noch einen anderen Port auf damit wir die Daten austauschen können weil wenn ich einen aufmachen muss, bleibst du an meiner Firewall hängen.5. Frage
Ich möchte gerne wissen was dieses "Port-Triggering-Regeln" bedeutet.
https://de.wikipedia.org/wiki/Portweiterleitung#Port_TriggeringIch möchte gerne wissen was dieses "Port-Triggering-Regeln" bedeutet.
Ist etwas sicherer als reines Port Forwarding. Beim Port-Forwarding ist der Port immer offen, beim Port-Triggering erst wenn auch von Innen nach Außen eine Anfrage stattgefunden hat.
Danke michi Besser hätte man es nicht erklären können.... !
Kleine Ergänzung:
Kleine Ergänzung:
die Firewall des Clients verwirft diese Pakete aber sofort.
Das ist bei active FTP dann aber meist die NAT Firewall des Routers davor die das schon voher verwirft, da der die Datensession des Servers eine inbound Session ist zu der im PAT kein Session Eintrag besteht. Damit geht die dann in den Datenmülleimer.
Kannst du mir bitte noch Frage 2+3 beantworten. Dankeschön
Danke für den Link. Ich kann mir aus diesem Bild nicht vorstellen wie NAT genau funktioniert. Dort steht nur Outbound und Inbound aber ich sehe nicht genau in die Datenpakete oder sogar ins TCP-Segment hinein wie bei http://kohnlehome.de/netz/Masquerading.swf. Die verlinkte Grafik erklärt ja richtig wie das abgeht da kann man sich ein Bild machen. Kannst du mir das bitte erklären?
Aha also Sicherheit? Jetzt muss ich nur noch verstehen wieso, es auch sicherer ist.
Der Server versucht nur auf diesem Port zu antworten, die Firewall des Clients verwirft diese Pakete aber sofort.
Also laut Aqui verwirft die NAT Firewall des Server die Pakete soviel wie ich verstehe. Was ich jetzt aber nicht verstehe wo das Problem liegt. Der Client stellt eine Verbindung zum Server her und sagt "hello ich will auf Port 21 dir was schicken". Der Server lässt das ja jetzt nicht zu bzw. die NAT Firewall dropt das Paket. Wieso verwirft die NAT Firewall diese Pakete wenn der Server auf diesem Port 21 auf welchem der Client etwas schicken will?
Wenn ich mir die Grafik bei http://slacksite.com/other/ftp.html unter aktivem FTP anschaue fängt ja der Server mit dem Initiieren der FTP Data-Session an. Wieso fängst du mit der Clientseite an? Beim passiven fängt der Client mit dem Initiieren an.
Was für eine Rolle spielt das den ob jetzt Port 21 oder Port 1024? Wieso werden beim passiven FTP nicht auf dem Port 21 die Daten verschickt?
Ja, FTP Port 21 (commands) ist bei beiden Modellen passiv und aktiv gleich. Aber der Datenfluss ist nicht gleich das verstehe ich nicht. Der jenige der die Verbindung initiiert lässt auch Daten zu?? Also als Beispiel: Wenn der Client Daten an den Server schicken will muss der Server dem Client sagen wenn du mir etwas schicken willst musst du das auf diesem Port tun 21? Hingegen wenn der Server mit dem Client kommunizieren möchte, muss der Client zum Server eine Verbindung initiieren und sagen die Daten kannst du mir auf diesem Port XY schicken. Danach erst kann der Server die Daten dem Client schicken.
Ist etwas sicherer als reines Port Forwarding. Beim Port-Forwarding ist der Port immer offen, beim Port-Triggering erst wenn auch von Innen nach Außen eine Anfrage stattgefunden hat.
Von Innen nach Aussen? Wieso den das? Im normal Fall kommt von aussen (WAN) nach LAN eine Anfrage z. B um auf meinen RDP-Server zuzugreifen.
Habe den Wiki Artikel gelesen sieht spannend aus. Nur verstehe ich nur die Hälfte. Eventuell hilft ein Praktikes Beispiel welches ich dann auf meinen Router übertragen könnte um es auszuprobieren :
Für Port Triggerin benötigt man ja mehrere Ports RDP lauscht bei mir auf dem default Port 3389 also denke ich mal müsste ich unter:
Auslösend / End-Port den Port 3389 hinschreiben. Was kommt bei eingehend hin? Der Eingehende Port wird doch dynamisch geregelt daher weiss ich doch nicht welchen?
Zitat von @michi1983:
1. Frage
Ich verstehe noch nicht wie NAT funktioniert. Anhand dieser Grafik http://kohnlehome.de/netz/Masquerading.swf habe ich verstanden wie PAT funktioniert. Kennst du auch so eine Grafik für NAT? Wie funktioniert den NAT?
http://computer.howstuffworks.com/nat.htmIch verstehe noch nicht wie NAT funktioniert. Anhand dieser Grafik http://kohnlehome.de/netz/Masquerading.swf habe ich verstanden wie PAT funktioniert. Kennst du auch so eine Grafik für NAT? Wie funktioniert den NAT?
Danke für den Link. Ich kann mir aus diesem Bild nicht vorstellen wie NAT genau funktioniert. Dort steht nur Outbound und Inbound aber ich sehe nicht genau in die Datenpakete oder sogar ins TCP-Segment hinein wie bei http://kohnlehome.de/netz/Masquerading.swf. Die verlinkte Grafik erklärt ja richtig wie das abgeht da kann man sich ein Bild machen. Kannst du mir das bitte erklären?
4. Frage
Wieso gibt es aktives und passives FTP. Es gibt ja nur einen kleinen Unterschied.
Weil früher alles egal war und nicht so auf Sicherheit geschaut wurde vielleicht?!Wieso gibt es aktives und passives FTP. Es gibt ja nur einen kleinen Unterschied.
Aha also Sicherheit? Jetzt muss ich nur noch verstehen wieso, es auch sicherer ist.
Das aktive FTP verursacht ja nur Probleme weil aus dem WAN zu LAN eine Verbindung versucht wird herzustellen oder?
Nicht ganz richtig, der Client stellt eine Verbindung zum Server her und sagt ihm auf welchem Port er lauscht.Der Server versucht nur auf diesem Port zu antworten, die Firewall des Clients verwirft diese Pakete aber sofort.
Also laut Aqui verwirft die NAT Firewall des Server die Pakete soviel wie ich verstehe. Was ich jetzt aber nicht verstehe wo das Problem liegt. Der Client stellt eine Verbindung zum Server her und sagt "hello ich will auf Port 21 dir was schicken". Der Server lässt das ja jetzt nicht zu bzw. die NAT Firewall dropt das Paket. Wieso verwirft die NAT Firewall diese Pakete wenn der Server auf diesem Port 21 auf welchem der Client etwas schicken will?
Wenn ich mir die Grafik bei http://slacksite.com/other/ftp.html unter aktivem FTP anschaue fängt ja der Server mit dem Initiieren der FTP Data-Session an. Wieso fängst du mit der Clientseite an? Beim passiven fängt der Client mit dem Initiieren an.
Was ich weiter nicht verstehe diese beiden Grafiken mit aktivem und passivem FTP unter http://slacksite.com/other/ftp.html dort die Datenübertragungs-Session. Einmal stellt der Server die Anfrage um Daten zusenden zu dürfen (aktives FTP). Das klappt nicht wie du sagst weil keine gültige Session zustande kommt.
Beim passivem FTP initiiert der Client auf einem anderen Port "2024" die Verbindung dort klappt dann die Kommunikation. Lag es an diesem 2024 Port oder wieso klappt im passivem Mode die Kommunikation?
Es klappt jetzt weil der Client dem Server sagt, mach bitte noch einen Port zwischen 1024 und 5000 auf und wir wickeln den rest über diesen Port ab. Der Server erlaubt die Anfragen dann auch auf diesem Port vom Client.Beim passivem FTP initiiert der Client auf einem anderen Port "2024" die Verbindung dort klappt dann die Kommunikation. Lag es an diesem 2024 Port oder wieso klappt im passivem Mode die Kommunikation?
Was für eine Rolle spielt das den ob jetzt Port 21 oder Port 1024? Wieso werden beim passiven FTP nicht auf dem Port 21 die Daten verschickt?
Weiter im passivem Mode stellt auch ein Client im LAN zu WAN (Server) eine Verbindung obwohl es dazu keine Session gibt und trotzdem klappt die Verbindung. Du hast gesagt die Kommunikation muss immer vom LAN ausgehend zu WAN sein. Genau das Gegenteil macht doch der passive Mode aus Sicht des Servers.
Nein, auch hier startet der Client die Kommunikation auf Port 21. Nur sagt er dem Server eben zusätzlich: Mach bitte noch einen anderen Port auf damit wir die Daten austauschen können weil wenn ich einen aufmachen muss, bleibst du an meiner Firewall hängen.Ja, FTP Port 21 (commands) ist bei beiden Modellen passiv und aktiv gleich. Aber der Datenfluss ist nicht gleich das verstehe ich nicht. Der jenige der die Verbindung initiiert lässt auch Daten zu?? Also als Beispiel: Wenn der Client Daten an den Server schicken will muss der Server dem Client sagen wenn du mir etwas schicken willst musst du das auf diesem Port tun 21? Hingegen wenn der Server mit dem Client kommunizieren möchte, muss der Client zum Server eine Verbindung initiieren und sagen die Daten kannst du mir auf diesem Port XY schicken. Danach erst kann der Server die Daten dem Client schicken.
5. Frage
Ich möchte gerne wissen was dieses "Port-Triggering-Regeln" bedeutet.
https://de.wikipedia.org/wiki/Portweiterleitung#Port_TriggeringIch möchte gerne wissen was dieses "Port-Triggering-Regeln" bedeutet.
Ist etwas sicherer als reines Port Forwarding. Beim Port-Forwarding ist der Port immer offen, beim Port-Triggering erst wenn auch von Innen nach Außen eine Anfrage stattgefunden hat.
Von Innen nach Aussen? Wieso den das? Im normal Fall kommt von aussen (WAN) nach LAN eine Anfrage z. B um auf meinen RDP-Server zuzugreifen.
Habe den Wiki Artikel gelesen sieht spannend aus. Nur verstehe ich nur die Hälfte. Eventuell hilft ein Praktikes Beispiel welches ich dann auf meinen Router übertragen könnte um es auszuprobieren :
Für Port Triggerin benötigt man ja mehrere Ports RDP lauscht bei mir auf dem default Port 3389 also denke ich mal müsste ich unter:
Auslösend / End-Port den Port 3389 hinschreiben. Was kommt bei eingehend hin? Der Eingehende Port wird doch dynamisch geregelt daher weiss ich doch nicht welchen?
Der URL http://computer.howstuffworks.com/nat.htm ist eigentlich der originale Cisco Artikel zur NAT Funktion !
Leider findet man den nicht mehr auf Ciscos Seite was sehr schade ist, denn dort wird wirklich umfassend und genau geschicldert was NAT ist und wie es im Einzelnen funktioniert.
Du musst aber zwingend den Text zu den Bildern lesen, sonst nützt das nix !!
Als FTP standartisiert wurde gab es sowas wie PAT noch gar nicht, vergiss das nicht ! Das protokoll ist niemals für die Verwendung mit PAT gemacht worden damals. Daher kommt auch die spätere Anpassung mit passive FTP Mode ! Nachdenken !!!
Hier machte eben der Client die Data Connection auf und NICHT der Server wie bei Active FTP. Das ist der ganze Witz dabei. Dadurch gibt es einen Session Eintrag in der PAT Tabelle und die Data Verbindung wird aufgebaut.
Andersrum bei Active initiiert der Server die Verbindung und dann kommt eine eingehende Data Verbindung am PAT an OHNE das einen Session von intern da ist, was PAT dann mit einem Paket Drop beantwortet.
Ist doch oben nun wirklich dir schon 4mal !! erklärt worden und das Bild hier:
http://slacksite.com/other/ftp.html
Erklärt das doch nun eindeutig !
Leider findet man den nicht mehr auf Ciscos Seite was sehr schade ist, denn dort wird wirklich umfassend und genau geschicldert was NAT ist und wie es im Einzelnen funktioniert.
Du musst aber zwingend den Text zu den Bildern lesen, sonst nützt das nix !!
Aha also Sicherheit? Jetzt muss ich nur noch verstehen wieso, es auch sicherer ist.
Das meinte er auf die Sicherheit bei Firewalls und PAT / NAT bezogen !! NICHT auf die Sicherheit von FTP.Als FTP standartisiert wurde gab es sowas wie PAT noch gar nicht, vergiss das nicht ! Das protokoll ist niemals für die Verwendung mit PAT gemacht worden damals. Daher kommt auch die spätere Anpassung mit passive FTP Mode ! Nachdenken !!!
Wieso werden beim passiven FTP nicht auf dem Port 21 die Daten verschickt?
Weil das bei passive FTP so vorgesehen ist !Hier machte eben der Client die Data Connection auf und NICHT der Server wie bei Active FTP. Das ist der ganze Witz dabei. Dadurch gibt es einen Session Eintrag in der PAT Tabelle und die Data Verbindung wird aufgebaut.
Andersrum bei Active initiiert der Server die Verbindung und dann kommt eine eingehende Data Verbindung am PAT an OHNE das einen Session von intern da ist, was PAT dann mit einem Paket Drop beantwortet.
Ist doch oben nun wirklich dir schon 4mal !! erklärt worden und das Bild hier:
http://slacksite.com/other/ftp.html
Erklärt das doch nun eindeutig !
FTP Port 21 (commands) ist bei beiden Modellen passiv und aktiv gleich. Aber der Datenfluss ist nicht gleich das verstehe ich nicht.
Kannst du oben am Flow Diagramm sehen ! Schritte 3 und 4 !! Das erklärt alles !Der jenige der die Verbindung initiiert lässt auch Daten zu??
Wenn keine PAT Firewall dazwischen ist ja...hier ist aber eine dazwischen !Zitat von @osze90:
Kannst du mir bitte noch Frage 2+3 beantworten. Dankeschön
Danke für den Link. Ich kann mir aus diesem Bild nicht vorstellen wie NAT genau funktioniert. Dort steht nur Outbound und Inbound aber ich sehe nicht genau in die Datenpakete oder sogar ins TCP-Segment hinein wie bei http://kohnlehome.de/netz/Masquerading.swf. Die verlinkte Grafik erklärt ja richtig wie das abgeht da kann man sich ein Bild machen. Kannst du mir das bitte erklären?
Kannst du mir bitte noch Frage 2+3 beantworten. Dankeschön
Zitat von @michi1983:
1. Frage
Ich verstehe noch nicht wie NAT funktioniert. Anhand dieser Grafik http://kohnlehome.de/netz/Masquerading.swf habe ich verstanden wie PAT funktioniert. Kennst du auch so eine Grafik für NAT? Wie funktioniert den NAT?
http://computer.howstuffworks.com/nat.htmIch verstehe noch nicht wie NAT funktioniert. Anhand dieser Grafik http://kohnlehome.de/netz/Masquerading.swf habe ich verstanden wie PAT funktioniert. Kennst du auch so eine Grafik für NAT? Wie funktioniert den NAT?
Danke für den Link. Ich kann mir aus diesem Bild nicht vorstellen wie NAT genau funktioniert. Dort steht nur Outbound und Inbound aber ich sehe nicht genau in die Datenpakete oder sogar ins TCP-Segment hinein wie bei http://kohnlehome.de/netz/Masquerading.swf. Die verlinkte Grafik erklärt ja richtig wie das abgeht da kann man sich ein Bild machen. Kannst du mir das bitte erklären?
Ev. hilft ja das hier:
NAT ist nix anderes als eine Möglichkeit mehrer Geräte eines LAN, gleichzeitig mit dem Internet kommunzieren zu lassen.
Wenn du mit einem Client aus dem Netz 192.168.0.0/24 ohne NAT z.B. www.google.de ansurfen möchtest, schickst du einen Request ins Internet raus und Google sieht als Absender z.b. die 192.168.0.10 und möchte dir eine Antwort schicken. Was glaubst du was passiert?
Was glaubst du wie viele Menschen auf dieser Welt Computer zu Hause stehen, die allesamt die selbe IP Adresse haben? Nämlich die 192.168.0.10. Das Paket geht schlicht weg verloren. NAT nimmt also deine IP Adresse 192.168.0.10 und die Ziel IP und speichert die in der NAT Table, maskiert deine LAN IP mit der öffentlichen IP die du an deinem Internet Anschluss hast und schickt das Paket an Google weiter. Google sieht nun wieder eine Absender IP, nur diesmal ist die eindeutig und schickt eine Antwort zurück. Dein NAT-Router bekommt das Paket, sieht in seiner Tabelle nach und sieht nun, dass die Absender IP gleich einer Ziel IP eines Eintrags in seiner NAT TAble ist und weiß somit welcher Client die Anfrage gestellt hat und leitet das Paket dorthin weiter.
4. Frage
Wieso gibt es aktives und passives FTP. Es gibt ja nur einen kleinen Unterschied.
Weil früher alles egal war und nicht so auf Sicherheit geschaut wurde vielleicht?!Wieso gibt es aktives und passives FTP. Es gibt ja nur einen kleinen Unterschied.
Aha also Sicherheit? Jetzt muss ich nur noch verstehen wieso, es auch sicherer ist.
Das aktive FTP verursacht ja nur Probleme weil aus dem WAN zu LAN eine Verbindung versucht wird herzustellen oder?
Nicht ganz richtig, der Client stellt eine Verbindung zum Server her und sagt ihm auf welchem Port er lauscht.Der Server versucht nur auf diesem Port zu antworten, die Firewall des Clients verwirft diese Pakete aber sofort.
Also laut Aqui verwirft die NAT Firewall des Server die Pakete soviel wie ich verstehe. Was ich jetzt aber nicht verstehe wo das Problem liegt. Der Client stellt eine Verbindung zum Server her und sagt "hello ich will auf Port 21 dir was schicken". Der Server lässt das ja jetzt nicht zu bzw. die NAT Firewall dropt das Paket. Wieso verwirft die NAT Firewall diese Pakete wenn der Server auf diesem Port 21 auf welchem der Client etwas schicken will?
Wenn ich mir die Grafik bei http://slacksite.com/other/ftp.html unter aktivem FTP anschaue fängt ja der Server mit dem Initiieren der FTP Data-Session an. Wieso fängst du mit der Clientseite an? Beim passiven fängt der Client mit dem Initiieren an.
Ich rede hier immer von der Erstinittierung. Die geht ja nun mal immer vom Client aus. Beim aktiven FTP, in weiterer Stufe, versucht dann aber der Server zusätzlich eine Session zu eröffnen.Was ich weiter nicht verstehe diese beiden Grafiken mit aktivem und passivem FTP unter http://slacksite.com/other/ftp.html dort die Datenübertragungs-Session. Einmal stellt der Server die Anfrage um Daten zusenden zu dürfen (aktives FTP). Das klappt nicht wie du sagst weil keine gültige Session zustande kommt.
Beim passivem FTP initiiert der Client auf einem anderen Port "2024" die Verbindung dort klappt dann die Kommunikation. Lag es an diesem 2024 Port oder wieso klappt im passivem Mode die Kommunikation?
Es klappt jetzt weil der Client dem Server sagt, mach bitte noch einen Port zwischen 1024 und 5000 auf und wir wickeln den rest über diesen Port ab. Der Server erlaubt die Anfragen dann auch auf diesem Port vom Client.Beim passivem FTP initiiert der Client auf einem anderen Port "2024" die Verbindung dort klappt dann die Kommunikation. Lag es an diesem 2024 Port oder wieso klappt im passivem Mode die Kommunikation?
Was für eine Rolle spielt das den ob jetzt Port 21 oder Port 1024? Wieso werden beim passiven FTP nicht auf dem Port 21 die Daten verschickt?
Weiter im passivem Mode stellt auch ein Client im LAN zu WAN (Server) eine Verbindung obwohl es dazu keine Session gibt und trotzdem klappt die Verbindung. Du hast gesagt die Kommunikation muss immer vom LAN ausgehend zu WAN sein. Genau das Gegenteil macht doch der passive Mode aus Sicht des Servers.
Nein, auch hier startet der Client die Kommunikation auf Port 21. Nur sagt er dem Server eben zusätzlich: Mach bitte noch einen anderen Port auf damit wir die Daten austauschen können weil wenn ich einen aufmachen muss, bleibst du an meiner Firewall hängen.Ja, FTP Port 21 (commands) ist bei beiden Modellen passiv und aktiv gleich. Aber der Datenfluss ist nicht gleich das verstehe ich nicht. Der jenige der die Verbindung initiiert lässt auch Daten zu?? Also als Beispiel: Wenn der Client Daten an den Server schicken will muss der Server dem Client sagen wenn du mir etwas schicken willst musst du das auf diesem Port tun 21?
Hingegen wenn der Server mit dem Client kommunizieren möchte, muss der Client zum Server eine Verbindung initiieren und sagen die Daten kannst du mir auf diesem Port XY schicken. Danach erst kann der Server die Daten dem Client schicken.
Nochmal, warum sollte ein FTP Server eine Verbindung zu einem Client aufbauen? Welchen Zweck soll das erfüllen?5. Frage
Ich möchte gerne wissen was dieses "Port-Triggering-Regeln" bedeutet.
https://de.wikipedia.org/wiki/Portweiterleitung#Port_TriggeringIch möchte gerne wissen was dieses "Port-Triggering-Regeln" bedeutet.
Ist etwas sicherer als reines Port Forwarding. Beim Port-Forwarding ist der Port immer offen, beim Port-Triggering erst wenn auch von Innen nach Außen eine Anfrage stattgefunden hat.
Von Innen nach Aussen? Wieso den das? Im normal Fall kommt von aussen (WAN) nach LAN eine Anfrage z. B um auf meinen RDP-Server zuzugreifen.
Es geht immer von der Quellseite zur Zielseite. Sind wir uns hier einig?
Edit:/ Vor lauter Schreiben viel zu langsam
Zitat von @aqui:
Der URL http://computer.howstuffworks.com/nat.htm ist eigentlich der originale Cisco Artikel zur NAT Funktion !
Leider findet man den nicht mehr auf Ciscos Seite was sehr schade ist, denn dort wird wirklich umfassend und genau geschicldert was NAT ist und wie es im Einzelnen funktioniert.
Du musst aber zwingend den Text zu den Bildern lesen, sonst nützt das nix !!
Der URL http://computer.howstuffworks.com/nat.htm ist eigentlich der originale Cisco Artikel zur NAT Funktion !
Leider findet man den nicht mehr auf Ciscos Seite was sehr schade ist, denn dort wird wirklich umfassend und genau geschicldert was NAT ist und wie es im Einzelnen funktioniert.
Du musst aber zwingend den Text zu den Bildern lesen, sonst nützt das nix !!
Der Text ist in englisch solch kompliziertes Zeugs auch noch in englisch da verstehe ich überhaupt nix mehr. Ich möchte genau wissen wie die Funktionsweise ist von NAT ist das Bild nunmal sagt das leider nicht aus. Kannst du das eventuell ganz simpel in Worten erklären wie NAT funktioniert? Ich stells mir so ähnlich vor wie PAT aber einfach OHNE Ports sondern und anstelle von Ports externe IP-Adressen.
Aha also Sicherheit? Jetzt muss ich nur noch verstehen wieso, es auch sicherer ist.
Das meinte er auf die Sicherheit bei Firewalls und PAT / NAT bezogen !! NICHT auf die Sicherheit von FTP.Als FTP standartisiert wurde gab es sowas wie PAT noch gar nicht, vergiss das nicht ! Das protokoll ist niemals für die Verwendung mit PAT gemacht worden damals. Daher kommt auch die spätere Anpassung mit passive FTP Mode ! Nachdenken !!!
Aha. Also ist aktives FTP veraltet und passives FTP neu? Also sollte ich auf dem Server immer passives FTP benutzen oder beides zulassen?
Wieso werden beim passiven FTP nicht auf dem Port 21 die Daten verschickt?
Weil das bei passive FTP so vorgesehen ist !Hier machte eben der Client die Data Connection auf und NICHT der Server wie bei Active FTP. Das ist der ganze Witz dabei. Dadurch gibt es einen Session Eintrag in der PAT Tabelle und die Data Verbindung wird aufgebaut.
Achso also wird im passivem Mode der Port 21 für die Daten gar NICHT genutzt sondern der Client bittet den Server irgend einen freien Port zu öffnen. Also der Sessiontabellen Eintrag wird beim Client erstellt da er die Verbindung zum Server initiiert = (Outbound-Session)? Also auf Seiten des Client gibt nun eine Outbound-Session. Auf dieser Outbound-Session kann nun der Server dem Client Daten schicken diese Daten kommen beim Client als inbound Traffic rein?
Im ersten Schritt baut der Client im passiven Mode eine Verbindung über den Server Port 21 (Commands) zum Server her. Beim Server kommt diese Anfrage rein aber eigentlich müsste der Server die Verbindung ablehnen bzw. PAT / NAT Firewall mit dem Grund, dass keine gültige Outbound-Session existiert? Oder macht Port Forwarding, dass eine gültige Outbound-Session offen ist und darum klappts?! Würde doch Sinn machen?
Genauso wie es beim aktiven Mode ja auch der Fall ist dort wird auch die Verbindung bzw. Pakete gedrop weil keine gültige Outbound-Session vorhanden ist?
Andersrum bei Active initiiert der Server die Verbindung und dann kommt eine eingehende Data Verbindung am PAT an OHNE das einen Session von intern da ist, was PAT dann mit einem Paket Drop beantwortet.
Ist doch oben nun wirklich dir schon 4mal !! erklärt worden und das Bild hier:
http://slacksite.com/other/ftp.html
Erklärt das doch nun eindeutig !
Ist doch oben nun wirklich dir schon 4mal !! erklärt worden und das Bild hier:
http://slacksite.com/other/ftp.html
Erklärt das doch nun eindeutig !
Hingegen im aktivem Mode ist fest auf Port 20 für die Commands und Port 21 für die Daten festgelegt? Also dropen tut das Paket die PAT / NAT Firewall auf der Client-Seite da dort kein Outbound-Eintrag besteht?
Aber was ich komische finde ist, beim passiven Mode bittet der Client den Server einen Port für die Daten zu öffnen. Beim Server existiert doch auch keine Outbound-Session Eintrag und trotzdem kommt die Verbindung zustande?
Der jenige der die Verbindung initiiert lässt auch Daten zu??
Wenn keine PAT Firewall dazwischen ist ja...hier ist aber eine dazwischen !Wie komme ich den sonst durch die PAT-Firewall auf Seiten des Clients? Doch nur indem der Client eine Outbound-Session zum Server herstellt. Dann kann der Server Daten schicken und kommt so durch die PAT-Firewall des Clients? Hingegen wenn ich als Client dem Server Daten schicken möchte müsste auf seiten des Servers zuerst eine Outound-Session bestehen damit ich als Client durch die PAT-Firewall des Server komme?
solch kompliziertes Zeugs auch noch in englisch da verstehe ich überhaupt nix mehr.
Das ist dann aber dein Problem ! Die IT ist nun mal 98% Englisch !Ich möchte genau wissen wie die Funktionsweise ist von NAT
Ist kinderleicht. Es gibt Source und Destination NAT. Bei einem wird die Source IP Adresse des Pakets ausgetauscht beim anderen die Destination IP.Muss man mehr wissen ?? Eigentlich nein...!
Also ist aktives FTP veraltet und passives FTP neu?
Jein.... veraltet kann man nicht sagen. Angepasst wäre besser.Aber was ich komische finde ist, beim passiven Mode bittet der Client den Server einen Port für die Daten zu öffnen.
Wieder falsch verstanden...Cleint sagt zum Server: He ich mach gleich ne Datenverbindung auf Port xyz auf nur das du weisst und den Port ready for takeoff hast....!
Dann macht der Client ! die Verbindung auf.
Andersrum hättest du ja wieder das gleiche in Grün wie bei Active...
Wie komme ich den sonst durch die PAT-Firewall auf Seiten des Clients?
Das geht immer ! Outbound Sessions lässt der PAT Prozess alles raus und eröffnet einen Sessioneintrag.Inbound lässt er nur das rein was einen gültigen Eintrag hat. Ohne outbound also kein inbound bei PAT. Deshalb schlägt ja auch active FTP fehl und diverse andere Protokolle auch.
Hingegen wenn ich als Client dem Server Daten schicken möchte müsste auf seiten des Servers zuerst eine Outound-Session bestehen damit ich als Client durch die PAT-Firewall des Server komme?
Nein !Die bestehende Outbound Session bezieht sich NICHT auf den Server sondern auf das PAT !!! Dort muss die Session vorhanden sein !
Zitat von @michi1983:
Ev. hilft ja das hier:
NAT ist nix anderes als eine Möglichkeit mehrer Geräte eines LAN, gleichzeitig mit dem Internet kommunzieren zu lassen.
Wenn du mit einem Client aus dem Netz 192.168.0.0/24 ohne NAT z.B. www.google.de ansurfen möchtest, schickst du einen Request ins Internet raus und Google sieht als Absender z.b. die 192.168.0.10 und möchte dir eine Antwort schicken. Was glaubst du was passiert?
Was glaubst du wie viele Menschen auf dieser Welt Computer zu Hause stehen, die allesamt die selbe IP Adresse haben? Nämlich die 192.168.0.10. Das Paket geht schlicht weg verloren. NAT nimmt also deine IP Adresse 192.168.0.10 und die Ziel IP und speichert die in der NAT Table, maskiert deine LAN IP mit der öffentlichen IP die du an deinem Internet Anschluss hast und schickt das Paket an Google weiter. Google sieht nun wieder eine Absender IP, nur diesmal ist die eindeutig und schickt eine Antwort zurück. Dein NAT-Router bekommt das Paket, sieht in seiner Tabelle nach und sieht nun, dass die Absender IP gleich einer Ziel IP eines Eintrags in seiner NAT TAble ist und weiß somit welcher Client die Anfrage gestellt hat und leitet das Paket dorthin weiter.
Zitat von @osze90:
Kannst du mir bitte noch Frage 2+3 beantworten. Dankeschön
Danke für den Link. Ich kann mir aus diesem Bild nicht vorstellen wie NAT genau funktioniert. Dort steht nur Outbound und Inbound aber ich sehe nicht genau in die Datenpakete oder sogar ins TCP-Segment hinein wie bei http://kohnlehome.de/netz/Masquerading.swf. Die verlinkte Grafik erklärt ja richtig wie das abgeht da kann man sich ein Bild machen. Kannst du mir das bitte erklären?
Kannst du mir bitte noch Frage 2+3 beantworten. Dankeschön
Zitat von @michi1983:
1. Frage
Ich verstehe noch nicht wie NAT funktioniert. Anhand dieser Grafik http://kohnlehome.de/netz/Masquerading.swf habe ich verstanden wie PAT funktioniert. Kennst du auch so eine Grafik für NAT? Wie funktioniert den NAT?
http://computer.howstuffworks.com/nat.htmIch verstehe noch nicht wie NAT funktioniert. Anhand dieser Grafik http://kohnlehome.de/netz/Masquerading.swf habe ich verstanden wie PAT funktioniert. Kennst du auch so eine Grafik für NAT? Wie funktioniert den NAT?
Danke für den Link. Ich kann mir aus diesem Bild nicht vorstellen wie NAT genau funktioniert. Dort steht nur Outbound und Inbound aber ich sehe nicht genau in die Datenpakete oder sogar ins TCP-Segment hinein wie bei http://kohnlehome.de/netz/Masquerading.swf. Die verlinkte Grafik erklärt ja richtig wie das abgeht da kann man sich ein Bild machen. Kannst du mir das bitte erklären?
Ev. hilft ja das hier:
NAT ist nix anderes als eine Möglichkeit mehrer Geräte eines LAN, gleichzeitig mit dem Internet kommunzieren zu lassen.
Wenn du mit einem Client aus dem Netz 192.168.0.0/24 ohne NAT z.B. www.google.de ansurfen möchtest, schickst du einen Request ins Internet raus und Google sieht als Absender z.b. die 192.168.0.10 und möchte dir eine Antwort schicken. Was glaubst du was passiert?
Was glaubst du wie viele Menschen auf dieser Welt Computer zu Hause stehen, die allesamt die selbe IP Adresse haben? Nämlich die 192.168.0.10. Das Paket geht schlicht weg verloren. NAT nimmt also deine IP Adresse 192.168.0.10 und die Ziel IP und speichert die in der NAT Table, maskiert deine LAN IP mit der öffentlichen IP die du an deinem Internet Anschluss hast und schickt das Paket an Google weiter. Google sieht nun wieder eine Absender IP, nur diesmal ist die eindeutig und schickt eine Antwort zurück. Dein NAT-Router bekommt das Paket, sieht in seiner Tabelle nach und sieht nun, dass die Absender IP gleich einer Ziel IP eines Eintrags in seiner NAT TAble ist und weiß somit welcher Client die Anfrage gestellt hat und leitet das Paket dorthin weiter.
Hast du gut erklärt, so einigermassen kann ich mir das Vorstellen, ein Bild würde jedoch vielmehr aussagen.
Aqui hat mir bereits diesen Link zugeschickt http://www.tcp-ip-info.de/tcp_ip_und_internet/ip_masquerading.htm. Mit NAT lassen sich mehrere private IP-Adressen zu öffentlichen IP-Adressen mappen.
Hingegen wenn der Server mit dem Client kommunizieren möchte, muss der Client zum Server eine Verbindung initiieren und sagen die Daten kannst du mir auf diesem Port XY schicken. Danach erst kann der Server die Daten dem Client schicken.
Nochmal, warum sollte ein FTP Server eine Verbindung zu einem Client aufbauen? Welchen Zweck soll das erfüllen?Auflisten des Directories z. B ../root/bilder/katzen -> katzte_tiger.jpg, katzte_schwarz.png. Aber hauptsächlich bezieht der Client vom Server die Dateien.
5. Frage
Ich möchte gerne wissen was dieses "Port-Triggering-Regeln" bedeutet.
https://de.wikipedia.org/wiki/Portweiterleitung#Port_TriggeringIch möchte gerne wissen was dieses "Port-Triggering-Regeln" bedeutet.
Ist etwas sicherer als reines Port Forwarding. Beim Port-Forwarding ist der Port immer offen, beim Port-Triggering erst wenn auch von Innen nach Außen eine Anfrage stattgefunden hat.
Von Innen nach Aussen? Wieso den das? Im normal Fall kommt von aussen (WAN) nach LAN eine Anfrage z. B um auf meinen RDP-Server zuzugreifen.
Es geht immer von der Quellseite zur Zielseite. Sind wir uns hier einig?
Edit:/ Vor lauter Schreiben viel zu langsam
Port-Triggerin öffnet den Port wenn von Client-Seite (LAN) also die Quelle zu Ziel (WAN) eine Anfrage startet dann ist der Port offen bzw. wird der Port geöffnet? Der Umgekehrte Weg wäre ja weniger sinnlos das soll ja verhindert werden mit Port Triggering.
Zitat von @aqui:
Muss man mehr wissen ?? Eigentlich nein...!
Ich möchte genau wissen wie die Funktionsweise ist von NAT
Ist kinderleicht. Es gibt Source und Destination NAT. Bei einem wird die Source IP Adresse des Pakets ausgetauscht beim anderen die Destination IP.Muss man mehr wissen ?? Eigentlich nein...!
Als ich mir den Wiki-Artikel über NAT durchgelesen habe, habe ich es so verstanden, dass Destination- und Source-Nat zwei unterschiedliche Arten von NAT sind. Das scheint laut deiner Aussage nicht so zu sein?
| ROUTER |
Aber was ich komische finde ist, beim passiven Mode bittet der Client den Server einen Port für die Daten zu öffnen.
Wieder falsch verstanden...Cleint sagt zum Server: He ich mach gleich ne Datenverbindung auf Port xyz auf nur das du weisst und den Port ready for takeoff hast....!
Dann macht der Client ! die Verbindung auf.
Andersrum hättest du ja wieder das gleiche in Grün wie bei Active...
Passiv Mode:
Also sagt der Client dem Server er möchte auf Port xy eine Verbindung herstellen sodass der Port reserviert ist. Das heisst also PAT-Router auf Seiten des Client macht eine Outbound-Session. Der Server bestätigt das mit ACK. Danach initiiert der Client die Verbindung zum Server auf dem definierten Port. Richtig?
Aktive Mode:
Sagt Server zu Client ich möchte auf Port 21 eine Verbindung aufbauen. Das ist eine Outbound-Session auf der Seite des Server. Beim Client kommt diese Anfrage des Servers an, da aber kein gültiger Outbound-Eintrag existiert dropt der PAT-Router an dem der Client hängt das Datenpaket. Richtig?
Aber was ich mir jetzt überlegt habe:
Was ich nun nicht verstehe ist, beim passiven Mode:
Der Client will sich mit dem Server verbinden es gibt einen Outbound-Eintrag. Das habe ich verstanden. Aber nun kommts:
Auf der Seite des Server existiert doch gar kein Outbound-Eintrag da die Anfrage vom Client kam. Wieso dropt die PAT-Firewall in diesem Fall nicht das Datenpaket, lässt die Verbindung zu? Liegt das daran, dass eine Port Forwarding eingerichtet wurde? Komme ich bei Port Forwarding durch eine PAT-Firewall obwohl kein Outbound-Session gibt?
Wenn das jetzt alles so stimmt habe ich die Zusammenhänge endlich verstanden. Hoffe es stimmt alles...
Hingegen wenn ich als Client dem Server Daten schicken möchte müsste auf seiten des Servers zuerst eine Outound-Session bestehen damit ich als Client durch die PAT-Firewall des Server komme?
Nein !Die bestehende Outbound Session bezieht sich NICHT auf den Server sondern auf das PAT !!! Dort muss die Session vorhanden sein !
Ich habe mich wohl nicht genug gut ausgedrückt, ich meinte die Outbound-Session auf dem PAT-Router auf seiten des Servers. Das ist mir klar das diese Outbound-Sessions der PAT-Router macht, hinter dem PAT-Router hängt dann der Server oder ein Client das ist mir mir schon klar.
Zitat von @osze90:
Der Client will sich mit dem Server verbinden es gibt einen Outbound-Eintrag. Das habe ich verstanden. Aber nun kommts:
Auf der Seite des Server existiert doch gar kein Outbound-Eintrag da die Anfrage vom Client kam. Wieso dropt die PAT-Firewall in diesem Fall nicht das Datenpaket, lässt die Verbindung zu? Liegt das daran, dass eine Port Forwarding eingerichtet wurde? Komme ich bei Port Forwarding durch eine PAT-Firewall obwohl kein Outbound-Session gibt?
Muss es auch nicht! Es ist ja der SERVER. Der wartet ja nur darauf, dass dort eine Anfrage kommt. Das ist der Sinn eines Servers bzw. ist die Firewall auf dem Server so konfiguriert, dass diese Anfragen alle durch kommen.Der Client will sich mit dem Server verbinden es gibt einen Outbound-Eintrag. Das habe ich verstanden. Aber nun kommts:
Auf der Seite des Server existiert doch gar kein Outbound-Eintrag da die Anfrage vom Client kam. Wieso dropt die PAT-Firewall in diesem Fall nicht das Datenpaket, lässt die Verbindung zu? Liegt das daran, dass eine Port Forwarding eingerichtet wurde? Komme ich bei Port Forwarding durch eine PAT-Firewall obwohl kein Outbound-Session gibt?
Die Passive Darstellung oben ist richtig. Die Active nicht...leider obwohl sie schon zig mal oben beschrieben wurde....
Client der ja eine outbount Kommando Session TCP 21 zum Server hat über den PAT Router sendet ein GET Kommando an den FTP Server.
Damit sagt er ihm das er Daten haben will.
Daraufhin öffnet der Server eine TCP 20 Data Session auf den Client. Der PAT Router sieht nun aber eine einkommende neue Sessions des Servers zu dem er KEINE Outbound Session in der Sesion Tabble hat, folglich droppt also der PAT Router diese Session und blockt sie somit.
Deshalb klappt kein Active FTP.
Bei Passive initiiert der Client die Data Session und schafft so einen gültigen Session Eintrag wie du ja selber richtig schon beschrieben hast.
Zusammengefasst:
Beim Passive Mode initiiert bei FTP der Client beide Sessions also die Command und die Data Session zum Server so das es beim PAT Router keine Probleme gibt.
Bei Actibe initiiert eben der Server die Data Session und das führt dann beim PAT dazu das diese Outbound Session geblockt wird da keinerlei Data Inbound Session zu Server besteht !
FTP Verbindungen bestehen immer aus 2 ! TCP Sessions...das ist die Besonderheit bei FTP.
SCP oder SMB/CIFS oder iSCSI oder NFS als File Transfer Protopkolle haben diesen Duialismus nicht.
Client der ja eine outbount Kommando Session TCP 21 zum Server hat über den PAT Router sendet ein GET Kommando an den FTP Server.
Damit sagt er ihm das er Daten haben will.
Daraufhin öffnet der Server eine TCP 20 Data Session auf den Client. Der PAT Router sieht nun aber eine einkommende neue Sessions des Servers zu dem er KEINE Outbound Session in der Sesion Tabble hat, folglich droppt also der PAT Router diese Session und blockt sie somit.
Deshalb klappt kein Active FTP.
Bei Passive initiiert der Client die Data Session und schafft so einen gültigen Session Eintrag wie du ja selber richtig schon beschrieben hast.
Zusammengefasst:
Beim Passive Mode initiiert bei FTP der Client beide Sessions also die Command und die Data Session zum Server so das es beim PAT Router keine Probleme gibt.
Bei Actibe initiiert eben der Server die Data Session und das führt dann beim PAT dazu das diese Outbound Session geblockt wird da keinerlei Data Inbound Session zu Server besteht !
FTP Verbindungen bestehen immer aus 2 ! TCP Sessions...das ist die Besonderheit bei FTP.
SCP oder SMB/CIFS oder iSCSI oder NFS als File Transfer Protopkolle haben diesen Duialismus nicht.
Zitat von @aqui:
Die Active nicht...leider obwohl sie schon zig mal oben beschrieben wurde....
Client der ja eine outbount Kommando Session TCP 21 zum Server hat über den PAT Router sendet ein GET Kommando an den FTP Server.
Damit sagt er ihm das er Daten haben will.
Daraufhin öffnet der Server eine TCP 20 Data Session auf den Client. Der PAT Router sieht nun aber eine einkommende neue Sessions des Servers zu dem er KEINE Outbound Session in der Sesion Tabble hat, folglich droppt also der PAT Router diese Session und blockt sie somit.
Deshalb klappt kein Active FTP.
Die Active nicht...leider obwohl sie schon zig mal oben beschrieben wurde....
Client der ja eine outbount Kommando Session TCP 21 zum Server hat über den PAT Router sendet ein GET Kommando an den FTP Server.
Damit sagt er ihm das er Daten haben will.
Daraufhin öffnet der Server eine TCP 20 Data Session auf den Client. Der PAT Router sieht nun aber eine einkommende neue Sessions des Servers zu dem er KEINE Outbound Session in der Sesion Tabble hat, folglich droppt also der PAT Router diese Session und blockt sie somit.
Deshalb klappt kein Active FTP.
Ok. Also nochmals zur Bestätigung ab TCP 20:
Der PAT-Router beim Client sieht also keinen Outbound-Session Eintrag für diese TCP 20 darum dropt er. Eigentlich ganz einfach
Bei Passive initiiert der Client die Data Session und schafft so einen gültigen Session Eintrag wie du ja selber richtig schon beschrieben hast.
Zusammengefasst:
Beim Passive Mode initiiert bei FTP der Client beide Sessions also die Command und die Data Session zum Server so das es beim PAT Router keine Probleme gibt.
Zusammengefasst:
Beim Passive Mode initiiert bei FTP der Client beide Sessions also die Command und die Data Session zum Server so das es beim PAT Router keine Probleme gibt.
Verstanden! Aber siehe unten
Aber was ich mir jetzt überlegt habe:
Was ich nun nicht verstehe ist, beim passiven Mode:
Der Client will sich mit dem Server verbinden, es gibt einen Outbound-Eintrag auf Seiten des PAT-Router des Clients. Das habe ich verstanden. Aber nun kommts:
Auf der Seite des Server existiert doch gar kein Outbound-Eintrag da die Anfrage vom Client kam. Wieso dropt die PAT-Firewall in diesem Fall nicht das Datenpaket, lässt die Verbindung zu? Liegt das daran, dass eine Port Forwarding eingerichtet wurde? Komme ich bei Port Forwarding durch eine PAT-Firewall obwohl kein Outbound-Session gibt?
Nochmals: Wieso kann der Client eine Verbindung zum Server herstellen, dass danach die Daten des Servers problemlos durch die PAT-Firewall des Clients kommen obwohl auf Seiten des Servers keine Outbound-Session besteht sondern nur beim Client? Der Server kann Daten durch die Outbound-Session des Client senden aber umgekehrt Daten vom Client zu Server wieso klappt das obwohl Server keine Outbound-Session hat? Hoffe verstehst was ich meine.
Kannst du mir bitte noch sagen ob meine Darstellung zu der Funktionsweise von NAT stimmt:
Als ich mir den Wiki-Artikel über NAT durchgelesen habe, habe ich es so verstanden, dass Destination- und Source-Nat zwei unterschiedliche Arten von NAT sind. Das scheint laut deiner Aussage nicht so zu sein?
| ROUTER |
Kannst du mir bitte noch die unbeantwortete Fragen bezüglich Protokollen ohne Port und NAT-Pooling beantworten:
2. Frage
So wie ich dich verstanden habe, gibts nur Session bei Protokollen die Ports haben. Bei GRE oder ESP (die Protokolle haben ja keine Ports) kann nur anhand einer höheren OSI-Schicht die Session zugeordnet werden und mit Hilfe der Protokollnummer. Möchte wissen wie das der Router einer Session zuordnen kann wenn das Protokoll keine Ports benutzt. Werden da eventuell auch auf einer anderen OSI-Schicht Ports benutzt? Z. B:
3. Frage
Verstehe noch nicht ganz das NAT-Pooling.
Also nochmals als Zusammenfassung zum NAT-Pooling: Pooling wird dann eingesetzt wenn Clients dynamisch eine WAN-IP-Adressen brauchen (z. B für die Kommunikation ins Internet) und es nicht soviele WAN-IP-Adressen gibt um jedem Server eine statische WAN-IP zu vergeben. Als Lösung bezieht nur der jenige Server eine WAN-IP der gerade ins Internet kommunizieren möchte? Habe ich das so richtig verstanden?
Aber wo z. B ist ein Einsatzort für NAT-Pooling? NAT wird doch nur eingesetzt bei Servern und da ein Server im normal Fall eine statische WAN-IP-Adresse haben muss / sollte wozu dann das Pooling? Oder ist Pooling mehr als Outbound Kommunikation gedacht?
Jeder Server braucht ja eine private IP-Adresse und eine öffentliche IP-Adresse beim Pooling bekommt ja mal Server A eine WAN-IP um durch die NAT gehen zu dürfen mal Server B während dieser Zeit ist ja Server A nicht erreichbar da die WAN-IP-Adresse für Server B reserviert ist.
Auf der Seite des Server existiert doch gar kein Outbound-Eintrag da die Anfrage vom Client kam.
Das ist richtig ! Deshalb sendet der Client ja eine Info über den Kommando Port 21 an den Server:Achtung Herr Server ich mache jetzt passive Mode und ich komme gleich bei dir mit einer Data Session auf Port xyz rein !!
Dann weiss der Server das dieser spezifische Client auf Port xyz ihm nun Daten schickt.
Jetzt initiiert der Clietn die Daten Session via PAT Router zum Server.
Der antwortet dann mit einem Syn ACK was durch den PAT Router auch wieder zurück geht da ja jetzt die Session besteht und dann startet der Client den Datentransfer.
Auch die Prozedur ist oben schon mehrfach erklärt worden und wenn du dir das Bild des Sessionhandlings endlich mal in
http://slacksite.com/other/ftp.html
angesehen hättest hätten wir uns das hier ersparen können !!!
Sieh dir doch bitte bitte dort auf der Seite einfach nur mal die Punkteliste der einzelnen Sessionschritte an und die Zeichnung darunter !!!
Das versteht doch dann auch jeder Dummie wie das geht.... Sorry
Hoffe das ist nun endlich klar das einmal der Server von außen initiiert (Active) und einmal der Client von innen (Passive). Genau das innen und außen macht aber für den PAT Prozess den eintscheidenden Unterschied.
dass Destination- und Source-Nat zwei unterschiedliche Arten von NAT sind. Das scheint laut deiner Aussage nicht so zu sein?
Na ja kommt darauf an was man mit "unterschiedlich" definiert.Grundsätzlich ist es erst einmal NAT.
Beim einen wird die Destination IP im Paket manipuliert beim anderen die Source IP.
Ist so wie als wenn du mit dem Auto tanken fährst und einmal Benzin und einmal Diesel tankst. Tanken bleibt aber tanken und damit ist der Prozess immer gleich. Aufs NAT bezogen ist das dann identisch.
So wie ich dich verstanden habe, gibts nur Session bei Protokollen die Ports haben. Bei GRE oder ESP (die Protokolle haben ja keine Ports) kann nur anhand einer höheren OSI-Schicht die Session zugeordnet werden und mit Hilfe der Protokollnummer.
Das ist genau richtig so.Möchte wissen wie das der Router einer Session zuordnen kann wenn das Protokoll keine Ports benutzt.
Das ist dann Protokoll spezifisch. Der Router "sieht" dann in den Datenbereich des entsprechenden Pakets und identifiziert hier Session IDs oder Paket Numbering je nach Protokoll und ordnet das dann einer Session zu. Das ist bei jeden dieser Protokolle spezifisch und muss der Router können. Deshalb sind diese Router "etwas" teurer als die billigen Consumer teile die das in der Regel nicht können.Aber wo z. B ist ein Einsatzort für NAT-Pooling?
Immer da wo es eine Mangelverwaltung von Adressen gibt. Also mehrere Clients die sich eine begrenzte Menge von Translation IPs teilen sei es Destination oder Source IPs.NAT wird doch nur eingesetzt bei Servern
Nein, da sist völliger Quatsch. Es wird natürlich auch bei Clients eingesetzt. Stell dir 20 Clients vor die in einem Zielnetz mit einer anderen Source IP auftauchen müssen als sie ursprünglich haben !Du hast diese 20 Clients aber nur 10 IP Adressen. Da kommt dann NAT Pooling ins Spiel. Pooling geht aber imemr davon aus das diese 20 niemals zur gleichen Zeit arbeiten.
Zitat von @aqui:
Achtung Herr Server ich mache jetzt passive Mode und ich komme gleich bei dir mit einer Data Session auf Port xyz rein !!
Dann weiss der Server das dieser spezifische Client auf Port xyz ihm nun Daten schickt.
Jetzt initiiert der Clietn die Daten Session via PAT Router zum Server.
Der antwortet dann mit einem Syn ACK was durch den PAT Router auch wieder zurück geht da ja jetzt die Session besteht und dann startet der Client den Datentransfer.
Auch die Prozedur ist oben schon mehrfach erklärt worden und wenn du dir das Bild des Sessionhandlings endlich mal in
http://slacksite.com/other/ftp.html
angesehen hättest hätten wir uns das hier ersparen können !!!
Sieh dir doch bitte bitte dort auf der Seite einfach nur mal die Punkteliste der einzelnen Sessionschritte an und die Zeichnung darunter !!!
Das versteht doch dann auch jeder Dummie wie das geht.... Sorry
Hoffe das ist nun endlich klar das einmal der Server von außen initiiert (Active) und einmal der Client von innen (Passive). Genau das innen und außen macht aber für den PAT Prozess den eintscheidenden Unterschied.
Auf der Seite des Server existiert doch gar kein Outbound-Eintrag da die Anfrage vom Client kam.
Das ist richtig ! Deshalb sendet der Client ja eine Info über den Kommando Port 21 an den Server:Achtung Herr Server ich mache jetzt passive Mode und ich komme gleich bei dir mit einer Data Session auf Port xyz rein !!
Dann weiss der Server das dieser spezifische Client auf Port xyz ihm nun Daten schickt.
Jetzt initiiert der Clietn die Daten Session via PAT Router zum Server.
Der antwortet dann mit einem Syn ACK was durch den PAT Router auch wieder zurück geht da ja jetzt die Session besteht und dann startet der Client den Datentransfer.
Auch die Prozedur ist oben schon mehrfach erklärt worden und wenn du dir das Bild des Sessionhandlings endlich mal in
http://slacksite.com/other/ftp.html
angesehen hättest hätten wir uns das hier ersparen können !!!
Sieh dir doch bitte bitte dort auf der Seite einfach nur mal die Punkteliste der einzelnen Sessionschritte an und die Zeichnung darunter !!!
Das versteht doch dann auch jeder Dummie wie das geht.... Sorry
Hoffe das ist nun endlich klar das einmal der Server von außen initiiert (Active) und einmal der Client von innen (Passive). Genau das innen und außen macht aber für den PAT Prozess den eintscheidenden Unterschied.
Mir ist ja nun klar wie Aktives und Passives FTP funktioniert auch der Unterschied ist mir jetzt klar ABER eines interessiert mich trotzdem noch:
Wieso komme ich als Client durch die PAT-Firewall beim Server obwohl beim Server KEIN Outbound-Session Eintrag besteht sondern NUR beim PAT-Router auf Seiten des Clients.
Ich komme als Server ja auch NICHT durch die PAT-Firewall des Client wenn nicht der Client zuerst einen Outbound-Eintrag macht zum Server. Wieso akzeptiert der PAT-Router beim Server die Anfrage des Client obwohl dort kein Outbound-Eintrag existiert. Liegt es an Port Forwarding, dass dort kein Outbound-Session Eintrag gebraucht wird? Hoffe du verstehst was ich meine...
Die von dir verlinkte Seite ich habe mir bereits um die 10 x angesehen.
dass Destination- und Source-Nat zwei unterschiedliche Arten von NAT sind. Das scheint laut deiner Aussage nicht so zu sein?
Na ja kommt darauf an was man mit "unterschiedlich" definiert.Grundsätzlich ist es erst einmal NAT.
Beim einen wird die Destination IP im Paket manipuliert beim anderen die Source IP.
Ist so wie als wenn du mit dem Auto tanken fährst und einmal Benzin und einmal Diesel tankst. Tanken bleibt aber tanken und damit ist der Prozess immer gleich. Aufs NAT bezogen ist das dann identisch.
Ich weiss, dass einmal die Ziel und mal Source Adresse durch eine andere Adresse ersetzt wird steht ja bei Wiki. Ich möchte verstehen wie NAT funktioniert wie ich mir die Funktionsweise vorstellen muss:
| ROUTER |
So stelle ich mir die Funktionsweise von NAT vor ähnlich wie bei PAT aber halt OHNE Ports stimmt das so?
Möchte wissen wie das der Router einer Session zuordnen kann wenn das Protokoll keine Ports benutzt.
Das ist dann Protokoll spezifisch. Der Router "sieht" dann in den Datenbereich des entsprechenden Pakets und identifiziert hier Session IDs oder Paket Numbering je nach Protokoll und ordnet das dann einer Session zu. Das ist bei jeden dieser Protokolle spezifisch und muss der Router können. Deshalb sind diese Router "etwas" teurer als die billigen Consumer teile die das in der Regel nicht können.Also kann man sagen, dass die Router so intelligent sind und merken wenn ich Beispielsweise:
1 x Router habe
1 x IKEv2 VPN Server
Wenn nun Client A und Client B gleichzeitig mit dem VPN Server kommunizieren kann der VPN Router Anhang der ESP Pakete unterscheiden von wem an wem das Paket muss? Im Body eines ESP-Paket ist ja der Inhalt eines IP-Datenpakets dort steht ja Destination und Source IP wenn man weiter ins Datenpaket schaut sind dort auch noch im Datensegment die Ports vermerkt. Also nimmt der Router die Informationen um die ESP Pakete zu unterschieden vom IP-Datenpaket und vom Datensegment.
Aber wo z. B ist ein Einsatzort für NAT-Pooling?
Immer da wo es eine Mangelverwaltung von Adressen gibt. Also mehrere Clients die sich eine begrenzte Menge von Translation IPs teilen sei es Destination oder Source IPs.Verstehe ich nicht ganz.
Weiter oben haben wir gesagt wenn viele Client zugriff auf wenige externe IPs stossen benutzt man Pooling. Eigentlich reicht doch eine IP-Adresse um mit NAT ins Internet zu kommunizieren. Verstehe nicht wieso es dann Pooling gibt. Eventuell um von Netz A mit Netz B direkt zu kommunizieren also innerhalb eines Autonomen Systems? Wenn ich z.B 2 Rechenzentren: RZ: Bern mit 212.12.12.10 IP-Adresse und RZ: Zürich mit 212.12.11.10 als IP-ADDR habe?
NAT wird doch nur eingesetzt bei Servern
Nein, da sist völliger Quatsch. Es wird natürlich auch bei Clients eingesetzt. Stell dir 20 Clients vor die in einem Zielnetz mit einer anderen Source IP auftauchen müssen als sie ursprünglich haben !Du hast diese 20 Clients aber nur 10 IP Adressen. Da kommt dann NAT Pooling ins Spiel. Pooling geht aber imemr davon aus das diese 20 niemals zur gleichen Zeit arbeiten.
20 Client die eine LAN IP haben und nur 10 externe IPs? Ich denke an mein Netzwerk von Zuhause dort habe ich doch auch ca. 20 Client aber nur 1 IP-Adresse um ins Internet zu kommunizieren. Wozu benötige ich dann in deinem Beispiel 10 IP-Adresse für diese 20 Clients? Damit ich mir dieses Pooling eventuell besser vorstellen kann, kannst du mir bitte mal ein Beispiel machen. Ich sehe nicht ganz wo Pooling zum Einsatz kommen soll.
Zitat von @osze90:
Mir ist ja nun klar wie Aktives und Passives FTP funktioniert auch der Unterschied ist mir jetzt klar ABER eines interessiert mich trotzdem noch:
Wieso komme ich als Client durch die PAT-Firewall beim Server obwohl beim Server KEIN Outbound-Session Eintrag besteht sondern NUR beim PAT-Router auf Seiten des Clients.
Das habe ich bereits im ersten Kommentar geschrieben.Zitat von @aqui:
Achtung Herr Server ich mache jetzt passive Mode und ich komme gleich bei dir mit einer Data Session auf Port xyz rein !!
Dann weiss der Server das dieser spezifische Client auf Port xyz ihm nun Daten schickt.
Jetzt initiiert der Clietn die Daten Session via PAT Router zum Server.
Der antwortet dann mit einem Syn ACK was durch den PAT Router auch wieder zurück geht da ja jetzt die Session besteht und dann startet der Client den Datentransfer.
Auch die Prozedur ist oben schon mehrfach erklärt worden und wenn du dir das Bild des Sessionhandlings endlich mal in
http://slacksite.com/other/ftp.html
angesehen hättest hätten wir uns das hier ersparen können !!!
Sieh dir doch bitte bitte dort auf der Seite einfach nur mal die Punkteliste der einzelnen Sessionschritte an und die Zeichnung darunter !!!
Das versteht doch dann auch jeder Dummie wie das geht.... Sorry
Hoffe das ist nun endlich klar das einmal der Server von außen initiiert (Active) und einmal der Client von innen (Passive). Genau das innen und außen macht aber für den PAT Prozess den eintscheidenden Unterschied.
Auf der Seite des Server existiert doch gar kein Outbound-Eintrag da die Anfrage vom Client kam.
Das ist richtig ! Deshalb sendet der Client ja eine Info über den Kommando Port 21 an den Server:Achtung Herr Server ich mache jetzt passive Mode und ich komme gleich bei dir mit einer Data Session auf Port xyz rein !!
Dann weiss der Server das dieser spezifische Client auf Port xyz ihm nun Daten schickt.
Jetzt initiiert der Clietn die Daten Session via PAT Router zum Server.
Der antwortet dann mit einem Syn ACK was durch den PAT Router auch wieder zurück geht da ja jetzt die Session besteht und dann startet der Client den Datentransfer.
Auch die Prozedur ist oben schon mehrfach erklärt worden und wenn du dir das Bild des Sessionhandlings endlich mal in
http://slacksite.com/other/ftp.html
angesehen hättest hätten wir uns das hier ersparen können !!!
Sieh dir doch bitte bitte dort auf der Seite einfach nur mal die Punkteliste der einzelnen Sessionschritte an und die Zeichnung darunter !!!
Das versteht doch dann auch jeder Dummie wie das geht.... Sorry
Hoffe das ist nun endlich klar das einmal der Server von außen initiiert (Active) und einmal der Client von innen (Passive). Genau das innen und außen macht aber für den PAT Prozess den eintscheidenden Unterschied.
Mir ist ja nun klar wie Aktives und Passives FTP funktioniert auch der Unterschied ist mir jetzt klar ABER eines interessiert mich trotzdem noch:
Wieso komme ich als Client durch die PAT-Firewall beim Server obwohl beim Server KEIN Outbound-Session Eintrag besteht sondern NUR beim PAT-Router auf Seiten des Clients.
Ein Server ist eben kein Client. Ein Server bietet von sich aus einen Service an. z.B. einen FTP Server. Das heißt, dass auch seine Firewall dementsprechend konfiguriert ist damit eben nix geblockt wird wenn eine Anfrage rein kommt.
Wieso komme ich als Client durch die PAT-Firewall beim Server
Weil der Client ja im inbound Interface des PAT Routers sitz !! Da gehen alle Sessions raus. Blocken tut er nur wenn auf dem Outbound Interface incoming Sessions kommen ohne Table Eintrag.Eins der Basic Grundprizipien von PAT und dafür gibts die Wikipedia oder die Cosco Seite !!!
So stelle ich mir die Funktionsweise von NAT vor ähnlich wie bei PAT aber halt OHNE Ports stimmt das so?
Yepp ! Endlich mal was richtig verstanden Also kann man sagen, dass die Router so intelligent sind und merken wenn ich
Was meinst du mit "die" Router genau ??? Wenn dann diese Router, denn es können nur ein Bruchteil der Hersteller das. Konsumer Gurken wie du sie kennst sind oft von solchen Features ausgenommen.Im Body eines ESP-Paket ist ja der Inhalt eines IP-Datenpakets dort steht ja Destination und Source IP
Nein, das ist wieder schlicht falsch. Im Header stehen die IP Adressen und im Data Segment (was du als "Body" titulierst) findest du diese Infos die für den Router relevant sind.Der Rest ist aber vollkommen richtig !
Weiter oben haben wir gesagt wenn viele Client zugriff auf wenige externe IPs stossen benutzt man Pooling
Ja, und nichts anderes steht auch in dem Satz "Also mehrere Clients die sich eine begrenzte Menge von Translation IPs teilen sei es Destination oder Source IPs." oder siehst du da irgendwo einen Widerspruch ?? Bitte richtig lesen !!!mein Netzwerk von Zuhause dort habe ich doch auch ca. 20 Client aber nur 1 IP-Adresse um ins Internet zu kommunizieren.
Deshalb macht man da ja auch PAT statt NAT.Wozu benötige ich dann in deinem Beispiel 10 IP-Adresse für diese 20 Clients?
Wenn diese Clients jeweils eine separate Absender IP haben müssen aus verscheidenen Gründen. Das müssen nicht Clients sein sondern können auch Server usw. sein.Ist eher was für Netz zu Netz Kopplungen.
Sorry für späte Antwort, habe wieder mit arbeiten begonnen.
Wie meinst du das mit "Weil der Client ja im inbound Interface des PAT Routers sitz" Der Client kommt doch immer durch die PAT-Firewall auf seiten des Server solange die PAT-Firewall auf Seiten des Servers eine offene Session hat. Aber wenn nun auf seiten des Clients die PAT-Firewall eine Session zu einem Server herstellt und dort keine Outbound Session besteht, ist eine Verbindung nicht möglich. Das ist doch meistens der Fall, den der Client fordert vom Server eine Verbindung an. Akzeptiert die PAT-Firewall vom Server alle Inbound-Session an? Die PAT-Firewall des Client hingegen akzeptiert nur alles was einen Outbound-Eintrag hat?
Bevor eine Verbindung bestehen kann muss z. B der Client eine Outbound-Sitzung zum Server eröffnen, der Server antwortet dann. Danach kann ja der Server dem Client anfangen Daten zu schicken. Das ist mir mal soweit klar. Weshalb akzeptiert der Server aber nun den Datenempfang vom Client obwohl beim Server kein Outbound-Eintrag besteht. Den der Client initiiert eine Verbindung zum Server das Heisst beim Client Outbound, beim Server Inbound. Wieso blockt der Server nicht die bei ihm incoming-Session auf der WAN-Schnittstelle?
Der Rest ist aber vollkommen richtig !
Also IP-Paket sind die IP-Adressen Infos, im Datasegment die Port Infos im Ethernet-Frame wiederrum MAC-Adressen. Ein Datenpaket besteht ja immer aus einem Body und Header im Header sind die Infos wie IP-Adresse, MAC, Ports... Im Body die Nutzdaten um z. B um ein Bild darzustellen oder irgend welchen Text? Das ESP steht ja vor einem ESP-Paket (siehe Link zu Bild).
Quelle
Zitat von @aqui:
Eins der Basic Grundprizipien von PAT und dafür gibts die Wikipedia oder die Cosco Seite !!!
Wieso komme ich als Client durch die PAT-Firewall beim Server
Weil der Client ja im inbound Interface des PAT Routers sitz !! Da gehen alle Sessions raus. Blocken tut er nur wenn auf dem Outbound Interface incoming Sessions kommen ohne Table Eintrag.Eins der Basic Grundprizipien von PAT und dafür gibts die Wikipedia oder die Cosco Seite !!!
Wie meinst du das mit "Weil der Client ja im inbound Interface des PAT Routers sitz" Der Client kommt doch immer durch die PAT-Firewall auf seiten des Server solange die PAT-Firewall auf Seiten des Servers eine offene Session hat. Aber wenn nun auf seiten des Clients die PAT-Firewall eine Session zu einem Server herstellt und dort keine Outbound Session besteht, ist eine Verbindung nicht möglich. Das ist doch meistens der Fall, den der Client fordert vom Server eine Verbindung an. Akzeptiert die PAT-Firewall vom Server alle Inbound-Session an? Die PAT-Firewall des Client hingegen akzeptiert nur alles was einen Outbound-Eintrag hat?
Bevor eine Verbindung bestehen kann muss z. B der Client eine Outbound-Sitzung zum Server eröffnen, der Server antwortet dann. Danach kann ja der Server dem Client anfangen Daten zu schicken. Das ist mir mal soweit klar. Weshalb akzeptiert der Server aber nun den Datenempfang vom Client obwohl beim Server kein Outbound-Eintrag besteht. Den der Client initiiert eine Verbindung zum Server das Heisst beim Client Outbound, beim Server Inbound. Wieso blockt der Server nicht die bei ihm incoming-Session auf der WAN-Schnittstelle?
Im Body eines ESP-Paket ist ja der Inhalt eines IP-Datenpakets dort steht ja Destination und Source IP
Nein, das ist wieder schlicht falsch. Im Header stehen die IP Adressen und im Data Segment (was du als "Body" titulierst) findest du diese Infos die für den Router relevant sind.Der Rest ist aber vollkommen richtig !
Also IP-Paket sind die IP-Adressen Infos, im Datasegment die Port Infos im Ethernet-Frame wiederrum MAC-Adressen. Ein Datenpaket besteht ja immer aus einem Body und Header im Header sind die Infos wie IP-Adresse, MAC, Ports... Im Body die Nutzdaten um z. B um ein Bild darzustellen oder irgend welchen Text? Das ESP steht ja vor einem ESP-Paket (siehe Link zu Bild).
Quelle
Wie meinst du das mit "Weil der Client ja im inbound Interface des PAT Routers sitz" Der Client kommt doch immer durch die PAT-Firewall
Ja, richtig. Inbound meint hier das lokale LAN. Ein Client im lokalen LAN kommt immer raus übers PAT..klar ! Eine bestehende Session ist niemals erforderlich vom lokalen Netz nach draußen. Logisch, sonst würde nix gehen.Akzeptiert die PAT-Firewall vom Server alle Inbound-Session an?
Ja wenn es einen von einem lokalen LAN Client initiierte Session ist ja. Dadurch das der vom LAN nach draußen geht kreiiert der ja diese PAT Session und Antworten vom Server zurück gehen dann durch.Dumm ist es nur wenn diese Session (wie bei FTP z.B.) einen neuen Sessionaufbau vom Server triggert. Dann öffnet der Server von außen eine neue Session und die bleibt dann logischerweise an der PAT Firewall hängen, denn die lässt nix von außen nach innen durch ohne gesetztes ACK Bit im Paket.
Klasssiches Verhalten bei PAT !
Also IP-Paket sind die IP-Adressen Infos, im Datasegment die Port Infos im Ethernet-Frame wiederrum MAC-Adressen.
Jau...richtig !Ein Datenpaket besteht ja immer aus einem Body und Header
Ja, grob gesagt ja...bischen mehr ist es schon.Klassischer Aufbau eines Ethernet IP Frames.
https://de.wikipedia.org/wiki/Ethernet
Zitat von @aqui:
Wie meinst du das mit "Weil der Client ja im inbound Interface des PAT Routers sitz" Der Client kommt doch immer durch die PAT-Firewall
Ja, richtig. Inbound meint hier das lokale LAN. Ein Client im lokalen LAN kommt immer raus übers PAT..klar ! Eine bestehende Session ist niemals erforderlich vom lokalen Netz nach draußen. Logisch, sonst würde nix gehen.Ja, das verstehe ich macht ja Sinn. Die Verbindung geht ja nachdem Sie den Router des Clients verlässt rüber zum Router aufdem der Server liegt. Wieso gestattet die Firewall dort die Verbindung obwohl nicht kein Outbound-Session Eintrag besteht?
Wenn der Client eine Verbindung zu Server XY aufbauen will macht er ersteinmal eine Outbound Verbindung zum PAT-Router (wo der Server liegt) da die Firewall wie du mehrmals sagtest nur eine Verbindung zulässt wenn eine Outbound-Session auf Seiten des Server besteht.
Akzeptiert der PAT-Router an dem der Server angeschlossen ist auch Sessions die keinen bei ihm zuvor geöffneten Outbound-Session Eintrag haben?Wie kommt der Client sonst bei einer Anfrage durch die PAT-Firewall an dem der Server angeschlossen ist?
Akzeptiert die PAT-Firewall vom Server alle Inbound-Session an?
Ja wenn es einen von einem lokalen LAN Client initiierte Session ist ja. Dadurch das der vom LAN nach draußen geht kreiiert der ja diese PAT Session und Antworten vom Server zurück gehen dann durch.Also so wie ich das verstehe hängt die Kommunikation immer vom Server ab? Das Heisst auf Seiten des Server muss immer erst auf der PAT-Firewall ein Outbound-Eintrag bestehen bevor irgendein Client dem Server Daten schicken kann?
Es initiiert ja nicht immer erst der Server die Verbindung. Wenn der Client eine Verbindung zu einem Server initiieren will geht das ja immer schief weil bei der PAT-Firewall kein Outbound-Session Eintrag besteht?
Dumm ist es nur wenn diese Session (wie bei FTP z.B.) einen neuen Sessionaufbau vom Server triggert. Dann öffnet der Server von außen eine neue Session und die bleibt dann logischerweise an der PAT Firewall hängen, denn die lässt nix von außen nach innen durch ohne gesetztes ACK Bit im Paket.
Klasssiches Verhalten bei PAT !
Klasssiches Verhalten bei PAT !
Beim Beispiel FTP wird ja das Problem umgangen indem nicht der Server sondern der Client direkt einen Verbindungsaufbau zum Server geöffnet wird (Outbound-Session beim Client) dann können vom Client Daten zum Server fliesen. Aber dass der Client zum Server eine Verbindung aufbauen darf muss doch der Server erstmals eine Outbond-Session haben? Sonst könnte ja jeder X beliebige Client eine Verbindung zu einem Server aufbauen (diese Clientseitige PAT-Firewall akzeptiert ja alles)?
Einer der beiden also entweder die PAT-Firewall beim Client oder die PAT-Firewall beim Server muss ja auch eine Verbindung eingehen obwohl keine Outbound-Session Eintrag besteht? Den entweder die PAT-Firewall beim Server oder Client hat eine Outbound-Session beim anderen kommt diese Outbound-Session als eine incoming Session an und diese muss man ja akzeptieren? Entweder ist beim Server oder beim Client eine Outbound-Session offen dann fliessen die Daten.
Verstehe nicht wieso nur dann Daten empfangen werden wenn auch ein Outbound-Session Eintrag besteht. Dann kann ich ja gleich sagen als Client zum Server XY ich möchte mit dir eine Verbindung herstellen, der Server akzeptiert und macht Outbound-Session und schon kann ich mit dem Server kommunizieren. Was bringt dann diese Outbound-Session?
Router des Clients verlässt rüber zum Router aufdem der Server liegt. Wieso gestattet die Firewall dort die Verbindung
Das tut sie nicht ! Kann sie auch gar nicht, denn da ist wieder die NAT Firewall davor die den Zugang verhintert wenn dieser Server dahinter in einem lokalen Netz liegt.Ohne ein Port Forwarding geht hier nix.
Der Server kann ja aber auch ein öffentlicher Server beim Hoster oder in einem RZ sein. Da gibts dann kein Router, kein NAT und damit auch das Problem nicht.
Das Beispiel ging von so einem Server aus und nicht von einem privaten der wieder hinter einer NAT Firewall steckt.
Akzeptiert der PAT-Router an dem der Server angeschlossen ist auch Sessions die keinen bei ihm zuvor geöffneten Outbound-Session Eintrag haben?
Wie bereits gesagt: Nein !Wie kommt der Client sonst bei einer Anfrage durch die PAT-Firewall an dem der Server angeschlossen ist?
Nur wenn dort Port Forwarding eingestellt ist die diese Session zwangsweise durchlässt auf die Server IP.Also so wie ich das verstehe hängt die Kommunikation immer vom Server ab?
Nein, das ist falsch !Es hängt davon ab:
- a. wie der Server angeschlossen ist
- b. welches Protokoll benutzt wird
Du gehst immer von einem Server aus der auch hinter einer NAT Firewall steckt. Bei der überwidenden Masse der Server ist das aber nicht der Fall, denn die stehen offen ohne NAT im Internet.
Bei Zugriff z.B. auf einen privaten Server der hinter einem NAT Router zuhause steht stimmt das wieder...aber wie gesagt die überwiegende Minderheit.
Beim Beispiel FTP wird ja das Problem umgangen indem nicht der Server sondern der Client direkt einen Verbindungsaufbau zum Server geöffnet wird
Nein, auch das ist falsch. Zeigt das du die Diskussion oben entweder nicht verstanden oder gelesen hast Bei FTP kommt es entscheident darauf an ob du den passive Mode oder den active Mode benutzt.
Welchen meinst du denn jetzt ?? FTP ist hier ein schelchtes Beispiel, da 2 Ports benutzt werden und einer noch mit dynamischen TCP Ports.
Eben ein schlechtes Beispiel da eine Sonderlocke um die Grundlagen von PAT zu klären ! Nimm besser Telnet oder SSH oder etwas was einen singulären TCP Port hat.
Es initiiert ja nicht immer erst der Server die Verbindung.
Nein, richtig. Niemals initiiert der Server oder nur seeehr, sehr selten. Der Client initiiert logischerweise. Es kann aber sein das die Initiierung des Clients beim Server bewirkt das der dann diverse Sessions zurück zum Client initiiert wie bei FTP oder SIP z.B.DAS macht dann die Probleme bei PAT.
Verstehe nicht wieso nur dann Daten empfangen werden wenn auch ein Outbound-Session Eintrag besteht.
Wie gesagt Denkfehler bei der Server Anordnung...NAT etc. Siehe oben.Zitat von @aqui:
Ohne ein Port Forwarding geht hier nix.
Der Server kann ja aber auch ein öffentlicher Server beim Hoster oder in einem RZ sein. Da gibts dann kein Router, kein NAT und damit auch das Problem nicht.
Das Beispiel ging von so einem Server aus und nicht von einem privaten der wieder hinter einer NAT Firewall steckt.
Router des Clients verlässt rüber zum Router aufdem der Server liegt. Wieso gestattet die Firewall dort die Verbindung
Das tut sie nicht ! Kann sie auch gar nicht, denn da ist wieder die NAT Firewall davor die den Zugang verhintert wenn dieser Server dahinter in einem lokalen Netz liegt.Ohne ein Port Forwarding geht hier nix.
Der Server kann ja aber auch ein öffentlicher Server beim Hoster oder in einem RZ sein. Da gibts dann kein Router, kein NAT und damit auch das Problem nicht.
Das Beispiel ging von so einem Server aus und nicht von einem privaten der wieder hinter einer NAT Firewall steckt.
Also das verstehe ich jetzt wieder überhaupt nicht. Wieso sollte ein öffentlicher Server welcher beim Hoster oder in einem RZ steht kein kein Router oder NAT dahinter sein? Was willst du damit sagen? Ohne Router ist keine Kommunikation möglich? Ich verstehe einfach immer noch nicht:
Damit eine Verbindung bestehen kann, muss ein Outbound-Session Eintrag existieren vorher kann die Gegenstelle keine Verbindung initiieren. Das setzt aber doch voraus, dass der PAT-Router für jede Verbindung immer die von einem Client kommt einen Outbound-Eintrag besteht (damit z.B Client zy ein Bild vom www. abrufen kann) und beim Client hingegen auch automatisch wenn der Client einen request zum Server herstellt auch gleich ein Outbound-Eintrag offen hat. Den der Server wird dem Client ja die Antwort auf seine Frage geben (das Bild ist irgendwelche bits.)
Also akzeptiert ein PAT-Router im öffentlichen Netz jede Client anfrage (automatischer Outbound-Eintrag im PAT) dann ist auf der Seite des Clients von welchem die Anfrage kam ein Outbound-Eintrag und auf der Seite des PAT-Router beim Server ebenfalls ein Outbound-Eintrag welcher immer bei jeder Client-Anfrage automatisch ein Outbound-Eintrag Session öffnet.
Wie kommt der Client sonst bei einer Anfrage durch die PAT-Firewall an dem der Server angeschlossen ist?
Nur wenn dort Port Forwarding eingestellt ist die diese Session zwangsweise durchlässt auf die Server IP.Heisst das also das bei einem Port-Forwarding automatisch ein Outbound-Session Eintrag in der PAT-Tabelle eröffnet wird? Damit der Client also mit dem Server kommunizieren kann? Der Server kann ja mit dem Client kommunizieren, weil ja der Client eine Outbound-Session gemacht hat.
Also so wie ich das verstehe hängt die Kommunikation immer vom Server ab?
Nein, das ist falsch !Es hängt davon ab:
- a. wie der Server angeschlossen ist
- b. welches Protokoll benutzt wird
Du gehst immer von einem Server aus der auch hinter einer NAT Firewall steckt. Bei der überwidenden Masse der Server ist das aber nicht der Fall, denn die stehen offen ohne NAT im Internet.
Bei Zugriff z.B. auf einen privaten Server der hinter einem NAT Router zuhause steht stimmt das wieder...aber wie gesagt die überwiegende Minderheit.
Aber wie sind die Server geschützt wenn sie hinter keiner NAT Firewall stecken. Ein Server der nicht hinter keiner NAT-Firewall stehen kann doch jeder X beliebige Client zugreifen ohne das ein Outbound-Eintrag besteht kann jeder Client drauf zugreifen somit ist das doch eine Sicherheitslücke?
Beim Beispiel FTP wird ja das Problem umgangen indem nicht der Server sondern der Client direkt einen Verbindungsaufbau zum Server geöffnet wird
Nein, auch das ist falsch. Zeigt das du die Diskussion oben entweder nicht verstanden oder gelesen hast Bei FTP kommt es entscheident darauf an ob du den passive Mode oder den active Mode benutzt.
Welchen meinst du denn jetzt ?? FTP ist hier ein schelchtes Beispiel, da 2 Ports benutzt werden und einer noch mit dynamischen TCP Ports.
Eben ein schlechtes Beispiel da eine Sonderlocke um die Grundlagen von PAT zu klären ! Nimm besser Telnet oder SSH oder etwas was einen singulären TCP Port hat.
Ich habe mir http://slacksite.com/other/ftp.html nochmals angesehen:
Im aktiven FTP:
Initiiert der Client die Verbindung auf Port 21 (Outbound-Eintrag). Der Server akzeptiert die Verbindung auf Port 21 weil ein Port Forwarding eingerichtet ist also wird auf beim Server ein Outbound-Session Eintrag gemacht. Nun initiiert der Server eine Outbound-Session auf Port 20 zum Client. Diese müsste ja nun scheitern weil beim Client für Port 20 kein Outbound-Eintrag besteht. Der Client besteht im letzten Schritt noch die Verbindung zum Server. Aber wie ich den aktivem FTP zum Laufen bringen kann ist mir ein Rätsel da der Server eine Outbound-Session zum Client macht obwohl beim Client kein Outbound-Eintrag besteht.
passive FTP: Client initiiert eine Verbindung zum Server (Outbound-Eintrag). Der Server bestätigt die Verbindung weil ein Port Forwarding eingerichtet ist das heisst er akzeptiert auch Verbindungen auch wenn kein Outbound-Eintag besteht? Oder wird doch das Port Forwarding ein Outbound-Eintrag gesetzt? Client initiiert erneut eine Verbindung zum Server um die Daten auszutauschen auch diese Verbindung lässt der Server durch wegen Port Forwarding. Weshhalb nicht über Port 20 wie beim aktiven FTP? Weiter unten hast du geschrieben
"Es kann aber sein das die Initiierung des Clients beim Server bewirkt das der dann diverse Sessions zurück zum Client initiiert wie bei FTP oder SIP z.B.
DAS macht dann die Probleme bei PAT.
"Damit meinst du wohl genau das oder nicht?
Habe ich das noch richtig in Erinnerung bezüglich FTP?
Es initiiert ja nicht immer erst der Server die Verbindung.
Nein, richtig. Niemals initiiert der Server oder nur seeehr, sehr selten. Der Client initiiert logischerweise. Es kann aber sein das die Initiierung des Clients beim Server bewirkt das der dann diverse Sessions zurück zum Client initiiert wie bei FTP oder SIP z.B.DAS macht dann die Probleme bei PAT.
Okay, also als Beispiel meinst du wohl das aktive FTP. Aber wie bringt man das aktive FTP zum Laufen wenn man auf das Passive verzichten möchte? Mir kommt das als erstes in den Sinn irgendeine Regel auf der Firewall erstellen, dass er passive FTP Sessions auch ohne Outbound-Eintrag durchlässt. Was würdest du als Experte da tun?
Achso. Also ist bei passivem FTP
Wieso sollte ein öffentlicher Server welcher beim Hoster oder in einem RZ steht kein kein Router oder NAT dahinter sein?
Denk mal etwas nach ! Öffentliche Hoster betrieben kein NAT. Deren Kundenserver stehen allesamt in öffentlichen IP Segmenten.Klar haben die auch einen Router aber der routet nur. NAT ist denen vollkommen fremd. Klar, wozu auch wenn deren Netze sich nur in einem öffentlichen IP Adress Umfeld befinden.
Wenn man sich das vor Augen führt wirst vermutlich sogar du das verstehen, oder ?
Heisst das also das bei einem Port-Forwarding automatisch ein Outbound-Session Eintrag in der PAT-Tabelle eröffnet wird?
Ja !Aber wie sind die Server geschützt wenn sie hinter keiner NAT Firewall stecken.
Gar nicht ! Eine lokale Firewall wie die Winblows interne oder iptables (Linux etc.) ist hier also absolute Pflicht will man seinen Server sicher machen !Aber wie ich den aktivem FTP zum Laufen bringen kann ist mir ein Rätsel
Nicht nur dir ! Ganz klar: Mit active FTP kommst du NICHT reverse über eine NAT Firewall, das ist technisch unmöglich. Du musst hier zwangsweise immer einen passive Client benutzen.Ausnahme: Bessere Router und Firewalls (Coisco etc.) haben ein Application Gateway laufen sofern man das aktiviert. Das sieht dann auch in höhere Layer und erkennt am Port 21 eine inbound FTP Session am NAT. Es eröffnet dann von sich aus die Firewall am Port TCP 20 für die Server IP so das dann auch active FTP Sessions passieren können.
Wie gesagt, das können nur "bessere" Produkte, nicht die simplen einfach NAT Router.
Damit meinst du wohl genau das oder nicht?
Ja, genau das. Das hast du absolut richtig wiedergegeben oben.Aber wie bringt man das aktive FTP zum Laufen wenn man auf das Passive verzichten möchte?
Nur so mit entsprechender Hardware die sowas wie Application gateways supportet. Anders ist das technisch nicht möglich wenn man auf den Passive Mode verzichten will oder muss (was aber unverständlich ist)Mit Firewall Regeln das zu lösen ist unmöglich. Ist klar wenn du dir deren Wirkweise mal vor Augen führst.
Zitat von @aqui:
Klar haben die auch einen Router aber der routet nur. NAT ist denen vollkommen fremd. Klar, wozu auch wenn deren Netze sich nur in einem öffentlichen IP Adress Umfeld befinden.
Wenn man sich das vor Augen führt wirst vermutlich sogar du das verstehen, oder ?
Mh, okay...Wieso sollte ein öffentlicher Server welcher beim Hoster oder in einem RZ steht kein kein Router oder NAT dahinter sein?
Denk mal etwas nach ! Öffentliche Hoster betrieben kein NAT. Deren Kundenserver stehen allesamt in öffentlichen IP Segmenten.Klar haben die auch einen Router aber der routet nur. NAT ist denen vollkommen fremd. Klar, wozu auch wenn deren Netze sich nur in einem öffentlichen IP Adress Umfeld befinden.
Wenn man sich das vor Augen führt wirst vermutlich sogar du das verstehen, oder ?
Aber diese Server haben doch auch eine LAN IP-Adresse und sind Mitglied eines privaten Netzes z. B 10.0.0.0/24. NAT wird doch auch in grossen IP-Netzten verwendet oder nicht?
Also ich hatte auch mal 3 Netze konfiguriert auf 3 Firewalls mit je einer öffentlichen IP-Adresse. Dort war NAT auch nur bedingt für gewisse Services aktiviert.
Aber wie sind die Server geschützt wenn sie hinter keiner NAT Firewall stecken.
Gar nicht ! Eine lokale Firewall wie die Winblows interne oder iptables (Linux etc.) ist hier also absolute Pflicht will man seinen Server sicher machen !Damit meinst du wohl genau das oder nicht?
Ja, genau das. Das hast du absolut richtig wiedergegeben oben.Aber diese Server haben doch auch eine LAN IP-Adresse und sind Mitglied eines privaten Netzes z. B 10.0.0.0/24. NAT wird doch auch in grossen IP-Netzten verwendet oder nicht?
Traumtänzer.... Nein, Server Hoster nutzen keinerlei NAT sondern rein öffentliche IPs in ihren RZ.Zitat von @aqui:
Aber diese Server haben doch auch eine LAN IP-Adresse und sind Mitglied eines privaten Netzes z. B 10.0.0.0/24. NAT wird doch auch in grossen IP-Netzten verwendet oder nicht?
Traumtänzer.... Nein, Server Hoster nutzen keinerlei NAT sondern rein öffentliche IPs in ihren RZ.Traumtänzer
Und wie muss ich mir das Vorstellen? Wir z.B hatten in der Firma in welcher ich gearbeitet habe eine Firewall und pro Interface konnte ich ein Netzzuordenen also X1 = 83.219.123.123 / 24 , X2 = 83.219.123.123 / 24Wenn der Kunde 2 Internet Anschlüsse hatte haben wir das wie oben konfiguriert. Durch NAT kann man sagen wenn Dienst HTTP vom Internet her auf Interfacee X1 kommt solls nach X2 etc... das habe ich in meiner Praxis mit NAT gelernt.
Habe nie in einem RZ gearbeitet kenne mich mit solchen Routern und deren Möglichkeiten und Netzen nicht aus...
Und wie muss ich mir das Vorstellen?
Stell dir einen Raum in Turnhallengröße vor mit diversen Schrankreihen. Dort sind 1 HE Server drin die zu TOR Switches gehen und diese sind entweder Fabric vernetzt mit DCB Switches oder gehen auf einen 10G Coreswitch.Alles rennt dort mit öffentlichen IPs.
So wie hier sieht da eine Reihe aus:
http://cimbura.com/tech/filemakerweb-hosting/
Da ist nix mit NAT oder wieviel Millonen NAT Router willst du da hinstellen für jeden popeligen Kunden Webserver...
Zitat von @aqui:
Alles rennt dort mit öffentlichen IPs.
So wie hier sieht da eine Reihe aus:
http://cimbura.com/tech/filemakerweb-hosting/
Da ist nix mit NAT oder wieviel Millonen NAT Router willst du da hinstellen für jeden popeligen Kunden Webserver...
Und wie muss ich mir das Vorstellen?
Stell dir einen Raum in Turnhallengröße vor mit diversen Schrankreihen. Dort sind 1 HE Server drin die zu TOR Switches gehen und diese sind entweder Fabric vernetzt mit DCB Switches oder gehen auf einen 10G Coreswitch.Alles rennt dort mit öffentlichen IPs.
So wie hier sieht da eine Reihe aus:
http://cimbura.com/tech/filemakerweb-hosting/
Da ist nix mit NAT oder wieviel Millonen NAT Router willst du da hinstellen für jeden popeligen Kunden Webserver...
Ein bisschen kenne ich RZs schon jedoch in Videos und kenne auch die Komponenten wie USB, Diesel-Generatoren, Brandbekämpfungsanlagen etc....
Kannst du mir noch bitte sagen was dieses FABRIC heissen soll konnte davon nix finden. TOR -> Top on Rack, soll heissen im Rack sind nur Server und auf dem Rack befindet sich ein Switch an welchem die Server angeschlossen sind?
DCB Switche haben das Ziel die Latenz so kurz wie möglich zu halten wie machen die das durch Load Balancing oder verstehe nicht ganz das Prinzip von DCB Switche...
10 G Coreswitch sind ja auch oft in Internet Exchanges zu finden dort bieten ja alle die da "mitmachen" wollen einen 1 G oder 10 Gb Port zur Verfügung. Wie der DE-CIX, SWISS IX oder eben TIX Zürich
Guckst du hier:
http://www.brocade.com/en/possibilities/technology/data-center-fabrics. ...
DCB Switches basieren meist auf TRILL oder SPB und sind hybride Switches die FCoE und Ethernet können, sprich also Storage und Netzwerk Traffic auf einer Hardware.
http://www.brocade.com/en/possibilities/technology/data-center-fabrics. ...
DCB Switches basieren meist auf TRILL oder SPB und sind hybride Switches die FCoE und Ethernet können, sprich also Storage und Netzwerk Traffic auf einer Hardware.
10 G Coreswitch sind ja auch oft in Internet Exchanges zu finden
Das ist schon lange vorbei.... Die operieren ausschliesslich nur noch mit 100G und 40GZitat von @aqui:
Guckst du hier:
http://www.brocade.com/en/possibilities/technology/data-center-fabrics. ...
DCB Switches basieren meist auf TRILL oder SPB und sind hybride Switches die FCoE und Ethernet können, sprich also Storage und Netzwerk Traffic auf einer Hardware.
Guckst du hier:
http://www.brocade.com/en/possibilities/technology/data-center-fabrics. ...
DCB Switches basieren meist auf TRILL oder SPB und sind hybride Switches die FCoE und Ethernet können, sprich also Storage und Netzwerk Traffic auf einer Hardware.
Ganz schön kompliziert... Wohl eine Nummer zu gross für mich....
Sowie ich das verstehe nutzten solche DCB Switche eine Bridge-Funktion um zwischen Fiber Channel over Ethernet und Ethernet zu vermitteln. Jeder WLAN-Router hat ja auch eine Art Bridge-Modus um von LAN zu WLAN zu übersetzten. Das habe ich so in der Ausbildung gelernt.
10 G Coreswitch sind ja auch oft in Internet Exchanges zu finden
Das ist schon lange vorbei.... Die operieren ausschliesslich nur noch mit 100G und 40GSchon bei 100 Gb/s ? Wow okay....
Danke für die Hilfe, ich lass das mal so, dass wird mir zu kompliziert die Grundlagen dafür habe ich ja nichtmal um das zu verstehen wie das ganze Funktioniert..
Schliesse das Thema mal ab. Das ursprüngliche Thema ist ja auch schon länger geklärt
Zitat von @osze90:
Danke für die Hilfe, ich lass das mal so, dass wird mir zu kompliziert die Grundlagen dafür habe ich ja nichtmal um das zu verstehen wie das ganze Funktioniert..
Ich denke das ist kein Grund zur Besorgnis Danke für die Hilfe, ich lass das mal so, dass wird mir zu kompliziert die Grundlagen dafür habe ich ja nichtmal um das zu verstehen wie das ganze Funktioniert..
Da hat uns Kollege @aqui einfach zu viel Berufserfahrung und Expertisenwissen voraus.Aber wenn das eigentliche VPN Thema damit beantwortet ist, dann bitte noch:
Wie kann ich einen Beitrag als gelöst markieren?
Alles Gute!
Gruß
Zitat von @michi1983:
Da hat uns Kollege @aqui einfach zu viel Berufserfahrung und Expertisenwissen voraus.
Aber wenn das eigentliche VPN Thema damit beantwortet ist, dann bitte noch:
Wie kann ich einen Beitrag als gelöst markieren?
Alles Gute!
Gruß
Zitat von @osze90:
Danke für die Hilfe, ich lass das mal so, dass wird mir zu kompliziert die Grundlagen dafür habe ich ja nichtmal um das zu verstehen wie das ganze Funktioniert..
Ich denke das ist kein Grund zur Besorgnis Danke für die Hilfe, ich lass das mal so, dass wird mir zu kompliziert die Grundlagen dafür habe ich ja nichtmal um das zu verstehen wie das ganze Funktioniert..
Da hat uns Kollege @aqui einfach zu viel Berufserfahrung und Expertisenwissen voraus.Aber wenn das eigentliche VPN Thema damit beantwortet ist, dann bitte noch:
Wie kann ich einen Beitrag als gelöst markieren?
Alles Gute!
Gruß
Ja, so ist es.... Ich hatte auch nur eine 2 jährige Berufsausbildung eine normale geht 4 Jahre bei uns. Meine Ausbildung war auch gezielt richtig Support einige wenige Netzwerkkenntnisse waren schon dabei.
Ganz schön kompliziert...
Nööö...nicht wirklich sonst würds ja keiner kaufen Sowie ich das verstehe nutzten solche DCB Switche eine Bridge-Funktion um zwischen Fiber Channel over Ethernet und Ethernet zu vermitteln
Nein ! FCoE ist eine einfache Layer 2 Encapsulierung von FC in Ethernet Frames. Das ist aber auch gar nicht das primäre Kriterium von DCB.Jeder WLAN-Router hat ja auch eine Art Bridge-Modus um von LAN zu WLAN zu übersetzten
Auch das ist natürlich technischer Unsinn oder du hattest einen schlecht ausgebildeten Lehrer. Ein "richtiger" WLAN Router kann auch das WLAN Segment an ihm routen.Das wo dein Horizont aufhört sind billige Baumarkt und Consumer Router vom Blödmarkt.
Die haben einfach nur einen embedded AP der via Bridging an den LAN Port angeflanscht ist. Das ist dann in der Tat Bridging.
Aber keine Sorge...mit der Zeit kommt das Wissen auch bei dir !
Man muss nur immer neugierig bleiben...
Das sagt der Profi mit der langjährigen Erfahrung
)Sowie ich das verstehe nutzten solche DCB Switche eine Bridge-Funktion um zwischen Fiber Channel over Ethernet und Ethernet zu vermitteln
Nein ! FCoE ist eine einfache Layer 2 Encapsulierung von FC in Ethernet Frames. Das ist aber auch gar nicht das primäre Kriterium von DCB.Also FCoE entkappselt Frames von Glasfaser in Ethernet Frames? Nichtmal gewusst, dass Glasfaser und Ethernet andere Frames nutzen.
In einem (Ethernet-)Frame sind ja vorwiegend folgende Infos soviel ich weiss:
Quell IP und MAC | Ziel IP und MAC danach in einem Payload oder Body sind die eigentlichen Daten. Eine Checksumme kommt mir da noch in den Sinn mehr wüsste ich nicht was da noch rein gehört.
Ist dieses FCoE behinhaltet wohl ein ganz eigenes Modell von Frames. Token Ring etc. nutzten wohl nochmals andere Frames bzw. haben einen nochmals anderen Inhalt.
Jeder WLAN-Router hat ja auch eine Art Bridge-Modus um von LAN zu WLAN zu übersetzten
Auch das ist natürlich technischer Unsinn oder du hattest einen schlecht ausgebildeten Lehrer. Ein "richtiger" WLAN Router kann auch das WLAN Segment an ihm routen.Wie meinst du das nun? Ein WLAN-Router beinhaltet ja auch einen Router (Wire) der gleichzeitig Access Point (Wireless) ist. Darum ist dieser Router nicht nur Router sondern auch eine Bridge?!
Ein Segment ist ja ein Teilnet | Switch 1 | = Segment 1 und Switch 2 = Segment 2
Das wo dein Horizont aufhört sind billige Baumarkt und Consumer Router vom Blödmarkt.
Die haben einfach nur einen embedded AP der via Bridging an den LAN Port angeflanscht ist. Das ist dann in der Tat Bridging.
Aber keine Sorge...mit der Zeit kommt das Wissen auch bei dir !
Man muss nur immer neugierig bleiben...
Die haben einfach nur einen embedded AP der via Bridging an den LAN Port angeflanscht ist. Das ist dann in der Tat Bridging.
Aber keine Sorge...mit der Zeit kommt das Wissen auch bei dir !
Man muss nur immer neugierig bleiben...
Ja, ich kennen aufgrund meiner wenigen Erfahrung oft nur Baumarkt-Geräte. Gut, eine Sonicwall TZ 400 auf der Arbeit habe ich konfguriert, da sind paar Einstellungen mehr vorhanden auch beim Preis sind das Welten 1600 CHF kostet diese.
Such dir mal einen Cisco Nexus 5000 Switch raus
Nicht dein Ernst? So ein Switch für privat?
Habe mir bereits ein Serverrack mit 42 HE gekauft 2 Meter hoch. Das reicht.
Cisco ist doch oft ohne GUI? Wir hatten in der Arbeit auch Cisco Router/Switche
sowas ähnliches das war ohne GUI
http://i.ebayimg.com/images/g/v40AAOxymHRRxKec/s-l300.jpg
Also FCoE entkappselt Frames von Glasfaser in Ethernet Frames? Nichtmal gewusst, dass Glasfaser und Ethernet andere Frames nutzen.
Tun sie auch nicht. Was gemeint war ist das um einen nativen FC Frame einfach ein Layer 2 Ethernet Frame "gebastelt" wird bei FCoE.Ein WLAN-Router beinhaltet ja auch einen Router (Wire) der gleichzeitig Access Point (Wireless) ist.
Nein ein simpler Home WLAN Router routet nur zwischen LAN Port und WAN Port. Intern ist dann ein simpler AP per Bridge an den LAN Port gehänt.So ein simpler DSL Router ist also immer ein Router mit integriertem Layer 2 AP am LAN Port. Deshalb haben LAN und WLAN auch immer das gleiche IP Netz.
Bessere Router wie Mikrotik, Cisco, Lancom, Bintec lassen aber auch ein richtiges Routing mit dem WLAN Segment zu wenn man es entsprechend konfiguriert.
Dann wird eben nicht zw. WLAN und LAN gebridged wie bei den Billigteilen sondern geroutet.
Merkt man an 2 unterschiedlichen IP netzen dieser Segmente.
Cisco ist doch oft ohne GUI? Wir hatten in der Arbeit auch Cisco Router/Switche sowas ähnliches das war ohne GUI
Märchenstunde eines Unwissenden....Das GUI ist konfigurierbar. Richtige netzwerker verfahren nach dem Leitspruch: "Real networkers do CLI...!"
Klicki Bunti ist was für Winblows Weicheier...
Zitat von @aqui:
Also FCoE entkappselt Frames von Glasfaser in Ethernet Frames? Nichtmal gewusst, dass Glasfaser und Ethernet andere Frames nutzen.
Tun sie auch nicht. Was gemeint war ist das um einen nativen FC Frame einfach ein Layer 2 Ethernet Frame "gebastelt" wird bei FCoE.Wieso ein FC Frame (Glas) in ein Ethernet-Frame (Kupfer) basteln? Dachte beides nutzten gleichen Frames? Wie muss man das den verstehen?...
Bei einem FC Frame wird in ein Ethernet-Frame hinzugefügt. Was muss den da hinzugefügt werden ein Frame besteht ja aus Quell, MAC und Destination MAC und einer Checksumme mehr glaube nicht. Oben sagte ich glaube mal, dass die IP-Adresse auch noch im Frame steht ist ja aber Blödsinn. Da erst eine Schickt weiter oben IP-Adresse hinzugefügt werden...
Also habe nochmals gegoogelt und habe gemerkt, dass wirklich diverse Ethernet-Frames gibt z. B tagged und untagged Frame bei VLANs. Wird bei FC-Frames wohl einfach auch noch irgendwelche zusätzliche Flags geben.
Verstehe glaube langsam was du meinst in einem FC-Frame wird einfach ein Ethernet-Frame verpackt dieses Ethernet-Frame dann zu einem IP-Paket dieses wird zu Datensegmenten etc...
Ein WLAN-Router beinhaltet ja auch einen Router (Wire) der gleichzeitig Access Point (Wireless) ist.
Intern ist dann ein simpler AP per Bridge an den LAN Port gehänt.Genau so meinte ich das. Hast du schon mal so erklärt.
Wieso ein FC Frame (Glas) in ein Ethernet-Frame (Kupfer) basteln?
Nun wirds aber langsam peinlich bei dir. Das man Ethernet auch auf Glasfaser übertragen kann weiss ja nun mittlerweile jeder Erstklässler !!Ziel ist es darum Fiberchannel Daten über einen Ethernet Frame zu transportieren egal über welches Medium Ethernet transportiert wird. Zur Not kann das ein feuchter Bindfaden sein.
Fiberchannel Storage Netze ist was ganz anderes als Ethernet....
https://de.wikipedia.org/wiki/Fibre_Channel
Zum Thema FCoE guckst du hier:
https://de.wikipedia.org/wiki/Fibre_Channel_over_Ethernet
Dort steht auch genau wie die FC Daten nativ in einem L2 Ethernet Frame enkapsuliert sind.
Verstehe glaube langsam was du meinst in einem FC-Frame wird einfach ein Ethernet-Frame verpackt dieses Ethernet-Frame dann zu einem IP-Paket
Nein !Vollkommen falsch ! Andersrum wird ein Schuh draus...
FC wird in Ethernet Frames eingepackt, deshalb ja auch der Name FC over Ethernet !!
Und natürlich ohne IP, denn FCoE gibts nur auf L2. Nix IP....
Zitat von @aqui:
Ziel ist es darum Fiberchannel Daten über einen Ethernet Frame zu transportieren egal über welches Medium Ethernet transportiert wird. Zur Not kann das ein feuchter Bindfaden sein.
Fiberchannel Storage Netze ist was ganz anderes als Ethernet....
https://de.wikipedia.org/wiki/Fibre_Channel
Zum Thema FCoE guckst du hier:
https://de.wikipedia.org/wiki/Fibre_Channel_over_Ethernet
Dort steht auch genau wie die FC Daten nativ in einem L2 Ethernet Frame enkapsuliert sind.
Wieso ein FC Frame (Glas) in ein Ethernet-Frame (Kupfer) basteln?
Nun wirds aber langsam peinlich bei dir. Das man Ethernet auch auf Glasfaser übertragen kann weiss ja nun mittlerweile jeder Erstklässler !!Ziel ist es darum Fiberchannel Daten über einen Ethernet Frame zu transportieren egal über welches Medium Ethernet transportiert wird. Zur Not kann das ein feuchter Bindfaden sein.
Fiberchannel Storage Netze ist was ganz anderes als Ethernet....
https://de.wikipedia.org/wiki/Fibre_Channel
Zum Thema FCoE guckst du hier:
https://de.wikipedia.org/wiki/Fibre_Channel_over_Ethernet
Dort steht auch genau wie die FC Daten nativ in einem L2 Ethernet Frame enkapsuliert sind.
Gut Glasfaser kenne ich nun nicht sehr gut ich weiss, dass es LC, ST, E2000 Stecker gibt für Glasfaser und habe mal eine Glasfaser gesehen vielmehr kenne ich nicht. Gearbeitet habe ich nie damit woher soll ich den das wissen? Ich weiss das man über Glasfaser auch über mehrere Signale senden kann (wir nannten das Gerät KEV. Es konnte die verschiedenen (Farben) eigentlich glaube ultraschall Bereiche trennen. DWDM, WWDM oder so habe ich auch schonmal gehört. Multimode und Singlemode kenne ich auch bzw. mal gehört.
Okay ja normalerweise wird ja für Internet etc immer Ethernet benutzt. Für VOIP nutzten wir VOIP-Gateways. VOIP kommuniziert ja nicht über Ethernet sondern nutzt ja eine andere Technologie, darum muss man ja auch einen (VOIP)-Gateway benutzten.
Verstehe glaube langsam was du meinst in einem FC-Frame wird einfach ein Ethernet-Frame verpackt dieses Ethernet-Frame dann zu einem IP-Paket
Nein !Vollkommen falsch ! Andersrum wird ein Schuh draus...
FC wird in Ethernet Frames eingepackt, deshalb ja auch der Name FC over Ethernet !!
Und natürlich ohne IP, denn FCoE gibts nur auf L2. Nix IP....
iSCSI ist doch der Vorgänger von SAS wieso wird SCSI immernoch benutzt? Im Link zur Wiki mit FCoE wird im Beispiel immer noch dieses SCSI benutzt. Es gibt ja auch noch Festplatten mit dieser $chnittstelle die wurde doch früher anstelle der SAS-Platten benutzt.
Ja aber die Kommunikation ist doch drauf angewiesen das alle Layer benutzt werden? von 1 auf 7? Das heisst wenn in einem solchen Storage Netzwerk jemand Daten anfordert wird das von einem Bits zu einem FCoE-Frame dieses wird doch zu einem Datenpaket damit es an seinen Ziel-Empfänger kann anschliessend werden dem Datensegment Ports hinzugefügt....
Wieso sollte man überhaupt FCoE benutzten? Wenn man über Glasfaser ja auch Ethernet benutzten kann wofür dann überhaupt FCoE?
Diese beiden Wikiartikeln sind sowas von kompliziert. Ohne Fachwissen kommt man da einfach überhaupt nicht weiter....
Ich dachte immer Fibre Channel heisst einfach das es über Glasfaser läuft statt Kupferkabel nun ist die Rede von einer Schnittstelle. Kann mir das nicht vorstellen wie das funktionieren soll.
So wie ich das verstehe basiert FCoE gar nicht auf OSI sondern hat ein eigenes Modell.
Okay ja normalerweise wird ja für Internet etc immer Ethernet benutzt.
Völliger Unsinn ! Woher nimmst du diese Weisheiten wenn du noch nichtmal sowas simples wie Glasfaser kennst.Besser nicht so aus dem Fenster lehnen bei Dingen wo du im freien Fall raten musst...
VOIP kommuniziert ja nicht über Ethernet sondern nutzt ja eine andere Technologie,
Auch wieder völliger Unsinn !!VoIP nutzt das IP Protokoll für den Transport der Voice Daten ! Wie der name ja schon sagt...
Über welche Infrstruktur, Ethernet, Seriell, ATM, MPLS oder ein feuchter Bindfaden ist damit ja noch gar nicht gesagt.
Verwechsle also bitte nicht Äpfel mit Birnen hier im freien Fall.
SCSI ist doch der Vorgänger von SAS
Und wieder völliger Unsinn.SCSI ist und bleibt SCSI egal ob es parallel übertragen wird oder seriell (SAS)
Englisch bleibt ja auch Englisch egal ob es ein Japaner spricht, ein Deutscher oder ein Engländer, oder ?
aber die Kommunikation ist doch drauf angewiesen das alle Layer benutzt werden?
Nein !NetBIOS und diverse andere Protokolle kennen nur einen Layer 2.
wird das von einem Bits zu einem FCoE-Frame
Uuuhhhh jetzt wirds aber wieder gruselg... Du rätst hier im freien Fall.. Bei FC wirds ein FC Frame und wenn du z.B. iSCSI machst wids ein IP Paket
kann anschliessend werden dem Datensegment Ports hinzugefügt....
Nicht bei FC, denn das ist ja kein TCP/IP sondern ein ganz anderes Verfahren und Protokoll. Obwohl auch nicht ganz, denn FC nutzt SCSI Kommandos aber in einem anderen Rahmen...über Glasfaser seriell eben.Mit IP hat das rein gar nix zu tun.
Wieso sollte man überhaupt FCoE benutzten?
Wieso sollte man überhaupt VoIP benutzen.FC und Ethernetnet erfordert 2 Infrastrukturen mit 2mal Hardware und doppelten Kosten.
Mit FCoE kann man sich das sparen und alles über eine gemeinsame Infrastruktur abfackeln.
Ist so wie VoIP... Früher gabs mal analoges Voice oder ISDN jedes mit einem ganz eigenen Netz...heute VoIP über eingemeinsames Datennetz um Kosten zu sparen.
Das lernt man doch schon in der Grundschule.
Diese beiden Wikiartikeln sind sowas von kompliziert.
Nöö...nicht wirklich ! Aber wenn dein Horizont schon bei Glasfaser zuende ist wirds in der Tat nicht einfach...Ich dachte immer
Oha...nicht denken sondern "nachdenken" !So wie ich das verstehe basiert FCoE gar nicht auf OSI sondern hat ein eigenes Modell.
Und wieder falsch !FCoE nutzt ja standartisiertes Ethernet Frameing und dann ists wieder OSI. Allerdigs eben nur L2 weils nix dadrüber gibt. Ist so wie ARP, das ist auch nicht routebar und hat nur L2
Sorry für die verspätete Antwort. Habe mir in den letzten Tagen das Thema Fibre Channel angesehen und das ist ja eine ganz andere Welt da gibt keine MAC-Adresse sondern WWNN... Fragen zu Fibre Channel habe ich jede Menge muss jedoch noch alle notieren.
Ja halt als Privat-Anwender ist Ethernet fast überall zu finden. Das meinte ich Wenn man das Fibre Channel in ein OSI-Referenzmodell klassifizieren müsste befindet sich das ja im Layer 2 auf der Sicherungsschicht richtig? Wo auch dieses Token Ring, Ethernet.... ist richtig? Was ich auch gelernt habe Fibre Channel hat auch wie TCP/IP ein eigenes Schichten-Modell und zwar nur 4 Schichten.
VoIP nutzt das IP Protokoll für den Transport der Voice Daten ! Wie der name ja schon sagt...
Über welche Infrstruktur, Ethernet, Seriell, ATM, MPLS oder ein feuchter Bindfaden ist damit ja noch gar nicht gesagt.
Verwechsle also bitte nicht Äpfel mit Birnen hier im freien Fall.
Wofür benötigt man den Gateways? Es gibt ja Geräte die sind mit VOIP-Gateways angeschrieben sind? Ein Gateway vermittelt laut Wikipedia zwischen mehreren Netzwerkprotokollen z .B SIP zu TCP/IP etc? Also ist ein Router auch ein Gatway darum weil er zwischen mehreren Netzwerkprotokollen vermittelt? Also wenn auf Seite A ein ADSL-Netzwerk ist und auf Seite B ein Ethernet-Netzwerk nimmt man einen Gateway um diese beiden Netze zu verbinden bzw. damit diese beiden unterschiedlichen Protokolle miteinander Kommunizieren können.
Die Bridge erfüllt ja ähnliche Aufgaben nur paar Schichten weiter unten z.B Funk (WLAN) zu Kabel (LAN)? Auch ein GIBIC ist ja eine Bridge am einen Ort kommt ein Optisches Signal am andern Ende gehts per Kabel oder so weiter oder halt über Leiterbahnen (habe nie in einen Switch reingeschaut)
SCSI ist und bleibt SCSI egal ob es parallel übertragen wird oder seriell (SAS)
Englisch bleibt ja auch Englisch egal ob es ein Japaner spricht, ein Deutscher oder ein Engländer, oder ?
Erst kam SCSI auf SCSI folgte SAS? Stimmt doch so steht zumindest auf Wiki so.
NetBIOS und diverse andere Protokolle kennen nur einen Layer 2.
Ja Fibre Channel hat auch nur 4.
Wenn ich nun von meinem PC über Ethernet ein Bild von einem Server herunterladen will (Server ist an einem SAN mit Fibre Channel anschl.) muss das ganze OSI-Referenzmodell durchlaufen werden? Also stimmt das doch?
Bei FC wirds ein FC Frame und wenn du z.B. iSCSI machst wids ein IP Paket
Ja das leuchtet mir ein den ein FC-Frame (Fibre Channel) ist wie ein Ethernet-Frame (Ethernet) auf der Sicherungsschicht (OSI 2) und ein IP-Paket auf der Vermittlungsschicht OSI Layer 3.
Wie meinst du das mit wenn ein FC-Frame iSCSI macht wirds ein IP-Paket? Also SCSI nutzt doch niemand mehr das ist doch uralt wie die ATA. Heute gibt doch meisten nur noch SATA oft in Computern und SAS oft in Servern? Also du willst mir sagen über Fibre Channel wird ein FC-Frame erstellt -> In den Layern FC-0 - FC-4 sind die Daten. FC-0 (Signale).... Die WWNN des HBA in irgendeinem Layer -> FC-4 (beinhaltet welches Übertragungsmedium SAS oder SATA) danach wird das einem IP-Paket übergeben. Das IP-Paket wird dann wieder auseinandergenommen in der Transport-Schicht.
Mit IP hat das rein gar nix zu tun.
Verstehe mittlerweile etwas mehr von SCSI. So wie ich das verstehe, nutzt Fibre Channel auch die Kommandos von SCSI darum hat es auch etwas mit SCSI zu tun? Fibre Channel hat aber mit der Schnittstelle sonst nichts weiter zu tun. SAS heisst ja Serial Attachet SCSI darum haben beide etwas miteinander zu tun. Über diese beiden Schnittstellen werden ja auch HDDS von Servern angeschlossen (ich kenne es aus meiner Erfahrung heraus nur SATA und SAS). Hingegen Fibre Channel dient nicht dazu, Festplatten anzuschließen sondern um das (langsame) Kupfer-Kabel abzulösen. // Edit von 15.3
Diese SCSI Kommandos finden ja in der FC-4 Layer statt, genauso könnten es ja auch IP-Kommandos sein oder ?
Aber oft brauchts ja auch einen Port den die Fibre Channel Daten werden von einem Server oder Client angefordert. Das durchläuft ja dann alle OSI-Schichten im normal Fall? Wenn ein HTTP-Server eine Datei die auf einem SAN liegt anfordert z.B?
FC und Ethernetnet erfordert 2 Infrastrukturen mit 2mal Hardware und doppelten Kosten.
Um genauer zu sein NICs mit Glas-Anschluss und mit Kupfer? Richtig?
Wieso aber 2 mal Hardware? Die meisten teureren Switche bei der Arbeit haben einen Glas-Faser-Anschluss als Uplink = Fibre Channel?
Kann ich über Glasfaser auch Ethernet betreiben?
Also diese FCoE Netzwerke benötigen aber diese Data Center Bridges die gleichzeitig Glasfaser für Fibre Channel und Kupfer für Ethernet können. Dabei werden alle FC-Frame in ein Ethernet-Frame verkapselt und dann durchläuft das die Kette -> IP-Paket -> Datensegment -> Daten
FCoE nutzt ja standartisiertes Ethernet Frameing und dann ists wieder OSI. Allerdigs eben nur L2 weils nix dadrüber gibt. Ist so wie ARP, das ist auch nicht routebar und hat nur L2
Fibre Channel hat ein eigenes Layer-Modell, sorry verwechselt.
Verstehe nicht ganz. Wo steht nichts darüber? Bei FCoE steht nichts darüber? Weil FCoE kein eigenes Modell hat, meinst du das? Jedoch bei OSI kommt nach L2 die L3 die Vermittlung also die Protokolle fürs Routing?
Also Ethernet basiert auf OSI weil Ethernet kein "eigenes" Layer-Modell hat? TCP/IP kann auf Ethernet basieren und TCP/IP hat jedoch sein eigenes Modell?!
ARP ist nicht routebar das macht Sinn ist auch kein Layer 3 Protokoll das verstehe ich.
Zitat von @aqui:
Besser nicht so aus dem Fenster lehnen bei Dingen wo du im freien Fall raten musst...
Okay ja normalerweise wird ja für Internet etc immer Ethernet benutzt.
Völliger Unsinn ! Woher nimmst du diese Weisheiten wenn du noch nichtmal sowas simples wie Glasfaser kennst.Besser nicht so aus dem Fenster lehnen bei Dingen wo du im freien Fall raten musst...
Ja halt als Privat-Anwender ist Ethernet fast überall zu finden. Das meinte ich
Wenn man das Fibre Channel in ein OSI-Referenzmodell klassifizieren müsste befindet sich das ja im Layer 2 auf der Sicherungsschicht richtig? Wo auch dieses Token Ring, Ethernet.... ist richtig? Was ich auch gelernt habe Fibre Channel hat auch wie TCP/IP ein eigenes Schichten-Modell und zwar nur 4 Schichten.VOIP kommuniziert ja nicht über Ethernet sondern nutzt ja eine andere Technologie,
Auch wieder völliger Unsinn !!VoIP nutzt das IP Protokoll für den Transport der Voice Daten ! Wie der name ja schon sagt...
Über welche Infrstruktur, Ethernet, Seriell, ATM, MPLS oder ein feuchter Bindfaden ist damit ja noch gar nicht gesagt.
Verwechsle also bitte nicht Äpfel mit Birnen hier im freien Fall.
Wofür benötigt man den Gateways? Es gibt ja Geräte die sind mit VOIP-Gateways angeschrieben sind? Ein Gateway vermittelt laut Wikipedia zwischen mehreren Netzwerkprotokollen z .B SIP zu TCP/IP etc? Also ist ein Router auch ein Gatway darum weil er zwischen mehreren Netzwerkprotokollen vermittelt? Also wenn auf Seite A ein ADSL-Netzwerk ist und auf Seite B ein Ethernet-Netzwerk nimmt man einen Gateway um diese beiden Netze zu verbinden bzw. damit diese beiden unterschiedlichen Protokolle miteinander Kommunizieren können.
Die Bridge erfüllt ja ähnliche Aufgaben nur paar Schichten weiter unten z.B Funk (WLAN) zu Kabel (LAN)? Auch ein GIBIC ist ja eine Bridge am einen Ort kommt ein Optisches Signal am andern Ende gehts per Kabel oder so weiter oder halt über Leiterbahnen (habe nie in einen Switch reingeschaut)
SCSI ist doch der Vorgänger von SAS
Und wieder völliger Unsinn.SCSI ist und bleibt SCSI egal ob es parallel übertragen wird oder seriell (SAS)
Englisch bleibt ja auch Englisch egal ob es ein Japaner spricht, ein Deutscher oder ein Engländer, oder ?
Erst kam SCSI auf SCSI folgte SAS? Stimmt doch so steht zumindest auf Wiki so.
aber die Kommunikation ist doch drauf angewiesen das alle Layer benutzt werden?
Nein !NetBIOS und diverse andere Protokolle kennen nur einen Layer 2.
Ja Fibre Channel hat auch nur 4.
Wenn ich nun von meinem PC über Ethernet ein Bild von einem Server herunterladen will (Server ist an einem SAN mit Fibre Channel anschl.) muss das ganze OSI-Referenzmodell durchlaufen werden? Also stimmt das doch?
wird das von einem Bits zu einem FCoE-Frame
Uuuhhhh jetzt wirds aber wieder gruselg... Du rätst hier im freien Fall.. Bei FC wirds ein FC Frame und wenn du z.B. iSCSI machst wids ein IP Paket
Ja das leuchtet mir ein den ein FC-Frame (Fibre Channel) ist wie ein Ethernet-Frame (Ethernet) auf der Sicherungsschicht (OSI 2) und ein IP-Paket auf der Vermittlungsschicht OSI Layer 3.
Wie meinst du das mit wenn ein FC-Frame iSCSI macht wirds ein IP-Paket? Also SCSI nutzt doch niemand mehr das ist doch uralt wie die ATA. Heute gibt doch meisten nur noch SATA oft in Computern und SAS oft in Servern? Also du willst mir sagen über Fibre Channel wird ein FC-Frame erstellt -> In den Layern FC-0 - FC-4 sind die Daten. FC-0 (Signale).... Die WWNN des HBA in irgendeinem Layer -> FC-4 (beinhaltet welches Übertragungsmedium SAS oder SATA) danach wird das einem IP-Paket übergeben. Das IP-Paket wird dann wieder auseinandergenommen in der Transport-Schicht.
kann anschliessend werden dem Datensegment Ports hinzugefügt....
Nicht bei FC, denn das ist ja kein TCP/IP sondern ein ganz anderes Verfahren und Protokoll. Obwohl auch nicht ganz, denn FC nutzt SCSI Kommandos aber in einem anderen Rahmen...über Glasfaser seriell eben.Mit IP hat das rein gar nix zu tun.
Verstehe mittlerweile etwas mehr von SCSI. So wie ich das verstehe, nutzt Fibre Channel auch die Kommandos von SCSI darum hat es auch etwas mit SCSI zu tun? Fibre Channel hat aber mit der Schnittstelle sonst nichts weiter zu tun. SAS heisst ja Serial Attachet SCSI darum haben beide etwas miteinander zu tun. Über diese beiden Schnittstellen werden ja auch HDDS von Servern angeschlossen (ich kenne es aus meiner Erfahrung heraus nur SATA und SAS). Hingegen Fibre Channel dient nicht dazu, Festplatten anzuschließen sondern um das (langsame) Kupfer-Kabel abzulösen. // Edit von 15.3
Diese SCSI Kommandos finden ja in der FC-4 Layer statt, genauso könnten es ja auch IP-Kommandos sein oder ?
Aber oft brauchts ja auch einen Port den die Fibre Channel Daten werden von einem Server oder Client angefordert. Das durchläuft ja dann alle OSI-Schichten im normal Fall? Wenn ein HTTP-Server eine Datei die auf einem SAN liegt anfordert z.B?
Wieso sollte man überhaupt FCoE benutzten?
Wieso sollte man überhaupt VoIP benutzen.FC und Ethernetnet erfordert 2 Infrastrukturen mit 2mal Hardware und doppelten Kosten.
Um genauer zu sein NICs mit Glas-Anschluss und mit Kupfer? Richtig?
Wieso aber 2 mal Hardware? Die meisten teureren Switche bei der Arbeit haben einen Glas-Faser-Anschluss als Uplink = Fibre Channel?
Kann ich über Glasfaser auch Ethernet betreiben?
Also diese FCoE Netzwerke benötigen aber diese Data Center Bridges die gleichzeitig Glasfaser für Fibre Channel und Kupfer für Ethernet können. Dabei werden alle FC-Frame in ein Ethernet-Frame verkapselt und dann durchläuft das die Kette -> IP-Paket -> Datensegment -> Daten
So wie ich das verstehe basiert FCoE gar nicht auf OSI sondern hat ein eigenes Modell.
Und wieder falsch !FCoE nutzt ja standartisiertes Ethernet Frameing und dann ists wieder OSI. Allerdigs eben nur L2 weils nix dadrüber gibt. Ist so wie ARP, das ist auch nicht routebar und hat nur L2
Fibre Channel hat ein eigenes Layer-Modell, sorry verwechselt.
Verstehe nicht ganz. Wo steht nichts darüber? Bei FCoE steht nichts darüber? Weil FCoE kein eigenes Modell hat, meinst du das? Jedoch bei OSI kommt nach L2 die L3 die Vermittlung also die Protokolle fürs Routing?
Also Ethernet basiert auf OSI weil Ethernet kein "eigenes" Layer-Modell hat? TCP/IP kann auf Ethernet basieren und TCP/IP hat jedoch sein eigenes Modell?!
ARP ist nicht routebar das macht Sinn ist auch kein Layer 3 Protokoll das verstehe ich.
Wieso aber 2 mal Hardware? Die meisten teureren Switche bei der Arbeit haben einen Glas-Faser-Anschluss als Uplink = Fibre Channel?
Das isnd aber Ethernet Switches, oder ?Ethernet und FC sind völlig andere Technologien. Stimmt sie nutzen das gleiche Medium aber die aktive Hardware ist vollkommen unterschedlich, deshalb2 unterschiedliche Netze..
Kannst du mir bitte die restlichen Fragen noch beantworten?
Danke.
Danke.
Zitat von @aqui:
Ob das Ethernet Switche sind weiss ich nicht, hatte ich auch nie gefragt, werde in Zukunft jedoch fragen. Vermutlich sind es wohl Ethernet Switche...Wieso aber 2 mal Hardware? Die meisten teureren Switche bei der Arbeit haben einen Glas-Faser-Anschluss als Uplink = Fibre Channel?
Das isnd aber Ethernet Switches, oder ?Ethernet und FC sind völlig andere Technologien. Stimmt sie nutzen das gleiche Medium aber die aktive Hardware ist vollkommen unterschedlich, deshalb2 unterschiedliche Netze..
Ok, darum auch 2 unterschiedliche Hardware-Typen im Einsatz wenn nicht gleich FCoE benutzt wird. Wenn ich das so richtig verstanden habe.
Vermuten sollte man in der IT nicht...! Es ist ein erheblicher Unterschied ob Ethernet oder Fibre Channel Switches. Optisch sehen die gleich aus drinnen ist aber was völlig unterschiedliches.
Mach dich also schlau wenn du es wissen willst was was ist...
Mach dich also schlau wenn du es wissen willst was was ist...
Zitat von @aqui:
Vermuten sollte man in der IT nicht...! Es ist ein erheblicher Unterschied ob Ethernet oder Fibre Channel Switches. Optisch sehen die gleich aus drinnen ist aber was völlig unterschiedliches.
Mach dich also schlau wenn du es wissen willst was was ist...
Vermuten sollte man in der IT nicht...! Es ist ein erheblicher Unterschied ob Ethernet oder Fibre Channel Switches. Optisch sehen die gleich aus drinnen ist aber was völlig unterschiedliches.
Mach dich also schlau wenn du es wissen willst was was ist...
Ja, hatte nicht gefragt, darum vermute ich einen Ethernet Switch. Kannst du mir noch bitte die restlichen Fragen von oben beantworten? Dankeschön
Da waren keine Fragen mehr...???
Doch jede Menge
. Hier nochmals:Zitat von @osze90:
Ja halt als Privat-Anwender ist Ethernet fast überall zu finden. Das meinte ich Wenn man das Fibre Channel in ein OSI-Referenzmodell klassifizieren müsste befindet sich das ja im Layer 2 auf der Sicherungsschicht richtig? Wo auch dieses Token Ring, Ethernet.... ist richtig? Was ich auch gelernt habe Fibre Channel hat auch wie TCP/IP ein eigenes Schichten-Modell und zwar nur 4 Schichten.
VoIP nutzt das IP Protokoll für den Transport der Voice Daten ! Wie der name ja schon sagt...
Über welche Infrstruktur, Ethernet, Seriell, ATM, MPLS oder ein feuchter Bindfaden ist damit ja noch gar nicht gesagt.
Verwechsle also bitte nicht Äpfel mit Birnen hier im freien Fall.
Wofür benötigt man den Gateways? Es gibt ja Geräte die sind mit VOIP-Gateways angeschrieben sind? Ein Gateway vermittelt laut Wikipedia zwischen mehreren Netzwerkprotokollen z .B SIP zu TCP/IP etc? Also ist ein Router auch ein Gatway darum weil er zwischen mehreren Netzwerkprotokollen vermittelt? Also wenn auf Seite A ein ADSL-Netzwerk ist und auf Seite B ein Ethernet-Netzwerk nimmt man einen Gateway um diese beiden Netze zu verbinden bzw. damit diese beiden unterschiedlichen Protokolle miteinander Kommunizieren können.
Die Bridge erfüllt ja ähnliche Aufgaben nur paar Schichten weiter unten z.B Funk (WLAN) zu Kabel (LAN)? Auch ein GIBIC ist ja eine Bridge am einen Ort kommt ein Optisches Signal am andern Ende gehts per Kabel oder so weiter oder halt über Leiterbahnen (habe nie in einen Switch reingeschaut)
NetBIOS und diverse andere Protokolle kennen nur einen Layer 2.
Ja Fibre Channel hat auch nur 4.
Wenn ich nun von meinem PC über Ethernet ein Bild von einem Server herunterladen will (Server ist an einem SAN mit Fibre Channel anschl.) muss das ganze OSI-Referenzmodell durchlaufen werden? Also stimmt das doch?
Bei FC wirds ein FC Frame und wenn du z.B. iSCSI machst wids ein IP Paket
Ja das leuchtet mir ein den ein FC-Frame (Fibre Channel) ist wie ein Ethernet-Frame (Ethernet) auf der Sicherungsschicht (OSI 2) und ein IP-Paket auf der Vermittlungsschicht OSI Layer 3.
Wie meinst du das mit wenn ein FC-Frame iSCSI macht wirds ein IP-Paket? Also SCSI nutzt doch niemand mehr das ist doch uralt wie die ATA. Heute gibt doch meisten nur noch SATA oft in Computern und SAS oft in Servern? Also du willst mir sagen über Fibre Channel wird ein FC-Frame erstellt -> In den Layern FC-0 - FC-4 sind die Daten. FC-0 (Signale).... Die WWNN des HBA in irgendeinem Layer -> FC-4 (beinhaltet welches Übertragungsmedium SAS oder SATA) danach wird das einem IP-Paket übergeben. Das IP-Paket wird dann wieder auseinandergenommen in der Transport-Schicht.
Mit IP hat das rein gar nix zu tun.
Verstehe mittlerweile etwas mehr von SCSI. So wie ich das verstehe, nutzt Fibre Channel auch die Kommandos von SCSI darum hat es auch etwas mit SCSI zu tun? Fibre Channel hat aber mit der Schnittstelle sonst nichts weiter zu tun. SAS heisst ja Serial Attachet SCSI darum haben beide etwas miteinander zu tun. Über diese beiden Schnittstellen werden ja auch HDDS von Servern angeschlossen (ich kenne es aus meiner Erfahrung heraus nur SATA und SAS). Hingegen Fibre Channel dient nicht dazu, Festplatten anzuschließen sondern um das (langsame) Kupfer-Kabel abzulösen. // Edit von 15.3
Diese SCSI Kommandos finden ja in der FC-4 Layer statt, genauso könnten es ja auch IP-Kommandos sein oder ?
Aber oft brauchts ja auch einen Port den die Fibre Channel Daten werden von einem Server oder Client angefordert. Das durchläuft ja dann alle OSI-Schichten im normal Fall? Wenn ein HTTP-Server eine Datei die auf einem SAN liegt anfordert z.B?
FC und Ethernetnet erfordert 2 Infrastrukturen mit 2mal Hardware und doppelten Kosten.
Kann ich über Glasfaser auch Ethernet betreiben? Ja oder? Den der Uplink eines Ethernet Switches ist oft ein Glasanschluss. Wenn ich einen Ethernet Switche benutze = Ethernet; Wenn ich einen Switched Fabric aus dem Bereich von Fibre Channel nutzte habe ich ein Fibre Channel Netz? Was ist bei einem Point-to-Point Topologie bei Fibre Channel? Dort ist kein Switch für Fibre Channel im Einsatz? Wenn ich nun einen SAN und gleichzeitig einen Server kaufe, könnte ich statt mit einem SAS-Kabel auch mit einem Glasfaser-Kabel (Point-to-Point) den Server und den SAN verbinden = Fibre Channel?
Also diese FCoE Netzwerke benötigen aber diese Data Center Bridges die gleichzeitig Glasfaser für Fibre Channel und Kupfer für Ethernet können. Stimmt das so? Dabei werden alle FC-Frame in ein Ethernet-Frame verkapselt und dann durchläuft das die Kette -> IP-Paket -> Datensegment -> Daten?
FCoE nutzt ja standartisiertes Ethernet Frameing und dann ists wieder OSI. Allerdigs eben nur L2 weils nix dadrüber gibt. Ist so wie ARP, das ist auch nicht routebar und hat nur L2
Fibre Channel hat ein eigenes Layer-Modell, sorry verwechselt.
Verstehe nicht ganz. Wo steht nichts darüber? Bei FCoE steht nichts darüber? Weil FCoE kein eigenes Modell hat, meinst du das? Jedoch bei OSI kommt nach L2 die L3 die Vermittlung also die Protokolle fürs Routing?
Also Ethernet basiert auf OSI weil Ethernet kein "eigenes" Layer-Modell hat? TCP/IP kann auf Ethernet basieren und TCP/IP hat jedoch sein eigenes Modell?!
Zitat von @aqui:
Besser nicht so aus dem Fenster lehnen bei Dingen wo du im freien Fall raten musst...
Okay ja normalerweise wird ja für Internet etc immer Ethernet benutzt.
Völliger Unsinn ! Woher nimmst du diese Weisheiten wenn du noch nichtmal sowas simples wie Glasfaser kennst.Besser nicht so aus dem Fenster lehnen bei Dingen wo du im freien Fall raten musst...
Ja halt als Privat-Anwender ist Ethernet fast überall zu finden. Das meinte ich
Wenn man das Fibre Channel in ein OSI-Referenzmodell klassifizieren müsste befindet sich das ja im Layer 2 auf der Sicherungsschicht richtig? Wo auch dieses Token Ring, Ethernet.... ist richtig? Was ich auch gelernt habe Fibre Channel hat auch wie TCP/IP ein eigenes Schichten-Modell und zwar nur 4 Schichten.VOIP kommuniziert ja nicht über Ethernet sondern nutzt ja eine andere Technologie,
Auch wieder völliger Unsinn !!VoIP nutzt das IP Protokoll für den Transport der Voice Daten ! Wie der name ja schon sagt...
Über welche Infrstruktur, Ethernet, Seriell, ATM, MPLS oder ein feuchter Bindfaden ist damit ja noch gar nicht gesagt.
Verwechsle also bitte nicht Äpfel mit Birnen hier im freien Fall.
Wofür benötigt man den Gateways? Es gibt ja Geräte die sind mit VOIP-Gateways angeschrieben sind? Ein Gateway vermittelt laut Wikipedia zwischen mehreren Netzwerkprotokollen z .B SIP zu TCP/IP etc? Also ist ein Router auch ein Gatway darum weil er zwischen mehreren Netzwerkprotokollen vermittelt? Also wenn auf Seite A ein ADSL-Netzwerk ist und auf Seite B ein Ethernet-Netzwerk nimmt man einen Gateway um diese beiden Netze zu verbinden bzw. damit diese beiden unterschiedlichen Protokolle miteinander Kommunizieren können.
Die Bridge erfüllt ja ähnliche Aufgaben nur paar Schichten weiter unten z.B Funk (WLAN) zu Kabel (LAN)? Auch ein GIBIC ist ja eine Bridge am einen Ort kommt ein Optisches Signal am andern Ende gehts per Kabel oder so weiter oder halt über Leiterbahnen (habe nie in einen Switch reingeschaut)
aber die Kommunikation ist doch drauf angewiesen das alle Layer benutzt werden?
Nein !NetBIOS und diverse andere Protokolle kennen nur einen Layer 2.
Ja Fibre Channel hat auch nur 4.
Wenn ich nun von meinem PC über Ethernet ein Bild von einem Server herunterladen will (Server ist an einem SAN mit Fibre Channel anschl.) muss das ganze OSI-Referenzmodell durchlaufen werden? Also stimmt das doch?
wird das von einem Bits zu einem FCoE-Frame
Uuuhhhh jetzt wirds aber wieder gruselg... Du rätst hier im freien Fall.. Bei FC wirds ein FC Frame und wenn du z.B. iSCSI machst wids ein IP Paket
Ja das leuchtet mir ein den ein FC-Frame (Fibre Channel) ist wie ein Ethernet-Frame (Ethernet) auf der Sicherungsschicht (OSI 2) und ein IP-Paket auf der Vermittlungsschicht OSI Layer 3.
Wie meinst du das mit wenn ein FC-Frame iSCSI macht wirds ein IP-Paket? Also SCSI nutzt doch niemand mehr das ist doch uralt wie die ATA. Heute gibt doch meisten nur noch SATA oft in Computern und SAS oft in Servern? Also du willst mir sagen über Fibre Channel wird ein FC-Frame erstellt -> In den Layern FC-0 - FC-4 sind die Daten. FC-0 (Signale).... Die WWNN des HBA in irgendeinem Layer -> FC-4 (beinhaltet welches Übertragungsmedium SAS oder SATA) danach wird das einem IP-Paket übergeben. Das IP-Paket wird dann wieder auseinandergenommen in der Transport-Schicht.
kann anschliessend werden dem Datensegment Ports hinzugefügt....
Nicht bei FC, denn das ist ja kein TCP/IP sondern ein ganz anderes Verfahren und Protokoll. Obwohl auch nicht ganz, denn FC nutzt SCSI Kommandos aber in einem anderen Rahmen...über Glasfaser seriell eben.Mit IP hat das rein gar nix zu tun.
Verstehe mittlerweile etwas mehr von SCSI. So wie ich das verstehe, nutzt Fibre Channel auch die Kommandos von SCSI darum hat es auch etwas mit SCSI zu tun? Fibre Channel hat aber mit der Schnittstelle sonst nichts weiter zu tun. SAS heisst ja Serial Attachet SCSI darum haben beide etwas miteinander zu tun. Über diese beiden Schnittstellen werden ja auch HDDS von Servern angeschlossen (ich kenne es aus meiner Erfahrung heraus nur SATA und SAS). Hingegen Fibre Channel dient nicht dazu, Festplatten anzuschließen sondern um das (langsame) Kupfer-Kabel abzulösen. // Edit von 15.3
Diese SCSI Kommandos finden ja in der FC-4 Layer statt, genauso könnten es ja auch IP-Kommandos sein oder ?
Aber oft brauchts ja auch einen Port den die Fibre Channel Daten werden von einem Server oder Client angefordert. Das durchläuft ja dann alle OSI-Schichten im normal Fall? Wenn ein HTTP-Server eine Datei die auf einem SAN liegt anfordert z.B?
Wieso sollte man überhaupt FCoE benutzten?
Wieso sollte man überhaupt VoIP benutzen.FC und Ethernetnet erfordert 2 Infrastrukturen mit 2mal Hardware und doppelten Kosten.
Kann ich über Glasfaser auch Ethernet betreiben? Ja oder? Den der Uplink eines Ethernet Switches ist oft ein Glasanschluss. Wenn ich einen Ethernet Switche benutze = Ethernet; Wenn ich einen Switched Fabric aus dem Bereich von Fibre Channel nutzte habe ich ein Fibre Channel Netz? Was ist bei einem Point-to-Point Topologie bei Fibre Channel? Dort ist kein Switch für Fibre Channel im Einsatz? Wenn ich nun einen SAN und gleichzeitig einen Server kaufe, könnte ich statt mit einem SAS-Kabel auch mit einem Glasfaser-Kabel (Point-to-Point) den Server und den SAN verbinden = Fibre Channel?
Also diese FCoE Netzwerke benötigen aber diese Data Center Bridges die gleichzeitig Glasfaser für Fibre Channel und Kupfer für Ethernet können. Stimmt das so? Dabei werden alle FC-Frame in ein Ethernet-Frame verkapselt und dann durchläuft das die Kette -> IP-Paket -> Datensegment -> Daten?
So wie ich das verstehe basiert FCoE gar nicht auf OSI sondern hat ein eigenes Modell.
Und wieder falsch !FCoE nutzt ja standartisiertes Ethernet Frameing und dann ists wieder OSI. Allerdigs eben nur L2 weils nix dadrüber gibt. Ist so wie ARP, das ist auch nicht routebar und hat nur L2
Fibre Channel hat ein eigenes Layer-Modell, sorry verwechselt.
Verstehe nicht ganz. Wo steht nichts darüber? Bei FCoE steht nichts darüber? Weil FCoE kein eigenes Modell hat, meinst du das? Jedoch bei OSI kommt nach L2 die L3 die Vermittlung also die Protokolle fürs Routing?
Also Ethernet basiert auf OSI weil Ethernet kein "eigenes" Layer-Modell hat? TCP/IP kann auf Ethernet basieren und TCP/IP hat jedoch sein eigenes Modell?!
Welche genau meinst du denn ?? Ist doch zu allen was gesagt !
Ich habe bei allen Fragen noch etwas dazu geschrieben da ich nicht alles genau verstehe wie es funktioniert.
Es gibt ja Geräte die sind mit VOIP-Gateways angeschrieben sind?
Ja, das sind Gateways von VoIP also ein IP Infrastruktur auf klassische Voice Netze wie Analog, ISDN, SDH usw.Also ist ein Router auch ein Gatway darum weil er zwischen mehreren Netzwerkprotokollen vermittelt?
Nein, das ist sachlich vollkommen falsch. Ein Router kann nur bis OSI L3 arbeiten. Der weiss nix von Protokollen usw. Interessiert ihn auch nicht, wozu ?Der liest nur IP Netzwerk Adressen und entscheidet dann WO ein Paket hinmuss...nicht mehr und nicht weniger !
ein ADSL-Netzwerk ist und auf Seite B ein Ethernet-Netzwerk nimmt man einen Gateway
Könnte man so sagen. Letztendlich sind es die Modems die alles wieder auf nacktes IP bringen intern und dann wäre Router auch richtig. Beides ist korrekt.Die Bridge erfüllt ja ähnliche Aufgaben nur paar Schichten weiter unten
Richtig, die arbeitet nur auf Hardware Adressen (Mac)Auch ein GIBIC ist ja eine Bridge
Nein, das ist wieder sachlich falsch. Das ist lediglich ein simpler Medienwandler der elektrische Signale in optische wandelt und umgekehrt.Also SCSI nutzt doch niemand mehr das ist doch uralt wie die ATA.
Auch wieder völliger Unsinn. SAS und auch iSCSI nutzen weiterhin den klassischen SCSI Kommandoset. Auch FC. FC ist grob gesagt nichts anderes als serial SCSI (SAS) über Glasfaser.SCSI ist also höchst lebendig !!
Und auch SATA ist ATA nur eben seriell und nicht mehr parallel. Internet werden weiter ATA Kommandos benutzt. Also auch hier alles noch wie es war...
nutzt Fibre Channel auch die Kommandos von SCSI darum hat es auch etwas mit SCSI zu tun?
Bingo ! Du hast es selber erkannt !!!Kann ich über Glasfaser auch Ethernet betreiben? Ja oder?
Die Frage ist wohl (hoffentlich) nicht ernst gemeint, oder ??Warum haben wohl so viele Ethernet Switches und Router SFP oder SFP+ Ports ??? Denk mal nach !!
Also diese FCoE Netzwerke benötigen aber diese Data Center Bridges die gleichzeitig Glasfaser für Fibre Channel und Kupfer für Ethernet können. Stimmt das so?
Wieder nur halb.....Sie haben natürlich auch Glasfaser für Ethernet an Bord..primär sogar. DCB ist rein für die automatische Prioritätssteuerung und Buffering in diesen Switches zuständig, denn du musst genau die selbe Übertragungssicherheit wie bei FC ja bei Ethernet sicherstellen. FC ist immer "lossless" Ethernet aber nicht es ist aber für sowas wie lossless nicht gemacht, daher DCB Funktionalität in den Switches.
Dabei werden alle FC-Frame in ein Ethernet-Frame verkapselt
Ja, richtig ! Aber bitte FCoE hat keinen IP Header !! Das ist L2 only, also nur Mac Adressen und nix IP !!!Zitat von @aqui:
Es gibt ja Geräte die sind mit VOIP-Gateways angeschrieben sind?
Ja, das sind Gateways von VoIP also ein IP Infrastruktur auf klassische Voice Netze wie Analog, ISDN, SDH usw.Ich bekam erst vor einigen Tagen eine Fehlermeldung auf der Seite depfile.com, dass der Gateway nicht erreichbar ist. Wo werden den Gateways eingesetzt im Web? Verstehe nicht ganz, bei VOIP und analoger Telefonie findet jeweile eine Vermittlung zwischen analog und IP statt. Wo wird das im Web genutzt? Bei Wikipedia steht, dass man SMS zu E-Mail mittels Gateway übersetzten kann. Benutzt eventuell Depfile nicht wie ich IP sondern IPX als Netzwerkprotokoll und darum braucht depfile einen Gateway?
Also ist ein Router auch ein Gatway darum weil er zwischen mehreren Netzwerkprotokollen vermittelt?
Nein, das ist sachlich vollkommen falsch. Ein Router kann nur bis OSI L3 arbeiten. Der weiss nix von Protokollen usw. Interessiert ihn auch nicht, wozu ?Der liest nur IP Netzwerk Adressen und entscheidet dann WO ein Paket hinmuss...nicht mehr und nicht weniger !
ein ADSL-Netzwerk ist und auf Seite B ein Ethernet-Netzwerk nimmt man einen Gateway
Könnte man so sagen. Letztendlich sind es die Modems die alles wieder auf nacktes IP bringen intern und dann wäre Router auch richtig. Beides ist korrekt.Also SCSI nutzt doch niemand mehr das ist doch uralt wie die ATA.
Auch wieder völliger Unsinn. SAS und auch iSCSI nutzen weiterhin den klassischen SCSI Kommandoset. Auch FC. FC ist grob gesagt nichts anderes als serial SCSI (SAS) über Glasfaser.SCSI ist also höchst lebendig !!
Und auch SATA ist ATA nur eben seriell und nicht mehr parallel. Internet werden weiter ATA Kommandos benutzt. Also auch hier alles noch wie es war...
Ok, Wie meinst du das mit: "Internet werden weiter ATA Kommandos benutzt"?
nutzt Fibre Channel auch die Kommandos von SCSI darum hat es auch etwas mit SCSI zu tun?
Bingo ! Du hast es selber erkannt !!!Wenn ich nun von meinem PC über Ethernet ein Bild von einem Server herunterladen will (Server ist an einem SAN mit Fibre Channel anschl.) muss das ganze OSI-Referenzmodell durchlaufen werden?
Kann ich über Glasfaser auch Ethernet betreiben? Ja oder?
Die Frage ist wohl (hoffentlich) nicht ernst gemeint, oder ??Warum haben wohl so viele Ethernet Switches und Router SFP oder SFP+ Ports ??? Denk mal nach !!
Ja, stimmt an das habe ich nicht gedacht. Ethernet Switche haben Glasfaseranschlüsse über diese auch Ethernet läuft.
Also diese FCoE Netzwerke benötigen aber diese Data Center Bridges die gleichzeitig Glasfaser für Fibre Channel und Kupfer für Ethernet können. Stimmt das so?
Wieder nur halb.....Sie haben natürlich auch Glasfaser für Ethernet an Bord..primär sogar. DCB ist rein für die automatische Prioritätssteuerung und Buffering in diesen Switches zuständig, denn du musst genau die selbe Übertragungssicherheit wie bei FC ja bei Ethernet sicherstellen. FC ist immer "lossless" Ethernet aber nicht es ist aber für sowas wie lossless nicht gemacht, daher DCB Funktionalität in den Switches.
Den letzten Satz verstehe ich gar nicht. Kannst du mir das vereinfacht gesagt nochmals genauer erklären bitte.
Dabei werden alle FC-Frame in ein Ethernet-Frame verkapselt
Ja, richtig ! Aber bitte FCoE hat keinen IP Header !! Das ist L2 only, also nur Mac Adressen und nix IP !!!Ja das ist klar, es ist ein Frame, dass nie eine IP-Adresse hat. Ob Ethernet-Frame oder Fibre Channel Frame nie eine IP nur MAC oder bei Fibre Channel diese WWNN.
Ich habe da noch weitere Fragen:
1.) Was ich noch nicht ganz verstehe Fibre Channel Modell besitzt 5 Layer dabei sind Layer FC2+3 in der Sicherungsschicht und auch in der Sitzung und der Transportschicht wenn man es als OSI betrachtet. Wieso ist das so? ->https://de.wikipedia.org/wiki/Fibre_Channel#Schichten (Tabelle)
2.) Diese SCSI Kommandos finden ja in der FC-4 Layer statt, genauso könnten es ja auch IP-Kommandos sein oder ? Wie sehen diese IP Komandos aus? Hat das mit der Vermittlungsschicht einen zusammenhang?
3.)
Und wieder falsch !
FCoE nutzt ja standartisiertes Ethernet Frameing und dann ists wieder OSI. Allerdigs eben nur L2 weils nix dadrüber gibt. Ist so wie ARP, das ist auch nicht routebar und hat nur L2
FCoE nutzt ja standartisiertes Ethernet Frameing und dann ists wieder OSI. Allerdigs eben nur L2 weils nix dadrüber gibt. Ist so wie ARP, das ist auch nicht routebar und hat nur L2
Verstehe nicht ganz. Wo steht nichts darüber? Bei FCoE steht nichts darüber? Weil FCoE kein eigenes Modell hat, meinst du das? Jedoch bei OSI kommt nach L2 die L3 die Vermittlung also die Protokolle fürs Routing?
Wo werden den Gateways eingesetzt im Web?
Im großen Stil bei den VoIP Providern die VoIP so in die (noch) bestehende separate Telefonie Infrastruktur bringen.Aber auch bei jeden Klein- und Kleinstkunden der einen VoIP Router hat. Der macht sowas im Miniformat nämlich VoIP umsetzen in analoge Telefonie oder ISDN.
Ok, Wie meinst du das mit: "Internet werden weiter ATA Kommandos benutzt"?
Freudsche Fehlleistung... "intern werden weiter..." sollte es natürlich heissen Wenn ich nun von meinem PC über Ethernet ein Bild von einem Server herunterladen will
Da du nicht sagst mit welchem Protokoll du das realisierst kann man die Frage nicht umfassend beantworten Wenn du im LAN z.B. FTP nutzt und der Server dann via FC die Daten von der Platte holt dann kann man die Frage mit Ja beantworten.
Den letzten Satz verstehe ich gar nicht.
FC ist von Natur aus designt verlustfrei zu arbeiten. Jedes Bit was du sendest kommt auch ganz sicher am Empfänger an. Klar muss auch so sein, denn da ist immer Storage am anderen Ende.Ethernet hat diesen Ansatz aber genau nicht. Der Ursprung war mal militärischer natur. Es kann ruhig was flöten gehen, TCP oder andere Redundanzen sorgen dafür das es irgendwann ankommt. Sowas wäre bei FC nicht möglich.
Ein Fundamentaler Unterschied, den man aber bei Ethernet mit Buffering, QoS, DCB und anderen Mechanismen kompensiert.
oder Fibre Channel Frame nie eine IP nur MAC oder bei Fibre Channel diese WWNN.
Ausnahme ist FC over IP. Da packt man FC in ein IP Paket und schickts weiter...1.) Kann ich dir nicht beantworten.
2.) Sowas gibt es auch und nennt sich "IP oder FC". Technisch ist das spezifiziert, angewendet wird das aber nirgendwo.
Wo steht nichts darüber? Bei FCoE steht nichts darüber?
An anderen Schichten ! Mac Adresse außen rum das wars.... Bei L2 ist Schluss. L3 (IP) und höher gibts nicht bei FCoE weil gar kein TCP/IP von der Partie ist...folglich auch keine höheren Schichten...ist doch logisch, oder ?
Sorry für die späte Antwort, habe eine neue Stelle angefangen...
Wie die Fritz.Box? Und im Web wirds ja auch genutzt wie in meinem Beispiel erwähnt, aber wo?
Ok, verstehe nicht ATA Kommandos werden im Internet benutzt??? Mit ATA kommuniziert Windows mit der HDD. Was hat das mit dem Internet zutun?
Ethernet hat diesen Ansatz aber genau nicht. Der Ursprung war mal militärischer natur. Es kann ruhig was flöten gehen, TCP oder andere Redundanzen sorgen dafür das es irgendwann ankommt. Sowas wäre bei FC nicht möglich.
Ein Fundamentaler Unterschied, den man aber bei Ethernet mit Buffering, QoS, DCB und anderen Mechanismen kompensiert.
Nicht ganz einfach zu verstehen... Also Ethernet kann mit Verlust umgehen da TCP Protokolle hat, die dafür sorgen das alles durchkommt. Bei Fibre Channel kommt immer alles durch? Das ist dass, was ich verstehe.
1.) Kann ich dir nicht beantworten.
2.) Sowas gibt es auch und nennt sich "IP oder FC". Technisch ist das spezifiziert, angewendet wird das aber nirgendwo.
Bei einem FC-Frame gibts keine MAC-Adressen sondern diese NNWW wenn das nun über FC over Ethernet verschickt wird... Ethernet kann mit diesen NNWW nichts anfangen. Verstehe nicht ganz was du mir sagst...
zu Punkt 2.:
Verstehe ich auch nicht. FC benutzt in den Layern 4 SCSI- oder IP Kommandos um zu kommunizieren. Was ist da der Unterschied? Ist damit eventuell gemeint ISCSI das benutzt ja andere Befehle als das normale SCSI welches direkt mit Kabeln verbunden ist?
FCoE und FC haben nur MAC-Adressen oder also NNWW bei FC? FC und FCoE ist nach Layer 2 Schluss da in FC-Modell keine IP-Schicht existiert? Ok ist verständlich.
P.S zu ISCSI an meiner neuen Arbeitsstelle haben wir die NAS-HDD per ISCSI an Windows Server hinzugefügt. Verstehe jetzt was dieses ISCSI ist. Man lernt jeden Tag... Die HDD wird mit ISCSI so angezeigt als wäre die HDD direkt am System angeschlossen nicht wie bei einem Netzlaufwerk....
Zitat von @aqui:
Aber auch bei jeden Klein- und Kleinstkunden der einen VoIP Router hat. Der macht sowas im Miniformat nämlich VoIP umsetzen in analoge Telefonie oder ISDN.
Wo werden den Gateways eingesetzt im Web?
Im großen Stil bei den VoIP Providern die VoIP so in die (noch) bestehende separate Telefonie Infrastruktur bringen.Aber auch bei jeden Klein- und Kleinstkunden der einen VoIP Router hat. Der macht sowas im Miniformat nämlich VoIP umsetzen in analoge Telefonie oder ISDN.
Wie die Fritz.Box? Und im Web wirds ja auch genutzt wie in meinem Beispiel erwähnt, aber wo?
Ok, Wie meinst du das mit: "Internet werden weiter ATA Kommandos benutzt"?
Freudsche Fehlleistung... "intern werden weiter..." sollte es natürlich heissen Ok, verstehe nicht ATA Kommandos werden im Internet benutzt??? Mit ATA kommuniziert Windows mit der HDD. Was hat das mit dem Internet zutun?
Den letzten Satz verstehe ich gar nicht.
FC ist von Natur aus designt verlustfrei zu arbeiten. Jedes Bit was du sendest kommt auch ganz sicher am Empfänger an. Klar muss auch so sein, denn da ist immer Storage am anderen Ende.Ethernet hat diesen Ansatz aber genau nicht. Der Ursprung war mal militärischer natur. Es kann ruhig was flöten gehen, TCP oder andere Redundanzen sorgen dafür das es irgendwann ankommt. Sowas wäre bei FC nicht möglich.
Ein Fundamentaler Unterschied, den man aber bei Ethernet mit Buffering, QoS, DCB und anderen Mechanismen kompensiert.
Nicht ganz einfach zu verstehen... Also Ethernet kann mit Verlust umgehen da TCP Protokolle hat, die dafür sorgen das alles durchkommt. Bei Fibre Channel kommt immer alles durch? Das ist dass, was ich verstehe.
oder Fibre Channel Frame nie eine IP nur MAC oder bei Fibre Channel diese WWNN.
Ausnahme ist FC over IP. Da packt man FC in ein IP Paket und schickts weiter...1.) Kann ich dir nicht beantworten.
2.) Sowas gibt es auch und nennt sich "IP oder FC". Technisch ist das spezifiziert, angewendet wird das aber nirgendwo.
Bei einem FC-Frame gibts keine MAC-Adressen sondern diese NNWW wenn das nun über FC over Ethernet verschickt wird... Ethernet kann mit diesen NNWW nichts anfangen. Verstehe nicht ganz was du mir sagst...
zu Punkt 2.:
Verstehe ich auch nicht. FC benutzt in den Layern 4 SCSI- oder IP Kommandos um zu kommunizieren. Was ist da der Unterschied? Ist damit eventuell gemeint ISCSI das benutzt ja andere Befehle als das normale SCSI welches direkt mit Kabeln verbunden ist?
Wo steht nichts darüber? Bei FCoE steht nichts darüber?
An anderen Schichten ! Mac Adresse außen rum das wars.... Bei L2 ist Schluss. L3 (IP) und höher gibts nicht bei FCoE weil gar kein TCP/IP von der Partie ist...folglich auch keine höheren Schichten...ist doch logisch, oder ?FCoE und FC haben nur MAC-Adressen oder also NNWW bei FC? FC und FCoE ist nach Layer 2 Schluss da in FC-Modell keine IP-Schicht existiert? Ok ist verständlich.
P.S zu ISCSI an meiner neuen Arbeitsstelle haben wir die NAS-HDD per ISCSI an Windows Server hinzugefügt. Verstehe jetzt was dieses ISCSI ist. Man lernt jeden Tag...
Die HDD wird mit ISCSI so angezeigt als wäre die HDD direkt am System angeschlossen nicht wie bei einem Netzlaufwerk....Bei Fibre Channel kommt immer alles durch? Das ist dass, was ich verstehe.
Ja, Fibre Channel gilt als "Lossless" !Die HDD wird mit ISCSI so angezeigt als wäre die HDD direkt am System angeschlossen nicht wie bei einem Netzlaufwerk....
Der tiefere Sinn von iSCSI wie jeder Netzwerker weiss
Habe noch diese Fragen wo du mir keine Antwort geben konntest:
Wie die Fritz.Box? Und im Web wirds ja auch genutzt wie in meinem Beispiel erwähnt, aber wo?
Ok, verstehe nicht ATA Kommandos werden im Internet benutzt??? Mit ATA kommuniziert Windows mit der HDD. Was hat das mit dem Internet zutun?
1.) Kann ich dir nicht beantworten.
2.) Sowas gibt es auch und nennt sich "IP oder FC". Technisch ist das spezifiziert, angewendet wird das aber nirgendwo.
Bei einem FC-Frame gibts keine MAC-Adressen sondern diese NNWW wenn das nun über FC over Ethernet verschickt wird... Ethernet kann mit diesen NNWW nichts anfangen. Verstehe nicht ganz was du mir sagst...
zu Punkt 2.:
Verstehe ich auch nicht. FC benutzt in den Layern 4 SCSI- oder IP Kommandos um zu kommunizieren. Was ist da der Unterschied? Ist damit eventuell gemeint ISCSI das benutzt ja andere Befehle als das normale SCSI welches direkt mit Kabeln verbunden ist?
FCoE und FC haben nur MAC-Adressen oder also NNWW bei FC? FC und FCoE ist nach Layer 2 Schluss da in FC-Modell keine IP-Schicht existiert? Ok ist verständlich.
Zitat von @aqui:
Aber auch bei jeden Klein- und Kleinstkunden der einen VoIP Router hat. Der macht sowas im Miniformat nämlich VoIP umsetzen in analoge Telefonie oder ISDN.
Wo werden den Gateways eingesetzt im Web?
Im großen Stil bei den VoIP Providern die VoIP so in die (noch) bestehende separate Telefonie Infrastruktur bringen.Aber auch bei jeden Klein- und Kleinstkunden der einen VoIP Router hat. Der macht sowas im Miniformat nämlich VoIP umsetzen in analoge Telefonie oder ISDN.
Wie die Fritz.Box? Und im Web wirds ja auch genutzt wie in meinem Beispiel erwähnt, aber wo?
Ok, Wie meinst du das mit: "Internet werden weiter ATA Kommandos benutzt"?
Freudsche Fehlleistung... "intern werden weiter..." sollte es natürlich heissen Ok, verstehe nicht ATA Kommandos werden im Internet benutzt??? Mit ATA kommuniziert Windows mit der HDD. Was hat das mit dem Internet zutun?
oder Fibre Channel Frame nie eine IP nur MAC oder bei Fibre Channel diese WWNN.
Ausnahme ist FC over IP. Da packt man FC in ein IP Paket und schickts weiter...1.) Kann ich dir nicht beantworten.
2.) Sowas gibt es auch und nennt sich "IP oder FC". Technisch ist das spezifiziert, angewendet wird das aber nirgendwo.
Bei einem FC-Frame gibts keine MAC-Adressen sondern diese NNWW wenn das nun über FC over Ethernet verschickt wird... Ethernet kann mit diesen NNWW nichts anfangen. Verstehe nicht ganz was du mir sagst...
zu Punkt 2.:
Verstehe ich auch nicht. FC benutzt in den Layern 4 SCSI- oder IP Kommandos um zu kommunizieren. Was ist da der Unterschied? Ist damit eventuell gemeint ISCSI das benutzt ja andere Befehle als das normale SCSI welches direkt mit Kabeln verbunden ist?
Wo steht nichts darüber? Bei FCoE steht nichts darüber?
An anderen Schichten ! Mac Adresse außen rum das wars.... Bei L2 ist Schluss. L3 (IP) und höher gibts nicht bei FCoE weil gar kein TCP/IP von der Partie ist...folglich auch keine höheren Schichten...ist doch logisch, oder ?FCoE und FC haben nur MAC-Adressen oder also NNWW bei FC? FC und FCoE ist nach Layer 2 Schluss da in FC-Modell keine IP-Schicht existiert? Ok ist verständlich.
