bolug bonner linux user group
news about wissen files archive hilfe suchen  

 

archive :: SchAN-User

druckfassung

SchAN-User

Re: [Schan-user] IP-Adressvergabe über 2 Netzwerkkarten an Arktur nach d

To: Schulen ans Netz - Anwender <schan-user@xxxxxxxxxxxxxxxxx>
Subject: Re: [Schan-user] IP-Adressvergabe über 2 Netzwerkkarten an Arktur nach dem Zufallfprinzip?
From: Juergen Engeland <juergen.engeland@xxxxxxxxxxx>
Date: Wed, 23 May 2012 18:35:43 +0200
Hallo Martin,

da Du auf jeden Fall die IP-Adresse von Arktur geändert hast, gibt es
etliche Stellen, wo Du diese von Hand nachpflegen musst.
Bis hin zum "default user profile", wie meine SchülerInnen aus einem
Informatikkurses im Rahmen eines Projekts herausgefunden haben.
Hier sammle ich die Stellen:
http://arktur.de/Wiki/index.php?title=Fog#Slackware_auf_Arktur

Gruß Jürgen

Am 23.05.2012 16:58, schrieb Martin Hülsmann:
> Hallo Helmut und Jürgen,
>
> wenn es aber nun Probleme mit der Adressvergabe gibt und das Argument
> mit dem Datendurchsatz nur am Rande interessant ist, kann ich auch die
> 3er-Karte stilllegen und alle Adressen aus dem 192.168.16.0/20-er Netz
> nehmen. Für die fest installierten Rechner zwacke ich davon einfach
> einen Adressbereich ab.
Wenn Du nur drahtgebundene Clients hast, die nicht voreinander geschützt
werden müssen, ist das im Zeitalter von switches vernünftig.

Ein WLAN sollte sich jedoch immer in einem eigenen Subnetz befinden.
Wenn Du manageable/smart switches hast, ist es verhältnismäßig einfach,
hierfür VLANs einzurichten.
Besonders einfach ist es, wenn alle von gleichen Herstellen kommen und
den gleichen Firmwarestand haben.

Wenn Du weißt, auf welchen Ports die Geräte mit den Adressen
192.168.3.*/24 und 192.168.16.*/20 stecken, wäre dies vielleicht noch
weniger Aufwand und Du hättest vor allem durch die Verkleinerung der
Broadcastdomäne wirklich einen Performancegewinn.
>
> Es kommen ohnehin noch eine Reihe netzwerkfähiger Geräte im
> Automatisierungslabor hinzu, die auch alle über eine eigene Adresse
> angesprochen werden wollen (ca. 70 Automatisierungsgeräte), und da
> wird mir der 3er Bereich dann doch zu eng.
>
> Das mit den 2 Netzwerkkarten scheint mir doch eher bei physikalisch
> getrennten Netzen sinnvoll zu sein (was bei mir ja nicht der Fall ist,
> es läuft alles "über den gleichen Draht").
>
> Es stellt sich jetzt noch die Frage, ob es (aus Vereinfachungsgründen)
> ausreicht, meine dhcp-MAC-Vergabe-Liste einfach anzupassen und
> anschließend aus der 3er-Karte den Stecker herauszuziehen. (dann
> brauche ich die Karte nicht zu deinstallieren, meine Fernwartung über
> 192.168.3.1 würde auch funktionieren, weil capella ja so herrlich routet).
>
> Dann müssten die dhcp-Anfragen doch ausschließlich über die 16er Karte
> laufen?
Ja, denn ein Broadcast wird nicht geroutet.

