• Jan
  • 22
  • 2010

Brückenbau

Posted by okami In Howtos | No Comments »

Was sind Bridges und wozu sind sie da

Bridges übertragen den Verkehr zwischen multiplen Netzwerkschnittstellen. Beim Bridgen wird der Traffic nur bis zu Netzwerk-Schicht verarbeitet und von da ab weitergeleitet. Damit schafft man eine einfache und sichere (bei Integration von Filtermechanismen etc.) Verbindung für homogene Netzwerke, wozu lediglich ein PC mit 2 Netzwerkkarten, ein Linux OS mit Kernel 2.2 oder höher und das Tool brctl erforderlich sind.

Arbeitsweise

Jede Bridge arbeitet nur über bestimmten Ports, sodass das Ansprechen von einem Port, ein transparentes Forwarding zu dem bzw. den anderen zur Folge hat. Daraus ergibt sich, dass eine solche Bridge für das Netzwerk unsichtbar ist, so z. B. von traceroute nicht erfasst. So bleiben auch die ARP-Pakete unberührt, mittels welchen zu IP gehörende MAC-Adressen übermittelt werden (was also keinen Schutz vor ARP-Poisoning bietet). Durch das cachen von Adressen, welche in den Frames stehen, kann die Bridge aber auch den Switch immitieren.

Spanning Tree Protocol

Ein weitere wichtiger Teil dieses HOWTOs ist das Multiple STP-Protokoll. Ethernet Bridges können so zusammen arbeiten um mittels des IEEE 802.1d SPT noch größere und leistungsstärkere Netze zu schaffen. Das Protokoll ist z.B. zuständig für das Wählen der kürzesten Verbindung und das Ausschalten der Loops. Bridges kommunizieren über BPDUs (Bridge Protocol Data Units), welche durch die Ethernet Zieladresse 01:80:c2:00:00:00 erkannt werden können. Da dieses Protokoll einen Standard darstellt, interagiert er problemlos mit anderen Linux-Bridges und Bridges von Drittanbietern.

Vorbereitungen

Zunächst installiert man ein OS wie z.B. GNU/Linux Debian mit Kernel 2.6.6-1-386 und richtet in diese Umgebung 2 Netzwerkkarten ein. Nun muss man beide Netzwerkadressen welche möglicherweise durch die Einrichtung gesetzt wurden entfernen und die Konfiguration der Bridge beginnen.

Einrichten der Bridge

Mittels


brctl addbr <bridgename>

muss man nun min. eine logische Bridginginstanz erstellen, welche die eingebauten Netzwerkkarten virtuell verbindet. Da nun eine Verbindung für die Netzwerkkarten, aber noch keine Netzwerkkarten definiert worden sind, geschieht das nun mit dem Befehl


brctl addif <bridgename> <device>

Wenn nun beide Netzwerkkarten auf diese Weise der Bridginginstanz zugewiesen wurden, sollte die Bridge fertig sein.

Starten der Bridge

Bevor man nun die Bridge in Betrieb nimmt, muss man klären welchen genauen Zweck sie erfüllen so:

  • einfaches Verbindenungsglied von Netzwerken, sodass keine IP für den Host vergeben wird (wodurch er vor diversen Angriffen, allerdings nicht vor physikalischen Angriffen geschützt ist)
    • ifconfig <bridgename> up
  • oder als Teil des entstehenden Netzes, sodass die Bridge (also bei Netzwerkkarten) nach außen als ein virtuelles Interface agiert und somit eine IP zugeteilt bekommt
    • ifconfig <bridgename> <ip-number> netmask <netmask-number> up

Nun sollte die Bridge soweit sein betrieben zu werden.

Testen der Bridge

