Wenn zwei unterschiedliche Netzwerke die gleiche IP Range haben…

Vorweg: mit IPv6 wäre das nicht notwendig. IPv6 ist aber immer noch nicht flächendeckend ausgerollt (und wird es wohl zu meiner Lebenzeit auch nicht)

Wenn man sich via VPN aus einem beliebigen Netz in sein eigenes Netzwerk verbindet funktioniert das nur, wenn das Lokale Netz (aus dem man sich verbinden will) eine andere Netzmaske hat, als das Zielnetz, in das man sich verbinden will.

In meinem Fall Hotel-WLan-Gateway die gleiche Adresse wie eine meiner Server (auf dessen Service ich gerade zugreifen wollte).

Ich halte ja mittlerweile zwei unterschiedliche VPN Netzwerk Konfigurationen bereit, für den Fall, dass mein Gastnetzwerk den gleichen Addressraum nutzt, denn auch mein VPN hat. Für die Zieladressen konnte ich diesen Weg aber nicht gehen.

Das Problem kann man mit einem Router und „Policy Based Routing“ lösen.

Der Router wird mit dem zur Verfügung gestellten Gast Netz verbunden (IP Range A) und stellt selber ein Netzwerk (IP Range B) zur Verfügung. Der Router wählt sich nun in das VPN-Netzwerk ein (IP Range C). Das interne Netzwerk, dass durch das VPN erreicht werden soll, hat auch IP Range A.

Das Problem: wenn ein Client aus IP Range B versucht auf interne Ressourcen mit der IP Range A zuzugreifen, geht der Router nicht über das VPN, sondern auf den direkten Link, also ins GastNetz.

Die Lösung: man legt sich eine neue Routing Table an, die zwei Einträge hat:

Den Lokalen Link für das eigene Netzwerk (IP Range B)
eine Default Route über das VPN (IP Range C)

Das kann dann so aussehen

ip route add IP-RANGE-B dev LOCAL-DEV proto kernel scope link src LOCAL-IP table 200 
ip route add default via VPN-GW-IP dev VPN-DEV table 200

Anschließend muss man dem Router nur noch dazu Bringen, alles aus dem eigenen Netzwerk (IP Range B) über diese Tabelle zu routen. Das geht wie folgt:

ip rule add from IP-RANGE-B lookup 200

Wenn nun etwas aus dem eigenen Netzwerk (IP Range B) bearbeitet wird, kennt der Router das GastNetz (IP Range A) nicht.

Das ganze kann man auch ohne Router erreichen, also mit einem Client direkt im GastNetz (IP Range A) und einer OpenVPN Instanz am laufen. Dann werden die „ip rule“ Statements nur viel komplizierter.

Die Ansatz hier ist: Sämtlichen Traffic, der nicht von dem VPN erzeugt wird, über eine gesonderte RoutingTable zu bearbeiten und nur den VPN Traffic an das Default GW zu bekommen. Der Kniff ist „Sämtlichen Traffic, der nicht von dem VPN erzeugt wird“ korrekt zu erkennen. Möglichkeiten hier sind:

  • Alles was nicht an den Default GW gesendet wird
  • Alles was nicht von einem bestimmten User erzeugt wurde

Alles in allem hat man einfach ein bisschen mehr Aufwand.

Oder man sorgt mittels IPv6 einfach dafür, dass man keine zwei Netze mit gleicher IP Range hat…

OpenVPN – TLS-Server-Check bestehen

OpenVPN liefert gleich eine ganze BuildChain mit um sich Zertifikate zu generieren und zu signieren. Leider hat man meist schon eine Infrastruktur (CA) im Feld mit der man seine Zertifikate signiert und verteilt. Bei mir habe ich das immer über das in Ubuntu mitgelieferte CA.pl Skript gemacht und die so erzeugten Zertifikate funktionieren gerade nicht in OpenVPN. Es kann zwar eine Verbindung aufgebaut werden aber ein TLS-Server-Check schlägt fehl. Um gültige Zertifikate zu erzeugen muss man folgendes machen.

in der /etc/ssl(openssl.cnf muss man eine neue Sektion anlegen. Am besten mit dem Namen „Server“ oder „OpenVPNHost“

[ server ]
basicConstraints=CA:FALSE
nsCertType          = server
nsComment           = "Some comment"
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
extendedKeyUsage=serverAuth
keyUsage = digitalSignature, keyEncipherment

anschließend muss man das certifiacte wie folgt erzeugen:

openssl req -days 365 -nodes -new -keyout newkey.pem -out newreq.pem -extensions server -config /etc/ssl/openssl.cnf
openssl ca -days 1095 -extensions server -in newreq.pem -policy policy_anything -out newcert.pem

Das so erzeugte Zertifikat besteht auch einen TLS-Server-Check