Bonjour ! Dans dans le précédent article J'ai décrit le fonctionnement de notre service MultiSIM en matière de réservation et équilibrage des canaux. Comme mentionné, nous connectons les clients au réseau via VPN, et aujourd'hui je vais en dire un peu plus sur le VPN et nos capacités dans ce domaine.
Il convient de commencer par le fait qu'en tant qu'opérateur de télécommunications, nous disposons de notre propre vaste réseau MPLS, qui pour les clients de téléphonie fixe est divisé en deux segments principaux — celui utilisé directement pour l'accès à Internet et celui utilisé pour créer des réseaux isolés — et c'est précisément à travers ce segment MPLS que transite le trafic IPVPN (L3 OSI) et VPLAN (L2 OSI) pour nos clients d'entreprise.
Généralement, la connexion d'un client se fait de la manière suivante.
Une ligne d'accès est tirée jusqu'au bureau du client depuis le Point de Présence réseau le plus proche (nœud MEN, PRTL, BSSS, FTTB, etc.) et ensuite, le canal est inscrit sur le réseau de transport jusqu'au routeur RE-MPLS correspondant, sur lequel nous le sortons dans un VRF spécialement créé pour le client, en tenant compte du profil de trafic nécessaire au client (les balises de profil sont choisies pour chaque port d'accès sur la base des valeurs de ip precedence 0,1,3,5).
Si pour une raison quelconque nous ne pouvons pas organiser complètement la dernière ligne au client, par exemple, si le bureau du client est situé dans un centre d'affaires où un autre fournisseur est prioritaire, ou qu'il n'y a tout simplement pas de point de présence à proximité, alors par le passé, les clients devaient créer plusieurs réseaux IPVPN chez différents fournisseurs (une architecture qui n’est pas la plus avantageuse en termes de coût) ou résoudre eux-mêmes les problèmes d'accès à leur VRF via le réseau Internet.
Beaucoup le faisaient en installant une porte d'entrée IPVPN Internet — en installant un routeur de périmètre (matériel ou une solution basée sur Linux), en le connectant avec un port au canal IPVPN et, avec l'autre, au canal Internet, en lançant sur celui-ci leur serveur VPN et en connectant les utilisateurs via leur propre passerelle VPN. Naturellement, un tel schéma entraîne aussi des charges : une telle infrastructure doit savoir être construite et, ce qui est le plus gênant, exploitée et développée.
Pour faciliter la vie de nos clients, nous avons mis en place un hub VPN centralisé et organisé le support des connexions sur Internet via IPSec. Ainsi, nos clients n'ont qu'à configurer leur routeur pour travailler avec notre hub VPN via un tunnel IPSec à travers n'importe quel Internet public, et nous émettrons le trafic de ce client dans son VRF.
À qui cela peut-il servir
- À ceux qui ont déjà un vaste réseau IPVPN et ont besoin de nouvelles connexions dans des délais serrés.
- À tous ceux qui, pour diverses raisons, souhaitent transférer une partie de leur trafic de l'Internet public à l'IPVPN, mais ont déjà rencontré des limitations techniques liées à plusieurs fournisseurs de services.
- À ceux qui ont actuellement plusieurs réseaux VPN disjoints chez différents opérateurs de télécommunication. Il existe des clients qui ont réussi à organiser l'IPVPN à la fois avec Beeline, MegaFon et Rostelecom, etc. Pour simplifier les choses, ils peuvent se limiter à notre offre unique. VPN, en redirigeant tous les autres canaux d'autres opérateurs vers l'Internet, puis en se connectant à l'IPVPN Beeline via IPSec et l'Internet de ces opérateurs.
- À ceux qui disposent déjà d'un réseau IPVPN superposé à Internet.
Si tout est déployé chez nous, les clients bénéficient d'un support complet pour le VPN, ainsi que d'une infrastructure sérieusement redondée, et de configurations standard qui fonctionneront sur n'importe quel routeur familier (que ce soit Cisco ou Mikrotik, tant qu'il prend en charge correctement IPSec/IKEv2 avec des méthodes d'authentification standardisées). À propos d'IPSec, nous ne soutenons en ce moment que lui, mais nous prévoyons de lancer un support complet pour OpenVPN et Wireguard, afin que les clients puissent être moins dépendants du protocole et avoir encore plus de facilité à tout transférer chez nous. Nous souhaitons également commencer à connecter des clients à partir d'ordinateurs et d'appareils mobiles (solutions intégrées dans les systèmes d'exploitation, Cisco AnyConnect, strongSwan, et similaires). Avec cette approche, la construction de l'infrastructure peut être confiée sans hésitation à l'opérateur, ne laissant que la configuration du CPE ou de l'hôte.
Comment se déroule le processus de connexion pour le mode IPSec :
- Le client soumet une demande à son gestionnaire en spécifiant la vitesse de connexion requise, le profil de trafic et les paramètres d'adressage IP pour le tunnel (par défaut, un sous-réseau avec un masque /30) ainsi que le type de routage (statique ou BGP). Pour la transmission des routes vers les réseaux locaux du client dans le bureau connecté, des mécanismes IKEv2 de la phase du protocole IPSec sont utilisés avec les réglages appropriés sur le routeur client, ou sont annoncés via BGP dans l'MPLS à partir du BGP AS privé spécifié dans la demande du client. Ainsi, les informations concernant les routes des réseaux clients sont entièrement contrôlées par le client via les réglages de son routeur.
- En réponse, le client reçoit de son gestionnaire les données de comptabilité à inclure dans son VRF sous la forme :
- Adresse IP VPN-HUB
- Identifiant
- Mot de passe d'authentification
- Configure le CPE, ci-dessous, pour exemple deux variantes de configuration de base :Variante pour Cisco :
crypto ikev2 keyring BeelineIPsec_keyring
peer Beeline_VPNHub
address 62.141.99.183 – Concentrateur VPN Beeline
pre-shared-key
!
Pour la variante avec routage statique, les routes vers les réseaux accessibles via le Vpn-hub peuvent être définies dans les réglages IKEv2 et apparaîtront automatiquement comme des routes statiques dans la table de routage du CPE. Ces réglages peuvent également être effectués de manière standard en définissant des routes statiques (voir ci-dessous).crypto ikev2 authorization policy FlexClient-author
La route vers les réseaux au-delà du routeur CPE est une configuration obligatoire lors du routage statique entre le CPE et le PE. La transmission des données des routes vers le PE est effectuée automatiquement lors de l'établissement du tunnel via l'interaction IKEv2.
route set remote ipv4 10.1.1.0 255.255.255.0 – Réseau local du bureau
!
crypto ikev2 profile BeelineIPSec_profile
identity local
authentication local pre-share
authentication remote pre-share
keyring local BeelineIPsec_keyring
aaa authorization group psk list group-author-list FlexClient-author
!
crypto ikev2 client flexvpn BeelineIPsec_flex
peer 1 Beeline_VPNHub
client connect Tunnel1
!
crypto ipsec transform-set TRANSFORM1 esp-aes 256 esp-sha256-hmac
mode tunnel
!
crypto ipsec profile default
set transform-set TRANSFORM1
set ikev2-profile BeelineIPSec_profile
!
interface Tunnel1
ip address 10.20.1.2 255.255.255.252 – Adresse du tunnel
tunnel source GigabitEthernet0/2 – Interface d'accès à Internet
tunnel mode ipsec ipv4
tunnel destination dynamic
tunnel protection ipsec profile default
!
Les routes vers les réseaux privés du client, accessibles via le concentrateur VPN Beeline, peuvent être définies de manière statique.ip route 172.16.0.0 255.255.0.0 Tunnel1
ip route 192.168.0.0 255.255.255.0 Tunnel1Variante pour Huawei (ar160/120) :
ike local-name
#
acl name ipsec 3999
règle 1 autoriser l'ip source 10.1.1.0 0.0.0.255 – Réseau local du bureau
#
aaa
schéma de service IPSEC
ensemble de routes acl 3999
#
proposition ipsec ipsec
algorithme d'authentification esp sha2-256
algorithme de chiffrement esp aes-256
#
proposition ike par défaut
algorithme de chiffrement aes-256
groupe dh2
algorithme d'authentification sha2-256
méthode d'authentification pré-partagée
algorithme d'intégrité hmac-sha2-256
prf hmac-sha2-256
#
pair Ike ipsec
clé pré-partagée simple
type d'identifiant local fqdn
type d'identifiant distant ip
adresse distante 62.141.99.183 – Concentrateur VPN Beeline
schéma de service IPSEC
demande d'échange de configuration
ensemble d'échange de configuration accepter
ensemble d'échange de configuration envoyer
#
profil ipsec ipsecprof
pair ike ipsec
proposition ipsec
#
interface Tunnel0/0/0
ip address 10.20.1.2 255.255.255.252 – Adresse du tunnel
protocole de tunnel ipsec
source GigabitEthernet0/0/1 – Interface d'accès à Internet
profil ipsec ipsecprof
#
Les itinéraires vers les réseaux privés des clients, accessibles via le concentrateur VPN Beeline, peuvent être définis de manière statiqueroute ip statique 192.168.0.0 255.255.255.0 Tunnel0/0/0
route ip statique 172.16.0.0 255.255.0.0 Tunnel0/0/0
Le schéma de communication résultant ressemble à ceci :
S'il n'y a pas d'exemples de configuration de base disponibles pour le client, nous les aidons généralement à les former et les rendons accessibles à tous les autres.
Il ne reste plus qu'à connecter le CPE à Internet, à faire un ping vers la partie distante du tunnel VPN et vers un hôte quelconque à l'intérieur du VPN, et tout est prêt, on peut considérer que la connexion est établie.
Dans le prochain article, nous expliquerons comment nous avons combiné ce schéma avec IPSec et la redondance MultiSIM en utilisant CPE Huawei : nous installons notre CPE Huawei pour les clients, qui peut utiliser non seulement un canal Internet filaire, mais aussi 2 cartes SIM différentes, et le CPE renégocie automatiquement le tunnel IPSec soit via WAN filaire soit via radio (LTE#1/LTE#2), réalisant une haute disponibilité du service final.
Un grand merci pour la préparation de cet article (et, en fait, aux auteurs de ces solutions techniques) aux collègues de notre RnD !
Source : habr.com
