29
Routing - Fremdnetz in vorhandenes Netz zur Internetnutzung einbinden
Eine häufig gestellte Frage ist, wie man ein Fremdnetz an ein existierendes Netz anschließt, um dort die Internetverbindung nutzen zu können, ohne Zugriff auf das Hauptnetz zu erlangen. Dieses Tutorial soll die Grundlagen von Routing schildern.
Gegeben ist ein Netz mit drei Workstations im Netz 192.168.0.0 Maske 255.255.255.0 mit eingebundenem Router und der IP 192.168.0.254, der den Internetzugang bereit stellt.
Ein zweites Netz mit der Netzwerkadresse 192.168.123.0 soll so an das vorhandene Netz angebunden werden, dass ausschließlich die Internetverbindung genutzt werden kann. Zu diesem Zweck wird ein zusätzlicher Rechner ("Workstation a") mit zwei Netzwerkkarten in das Netz aufgenommen, der mit dem Interface 192.168.123.254 in das einzubindende Netz zeigt (Achtung!!! Dieser Rechner ist aus dem Fremdnetz zu sehen!). Wird diese Verbindung über einen Hub oder Switch realisiert, ist ein normales Patchkabel zu verwenden, wird die Verbindung direkt von Rechner zu Rechner hergestellt, ist zwingend ein gekreuztes Patchkabel zu verwenden.
Auf "Workstation a" ist das Routing zu aktivieren über:
"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" setzen auf "IPEnableRouter=1"
Damit wir erreicht, dass "Workstation a" Anfragen in das Netz 192.168.123.0 weiterleitet. Um die Clients, im Fremdnetz nun wissen zu lassen, woher sie ihr Internet beziehen müssen, erhalten die Netzwerkkarten in den Eigenschaften der Netzwerkverbindung als Gateway die IP-Adresse der Karte "Workstation a extern" und als DNS-Server die Interne IP des Routers. Damit sie aber den Weg zum Router überhaupt finden, muss ihnen eine statische Route eingetragen werden:
"route add -p 192.168.0.1 mask 255.255.255.255 192.168.123.254".
Der Router weiß nun seinerseits noch nicht, wohin er Pakete zu schicken hat, die für dieses Fremdnetz ankommen. Ihm muss folglich auch eine eine statische Route gegeben werden in der Art:
finde das Netz 192.168.123.0 mit Maske 255.255.255.0 über das Interface 192.168.0.254
Dieser Eintrag ist von Router zu Router unterschiedlich und kann daher nur "bildlich" angegeben werden. Sollte der Router auch "NAT" verstehen, muss auch dort ein entsprechender Eintrag gemacht werden.
Somit ist die Aufgabe gelöst und das Fremdnetz hat Internetzugang.
Wenn die beiden Netze obendrein miteinander kommunizieren sollen, ist der Eintrag der statischen Route für alle Clients im Netz 192.168.123.0 nur folgendermaßen vorzunehmen:
"route add -p 192.168.0.0 mask 255.255.255.0 192.168.123.254",
das Hauptnetz muss nun natürlich noch den Weg zurück erklärt bekommen indem dort auf allen Clients der Eintag:
"route add -p 192.168.123.0 mask 255.255.255.0 192.168.0.254" gemacht wird.
Und nun viel Spaß beim Routing,
Atti.
PS: Für Hinweise und Korrekturen bin ich wie immer dankbar.
Nachtrag vom 21.10.2005
Nach eingehender Diskussion mit Günni und Hämmi und nochmaliger Überprüfung am Testnetz muss festgestellt werden:
Die Route im zweiten Netz ist möglicherweise nicht notwendig, da das Standardgateway 192.168.123.254 diesen Weg bereits beschreibt und das Gateway für den Internetzugang zwingend notwendig ist. Ebenso ist der Routingeintrag im ersten Netz im Falle, dass die Netze sich sehen sollen, nicht zwingend erforderlich, er verkürzt aber den Weg zu Netz zwei.
Auf Grund der Routingfunktionalität der Workstation A und der Tatsache, dass der Router den Weg in das !92.168.123.0 - Netz kennt, ist eine Abschottung der beiden Netze gegeneinander nicht gegeben. Wenn diese Trennung zwingend erfolgen muss, ist das zweite Netz in ein sogenanntes DMZ zu hägen, sofern der Router diese Funtionalität unterstützt.
Anmerkung: Ich habe überlegt, ob ich dieses Tutorial auf Grund dessen zurückziehen soll oder nicht, habe mich aber dafür entschieden, es in der alten, unveränderten Form hier stehen lassen, da die Frage "Wie verbinde ich zwei Netzwerke über WLAN miteinander" hier häufig gestellt wird und das kann man analog zu dieser Anleitung bewerkstelligen.
Ende des Nachtrags
Gegeben ist ein Netz mit drei Workstations im Netz 192.168.0.0 Maske 255.255.255.0 mit eingebundenem Router und der IP 192.168.0.254, der den Internetzugang bereit stellt.
Ein zweites Netz mit der Netzwerkadresse 192.168.123.0 soll so an das vorhandene Netz angebunden werden, dass ausschließlich die Internetverbindung genutzt werden kann. Zu diesem Zweck wird ein zusätzlicher Rechner ("Workstation a") mit zwei Netzwerkkarten in das Netz aufgenommen, der mit dem Interface 192.168.123.254 in das einzubindende Netz zeigt (Achtung!!! Dieser Rechner ist aus dem Fremdnetz zu sehen!). Wird diese Verbindung über einen Hub oder Switch realisiert, ist ein normales Patchkabel zu verwenden, wird die Verbindung direkt von Rechner zu Rechner hergestellt, ist zwingend ein gekreuztes Patchkabel zu verwenden.
Auf "Workstation a" ist das Routing zu aktivieren über:
"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" setzen auf "IPEnableRouter=1"
Damit wir erreicht, dass "Workstation a" Anfragen in das Netz 192.168.123.0 weiterleitet. Um die Clients, im Fremdnetz nun wissen zu lassen, woher sie ihr Internet beziehen müssen, erhalten die Netzwerkkarten in den Eigenschaften der Netzwerkverbindung als Gateway die IP-Adresse der Karte "Workstation a extern" und als DNS-Server die Interne IP des Routers. Damit sie aber den Weg zum Router überhaupt finden, muss ihnen eine statische Route eingetragen werden:
"route add -p 192.168.0.1 mask 255.255.255.255 192.168.123.254".
Der Router weiß nun seinerseits noch nicht, wohin er Pakete zu schicken hat, die für dieses Fremdnetz ankommen. Ihm muss folglich auch eine eine statische Route gegeben werden in der Art:
finde das Netz 192.168.123.0 mit Maske 255.255.255.0 über das Interface 192.168.0.254
Dieser Eintrag ist von Router zu Router unterschiedlich und kann daher nur "bildlich" angegeben werden. Sollte der Router auch "NAT" verstehen, muss auch dort ein entsprechender Eintrag gemacht werden.
Somit ist die Aufgabe gelöst und das Fremdnetz hat Internetzugang.
Wenn die beiden Netze obendrein miteinander kommunizieren sollen, ist der Eintrag der statischen Route für alle Clients im Netz 192.168.123.0 nur folgendermaßen vorzunehmen:
"route add -p 192.168.0.0 mask 255.255.255.0 192.168.123.254",
das Hauptnetz muss nun natürlich noch den Weg zurück erklärt bekommen indem dort auf allen Clients der Eintag:
"route add -p 192.168.123.0 mask 255.255.255.0 192.168.0.254" gemacht wird.
Und nun viel Spaß beim Routing,
Atti.
PS: Für Hinweise und Korrekturen bin ich wie immer dankbar.
Nachtrag vom 21.10.2005
Nach eingehender Diskussion mit Günni und Hämmi und nochmaliger Überprüfung am Testnetz muss festgestellt werden:
Die Route im zweiten Netz ist möglicherweise nicht notwendig, da das Standardgateway 192.168.123.254 diesen Weg bereits beschreibt und das Gateway für den Internetzugang zwingend notwendig ist. Ebenso ist der Routingeintrag im ersten Netz im Falle, dass die Netze sich sehen sollen, nicht zwingend erforderlich, er verkürzt aber den Weg zu Netz zwei.
Auf Grund der Routingfunktionalität der Workstation A und der Tatsache, dass der Router den Weg in das !92.168.123.0 - Netz kennt, ist eine Abschottung der beiden Netze gegeneinander nicht gegeben. Wenn diese Trennung zwingend erfolgen muss, ist das zweite Netz in ein sogenanntes DMZ zu hägen, sofern der Router diese Funtionalität unterstützt.
Anmerkung: Ich habe überlegt, ob ich dieses Tutorial auf Grund dessen zurückziehen soll oder nicht, habe mich aber dafür entschieden, es in der alten, unveränderten Form hier stehen lassen, da die Frage "Wie verbinde ich zwei Netzwerke über WLAN miteinander" hier häufig gestellt wird und das kann man analog zu dieser Anleitung bewerkstelligen.
Ende des Nachtrags
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: 17491
Url: https://administrator.de/tutorial/routing-fremdnetz-in-vorhandenes-netz-zur-internetnutzung-einbinden-17491.html
Ausgedruckt am: 23.12.2024 um 11:12 Uhr
29 Kommentare
Neuester Kommentar
Schön dass das mal einer zusammengestellt hat! 
Ups, ist da ein Fehler in der Grafik?
Müssten die Clients im Netz 192.168.123.0 nicht als Gateway das
192.168.123.254
haben?
Steht zwar oben drüber, aber unter den Grafiken steht jeweils das GW 192.168.0.254.
Ich weiss, die statische Route regelt den Verkehr in das "0"-er Netz, aber die 123-er-Clients würde sehr wahrscheinlich meckern, wenn das GW außerhalb des 123-er Netzes liegt (trotz Route) ? oder verhindert die statische Route genau diese (Windows-)"Fehlermeldung"?
Gruß, Rene
Müssten die Clients im Netz 192.168.123.0 nicht als Gateway das
192.168.123.254
haben?
Steht zwar oben drüber, aber unter den Grafiken steht jeweils das GW 192.168.0.254.
Ich weiss, die statische Route regelt den Verkehr in das "0"-er Netz, aber die 123-er-Clients würde sehr wahrscheinlich meckern, wenn das GW außerhalb des 123-er Netzes liegt (trotz Route) ? oder verhindert die statische Route genau diese (Windows-)"Fehlermeldung"?
Gruß, Rene
@Rene
Natürlich hast Du Recht - das Gateway war falsch. Das kommt davon, wenn man im "Modell" nachträglich die IP's ändert
...
Danke,
Atti
Natürlich hast Du Recht - das Gateway war falsch. Das kommt davon, wenn man im "Modell" nachträglich die IP's ändert
...Danke,
Atti
@Atti58
Hi,
ich kann mich erinnern, das bei ähnlicher Konstellation, nur ein Netzwerk über einen Router ins
Internet, die Clients die Adresse eines öffentlichen DNS-Servers gebraucht haben, und
NICHT die Adresse des Routers als DNS-Server. Mit anderen Worten:
Das Gateway, der Router, ermöglicht dem Client erst, DNS-Info zu beschaffen; mir fällt grad´keine
andere Umschreibung ein.
Denn so wird ja erwartet, dass, wenn ich eine Adresse eingebe, der Router selber imstande ist,
die Adresse aufzulösen.
Oder ist das event. vom Router abhängig?
Gruß
Günni
Hi,
ich kann mich erinnern, das bei ähnlicher Konstellation, nur ein Netzwerk über einen Router ins
Internet, die Clients die Adresse eines öffentlichen DNS-Servers gebraucht haben, und
NICHT die Adresse des Routers als DNS-Server. Mit anderen Worten:
Das Gateway, der Router, ermöglicht dem Client erst, DNS-Info zu beschaffen; mir fällt grad´keine
andere Umschreibung ein.
Denn so wird ja erwartet, dass, wenn ich eine Adresse eingebe, der Router selber imstande ist,
die Adresse aufzulösen.
Oder ist das event. vom Router abhängig?
Gruß
Günni
Moin,
im Router selbst ist ein Forward-Eintrag, daher fragt der Router eh' nach "draussen".
Gruß, Rene
im Router selbst ist ein Forward-Eintrag, daher fragt der Router eh' nach "draussen".
Gruß, Rene
@rene_d
Hi,
deshalb ja meine Frage nach den Fähigkeiten eines Routers. Bei uns, wann, wo spielt
ja im Moment keine Rolle, ohne Angabe eines öffentlichen DNS-Servers ging nichts.
Und man muß ja schließlich alle Möglichkeiten in Betracht ziehen.
Meine Frage ist also nur, gibt es (noch) Router, die das einfach nicht können, und sollte man
dies nicht in einem Tutorial berücksichtigen? Quasi, als Ergänzung.
Gruß
Günni
Hi,
deshalb ja meine Frage nach den Fähigkeiten eines Routers. Bei uns, wann, wo spielt
ja im Moment keine Rolle, ohne Angabe eines öffentlichen DNS-Servers ging nichts.
Und man muß ja schließlich alle Möglichkeiten in Betracht ziehen.
Meine Frage ist also nur, gibt es (noch) Router, die das einfach nicht können, und sollte man
dies nicht in einem Tutorial berücksichtigen? Quasi, als Ergänzung.
Gruß
Günni
Hallo Günni,
die meisten Router (ich denke mal "eigentlich" alle ) haben keinen eigenen DNS-Server. Zwar setzt man sie den Clients (muss aber nicht!) als DNS vor, der Router selbst ist aber nicht in der Lage, eigene DNS-Anfragen (auf)zu lösen ? daher trägt man den Kisten den EXTERNEN DNS des Providers (oder einen öffentlichen) mittels der IP ein.
Bekommt der Router nun eine DNS-Anfrage seines Client´s, fragt er blitzschnell beim ISP nach und liefert diese Auflösung an den Client (Port 53), bzw, er nutzt die Auflösung zur Konnektierung.
Grundsätzlich ist der Router als "DNS-Dealer" [also 'Forwarder'] anzusehen, er selbst kann es natürlich nicht.
Gruß, Rene
die meisten Router (ich denke mal "eigentlich" alle
) haben keinen eigenen DNS-Server. Zwar setzt man sie den Clients (muss aber nicht!) als DNS vor, der Router selbst ist aber nicht in der Lage, eigene DNS-Anfragen (auf)zu lösen ? daher trägt man den Kisten den EXTERNEN DNS des Providers (oder einen öffentlichen) mittels der IP ein.Bekommt der Router nun eine DNS-Anfrage seines Client´s, fragt er blitzschnell beim ISP nach und liefert diese Auflösung an den Client (Port 53), bzw, er nutzt die Auflösung zur Konnektierung.
Grundsätzlich ist der Router als "DNS-Dealer" [also 'Forwarder'] anzusehen, er selbst kann es natürlich nicht.
Gruß, Rene
daher trägt man den Kisten
den EXTERNEN DNS des Providers (oder einen
öffentlichen) mittels der IP ein.
den EXTERNEN DNS des Providers (oder einen
öffentlichen) mittels der IP ein.
@rene_d
Hi,
GENAU das ist es ja, was ich meine, die Clients im Tutorial HABEN ja als DNS-Eintrag
die Adresse des Routers, und eben KEINEN externen(z.B. des Providers) Eintrag.
KANN??? die Adresse des Routers eingetragen sein, und wenn es nicht funkt., sollte
DANN ein DNS-Eintrag eines öffentl., meinetwegen des Providers, DNS-Servers vorgenommen werden???
Ich sehe meine Frage ja nur als Ergänzung des Tutorials, also wenn das eine nicht geht, probiert mal das.
Gruß
Günni
Hallo Günni,
sorry, ich bin etwas schwer von Begriff heute Ich sitze wohl auf dem Kopf.
Klar, man KANN dem Client auch direkt einen externen DNS eintragen, das ist kein Problem, AUßER: Man ist innerhalb einer Domäne! Dann MUSS der DNS der AD-Server sein, sonst gibt es Probleme.
Innerhalb von Workgroups kann man jederzeit direkt den externen DNS eintragen, zumal man auch die HOST-Datei entsprechend mit den Workgroup-Membern "füttern" kann.
Gruß, Rene
Ich geh´jetzt wieder in´s Heim
sorry, ich bin etwas schwer von Begriff heute
Ich sitze wohl auf dem Kopf.Klar, man KANN dem Client auch direkt einen externen DNS eintragen, das ist kein Problem, AUßER: Man ist innerhalb einer Domäne! Dann MUSS der DNS der AD-Server sein, sonst gibt es Probleme.
Innerhalb von Workgroups kann man jederzeit direkt den externen DNS eintragen, zumal man auch die HOST-Datei entsprechend mit den Workgroup-Membern "füttern" kann.
Gruß, Rene
Ich geh´jetzt wieder in´s Heim
Ich habe mir zum Schreiben dieses Tutorials extra eine Testumgebung aufgebaut und die war so eingerichtet, wie oben abgebildet - definitiv. Natürlich ist es kein Fehler, wenn man externe DNS-Server einträgt und es sollte trotzdem funktionieren, mir ging es um eine möglichst einfache Darstellung,
Gruß
Atti.
Gruß
Atti.
Hallo Atti,
ich denke, Deine Leistung ist hier in keiner Art und Weise davon betroffen.
Es ging nur um mein Brain 2.0a (RC-1 ) ? das hing gestern wohl etwas!
Der gestrige Tag hat sehr hohe Anforderungen gestellt, da hatte ich wohl einen 'Pufferüberlauf' in meiner "Betriebssoftware"
Leider musste ich dann Günni mit den "Ergebnissen" meiner inkompetenten Brain-Software zum Wahnsinn treiben. Aber keine Sorge, ich habe heute Nacht eine Wartung gefahren, jetzt läuft wieder alles
Gruß, Rene
ich denke, Deine Leistung ist hier in keiner Art und Weise davon betroffen.
Es ging nur um mein Brain 2.0a (RC-1
) ? das hing gestern wohl etwas!Der gestrige Tag hat sehr hohe Anforderungen gestellt, da hatte ich wohl einen 'Pufferüberlauf' in meiner "Betriebssoftware"
Leider musste ich dann Günni mit den "Ergebnissen" meiner inkompetenten Brain-Software zum Wahnsinn treiben. Aber keine Sorge, ich habe heute Nacht eine Wartung gefahren, jetzt läuft wieder alles
Gruß, Rene
Hallo Atti58,
Du hast dir viel Mühe gemacht und diese Lösung funktioniert sicherlich.
Wenn du einen "guten" Router hast, dann bindest du einfach auf die interne Netzwerkkarte des Routers eine 2. IP-Adresse (neues Netz) auf und damit sparst Du Dir eine Windows-Maschine, die du als Router zu nutzten nußt.
Gruß
Hämmi
Du hast dir viel Mühe gemacht und diese Lösung funktioniert sicherlich.
Wenn du einen "guten" Router hast, dann bindest du einfach auf die interne Netzwerkkarte des Routers eine 2. IP-Adresse (neues Netz) auf und damit sparst Du Dir eine Windows-Maschine, die du als Router zu nutzten nußt.
Gruß
Hämmi
@hämmi
... danke für Deinen Hinweis. Die zweite Maschine habe ich eigentlich nur vorgesehen, damit alle vorhandenen Rechner des "Hauptnetzes" unsichtbar bleiben. Das mit der zweiten IP für die interne Karte ist zwar verlockend, in anderem Zusammenhang habe ich da aber schon Pleiten erlebt, deshalb habe ich die Lösung mit der zusätzlichen Karte gewählt,
Gruß
Atti.
... danke für Deinen Hinweis. Die zweite Maschine habe ich eigentlich nur vorgesehen, damit alle vorhandenen Rechner des "Hauptnetzes" unsichtbar bleiben. Das mit der zweiten IP für die interne Karte ist zwar verlockend, in anderem Zusammenhang habe ich da aber schon Pleiten erlebt, deshalb habe ich die Lösung mit der zusätzlichen Karte gewählt,
Gruß
Atti.
@Atti:
Super Beitrag, schön mal wieder was von dir zu hören.
@all:
Die Diskussion um den DNS kann ich nicht verstehen. Es wiederspricht aller Regel der Kunst, einen DNS direkt am Client einzutragen. Mal ganz abgesehen davon, daß dann evtl. zuest Anfragen ins Internet und danach ins lokale Netz geleitet werden, was u.U. nicht nur sicherheitsbedenklich, sondern auch nicht schnell ist. In einem sauberen Netzwerk hat der Client keine Anfragen nach draußen zu stellen, dies macht immer ein vorgesetzter Server, Router etc. Natürlich ist am schösnten, wenn man im Netz einen eigenen DNS hat, der im Zweifel die Anfrage weiterleitet. Aber für den Homezweck tuts der Router auch.
@Atti:
Wo hast du die Graphik her.... sehr gut lesbar.....
Super Beitrag, schön mal wieder was von dir zu hören.
@all:
Die Diskussion um den DNS kann ich nicht verstehen. Es wiederspricht aller Regel der Kunst, einen DNS direkt am Client einzutragen. Mal ganz abgesehen davon, daß dann evtl. zuest Anfragen ins Internet und danach ins lokale Netz geleitet werden, was u.U. nicht nur sicherheitsbedenklich, sondern auch nicht schnell ist. In einem sauberen Netzwerk hat der Client keine Anfragen nach draußen zu stellen, dies macht immer ein vorgesetzter Server, Router etc. Natürlich ist am schösnten, wenn man im Netz einen eigenen DNS hat, der im Zweifel die Anfrage weiterleitet. Aber für den Homezweck tuts der Router auch.
@Atti:
Wo hast du die Graphik her.... sehr gut lesbar.....
Hallo Christian,
Im Homenetz gebe ich Dir recht ...
Gruß, Rene
Es wiederspricht aller Regel der
Kunst, einen DNS direkt am Client
einzutragen.
Kunst, einen DNS direkt am Client
einzutragen.
Im Homenetz gebe ich Dir recht ...
Gruß, Rene
@linkit
"... schön mal wieder was von dir zu hören ..." - wer war denn hier 'ne Weile abgetaucht?
Ich sag's ja nicht gerne - die Grafik ist mit Visio 2002 gemacht. Die Anpassung der Größe an das hiesige Format aber hat mich einiges an Nerven gekostet ...
Gruß
Atti
"... schön mal wieder was von dir zu hören ..." - wer war denn hier 'ne Weile abgetaucht
?Ich sag's ja nicht gerne - die Grafik ist mit Visio 2002 gemacht. Die Anpassung der Größe an das hiesige Format aber hat mich einiges an Nerven gekostet ...
Gruß
Atti
@Atti58
Hi,
mit der Routerei habe ich einige Verständnisprobleme, wobei ich jetzt nicht die
Funktionalität deines Tutorials in Abrede stellen will, sondern dass mir einige
Sachen einfach unlogisch erscheinen.
Erstes Verständnisproblem:
Durch die Anweisung
"route add ?p 192.168.0.1 mask 255.255.255.255 192.168.123.254"
sollen die Clients ja den Router über das GW 192.168.123.254 erreichen, die Maske
255.255.255.255 soll ja bewirken, dass die Clients ausschließlich den Router erreichen
und sonst keinen anderen im Netz 1.
Dürfen dann die Clients überhaupt ein Standardgateway haben?
Dazu Routingtabelle meines Clients ohne statische Route(Tab1)
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Anzahl
0.0.0.0 0.0.0.0 192.168.179.3 192.168.179.40 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.179.0 255.255.255.0 192.168.179.40 192.168.179.40 1
192.168.179.40 255.255.255.255 127.0.0.1 127.0.0.1 1
192.168.179.255 255.255.255.255 192.168.179.40 192.168.179.40 1
224.0.0.0 224.0.0.0 192.168.179.40 192.168.179.40 1
255.255.255.255 255.255.255.255 192.168.179.40 192.168.179.40 1
Standardgateway: 192.168.179.3
St?ndige Routen:
Keine
Und Routingtabelle meines Clients mit statischer Route(Tab2)
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Anzahl
0.0.0.0 0.0.0.0 192.168.179.3 192.168.179.40 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.178.1 255.255.255.255 192.168.179.3 192.168.179.40 1
192.168.179.0 255.255.255.0 192.168.179.40 192.168.179.40 1
192.168.179.40 255.255.255.255 127.0.0.1 127.0.0.1 1
192.168.179.255 255.255.255.255 192.168.179.40 192.168.179.40 1
224.0.0.0 224.0.0.0 192.168.179.40 192.168.179.40 1
255.255.255.255 255.255.255.255 192.168.179.40 192.168.179.40 1
Standardgateway: 192.168.179.3
St?ndige Routen:
Netzwerkadresse Netzmaske Gatewayadresse Anzahl
192.168.178.1 255.255.255.255 192.168.179.3 1
Wie man in Tab2 sieht, hat der Client immer noch sein Standardgateway.
Wenn ein Client jetzt ein Datenpaket verschickt, dessen Netzmuster ein anderes
als das des Clients ist, geht das Paket ja übers Standardgateway hinaus.
Oder, wenn man das Ganze mal aufdröselt:
Ein Client im Netz 2 schickt eine Anfrage:"Gibt?s hier jemand, mit der
IP 192.168.0.2?"
Keiner antwortet, die Anfrage geht übers Gateway ins andere Netz an alle Rechner, der
Rechner mit der entspr. IP antwortet, das Paket kann verschickt werden.
Kann der Client in Netz 2 dann nicht doch die Rechner im anderen Netz erreichen,
nämlich über sein Standardgateway?
Zweites Verständnisproblem:
Ich habe einen DSL-Router mit der IP 192.168.178.1,
einen Server mit Nic_1 - IP 192.168.178.2, Nic_2 - IP 192.168.179.3,
einen Client mit IP 192.168.179.40.
Routing brauche ich norm. nicht, da ich über den Proxy des Servers ins Internet
gehe.
Wenn ich jetzt auf dem Server Routing aktiviere, und lt. deiner Empfehlung
auch noch NAT(oder Masquerading bei Linux), kann mein Client den DSL-Router
erreichen, er findet den DSL-Router also, auch OHNE dass eine statische
Route eingetragen wurde, weder auf dem Client noch sonstwo.
Lt. deinem Tutorial ist diese stat. Route zum Finden des Routers im anderen
Netz aber erforderlich.
Drittes Verständnisproblem:
Zitat aus Tutorial:
"Der Router weiß nun seinerseits noch nicht, wohin er Pakete zu schicken hat,
die für dieses Fremdnetz ankommen. Ihm muss folglich auch eine eine statische
Route gegeben werden in der Art:
finde das Netz 192.168.123.0 mit Maske 255.255.255.0 über das Interface
192.168.0.254"
Zitat Ende
Ein Gateway verbindet unterschiedliche Umgebungen miteinander.
Das geschieht ja, in dem es die Information der Protokollschicht vom ein-
kommenden Paket entfernt und durch die für die andere Umgebung
erforderliche Paketinformation ersetzt.
Der IP-Header enthält ja unter anderem Informationen über
Hardware- und IP-Adressen der Systeme, die miteinander kommunizieren,
welche von den Hosts in Tabellen abgelegt werden. Ansonsten wäre ja kein
Routing möglich. Große Datenpakete werden ja schließlich in viele, kleine
Pakete zerlegt, und diese Pakete können über versch. Knoten zum Ziel-
rechner gelangen, wo sie wieder zusammengesetzt werden. Heißt, jeder
Knoten weiß aufgrund des IP-Headers, wo das Paket hingehört.
Und damit müßte der Router doch entsprechende Information haben, um zu
"wissen", dass ein Paket aus Netz 2 von der Workstation a kommt, die ja die Netze verbindet,
und Pakete entsprechend an die Workstation a zurückschicken, die wiederum
an den entsprechenden Rechner in Netz 2.
Denn schließlich gelangen Anfragen aus Netz 1 ja auch zum richtigen Host zurück,
warum nicht auch zu workstation a, beheimatet in beiden Netzen, die ja aus Sicht
des Routers stellvertretend für Netz 2 die Anfragen stellt.
Oder bin ich da vielleicht irgendwo auf dem Holzweg?
Gruß
Günni
Hi,
mit der Routerei habe ich einige Verständnisprobleme, wobei ich jetzt nicht die
Funktionalität deines Tutorials in Abrede stellen will, sondern dass mir einige
Sachen einfach unlogisch erscheinen.
Erstes Verständnisproblem:
Durch die Anweisung
"route add ?p 192.168.0.1 mask 255.255.255.255 192.168.123.254"
sollen die Clients ja den Router über das GW 192.168.123.254 erreichen, die Maske
255.255.255.255 soll ja bewirken, dass die Clients ausschließlich den Router erreichen
und sonst keinen anderen im Netz 1.
Dürfen dann die Clients überhaupt ein Standardgateway haben?
Dazu Routingtabelle meines Clients ohne statische Route(Tab1)
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Anzahl
0.0.0.0 0.0.0.0 192.168.179.3 192.168.179.40 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.179.0 255.255.255.0 192.168.179.40 192.168.179.40 1
192.168.179.40 255.255.255.255 127.0.0.1 127.0.0.1 1
192.168.179.255 255.255.255.255 192.168.179.40 192.168.179.40 1
224.0.0.0 224.0.0.0 192.168.179.40 192.168.179.40 1
255.255.255.255 255.255.255.255 192.168.179.40 192.168.179.40 1
Standardgateway: 192.168.179.3
St?ndige Routen:
Keine
Und Routingtabelle meines Clients mit statischer Route(Tab2)
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Anzahl
0.0.0.0 0.0.0.0 192.168.179.3 192.168.179.40 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.178.1 255.255.255.255 192.168.179.3 192.168.179.40 1
192.168.179.0 255.255.255.0 192.168.179.40 192.168.179.40 1
192.168.179.40 255.255.255.255 127.0.0.1 127.0.0.1 1
192.168.179.255 255.255.255.255 192.168.179.40 192.168.179.40 1
224.0.0.0 224.0.0.0 192.168.179.40 192.168.179.40 1
255.255.255.255 255.255.255.255 192.168.179.40 192.168.179.40 1
Standardgateway: 192.168.179.3
St?ndige Routen:
Netzwerkadresse Netzmaske Gatewayadresse Anzahl
192.168.178.1 255.255.255.255 192.168.179.3 1
Wie man in Tab2 sieht, hat der Client immer noch sein Standardgateway.
Wenn ein Client jetzt ein Datenpaket verschickt, dessen Netzmuster ein anderes
als das des Clients ist, geht das Paket ja übers Standardgateway hinaus.
Oder, wenn man das Ganze mal aufdröselt:
Ein Client im Netz 2 schickt eine Anfrage:"Gibt?s hier jemand, mit der
IP 192.168.0.2?"
Keiner antwortet, die Anfrage geht übers Gateway ins andere Netz an alle Rechner, der
Rechner mit der entspr. IP antwortet, das Paket kann verschickt werden.
Kann der Client in Netz 2 dann nicht doch die Rechner im anderen Netz erreichen,
nämlich über sein Standardgateway?
Zweites Verständnisproblem:
Ich habe einen DSL-Router mit der IP 192.168.178.1,
einen Server mit Nic_1 - IP 192.168.178.2, Nic_2 - IP 192.168.179.3,
einen Client mit IP 192.168.179.40.
Routing brauche ich norm. nicht, da ich über den Proxy des Servers ins Internet
gehe.
Wenn ich jetzt auf dem Server Routing aktiviere, und lt. deiner Empfehlung
auch noch NAT(oder Masquerading bei Linux), kann mein Client den DSL-Router
erreichen, er findet den DSL-Router also, auch OHNE dass eine statische
Route eingetragen wurde, weder auf dem Client noch sonstwo.
Lt. deinem Tutorial ist diese stat. Route zum Finden des Routers im anderen
Netz aber erforderlich.
Drittes Verständnisproblem:
Zitat aus Tutorial:
"Der Router weiß nun seinerseits noch nicht, wohin er Pakete zu schicken hat,
die für dieses Fremdnetz ankommen. Ihm muss folglich auch eine eine statische
Route gegeben werden in der Art:
finde das Netz 192.168.123.0 mit Maske 255.255.255.0 über das Interface
192.168.0.254"
Zitat Ende
Ein Gateway verbindet unterschiedliche Umgebungen miteinander.
Das geschieht ja, in dem es die Information der Protokollschicht vom ein-
kommenden Paket entfernt und durch die für die andere Umgebung
erforderliche Paketinformation ersetzt.
Der IP-Header enthält ja unter anderem Informationen über
Hardware- und IP-Adressen der Systeme, die miteinander kommunizieren,
welche von den Hosts in Tabellen abgelegt werden. Ansonsten wäre ja kein
Routing möglich. Große Datenpakete werden ja schließlich in viele, kleine
Pakete zerlegt, und diese Pakete können über versch. Knoten zum Ziel-
rechner gelangen, wo sie wieder zusammengesetzt werden. Heißt, jeder
Knoten weiß aufgrund des IP-Headers, wo das Paket hingehört.
Und damit müßte der Router doch entsprechende Information haben, um zu
"wissen", dass ein Paket aus Netz 2 von der Workstation a kommt, die ja die Netze verbindet,
und Pakete entsprechend an die Workstation a zurückschicken, die wiederum
an den entsprechenden Rechner in Netz 2.
Denn schließlich gelangen Anfragen aus Netz 1 ja auch zum richtigen Host zurück,
warum nicht auch zu workstation a, beheimatet in beiden Netzen, die ja aus Sicht
des Routers stellvertretend für Netz 2 die Anfragen stellt.
Oder bin ich da vielleicht irgendwo auf dem Holzweg?
Gruß
Günni
Hallo Günni,
Durch die Anweisung
"route add ?p 192.168.0.1 mask 255.255.255.255 192.168.123.254"
sollen die Clients ja den Router über das GW 192.168.123.254 erreichen, die Maske
255.255.255.255 soll ja bewirken, dass die Clients ausschließlich den Router erreichen
und sonst keinen anderen im Netz 1.
<<
Dies Info ist nicht richtig. Die soll nur dafür sorgen, wenn kein Standartgateway vorhanden
ist, der Router immer noch durch die PCs von Netz2 erreichbar ist.
<<
Dürfen dann die Clients überhaupt ein Standardgateway haben?
Die Clients müssen ein Stadartgateway haben, damit ein Zugriff ins Internet möglich ist.
Deswegen ist die o.a. Route nicht notwendig.
<<
Kann der Client in Netz 2 dann nicht doch die Rechner im anderen Netz erreichen,
nämlich über sein Standardgateway?
Das stimmt. Nur hat Atti58 einen "Routing-Fehler" eingebaut, damit das nicht funktioniert.
Ein PC von Netz2 sendet ein Paket an einen PC von Netz1.
Weg: Router-PC, da der beide Netze kennt und Standartgateway von Netz2 ist
Das Paket kommt auch bei dem PC von Netz1 an.
Da dieser das Netz2 nicht kennt, sendet er das Paket zu dem Router, da dieser
Standartgateway von Netz1 ist.
Dr Router sendet das Paket zu dem PC im Netz 2 zurück., er kennt das Netz 2.
Der PC von Netz2 wiederum erkennt, das er das Paket zu dem PC im Netz1 über den Router PC gesendet hat und wird deswegen das Paket nicht annehmen.
Sehr komliziert und extrem Fehlerbehaftet und kein wirklicher Schutz.
Besser man richtet eine DNZ ein, wenn man 2 Netze von einander trennen möchte.
Hoffe etwas für das Verständnis getan zu haben.
Gruß
Hämmi
"route add ?p 192.168.0.1 mask 255.255.255.255 192.168.123.254"
sollen die Clients ja den Router über das GW 192.168.123.254 erreichen, die Maske
255.255.255.255 soll ja bewirken, dass die Clients ausschließlich den Router erreichen
und sonst keinen anderen im Netz 1.
<<
Dies Info ist nicht richtig. Die soll nur dafür sorgen, wenn kein Standartgateway vorhanden
ist, der Router immer noch durch die PCs von Netz2 erreichbar ist.
<<
Dürfen dann die Clients überhaupt ein Standardgateway haben?
Deswegen ist die o.a. Route nicht notwendig.
<<
Kann der Client in Netz 2 dann nicht doch die Rechner im anderen Netz erreichen,
nämlich über sein Standardgateway?
Ein PC von Netz2 sendet ein Paket an einen PC von Netz1.
Weg: Router-PC, da der beide Netze kennt und Standartgateway von Netz2 ist
Das Paket kommt auch bei dem PC von Netz1 an.
Da dieser das Netz2 nicht kennt, sendet er das Paket zu dem Router, da dieser
Standartgateway von Netz1 ist.
Dr Router sendet das Paket zu dem PC im Netz 2 zurück., er kennt das Netz 2.
Der PC von Netz2 wiederum erkennt, das er das Paket zu dem PC im Netz1 über den Router PC gesendet hat und wird deswegen das Paket nicht annehmen.
Sehr komliziert und extrem Fehlerbehaftet und kein wirklicher Schutz.
Besser man richtet eine DNZ ein, wenn man 2 Netze von einander trennen möchte.
Hoffe etwas für das Verständnis getan zu haben.
Gruß
Hämmi
@günni
Wo soll ich anfangen? Schwierig ... Zum "Ersten Verständnisproblem":
Ich habe mir ja für dieses Tutorial eine Testumgebung aufgebaut (nicht ganz so wie abgebildet, ich geb's zu - der Router ist in Wirklichkeit eine Astaro-Firewall) und alles getestet ... Du hast Recht, unlogisch ist das schon, ich habe deshalb mal das Gateway rausgenommen und das Internet ging nicht mehr
... GW wieder rein und Route raus - Internet ging nicht mehr ... Route wieder rein und das Routing auf "Workstation a" deaktiviert - Internet ging nicht mehr ... und nun kann ich das Routing nicht mehr aktivieren ... Es macht doch Spass, sich von M$ mit Arbeit versorgen zu lassen ...
Ich werde jetzt erst einmal versuchen, meine Testumgebung wieder zum Laufen zu bringen und mich dann wieder melden,
Gruß
Atti.
Wo soll ich anfangen? Schwierig ... Zum "Ersten Verständnisproblem":
Ich habe mir ja für dieses Tutorial eine Testumgebung aufgebaut (nicht ganz so wie abgebildet, ich geb's zu - der Router ist in Wirklichkeit eine Astaro-Firewall) und alles getestet ... Du hast Recht, unlogisch ist das schon, ich habe deshalb mal das Gateway rausgenommen und das Internet ging nicht mehr
... GW wieder rein und Route raus - Internet ging nicht mehr ... Route wieder rein und das Routing auf "Workstation a" deaktiviert - Internet ging nicht mehr ... und nun kann ich das Routing nicht mehr aktivieren ... Es macht doch Spass, sich von M$ mit Arbeit versorgen zu lassen ...Ich werde jetzt erst einmal versuchen, meine Testumgebung wieder zum Laufen zu bringen und mich dann wieder melden,
Gruß
Atti.
@Atti
Also, das ganze muß ohne den Routen-Eintrag
"route add ?p 192.168.0.1 mask 255.255.255.255 192.168.123.254"
funktionieren.
Bei MS-Maschinen ist Vorsicht geboten, da die einen ARP-Cache verwenden
und der dir immer große "Freunde" bereiten kann.
Wenn Du etwas umgestellt hat, am besten alle betroffen Windows-PCs neu starten.
Kannst Du bei der Astaro keine DMZ einichten? Wenn ja,
dann verlagere dein Netz2 in die DMZ - aber nur wenn diese sonst nicht genutzt wird.
Oder binde wie schon mal erwähnt, das 2.Netz auf den Router. Das wird und muß
einwandfrei funktionieren.
Gruß
Hämmi
Also, das ganze muß ohne den Routen-Eintrag
"route add ?p 192.168.0.1 mask 255.255.255.255 192.168.123.254"
funktionieren.
Bei MS-Maschinen ist Vorsicht geboten, da die einen ARP-Cache verwenden
und der dir immer große "Freunde" bereiten kann.
Wenn Du etwas umgestellt hat, am besten alle betroffen Windows-PCs neu starten.
Kannst Du bei der Astaro keine DMZ einichten? Wenn ja,
dann verlagere dein Netz2 in die DMZ - aber nur wenn diese sonst nicht genutzt wird.
Oder binde wie schon mal erwähnt, das 2.Netz auf den Router. Das wird und muß
einwandfrei funktionieren.
Gruß
Hämmi
@hämmi
Das mit dem DMZ ist gut und schön, ich habe aber diese Variante mit zwei Netzwerkkarten gewählt, weil sie hier sehr oft angefragt und immer wieder falsch gemacht wird. Ich bin gerade dabei, Eure Vorschläge nachzuvollziehen und zu dokumentieren, das wird aber wohl noch ein Weilchen dauern,
Gruß
Atti.
Das mit dem DMZ ist gut und schön, ich habe aber diese Variante mit zwei Netzwerkkarten gewählt, weil sie hier sehr oft angefragt und immer wieder falsch gemacht wird. Ich bin gerade dabei, Eure Vorschläge nachzuvollziehen und zu dokumentieren, das wird aber wohl noch ein Weilchen dauern,
Gruß
Atti.
@ Günni & Hämmi
Ich habe das Tutorial um einen Nachtrag am Anfang erweitert, Danke für Eure Hinweise,
Gruß
Atti.
Ich habe das Tutorial um einen Nachtrag am Anfang erweitert, Danke für Eure Hinweise,
Gruß
Atti.
Bei MS-Maschinen ist Vorsicht geboten, da
die einen ARP-Cache verwenden
und der dir immer große
"Freunde" bereiten kann.
die einen ARP-Cache verwenden
und der dir immer große
"Freunde" bereiten kann.
@hämmi
Hi,
"nur" MS-Maschinen benutzen einen ARP-Cache?
Dazu folg. Artikel:
ARP - Address Resolution Protocol
Das Address Resolution Protocol (ARP) arbeitet auf der Schicht 2, der Sicherungsschicht, des OSI-Schichtenmodells und setzt IP-Adressen in Hardware- und MAC-Adressen um. Alle Netzwerktypen und -topologien benutzen Hardware-Adressen um die Datenpakete zu adressieren. Damit nun ein IP-Paket an sein Ziel findet, muss die Hardware-Adresse des Ziels bekannt sein.
Jede Netzwerkkarte besitzt eine einzigartige und eindeutige Hardware-Adresse, die fest auf der Karte eingebrannt ist und meist nicht änderbar ist.
Bevor nun ein Datenpaket verschickt werden kann, muss durch ARP eine Adressauflösung erfolgen. Dazu benötigt ARP Zugriff auf IP-Adresse und Hardware-Adresse. Um an die Hardware-Adresse einer anderen Station zu kommen verschickt ARP z. B. einen Ethernet-Frame als Broadcast-Meldung mit der MAC-Adresse "FF FF FF FF FF FF". Diese Meldung wird von jedem Netzwerkinterface entgegengenommen und ausgewertet. Der Ethernet-Frame enthält die IP-Adresse der gesuchten Station. Fühlt sich eine Station mit dieser IP-Adresse angesprochen, schickt sie eine ARP-Antwort an den Sender zurück. Die gemeldete MAC-Adresse wird dann im lokalen ARP-Cache des Senders gespeichert. Dieser Cache dient zur schnelleren ARP-Adressauflösung.
Häufig findet man in anderen Dokumentationen, das ARP ein Schicht 3 Protokoll ist. Allerdings sind ARP und auch RARP für die Adressauflösung zuständig, was eigentlich kein Schicht 3 Protokoll ist. Da ARP und IP aber so eng verzahnt sind, wird ARP und RARP auch in Schicht 3 gelegt, wäre aber eigentlich irgendwo zwischen Schicht 3 und Schicht 2 richtig angesiedelt.
Ablauf einer ARP-Adressauflösung
Eine ARP-Auflösung unterscheidet zwischen lokalen IP-Adressen und IP-Adressen in einem anderen Subnetz. Als erstes wird anhand der Subnetzmaske festgestellt, ob sich die IP-Adresse im gleichen Subnetz befindet. Ist das der Fall, wird im ARP-Cache geprüft, ob bereits eine MAC-Adresse für die IP-Adresse hinterlegt ist. Wenn ja, dann wird die MAC-Adresse zur Adressierung verwendet. Wenn nicht, setzt ARP eine Anfrage mit der IP-Adresse nach der Hardware-Adresse in das Netzwerk. Diese Anfrage wird von allen Stationen im selben Subnetz entgegengenommen und ausgewertet. Die Stationen vergleichen die gesendete IP-Adresse mit ihrer eigenen. Wenn sie nicht übereinstimmt, wird die Anfrage verworfen. Wenn die IP-Adresse übereinstimmt schickt die betreffende Station eine ARP-Antwort direkt an den Sender der ARP-Anfrage. Dieser Speichert die Hardware-Adresse in seinem Cache. Da bei beiden Stationen die Hardware-Adresse bekannt sind, können sie nun miteinander Daten austauschen.
Befindet sich eine IP-Adresse nicht im gleichen Subnetz, geht ARP über das Standard-Gateway. Findet ARP die Hardware-Adresse des Standard-Gateways im Cache nicht, wird eine lokale ARP-Adressauflösung ausgelöst. Ist die Hardware-Adresse des Standard-Gateways bekannt, schickt der Sender bereits sein erstes Datenpaket an die Ziel-Station. Der Router (Standard-Gateway) nimmt das Datenpaket in Empfang und untersucht den IP-Header. Der Router überprüft, ob sich die Ziel-IP-Adresse in einem angeschlossenen Subnetz befindet. Wenn ja, ermittelt er anhand der lokalen ARP-Adressauflösung die MAC-Adresse der Ziel-Station. Anschließend leitet er das Datenpaket weiter. Ist das Ziel in einem entfernten Subnetz, überprüft der Router seine Routing-Tabelle, ob ein Weg zum Ziel bekannt ist. Ist das nicht der Fall steht dem Router auch ein Standard-Gateway zu Verfügung. Der Router führt für sein Standard-Gateway eine ARP-Adressauflösung durch und leitet das Datenpaket an dieses weiter.
Die vorangegangenen Schritte weiderholen sich dann so oft, bis das Datenpaket sein Ziel erreicht oder das IP-Header-Feld TTL auf den Wert 0 springt. Dann wird das Datenpaket vom Netz genommen.
Erreicht dann irgendwann das Datenpaket doch sein Ziel, schreibt die betreffende Station seine Rückantwort in ein ICMP-Paket an den Sender. In dieser Antwort wird falls möglich ein Gateway vermerkt, über das die beiden Stationen miteinander kommunizieren. So werden weitere ARP-Adressauflösungen und dadurch Broadcasts vermieden.Ist ein Betriebssystem in OSI-Schicht 2/3 angesiedelt?
Eher umgekehrt, jedes OS, das TCP/IP implementiert, verwendet den ARP-Cache.
Gruß
Günni
@günni
Hallo Günni,
ich denke, wir beenden am besten diese Diskussion, da dies nicht mehr so direkt zu dem eigentlichen Thema passt.
Ich habe mich vor vielen Jahren mit dem OSI-Refernzmodell
beschäftigt und wollte es eigentlich nicht mehr tun, da ich
es langweilig finde und ich Fehler im Netz auch ohne Kenntnisse der Schichten finde.
Nur kurz noch ein Kommentar zu deinem Hinweis.
zeigt, dass besonders die MS-Maschinen ein "Elefantengedächtnis" haben.
wenn man einen Netzwerkkartentreiber als Teil des Betriebssystemes sieht.
Einzig die Schicht 1 liegt auf der Hardware (Netzwerkkarte).
Gruß
Hämmi
Hallo Günni,
ich denke, wir beenden am besten diese Diskussion, da dies nicht mehr so direkt zu dem eigentlichen Thema passt.
Ich habe mich vor vielen Jahren mit dem OSI-Refernzmodell
beschäftigt und wollte es eigentlich nicht mehr tun, da ich
es langweilig finde und ich Fehler im Netz auch ohne Kenntnisse der Schichten finde.
Nur kurz noch ein Kommentar zu deinem Hinweis.
"nur" MS-Maschinen benutzen einen
ARP-Cache?
Nein, das ist natürlich nicht richtig, aber meine ErfahrungARP-Cache?
zeigt, dass besonders die MS-Maschinen ein "Elefantengedächtnis" haben.
Ist ein Betriebssystem in OSI-Schicht 2/3
angesiedelt?
Natürlich liegt die OSI-Schicht 2/3 im Betriebssystem,angesiedelt?
wenn man einen Netzwerkkartentreiber als Teil des Betriebssystemes sieht.
Einzig die Schicht 1 liegt auf der Hardware (Netzwerkkarte).
Eher umgekehrt, jedes OS, das TCP/IP
implementiert, verwendet den ARP-Cache.
Stimmt!implementiert, verwendet den ARP-Cache.
Gruß
Hämmi
Gut gemacht.
Für ein Firmennetz fehlt mir noch die Sicherheitszone, wie Firewall, Proxy etc. auf der Skizze.
Für ein Firmennetz fehlt mir noch die Sicherheitszone, wie Firewall, Proxy etc. auf der Skizze.
Hallo Atti,
auf den ersten Blick erschien mir Dein Beitrag sehr hilfreich, da er eine Aufgabenstellung addressiert, die ich zu erledigen habe.
Auf den zweiten Blick muß ich sagen, ich krieg's nicht hin
Meine Konfiguration ist ein DSL Router mit IP 192.168.178.1, das lokale Netz ist ein WLAN mit drei Arbeitsstationen 192.168.178.22, 192.168.178.23 und 192.168.178.24.
An Arbeitsstation 192.168.178.22 ist ein zweiter NIC angeschlossen mit IP 192.168.0.1 daran per Kabel ein WD ShareSpace NAS mit IP 192.168.0.100
Die Idee ist, den WD ShareSpace allen Netzwerkstationen zugänglich zu machen, und dem WDShareSpace Internetzugang (Time Server, Softwareupdate, etc. ) zu ermöglichen.
Auf dem Router habe ich als statische Route Netzwerk 192.168.0.0 Subnetz 255.255.255.0 Gateway 192.168.178.22 eingetragen
Auf der Arbeitsstation 192.168.178.22 habe ich, analog zu Deinen Angaben
route add -p 192.168.178.1 mask 255.255.255.255 192.168.0.1
Danach ist kein Internetzugang mehr möglich
Was mache ich falsch ? Für hilfreiche Kommentare wäre ich dankbar.
Casual
P.S. Könnte auf Deiner Grafik ein Fehler sein ? Müßte Netzwerk 1 nicht 192.168.0.0 anstelle von 192.168.1.0 heißen ?
P.P.S. Nach Einrichten von ICS (Interenet Connection Sharing) auf der Arbeitsstation 192.168.178.22 kann jetzt der WDShareSpace auf Timeserver und Softwareupdate zugreifen. Jetzt fehlt nur noch der Weg von den anderen Arbeitsstationen zum WDShareSpace.
Windows-IP-Konfiguration
Ethernetadapter Bluetooth-Netzwerkverbindung:
Medienstatus. . . . . . . . . . . : Es besteht keine Verbindung
Ethernetadapter LAN-Verbindung 4:
Verbindungsspezifisches DNS-Suffix:
IP-Adresse. . . . . . . . . . . . : 192.168.0.1
Subnetzmaske. . . . . . . . . . . : 255.255.255.0
IP-Adresse. . . . . . . . . . . . : fe80::2e0:4cff:fe68:11e%5
Standardgateway . . . . . . . . . :
Ethernetadapter Drahtlose Netzwerkverbindung:
Verbindungsspezifisches DNS-Suffix:
IP-Adresse. . . . . . . . . . . . : 192.168.178.22
Subnetzmaske. . . . . . . . . . . : 255.255.255.0
IP-Adresse. . . . . . . . . . . . : fe80::213:2ff:fe18:12ac%6
Standardgateway . . . . . . . . . : 192.168.178.1
Tunneladapter Teredo Tunneling Pseudo-Interface:
Verbindungsspezifisches DNS-Suffix:
IP-Adresse. . . . . . . . . . . . : 2001:0:d5c7:a2d6:0:fb92:261e:d0ae
IP-Adresse. . . . . . . . . . . . : fe80::ffff:ffff:fffd%7
Standardgateway . . . . . . . . . : ::
Tunneladapter Automatic Tunneling Pseudo-Interface:
Verbindungsspezifisches DNS-Suffix:
IP-Adresse. . . . . . . . . . . . : fe80::5efe:192.168.178.22%2
Standardgateway . . . . . . . . . :
Tunneladapter Automatic Tunneling Pseudo-Interface:
Verbindungsspezifisches DNS-Suffix:
IP-Adresse. . . . . . . . . . . . : fe80::5efe:192.168.0.1%2
Standardgateway . . . . . . . . . :
0x1 ........................... MS TCP Loopback interface
0x2 ...00 11 e2 fe 2f 85 ...... Bluetooth-Gerõt (PAN) #3
0x3 ...00 e0 4c 68 01 1e ...... Realtek RTL8168C(P)/8111C(P) PCI-E Gigabit Ethernet NIC - Paketplaner-Miniport
0x4 ...00 13 02 18 12 ac ...... Intel(R) PRO/Wireless 3945ABG Network Connection - Paketplaner-Miniport
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Anzahl
0.0.0.0 0.0.0.0 192.168.178.1 192.168.178.22 25
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.0.0 255.255.255.0 192.168.0.1 192.168.0.1 10
192.168.0.1 255.255.255.255 127.0.0.1 127.0.0.1 10
192.168.0.255 255.255.255.255 192.168.0.1 192.168.0.1 10
192.168.178.0 255.255.255.0 192.168.178.22 192.168.178.22 25
192.168.178.22 255.255.255.255 127.0.0.1 127.0.0.1 25
192.168.178.255 255.255.255.255 192.168.178.22 192.168.178.22 25
224.0.0.0 240.0.0.0 192.168.0.1 192.168.0.1 10
224.0.0.0 240.0.0.0 192.168.178.22 192.168.178.22 25
255.255.255.255 255.255.255.255 192.168.0.1 192.168.0.1 1
255.255.255.255 255.255.255.255 192.168.178.22 192.168.178.22 1
255.255.255.255 255.255.255.255 192.168.178.22 2 1
Standardgateway: 192.168.178.1
Ständige Routen:
Keine
auf den ersten Blick erschien mir Dein Beitrag sehr hilfreich, da er eine Aufgabenstellung addressiert, die ich zu erledigen habe.
Auf den zweiten Blick muß ich sagen, ich krieg's nicht hin
Meine Konfiguration ist ein DSL Router mit IP 192.168.178.1, das lokale Netz ist ein WLAN mit drei Arbeitsstationen 192.168.178.22, 192.168.178.23 und 192.168.178.24.
An Arbeitsstation 192.168.178.22 ist ein zweiter NIC angeschlossen mit IP 192.168.0.1 daran per Kabel ein WD ShareSpace NAS mit IP 192.168.0.100
Die Idee ist, den WD ShareSpace allen Netzwerkstationen zugänglich zu machen, und dem WDShareSpace Internetzugang (Time Server, Softwareupdate, etc. ) zu ermöglichen.
Auf dem Router habe ich als statische Route Netzwerk 192.168.0.0 Subnetz 255.255.255.0 Gateway 192.168.178.22 eingetragen
Auf der Arbeitsstation 192.168.178.22 habe ich, analog zu Deinen Angaben
route add -p 192.168.178.1 mask 255.255.255.255 192.168.0.1
Danach ist kein Internetzugang mehr möglich
Was mache ich falsch ? Für hilfreiche Kommentare wäre ich dankbar.
Casual
P.S. Könnte auf Deiner Grafik ein Fehler sein ? Müßte Netzwerk 1 nicht 192.168.0.0 anstelle von 192.168.1.0 heißen ?
P.P.S. Nach Einrichten von ICS (Interenet Connection Sharing) auf der Arbeitsstation 192.168.178.22 kann jetzt der WDShareSpace auf Timeserver und Softwareupdate zugreifen. Jetzt fehlt nur noch der Weg von den anderen Arbeitsstationen zum WDShareSpace.
ipconfig
Windows-IP-Konfiguration
Ethernetadapter Bluetooth-Netzwerkverbindung:
Medienstatus. . . . . . . . . . . : Es besteht keine Verbindung
Ethernetadapter LAN-Verbindung 4:
Verbindungsspezifisches DNS-Suffix:
IP-Adresse. . . . . . . . . . . . : 192.168.0.1
Subnetzmaske. . . . . . . . . . . : 255.255.255.0
IP-Adresse. . . . . . . . . . . . : fe80::2e0:4cff:fe68:11e%5
Standardgateway . . . . . . . . . :
Ethernetadapter Drahtlose Netzwerkverbindung:
Verbindungsspezifisches DNS-Suffix:
IP-Adresse. . . . . . . . . . . . : 192.168.178.22
Subnetzmaske. . . . . . . . . . . : 255.255.255.0
IP-Adresse. . . . . . . . . . . . : fe80::213:2ff:fe18:12ac%6
Standardgateway . . . . . . . . . : 192.168.178.1
Tunneladapter Teredo Tunneling Pseudo-Interface:
Verbindungsspezifisches DNS-Suffix:
IP-Adresse. . . . . . . . . . . . : 2001:0:d5c7:a2d6:0:fb92:261e:d0ae
IP-Adresse. . . . . . . . . . . . : fe80::ffff:ffff:fffd%7
Standardgateway . . . . . . . . . : ::
Tunneladapter Automatic Tunneling Pseudo-Interface:
Verbindungsspezifisches DNS-Suffix:
IP-Adresse. . . . . . . . . . . . : fe80::5efe:192.168.178.22%2
Standardgateway . . . . . . . . . :
Tunneladapter Automatic Tunneling Pseudo-Interface:
Verbindungsspezifisches DNS-Suffix:
IP-Adresse. . . . . . . . . . . . : fe80::5efe:192.168.0.1%2
Standardgateway . . . . . . . . . :
route print
Schnittstellenliste0x1 ........................... MS TCP Loopback interface
0x2 ...00 11 e2 fe 2f 85 ...... Bluetooth-Gerõt (PAN) #3
0x3 ...00 e0 4c 68 01 1e ...... Realtek RTL8168C(P)/8111C(P) PCI-E Gigabit Ethernet NIC - Paketplaner-Miniport
0x4 ...00 13 02 18 12 ac ...... Intel(R) PRO/Wireless 3945ABG Network Connection - Paketplaner-Miniport
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Anzahl
0.0.0.0 0.0.0.0 192.168.178.1 192.168.178.22 25
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.0.0 255.255.255.0 192.168.0.1 192.168.0.1 10
192.168.0.1 255.255.255.255 127.0.0.1 127.0.0.1 10
192.168.0.255 255.255.255.255 192.168.0.1 192.168.0.1 10
192.168.178.0 255.255.255.0 192.168.178.22 192.168.178.22 25
192.168.178.22 255.255.255.255 127.0.0.1 127.0.0.1 25
192.168.178.255 255.255.255.255 192.168.178.22 192.168.178.22 25
224.0.0.0 240.0.0.0 192.168.0.1 192.168.0.1 10
224.0.0.0 240.0.0.0 192.168.178.22 192.168.178.22 25
255.255.255.255 255.255.255.255 192.168.0.1 192.168.0.1 1
255.255.255.255 255.255.255.255 192.168.178.22 192.168.178.22 1
255.255.255.255 255.255.255.255 192.168.178.22 2 1
Standardgateway: 192.168.178.1
Ständige Routen:
Keine
Hallo Atti58, Hi@all
erst einmal vielen Dank für eine so einfach verständliche HowTwo. Ich habe dazu eine Frage:
Ich möchte gerne in der Firma eine Bestimmte Gruppe gerne unseren Internet Gateway nutzen lassen, aber so, dass *diese* Gruppe weder auf den Server, noch auf das bestehende Netzwerk zugreifen kann -> Aus Datenschutz Rechtlichen Gründen. Jetzt die eigentliche frage -> Mein kleines Technisches Verständiss sagt mir, Diese Anleitung würde mir dazu weiterhelfen. Oder irre ich mich da ?
Gruß
Frank
erst einmal vielen Dank für eine so einfach verständliche HowTwo. Ich habe dazu eine Frage:
Ich möchte gerne in der Firma eine Bestimmte Gruppe gerne unseren Internet Gateway nutzen lassen, aber so, dass *diese* Gruppe weder auf den Server, noch auf das bestehende Netzwerk zugreifen kann -> Aus Datenschutz Rechtlichen Gründen. Jetzt die eigentliche frage -> Mein kleines Technisches Verständiss sagt mir, Diese Anleitung würde mir dazu weiterhelfen. Oder irre ich mich da ?
Gruß
Frank
Ich habe das Problem inzwischen elegater gelöst: Mit Netzwerkbrücke. Das ist zwar in Linux etwas unelegant einzurichten, funktioniert aber genau wie in Windows.
In Windows alle NICs die an der Brücke teilhaben sollen markieren, context menü (rechts klick) Netzwerkverbindungen überbrücken, das war's.
In Linux (openSuSE 11.2RC1) mit yast2 lan alle Netzwerkverbindungen zurücksetzen, die an der Brücke partizipieren sollen. Netzwerkgerät hinzufügen Brücke.
Brücke konfigurieren (feste IP oder DHCP, teilnehmende NICs markieren), anschließend die markierten NICs neu konfigurieren IP 0.0.0.0/netmask255.255.255.255 das war's
In Windows alle NICs die an der Brücke teilhaben sollen markieren, context menü (rechts klick) Netzwerkverbindungen überbrücken, das war's.
In Linux (openSuSE 11.2RC1) mit yast2 lan alle Netzwerkverbindungen zurücksetzen, die an der Brücke partizipieren sollen. Netzwerkgerät hinzufügen Brücke.
Brücke konfigurieren (feste IP oder DHCP, teilnehmende NICs markieren), anschließend die markierten NICs neu konfigurieren IP 0.0.0.0/netmask255.255.255.255 das war's
