Salut
>>>Nous sommes une petite organisation dont nous n’avons besoin que d’au plus moins de 10 personnes qui ont besoin du VPN, n’est-ce toujours pas pratique, avons-nous encore >>> besoin de faire un serveur CA interne
1. Eh bien, cela dépend. Si vous n’avez aucun problème avec les coûts / budget / dépenses pour l’achat de certificats distincts pour le serveur VPN et 10 clients VPN, vous pouvez aller de l’avant et obtenir les certificats auprès d’une autorité de certification commerciale et installer ces certificats dans RV340 et dans les 10 clients.
2. MAIS dans les deux cas (soit vous procurer auprès d’une autorité de certification commerciale, soit créer vos propres certificats en installant votre propre autorité de certification interne sur une machine interne), vous DEVEZ vous souvenir de 1 chose:
- Pour le certificat sur VPN-Server (RV34X), assurez-vous que
a) la valeur fieild « Common Name/CN » est définie sur un nom de domaine complet/DNS du serveur VPN tel que votre nom de domaine dns enregistré (disons pour l’hypothèse de son « example.com ») tel que vpnservergw.example.com ou rv34x.example.com OU si vous utilisez un serveur dyns-dns, il peut être rv34x.dyndns.org ou vpnservergw.dyndns.org
b) le même nom de domaine complet dans le CN/CommonName doit également être défini comme « subject-Alt-Name » dans le certificat :
DNS:rv34x.exemple.com
ou
DNS:vpnservergw.exemple.com
ou
DNS:rv34x.dyndns.org
- Pour les 10 clients-certificats, assurez-vous que chacun des certificats-clients a une valeur individuelle/distincte pour le champ subject-alt-name dans le certificat client sous la forme d’email-id, comme ci-dessous (en supposant que vous utilisez votre nom de domaine enregistré « example.com »
pour le certificat client1, le nom subject-alt-name doit être défini comme par exemple : client1@example.com
pour le certificat client2, le nom subject-alt-name doit être défini comme par exemple : client2@example.com
pour le certificat client3, le nom subject-alt-name doit être défini comme par exemple : client3@example.com
.... et ainsi de suite
>>>> Votre réponse me fait réaliser que nous ne décidons peut-être pas correctement. Dans notre cas, un PSK serait-il aussi sûr qu’un certificat? Dans mon >>>mind, le grand avantage du certificat est que nous pouvons expirer / invalider les certificats via l’autorité de certification, mais s’il n’y a que 10 d’entre nous et seulement 1 site, je >>>pourrait facilement annuler ou modifier le PSK. Qu’en penses-tu.
Ok, les informations que vous devez connaître en référence aux serveurs IKEv2-VPN pour les clients IKEv2-VPN sont:
Il peut y avoir différentes méthodes qui pourraient être confgurées / définies, mais par configurations de base standard, il existe 3 méthodes pour confgurer / utiliser le serveur VPN IKEv2 pour les clients VPN
1. Le serveur VPN IKEv2 utilisant PSK pour l’authentification
- Ici, l’authentification psk consiste à authentifier mutuellement le serveur VPN et les clients VPN en tant que pairs ipsec, et donc il n’y a PAS de nom d’utilisateur / mot de passe impliqué dans cet établissement de tunnel
- Seuls les clients Greenbow et MacOS/iOS IKEv2 prennent en charge cette méthode
- Le client windows-IKev2 natif ne prend pas en charge l’ikev2-auth basé sur PSK (il ne prend en charge que Certificates-Only et EAP-Mschapv2 avec nom d’utilisateur/passwd, ainsi que EAP-TLS)
2. Serveur VPN IKEv2 utilisant des certificats pour l’authentification ike
a) Ici aussi, seuls les certificats sont utilisés à la fois sur le serveur VPN et les clients pour l’authentification mutuelle des pairs IPsec (serveur et client)
- et il n’y a pas d’utilisation de nom d’utilisateur/mot de passe pour l’authentification étendue
- Le client windows-IKEv2 natif prend en charge cela (vous devez sélectionner la case d’option « certificats machine » dans les sections de configuration du client)
- Les clients Greenbow et MacOS / iOS prennent également en charge
- Dans ce cas, le serveur et les clients doivent avoir leurs propres certificats distincts qui seront utilisés pour effectuer l’authentification mutuelle IKEv2 des pairs.
b) Alors, comment chacun des types de clients obtient-il l’authentification ikev2 à l’aide de certificats?
Sur le client IKEv2 natif Windows
----------------------------
- En ce qui concerne le client windows-ikev2 natif, il n’y a pas de configuration pour définir/sélectionner la valeur subject-alt-name dans le client-cert.
- Ainsi, windows first server enverra son certificat serveur qui sera vérifié/authentifié sur le client windows à l’aide du certificat Root-CA du certificat serveur qui a été importé dans le client précédemment. Ensuite, le client Windows lui-même enverra simplement le champ de nom d’objet (connu sous le nom de champ DN ou simplement ASN1DN) de son client-cert au serveur VPN qui sera vérifié et validé sur le serveur VPN à l’aide du rootCA-cert qui avait signé le client-cert
Sur Greenbow-client
-------------------
- Sur ce client, il serait préférable d’utiliser la valeur U-FQDN dans son certificat client en tant qu’ID local
- et donc d’abord il va authentifier le certificat du serveur à l’aide du certificat Root-CA qui a signé le server-cert
- et ensuite, le client GB enverra son certificat au serveur, où en fonction des configurations, le vpn-server utilisera soit le champ d’objet du client-cert OU vérifie le subject-altname pour la valeur U-FQDN (clientX@example.com) dans le client-cert et correspond à la valeur de l’identificateur distant qui a été configuré sur le serveur vpn
Sur le client MacOS
---------------
- Ici, nous allons configurer la valeur UFQDN dans le champ subject-alt-name du client-cert installé sur ce macOS
- Cette valeur sera configurée en tant que Local-ID dans le client macOS
- Le processus d’authentification du certificat vpn-server sur mac-client à l’aide du certificat RootCA, et l’authentification du client en fonction de la valeur du champ Remote-ID défini sur le serveur. L’ID requis/pertinent est vérifié dans le champ subject-alt-name du client-cert
3. Serveur VPN IKEv2 utilisant des méthodes EAP (telles que EAP-Mschapv2 avec nom d’utilisateur / passwd)
- Ici, dans ce cas, le vpn-server sera authentifié à l’aide du server-cert envoyé au client (vérifié sur le client à l’aide du RootCA-cert que vous aviez importé sur le client au début lui-même)
- Et sur le client, il n’y a AUCUN certificat installé.
- Et le client s’authentifiera à l’aide d’EAP (dans ce cas, ce sera EAP-Mschapv2 en utilisant le username-passwd configuré sur les clients)
