Homebanking unter Linux

Seit geraumer Zeit nutzen meine Frau und ich ein Haushaltsbuch auf App-Basis, welches uns eine Auswertung unserer Einnahmen und Ausgaben nach Kategorien ermöglicht. Das ganze klappt auch recht gut mittlerweile. Wer sich dafür interessiert: Die App heißt „Unser Haushaltsbuch“, von einem deutschen Entwickler, es werden keine Online-Services genutzt, zum Synchronisieren von mehreren Nutzern kann man ein verschlüsseltes Sync-File bei Google Docs ablegen.

Was das Tool nicht nicht kann: einen Überblick über unsere Konten geben, am besten mit einer Langzeitanalyse. Das ist auch nichts, was ich an die Sparkasse oder Data Buhl und Co. in die Cloud auslagern wollen würde. Und dafür jedesmal eine VM oder ein Windows hochfahren finde ich ein wenig mit Kanonen auf Spatzen geschossen.

Prinzipiell ist Finanzsoftware unter Linux ähnlich stiefmütterlich behandelt wie einst Spiele unter Linux und auch wenn ich kein Java-Freund bin: Die Software für die ich mich entschieden habe, läuft und liefert einfach, was ich haben will: Zahlen und Diagramme.

Screenshot: willuhn.de

Nach einiger Suchererei nach Anwendungen, die ähnlich wie WISO MeinGeld oder StarMoney mir meine Kontenhistorie lokal verfügbar machen, bin ich schließlich bei Hibiscus gelandet. Das ganze ist ziemlich rund, wenn man ein paar kleine Copy-Paste-Aktionen und ein bisschen Doku lesen nicht abschreckend findet. So habe ich unsere kompletten Konten zusammengefasst und kann jetzt auch bequem alle Umsätze auf dem heimischen Rechner sehen, filtern, kategorisieren und z.B. einen generellen Trend der Kontenentwicklung erkennen etc.

,♥

Was mir viel mehr aufstößt als der Heartbleed-Bug ist die löchrige Infrastruktur, die nun zutage tritt und sich in meinem Kopf etwa folgender Kommentar bildet: „Was wenn der Ernstfall eintritt?“ – „Der darf nicht eintreten!“ – „Okay! Dann ist ja alles gut!“
Weiterlesen

Linux developers are used to being told ‘no’

Linux developers are used to being told ‘no’, then doing it anyway.

OMG! Ubuntu!

Ich kann immer noch nicht verstehen, wieso es Lovefilm & Co. nicht für Linux gibt. Wie man bei Steam und auch bei Android sehen kann, ist „runs on Linux“ nicht gleichbedeutend mit kostenlos. Und wie man auch sehr wohl in beiden Welten sehen kann, auch nicht gleichbedeutend mit der Abwesenheit von DRM.

Android hat das Konzept im Mobile-Sektor mit GPL-Wurzeln umgesetzt. Steam auch. Apple nutzt BSD, was auch eine Open Source Software ist. Im Fall von Apple wird davon im heutigen iOS und OSX vermutlich nicht mehr so viel sichtbar sein, aber sei es drum.

Allerdings: gerade beim Thema Abonnement-Dienste werde ich mir aber nicht wirklich einig  mit der FSF, die der Legitimität dieser Geschäftsmodelle extrem kritisch gegenübersteht. Ich habe keine Probleme mit dem Mieten von Zugang zu Musik oder Filmen. Erst recht nicht, wenn der Zugang mich nicht einschränkt, wie es bei DRM und gekauften Medien der Fall wäre. Denn wenn ich Dinge kaufe, bestehe ich auf Einhaltung des Erschöpfungsgrundsatzes. Und ich will das Produkt ohne Einschränkungen (DRM) nutzen können, konvertieren etc.

Ich bin froh, dass es Menschen gibt, in bestimmten Situationen eben nicht einfach damit abfinden, dass der Erfinder es nicht will. Und es dann einfach trotzdem machen, so dass es so wunderbare Projekte wie „Pipelight“ gibt. Die dann allen nutzen.

[yellow_box]Um das ganze nochmal klarzustellen: Ich befürworte DRM nicht, im Gegenteil. Ich sehe aber die Notwendigkeit, DRM (in welcher Art und Weise auch immer) für Verleihmodelle zu nutzen. Das bringt im Endeffekt auch Nutzern etwas. Und man muss es ja nicht gleich wie bei Systemen wie Origin übertreiben.[/yellow_box]

Mit dem VPN hinter eine Firewall

