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:

    #!/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
    
    

    Down ist nicht notwendig, da die Routen sowieso mit dem Interface wegfliegen

    VN:F [1.9.22_1171]
    Rating: 0.0/10 (0 votes cast)
    VN:F [1.9.22_1171]
    Rating: +1 (from 1 vote)

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.

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

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.

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Schon wieder ein SSH Tipp: VPN

SSH kann mehr als einfaches Tunneln per Portforwarding. Mit SSH kann man sehr einfach Punkt zu Punkt VPNs bauen. Der interessante Parameter ist hier -w. Damit wird sowohl auf der lokalen als auch auf der entfernten Seite ein Tun Interface etabliert.

Eine schöne Anleitung wie das ganze automatisiert werden kann habe ich auf dieser Debian Administration Seite gefunden.

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Ping tunnel

Neben der Frage ob DNS-Request möglich ist, die ich ja schon hier beantwortet habe, werde ich häufig gefragt, ob es Tunnel auch über ICMP/Ping gibt. Manchmal trifft man auf abgeschirmte Netze die außer Pings nichts durchlassen. Also bleibt nur Traffic über ICMP-Pakete zu tunneln.

Natürlich geht das auch! Mit Ping tunnel gibt es das entsprechende Paket. Auf der Seite wird übrigens detailliert beschrieben, wie es funktioniert. Das Tool liegt übrigens auch vielen Distributionen als „ptunnel“ bei.

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

CloudVPN – secure mesh VPN

cloudvpn_smallVPNs sind normalerweise immer Punkt zu Punkt Verbindungen. Egal wie redundant die „Transport-Infrastruktur“ ist fällt ein VPN-Knoten aus, dann ist die Verbindung beendet. Jetzt habe ich ein neues interssantes Projekt gefunden. Der Entwickler von CloudVPN hat sich über dieses Problem Gedanken gemacht und ein secure mesh VPN über SSL geschaffen. Vielleicht versuch ich das irgendwann mal. Interessant ist es auf jeden Fall.

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)