Um die Funktionalität der Bridge zu kontrollieren und noch expliziter zu konfigurieren sind verschiedene Optionen im brctl-Tool implementiert:

  • brctl show <bridgename>: zeigt diverse Informationen zu der eingerichteten Bridgeinstanz
  • brctl showmacs <bridgename>: listet alle bisher gecacheten MAC Adressen auf
  • brctl setageingtime <bridgename> <time>: nachdem diese Zeit verstrichen ist und kein Frame von einer bestimmten Adressen empfangen wurde, löscht die Bridge den entsprechenden Eintrag aus der “Forwarding DataBase” (fdb)
  • brctl setgcint <bridgename> <time>: legt den Intervall fest, mit welchem nach timed-out Einträgen in der fdb gesucht wird.
  • brctl stp <bridgename> <state>: kontrolliert das STP der Bridge
  • brctl setbridgeprio <bridgename> <priority>: setzt die Priorität der Bridge auf
  • brctl setfd <bridgename> <time>: setzt die Verzögerungszeit für das Forwarding in Sekunden
  • brctl sethello <bridgename> <time>: setzt die “bridge hello time”
  • brctl setmaxage <bridgename> <time>: setzt TTL der Bridge
  • brctl setpathcost <bridgename> <port> <cost>: setzt die Port-Cost
  • brctl setportprio <bridgename> <port> <priority>: setzt die Port-Priorität

Read More

  • Dez
  • 28
  • 2009

Tuning TCP Linux

Posted by okami In Featured, Howtos | No Comments »

Das Tutorial basiert auf dem TCP Tuning Linux Guide & TCP Tuning for WAN und ist im wesentlichen eine Übersetzung mit ein paar zusätzlichen Erläuterungen

LINUX

Da es  unterschiedliche TCP Optionen in denKernelversionen 2.4. und 2.6. gibt, soll es uns im folgenden ausschliesslich um Kernelversionen der 2.6 – Familie gehen. Prinzipiell finden sich alle Parameter in der Datei ip-sysctl.txt die den Kernelsourcen beiligt. Um die TCP Einstellungen zu ändern, werden die Einträge entweder in die /etc/sysctl.conf eingefügt oder entsprechend abgeändert und mit “sysctl -p” übernommen.

Als erstes erhöhen wir  den zu klein geratenen TCP buffer:

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
sysctl net.ipv4.tcp_sack =  0

# für Gigabitadapter
net.core.netdev_max_backlog = 2500
#für 10 Gigabit
net.core.netdev_max_backlog = 30000

Darüber hinaus überprüfen wir ob folgende Werte auf 1 gesetzt sind:

sysctl net.ipv4.tcp_window_scaling
sysctl net.ipv4.tcp_timestamps

Mit der Kernelversion 2.6.13 unterstützt Linux sogenannte “pluggable congestion control algorithmen” . Welche Algorithmus Verwendung finden soll, wird mittels net.ipv4.tcp_congestion_control festgelegt. Abhängig von der Kernelversion sollte er default auf cubic oder reno stehen. Um nachzuschauen welche Algorithmen der Kernel unterstützt:

sysctl net.ipv4.tcp_available_congestion_control

Von Hause aus stehen mehrere Algorithmen zur Verfügung, die Unterstützung muss beim kompilieren des Kernel berücksichtigt werden. Weiterführende Informationen und Arbeitsweise der einzelnen Algorithmen findet sich hier. Ein Benchmark über die unterschiedlichen Algorithmen mit diversen MTU Werten findet sich hier für eine Teststellung im 10GBit Bereich. Der Algorithmus wird dann beispielsweise durch

sysctl -w net.ipv4.tcp_congestion_control=htcp

gesetzt.

Um den Durchsatz zu erhöhen können wir ebenso die die Queue des Interfaces anpassen:

ifconfig eth0 txqueuelen 10000

Letzteres ist einzig für Gigabit Ethernet Adapter zu empfehlen, darüber hinaus ist an dieser Stelle mit Nebenwirkungen zu rechnen: wie z.B. dass die einzelnen Streams nicht mehr gleichwertig das Medieum teilen.

Jumbo Frames und die Spielerei mit den MTU-Werten:

Laut IEEE 802.3 haben Frames im Ethernet eine maximale Größe von 1518 Byte. Das ergibt beim Einsatz von IP eine MTU Größe von 1500 Byte. Als Jumbo Frames werden nun  Frames mit einer Größe über 1518 Byte bezeichnet. Jumbo Frames sind ersteinmal nicht standardisiert. Jeder Netzwerkhersteller implementiert hier seinen eigenen “Standard”. Typischweise werden Framegrößen von 9 kB, 12kB, 14 kB und 16 kB verwendet. Der Einsatz von Jumbo Frames soll die Interruptlast der beteiligten Stationen verringern. Ein weiterer positiver Effekt, der großen Frames, ist der kleinere Protokolloverhead.

