4 votes

Soufiane Hassou avatar

Comment configurer StrongSwan pour qu'il agisse en tant que client IKEv1 ?

Demandé el 5 de Juin, 2017
Quand la question a-t-elle été
18226 affichage
Nombre de visites la question a
1 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

Un client de notre entreprise de développement nous a donné accès à son VPN IPSec en nous fournissant les informations d'identification nécessaires (anonymisées) :

  • Passerelle : example.fake
  • Le groupe : MYGROUP
  • Utilisateur : MYUSER
  • Mot de passe : MYPASSWORD
  • PSK : MYPSK

Ils ont également fourni les paramètres configurés de leur côté :

Phase 1

  • Authentification : SHA1
  • Chiffrement : AES 256
  • Durée de vie de l'AS : 1 heure
  • Groupe clé : Groupe Diffie Helman 2
  • NAT Traversal et DPD sont activés
  • Intervalle de maintien : 20 secondes

Phase 2

  • Type : ESP
  • Authentification : SHA1
  • Chiffrement : AES 256
  • Forcer l'expiration de la clé : 1 heure

Le type de connexion est IKEv1 et ils ont configuré l'accès à travers le tunnel VPN uniquement sur une IP spécifique 1.2.3.4 parce que c'est la seule machine que nous devons atteindre.

Objectif et tentative

J'essaie de comprendre comment configurer StrongSwan pour qu'il se connecte à leur VPN. J'ai besoin que cela fonctionne sur un VPS avec Ubuntu Server 16.04.

J'ai essayé de suivre un certain nombre de guides, mais certains concernaient des versions plus anciennes de StrongSwan et n'ont donc pas fonctionné. Finalement, j'ai édité /etc/ipsec.conf avec la tentative de configuration suivante :

config setup

conn myconn
    authby=xauthpsk
    dpdaction=restart
    esp=aes256-sha1
    ike=aes256-sha1-dh2
    ikelifetime=1h
    keyexchange=ikev1
    leftauth=psk
    leftauth2=xauth
    leftgroups=MYGROUP
    leftid=@MYUSER
    right=example.fake
    rightsubnet=1.2.3.4/32

J'ai créé /etc/ipsec.secrets :

: PSK "MYPSK"
MYUSER: XAUTH "MYPASSWORD"

État final souhaité et message d'erreur

L'état final souhaité est que notre machine se connecte au VPN du client et que nous puissions atteindre cette seule IP 1.2.3.4. Le reste du trafic doit être divisé et ne pas passer par le VPN.

Malgré le fait que myconn est défini dans /etc/ipsec.conf Le message d'erreur suivant s'affiche lors de la tentative de connexion :

# ipsec restart
Stopping strongSwan IPsec...
Starting strongSwan 5.3.5 IPsec [starter]...
# ipsec up myconn
no config named 'myconn'

Fichiers journaux

Ces lignes sont ajoutées à /var/log/syslog après avoir couru ipsec restart :

