FortiGate-IPsec unter Linux: Welcher Client sich wirklich verbindet

Ihr Windows-Kollege importiert ein FortiGate-Assistentenprofil und ist in einer Minute online. Sie installieren dasselbe Herstellerpaket auf Ubuntu, suchen einen IPsec-Reiter und finden einen Client, der nur ein SSL VPNPortal öffnen kann. Die Schlussfolgerung daraus ist meist doppelt falsch: Das Gateway weist Sie nicht ab, und der Linux-Build ist nicht kaputt. Fortinet liefert diesen Client nur mit SSL-VPN-Unterstützung, ein mobiles IPsec-Profil hat dort also keinen Platz und muss dort neu gebaut werden, wo IKEv1 gesprochen wird.

Zuerst klären, welches Protokoll Sie tatsächlich bekommen haben

Dieser Neubau ist mechanisch, sobald Sie aufhören, den Herstellerclient als Referenzimplementierung zu betrachten.

FortiGate-Geräte veröffentlichen sowohl SSL VPN als auch IPsec, und die Übergabe-E-Mail sagt selten, welches Sie erhalten haben. Eine Portal-URL plus eine Anmeldeseite im Browserstil bedeutet SSL VPN, und unter Linux ist die Antwort dort openfortivpn, nicht die Feldzuordnung unten. Eine Gruppenkennung plus ein vorab geteilter Schlüssel bedeutet mobiles IPsec, womit vpnc und strongSwan umgehen.

Das falsch zu machen ist der häufigste Grund, warum ein Linux-Versuch stirbt, bevor die erste Phase abgeschlossen ist: der Client bietet einem HTTPS-Portal IKEv1 an oder umgekehrt. Lassen Sie sich den Protokollnamen schriftlich vom Administrator geben, bevor Sie irgendetwas installieren.

Vier Geheimnisse reisen in vier verschiedenen Feldern

Das Wort Passwort kommt in den meisten Übergaben zweimal vor und bedeutet zwei verschiedene Dinge. Der vorab geteilte Schlüssel authentifiziert den Peer selbst, und er ist ein Maschinengeheimnis, das der Administrator aus der Gateway-Konfiguration liest. Ihr Kontopasswort ist ein eigenes Geheimnis, das belegt, welcher Mensch hinter diesem Peer steht.

Die anderen beiden Werte werden leichter übersehen. Die Gruppenkennung ist die Zeichenkette, die der Assistent in das IPsec-Gruppenobjekt geschrieben hat, und 0 ist ein gültiger Wert und kein leeres Feld. Der Vorschlag umfasst Verschlüsselung, Hashing und eine Diffie-Hellman-Gruppe für jede Phase sowie die PFS-Einstellung, und jeder Punkt darin muss mit dem Gateway übereinstimmen. Wenn eine Verbindung in Phase 1 scheitert, ist fast immer einer dieser vier schuld, also notieren Sie sie getrennt, statt sie in einen Dialog zu werfen.

Was jedes vpnc-Feld enthalten muss

Installieren Sie den Client zusammen mit der Editor-Oberfläche und legen Sie dann eine VPNC-Verbindung an:

sudo apt install vpnc network-manager-vpnc network-manager-vpnc-gnome

Setzen Sie das Gateway auf die öffentliche Adresse des FortiGate und den Gruppennamen exakt auf die Kennung vom Gateway, einschließlich einer bloßen Null. Group password nimmt den vorab geteilten Schlüssel auf, während Benutzername und Passwort Ihr Konto aufnehmen, mit einem eventuellen Token so angehängt, wie das Gateway es erwartet. Wählen Sie im erweiterten Dialog die Diffie-Hellman-Gruppe, die der Vorschlag nennt, gleichen Sie PFS auf dieselbe Gruppe ab, aktivieren Sie NAT-Traversal, wenn der Client hinter einem Heimrouter sitzt, und lassen Sie die Erkennung toter Peers im Gleichschritt mit dem Gateway.

Der Gruppenname ist das Feld, das übersprungen wird, weil er optional aussieht und der Standardwert null wie ein Platzhalter wirkt. Senden Sie ihn leer, überträgt der Client eine andere Kennung als die, die das Gateway prüft. Wenn das Profil weiterhin scheitert, vergleichen Sie die erweiterten Werte mit dem funktionierenden Windows-Client statt mit einem Forumsbeitrag für einen anderen Standort.

Dasselbe Profil für strongSwan geschrieben

strongSwan ist der bessere langfristige Behälter für diese Werte, denn die Konfiguration ist eine Textdatei, die Sie prüfen und aufbewahren können:

conn office-fw
    keyexchange=ikev1
    aggressive=yes
    left=%any
    leftauth=psk
    leftauth2=xauth
    xauth_identity=YOUR_USER
    right=GATEWAY_ADDRESS
    rightauth=psk
    rightsubnet=OFFICE_SUBNET
    ike=aes128-sha1-modp1536!
    esp=aes128-sha1-modp1536!

Lesen Sie die Vorschlagszeilen vor dem Block, denn das Ausrufezeichen am Ende ändert ihre Bedeutung: Es fixiert genau diesen einen Vorschlag und entfernt die Alternativen, die der Client sonst anbieten würde. Ein Gateway, das für ein einziges Transformationspaar konfiguriert ist, weist einen Client ab, der mit einer Liste beginnt, also macht erst die Fixierung aus einer Verhandlung eine Übereinstimmung. Nehmen Sie die genauen Algorithmusnamen aus dem funktionierenden Gateway-Profil und ersetzen Sie die Platzhalter durch Ihre eigenen Werte.

Die beiden Authentifizierungszeilen sind nicht überflüssig. Der PSK belegt den Peer, der XAuth-Block belegt den Benutzer, und wer eine davon weglässt, hinterlässt eine Phase, die das Gateway nicht beendet.

Lesen Sie den Fehler, bevor Sie ein weiteres Feld ändern

Arbeiten Sie vom Symptom rückwärts, statt den Dialog neu zu durchwürfeln. Eine IKE SA, die ohne zugewiesene Adresse hochkommt, bedeutet, dass der Authentifizierungsaustausch des Benutzers fehlschlug oder nie lief, also prüfen Sie Konto und Token-Behandlung. Eine Phase 1, die nie abschließt, deutet auf den Vorschlag, die Gruppenkennung oder den aggressiven Modus, und jeder davon wird mit dem Gateway verglichen, nicht nur mit dem Windows-Client.

Ein Tunnel, der aufgebaut wird und dann alle paar Minuten stirbt, ist eine Uneinigkeit bei der Erkennung toter Peers zwischen beiden Enden; gleichen Sie den Timer des Gateways ab, statt überall Keepalives abzuschalten. Ein bestehender Tunnel, in dem Büro-Hosts unerreichbar bleiben, bedeutet meist, dass das geschobene Subnetz nie in der lokalen Routing-Tabelle ankam, was ein Drittanbieter-Client womöglich nicht von selbst tut.

Geben Sie die funktionierenden Werte am Ende an den Gateway-Besitzer zurück: Protokoll, Gruppenkennung, vorab geteilter Schlüssel, Vorschlag, PFS und die DPD-Entscheidung. Die nächste Linux-Maschine braucht dann Minuten statt eines Abends, und niemand muss neu entdecken, dass der Gruppenname null war.