Technik

Das meiste, was diese Woche hier im Blog passiert ist, passierte natürlich nicht ohne Grund.

Manch einer mag es bereits vermutet haben, manch anderer hat es schon gemerkt, sogar unsere Webseite kennt es schon länger:

VPN Gateway Firewall

Um dies zu bewerkstelligen legt man einfach im Kundeninterface eine entsprechende Firewall-Regel an, stellt den Filter auf "Pakete anonymiseren" und startet den VPN-Tunnel neu. Voila, alles fertig!

Natürlich gibt es hier viele Kritikpunkte, die es besonders im Bezug auf Tor zu berücksichtigen gibt. So ist unsere Implementierung eine denkbar bequeme, aber niemals als eine Vollweritge zu betrachten - immerhin werden die Daten auf unserem VPN Gateway Router unverschlüsselt verarbeitet, sprich sie kommen entschlüsselt aus dem VPN-Tunnel, werden geroutet und anschließend erst über Tor wieder verschlüsselt übermittelt, bleiben für uns (und somit im weiteren Schritt auch für Strafverfolgung o.ä.) jedoch einsehbar. Auch ist noch nicht ganz klar inwieweit wir als Dienstleister hier einer Protokollierungspflicht unterliegen (Dazu mehr, sobald die Situation eindeutig geklärt ist).

Wer alle Vorteile von Tor nutzen will, wird um die Installation eines lokalen Clients nicht herum kommen. Wer aber unabhängig vom Computer an dem er sitzt (sondern nur von der VPN Gateway-Verbindung abhängig) selektiv, spontan oder allgemein Tor nutzen will, für den wird diese Erweiterung sicherlich nützlich sein...

... es kostet auch nichts extra. Und selbst, wenn ich nicht der Tor-Typ bin, bin ich der Meinung, dass es doch sehr schön ist solch "Zwischending" zu haben. Im aktuellen Marketing hat das Feature auch bereits seinen Platz gefunden.

Nachdem ich am Montag von meinem "transparenten SOCKS5-Proxy" berichtete gibt es heute nun die passenden Sourcen zu dem Projekt.

Technisch wie bereits gesagt nicht ganz ein novum, allerdings von zumindest einem Kommentator heiß erwartet. Doch wie funktioniert das Programm eigentlich? Recht simpel:

1. Aktuelle Version aus dem SVN auschecken
2. "make" ausführen (ggf. Makefile bzgl. libevent anpassen) und das Programm kompilieren
3. transocks_ev ausführen:
   
   ~#> ./transocks_ev -p 1211 -S IP-Addresse des SOCKS-Server -s Port des SOCKS-Server
   
4. iptables anpassen, z.B. so:
   
   ~#> iptables -t nat -A PREROUTING -p tcp -d 207.46.0.0/16 -j REDIRECT --to-ports 1211
   
5. Fertig! ggf. zwischendurch die README lesen...

Manchmal bin ich echt geneigt den Kopf auf den Tisch zu hauen.

In den vergangenen 2 Tagen durfte ich mich wieder mit einer .de-Domain rumplagen, die von der DeNIC partout nicht auf den aktuellsten Stand gebracht werden wollte. Alle Update-Versuch wurden stets mit einem "Nameserver Error" quittiert.

Natürlich kann das mal passieren, allerdings hatte ich die Nameserver manuell zu diesem Problem mindestens 10 Mal befragt und es wäre nicht so, dass es sowas nicht schon mal gab (allerdings war ich darmals noch wesentlich grüner ).

Heute morgen hatte ich dann die Nase voll als sich unser Robot mal wieder mit einem Fehler meldete und bin wieder von Hand an die Sache gegangen. Aber was hab ich überhaupt gemacht?

1. "Einfaches" Update von Hand - sprich die Daten wie sie aktuell sind ohne Änderungen an die DeNIC übermittelt.
   Fehler: Nameserver error [ERROR: No SOA record found on server (ns1.tiggersystems.info, ns3.tiggersystems.info)]
   
