Treo 650: Von den Toten auferstanden

2004 erschien der Treo 650 in den USA. Seitdem hat sich viel geändert: Palm gibt es nicht mehr, Technologien haben sich weiterentwickelt, mit welchen das Gerät nicht umgehen kann.

So hat z.B. der eingebaute Browser massive Probleme mit aktuellen, per TLS gesicherten Webseiten. Was mit einem aktuellen Smartphone ohne Probleme funktioniert, wirft auf dem Treo viele Fehlermeldungen oder die Webseite kann überhaupt nicht aufgerufen werden. Der Grund dafür sind aktuelle TLS-Implementationen, welche auf PalmOS nicht verfügbar sind. So wurde kürzlich SSLv3 in der Linux-Bibliothek OpenSSL deaktiviert – das Protokoll mit dem der Treo noch klar kommen würde. Weiterhin sind Hash- und Verschlüsselungsalgorithmen mit der Zeit geschwächt oder gebrochen worden, sodass viele Webseiten diese Verfahren über TLS nicht mehr anbieten. Dies betrifft die vom Treo beherrschten Standards SHA-1, MD5, 3DES und RC4. Hinzukommt, dass eine Überprüfung des TLS-Zertifikats nicht mehr durchgeführt werden kann. Mittlerweile sind viele neue Root-CAs entstanden (die dem Treo unbekannt und deshalb abgelehnt werden) bzw es haben sich auch im Zertifikatssystem Technologien verändert. Diese Veränderungen haben zur Folge, dass der Treo 650 zwar ins Internet gelangt, Webseiten aber nur sehr eingeschränkt nutzbar ist.

Beim E-Mail Abruf sieht es nicht viel besser aus. Auch hier machen aktuelle Technologien Schwierigkeiten. Einzig der bewusste Verzicht auf Verschlüsselung kann, wenn der Provider es unterstützt, zum Erfolg führen. Allerdings ist diese “Lösung” stark mit Vorsicht zu genießen, da man so mindestens seinen E-mail Verkehr im Klartext durch das Internet schickt. Die Zugangsdaten müssen nicht zwangsweise unverschlüsselt übertragen werden. Je nach Anbieter und verwendeter Mail-Software kann das CRAM-MD5-Verfahren zur Absicherung des Passwortes genutzt werden. Noch gilt das Verfahren als nicht gebrochen und wird beispielsweise von Snappermail Enterprise unterstützt.

Doch wie kann man dem Treo noch etwas mehr “Internet beibrigen”? Dazu muss auf die vorhandenen Möglichkeiten aufgesetzt und passende Infrastruktur (eigener vServer/Server oder Webspace) vorhanden sein. Am einfachsten ist der Zugriff auf das Internet per Browser. Statt sich direkt mit dem Palm-Browser zu der Webseite zu verbinden, wird ein Web-Proxy (installiert auf einem Webspace oder vServer/Server) wie z.B. Glype zwischengeschaltet. Der Proxy ruft die Webseite ab und leitet sie an den Palm weiter. Der Proxy selbst muss dazu über eine ungesicherte HTTP-Verbindung oder über eine unterstützte TLS-Verbindung vom Palm aus aufgerufen werden. Dabei sollte man beachten, das der Datenverkehr zwischen Palm und Proxy unverschlüsselt erfolgt, d.h. man sollte es tunlichst vermeiden, sensible Daten über diesen Weg auszutauschen.

Der E-Mail-Abruf gestaltet sich deutlich komplizierter und kann nicht so einfach reaktiviert werden, wenn E-Mail-Anbieter wie GMX, GMail, web.de etc genutzt werden. Nur bei einer self-hosted-Lösung ist dies umsetzbar.
Noch bis vor ein paar Monaten konnte ich mit nginx einen E-Mail Proxy betreiben, welcher die von PalmOS bzw. Snappermail beherrschten Protokolle unterstützte. Da diese Verfahren seit dem Update durch OpenSSL global deaktiviert wurden, funktionierte auch diese Lösung nicht mehr. Die aktuelle Lösung basiert auf einem VPN-Tunnel, welcher vom Treo zum Server aufgebaut wird. Hier kommen zwei VPN-Protokolle in Frage: PPTP und IPSec. Für beide Varianten existieren VPN-Clients für PalmOS: Movian VPN für IPSec und Mergic VPN für PPTP. PPTP ist dabei die schwächere Wahl, da das Protokoll als gebrochen gilt. Ich habe mich trotzdem für PPTP entschieden, da die Einrichtung am Server zunächst einfacher und unkomplizierter war und es dann doch nicht ganz trivial ist, die Verbindung anzugreifen was zumindest Script-Kiddies da Leben erschweren sollte. Sollte die VPN-Verbindung gebrochen werden, sind die Zugangsdaten noch immer per CRAM-MD5 gesichert. Vielleicht versuche ich mich demnächst noch an einer IPSec-Verbindung, welche noch als sicher und ungebrochen gilt.
Der Mailabruf im Mail-Client erfolgt dann nicht über die normale Adresse des Mailservers, sondern über die interne IP der VPN-Verbindung. Der Haken an der Sache ist, dass diese Art von VPN-Verbindung von Netzwerkgeräten unterstützt werden muss. Dies ist gerade in Heimnetzen manchmal nicht der Fall. So habe ich es (noch) nicht hinbekommen, einen PPTP-Tunnel durch den Bluetooth-Access-Point blue2net zu tunneln. GRE-Pakete, welche für PPTP essentiell sind, werden nicht durchgeleitet.

