Den Linux-VPN-Client zum Protokoll des alten Geräts passend wählen

Vier Protokollfamilien decken fast jedes Gerät ab, das noch in einem Rack steht, und jede scheitert unter Linux anders. Die veröffentlichten Ports und konfigurierten Vorschläge der Gegenseite bestimmen Ihr Paket, nicht die Distribution, die Sie zufällig einsetzen. Zu installieren, was ein Forenbeitrag nennt, und dann zu editieren, bis irgendetwas verbindet, ist der Weg, auf dem ein Nachmittag verschwindet. Lesen Sie das Gerät, installieren Sie als Zweites, verifizieren Sie als Drittes.

Notieren Sie, was die Gegenseite veröffentlicht

Notieren Sie Protokoll, Ports und Authentifizierung, die das Gerät erwartet, bevor Sie einen Paketmanager öffnen. Vier Familien decken den Großteil alter Geräte ab, und die Tabelle unten ist die ganze Entscheidung auf einem Bildschirm.

Das Handbuch und die eigenen Firewallregeln des Geräts sind verlässlicher als der Protokollname auf seiner Anmeldeseite. Ein Gerät, das IPsec bewirbt, spricht vielleicht nur IKEv1, und eine Firmware-Version, die niemand eingespielt hat, ist womöglich das, was schließlich IKEv2 hinzufügt. Bestätigen Sie den Datenpfad ebenso wie den Einrichtungsport, denn hier gehen altes Gerät und moderne Netze auseinander. Wer diesen Schritt falsch macht, debuggt seinen Client gegen eine Funktion, die die Gegenseite nie hatte.

PPTP: GRE nachweisen, bevor Sie pppd editieren

PPTP unter Linux ist kein Dienst, den Sie starten, sondern ein pppd-Aufruf, und die Verbindungsparameter liegen in einer benannten Peer-Datei, die pppd liest, wenn er aufgerufen wird. Distributionen packen es weiterhin, obwohl die bekannten Schwächen des Protokolls es für alles Sensible untauglich machen, halten Sie es also strikt für ein Gerät bereit, das nichts anderes bietet. Achten Sie auf GRE, während der Client verhandelt, mit einem kurzen Mitschnitt statt einer Vermutung. Der Fehler, der die meiste Zeit kostet, ist nicht die Authentifizierung, sondern der fehlende Datenpfad.

pppd call branch-office
tcpdump -ni any proto gre -c 5

Wenn die Einrichtung durchläuft und die Verbindung nie Verkehr trägt, verdächtigen Sie den GRE-Pfad, bevor Sie Anmeldedaten anfassen. Cloud-Sicherheitsgruppen brauchen eine ausdrückliche Regel für Protokoll 47, und manche Netze blockieren es ohne sichtbaren Fehler vollständig. Testen Sie aus dem Netz, das Sie tatsächlich nutzen werden, nicht aus einem Labor, das alles erlaubt.

L2TP/IPsec: ein passender Vorschlag schlägt zehn Versuche

Lesen Sie das Daemon-Log statt des Desktop-Dialogs, denn der Dialog fasst mehrere verschiedene Fehler zu einer Meldung zusammen. Ein NO_PROPOSAL_CHOSEN-Fehler gehört zur ersten Phase: Der Client hat eine Verschlüsselung, einen Hash oder eine Diffie-Hellman-Gruppe angeboten, die der Server nicht akzeptiert. Zählen Sie auf, was das Gerät unterstützt, und schreiben Sie einen passenden Vorschlag, denn zufällige Kombinationen erzeugen meist denselben Fehler langsamer. Auf dem Desktop ist der praktische Client das NetworkManager-Plugin L2TP mit strongSwan oder Libreswan darunter.

Eine Vorschlagszeichenfolge, die für ein Desktop-Plugin eines bedeutet, kann für den Daemon, dem es die Arbeit übergibt, etwas anderes bedeuten, halten Sie die Syntax also passend zur Ebene, die Sie bearbeiten. Verlangt das Gerät zusätzlich ein Tunnelgeheimnis, ist das eine eigene Stufe getrennt vom IPsec-Schlüssel. Bestätigen Sie, nach welchem von beiden die Oberfläche fragt, bevor Sie etwas hineintippen.

Aggressives IKEv1 mit XAuth und der Portal-Fall

Ein Endpunkt im FortiGate-Stil will meist aggressiven Modus mit XAuth und eine Adresse im konfigurierten Modus, was ein grafisches Plugin womöglich gar nicht anbietet. Der native Daemon beherrscht es, und der Block unten ist die Form dieser Konfiguration, keine vollständige Datei. Prüfen Sie die aktuelle Dokumentation des Herstellers für die Vorschlagswerte.

conn branch
    keyexchange=ikev1
    aggressive=yes
    leftauth=psk
    leftauth2=xauth
    leftsourceip=%config
    right=203.0.113.10

Ältere strongSwan-Versionen nutzten xauth=client, wo Version 5 leftauth2=xauth nutzt, ein kopiertes Snippet kann also allein an der Syntax scheitern. Für ein TLS-Portal bewältigt openconnect, das das AnyConnect-Protokoll spricht, Cisco und die meisten umbenannten Marken, und es braucht ein TUN-Gerät plus die Rechte, es zu konfigurieren. Übergeben Sie die Portaladresse genau so, wie der Browser sie zeigt, einschließlich jedes Pfads, den das Gerät erwartet, und prüfen Sie dann die zugewiesene Adresse, bevor Sie irgendetwas dahinter testen. Die Schnittstelle vorab anzulegen nimmt eine Klasse von Überraschungen bei der Einrichtung heraus.

sudo ip tuntap add dev tun0 mode tun
sudo openconnect --protocol=anyconnect vpn.example.com

Verbinden, dann in fester Reihenfolge verifizieren

Betreiben Sie immer genau einen VPN-Manager, denn ein NetworkManager-Profil und ein von Hand gestarteter Daemon streiten um Routen und DNS. Nehmen Sie das Profil herunter, bevor Sie eine manuelle Verbindung testen, und stellen Sie sicher, dass keine alte Tunnelschnittstelle überlebt. Verifizieren Sie dann in dieser Reihenfolge: Tunneladresse, Route zum einzigen internen Host, den Sie brauchen, Namensauflösung und zuletzt eine tatsächliche Anfrage. Ein grünes Symbol beweist die Authentifizierung und sonst nichts.

ip -4 addr show tun0
ip route get 10.20.30.10
getent hosts app.internal

Scheitert ein Schritt, halten Sie dort an, statt den nächsten zu testen, denn ein DNS-Fehler hinter einer kaputten Route lehrt Sie nichts. Sichern Sie eine Kopie des funktionierenden Profils, bevor Sie experimentieren, denn eine gelöschte Verbindungsdatei ist schnell verloren und mühsam neu zu bauen. Bewahren Sie die Vorschlagswerte in derselben Notiz wie Gerätemodell und Firmware-Version auf, denn diese Notiz ist der Unterschied zwischen einer Migration und einem Archäologieprojekt, wenn die Kiste ersetzt wird.