Statische Routen mit dem NetworkManager

Ich hatte eben das Problem, dass ich statische Routen für eines meiner OpenVPN Tunnel anlegen wollte. Das Problem war jedoch, dass der NetworkManger keine „pseudo“ IPs via vpn_gateway oder ähnliches akzeptiert. Daher blieb mir nur der Weg über ein Skript. Beim Up und Down einer Netzwerkverbindung ruft der NetworkManager die Dispatcher Skripte unter /etc/NetworkManager/dispatcher.d/ auf. Daher habe ich

  1. Der entsprechenden NetworkManager Verbindung ein fixes Interface zugeordnet (im Beispiel tun2) und
  2. Mir folgendes Skript /etc/NetworkManager/dispatcher.d/98-private-routes gebaut:

    [shell]
    #!/bin/sh

    if [ „$1“ == „tun2“ ]; then

    GW=`route -n | grep tun2 | grep „0.0.0.0“ | grep „255.255.255.255“ | cut -f1 -d“ „`
    echo $1“ „$2“ „$GW > /tmp/foo

    case „$2“ in
    up|vpn-up)
    ip r a 192.168.128.12/32 via $GW # VM
    ip r a 10.0.0.0/16 via $GW # 10er Netz
    ;;
    esac

    fi

    [/shell]
    Down ist nicht notwendig, da die Routen sowieso mit dem Interface wegfliegen

OpenVPN – mein Retter in der Not

Ich konnte es nicht glauben. Es gibt tatsächlich noch Flecken in Deutschland, die keinen Handyempfang haben. Ich laufe ja immer mit 2 UMTS Karten herum und zwar Vodafone und T-Mobile. Beide Karten waren an dem Ort, wo ich am Samstag war nutzlos. An Internet per UMTS war nicht zu denken. Ich musste aber irgendwie ins Netz. Gott sei Dank hatte die Stadtverwaltung ein Ethernet-Kabel für mich. Natürlich war aber da nur HTTP und HTTPS erlaubt. Zudem ging alles über einen Proxy. Nachdem ich auf andere Ports angewiesen war, bin ich erstmal ganz schön dumm da gestanden. Zum Glück hatte ich ein OpenVPN Gateway im Rechenzentrum. Zusammen mit der Option –redirect-gateway war ich ohne Einschränkungen im Internet. Mein Tag war gerettet.

OpenNMS und dynamische IPs

Meinen alten Banknachbarn zur Schulzeit habe ich auch schon mit OpenNMS angesteckt. Hat er auch gleich dokumentiert. *grins*. Beim Chatten heute haben wir überlegt, wie man Kundenrechner mit dynamischen IPs überwacht. Die Antwort ist einfach: OpenVPN! Das ganze hat viele Vorteile:

  • Die Daten – selbst mit SNMP – werden automatisch verschlüsselt.
  • IP-Adressen extern/intern spielen keine Rolle.
  • Firwalls spielen nahezu keine Rolle. Das Tunnel kann vom Kunden aufgebaut werden.

So habe ich die Infrastruktur bei meinem Bruder im Laden schon lange im Blick (allerdings immer noch mit Nagios).

Top 10

