Pourquoi et de quoi parle cet article?
Si vous google sur le sujet "openvpn bgp", vous pouvez trouver plusieurs articles intéressants et utiles d'un point de vue pratique (par exemple, une ou deux fois ). Mais en commençant à résoudre le problème dans le titre, pour de nombreuses raisons, je n'ai même pas pris la peine de le rechercher sur Google. L'idée est née d'une manière ou d'une autre au cours d'un long travail avec OpenVPN en général (dans le cadre de tâches assez typiques, avec un ensemble fixe de réseaux des deux côtés), en travaillant avec la mise en œuvre d'OpenVPN sur le système RouterOS de MikroTik et en connectant les systèmes Linux et RouterOS entre eux. En fait, dans le processus de réalisation des raisons pour écrire notre propre implémentation d'OpenVPN dans RouterOS, la «perspicacité» est venue sur la façon dont ce problème peut être résolu dans le cadre de l'édition OpenVPN à personnel complet. Ensuite, un court contrôle expérimental a montré la pleine capacité de travail de l'idée et le lancement de cette solution en fonctionnement «industriel».
Gardant à l'esprit que cette situation est assez typique pour différentes applications et que la solution décrite ci-dessous n'a pas encore été présentée, j'ai décidé de partager l'idée avec la communauté.
L'essence du problème ("qui est à blâmer?")
Quelle est la différence entre la version régulière d'OpenVPN et celle qui est implémentée dans RouterOS? Il y a probablement quelques différences, mais dans cet article, nous ne considérerons qu'une seule chose: l'OpenVPN normal dans les systèmes autres que RouterOS (et peut-être certains autres) est une moissonneuse-batteuse qui contient la partie transport (c'est-à-dire la transmission de paquets elle-même, elle est également en train de transmettre, c'est aussi un plan de données ) et le routage (c'est-à-dire l'échange d'informations sur les itinéraires, c'est le routage, c'est aussi un plan de contrôle), et dans RouterOS, le service OpenVPN n'est responsable que de la partie transport , et le routage est géré par un processus système différent, ce qui permet, d'une part, de ne pas dupliquer la fonctionnalité du routage sous (et de plus, ne conservez pas plusieurs tables de routage identiques dans différents services et synchronisez-les constamment les unes avec les autres), et d'autre part, permet un transfert transparent des tables de route sur ces véhicules et changez les tables de route des deux côtés à la volée.
De plus, l'implémentation régulière d'OpenVPN présente un autre inconvénient: le transfert de routes ne se produit que dans une seule direction (du serveur au client) et uniquement au moment de l'établissement d'une session (c'est-à-dire l'élévation du tunnel). Il n'y a aucun moyen régulier d'ajouter un itinéraire à la table de routage OpenVPN interne lors de vos déplacements pendant le fonctionnement du tunnel, ainsi que de transférer des itinéraires d'un côté à l'autre. De plus, il n'est même pas possible d'obtenir la table de routage elle-même.
Solution au problème («Que faire»)
En analysant mes scripts qui automatisent l'attribution des routes à différents clients, j'ai remarqué qu'OpenVPN a deux options différentes qui spécifient les routes:
i route - définit les routes à l' intérieur de la table de routage du processus OpenVPN.route - définit les routes que le processus OpenVPN transmet à la table de routage système (c'est-à-dire qu'il ajoute des routes à la table via son interface de tunnel lors de la connexion et les supprime lorsqu'il est déconnecté).
La question évidente s'est posée: que se passera-t-il si la i route ajoutée avec la route 0.0.0.0/0 des deux côtés, puis les routes nécessaires (y compris celles qui apparaissent ou disparaissent dynamiquement) sont ajoutées ou supprimées sur l'interface du tunnel elle-même à l'aide d'un service de routage ( en déroute, zèbre / quagga, oiseau, etc.)?
L'expérience a montré qu'un tel schéma fonctionne vraiment avec un léger inconvénient de restriction: un seul client peut être connecté à un tunnel de serveur. Le reste du circuit s'est avéré être pleinement opérationnel.
Le schéma fonctionne en mode TLS sur TCP, c'est-à-dire que pour la configuration, vous devez d'abord générer des clés et des certificats SSL.
Ci-dessous, je donne un exemple de configuration OpenVPN pour le côté serveur et client.
Configuration côté serveur (une pour chaque client).
Fichier server_dyn_rt.conf (côté serveur)
daemon compress ping-timer-rem persist-tun persist-key tls-server proto tcp-server topology net30 mode server script-security 3 keepalive 15 45 tun-mtu 1500 remote-cert-tls client verify-x509-name <CLIENT_DISTINGUISHED_NAME> name auth <TLS_AUTH_ALGORITHM> cipher <CIPHER_ALGORITHM> local <SERVER_PUBLIC_IP> lport <SERVER_PUBLIC_PORT> dev-type tun dev <TUNNEL_INTERFACE_NAME> ifconfig <TUNNEL_SERVER_SIDE_IP> <TUNNEL_CLIENT_SIDE_IP> client-connect client_connect.sh push "route-gateway <TUNNEL_SERVER_SIDE_IP>" push "topology net30" push "persist-tun" push "persist-key" <dh> ... Diffie-Hellman data <</dh> <ca> ... Certificate Authority certificate data </ca> <cert> ... Server certificate data </cert> <key> ... Server Private Key data </key>
Fichier client_connect.sh (côté serveur)
Fichier client_dyn_rt.conf (côté client)
daemon compress tls-client auth <TLS_AUTH_ALGORITHM> cipher <CIPHER_ALGORITHM> client dev-type tun dev <TUNNEL_INTERFACE_NAME> script-security 3 remote-cert-tls server verify-x509-name <SERVER_DISTINGUISHED_NAME> name remote <SERVER_PUBLIC_IP> <SERVER_PUBLIC_PORT> tcp <ca> ... Certificate Authority certificate data </ca> <cert> ... Client certificate data </cert> <key> ... Client Private Key data </key>
Je ne cite pas les paramètres des paquets et des protocoles de routage soit à cause de la variété des paquets, soit à cause de la variété des paramètres eux-mêmes (en fait, comme source d'exemples de configuration, vous pouvez utiliser le deuxième des articles, dont les liens sont donnés au début de l'article). Je veux juste noter que le paramètre ci-dessus vous permet d'utiliser en particulier BGP (que j'aime personnellement à la fois en raison de sa "contrôlabilité" et de la possibilité de transmettre des routes de divers protocoles au cours d'une même session). Dans le cas de BGP, l'adresse <TUNNEL_CLIENT_SIDE_IP> doit être utilisée comme adresse du voisin côté "serveur", et l'adresse <TUNNEL_SERVER_SIDE_IP> ou les adresses "internes" des parties respectives doivent être utilisées côté client, mais vous devez ensuite ajouter les routes correspondantes à la configuration. serveur et / ou client.
Avantages et inconvénients de la solution ci-dessus
Inconvénients:
- Il doit y avoir exactement un client par serveur, donc pour plusieurs clients, vous devrez garder plusieurs processus OpenVPN actifs. En conséquence - un certain dépassement de mémoire et tout cela.
- Vous ne pouvez pas utiliser le mode de clé pré-partagée dans OpenVPN, car dans ce mode, le transfert dynamique des paramètres du serveur vers le client (push / pull) est interdit. Pour cette raison, une configuration plus complexe est requise, y compris la génération d'un ensemble de clés et de certificats, ainsi qu'un script pour générer une pièce de configuration côté client d'un serveur (qui, cependant, peut être remplacé par un répertoire de fichiers statiques en remplaçant l'option
client-connect /path/to/script par l'option client-connect-dir /path/to/config/dir , ce qui augmente le niveau de sécurité côté serveur.
Avantages:
- Contrairement aux protocoles tels que GRE / IPIP, les tunnels OpenVPN peuvent avoir une MTU de 1500 octets (car le processus OpenVPN masque toute la fragmentation / défragmentation sous le capot, envoyant des paquets complets à l'interface du tunnel). Cela facilite la configuration de toutes sortes de tunnels secondaires sur le tunnel OpenVPN.
- Le tunnel OpenVPN prend en charge simultanément la transmission d'IPv4 et d'IPv6, ce qui réduit le nombre de tunnels entre des paires de nœuds, le coût de leur configuration et de leur administration, ainsi que la transmission de routes IPv6 dans la même session BGP que les routes IPv4.
- Tous les avantages du protocole OpenVPN, tels que la facilité de mise en place d'un équipement réseau intermédiaire (ou son absence totale), la possibilité de masquer le trafic sous HTTPS, la présence d'une implémentation pour la plupart des plateformes et cetera, et cetera.
J'espère que quelqu'un trouvera le guide ci-dessus utile.