Ich mag VPNs. Vor allem das P darin. Und wenn man öfter mal in nicht vertrauenswürdigen Netzen unterwegs ist, ist das auch eine tolle Sache. Nun hat sich mein neuer Internet-Provider entschieden, dass ich nur IPv6 „richtig“, aber mit dynamischem Netzpräfix bekomme, IPv4 dafür nur über Carrier-NAT. Wenn ich zuhause sitze und surfe, ist das auch völlig egal. Die Adressumsetzung macht der Provider (so wie es früher meine Fritz!Box getan hat). Das Problem: die meisten DynDNS Provider können auch nach fast 10 Jahren Vorlauf kein IPv6. Und aus einem IPV4-Netz kommt man so einfach nicht an ein IPv6-Only-Netz.

Das Problem

Ich komme nicht mehr an meinen zentralen Messaging-Server, nicht an mein NAS, nicht an meinen Rechner zu hause und wenn ich in fremden (und offenen) WLAN-Netzen unterwegs bin: Keine sichere Verbindung zu nicht-https-Seiten. Und in offenen WLANs mit vielen Gästen traue ich im Zweifel auch nicht mal HTTPS. Da habe ich bisher meinen Raspberry via SSH verwendet.

Erster Anlauf: (auto-)ssh und Reverse Tunnel

Mein erster Ansatz war, einen vServer mit Reverse-Tunnels zu bestücken. Das hat geplappt, war aber insgesamt recht unflexibel und die Verbindung über den Reverse-Tunnel direkt auf den Raspberry war stellenweise einfach zu instabil, so dass keine stabile (direkte) Verbindung in mein Heimnetz (mit Zugriff auf das NAS) möglich war.
Sprich: habe ich vom Raspberry aus via

ssh -R 8080:localhost:22

eine Verbindung erstellt, und dann von (ganz) außen via

ssh vserver -p 8080

darauf zugegriffen, so war die Verbindung in der Regel deutlich instabiler als der Zugriff zum vServer via SSH. Der Zugriff vom vServer auf den Reverse-Tunnel auf den Raspberry war allerdings extrem stabil. Ich bin nicht sicher, ob das Problem nicht bei meinem Putty lag. Allerdings hat das ganze auch Nachteile, wenn es stabil läuft: Ich benutze immer mittels des vServers meinen Raspberry als Proxy. Das ist 1 „Hop“ mehr als notwendig sein sollte. Den vServer als 100Mbit/s-Proxy nutzen und nur den Verkehr ins lokale Netz über den Raspberry routen, das wäre die optimale Lösung. Daher: Ein echtes VPN muss her.

Zweiter Anlauf: OpenVPN, aber mit Anlauf!

OpenVPN. Bewährt, verbreitet, flexibel, unter Linux zuhause. Installation auf Raspian und dem dem Wheezy-vServer: ein einfachen apt-get install openvpn. VPN schön und gut, aber in einem klassischen steht ja der Server ganz oder einbeinig (DMZ) in dem Netz, in welches ich will, bei Unternehmen ist das in der Regel die Firewall, die so etwas anbietet. Astaro/Sophos und Securepoint bieten so etwas z.B. von Haus aus an.

Nun habe ich die Besonderheit, dass mein VPN-Server komplett außerhalb meines Zielnetzes steht, ich aber in das Netz hinter einem bestimmten Client (im Zielnetz) routen will. Die Anleitung „ServerNET zu ClientNET“ hat mich auch schon ein ganzes Stück weitergebracht. Ich konnte vom Raspberry (der Client im lokalen Netz) die VPN-Adresse des Servers pingen, der Server konnte die VPN-Adresse des Raspberrys pingen. Auch vom Server auf die LAN-IP des Raspberrys konnte ich pingen. Aber auf kein anderes Gerät.

Nach viel ausprobieren und gefrage, fand ich dann auf der OpenVPN-Seite die Antwort. Ich bin linuxmäßig bewandeter als in Netzwerktechnik. Ich in davon ausgegangen, dass wie beim NAT der Rückweg einer Verbindung auch bekannt sein sollte. Dem ist nicht so.Ich habe die Route ins 10er (VPN-) Netz dann in der Fritz!Box eingetragen und seitdem geht alles wie es soll. Inklusive Zugriff auf das lokale Netz vom vServer aus.

Nächster Schritt wird dann sein, den Zugriff vom Notebook und Handy soweit hinzubekommen, dass der Verkehr komplett über das VPN und bei Bedarf ins lokale Netz geroutet wird.

