Seit einigen Wochen habe ich nun mehrere Internetanschlüsse zuhause: Neben dem von der Telekom etwas vernachlässigtem DSL nenne ich nun einen über 10x schnelleren Zugang über das Kabelnetz mein eigen. Beide treffen auf einem pfSense zusammen, welche sich mit Load-Balancing über beide Leitungen beschäftigt.

Ursprünglich hatte ich an drei Traffic-Klassen gedacht:
High-Prio
Einige Dinge müssen laufen – schnell. Hierzu zählen z.B. Videostreams, Daten von Computerspielen, etc. Diese Daten werden wegen der besseren Bandbreite und Latenz wann immer möglich über das Kabelnetz gesendet. Lediglich bei einem Ausfall des Kabel-Internet werden die Daten per DSL übermittelt. Die Unterscheidung erfolgt bei den meisten Fällen über das Protokoll – RTSP, Gameserver & co lassen ich am Port schnell erkennen. Lediglich einige HTTP-Streams werden über die Ziel-IP zugeordnet, da ich nur wenige dieser Streams verwende hält sich der Aufwand in Grenzen
Downloads
Auch wenn es verlockend ist: Downloads auf der Kabel-Leitung sind keine gute Idee. Einerseits würden diese ggf. High-Prio-Pakete beeinträchtigen, andererseits hat mein Kabel-ISP im Kleingedruckten einige Traffic-Limits stehen, die ich ohnehin ankratzen werde. Entsprechend gehen Downloads wann immer möglich über DSL. FTP wurde komplett zugeordnet, bei HTTP ist das ganze etwas schwerer. Zwar dürfte es möglich zein einen Proxy vorzuschalten, der bei jedem Aufruf per HEAD die Dateigröße überprüft und ggf. umleitet, jedoch ist das mit den Prozessoranforderungen derzeit nicht mit meiner Hardware machbar. Zum Glück kommen die meisten meiner Downloads von den Distributionsservern einiger Linux-Distributionen, welche sich über die IP zuordnen lassen.
Rest
Für alles andere hatte ich Balancing vorgesehen. Die Anfragen werden – sofern beide Leitungen verfügbar – über beide verteilt. Am liebsten wäre es mir, wenn ich noch ein passendes Verhältnis 10:1 festlegen könnte, dies scheint mit pfSense derzeit allerdings noch nicht möglich zu sein, daher ein einfaches Round-Robin.

Was in der Theorie OK aussieht zeigt in der Praxis beim Rest leider ein paar Schwächen – die größte nennt sich HTTP. Das eigentlich ist noch nicht einmal HTTP, sondern eher die Entwickler diverser Webapplikationen. HTTP sendet im Prinzip (keepalive lasse ich mal weg – das hält auch nicht ewig) für jedes Objekt der Webseite und jede neue Seite einen eigenen Aufruf. Da jeder Aufruf auch eine eigene TCP-Verbindung generiert werden die Aufrufe auch über die Internetleitungen verteilt und schlagen daher mit unterschiedlichen IPs beim Anbieter auf. Bis hier ist ebenfalls noch kein Problem: Sitzungsdaten werden üblicherweise über Cookies oder Request-Variabeln zugeordnet. Leider gibt es die Tendenz, dass Web-Entwickler versuchen tolle neue Funktionen zu schaffen ohne sich über Nebenwirkungen Gedanken zu machen. Inzwischen ist es daher in Mode gekommen die Sitzung an eine IP zu binden. Das hat den Vorteil, dass ein Angreifer, welche das identifizierende Cookie oder die Variable in Erfahrung bringt, mehr Aufwand treiben muss um die Sitzung zu übernehmen. Da ich über mehrere IPs eintreffe bedeutet es aber auch, dass ich diese Webseite nicht nutzen kann. Viele Projekte bieten beim Login eine Einstellung um ggf. die IP-Bindung abzuschalten – in den meisten Fällen auf Grund der Tatsache, dass AOL lange zeit alle Kunden über ein solches System mit mehreren IPs abwickelte. Leider haben einige wichtige Dienste wie z.B. meine Bank zwangsweise einen IP-Check – hier kann ich nur per Hand spezielle Regeln erstellen oder über einen Tunnel arbeiten. Hauptsache wir haben was für die „absolute Sicherheit“(tm) getan. Vorallem frage ich mich, was die Dienste machen wenn jemand die IPv6-Privacy-Extensions entdeckt – hierbei geht der Rechner dann absichtlich mit immer wieder wechselnden IPs ins Netz… Sicherheitstechnisch sehe ich jedenfalls keine Notwendigkeit: Wer die möglichkeit hat Cookies abzufangen kann auch die IP des Rechners fälschen oder nutzen…