VPN von außerhalb des Campus

Bringt dich von überall ins Campusnetz, mit derselben SSO-Anmeldung wie überall sonst. Nötig für Netzlaufwerke, manche Bibliotheksressourcen und alles, was prüft, ob du am Campus bist.

Offizielle Dokumentation: VPN-Service der THI. Der offizielle Client ist FortiClient; diese Seite nutzt openfortivpn: quelloffen, ohne Oberfläche und ohne dauerhaft erhöhte Rechte außerhalb des Tunnels selbst.

Das Zertifikatsproblem, einmalig

vpn.thi.de liefert das eigene Zertifikat aus, aber nicht das Zwischenzertifikat, das es mit einer vertrauenswürdigen Wurzel verbindet. Ein korrekt konfigurierter Client kann die Kette deshalb nicht vervollständigen und verweigert die Verbindung. Das sieht wie ein Fehler auf dem eigenen Rechner aus, ist aber keiner.

Die Lösung: openfortivpn ein eigenes Zertifikatsbündel geben, bestehend aus dem fehlenden Zwischenzertifikat und den Wurzelzertifikaten, die das System ohnehin mitbringt. Mit --ca-file liest openfortivpn diese Datei statt des systemweiten Zertifikatsspeichers. Ein Client lernt ein Gateway kennen, und sonst ändert sich auf dem Rechner nichts daran, wem vertraut wird.

Das Zwischenzertifikat allein reicht nicht. Es ist nicht selbstsigniert, OpenSSL akzeptiert es deshalb nicht als Anker und bricht mit „unable to get issuer certificate" ab. Die Wurzeln gehören in dieselbe Datei.

sudo pacman -S openfortivpn
curl -o /tmp/inter.cer http://crt.harica.gr/HARICA-GEANT-TLS-E1.cer
openssl x509 -inform DER -in /tmp/inter.cer -out /tmp/HARICA-GEANT-TLS-E1.pem
sudo install -d -m 755 /etc/openfortivpn
cat /tmp/HARICA-GEANT-TLS-E1.pem /etc/ssl/certs/ca-certificates.crt |
  sudo tee /etc/openfortivpn/ca-bundle.pem > /dev/null

sudo apt install openfortivpn
curl -o /tmp/inter.cer http://crt.harica.gr/HARICA-GEANT-TLS-E1.cer
openssl x509 -inform DER -in /tmp/inter.cer -out /tmp/HARICA-GEANT-TLS-E1.pem
sudo install -d -m 755 /etc/openfortivpn
cat /tmp/HARICA-GEANT-TLS-E1.pem /etc/ssl/certs/ca-certificates.crt |
  sudo tee /etc/openfortivpn/ca-bundle.pem > /dev/null

macOS hält seine Wurzelzertifikate in einem Schlüsselbund statt in einer Datei, sie werden deshalb zuerst exportiert.

brew install openfortivpn
curl -o /tmp/inter.cer http://crt.harica.gr/HARICA-GEANT-TLS-E1.cer
openssl x509 -inform DER -in /tmp/inter.cer -out /tmp/HARICA-GEANT-TLS-E1.pem
security find-certificate -a -p /System/Library/Keychains/SystemRootCertificates.keychain > /tmp/roots.pem
sudo install -d -m 755 /etc/openfortivpn
cat /tmp/HARICA-GEANT-TLS-E1.pem /tmp/roots.pem |
  sudo tee /etc/openfortivpn/ca-bundle.pem > /dev/null

Die URL oben ist kein fremder Spiegel: Sie steht im Zertifikat des Gateways selbst, in der Erweiterung „Authority Information Access". Das Zwischenzertifikat ist GEANT TLS ECC 1 unterhalb von HARICA TLS ECC Root CA 2021, dem dein System bereits vertraut.

Das Bündel liegt bewusst unter /etc und gehört root. openfortivpn läuft mit sudo, ein Bündel im Homeverzeichnis wäre also von genau dem Konto beschreibbar, das es schützen soll.