Damit die Übertragung von Jumbo Frames funktioniert, müssen alle Switche und Router zwischen Sender und Empfänger diese unterstützen. Und hier fangen die Probleme an. Da kein Standard existiert, ist die Unterstützung der Hersteller recht unterschiedlich. Auch zwischen den einzelnen Produkten eines Herstellers gibt es oft Unterschiede bei der Behandlung von “Jumbos”. Cisco unterstützt Jumbo Frames nur bei bestimmten Modulen und teilweise nur auf bestimmten Ports von Modulen. Hier ist also Lesen angesagt. Sinnvoll ist der Einsatz von Jumbo Frames unter Umständen in einem Cluster Server, da hier die Member des Clusters über eine kontrollierte Infrastruktur kommunizieren. Switche, Router und Netzwerkkarten die keine großen Frames kennen, verwerfen die Jumbos einfach. In den Fehlercountern tauchen diese dann als Giants auf.

Read More

  • Dez
  • 21
  • 2009

This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary

Posted by okami In Datenbanken | No Comments »

Als ich heute ein Backup einspielen wollte, um eine Replikation erneut aufzusetzen, stolperte ich über folgenden Fehler:

ERROR HY000: This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable)

Wenn wir eine gespeicherte Funktion erstellen, müssen diese entweder als deterministisch deklariert oder es muss festgelegt werden, dass sie keine Daten modifizieren. Andernfalls kann sie für die Datenwiederherstellung oder Replikation Unsicherheiten bergen … so dass MySQL Handbuch. Zur Lockerung der  Bedingungen für die Erstellung einer Funktion setzen wir die globale Systemvariable log_bin_trust_function_creators auf 1. Diese Variable hat den Standardwert 0.

  1. > SET GLOBAL log_bin_trust_function_creators = 1;

Darüber hinaus können  wir diese Variable genaus als Option beim Start des MySQL Servers übergeben –log-bin-trust-function-creators=1. Mehr Informationen gibt es [hier]. Und dann klappt es auch mit dem Einspielen des Backup :-) …

Read More

  • Dez
  • 06
  • 2009

Mailserver Howto für Debian

Posted by okami In Mailserver | No Comments »

Nachdem sich Debian immer weiterdreht, habe ich meine  Mail- und Antispamhowtos zusammengefasst und mal auf den aktuellen Stand gebracht. Ich beziehe mich zwar im wesentlichen auf Debian, allerdings dürften abweichend von der Grundinstallation der Pakete, dieses Howto auf jeden anderen Linuxsystem ebenso funktionieren. Als Mailsystem kommen cyrus und postfix zum Einsatz, zur Authentifizierung der saslauthd. Zum Filtern und Virencheck setze ich Amavisd-new, Spamassassin, Razor, DCC und Pyzor ein.

Stand: 06.12.2009

ToDo – List:

- Authentifizierung (unterschiedliche Mechanismen)
- Usermanagement (Ldap)
- Usermanagement (MySQL)
- IMAP Backup

Read More

  • Aug
  • 05
  • 2008

Postfix, Spamassassin, Amavisd und Cacti unter Debian (Teil3)

Posted by okami In Mailserver | Kommentare deaktiviert
Postfix, Spamassassin, Amavisd und Cacti unter Debian (Teil3)

Die Version des Artikels ist veraltet, zur aktuellen Version >> hier <<

Heute soll es uns darum gehen Cacti an den Start zu bringen. Cacti soll uns den Überblick über unser Filteraufkommen zeigen. Ich setze dabei eine funktionierende Postfix, Amavis und Spamassassin Installation vorraus, sowie einen funktionierenden Apache und MySQL Datenbank.

Read More

  • Jul
  • 19
  • 2008

Canon EOS 400D unter Linux

Posted by okami In Fotografie, Howtos, Sonstiges | No Comments »

Nachdem ich gesehen habe, dass für einfache Fotospielereien mit meiner EOS 400D Gimp völlig ausreichend ist, habe ich mich mal ein wenig umgeschaut, wie man denn Kamera mit Photomanagement unter Linux auf die Reihe bekommt. Das ganze gestaltete sich im Endeffekt auch relativ einfach. Meine Wahl viel auf Digikam und Gimp. Digikam zum verwalten der Fotos und Gimp zum bearbeiten. Ich bin aber immer noch auf der Suche nach Alternativen für digikam.

Read More

Page 3 of 6«12345»...Last »

Kategorien