gruber hat geschrieben:bei meinem videorecorder ist von "operating system" die rede. (dĂĽrfte linuxbasiert sein)
tatsächlich.
wenn's wirklich ein linux ist, dann kommt's auch online.
und trotzdem isses ne firmware, auch wenn's nen linux kernel hat.
gruber hat geschrieben:bei meinem videorecorder ist von "operating system" die rede. (dĂĽrfte linuxbasiert sein)
gruber hat geschrieben:hab ich ganz vergessen: viele router-os ĂĽbrigens auch nicht.
superracer hat geschrieben:gruber hat geschrieben:bei meinem videorecorder ist von "operating system" die rede. (dĂĽrfte linuxbasiert sein)
tatsächlich.
wenn's wirklich ein linux ist, dann kommt's auch online.
und trotzdem isses ne firmware, auch wenn's nen linux kernel hat.
jutta hat geschrieben:gruber hat geschrieben:hab ich ganz vergessen: viele router-os ĂĽbrigens auch nicht.
abgesehen vom unterschied zwischen os und firmware (siehe das posting von dfx) erinnere ich mich da an einen thread vor ein paar tagen, wo du gemeint hast, dass ein pc mit modemanschluss + netzwerkarte ein router ist. diese definition trifft auf sehr viele pcs zu. relativiert das deine aussage nicht etwas?
superracer hat geschrieben:wenn's wirklich ein linux ist, dann kommt's auch online.
jutta hat geschrieben:nun, wenn fast jeder pc ein router ist, dann beherrscht die grosse mehrzahl der router die pptp-einwahl, was deine aussage, dass viele router-os sie nicht beherrschen, relativiert. ein paar bleiben sicher uebrig - warum solls keine dummen router geben? die sind dafuer vielleicht besonders schoen, ist ja auch was wert.
dfx hat geschrieben:normalerweise läuft es so ab: ein device (pc oder sonstwas) macht einen dhcp request über sein netzwerkinterface raus. von einem zentralen dhcp server im inode-netz wird dann eine ip-adresse (aus dem bereich 172.16.*), netmask (255.255.255.0) und default gateway (172.16.xxx.1) vergeben. damit kann das device einmal mit andern netzwerkdevice sprechen, ist allerdings nur in einem internen wan online und nicht mit dem restlichen internet verbunden.
in diesem internen wan gibt es einen pptp-server, der die ip-adresse 10.0.0.138 hat. da diese ip-adresse nicht im selben subnetz liegt, wie die ip-adresse des devices, muĂź diese ĂĽber den default gateway angesprochen werden. dh von der 172.16.xxx.yyy aus kann die 10.0.0.138 nur mit 172.16.xxx.1 als zwischenhop erreicht werden.
nun wird ein pptp-tunnel und darin eine pptp-session auf die 10.0.0.138 aufgebaut. dh es entsteht ein tunnel zwischen der 172.16.xxx.yyy und der 10.0.0.138. in diesem tunnel läuft eine ppp-session ab, was das selbe protokoll ist, was zb bei dialup-zugängen über analoges modem verwendet wird. in der anfangsphase werden (nebst authentifizierung usw) zwischen den beiden ppp-endpunkten ip-adressen ausgetauscht. genauer gesagt: das device mit der 172.16.xxx.yyy erhält von der gegenstelle eine ip-adresse zugewiesen und bekommt außerdem die ip seiner gegenstelle mitgeteilt.
dadurch erhält das device nun zusätzlich zur 172.16.xxx.yyy noch eine zweite ip-adresse über den pptp-tunnel, diesmal eine aus dem öffentlichen internet. die ip der gegenstelle (ebenfalls eine öffentliche) wird dann als gateway verwendet, um das restliche internet zu erreichen.
ip-pakete, die zwischen der öffentlichen ip des devices und dem internet ausgetauscht werden, werden erst in pptp-pakete eingepackt ("eingekapselt") und dann durch den pptp-tunnel an die ppp-gegenstelle verschickt. auf der andern seite werden die dann wieder ausgepackt und an das richtige ziel weiterverschickt. die umgekehrte richtung läuft genauso ab.
was den netgear angeht: anscheinend haben so ziemlich alle netgear router das problem, dieses einfache setup nicht zu verstehen und deshalb entweder gar nicht gehen, oder nur mit ein paar tricks. aus den beiden screenshots geht zb hervor, daß da lokal eine statische ip und statische route vergeben wird, was eigentlich nicht sein dürfte: wenn diese ip nämlich vom dhcp server an einen andern kunden vergeben wird, kann dieser mit der ip nicht online und du dann auch nicht mehr.
die statische route hat folgenden sinn: er wird ja einmal am anfang über dhcp ein default gateway vergeben, und danach in der ppp-session noch einer. der erste gateway ist nur wichtig, um die 10.0.0.138 erreichen zu können, der zweite gateway ist dazu da, das öffentliche internet zu erreichen (und der zeigt auf die ip der ppp-gegenstelle). wenn nun die zweite default route die erste "überschreibt", kann die 10.0.0.138 nicht mehr erreicht werden, somit bricht der tunnel wieder ab. deswegen wird die erreichbarkeit der 10.0.0.138 schon im vorfeld durch eine statische route garantiert.
das ganze hab ich im schnellverfahren runtergetippt, falls was noch unklar sein sollte, bitte fragen.
tombman hat geschrieben:1. wieso steht in der static route 10.0.0.0 und nicht 10.0.0.138 ? ist die letzte 0 als wildcard zu verstehen, damit alle "10er server" erreicht werden können und nicht nur der 138er?
2. bei dem 3000/384 account bekommt man von inode eine statische ip. meint man damit die aus dem tunnel kommende öffentliche 62.x.x.x (= meine jetzige von außen sichtbare ip), die auch auf dem zettel mit den zugangsdaten steht?
3. wenn, wie du sagst, die erste 172.x.x.x (plus maske + gateway 172.x.x.1) vom ersten dhcp dynamisch vergeben wird, wieso kann ich sie dann im router fix eintragen und es funkt?
oder bleibt der erste inode dhcp erstmal bei einer ip für einen kunden, wenn er mal eine vergeben hat- besonders bei einem 3000/384 kunden, der ja auch eine öffentlich statische 62er ip braucht.
so nach dem motto: öffentlich statisch, also auch "zum tunnel" statisch?
4.) kann ich die "tunnel-gateway" ip irgendwie rausfinden? oder ist das einfach die 62.x.x.1 ?
5.) wieso bekomm ich beim pingen auf das 172er gateway und auf 10.0.0.138 keine antwort? (eigenheit des wgt634?)
6.) hat inode vor jemals diesen vpnpptp tunnel quatsch aufzugeben?
7.) welche router unter 300€ sind deiner meinung nach die besten und flexibelsten?
ZurĂĽck zu MOBILES INTERNET, WLAN & FUNK
Mitglieder in diesem Forum: 0 Mitglieder und 13 Gäste