Jun  5 16:45:01 server charon: 00[DMN] signal of type SIGINT received. Shutting down
Jun  5 16:45:03 server charon: 00[DMN] Starting IKE charon daemon (strongSwan 5.3.5, Linux 4.8.0-53-generic, x86_64)
Jun  5 16:45:03 server charon: 00[CFG] disabling load-tester plugin, not configured
Jun  5 16:45:03 server charon: 00[LIB] plugin 'load-tester': failed to load - load_tester_plugin_create returned NULL
Jun  5 16:45:03 server charon: 00[CFG] dnscert plugin is disabled
Jun  5 16:45:03 server charon: 00[CFG] ipseckey plugin is disabled
Jun  5 16:45:03 server charon: 00[CFG] attr-sql plugin: database URI not set
Jun  5 16:45:03 server charon: 00[CFG] loading ca certificates from '/etc/ipsec.d/cacerts'
Jun  5 16:45:03 server charon: 00[CFG] loading aa certificates from '/etc/ipsec.d/aacerts'
Jun  5 16:45:03 server charon: 00[CFG] loading ocsp signer certificates from '/etc/ipsec.d/ocspcerts'
Jun  5 16:45:03 server charon: 00[CFG] loading attribute certificates from '/etc/ipsec.d/acerts'
Jun  5 16:45:03 server charon: 00[CFG] loading crls from '/etc/ipsec.d/crls'
Jun  5 16:45:03 server charon: 00[CFG] loading secrets from '/etc/ipsec.secrets'
Jun  5 16:45:03 server charon: 00[CFG]   loaded RSA private key from '/etc/ipsec.d/private/myKey.der'
Jun  5 16:45:03 server charon: 00[CFG] sql plugin: database URI not set
Jun  5 16:45:03 server charon: 00[CFG] opening triplet file /etc/ipsec.d/triplets.dat failed: No such file or directory
Jun  5 16:45:03 server charon: 00[CFG] eap-simaka-sql database URI missing
Jun  5 16:45:03 server charon: 00[CFG] loaded 0 RADIUS server configurations
Jun  5 16:45:03 server charon: 00[CFG] no threshold configured for systime-fix, disabled
Jun  5 16:45:03 server charon: 00[CFG] coupling file path unspecified
Jun  5 16:45:03 server charon: 00[LIB] loaded plugins: charon test-vectors unbound ldap pkcs11 aes rc2 sha1 sha2 md4 md5 rdrand random nonce x509 revocation constraints acert pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey dnscert ipseckey pem openssl gcrypt af-alg fips-prf gmp agent chapoly xcbc cmac hmac ctr ccm gcm ntru bliss curl soup mysql sqlite attr kernel-netlink resolve socket-default connmark farp stroke updown eap-identity eap-sim eap-sim-pcsc eap-aka eap-aka-3gpp2 eap-simaka-pseudonym eap-simaka-reauth eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap eap-tnc xauth-generic xauth-eap xauth-pam xauth-noauth tnc-tnccs tnccs-20 tnccs-11 tnccs-dynamic dhcp whitelist lookip error-notify certexpire led radattr addrblock unity
Jun  5 16:45:03 server charon: 00[LIB] dropped capabilities, running as uid 0, gid 0
Jun  5 16:45:03 server charon: 00[JOB] spawning 16 worker threads

Ils sont ajoutés après l'exécution de ipsec up myconn :

Jun  5 16:45:21 server charon: 15[CFG] received stroke: initiate 'myconn'
Jun  5 16:45:21 server charon: 15[CFG] no config named 'myconn'

Elles semblent correspondre au message d'erreur susmentionné.

クエスチョン

Pourquoi les ipsec up myconn dire qu'une telle configuration n'existe pas ? C'est la première fois que j'essaie de gérer un VPN IPSec... est-ce que la configuration que j'ai essayé d'écrire a un sens ?

Que dois-je modifier pour que cela fonctionne ?

Mise à jour après l'ajout de auto=add

Comme suggéré dans les commentaires, j'ai ajouté auto=add à ma configuration. J'obtiens maintenant ceci :

# ipsec up myconn
initiating Main Mode IKE_SA myconn[1] to <IP of example.fake>
configuration uses unsupported authentication
tried to check-in and delete nonexisting IKE_SA
establishing connection 'myconn' failed

Ces lignes sont ajoutées au fichier journal :

Jun  5 17:07:19 server charon: 12[CFG] received stroke: initiate 'myconn'
Jun  5 17:07:19 server charon: 14[IKE] initiating Main Mode IKE_SA myconn[2] to <IP of example.fake>
Jun  5 17:07:19 server charon: 14[CFG] configuration uses unsupported authentication
Jun  5 17:07:19 server charon: 14[MGR] tried to check-in and delete nonexisting IKE_SA

Mise à jour après suppression esp= , ike= y keyexchange=

