Pourquoi les VPN sont nuls et comment y remédier ?

C'est le milieu de la journée et vous travaillez sur un problème difficile qui demande un peu d'attention. Un utilisateur vous contacte parce qu'il ne peut pas se connecter au VPN. Il s'agit peut-être d'un problème de mot de passe ou d'un endroit qui bloque les VPN. Vous avez peut-être de la chance et le niveau 1 s'est occupé de ce problème, mais vous n'avez pas eu de chance après qu'il soit remonté jusqu'à vous.

Les problèmes liés aux VPN ne figurent jamais en tête de nos listes de choses à faire, car les VPN devraient fonctionner, du moins jusqu'à ce qu'ils ne fonctionnent plus. Voici un aperçu des raisons pour lesquelles les VPN sont parfois frustrants - et comment vous pouvez les aider à mieux fonctionner.

Manque de diversité des protocoles dans la mise en œuvre des VPN

Une bonne mise en œuvre d'un VPN de point à site (P2S) ou d'utilisateur offre aux utilisateurs finaux quelques méthodes de connectivité, même si les options sont transparentes et négociées automatiquement. L'absence de ces options peut poser des problèmes. IPsec a parfois des problèmes avec les services Internet des hôtels, en particulier lorsqu'ils utilisent des routeurs bas de gamme ou domestiques. Si vous n'avez pas d'option de rechange, vos utilisateurs finaux ne pourront tout simplement pas se connecter. Cela ne donne pas une bonne image de l'informatique lorsqu'un utilisateur final doit quitter un hôtel et en trouver un autre avec un Internet plus compatible avec votre VPN.

Par exemple, Palo Alto Global Protect et Cisco AnyConnect prennent en charge les VPN IPsec et SSL. OpenVPN en est un autre qui a la particularité d'avoir des options UDP et TCP et une sélection transparente de celles-ci par défaut. L'ancien client VPN Cisco utilisait principalement l'IPsec, mais permettait une option TCP.

IPsec reste l'un des protocoles préférés, en particulier pour le S2S mais aussi pour le P2S. Il fonctionne à un niveau inférieur de la couche OSI et présente donc moins de frais généraux. Il s'agit d'un protocole normalisé, qui offre donc une interopérabilité entre les fournisseurs. Cela dit, il présente souvent des difficultés avec le NAT et DS-Lite (IPv6 Dual Stack Lite). Ces problèmes peuvent aller des performances à l'absence totale de fonctionnement.

D'autre part, les VPN SSL ont tendance à mieux fonctionner avec le NAT car les dispositifs d'inspection dynamique comme les pare-feu comprennent le trafic et le font depuis un certain temps. Ils perçoivent le trafic comme étant identique à tout autre trafic TLS et n'interfèrent généralement pas.

La solution : disposer de plusieurs options

Assurez-vous que votre solution offre plusieurs options de protocoles VPN, le cas échéant. À l'époque du client VPN Cisco, cela impliquait l'ouverture d'un port TCP et la configuration manuelle d'une connexion dans le client. Aujourd'hui, de nombreuses solutions VPN négocient automatiquement quelques protocoles et il suffit de s'assurer que les ports appropriés sont ouverts.

De nombreuses organisations disposent de listes de contrôle d'accès (ACL) largement ouvertes sur leur point de terminaison VPN, ce qui devrait permettre d'ouvrir tous les ports nécessaires. Si vous limitez l'accès à cette IP, assurez-vous que les ports et les protocoles appropriés sont autorisés à se connecter. Pour IPsec, assurez-vous qu'au moins UDP/500 (pour IKE) et Internet Protocol 50 (ESP) et Internet Protocol 51 (AH) sont ouverts. Les protocoles Internet sont souvent confondus avec les ports TCP/UDP.

Assurez-vous de lire la documentation de votre fournisseur sur les ports qu'il utilise - et les protocoles autorisés. Essayez également de tester manuellement chaque protocole autorisé pour vous assurer qu'il fonctionne. Si votre solution VPN bascule automatiquement vers différents protocoles, vous devrez peut-être utiliser Wireshark pour valider la connexion.

Dimensionnement des paquets et encapsulation sur les VPN

Un ensemble de problèmes qu'un administrateur réseau rencontrera parfois lors de nouveaux déploiements de VPN est lié à l'unité de transmission maximale (MTU) et à la taille maximale de segment (MSS). Par défaut, le MTU et le MSS sont généralement configurés de manière appropriée et capables d'accueillir des tunnels VPN. Le MTU est la taille maximale de la trame et est généralement de 1500 octets. Le MSS exclut les en-têtes IP et TCP, qui font chacun 20 octets pour IPv4. Pour correspondre au MTU, un MSS serait traditionnellement réglé sur 1460 octets pour respecter le MTU de 1500 octets.

Comme nous encapsulons les paquets IP dans un paquet IPsec, ils pourraient dépasser la limite de 1500 octets en raison de l'en-tête IPsec supplémentaire. Pour tenir compte de cette surcharge et de divers scénarios, Cisco ASA définit par défaut un MTU de 1380. D'autres fournisseurs vous permettent de définir cette valeur par interface, comme une interface VPN, ou sont suffisamment intelligents pour le faire dynamiquement pour le trafic IPsec ou tout autre trafic encapsulé.

Lorsque cette valeur est trop basse, par exemple 1280 pour le trafic IPv4, le nombre de paquets envoyés est plus élevé. Par exemple, si vous avez un paquet de 1300 octets, il devient maintenant deux paquets alors qu'un MSS de 1380 lui aurait permis de rester un seul. Si vous le fixez trop haut, certains paquets qui atteignent le MTU seront abandonnés car ils sont trop volumineux. Il est toujours recommandé de rechercher les meilleures pratiques MTU et MSS pour le fournisseur et la plate-forme que vous utilisez lorsque vous mettez en œuvre une solution VPN ou que vous en prenez l'administration.