Verbinden

sudo openfortivpn vpn.thi.de --saml-login --ca-file=/etc/openfortivpn/ca-bundle.pem

openfortivpn gibt eine SSO-URL aus und wartet. Diese URL selbst im Browser öffnen und wie gewohnt anmelden: geöffnet wird sie von niemandem, ein scheinbar hängender Aufruf ist deshalb meist einer, dessen URL niemand angeklickt hat. Der Tunnel besteht, solange der Befehl läuft; Strg+C trennt ihn.

Oder das Skript nutzen, das zuerst das Bündel prüft und den Fehler erklärt, statt einen TLS-Fehler auszugeben:

vpn-connect.sh Herunterladen

Verbindet und erklärt verständlich, wenn das Bündel fehlt oder unvollständig ist

curl -fsSLO https://hutzelmann.github.io/thi-linux-macos-setup/scripts/vpn-connect.sh
less vpn-connect.sh   # erst lesen
sh vpn-connect.sh --dry-run
sh vpn-connect.sh

Läuft eigenständig. Die dokumentierten Werte und Hilfsfunktionen sind eingebaut, das Repository wird nicht gebraucht. --dry-run zeigt nur an, was passieren würde.

Rückfallweg: das Zertifikat pinnen, für etwa ein Jahr

Wo sich kein Bündel bauen lässt, kann openfortivpn genau ein Gateway-Zertifikat akzeptieren:

sudo openfortivpn vpn.thi.de --saml-login --trusted-cert=<sha256>

openfortivpn gibt bei fehlgeschlagener Prüfung den zu übergebenden Digest selbst aus, ein Fehlversuch genügt also. Vorab berechnen:

echo | openssl s_client -connect vpn.thi.de:443 \
  -servername vpn.thi.de 2>/dev/null |
  openssl x509 -noout -fingerprint -sha256 | cut -d= -f2 | tr -d ':' | tr 'A-Z' 'a-z'

Die Einschränkung: Gepinnt wird ein einzelnes Zertifikat, nicht die Kette, und das Gateway-Zertifikat wird etwa jährlich ersetzt. Beim nächsten Wechsel schlägt die Verbindung wieder fehl, und der Digest muss von Hand gesucht und neu eingetragen werden. Das Bündel übersteht den Wechsel, weil Zwischen- und Wurzelzertifikat das Serverzertifikat um Jahre überdauern.

Auf dieser Seite steht kein Digest. Ein aus dem Netz gelesener Wert ist ein beobachteter, kein geprüfter Wert, und das Pinnen von Vertrauensmaterial entscheidet jede Leserin und jeder Leser selbst.

Prüfen

vpn-verify.sh Herunterladen

Prüft das Gateway und ob das dokumentierte Bündel vorhanden ist

curl -fsSLO https://hutzelmann.github.io/thi-linux-macos-setup/scripts/vpn-verify.sh
less vpn-verify.sh   # erst lesen
sh vpn-verify.sh --dry-run

Läuft eigenständig. Die dokumentierten Werte und Hilfsfunktionen sind eingebaut, das Repository wird nicht gebraucht. --dry-run zeigt nur an, was passieren würde.

Es wird nichts verbunden und keine Zugangsdaten verwendet; geprüft wird nur der TLS-Handshake. Von Hand:

echo | openssl s_client -connect vpn.thi.de:443 \
  -servername vpn.thi.de 2>/dev/null | openssl x509 -noout -subject -dates

Bekannte Eigenheiten

DNS stört Avahi, und Avahi bricht das Drucken. openfortivpn stellt DNS über resolvconf um. Auf Systemen mit systemd-resolved kollidiert das mit dem Avahi-Dienst, den CUPS für die Druckererkennung braucht. Eine VPN-Verbindung kann das Drucken also lahmlegen, bis sie getrennt wird. Üblicher Ausweg: openresolv installieren und die Umstellung darüber laufen lassen. Diskussion: Arch-BBS-Thread.