Après avoir supprimé les trois lignes mentionnées ci-dessus, la tentative de connexion se déroule comme suit, à trois reprises (l'extrait ne montre que la première, les autres sont identiques) :

Jun  5 17:18:44 server charon: 06[CFG] received stroke: initiate 'myconn'
Jun  5 17:18:45 server charon: 04[IKE] initiating IKE_SA myconn[1] to <IP of example.fake>
Jun  5 17:18:45 server charon: 04[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) ]
Jun  5 17:18:45 server charon: 04[NET] sending packet: from <our server IP>[500] to <IP of example.fake>[500] (1500 bytes)
Jun  5 17:18:49 server charon: 03[IKE] retransmit 1 of request with message ID 0
Jun  5 17:18:49 server charon: 03[NET] sending packet: from <our server IP>[500] to <IP of example.fake>[500] (1500 bytes)
Jun  5 17:18:56 server charon: 15[IKE] retransmit 2 of request with message ID 0
Jun  5 17:18:56 server charon: 15[NET] sending packet: from <our server IP>[500] to <IP of example.fake>[500] (1500 bytes)
Jun  5 17:19:09 server charon: 01[IKE] retransmit 3 of request with message ID 0
Jun  5 17:19:09 server charon: 01[NET] sending packet: from <our server IP>[500] to <IP of example.fake>[500] (1500 bytes)
Jun  5 17:19:32 server charon: 16[IKE] retransmit 4 of request with message ID 0
Jun  5 17:19:32 server charon: 16[NET] sending packet: from <our server IP>[500] to <IP of example.fake>[500] (1500 bytes)
Jun  5 17:20:14 server charon: 05[IKE] retransmit 5 of request with message ID 0
Jun  5 17:20:14 server charon: 05[NET] sending packet: from <our server IP>[500] to <IP of example.fake>[500] (1500 bytes)
Jun  5 17:21:30 server charon: 13[IKE] giving up after 5 retransmits
Jun  5 17:21:30 server charon: 13[IKE] peer not responding, trying again (2/3)

Mise à jour : configuration fonctionnelle pour ShrewSoft VPN

La connexion au VPN du client a été testée sur une machine de bureau au bureau, en utilisant ShrewSoft VPN, mais cela ne convient pas pour l'utiliser sur le VPS de développement. Ledit programme a exporté la configuration suivante :

n:version:4
n:network-ike-port:500
n:network-mtu-size:1380
n:client-addr-auto:1
n:network-natt-port:4500
n:network-natt-rate:15
n:network-frag-size:540
n:network-dpd-enable:1
n:network-notify-enable:1
n:client-banner-enable:1
n:client-dns-used:1
n:client-dns-auto:1
n:client-dns-suffix-auto:1
b:auth-mutual-psk:****REMOVED****
n:phase1-dhgroup:2
n:phase1-keylen:0
n:phase1-life-secs:86400
n:phase1-life-kbytes:0
n:vendor-chkpt-enable:0
n:phase2-keylen:0
n:phase2-pfsgroup:-1
n:phase2-life-secs:3600
n:phase2-life-kbytes:0
n:policy-nailed:0
n:policy-list-auto:1
s:network-host:example.fake
s:client-auto-mode:pull
s:client-iface:virtual
s:network-natt-mode:enable
s:network-frag-mode:enable
s:auth-method:mutual-psk-xauth
s:ident-client-type:keyid
s:ident-client-data:MYGROUP
s:ident-server-type:any
s:phase1-exchange:aggressive
s:phase1-cipher:auto
s:phase1-hash:auto
s:phase2-transform:auto
s:phase2-hmac:auto
s:ipcomp-transform:disabled
s:policy-level:auto

Cela suggère-t-il des changements à apporter à la ipsec.conf pour que cela fonctionne avec StrongSwan ?

Demandé el 5 de Juin, 2017 par Soufiane Hassou

Réponse

Trop de publicités?

1voto

HidekiAI avatar
HidekiAI Points 111

