nicht angemeldet
Linux Sub-Netz, DHCP, DNS, Filesharing, Peer-to-Peer
Hellihello
In der Schul-AG haben wir nun vier Rechner mit Linux bestückt, die untereinander auch kommunizieren sollten.
Das Freigeben von Ordnern über FTP ist zwar zu Lernzwecken durchaus ganz schön mal, mir schwebt aber vor, dass man auf jeden Rechner nicht nur per FTP und HTTP auf einen spezifischen Ordner zugreifen kann, sondern vielleicht auch eine Art Peer-to-Peer Netzwerk, in dem all die Inhalte des Ordners z.Z. /usr/htmlag auf jedem Rechner sichtbar wären.
Nützlich wäre sicher auch, nicht auf jedem Rechner eine /etc/hosts zu konfigurieren, sondern in dem Fall dann einen zentralen Rechner als DNS-Server zu konfigurieren.
Das ganze findet ja in einem bereits bestehenden Netz statt, in dem die Rechner momentan noch unter 192.168.16.XXX per dhcp eine IP zugewiesen kriegen.
Ich dachte nun, man könnte dem DNS-Server ja eine feste IP verpassen, und dann einen zweiten IP-Namensraum aufmachen, 192.168.17.XXX, der dann von diesem Server verwaltet würde. Dazu müsste dann wohl noch ein dhcp-Server installiert sein, der dann auf den Namensraum 192.168.17.XXX eingestellt ist bzw. darin dann IPs vergibt.
Sind da irgendwo Denkfehler, ist das machbar, und wenn ja womit?
Bisher laufen auf allen Rechnern Debian-Derivate (GnewSense, Debian, ggf. Ubuntu).
Dank und Gruß,
-
Hallo
In der Schul-AG haben wir nun vier Rechner mit Linux bestückt, die untereinander auch kommunizieren sollten.
Das Freigeben von Ordnern über FTP ist zwar zu Lernzwecken durchaus ganz schön mal, mir schwebt aber vor, dass man auf jeden Rechner nicht nur per FTP und HTTP auf einen spezifischen Ordner zugreifen kann, sondern vielleicht auch eine Art Peer-to-Peer Netzwerk, in dem all die Inhalte des Ordners z.Z. /usr/htmlag auf jedem Rechner sichtbar wären.
zum Beispiel mit NFS oder SMB.
Du bist Dir über die Nachteile von Peer-to-Peer im Klaren?Nützlich wäre sicher auch, nicht auf jedem Rechner eine /etc/hosts zu konfigurieren, sondern in dem Fall dann einen zentralen Rechner als DNS-Server zu konfigurieren.
Ja, das ist sinnvoll. Ich hatte Dir doch mal das DNS-Howto verlinkt.
Das ganze findet ja in einem bereits bestehenden Netz statt, in dem die Rechner momentan noch unter 192.168.16.XXX per dhcp eine IP zugewiesen kriegen.
Ich dachte nun, man könnte dem DNS-Server ja eine feste IP verpassen,Rechner, die Serverdienste anbieten, sollten eine feste IP-Adresse haben.
Wenn Du Peer-to-Peer machst, bietet jeder Rechner Serverdienste an ...und dann einen zweiten IP-Namensraum aufmachen, 192.168.17.XXX, der dann von diesem Server verwaltet würde.
Huch, wozu das? Was willst Du damit erreichen. Du kannst selbstverständlich allen Rechnern eine statische IP-Adresse vergeben. Wie der Stand der Dinge bei dynamischer Aktualisierung Deines DNS in Abhängigkeit von der per DHCP vergebenen Adresse aussieht, wie es z.B. unter Windows 2003 funktioniert, weiß ich nicht.
Dazu müsste dann wohl noch ein dhcp-Server installiert sein, der dann auf den Namensraum 192.168.17.XXX eingestellt ist bzw. darin dann IPs vergibt.
s.o. Ich halte das nicht für eine gute Idee.
Es ist unter Linux einfach, einer Netzwerkkarte zwei unterschiedliche IP-Adressen zuzuweisen. In Deinem Fall verkompliziert das die Netzwerkkonfiguration nur unnötig - ohne dass es etwas zum Verständnis beitragen würde.Freundliche Grüße
Vinzenz
-
Hellihello Vinzenz,
Hallo
In der Schul-AG haben wir nun vier Rechner mit Linux bestückt, die untereinander auch kommunizieren sollten.
Das Freigeben von Ordnern über FTP ist zwar zu Lernzwecken durchaus ganz schön mal, mir schwebt aber vor, dass man auf jeden Rechner nicht nur per FTP und HTTP auf einen spezifischen Ordner zugreifen kann, sondern vielleicht auch eine Art Peer-to-Peer Netzwerk, in dem all die Inhalte des Ordners z.Z. /usr/htmlag auf jedem Rechner sichtbar wären.
zum Beispiel mit NFS oder SMB.
Du bist Dir über die Nachteile von Peer-to-Peer im Klaren?Nein, über die Nachteile bin ich mir nicht im Klaren. NFS würde ich mir dann mal genauer zu Gemüte führen. Schön wäre es ja, wenn man zB. nicht auf 6 verschiedenen Festplatten/Ordnern/Mountpoints nach einer Datei suchen müsste, sondern irgendwie die Platten gemeinsam im Blick haben könnte - so dachte ich und kam ahnungslos auf das Stichwort Peer-to-Peer, weil ich dachte, dass dann die Grenzen von Server und Client verschwinden.
Nützlich wäre sicher auch, nicht auf jedem Rechner eine /etc/hosts zu konfigurieren, sondern in dem Fall dann einen zentralen Rechner als DNS-Server zu konfigurieren.
Ja, das ist sinnvoll. Ich hatte Dir doch mal das DNS-Howto verlinkt.
Jau, das war, als ich versuchte, einen DNS-Eintrag zu platzieren. http://forum.de.selfhtml.org/archiv/2008/1/t165149/#m1076734
Das ganze findet ja in einem bereits bestehenden Netz statt, in dem die Rechner momentan noch unter 192.168.16.XXX per dhcp eine IP zugewiesen kriegen.
Ich dachte nun, man könnte dem DNS-Server ja eine feste IP verpassen,Rechner, die Serverdienste anbieten, sollten eine feste IP-Adresse haben.
Wenn Du Peer-to-Peer machst, bietet jeder Rechner Serverdienste an ...und dann einen zweiten IP-Namensraum aufmachen, 192.168.17.XXX, der dann von diesem Server verwaltet würde.
Huch, wozu das? Was willst Du damit erreichen. Du kannst selbstverständlich allen Rechnern eine statische IP-Adresse vergeben. Wie der Stand der Dinge bei dynamischer Aktualisierung Deines DNS in Abhängigkeit von der per DHCP vergebenen Adresse aussieht, wie es z.B. unter Windows 2003 funktioniert, weiß ich nicht.
Na, die Überlegung kam daher, dass der Windowsserver eben 192.168.16.XXX verwaltet und nur eine begrenzte Zahl von IPs für dhcp zur Verfügung hat. Zudem kann der von der AG nicht administriert werden. Das macht der Fachbereichsleiter und wird u.U. sogar irgendwann mal berlinweit zentralisiert. Somit dachte ich, macht man einen eigene Ip-Raum, den man selbst konfigurieren kann, und ein Rechner spielt den Schleuser oder das Gateway, hat selbst zB. die Ip 192.168.16.201 und spielt den DNS-Server für die Rechner im IP-Raum 192.168.17.XXX. Ist halt früheste Planungsphase. Die Rechner im Sub-Linux-Netz sollten dann vielleicht auch fest IPs bekommen, damit man sie über Namen (DNS) ansprechen kann.
Dazu müsste dann wohl noch ein dhcp-Server installiert sein, der dann auf den Namensraum 192.168.17.XXX eingestellt ist bzw. darin dann IPs vergibt.
s.o. Ich halte das nicht für eine gute Idee.
Ich dachte eben, man käme sich so mit dem Win-Server nicht "ins Gehege".
Es ist unter Linux einfach, einer Netzwerkkarte zwei unterschiedliche IP-Adressen zuzuweisen. In Deinem Fall verkompliziert das die Netzwerkkonfiguration nur unnötig - ohne dass es etwas zum Verständnis beitragen würde.
Ja, an dem Punkt lahmt mein Hirn irgendwie grade.
Dank und Gruß,
Robert aka
-
Hallo frankx,
Zudem kann der von der AG nicht administriert werden. Das macht der Fachbereichsleiter und wird u.U. sogar irgendwann mal berlinweit zentralisiert.
das kommt mir irgendwie bekannt vor. Es erinnert mich an Felix und seine AG.
Für mich steht nun Fortbildung an, heute am späten Abend mehr.Freundliche Grüße
Vinzenz
-
Hallo Robert,
Na, die Überlegung kam daher, dass der Windowsserver eben 192.168.16.XXX
verwaltet und nur eine begrenzte Zahl von IPs für dhcp zur Verfügung hat.
Zudem kann der von der AG nicht administriert werden.glücklicherweise war ich bei solchen Vorhaben nie in der unglücklichen Lage,
nur "Subadministrator" zu sein. Das machte mir das deutlich leichter :-)Fangen wir damit an:
Dazu müsste dann wohl noch ein dhcp-Server installiert sein, der dann
auf den Namensraum 192.168.17.XXX eingestellt ist bzw. darin dann IPs
vergibt.s.o. Ich halte das nicht für eine gute Idee.
Ich dachte eben, man käme sich so mit dem Win-Server nicht "ins Gehege".
Wenn Du in einem physischen Netzwerk einen weiteren DHCP-Server installierst,
dann kommen sich die beiden DHCP-Server ganz gewaltig ins Gehege. Das liegt
an dem Mechanismus, wie DHCP funktioniert:Die DHCP-Clientkonfiguration erfolgt in vier Phasen:
1.) IP-Leaseerkennung (durch den DHCP-Client)
2.) IP-Leaseangebot (durch die DHCP-Server)
3.) IP-Leaseanforderung (durch den Client)
4.) IP-Leasebestätigung (durch den Server)1.) IP-Leaseerkennung
Der DHCP-Client sendet die DHCPDISCOVER-Meldung per Rundsendung (Broadcast).
Dabei verwendet er 0.0.0.0 als Quelladresse (weil er ja noch keine IP-Adresse
hat) und 255.255.255.255 als Zieladresse und sendet seine Hardwareadresse mit.2.) IP-Leaseangebot
Alle sich zuständig fühlenden DHCP-Server senden eine DHCPOFFER-Meldung an
den Client und bieten dem Client eine IP-Adresse an (es werden noch ein paar
Daten mehr übertragen, unter anderem die DHCP-Serverkennung).3.) IP-Leaseanforderung
Wenn der DHCP-Client mindestens ein Angebot erhalten hat, dann sendet er
Broadcasts an alle DHCP-Server, von denen er ein Angebot erhalten hat, eine
DHCPREQUEST-Meldung. Sie enthält die Serverkennung des Servers, dessen Angebot
akzeptiert wurde. Die anderen DHCP-Server ziehen ihre Angebote zurück.4.) IP-Leasebestätigung
Der DHCP-Server dessen Angebot angenommen wurde, sendet eine Bestätigung an
den Client zurück, eine DHCPACK-Meldung. Diese enthält eine gültige Lease für
eine IP-Adresse und gegebenenfalls weitere Konigurationsinformationen. Wenn
der Client diese Bestätigung erhält, ist auf dem Client TCP/IP komplett
initialisiert und der Client kann im Netzwerk über TCP/IP kommunizieren.
(Soweit die Theorie, in der Praxis kann es bei bestimmten Chipsets mit einem
kaputten Design zu Problemen kommen, siehe Garys Problem.)Welche Auswirkungen hat das auf Dein Vorhaben?
Stell Dir vor, Du bringst einen neuen Rechner ins Netzwerk und dieser nimmt
die Lease des Windowsservers an? Dumm gelaufen!
Stell Dir vor der Admin des Fachbereichs fügt einen neuen direkt ans Netzwerk
angeschlossenen Drucker dem Netzwerk hinzu und dieser entscheidet sich für
die Lease Deiner Kiste? Dumm gelaufen!Du siehst, diese beiden kommen sich gewaltig ins Gehege. Also vermeide diese
Konfiguration.Das macht der Fachbereichsleiter und wird u.U. sogar irgendwann mal berlinweit
zentralisiert. Somit dachte ich, macht man einen eigene Ip-Raum, den man
selbst konfigurieren kann,Und damit Du ein Netzwerk hast, in dem Du (fast) nach Belieben experimentieren
kannst, ist es die beste Lösung, wenn Du über ein eigenständiges Netzwerk
verfügst, d.h. ein Netzwerk, das physisch von dem durch den Fachbereich
verwalteten getrennt ist.und ein Rechner spielt den Schleuser oder das Gateway, hat selbst zB. die
Ip 192.168.16.201 und spielt den DNS-Server für die Rechner im IP-Raum
192.168.17.XXX. Ist halt früheste Planungsphase.Der Gedankengang ist durchaus richtig. Du benötigst eine Netzwerkkomponente,
die die beiden physisch getrennten Netzwerke miteinander verbindet, im
einfachsten Fall übernimmt diese Netzwerkkomponente Routerdienste. Ein
Gateway (auf OSI-Schicht 7) ist nicht unbedingt erforderlich.Die Rechner im Sub-Linux-Netz
Nein, eben kein Sub-Netz, sondern ein eigenes Netzwerk.
sollten dann vielleicht auch fest IPs bekommen, damit man sie über
Namen (DNS) ansprechen kann.Das Problem, das Du bei der Umsetzung dieser Lösung hast ist die physische
Vernetzung Deiner Rechner. Ich gehe davon aus, dass deren Netzwerkkarten
über ein Patchkabel mit einer Patchdose im Kabelkanal (oder im Boden)
verbunden sind. Von dort werden sie zu einem Switch geführt, der sich z.B.
im Serverraum befindet.
Für Dein eigenes Netzwerk benötigst Du entweder einen eigenen Switch oder
der vorhandene Switch besitzt die Möglichkeit, Dir ein eigenes Netzwerk
zur Verfügung zu stellen. Letzteres erfordert einen entsprechend leistungs-
starken Switch sowie die Kooperation des Fachbereichsleiters, der die
Konfiguration vornehmen muss). Willst Du den eigenen Switch über die
bisherigen Anschlüsse nutzen, so wird dieser praktischerweise dort sein,
wo der vorhandene schon ist, z.B. im Serverraum. Es muss umgepatcht (und
dokumentiert :-)) werden, auch dies erfordert die Kooperation wie oben.
Am einfachsten wäre es, Deine Linuxkisten im Raum selbst zu vernetzen,
Stolperfallen sind natürlich zu vermeiden. Je nach Anzahl der Rechner tuts
ein günstiger 8-Port-Switch aus dem Soho-Bereich.Dein Server verbindet als Router die beiden Netzwerke:
Schulnetzwerk
|-------------------------------------------------|
| | | 192.168.16.201
---------------- --------- -----------------------
| Win-Server | |Client | | Linux-Server |
| DHCP-Server | |viele | | Router |
| für Netzwerk | |davon | | DNS-Server |
| 192.168.16.0 | --------- | DHCP-Server |
| 255.255.255.0| | für Netzwerk |
---------------- | 192.168.17.0 |
| 255.255.255.0 |
| und weitere Dienste |
| in diesem Netzwerk |
-----------------------
| 192.168.17.1
|
|--------------------------------------------------|
| Roberts Spezialnetzwerk |
| |
---------- ----------
| Linux- | | Linux- | ...
| kiste | | kiste |
| NFS | | NFS |
| ... | | ... |
---------- ----------Wie Du dieser Skizze bereits entnehmen kannst, benötigt Dein Server zwei
Netzwerkkarten, für jedes der beiden physichen Netze eine.Weiterhin kannst Du das Netzwerk 192.168.17.0/255 nur dann verwenden, wenn
es im Schulnetzwerk nicht bereits verwendet wird. Setze Dich dazu mit dem
Fachbereichsleiter zusammen. Ich würde einfach auf 10.x.y.z/255 setzen :-)Die Linux-Kisten sollen sicher weiter solche Annehmlichkeiten wie den
Internetzugang über das Schulnetzwerk nutzen, das Schulnetzwerk soll aber
im Prinzip nichts von Deinem Privatnetzwerk wissen. Dazu gehst Du so vor
wie beim kleinen Heimnetzwerk. Konfiguriere Deinen Linuxserver mit
Network Address Translation, das was in Wikipedia als Outbound-NAT
bezeichnet wird. Siehe z.B. das IP-Masquerade-HowTo.Wenn das soweit funktioniert, kannst Du an die anderen Dienste gehen, wie
DHCP (für Dein Spezialnetzwerk), DNS (caching + für Dein Spezialnetzwerk),
NFS, SMB, ...Netzwerk macht Spass
Vinzenz
-
Hellihello Vinzenz,
Du beeindruckst mich zum wiederholten Male. Da haben wir ja genug Futter für die nächsten Stunden. Da wir die Linux-Rechner sowieso schon im Raum per (alte) Hubs an einer Netzwerkbuchse stecken, sollte die Untereinandvernetzung (also ein eigenes Netz) kein echtes Problem sein.
Im Serverraum, zu dem wir keinen autonomen Zugang haben, steht ein zur Zeit noch ungenutzter Lern-Server, den "wir" (die AG) in Zukunft administrieren können. Den kriegen wir natürlich nicht so einfach ins "eigene" Netz. Das "rumfummeln" (auch das dokumentierte) an den Switches liegt glaub ich momentan in einiger Ferne. Der Fachbereichsleiter ist ausgesprochen kooperatriv/zugetan, arbeitet aber zugleich an mehreren Baustellen (Landesinstitut/Fortbildungsleitung etc.) so dass ihm die Zeit fehlt, wie er selbst immer sagt.
Deine ausführlichen Beschreibungen mit Planskizze werde ich dann beim nächsten Termin den interessierten AG-lern präsentieren. Schade, dass die TDL der Threads nur künstlich aufrechterhalten werden kann.
Dank und Gruß aus Berlin,
Robert aka
-
Moin!
Du beeindruckst mich zum wiederholten Male. Da haben wir ja genug Futter für die nächsten Stunden. Da wir die Linux-Rechner sowieso schon im Raum per (alte) Hubs an einer Netzwerkbuchse stecken, sollte die Untereinandvernetzung (also ein eigenes Netz) kein echtes Problem sein.
Im Serverraum, zu dem wir keinen autonomen Zugang haben, steht ein zur Zeit noch ungenutzter Lern-Server, den "wir" (die AG) in Zukunft administrieren können.
Wenn ihr sowieso schon einen Server habt, dann macht die Abschottung eines eigenen internen Netzwerks für Peer2Peer-Filesharing keinen wirklichen Sinn. Klar, Rumspielen und Lerneffekt sind ein netter Faktor, aber es wird komplizierter.
Wenn ein Server für die Dateiablage und sonstige Dinge der AG existiert, und DHCP und DNS anderweitig schon geregelt sind, ist das eine Umgebung, mit der man bestens arbeiten kann. Nichts anderes machen wir bei SELFHTML - und das klappt prima. :)
- Sven Rautenberg
--
"Love your nation - respect the others."-
Hellihello Sven,
Im Serverraum, zu dem wir keinen autonomen Zugang haben, steht ein zur Zeit noch ungenutzter Lern-Server, den "wir" (die AG) in Zukunft administrieren können.
Wenn ihr sowieso schon einen Server habt, dann macht die Abschottung eines eigenen internen Netzwerks für Peer2Peer-Filesharing keinen wirklichen Sinn.
naja, "die Schule hat" und "wir haben bzw. die AG hat" könnte ein Unterschied sein. Zudem steht ja ein Server ungenutzt herum, der den Schülern zum Administrieren überlassen werden kann/soll. Der nun steht aber eben im Serverraum, also nur zum Remote-Administrieren, was ja aber eigentlich ganz perfekt ist. Der zentrale Windows-Server wird allein vom FB-Leiter gewartet. Und Perspektive halt seinen Aussagen nach, dass das vielleicht ab irgendwann mal sogar remote und landesweit geregelt werden könnte.
Die Linuxrechner beispielsweise sind z.Z. allein AG-Rechner. Und der DHCP-Raum des Windows-Servers ist begrenzt. Änderungen bedürften halt immer einer Bemühung des FB-Leiters, der selbst sagt, dass er gewisse Dinge, die er gern machen würde, rein zeitlich nicht schafft.
Klar, Rumspielen und Lerneffekt sind ein netter Faktor, aber es wird komplizierter.
Na, das überlasse ich auf ne Art der Interessenslage der Schüler. Es sollte sich halt mit dem existierenden System vertragen. Im Grunde haben wir im Raum ja schon ein "Netzwerk" aus drei/vier PCs - Tendenz steigend (Nachfrage ist da: "... wann kann ich auch mal so einen Linux-Rechner haben?"). Sie hängen alle an denselben beiden älteren in Reihe geschalteten Hubs, von denen einer an einer Lan-Buchse steckt.
Eine Frage beim letzten mal war halt, wie greif ich von Rechner A am besten auf das Script von Rechner B zu, allein, um es anzuschauen. Zentrale Ablage für alle drei Rechner? Einbinden von einem Ordner des anderen Rechners ins Dateisystem via Gnomes "mit Server verbinden"?
Dann eben auch: soll man immer die IP eingeben, wenn ich per HTTP oder FTP oder SSH auf den anderen Rechner zugreifen will? Soll man auf jedem Rechner die /etc/hosts anpassen? Oder auch: Verteilt der Windowsserver immer die selben IPs an die Rechner? Bleibt das so?
Wenn ein Server für die Dateiablage und sonstige Dinge der AG existiert, und DHCP und DNS anderweitig schon geregelt sind, ist das eine Umgebung, mit der man bestens arbeiten kann. Nichts anderes machen wir bei SELFHTML - und das klappt prima. :)
Das ist vollkommen klar. Im Bereich der Windices hatten wir das so auch gemacht. Aber wenn da dann plötzlich drei bzw. u.U. auch vier Rechner nebeneinander stehen, die nur Gnu/Linux können (auch mal NetBSD) und sich auch nicht so beim Start mit dem Windows-Server verbinden, _sieht_ die Sache dann vor Ort irgendwie auch anders aus.
Dank und Gruß,
-
-
Hellihello Vinzenz,
hey, der Thread lebt ja noch.
Der Server hat 2 Lan-Buchsen. Wir haben jetzt mal die eine mit 192.168.16.199 ins Netz des Windowsservers (den IP-Namensraum?) gestellt.
Den zweiten, eth1, mal testweise mit 10.123.123.1 und einer Subnetzmaske 255.255.255.0. Einem Linuxrechner hab ich dann mal temporär die 10.123.123.2 verpasst, der konnte dann den Server anpingen.
Was mir bei IP-Adresse noch unklar ist: die Subnetzmaske definiert durch binäre Addition den Bereich. zB. 11111111.11111111.11111111.00000000 . Irgendwie hab ich aber überlesen, wieso sich daraus ein "Bereich" ergibt. Definieren die letzten Nullen den Bereich von 00000000 bis 11111111?
Und: anpingen kann ich nur Rechner, die entweder
a) direkt im durch eigene IP und Subnetzmaske definierten Namensraum liegen oder
b) vom DNS-Server aus erreichbar sind?Nicht ganz klar geworden ist mir, warum ein physisch getrenntes Netzwerk günstiger wäre - vorausgesetzt man verwendet _kein_ DHCP für das zweite Netzwerk. Für die Computer im Netzwerk 192.168.16.0/24 existieren doch andere IP-Adressen (ohne 192.168.16...) garnicht, oder? Bzw. nicht direkt, sondern nur über den DNS-Server unter 192.168.16.1 bzw 102 oder 254, das wechselt komischerweise immer mal in der /etc/resolve.conf. Ich geh mal davon aus, dass die übers DHCP generiert wird, also vom DHCP-Server auch den die IP des DNS-Servers genannt bekommt, oder?
Robert aka
-
Hallo Robert,
Der Server hat 2 Lan-Buchsen. Wir haben jetzt mal die eine mit 192.168.16.199 ins Netz des Windowsservers (den IP-Namensraum?) gestellt.
Den zweiten, eth1, mal testweise mit 10.123.123.1 und einer Subnetzmaske 255.255.255.0. Einem Linuxrechner hab ich dann mal temporär die 10.123.123.2 verpasst, der konnte dann den Server anpingen.
Was mir bei IP-Adresse noch unklar ist: die Subnetzmaske definiert durch binäre Addition den Bereich. zB. 11111111.11111111.11111111.00000000 . Irgendwie hab ich aber überlesen, wieso sich daraus ein "Bereich" ergibt. Definieren die letzten Nullen den Bereich von 00000000 bis 11111111?
Dazu verlinke ich Dir einfach den Wikipedia-Artikel zu CIDR und einen [link:/archiv/2004/10/t92849/#m560271@title=Archivbeitrag von mir.
a) direkt im durch eigene IP und Subnetzmaske definierten Namensraum liegen oder
und auch erreichbar sind.
b) vom DNS-Server aus erreichbar sind?
Nein. DNS ist für die Umsetzung von Namen in IP-Adressen zuständig (bei Reverse-DNS auch für die Umsetzung von IP-Adressen in Namen, siehe die Reverse-Zone im DNS-HowTo).
Möchtest Du etwas anpingen, was sich nicht in dem Netzwerk befindet, in dem Du gerade bist, dann ist Routing notwendig. Deine Linuxkiste muss dazu das Routen lernen :-) Weiterhin ist die IP-Adresse Deines Linuxrouters (der Kiste mit den zwei Netzwerkkarten) als Standardgateway einzutragen, natürlich die IP-Adresse, die im gleichen Netzwerk liegt.
Wozu ist das Standardgateway da? Ganz einfach: Alle IP-Pakete, die nicht direkt zugestellt werden können (d.h. im gleichen Netzwerk bleiben) und deren Wege nicht durch statische Routen festgelegt sind, die werden ans Standardgateway geschickt. Das Gerät dort (der Router) soll gefälligst sehen, dass die Pakete ankommen :-)
Siehe dazu auch diesen Beitrag, den Du sicher schon einmal gelesen hast.
Damit bei Ping die Antwort zurückkommen kann, muss das umgekehrt genauso funktionieren. Wenn die böse Welt dort draußen - und das ist hier auch schon im Schulnetz so - nichts von Deinem privaten Linux-Netzwerk wissen soll, dann solltest Du Deine Linuxkiste mit den zwei Netzwerkkarten für NAT konfigurieren, wie ich Dir bereits geraten habe.
Nicht ganz klar geworden ist mir, warum ein physisch getrenntes Netzwerk günstiger wäre - vorausgesetzt man verwendet _kein_ DHCP für das zweite Netzwerk. Für die Computer im Netzwerk 192.168.16.0/24 existieren doch andere IP-Adressen (ohne 192.168.16...) garnicht, oder? Bzw. nicht direkt, sondern nur über den DNS-Server unter 192.168.16.1 bzw 102 oder 254,
nö, übers Standardgateway. Kriegst Du typischerweise auch mit DHCP konfiguriert. Das ist weniger Arbeit.
das wechselt komischerweise immer mal in der /etc/resolve.conf. Ich geh mal davon aus, dass die übers DHCP generiert wird, also vom DHCP-Server auch den die IP des DNS-Servers genannt bekommt, oder?
Ja, das ist ebenfalls eine typische Option, die man unter DHCP gerne nutzt.
Ich empfehle Dir, auf Deiner Linuxkiste einen DHCP-Server zu installieren,
der an eth1 lauscht und für dein 10.123.123.0/24-Netzwerk zuständig ist.
Das ist gar nicht soo schwer. Und bringt einen enormen Lerneffekt:"Aha, so (ähnlich) macht das auch der Windowsserver für das Schulnetz."
Freundliche Grüße
Vinzenz
-
Hellihello Vinzenz,
Dazu verlinke ich Dir einfach den Wikipedia-Artikel zu CIDR und einen [link:/archiv/2004/10/t92849/#m560271@title=Archivbeitrag von mir.
Merci, nun ist der Groschen gefallen.
a) direkt im durch eigene IP und Subnetzmaske definierten Namensraum liegen oder
und auch erreichbar sind.
b) vom DNS-Server aus erreichbar sind?
Nein. DNS ist für die Umsetzung von Namen in IP-Adressen zuständig (bei Reverse-DNS auch für die Umsetzung von IP-Adressen in Namen, siehe die Reverse-Zone im DNS-HowTo).
Also bei "ping example.com".
Möchtest Du etwas anpingen, was sich nicht in dem Netzwerk befindet, in dem Du gerade bist, dann ist Routing notwendig. Deine Linuxkiste muss dazu das Routen lernen :-) Weiterhin ist die IP-Adresse Deines Linuxrouters (der Kiste mit den zwei Netzwerkkarten) als Standardgateway einzutragen, natürlich die IP-Adresse, die im gleichen Netzwerk liegt.
Routing per NAT, wobei es kein extra NAT-Router-Programm (Server) gibt, sondern das eine Konfigruation in den Netzwerkkonfigurationen ist (?).
Siehe dazu auch diesen Beitrag, den Du sicher schon einmal gelesen hast.
(;-).
Damit bei Ping die Antwort zurückkommen kann, muss das umgekehrt genauso funktionieren. Wenn die böse Welt dort draußen - und das ist hier auch schon im Schulnetz so - nichts von Deinem privaten Linux-Netzwerk wissen soll, dann solltest Du Deine Linuxkiste mit den zwei Netzwerkkarten für NAT konfigurieren, wie ich Dir bereits geraten habe.
Nicht ganz klar geworden ist mir, warum ein physisch getrenntes Netzwerk günstiger wäre - vorausgesetzt man verwendet _kein_ DHCP für das zweite Netzwerk. Für die Computer im Netzwerk 192.168.16.0/24 existieren doch andere IP-Adressen (ohne 192.168.16...) garnicht, oder? Bzw. nicht direkt, sondern nur über den DNS-Server unter 192.168.16.1 bzw 102 oder 254,
nö, übers Standardgateway. Kriegst Du typischerweise auch mit DHCP konfiguriert. Das ist weniger Arbeit.
Aber ich verstand Dich so, dass bei physisch _nicht_getrennten Netzwerken sich die beiden DHCP-Server in die Quere kommen könnten (mal abgesehen davon, dass der Schul-Win-Server DHCP nur als eine Alternative für eine begrenzte Anzahl von IPs angibt, fast alle Rechner haben eine feste IP).
das wechselt komischerweise immer mal in der /etc/resolve.conf. Ich geh mal davon aus, dass die übers DHCP generiert wird, also vom DHCP-Server auch den die IP des DNS-Servers genannt bekommt, oder?
Ja, das ist ebenfalls eine typische Option, die man unter DHCP gerne nutzt.
Ich empfehle Dir, auf Deiner Linuxkiste einen DHCP-Server zu installieren,
der an eth1 lauscht und für dein 10.123.123.0/24-Netzwerk zuständig ist.
Das ist gar nicht soo schwer. Und bringt einen enormen Lerneffekt:"Aha, so (ähnlich) macht das auch der Windowsserver für das Schulnetz."
Jau, aber: dann müsste ich den Linux-DHCP-Clients ja vorher bereits eine Subnetzmaske verpasst haben. Ich dachte, das ginge nur zusammen mit einer eigenen IP. Oder kann ich auch das Standardgateway (und/oder DNS-Server) festlegen mit Subnetzmaske und die IP dennoch per DHCP vergeben? Oder ist das murx?
Dank und Gruß,
Robert aka
-
Moin!
Jau, aber: dann müsste ich den Linux-DHCP-Clients ja vorher bereits eine Subnetzmaske verpasst haben. Ich dachte, das ginge nur zusammen mit einer eigenen IP. Oder kann ich auch das Standardgateway (und/oder DNS-Server) festlegen mit Subnetzmaske und die IP dennoch per DHCP vergeben? Oder ist das murx?
DHCP übermittelt (wenn gewünscht und konfiguriert) eine Unmenge an Netzwerkparametern, nicht nur IP und Subnetzmaske.
Üblich, weil eigentlich zwingend notwendig, sind IP von Standardgateway und DNS-Server.
Goodies sind z.B. die Adressen/Namen von Zeitservern (NTP- oder Time-Protokoll), oder Angaben zur vom Standard abweichenden MTU (weil z.B. der DSL-Router sonst fragmentierte Pakete via PPPoE schicken müßte). Eher "esoterisch" in einer Linux-Umgebung sind die diversen Konfigurationsoptionen zu Windows-Shares und SMB - aber existent.
Es ist eine extrem gute Idee, auch bei nur einer überschaubaren Anzahl von Clients, die man eigentlich manuell konfigurieren könnte, DHCP einzusetzen, weil man damit einfach alle Netzwerkparameter, die man konfiguriert, fix an EINEM Ort zusammenhält. Das gilt auch dann, wenn die Clients fixe IPs bekommen sollen (auch das geht basierend auf der Mac-Adresse des Netzwerkadapters). Ist einfach angenehmer, mit einem Edit global die neue IP z.B. des DNS-Servers bekannt zu machen, anstelle das bei jedem Client manuell nachzutragen.
- Sven Rautenberg
--
"Love your nation - respect the others."-
Hellihello Sven,
danke für die Antwort.
DHCP übermittelt (wenn gewünscht und konfiguriert) eine Unmenge an Netzwerkparametern, nicht nur IP und Subnetzmaske.
Üblich, weil eigentlich zwingend notwendig, sind IP von Standardgateway und DNS-Server.
Goodies sind z.B. die Adressen/Namen von Zeitservern (NTP- oder Time-Protokoll), oder Angaben zur vom Standard abweichenden MTU (weil z.B. der DSL-Router sonst fragmentierte Pakete via PPPoE schicken müßte). Eher "esoterisch" in einer Linux-Umgebung sind die diversen Konfigurationsoptionen zu Windows-Shares und SMB - aber existent.
Es ist eine extrem gute Idee, auch bei nur einer überschaubaren Anzahl von Clients, die man eigentlich manuell konfigurieren könnte, DHCP einzusetzen, weil man damit einfach alle Netzwerkparameter, die man konfiguriert, fix an EINEM Ort zusammenhält. Das gilt auch dann, wenn die Clients fixe IPs bekommen sollen (auch das geht basierend auf der Mac-Adresse des Netzwerkadapters). Ist einfach angenehmer, mit einem Edit global die neue IP z.B. des DNS-Servers bekannt zu machen, anstelle das bei jedem Client manuell nachzutragen.
Was ich noch nicht verstehe ist: wie bringe ich die GNU/Linuxrechner (das sind jetzt zufälligerweise die, die ins getrennte Netz sollen) dazu, ihr DHCP vom Server ("Lernserver") zu beziehen, der mit eth1 mit 10.123.123.1 im Netz erreichbar ist, und nicht den Windows Server ("Schulserver") 192.168.16.1?
Der "Lernserver" soll ja autark nur den IP-Raum 10.123.123.0/24 verwalten. Und als Gateway dienen. Die eth0 hat dann die IP 192.168.16.199 und soll (wenns nicht besser machbar ist) dann zum Windows-Server routen.
Das mit NAT hab ich auch noch nicht so ganz kapiert. Da stehen so viele Hyrogplyphen im Manual. Statt: konfiguriere so und so und so.
Dank und Gruß,
-
Hallo
Was ich noch nicht verstehe ist: wie bringe ich die GNU/Linuxrechner (das sind jetzt zufälligerweise die, die ins getrennte Netz sollen) dazu, ihr DHCP vom Server ("Lernserver") zu beziehen, der mit eth1 mit 10.123.123.1 im Netz erreichbar ist, und nicht den Windows Server ("Schulserver") 192.168.16.1?
dazu müssen diese physisch getrennte Netzwerke (oder halt VLANs) verwenden.
An den zusätzlichen Hubs/Switches, über die Du doch verfügst, hängen _nur_ die Rechner aus dem 10.x-Netzwerk, die Rechner, die zum Windows-Server müssen, dürfen da _nicht_ dranhängen.Der "Lernserver" soll ja autark nur den IP-Raum 10.123.123.0/24 verwalten. Und als Gateway dienen. Die eth0 hat dann die IP 192.168.16.199 und soll (wenns nicht besser machbar ist) dann zum Windows-Server routen.
Das mit NAT hab ich auch noch nicht so ganz kapiert. Da stehen so viele Hyrogplyphen im Manual. Statt: konfiguriere so und so und so.
Ach, in der einfachsten Variante ist das nun wirklich gar nicht schwer.
Daher meine Frage: Sind die Netzwerke physisch von einander getrennt?
Hängt nur die Kiste mit den zwei Netzwerkkarten in beiden Netzwerken?Freundliche Grüße
Vinzenz
-
Hellihello Vinzenz,
Was ich noch nicht verstehe ist: wie bringe ich die GNU/Linuxrechner (das sind jetzt zufälligerweise die, die ins getrennte Netz sollen) dazu, ihr DHCP vom Server ("Lernserver") zu beziehen, der mit eth1 mit 10.123.123.1 im Netz erreichbar ist, und nicht den Windows Server ("Schulserver") 192.168.16.1?
dazu müssen diese physisch getrennte Netzwerke (oder halt VLANs) verwenden.
An den zusätzlichen Hubs/Switches, über die Du doch verfügst, hängen _nur_ die Rechner aus dem 10.x-Netzwerk, die Rechner, die zum Windows-Server müssen, dürfen da _nicht_ dranhängen.Ja, so hatte ich das bereits auch verstanden und bin nun bestätigt, dass ich recht verstand.
Der "Lernserver" soll ja autark nur den IP-Raum 10.123.123.0/24 verwalten. Und als Gateway dienen. Die eth0 hat dann die IP 192.168.16.199 und soll (wenns nicht besser machbar ist) dann zum Windows-Server routen.
Das mit NAT hab ich auch noch nicht so ganz kapiert. Da stehen so viele Hyrogplyphen im Manual. Statt: konfiguriere so und so und so.
Ach, in der einfachsten Variante ist das nun wirklich gar nicht schwer.
Daher meine Frage: Sind die Netzwerke physisch von einander getrennt?
Hängt nur die Kiste mit den zwei Netzwerkkarten in beiden Netzwerken?Zur Zeit kann ich nur sagen: ich weiß es nicht 100%. In einer Reihe von Lan-Buchsen, die an drei Wänden im Raum angebracht sind, von der Tür startend, sitzen wir jetzt mit vier Rechnern an deren Ende. Wenn es sich als möglich erweist, diese letzte Buchse im Serverraum (neben der ersten Wandreihe Lanbuchsen) direkt mit dem Lernserver im Serverraum zu verbinden, dann ja. Der Wille ist da, auch auf Seiten der FB-Leitung. Allein an Zeit fehlt es dort eben öfter. Jetzt wo ich drüber nachdenke, "müsste" es ja eigentlich in jedem Fall machbar sein. Und dann würde ich/wir das auch so machen.
Heute war es nicht so, da hatten wir den Server zum Einrichten schlicht mit an eine Lanbuchse im Rechnerraum gestöpselt. Bis Mittwoch wird sich das mit der Kabelage klären lassen.
Dennoch frage ich mich, ob theoretisch mit fester IP für die Rechner im Netz 10.123.123.0/24 das dann sinnigerweise ohne DHCP aber doch gleiche Bedingungen liefert, wie ein physisch getrennets Netz. Also auch, was das Routing angeht? Oder ist das im Zusammenspiel mit DHCP und _physisch_ getrenntem Netz einfacher?
Btw: müssen die Server immer so laut sein? Sind das vier kleine Lüfter, die sich nicht an die CPU-Temperatur anpassen im Speed?
Dank und Gruß,
-
Hallo Robert,
Dennoch frage ich mich, ob theoretisch mit fester IP für die Rechner im Netz 10.123.123.0/24 das dann sinnigerweise ohne DHCP aber doch gleiche Bedingungen liefert, wie ein physisch getrennets Netz.
was verstehst Du unter gleichen Bedingungen?
Also auch, was das Routing angeht?
Wenn Du zwei verschiedene Netzwerke auf dem gleichen physischen Netz betreibst, nur einen DHCP-Server hast, weitgehend ja.
Oder ist das im Zusammenspiel mit DHCP und _physisch_ getrenntem Netz einfacher?
Ja, ist es. DHCP ist was wunderbares. Lies Dir einfach nochmals Svens Beitrag durch.
Btw: müssen die Server immer so laut sein?
Hmm, müssen sie nicht. Sind sie aber oft. Schließlich stehen Server normalerweise in einem Raum, wo das keinen stört - außer wenn man sich im Raum befindet - was selten lange dauert.
Sind das vier kleine Lüfter,
Unterschiedliche Serverhardware hat unterschiedliche (und unterschiedlich viele) Lüfter. Für Dein Lernnetzwerk sollte es jeder handelsübliche (und entsprechend leise) Büro-PC, der nicht allzu alt ist tun - er benötigt nur zwei Netzwerkkarten - und die kosten ja nicht die Welt.
Freundliche Grüße
Vinzenz
-
Hellihello Vinzenz,
merci.
Dennoch frage ich mich, ob theoretisch mit fester IP für die Rechner im Netz 10.123.123.0/24 das dann sinnigerweise ohne DHCP aber doch gleiche Bedingungen liefert, wie ein physisch getrennets Netz.
was verstehst Du unter gleichen Bedingungen?
s.u.
Also auch, was das Routing angeht?
Wenn Du zwei verschiedene Netzwerke auf dem gleichen physischen Netz betreibst, nur einen DHCP-Server hast, weitgehend ja.
S.o., das meinte ich.
Oder ist das im Zusammenspiel mit DHCP und _physisch_ getrenntem Netz einfacher?
Ja, ist es. DHCP ist was wunderbares. Lies Dir einfach nochmals Svens Beitrag durch.
Jau, das hab ich schon kapiert, nicht genau die Details, aber dass DHCP zu den guten gehört.
Unterschiedliche Serverhardware hat unterschiedliche (und unterschiedlich viele) Lüfter. Für Dein Lernnetzwerk sollte es jeder handelsübliche (und entsprechend leise) Büro-PC, der nicht allzu alt ist tun - er benötigt nur zwei Netzwerkkarten - und die kosten ja nicht die Welt.
Naja, wir sind ja in der schrecklichen Lage, dass es das "Ding" schon gibt, vor ca. einem Jahr von Schulseite angeschafft, aber bisher keiner Nutzung zugeführt wurde. Mir ist schon klar, dass wir das auch in der Runde mit den vier Linux-Pcs direkt lösen könnten, indem wir einen zum Server machen. Aber es ist ja ein Graus, wenn so ein Gerät nicht sinnvoll eingebunden wird.
Das Problem mit dem getrennten Netz könnte sein, dass an der Fensterseite (visavis der Wand, auf deren Rückseite der Serverraum ist) nur einfache Buchsen (keine doppelten) montiert sind. An der letzten Buchse hängt bereits ein Win-Rechner, der nach wie vor im Win-Netz bleiben soll. Aber mit Kabeln und einem Hub wird sich da vielleicht "was" machen lassen. Vorausgesetzt ich /wir finden das Kabel im Serverraum, was zur letzten Buchse im Rechnerraum führt. Das ist gemäß euren/Deinen Ratschlägen definitiv Plan A. Morgen seh ich da klarer vermutlich.
Dank und Gruß,
Robert aka
-
Hellihello Vinzenz,
das mit dem Kabel/Buchse finden war jetzt doch erfolglos. Obowhl beschriftet, und mit so einem kleinen Lan-Buchsen-Verbindungs-Checker getestet, hängt eth1 jetzt an irgendeiner Buchse, keine Ahnung wo, aber mit Sicherheit nicht an "206 D2 1" und auch nicht an "206 D2 /2" und an keiner der anderen im Raum 206. Da der Fachbereichsleiter dann selbst eine Fortbildungsveranstaltung gab, werden wir mal schauen, ob er zu Freitag die korrekte Buchse findet.
Insofern erstmal TTL += 68400*3 für diesen Thread.
Dank und Gruß,
Robert aka
-
-
-
-
Hellihello Vinzenz,
Ach, in der einfachsten Variante ist das nun wirklich gar nicht schwer.
Daher meine Frage: Sind die Netzwerke physisch von einander getrennt?
Hängt nur die Kiste mit den zwei Netzwerkkarten in beiden Netzwerken?Ja.
Dank und Gruß,
Robert aka
-
Hallo Robert,
Ach, in der einfachsten Variante ist das nun wirklich gar nicht schwer.
Daher meine Frage: Sind die Netzwerke physisch von einander getrennt?
Hängt nur die Kiste mit den zwei Netzwerkkarten in beiden Netzwerken?Ja.
wenn die Rechner in Deinem Netzwerk nur Zugriff aufs Internet benötigen - und sonst nichts, dann sollte Vorgehen nach dem bereits verlinkten Masquerading-Howto ausreichen. Kurz zusammengefasst:
-
Grundlagen in Kapitel 2
Voraussetungen entnimm 2.6 (auch wenn dort Kernel 2.4 steht und Du sicher
einen 2.6er hast. -
Konfiguration des Routers, siehe Kapitel 3.4.1
Nutze das gut kommentierte Firewallscript, die notwendigen Anpassungen
an Deine Umgebung solltest Du problemlos finden. Für Deinen Zweck sollte
es das einfache Skript aus 3.4.1 tun (gibt es auch als Download). -
Clientkonfiguration beschränkt sich auf Standardgateway und DNS-Server
(was man hervorragend über DHCP zuweisen kann), siehe Kapitel 4 -
Testen, siehe Kapitel 5
Viel Erfolg,
Vinzenz
-
Hellihello Vinzenz,
Danke!
wenn die Rechner in Deinem Netzwerk nur Zugriff aufs Internet benötigen - und sonst nichts,
Jau, erstmal. Was könnte denn sonst noch bei der Simulation einer realistischen Umgebung in der Welt da draußen gefragt sein? Aber das eine reicht erstmal.
dann sollte Vorgehen nach dem bereits verlinkten Masquerading-Howto ausreichen. Kurz zusammengefasst:
- Grundlagen in Kapitel 2
Voraussetungen entnimm 2.6 (auch wenn dort Kernel 2.4 steht und Du sicher
einen 2.6er hast.
Iptables heißt wohl das Zauberwort. Und das kann eben die Verbindung zwischen internen IPs und der einen einzigen äußeren nach draußen "routen" oder herstellen oder bewerkstelligen.
- Konfiguration des Routers, siehe Kapitel 3.4.1
Nutze das gut kommentierte Firewallscript, die notwendigen Anpassungen
an Deine Umgebung solltest Du problemlos finden. Für Deinen Zweck sollte
es das einfache Skript aus 3.4.1 tun (gibt es auch als Download).
Das "<rc.firewall-iptables START>"
#!/bin/sh # # rc.firewall-iptables FWVER=0.76...
darin u.a. die Variablendeklaration:
EXTIF="eth0" INTIF="eth1"Ipadressen finden sich darin vergeblich. Kapiert habe ich die Details des Skriptes noch nicht. Vermutlich ist es dem Script auch egal, ob der Rechner dann auf dem eth0 mit einem Server im Internet hantiert oder mit einem im lokalen Netz, der selbst wiederum als Router fungiert. Oder sind alle Rechner, egal ob lokal oder im Internet, im Grunde so konfiguriert als Router, nur dass die einen mit lokalen IPs hantieren und die anderen mit öffentlichen?
- Clientkonfiguration beschränkt sich auf Standardgateway und DNS-Server
(was man hervorragend über DHCP zuweisen kann), siehe Kapitel 4
Na, die sollen ja DHCP machen. Die landen ja nur am eth1 des Lernservers mittlerweile.
- Testen, siehe Kapitel 5
Mittwoch dann.
Dank und Gruß,
Robert aka
-
Hallo Robert,
- Konfiguration des Routers, siehe Kapitel 3.4.1
Nutze das gut kommentierte Firewallscript, die notwendigen Anpassungen
an Deine Umgebung solltest Du problemlos finden. Für Deinen Zweck sollte
es das einfache Skript aus 3.4.1 tun (gibt es auch als Download).
Ipadressen finden sich darin vergeblich.
die kommen erst in rc.firewall-iptables-stronger, dem Skript dass Du nach erfolgreichen Tests mit der einfachen Version einsetzen solltest :-)
Beachte insbesondere folgenden Änderungslogeintrag:
# 0.74s - Changed the EXTIP command to work on NON-English distros
siehe dazu auch </archiv/2007/1/t143984/#m934772>ff.
- Clientkonfiguration beschränkt sich auf Standardgateway und DNS-Server
(was man hervorragend über DHCP zuweisen kann), siehe Kapitel 4
Na, die sollen ja DHCP machen. Die landen ja nur am eth1 des Lernservers mittlerweile.
Ist der DHCP-Server schon konfiguriert? Oder noch in der Mache?
Freundliche Grüße
Vinzenz
-
Hellihello
Na, die sollen ja DHCP machen. Die landen ja nur am eth1 des Lernservers mittlerweile.
Ist der DHCP-Server schon konfiguriert? Oder noch in der Mache?
Mittwoch dann. Musste mich erstmal breitschlagen lassen, die Dokumentation mit "troff" machen zu lassen (;-) und sonstigen "Schnickschnack" am Freitag klären. DHCP steht aber oben auf der Tagesordnung als erstes am Mittwoch.
Dank und Gruß,
-
Hellihello
Ist der DHCP-Server schon konfiguriert? Oder noch in der Mache?
Der laeuft jetzt. Immerhin erhalten die Rechner eine Ip-Adresse von ihm.
Loading simple rc.firewall-iptables version 0.76..
External Interface: eth0
Internal Interface: eth1
loading modules: - Verifying that all kernel modules are ok
----------------------------------------------------------------------
ip_tables, ip_conntrack, ip_conntrack_ftp, ip_conntrack_irc, iptable_nat, ip_nat_ftp, ----------------------------------------------------------------------
Done loading modules.Enabling forwarding..
Enabling DynamicAddr..
Clearing any existing rules and setting default policy..
FWD: Allow all connections OUT and only existing and related ones IN
Enabling SNAT (MASQUERADE) functionality on eth0rc.firewall-iptables v0.76 done.
Firewall/IP-Masq-Script hab ich auch laufen lassen. Der die Clientrechner aber kriegen kein Internet.
Das ist die dhcpd.conf, die ich eingebaut habe. Im Bereich Nameserver vermutlich nicht korrekt?
////////////////////////////
Sample configuration file for ISC dhcpd for Debian
$Id: dhcpd.conf,v 1.4.2.2 2002/07/10 03:50:33 peloy Exp $
subnet 10.123.123.0 netmask 255.255.255.0 {
range 10.123.123.128 10.123.123.254; # Range of IP addresses to be issued to DHCP clients
option subnet-mask 255.255.255.0; # Default subnet mask to be used by DHCP clients
option broadcast-address 10.123.123.255; # Default broadcastaddress to be used by DHCP clients
option routers 10.123.123.1; # Default gateway to be used by DHCP clients
option domain-name "your-domain.org";
option domain-name-servers 40.175.42.254, 40.175.42.253; # Default DNS to be used by DHCP clients
option netbios-name-servers 10.123.123.100; # Specify a WINS server for MS/Windows clients.
# (Optional. Specify if used on your network)# DHCP requests are not forwarded. Applies when there is more than one ethernet device and forwarding is configured.
# option ipforwarding off;default-lease-time 21600; # Amount of time in seconds that a client may keep the IP address
max-lease-time 43200;option time-offset -18000; # Eastern Standard Time
# option ntp-servers 10.123.123.1; # Default NTP server to be used by DHCP clients
# option netbios-name-servers 10.123.123.1;--- Selects point-to-point node (default is hybrid). Don't change this unless you understand Netbios very well
# option netbios-node-type 2;
# We want the nameserver "ns2" to appear at a fixed address.
# Name server with this specified MAC address will recieve this IP.host ns2 {
next-server ns2.your-domain.com;
hardware ethernet 00:02:c3:d0:e5:83;
fixed-address 40.175.42.254;
}# Laser printer obtains IP address via DHCP. This assures that the
# printer with this MAC address will get this IP address every time.#host laser-printer-lex1 {
# hardware ethernet 08:00:2b:4c:a3:82;
# fixed-address 10.123.123.120;
#}
}////////////////////////////
Ip-Masq-Script
ein paar Kommentarzeilen geloescht, da ich der Geschwaetzigkeit bezichtigt wurde
////////////////////////////
#!/bin/sh
rc.firewall-iptables
FWVER=0.76
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
** Please use the "whereis iptables" command to figure out
** where your copy is and change the path below to reflect
** your setup
IPTABLES=/sbin/iptables
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe#Setting the EXTERNAL and INTERNAL interfaces for the network
EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==echo -en " loading modules: "
Need to verify that all modules have all required dependencies
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a===============================================================
echo "----------------------------------------------------------------------"
#Load the main body of the IPTABLES module - "iptable"
# - Loaded automatically when the "iptables" command is invoked# - Loaded manually to clean up kernel auto-loading timing issues
echo -en "ip_tables, "
$MODPROBE ip_tables#Load the IPTABLES filtering module - "iptable_filter"
# - Loaded automatically when filter policies are activated#Load the stateful connection tracking framework - "ip_conntrack"
# - Loaded manually to clean up kernel auto-loading timing issues
echo -en "ip_conntrack, "
$MODPROBE ip_conntrack#Load the FTP tracking mechanism for full FTP tracking
Enabled by default -- insert a "#" on the next line to deactivate
echo -en "ip_conntrack_ftp, "
$MODPROBE ip_conntrack_ftp#Load the IRC tracking mechanism for full IRC tracking
Enabled by default -- insert a "#" on the next line to deactivate
echo -en "ip_conntrack_irc, "
$MODPROBE ip_conntrack_irc#Load the general IPTABLES NAT code - "iptable_nat"
# - Loaded automatically when MASQ functionality is turned on# - Loaded manually to clean up kernel auto-loading timing issues
echo -en "iptable_nat, "
$MODPROBE iptable_nat#Loads the FTP NAT functionality into the core IPTABLES code
Required to support non-PASV FTP.
Enabled by default -- insert a "#" on the next line to deactivate
echo -en "ip_nat_ftp, "
$MODPROBE ip_nat_ftp#Loads the IRC NAT functionality into the core IPTABLES code
Required to support NAT of IRC DCC requests
Disabled by default -- remove the "#" on the next line to activate
#echo -e "ip_nat_irc"
#$MODPROBE ip_nat_ircecho "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
#CRITICAL: Enable IP forwarding since it is disabled by default since
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forwardDynamic IP users:
# If you get your IP address dynamically from SLIP, PPP, or DHCP,
# enable this following option. This enables dynamic-address hacking
# which makes the life with Diald and similar programs much easier.echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddrEnable simple IP forwarding and Masquerading
# NOTE: In IPTABLES speak, IP Masquerading is a form of SourceNAT or SNAT.
# NOTE #2: The following is an example for an internal LAN address in the
# 192.168.0.x network with a 255.255.255.0 or a "24" bit subnet mask
# connecting to the Internet on external interface "eth0". This
# example will MASQ internal traffic out to the Internet but not
# allow non-initiated traffic into your internal network.# ** Please change the above network numbers, subnet mask, and your
# *** Internet connection interface name to match your setup#Clearing any previous configuration
# Unless specified, the defaults for INPUT and OUTPUT is ACCEPT
# The default for FORWARD is DROP (REJECT is not a valid policy)# Isn't ACCEPT insecure? To some degree, YES, but this is our testing
# phase. Once we know that IPMASQ is working well, I recommend you run
# the rc.firewall-*-stronger rulesets which set the defaults to DROP but
# also include the critical additional rulesets to still let you connect to
# the IPMASQ server, etc.echo " Clearing any existing rules and setting default policy.."
$IPTABLES -P INPUT ACCEPT
$IPTABLES -F INPUT
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -F OUTPUT
$IPTABLES -P FORWARD DROP
$IPTABLES -F FORWARD
$IPTABLES -t nat -Fecho " FWD: Allow all connections OUT and only existing and related ones IN"
$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT
$IPTABLES -A FORWARD -j LOGecho " Enabling SNAT (MASQUERADE) functionality on $EXTIF"
$IPTABLES -t nat -A POSTROUTING -o $EXTIF -j MASQUERADEecho -e "\nrc.firewall-iptables v$FWVER done.\n"
///////////////////////////////////////////////////////
Dank und Gruß,
-
Hellihello Vinzenz,
option domain-name-servers 40.175.42.254, 40.175.42.253; # Default DNS to be used by DHCP clients
Hab ich jetyt mal die 192.168.16.254 und 192.168.16.1 reingesetzt. Jetzt gehts, Internet und anpingen des Win-Servers.
Dank und Gruß,
Robert aka
-
Hallo Robert,
Das ist die dhcpd.conf, die ich eingebaut habe. Im Bereich Nameserver vermutlich nicht korrekt?
wie Du inzwischen selbst herausgefunden hast.
option domain-name "your-domain.org";
Verwendet Ihr tatsächlich diese Domain?
Wenn nein, weg mit dieser Option.option domain-name-servers 40.175.42.254, 40.175.42.253; # Default DNS to be used by DHCP clients
Hast Du korrigiert und einen nahen DNS-Server aus eurem Schulnetzwerk eingerichtet. Möglicherweise dürfen ausschließlich diese DNS-Anfragen ins wilde Internet starten.
option netbios-name-servers 10.123.123.100; # Specify a WINS server for MS/Windows clients.
Hast Du einen WINS/Samba-Server mit dieser IP-Adresse? Wenn nein, Option auskommentieren.
option time-offset -18000; # Eastern Standard Time
kannst Du getrost auskommentieren.
# We want the nameserver "ns2" to appear at a fixed address.
# Name server with this specified MAC address will recieve this IP.host ns2 {
next-server ns2.your-domain.com;
hardware ethernet 00:02:c3:d0:e5:83;
fixed-address 40.175.42.254;
}solltest Du unbedingt auskommentieren. Das ist ein Beispiel dafür, wie man für einen Rechner mit einer bestimmten MAC-Adresse eine IP-Adresse reserviert. Das ist ganz nützlich, um beispielsweise Server oder Netzwerkdrucker über DHCP und doch statisch zu konfigurieren.
ein paar Kommentarzeilen geloescht, da ich der Geschwaetzigkeit bezichtigt wurde
es ist ja auch nicht sinnvoll, ein solches Skript, das im Internet problemlos erreichbar ist, komplett zu zitieren.
Nun, da das Grundsystem läuft, kannst Du auf das bessere Firewallskript umsteigen ...
Freundliche Grüße
Vinzenz
-
- Konfiguration des Routers, siehe Kapitel 3.4.1
- Grundlagen in Kapitel 2
-
-
-
-
-
-
-
-
-
-
-
-