La solution : Utiliser les meilleures pratiques

Commencez par les meilleures pratiques de votre produit VPN ou pare-feu. Cisco ASA utilise par défaut un TCP MSS de 1380 pour IPv4, ce qui est généralement la meilleure option en supposant un MTU de 1500 octets, tandis que Palo Alto et d'autres solutions de nouvelle génération peuvent le faire automatiquement ou peuvent simplement exiger que le MTU de l'interface du tunnel soit de 1460.

Ce que nous voulons éviter, c'est de définir incorrectement ce paramètre sur désactivé ou sur un nombre extrêmement bas tel que 1280. Cependant, vous voulez vous assurer qu'il n'est pas réglé trop haut, comme 1460, lorsqu'il doit avoir plus de surcharge et que le dispositif ne "serre" pas automatiquement les paquets.

VPN et décisions de conception commerciale

Certains des plus gros problèmes de VPN sont liés à des décisions commerciales. Un exemple de ces décisions est l'emplacement des points de terminaison VPN. Souvent, ces décisions sont liées à des contraintes budgétaires. Si vous avez un centre de données unique, la décision se fait généralement d'elle-même quant à l'emplacement principal.

Disposez-vous d'un site de reprise après sinistre (DR) ? Le VPN existe-t-il ou n'a-t-il pas été prévu dans le budget ? Avez-vous des utilisateurs dans un autre pays, mais vous leur faites utiliser un VPN vers un point de terminaison à l'autre bout du monde dans votre centre de données ?

La solution : Point de présence

Idéalement, nous voulons fournir aux utilisateurs un point de terminaison VPN qui soit géographiquement proche d'eux. C'est ce qu'on appelle parfois un point de présence (POP). Les tentatives de réouverture et la latence peuvent nuire aux protocoles VPN et au trafic encapsulé sous-jacent. Cela nécessite une certaine forme de backhauling, généralement via un circuit privé. Le backhauling peut se faire via IPsec S2S, mais des mesures doivent être prises pour s'assurer que le POP est bien visible à l'autre extrémité du tunnel S2S. Il est recommandé de pouvoir basculer les transporteurs en raison de problèmes de peering ou d'autres problèmes de latence.

Si vous avez un site DR froid, essayez de rendre la solution VPN active afin que les utilisateurs puissent l'utiliser comme sauvegarde. Cela permet d'assurer la maintenance de la solution VPN primaire tout en permettant aux utilisateurs de se connecter si nécessaire. C'est également un excellent banc d'essai pour appliquer les mises à jour en premier.

Formation et auto-assistance VPN
Les problèmes de mot de passe ne devraient pas exister, n'est-ce pas ? Il n'y a rien de pire qu'un afflux constant de demandes de support qui finissent par être des problèmes de mot de passe. Les expirations de mot de passe aggravent la situation. Les utilisateurs finaux reçoivent souvent des messages vagues qui semblent être un problème de réseau, mais qui se révèlent être un mauvais mot de passe, un mot de passe expiré ou un compte verrouillé.

Ils ne peuvent pas faire la différence en raison des informations limitées que le client VPN leur donne. Souvent, l'utilisateur a reçu un ordinateur portable sur lequel le client VPN est déjà installé. D'autres fois, ils reçoivent simplement de brèves instructions sur la façon d'installer et d'utiliser le client, mais c'est tout.

La solution : Documentation
Une documentation doit être fournie à l'utilisateur pour l'aider à résoudre son problème. Les utilisateurs intensifs et les travailleurs itinérants sont généralement assez réceptifs à la documentation car leur emploi du temps ne leur laisse pas beaucoup de temps pour travailler avec le support informatique. Cette documentation doit inclure la manière d'installer/de réinstaller et de reconfigurer le logiciel VPN.

Une bonne documentation comprend également certaines erreurs courantes et la manière de les corriger. Lorsque vous travaillez hors ligne avec les utilisateurs par e-mail ou par chat, faites référence à votre documentation pour qu'ils en prennent connaissance. Lorsque vous travaillez directement avec eux, résumez et indiquez des extraits ou des citations de la documentation au lieu de leur envoyer un lien et de leur dire de la lire. Cela contribue grandement à leur faire prendre conscience de l'existence de la documentation et de son utilité. Ils seront plus enclins à la lire en premier la prochaine fois.

Mettez en place un portail en libre-service. Les portails en libre-service sont un moyen idéal d'atténuer les problèmes liés aux mots de passe. Ils peuvent adopter une approche proactive de l'expiration des mots de passe en avertissant l'utilisateur à l'avance. Veillez toutefois à ce que l'utilisateur dispose d'un délai suffisant pour agir. L'idéal serait de le faire plus de sept jours à l'avance pour tenir compte des utilisateurs en vacances au moment de l'envoi des avis.

Dernières réflexions
Souvent, les VPN fonctionnent bien, mais si votre environnement connaît des problèmes récurrents, envisagez certains des cas et solutions ci-dessus. Parfois, il s'agit simplement d'un problème de perception et de formation des utilisateurs finaux. D'autres fois, ce sont des problèmes de configuration mineurs qui doivent être réglés. Plus vous parviendrez à rationaliser vos services VPN, plus vous aurez de temps pour vous concentrer sur des tâches plus critiques.

Problème courant L2TP/Ipsec

VPN obsoléte pour gestion d' entreprise ?