Il s'agit peut-être d'une réponse tardive, mais voici quelques indications sur des questions que j'ai observées (mais que je n'ai pas essayées/testées) :

  • authby est obsolète, et vous utilisez leftauth. Paramétrer explicitement leftauth/rightauth et leftauth2/rightauth2 serait utile. D'après mon expérience (et en regardant le code C sur github) pour IKEv1, il n'y a qu'un nombre limité de vérifications if/else, et lorsque left et right ne correspondent pas (autre que cualquier ), vous obtiendrez le message "unsupported authentication" (authentification non prise en charge).
  • Curieusement (et je n'ai pas regardé le code C pour le vérifier), il y a des affirmations selon lesquelles on peut doit avoir un de chaque côté du ':' dans vos fichiers secrets (c.-à-d. 'MYUSERS : XAUTH "MYPASSWORD"', sur le vôtre, vous n'avez pas d'espace dans MYUSER :)
  • En fonction de vos distros, certaines méthodes de cryptage peuvent ne pas être supportées (par exemple 3DES) - surveillez le journal charon pour les plugins afin de voir ce qui est chargé.
  • La personne qui a dit de supprimer "keyexchange" n'a pas tenu compte de votre question, à savoir que vous voulez IKEv1. Pour IKEv1, vous devez explicitement configurer keyexchange=ikev1 ; la valeur par défaut est 'ike', ce qui correspond à IKEv1 et IKEv2 côté serveur, et non côté client (ce qui signifie qu'en tant que serveur VPN, j'accepterai à la fois v1 et v2 de la part de mes clients). Dans votre cas, votre rouleau est un client, vous devez donc être explicite.
  • Je ne suis pas d'accord avec la suppression de esp= et ike= puisque vous avez indiqué explicitement dans votre OP quelle est votre Phase1 (est-ce dh2 ou aes256-sha1-modp2048 ?) et Phase2 ; Si vous pouvez mettre la main sur l'outil 'ike-scan' pour votre distro, utilisez-le à la place. Il vous donnera même des indications sur le fait que votre terminal supporte IKEv2. En général, ce que je découvre grâce à 'ike-scan', c'est si le point de terminaison supporte ou non le 3DES, étant donné que sur certaines distro, ils ne distribuent plus le 3DES en tant que partie du binaire.
  • J'ai remarqué que dans votre configuration Shrewsoft, vous avez mis agressive=yes, ce que vous pourriez aussi essayer dans ipsec.conf une fois que la phase 2 fonctionnera.
  • En supposant que 'left' est le côté client, et 'right' la passerelle distante, vous avez défini 'leftid' au lieu de 'rightid' - en fait, rightid doit correspondre à votre fichier .secrets, à moins que vous ne vouliez intentionnellement que la passerelle s'authentifie auprès de vous ?

Quelques autres conseils :

  • Réglez votre journal charon sur 'NET' et 'CFG' (choisissez) pour qu'il soit d'un niveau plus élevé en fonction de ce que vous déboguez (avec un niveau de journal suffisamment élevé, vous ne devriez même pas avoir besoin de tcpdump).
  • Comme nous l'avons mentionné plus haut, il est essentiel que à la fois correspondances auth/auth2 gauche et droite (même si la gauche est côté client) pour s'assurer que vous n'obtenez pas d'erreurs 'configuration sues unsupported...' (définir votre 'cfg' dans charon log n'aidera pas ici, j'ai dû regarder le code C)
  • Comme quelqu'un l'a mentionné, assurez-vous d'avoir au moins "auto=add" - un piège est lorsque vous faites "$ ipsec statusall Vous ne verrez pas votre "conn" s'il n'a pas été ajouté.

Dans tous les cas, quelques informations manquantes qui ont dû être déduites indirectement sur la base des configs et autres logs que vous auriez peut-être souhaité fournir plus tôt pour éviter les allers-retours sur les commentaires :

  • Phase 1 : PSK (prépartagé)
  • Phase 2 : xauth-radius

Je ne suis pas sûr de ce qu'utilise votre serveur VPN distant, mais je suppose qu'il est basé sur radius, assurez-vous de configurer correctement vos plugins xauth en fonction de cela.

Enfin, suivez scrupuleusement la documentation 'ipsec.conf' de Strongswan sur ce qui est supporté par IKEv1. De plus, si votre terminal est basé sur NTLM, rappelez-vous que les mots de passe NTLM sont encodés en MD4 (il suffit de chercher quelque chose dans le sens de l'introduction d'une chaîne UTF16 dans openssl en tant que MD4).

Répondu el 13 de Novembre, 2018 par HidekiAI (111 Points )

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X