2. Aus Spass mal "ns3.tiggersystems.info" aus der Liste der Nameserver genommen.
   Fehler: Nameserver error [ERROR: No SOA record found on server (ns1.tiggersystems.info, ns2.tiggersystems.info)] :eek:
   
3. Resigniert und "ns3.tiggersystems.info" wieder auf die Liste der Nameserver gesetzt. Funktioniert! :eek:

Wohlgemerkt betreffen diese Einstellungen nur die Daten die wir an die DeNIC übermitteln, Daten auf unseren DNS-Servern wurden hierbei nicht geändert (wobei das sowieso zu kurz für das Rehash-Interval war) und somit hätte Schritt 2 so oder so fehlschlagen müssen, allerdings mit einem anderen Fehler.

Nachdem eine ehemalige Kundin mich vor ein paar Tagen wieder an "den Zwiebelrouter" (TOR, The Onion Router) erinnert hat, betreiben wir nun auch wieder ein kleiners TOR-Relay mit dem Namen "tiggersWelt" - sprich: Wir leiten Traffic innerhalb des Netzwerkes weiter, sind aber kein "Exit Node", der die Daten in das "normale" Internet überführt.

Wir hatten ein ähnliches Projekt bereits vor etwas mehr als einem Jahr, haben es aber nach ein wenig unbehagen und einem Hardware-Ausfall eingemottet. Das aktuelle Projekt bewegt sich noch in einem ähnlichen Rahmen, ist aber für mehr vorgesehen - mehr dazu später, bis dahin darf gemutmaßt werden.

Gestern Nacht hatte ich wieder "Programmier-Wut". Dabei ist etwas entstanden, was ich gerne als "fork" bezeichne, allerdings wäre "offener Ideenklau" hier sicherlich angebrachter, denn von 335 Zeilen Programmcode sind nur noch ca. 10 Zeilen aus dem ursprünglichen Programm - und die haben nichtmals wirklich was mit dem eigentlichen Abluaf zu tun

Herausgekommen ist dabei (wie schon in der Überschrift vermerkt) ein transparenter SOCKS5-Proxy, der komplett im Userspace läuft und bequem via IP-Tables konfigurierbar ist. Anders als sein Vorgänger verzichtet meine Implementation auf eine externe SOCKS-Library und den fork() pro eingehender Verbindung, im Gegenzug setze ich zum ersten mal libevent zur Verwaltung der Ereignisse auf den Sockets ein.

Da die ursprüngliche Version keinerlei Lizenz-Informationen beinhaltet, warte ich noch auf Rückmeldung vom Original-Author. Wenn der sein gründes Licht gibt, wird das ganze OpenSource. Bis dahin bereite ich den Einsatz auf unserer Seite als Erweiterung eines bestehenden Produkts vor

Es klingt irgendwo schon ein wenig skuril: Ein Kunde will gerne seine Webseitenzugriffe in Echtzeit auf einem eigenen System auswerten und fragte und daher nach einer Möglichkeit die Access-Logs für ihn an seine Server zu "pushen".

Es gibt hier sicherlich viele Wege so etwas zu realisieren, so war neben einer einfachen TCP-Verbindung über die die Daten in Text-Form geschickt werden auch eine direkte Anbindung an seine MySQL-Datenbank im Gespräch. Letzten Endes haben wir uns dann aber doch vorerst für einen Transport über Jabber/XMPP entschieden.

Um den Datenverkehr zu gering wie möglich zu halten, soll unser Logging-Backend direkt auf einem Jabber-Server beim Kunden einloggen und die Verbindung wird zusätzlich komprimiert. Die Daten werden dann ein einem eigenen Namespace umschlossen von eimem <message>-Block ihr Zuhause finden.

Momentan wird das Projekt noch geplant, aber ich bin jetzt schon ganz wild und gespannt was daraus wird.