The last step, and one that is often forgotten

The last step, and one that is often forgotten, is to add a route to the server’s LAN gateway which directs 192.168.4.0/24 to the OpenVPN server box (you won’t need this if the OpenVPN server box is the gateway for the server LAN). Suppose you were missing this step and you tried to ping a machine (not the OpenVPN server itself) on the server LAN from 192.168.4.8? The outgoing ping would probably reach the machine, but then it wouldn’t know how to route the ping reply, because it would have no idea how to reach 192.168.4.0/24. The rule of thumb to use is that when routing entire LANs through the VPN (when the VPN server is not the same machine as the LAN gateway), make sure that the gateway for the LAN routes all VPN subnets to the VPN server machine.

Similarly, if the client machine running OpenVPN is not also the gateway for the client LAN, then the gateway for the client LAN must have a route which directs all subnets which should be reachable through the VPN to the OpenVPN client machine.

OpenVPN HowTo

In meinem Fall hat die Route in der Fritzbox gefehlt, die Pakete an das 10er VPN über den Raspberry routet, der ja im 192er und dem 10er-Netz sitzt. Nun erreiche ich auch die lokalen Rechner über den VPN-Server.

Herzlich willkommen im Netz der Zukunft?

Eine Geschichte aus dem Internet des Breitband-MKK-Ausbaus mit dem klangvollen Untertitel: „Der Fluch der tanzenden Schildkröte“

Nicht, dass jetzt jemand denkt mein Internet wäre kaputt oder völlig unbrauchbar, das ist es nicht. Ich habe 27MBit/s Downstream und 2,6MBit/s Upstream zuhause. Und ich habe IPv6, bin damit also schon im Netz der Zukunft angekommen. Allerdings stößt mir dabei die eine oder andere Kleinigkeit sauer auf:

  1. Der Provider ist der Meinung, man dürfe / könne nur die von ihm bereitgestellte Fritz!box nutzen. Hatte ich bei Unitymedia auch, allerdings waren hier auch wenig sinnvolle Alternativen möglich.
  2. Für Privatkunden liefert der Provider nur DS-Lite aus. Dual-Stack wäre möglich, wird aber nur für Geschäftskunden gegen Aufpreis angeboten. Damit ist mein bisheriges Konstrukt für einen SOCKS5-Proxy und meine Kommunikationslösung mit Weechat und screen ziemlich für die Füße. Auch das (Open-)VPN nach Hause kann ich vergessen, da die ganzen DynDNS-Provider keine Unterstützung für IPv6
  3. Ein zweiter Telefonanschluss via Sipgate kann nicht eingetragen werden. Die Begründungen aus dem Support-Forum, die im Internet zu finden sind, sind mehr als fadenscheinig.

Insgesamt muss man damit sagen, dass die Bandbreite der Leitung zwar hält, was sie verspricht, aber leider der „Funktionsumfang“ der Leitung und der Fritzbox auf das Minimum beschränkt ist.

Da der Provider auf Nachfrage den Betrieb von Dual Stack verweigert – und das tut er generell für Privatkunden – und ein Wechsel in einen Business-Tarif erhebliche Mehrkosten (zuzüglich einem Extra-Aufschlag für Dual-Stack) bedeuten würde, war die Lösung zwangsweise die Anmietung von „Hardware“.

Zuletzt war mein Raspberry Pi das Gateway in mein Heimnetz. Da ich per IPv4 gar nicht mehr erreichbar bin (CGN sei Dank), habe ich mir bei TLDHost einen günstigen Mini-vServer auf Linux-Basis gemietet.

Mit AutoSSH baue ich mir einen bzw. zwei Tunnel vom Raspberry zum vServer und connecte mich auf diesen. Je nach Anforderung (ob ich z.B. ins Netz zuhause muss), kann ich damit auch meinen Tunnel für einen lokalen Proxy damit auch am vServer enden lassen (mit entsprechend größerer Bandbreite) oder direkt zu Hause auf dem Raspberry, mit Zugriff auf die Infrastruktur.

Das ist zwar praktischer/flexibler als mit DynDNS und (nur) der Leitung zuhause, erzeugt aber zusätzlich zum Regio-Tarif („Provinz-Strafgebühr“) weitere Kosten, die meinen Monatstarif damit insgesamt weiter hochschrauben. So hatten wir (und insbesondere ich) uns das ehrlich gesagt nicht vorgestellt, das mit dem tollen neuen schnellen Internet.

Und was das mit der Schildkröte betrifft: So doll ist die Animation nun auch nicht.