Mit diesen zwei Methoden ist der Treo wieder etwas mehr nutzbar geworden und muss nicht in der Ecke verstauben. ;)

Open vSwitch + SDN – aus dumm mach schlau

Verbindet man Open vSwitch mit einem SDN-Controller (z.B. OpenDaylight), ist das Netzwerk ersteinmal tot. Erst mit dem Hinzufügen von Regeln bekommt das Netz wieder in Gang. Für Basiskommunikation benötigt es Regeln, welche ARP- und IP-Traffic berücksichtigen. Dazu müssen folgende Fälle berücksichtigt werden:

  1. ARP-Traffic an die Broadcastdomain
  2. ARP-Traffic an einen bestimmten Host
  3. IP-Traffic an deinen bestimmten Host

Die Regel für den ersten Fall muss alle ARP-Pakete an die Broadcastdomain über alle Interfaces weiterleiten, damit es den Zielhost erreichen kann:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<flow xmlns="urn:opendaylight:flow:inventory">
    <flow-name>arp2broadcast</flow-name>
    <table_id>0</table_id>
    <id>0</id>
    <priority>100</priority>	
    <instructions>
        <instruction>
            <order>0</order>
	     <apply-actions>		
                <action>
                    <order>1</order>
                    <output-action>
                        <output-node-connector>ALL</output-node-connector>
                        <max-length>200</max-length>
                    </output-action>
                </action>    
	     </apply-actions>
        </instruction>
    </instructions>
    <match>
   <ethernet-match>
            <ethernet-type>
                <type>2054</type>
            </ethernet-type>
	   <ethernet-destination>
                <address>ff:ff:ff:ff:ff:ff</address>
            </ethernet-destination>
   </ethernet-match> 
  </match>
</flow>

Für Fall 2 muss die Ethernetzieladresse und der Output-Port angepasst werden. Jeder Host im Netzwerk benötigt einen solchen Eintrag, damit die Pakete entsprechend geroutet werden können:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<flow xmlns="urn:opendaylight:flow:inventory">
    <flow-name>arp2linuxadmin</flow-name>
    <table_id>0</table_id>
    <id>3</id>
    <priority>100</priority>	
    <instructions>
        <instruction>
            <order>0</order>
            <apply-actions>
                <action>
                    <order>1</order>
                    <output-action>
                        <output-node-connector>4</output-node-connector>
                        <max-length>200</max-length>
                    </output-action>
                </action>
            </apply-actions>
        </instruction>
    </instructions>
    <match>
   <ethernet-match>
            <ethernet-type>
                <type>2054</type>
            </ethernet-type>
	   <ethernet-destination>
                <address>52:54:00:34:85:00</address>
	   </ethernet-destination>
   </ethernet-match> 
  </match>
</flow>

Der Rechner mit der MAC-Adresse 52:54:00:34:85:00 ist über Port 4 erreichbar, der Ethernet-Type 2054 matcht ARP-Pakete. In diesem Fall wird das einfachste Szenario, die VMs sind direkt an den Switch angeschlossen, betrachtet. Sind VMs über einen weiteren Switch angeschlossen, muss der Output-Port der Regeln entsprechend angepasst werden.

Um IP-Pakete zu erfassen, wird der Ethernet-Type entsprechend angepasst:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<flow xmlns="urn:opendaylight:flow:inventory">
    <flow-name>linuxadmin</flow-name>
    <table_id>0</table_id>
    <id>102</id>
    <priority>100</priority>
    <instructions>
        <instruction>
            <order>0</order>
            <apply-actions>
            	<action>
		    <order>1</order>
                    <output-action>
                        <output-node-connector>4</output-node-connector>
                        <max-length>200</max-length>
                    </output-action>
                </action>
            </apply-actions>
        </instruction>
    </instructions>
    <match>
   <ethernet-match>
            <ethernet-type>
                <type>2048</type>
            </ethernet-type>
            <ethernet-destination>
                <address>52:54:00:34:85:00</address>
            </ethernet-destination>
   </ethernet-match>
   </match>
</flow>

Damit ist eine Grundkommunikation im Netzwerk hergestellt. Weitere, tiefer greifende Konfigurationsmöglichkeiten – wie das setzen von VLAN-Tags oder filtern von bestimmten Pakettypen – ist möglich: https://wiki.opendaylight.org/view/Editing_OpenDaylight_OpenFlow_Plugin:End_to_End_Flows:Example_Flows

Kompletten Netzwerkverkehr per iptables umleiten

Um den kompletten Netzwerkverkehr per iptables zu einer anderen Adresse umzuleiten, muss zunächst die Weiterleitung von IP-Paketen im System aktiviert werden (sysctl -w net.ipv4.ip_forward=1).
Als nächstes aktiviert man die eigentliche Weiterleitung mit folgenden Regeln:
iptables -t nat -A PREROUTING -s 0.0.0.0/0 -p all -j DNAT --to-destination $ipdeszielsystems
iptables -t nat -A POSTROUTING -j MASQUERADE

Bei mir kommt die Umleitung immer dann zum Einsatz, wenn ich einen vServer migriert habe, sich die IP gewechselt hat und nur noch die neuen Einstellungen des DNS-Servers wirksam werden müssen. Dies kann 24h dauern, wodurch Zugriffe auf das alte und neue System erfolgen können. Damit dies nicht passiert, leitet das alte System auf das neue um.
Nachteil: Auch der SSH-Zugriff wird umgeleitet, sodass auf dem Altsystem nur noch per VNC-Konsole über den Host zugegriffen kann. Zudem erscheinen alle umgeleiteten Zugriffe auf dem neuen System mit der IP-Adresse des alten Systems.