IPsec FortiGate sous Linux : quel client se connecte vraiment

Votre collègue sous Windows importe un profil de l'assistant FortiGate et est en ligne en une minute. Vous installez le même paquet du fournisseur sur Ubuntu, cherchez un onglet IPsec et trouvez un client qui ne sait qu'ouvrir un SSL VPN portail. La conclusion qui suit est généralement fausse deux fois : la passerelle ne vous rejette pas, et la compilation Linux n'est pas cassée. Fortinet livre ce client avec la seule prise en charge SSL VPN, donc un profil IPsec mobile n'a nulle part où vivre et doit être reconstruit là où l'on parle IKEv1.

D'abord, déterminez quel protocole on vous a réellement donné

Cette reconstruction est mécanique dès que vous cessez de considérer le client du fournisseur comme l'implémentation de référence.

Les équipements FortiGate publient à la fois SSL VPN et IPsec, et l'e-mail de remise dit rarement lequel vous a été accordé. Une URL de portail plus une page de connexion de style navigateur signifient SSL VPN, et sous Linux la réponse y est openfortivpn, pas la correspondance des champs ci-dessous. Un identifiant de groupe plus une clé pré-partagée signifient IPsec mobile, ce que gèrent vpnc et strongSwan.

Se tromper là-dessus est la raison la plus fréquente pour laquelle une tentative Linux meurt avant la fin de la première phase : le client propose IKEv1 à un portail HTTPS ou l'inverse. Demandez le nom du protocole par écrit à l'administrateur avant d'installer quoi que ce soit.

Quatre secrets voyagent dans quatre champs différents

Le mot password apparaît deux fois dans la plupart des remises et signifie deux choses différentes. La clé pré-partagée authentifie le pair lui-même, et c'est un secret machine que l'administrateur lit dans la configuration de la passerelle. Le mot de passe de votre compte est un secret distinct qui prouve quel humain se trouve derrière ce pair.

Les deux autres valeurs sont plus faciles à manquer. L'identifiant de groupe est la chaîne que l'assistant a écrite dans l'objet de groupe IPsec, et 0 est une valeur légitime et non un champ vide. La proposition couvre le chiffrement, le hachage et un groupe Diffie-Hellman pour chaque phase, plus le réglage PFS, et chaque élément doit s'accorder avec la passerelle. Quand une connexion échoue en phase 1, l'un de ces quatre est presque toujours le coupable, alors notez-les séparément plutôt que de les jeter dans une seule boîte de dialogue.

Ce que chaque champ de vpnc doit contenir

Installez le client avec l'interface d'édition, puis créez une connexion VPNC :

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

Réglez la passerelle sur l'adresse publique du FortiGate, et le nom de groupe exactement sur l'identifiant issu de la passerelle, y compris un zéro nu. Group password prend la clé pré-partagée, tandis que le nom d'utilisateur et le mot de passe prennent votre compte, avec tout jeton ajouté comme la passerelle l'attend. Dans la boîte de dialogue avancée, choisissez le groupe Diffie-Hellman que nomme la proposition, alignez PFS sur le même groupe, activez la traversée NAT lorsque le client est derrière un routeur domestique, et laissez la détection de pair mort au même pas que la passerelle.

Le nom de groupe est le champ que l'on saute, parce qu'il paraît facultatif et que la valeur par défaut zéro ressemble à un espace réservé. Envoyez-le vide et le client transmet un identifiant différent de celui que la passerelle valide. Si le profil échoue encore, comparez les valeurs avancées au client Windows qui fonctionne plutôt qu'à un message de forum pour un autre site.

Le même profil écrit pour strongSwan

strongSwan est le meilleur conteneur à long terme pour ces valeurs, car la configuration est un fichier texte que vous pouvez relire et conserver :

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!

Lisez les lignes de proposition avant le bloc, car le point d'exclamation final change leur sens : il épingle cette seule proposition et retire les alternatives que le client offrirait autrement. Une passerelle configurée pour une seule paire de transformations rejettera un client qui s'ouvre avec une liste, donc c'est l'épinglage qui transforme une négociation en correspondance. Prenez les noms exacts des algorithmes dans le profil de passerelle qui fonctionne, et remplacez les espaces réservés par vos propres valeurs.

Les deux lignes d'authentification ne sont pas redondantes. La PSK prouve le pair, le bloc XAuth prouve l'utilisateur, et retirer l'une ou l'autre laisse une phase que la passerelle ne terminera pas.

Lisez l'échec avant de changer encore un champ

Travaillez à rebours depuis le symptôme au lieu de re-tirer la boîte de dialogue au hasard. Un IKE SA qui monte sans adresse attribuée signifie que l'échange d'authentification de l'utilisateur a échoué ou n'a jamais eu lieu, alors vérifiez le compte et la gestion du jeton. Une phase 1 qui ne se termine jamais pointe vers la proposition, l'identifiant de groupe ou le mode agressif, et chacun de ces éléments se compare à la passerelle, pas seulement au client Windows.

Un tunnel qui s'établit puis meurt toutes les quelques minutes est un désaccord de détection de pair mort entre les deux extrémités ; alignez le minuteur de la passerelle plutôt que de désactiver les keepalives partout. Un tunnel établi où les hôtes du bureau restent injoignables signifie généralement que le sous-réseau poussé n'est jamais arrivé dans la table de routage locale, ce qu'un client tiers ne fait peut-être pas de lui-même.

Rendez les valeurs qui fonctionnent au propriétaire de la passerelle lorsque vous avez fini : protocole, identifiant de groupe, clé pré-partagée, proposition, PFS et la décision DPD. La machine Linux suivante prend alors des minutes au lieu d'une soirée, et personne n'a besoin de redécouvrir que le nom de groupe valait zéro.