Obwohl beide Netze physikalisch verbunden sind, werden Pakete z.B. von
192.168.3.22 nach 192.168.16.22 auch geroutet. Oder gefiltert!
>
>
> Und der Aufwand für mich wäre halbwegs überschaubar, ich bräuchte nur
> 2-3 Dateien anzupassen (/etc/dnsmasq.d/dhcp.conf und die Dateien für
> die squid-Anmeldung, soweit sie über die IP-Adresse geregelt sind).
Ich vermute mal, dass Du 192.168.1.0/24 als Subnetz für den externen
Router benutzst und das "große" Subnetz deswegen bei 192.168.16.0 beginnt.
Wie wärs, wenn Du für dies ändertest?
Dann könntest Du 192.168.0.0 für das interne Netzwerk benutzen mit der
Subnetzmaske, die Du benötigst.
>
>
> Am 23.05.2012 16:42, schrieb Helmut Hullen:
>> Hallo, Juergen,
>>
>> Du meintest am 22.05.12:
>>
>>>>
>>>>              -192.168.3.1/24--
>>>> Capella----|                 |------LAN mit allen Rechnern
>>>>              -192.168.16.1/20-
>>>>
>>>> d. h. die beiden "Subnetze" sind nicht physikalisch getrennt. Ich
>>>> wollte nur die Netzlast auf 2 Karten verteilen, die 3er-Karte
>>>> versorgt den Bestand an fest verkabelten Rechnern, die 16er Karte
>>>> eine Vielzahl an mobilen Geräten, etliche davon privat.
>>> Der DHCP-Request des Client erreicht als Broadcast definitiv beide
>>> Netzwerkkarten.
>>
>>
>>> diese Konstruktion macht Dir möglicherweise mehr Ärger als Freude.
>>
>> Das Bild ist etwas ungenau; das LAN besteht aus 2 Teilnetzen.
>>
>>> Hast Du messbare Indikatoren, die Dich davon abhalten, den
>>> Datenverkehr über eine Netzwerkkarte abzuwickeln?
>>
>> Datendurchsatz. Auch bei einer Gigabit-Karte ist der Durchsatz begrenzt;
>> über 2 Karten geht nun mal mehr als über eine.
>>
>> Hinzu kam: das Netz 192.168.3.0/24 war schon fast voll mit den
>> schuleigenen Rechnern, "irgendwie" musste sowieso ein weiterer
>> Adressbereich freigeschaufelt werden. Und wenn an einer Berufsschule
>> auch private Smartphones sich einloggen dürfen, dann reicht ein weiterer
>>   x.y.z.0/24-Bereich nicht lange.
>>
>> Erhoffter Zusatznutzen: einfache Steuerung z.B. von Berechtigungen, je
>> nach IP-Adresse. Aber da hakt es ja noch irgendwo.
>
> und da sind ja noch andere Mechanismen im Spiel, z. B. die
> squid-Anmeldung und damit die Notwendigkeit, über einen Nutzeraccount
> zu verfügen.
>
> Und da ich jetzt über eine professionelle W-LAN-Umgebung verfüge
> (deren Möglichkeiten ich noch gar nicht ganz durchschaue), ist meine
> frühere Idee, mit RADIUS zu arbeiten, auch noch nicht im Papierkorb
> gelandet. Ist nichts dringendes, möchte ich aber weiterverfolgen.
Bei mir ist RADIUS inzwischen im Papierkorb gelandet! Mit Windows Server
ließ sich damit vollkommen stressfrei ein "single sign on" für
WLAN-Clients realisieren. Mit Arktur habe ich es nicht hinbekommen, dass
der WLAN-Schlüssel mit den Informationen aus /etc/passwd und /etc/shadow
ausgehandelt wird. Und LDAP haben wir ja nicht mehr.

Das "professionelle" WLAN ist in ein VLAN verbannt und nur durch einen
IPCop mit Zerina und OpenVPN mit dem LAN verbunden.
"Blau" ist wie vorgesehen für das WLAN und "Rot" für das LAN. "
An "Grün" gehe ich nur für Wartungsarbeiten und die Verwaltung der
Zertifikate mit einem Crosskabel.

Man beachte, das OpenML in der aktuellen Version 5.10 trotz LDAP den
IPCop mitsamt der WLAN-Zugangskontrolle auf zusätzliche Hardware
ausgelagert hat. Da hierfür "Sperrmüllqualität" ausreicht, finde ich
diese Entscheidung im Sinne von "reduce & simplify" gut.
Bei mir ist der IPCop zurzeit mit einem Duron900 mit 256 MB und 3 100
MBit-Netzwerkkarten eher überdimensioniert.
Mit richtig vielen WLAN-Clients mag das anders werden.

Der Flaschenhals wird bei den "Kommunikations-" (besser
Unterhaltungs-)Bedürfnissen unserer SchülerInnen als WLAN-Kunden eher
die WAN-Verbindung sein.
>>
>> Viele Gruesse!
>> Helmut
>>
>> _______________________________________________
>> schan-user mailing list
>> schan-user@xxxxxxxxxxxxxxxxx
>> http://www.heise.de/bin/newsletter/listinfo/schan-user
>


_______________________________________________
schan-user mailing list
schan-user@xxxxxxxxxxxxxxxxx
http://www.heise.de/bin/newsletter/listinfo/schan-user

 « Vorige im Thread  Dieser Thread  Nächste im Thread » 

 

seitenanfang


 

news about wissen files archive hilfe suchen  
kontakt letzte änderung: 23.05.2012