Toms Kommentar hat mich mal motiviert meine aktuellen Top 10 aus der [[FOSS]] hier auf zu schreiben.

  1. KVM
    Virtualisierung ist das Thema Nummer eins zur Zeit. Damit sind erst viele andere Sachen möglich. Aktuell lasse ich Dank KVM ein Centos 4.7 auf einer Centos 5.2 als VM laufen. Xen ist raus gefallen aus meiner Top 10 Liste. Es mag zwar sicherer sein aber wer es nicht schafft aktuell zu bleiben fliegt raus.
  2. OpenNMS
    OpenNMS ist wirklich super. Dank Autodiscover hat man super schnell sein Netzwerk integriert und überwacht. Die integrierten Collectoren und Monitore erlauben es auch ganz einfach eigene Test zu integrieren ohne dass man was programmieren muss. Nagios hat es leider nicht mir in die Liste geschafft. Die Nagios Entwicklung ist leider viel zu langsam und Nagios selbst fehlen viel zu viele Selbstverständlichkeiten. Der Zug ist abgefahren.
  3. HAProxy
    HAProxy ist endlich ein wirklicher HTTP(s) Loadbalancer mit allen Features die man braucht. In Minuten eingerichtet und performant ohne Ende. LVS mag zwar ganz nett sein für andere TCP Geschichten aber ehrlich gesagt hatte ich noch nie für etwas anderes wie HTTP(s) Bedarf.
  4. Heartbeat
    Heartbeat ist meine HA-Lösung und dass obwohl ich hier immer noch auf die Version 1! setze. Bei meinen Cluster laufen normalerweise die Resourcen sowieso auf beiden Nodes, so dass ich nur die IP schwenken muss. Trotzdem muss ich mir mal Pacemaker genauer ansehen um beim Ausfall einer Resource auch zu schwenken.
  5. Quagga
    Nichts ist schlimmer als den Überblick zu verlieren. Quagga ist der Routing Daemon unter Linux für mich. Dank der „Cisco“-like Konfiguration kommt man sofort damit zu recht. Perfekt!
  6. WordPress
    Dank WordPress dokumentieren ich endlich meine privaten IT Krempel und finde ihn auch wieder. Durch die Öffentlichkeit meines Blogs bekomme ich auch sehr viel Tipps und Anregungen.
  7. OpenVPN
    Bei OpenVPN fehlt mir nur noch der Client fürs Handy. Zusammen mit Quagga ist OpenVPN wirklich super.
  8. Apache Http Server
    Obwohl es zig andere leichtere Server gibt ist der Apache immer noch mein Arbeitspferd. Richtig konfiguriert ist er richtig schnell.
  9. Postfix
    Kein MTA Daemon ist für mich schneller und einfacher eingerichtet. Neben der Performance von Postfix schätze ich auch die leichte Erweiterbarkeit.
  10. Bacula
    Backups sind super wichtig. Bacula hat mir schon oft den Hintern gerettet. Danke!

Mal sehen wie sich die Statistik so weiter entwickelt. Vor einem halben Jahr oder früher hätte sie noch ganz anders ausgesehen (Xen, Nagios, Exim, dokuwiki, LVS, …)

openvpn metric … ich bin verwirrt.

OpenVPN fehlt meiner Meinung nach eine Art [[Split Horizon]]. Ich hatte bisher immer ein Problem. Läuft mein OpenVPN Client immer, also auch wenn ich meinen Computer zu Hause betreibe, so gerät das Routing durcheinander. Zu Hause benutze ich das 172.16.1.0/24 Netz. Fürs VPN 172.16.3.0/24. Verbindet sich nun mein Client auch zu Hause mit meinem Server per OpenVPN so sieht die Routing Tabelle bei mir wie folgt aus:

Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
172.16.1.0      0.0.0.0         255.255.255.0   U     1      0        0 eth0
172.16.1.0      172.168.3.1     255.255.255.0   UG    1      0        0 tap1
172.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 tap1
0.0.0.0         172.16.1.1      0.0.0.0         UG    0      0        0 eth0

Wie man sieht, soll das lokale Netz plötzlich über das VPN erreichbar sein. Dieses ist aber wiederum über das lokale Netz angebunden. Deadlock!

Bisher habe ich das „einfach“ gelöst. Ich habe auf meinem VPN-Server den entsprechenden Port von Innen gesperrt und so das VPN verhindert. Jetzt ist aber alles anders. Mein VPN läuft auf Port 443 und darauf sollen auch der Apache per https antworten. Daher setze ich nun OpenVPN 2.1 mit Port-Share ein. Soweit so gut. Dank meiner Konfiguration konnte ich aber den HTTPS Server von Innen nicht erreichen. Blöd! Also musste der Filter wieder weg. Damit nun aber meine Routing Tabellen nicht wieder kaputt gehen bzw. unlogisch werden habe ich die Metric entsprechend in der OpenVPN.conf auf meinem Server geändert:

