Jens Benecke schrieb: > > Gucken in /usr/share/doc/iproute/ip-cref.* unter dem Stichwort ".. > Ich habe rudiment�re Ahnung von Routing (will sagen, Dijksrta & Co
Wichtiger wird es sein, mit iptables zurecht zu kommen. Das umfangreichste Howto dazu ist meines Wissens: http://freshmeat.net/projects/iptables-tutorial/ Zu "ip" gibt es neben .../share/doc/iproute noch www.lartc.org. "ip rule" ben�tigst Du nur f�r die offiziellen IPs der Uni, die durchgereicht werden m�ssen. Dabei geht beides: die Verteilung des Traffics komplett mit "ip rule" steuern oder das meiste mit iptables machen bzw. dort markieren und dann "ip rule" nur das Notwendigste machen lassen. > SSH und anderer interaktiver Kram usw. soll weiterhin �ber die TUHH > laufen, weil die so gute Latency-Zeiten und sch�n schnelle pings hat > und diese Dienste wenig bis kaum Traffic erzeugen. Ich w�rde die Logik genau umgekehrt ansetzen: der gesamte Traffic geht standardm�ssig �ber die Hansenet-DSL und nur explizit ausgew�hlter Verkehr geht �ber die Uni-SDSL. Das erscheint mir vom Konzept flexibler und kontrollierbarer. Dann k�nnen die Leute treiben, was sie wollen und es werden nur die Dienste �ber die Uni gef�hrt, deren Traffic und Inhalt den vorgegebenen Bedingungen entspricht. Auf den Uni-Uplink wird nur geroutet, f�r die Hansenet-DSL macht man SNAT in der POSTROUTING Table. > Die Alternative ist, da� wir einfach 2 Gateways zur Verf�gung stellen > und die Leute ihren Default-Gateway selbst aussuchen lassen. Das sowieso. Und zwar am besten, indem Du Gateway-Konzeptregel No. 1 folgst, die lautet "Netzwerkkarten, Netzwerkkarten, Netzwerkkarten". Ich kann immer nur mit dem Kopf sch�tteln, wenn ein Gateway gerade mal eine Karte f�r Intranet und eine f�r Extern hat. Immer besser noch eine Karte ungenutzt in petto haben. So kann man ohne den laufenden Betrieb zu unterbrechen erweitern, umbauen, noch eine DMZ aufmachen, etc. Ausserdem sollte jeder Uplink eine eigene Netzwerkkarte haben und Router/Modem sollten direkt �ber eine separate Line dran h�ngen. D.h. Kreuzkabel oder separater Mini-Hub. Bitte auf keinen Fall so einen Murks, beide Router und das Gateway oder gar noch das ganze Intranet an einen gemeinsamen Hub zu h�ngen. Zumal das sowieso ulkigen Spass mit icmp redirects und anderen Effekten bringen w�rde. Ich w�rde den Leuten aber auf jeden Fall auch eine Wahlm�glichkeit geben: und zwar gegen die Uni-Linie. Wer Dienste oder Ziel-IPs (z.B. Uni-intern), die standardm�ssig �ber den Uni-Uplink laufen w�rden, �ber Hansenet nach draussen f�hren m�chte, sollte das ausw�hlen k�nnen. Und zwar nicht �ber verschiedene Gateways, sondern �ber ein separates logisches (nicht physikalisches) Netz mit RFC 1918-IPs. Der Benutzer kann so durch die Wahl der eigenen IP festlegen, wie die gesonderten Dienste im einzelnen geroutet werden. Es ist f�r die meisten Leute einfacher einen Dienst an eine bestimmte Quell-IP zu binden, als diensteorientiert ein bestimmtes Ziel-Gateway anzusteuern ;-) -- [EMAIL PROTECTED] -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