openresolv zu installieren ist nur die halbe Miete, und die andere Hälfte meldet sich leise. Das Gateway schiebt seine Nameserver und ein Suffix nach, openfortivpn reicht beides an resolvconf weiter. Schreibt NetworkManager /etc/resolv.conf weiterhin selbst, beanspruchen zwei Programme dieselbe Datei: openresolv findet eine Datei, die es nicht angelegt hat, und lehnt ab, statt sie zu überschreiben.

INFO:   Adding VPN nameservers...
resolvconf: signature mismatch: /etc/resolv.conf
resolvconf: run `resolvconf -u` to update

Der Verkehr durch den Tunnel ist davon unberührt, es wirkt also wie ein verbundenes VPN, in dem plötzlich kein einziger Campusname mehr bekannt ist, und in /etc/resolv.conf steht weiterhin das, was das lokale Netz geliefert hat. Die erste Zeile dieser Datei nennt das Programm, das sie zuletzt geschrieben hat, und trennt die beiden Fälle am schnellsten. Welche Nameserver hätten gesetzt werden sollen, gibt openfortivpn eine Zeile darüber selbst aus, in der Zeile Got addresses.

Das ist eine lokale Kollision und hat mit dem Campus nichts zu tun. Ein Lösungsweg ist hier noch nicht festgehalten.

DNS stört Avahi, und Avahi bricht das Drucken. openfortivpn stellt DNS über resolvconf um. Auf Systemen mit systemd-resolved kollidiert das mit dem Avahi-Dienst, den CUPS für die Druckererkennung braucht. Eine VPN-Verbindung kann das Drucken also lahmlegen, bis sie getrennt wird. Üblicher Ausweg: openresolv installieren und die Umstellung darüber laufen lassen. Diskussion: Arch-BBS-Thread.

openresolv zu installieren ist nur die halbe Miete, und die andere Hälfte meldet sich leise. Das Gateway schiebt seine Nameserver und ein Suffix nach, openfortivpn reicht beides an resolvconf weiter. Schreibt NetworkManager /etc/resolv.conf weiterhin selbst, beanspruchen zwei Programme dieselbe Datei: openresolv findet eine Datei, die es nicht angelegt hat, und lehnt ab, statt sie zu überschreiben.

INFO:   Adding VPN nameservers...
resolvconf: signature mismatch: /etc/resolv.conf
resolvconf: run `resolvconf -u` to update

Der Verkehr durch den Tunnel ist davon unberührt, es wirkt also wie ein verbundenes VPN, in dem plötzlich kein einziger Campusname mehr bekannt ist, und in /etc/resolv.conf steht weiterhin das, was das lokale Netz geliefert hat. Die erste Zeile dieser Datei nennt das Programm, das sie zuletzt geschrieben hat, und trennt die beiden Fälle am schnellsten. Welche Nameserver hätten gesetzt werden sollen, gibt openfortivpn eine Zeile darüber selbst aus, in der Zeile Got addresses.

Das ist eine lokale Kollision und hat mit dem Campus nichts zu tun. Ein Lösungsweg ist hier noch nicht festgehalten.

--saml-login braucht einen Browser auf demselben Rechner. Auf einem Server ohne Oberfläche musst du dich anderswo anmelden und das Cookie übergeben.

Wie viel Verkehr durch den Tunnel läuft, entscheidet das Gateway, nicht eine Einstellung hier. Auf einem Konto hat das Gateway ausschließlich Routen in die Campusnetze gesetzt, die Standardroute blieb auf der lokalen Schnittstelle, Verkehr zu allem anderen lief also nicht durch den Tunnel. Das ist eine Richtlinie auf Gateway-Seite und kann sich je nach Konto unterscheiden. Deshalb an der eigenen Verbindung ablesen, statt es in die eine oder andere Richtung anzunehmen:

ip route show dev ppp0     # was das Gateway in den Tunnel geroutet hat
ip route show default      # unverändert heißt: alles andere bleibt lokal