push route 172.16.1.0 255.255.255.0 vpn_gateway 150

Was zu der folgenden Routingtabelle führt:

Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
172.16.1.0      0.0.0.0         255.255.255.0   U     1      0        0 eth0
172.16.1.0      172.168.3.1     255.255.255.0   UG    150    0        0 tap1
172.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 tap1
0.0.0.0         172.16.1.1      0.0.0.0         UG    0      0        0 eth0

Damit kommt der Client nicht auf die Idee, das lokale Netz über das VPN erreichen zu wollen. Also alles in bester Ordnung.

Warum bin ich aber nun verwirrt? Ich zitiere mal man route:

 
Metric The  ’distance’ to the target (usually counted in hops). 
  It is not used by recent kernels, but may be needed by routing daemons.

Ist der Kommentar so alt, oder wer kümmert sich um die Metric? Aber Hauptsache es funktioniert jetzt.

TinyCA – CA Verwaltung unter Gnome

Mit easy-rsa bringt openvpn ja bereits eine CA-Lösung mit, die mit wenigen Skripts auskommt und ziemlich einfach bedienbar ist. Manchmal ist aber ein graphisches Frontend doch schöner. Für die CA-Verwaltung habe ich eben per Zufall TinyCA entdeckt. Sieht ziemlich praktisch aus. Übrigens kommt das Teil aus Franken (Nürnberg).

OpenVPN für Olympia

OpenVPNIm Blog von Netways schreibt Bernd Erk ein Loblied über OpenVPN. Dabei vergisst er allerdings 3 wichtige Dinge, die das Leben mit OpenVPN so praktisch machen:

  1. OpenVPN kann Proxys benutzen. D.h. selbst wenn nur ein indirekter Internet-Zugang über einen Proxy möglich ist, ist der Tunnel-Aufbau auch kein Problem
  2. Kann OpenVPN die Default Router umbiegen. Dh. steht der Tunnel geht sämtlicher Traffic über das Tunnel und die Firewall, Proxy, … sieht nur noch https Traffic.
  3. Unterstützt OpenVPN dynamische IPs. Wechselt eine der beiden Seiten die IP so baut sich einfach der Tunnel wieder auf und alle Sitzungen durch das Tunnel bleiben erhalten.

Ich hatte wirklich noch keinen einzigen Fall, wo ich nicht mit OpenVPN nach draußen kam. Viele liebe Grüße an meine ehemaligen Kunden 😉

Übrigens wird die neue Version 2.1 auch port-share unterstützen. D.h. OpenVPN und ein HTTPS Server können sich den TCP Port 443 teilen. Damit reicht auf der Serverseite sogar nur noch eine IP für beides und man kann jeden DSL-Anschluss als Server nutzen. Wie wollen die Chinesen das noch sperren? Ich jedenfalls werde mir umgehend nachdem 2.1 stable ist das installieren.

OpenVPN ist für mich das beste OpenSource Projekt seit langem.

Eine eigene PKI mit easy-rsa

OpenVPNOpenVPN macht einen das Leben wirklich leicht. War es anfangs ein echter Kraus OpenVPN mit Zertifikaten einzurichten, ist es jetzt ein Kinderspiel. OpenVPN bringt mit der Dokumentation ein Verzeichnis easy-rsa mit. Dieses enthält alles was für die eigene PKI. Schritt für Schritt ist das Vorgehen auf der OpenVPN.net Website beschrieben. Die notwendige Konfiguration kann man sich dort auch ziehen. Damit ist eine PKI und ein darauf basierendes VPN in wenigen Minuten installiert.

Danke OpenVPN!