La vie d'un ingénieur réseau était heureuse et insouciante jusqu'à ce qu'une passerelle crypto certifiée apparaisse. D'accord, traiter des solutions conçues pour crypter les canaux de transmission de données conformément à GOST n'est pas une tâche facile. C'est bien si ce sont des produits bien connus et compréhensibles. Rappelons-nous le même "S-Terra" (nous avons déjà écrit sur leur passerelle S-Terra ). Mais que faire des solutions plus exotiques basées sur leurs propres protocoles de cryptage, par exemple, "Continent" (de "Security Code") ou ViPNet Coordinator HW (de "Infotex")? Dans cet article, je vais essayer de faciliter la plongée dans le monde de ViPNet (nous parlerons aussi de Continent un jour) et de vous dire quels problèmes je me suis rencontré et comment je les ai résolus.
Je ferai une réservation tout de suite que nous parlerons de la version 4.2.1 certifiée par le FSB et le FSTEC pour aujourd'hui. Dans les versions actuelles 4.3.x, beaucoup de choses intéressantes sont apparues, par exemple, DGD (Dead Gateway Detection) et un mécanisme de clustering modifié, qui fournit une commutation presque transparente, mais pour l'instant, c'est l'avenir. Je ne vais pas plonger profondément dans les profondeurs des commandes et des fichiers de configuration, en me concentrant sur les commandes clés et les variables, et une description détaillée de ces «touches» peut être trouvée dans la documentation.
Tout d'abord, voyons comment tout cela fonctionne. Ainsi, un coordinateur ViPNet remplit plusieurs fonctions. Tout d'abord, il s'agit d'une passerelle cryptographique (CG), qui permet à la fois un VPN site à site et RA. Deuxièmement, il s'agit d'un serveur-routeur d'enveloppes contenant des données de service chiffrées (répertoires et clés) ou des données d'applications clientes (échange de fichiers, courrier professionnel). D'ailleurs, c'est dans des répertoires que sont stockés les fichiers contenant des informations sur les objets du réseau ViPNet, y compris leurs noms, identifiants, adresses, connexions. Le coordinateur est également une source d'information de service pour ses clients.
En outre, il peut tunneliser le trafic des ordinateurs du réseau sur lesquels le logiciel ViPNet n'est pas installé. À propos, les personnes travaillant avec cette solution se réfèrent souvent aux hôtes ouverts comme des «tunnels» plutôt que des «nœuds tunnelés». Cela peut être déroutant pour les ingénieurs habitués à d'autres solutions VPN, où un tunnel signifie une connexion PtP entre KSH.
IPlir, également développé par Infotex, est utilisé comme protocole de cryptage dans ViPNet. Pour encapsuler le trafic, les protocoles de transport sont IP / 241 (si le trafic ne quitte pas le domaine de diffusion), UDP / 55777 et TCP / 80 (si UDP n'est pas disponible).
Le concept de création de connexions sécurisées est basé sur les soi-disant «connexions», qui sont de deux types. Les premiers (au niveau du nœud) sont nécessaires pour établir une connexion sécurisée entre les nœuds, les seconds (au niveau de l'utilisateur) sont nécessaires pour le fonctionnement des applications clientes. Mais il y a une exception: les nœuds administrateurs ViPNet nécessitent les deux types de communication.
Qu'est-ce qui peut mal tourner dans ce schéma? Comme le montre la pratique, il y a vraiment de nombreuses particularités du travail, et tous les problèmes ne peuvent pas être résolus intuitivement, sans «l'aide du public», mais il faut juste prendre quelque chose pour acquis.
Coordinateur indisponible
«Nous n'avons pas de coordinateur / client / tunnel disponible. Que faire?" - la question la plus fréquemment posée par les débutants lors de la configuration de ViPNet. La seule action correcte dans une telle situation est d'activer l'enregistrement de tout le trafic sur les coordinateurs et de consulter le journal des paquets IP, qui est l'outil le plus important pour résoudre toutes sortes de problèmes de réseau. Cette méthode permet d'économiser dans 80% des cas. Travailler avec le journal des paquets IP permet également de mieux comprendre les mécanismes de fonctionnement des nœuds du réseau ViPNet.
Enveloppe non livrée
Mais le journal des paquets IP est, hélas, inutile lorsqu'il s'agit d'enveloppes. Ils sont livrés à l'aide d'un module de transport (mftp), qui possède son propre journal et sa propre file d'attente. Par défaut, les enveloppes sont envoyées au «propre» coordinateur du client (c'est-à-dire celui sur lequel le nœud est enregistré), puis via les canaux inter-serveurs qui sont configurés entre les coordinateurs (c'est-à-dire pas directement sur un canal sécurisé). Cela signifie que si vous souhaitez envoyer une lettre par courrier professionnel, le client la mettra dans une enveloppe et la transmettra d'abord à son coordinateur. Plus loin, il peut y avoir plusieurs autres coordinateurs, et seulement après cela, l'enveloppe atteindra le nœud du destinataire.
Deux conclusions en découlent. Premièrement, la communication entre clients n'a pas besoin d'être vérifiée (en appuyant sur F5 et l'icône correspondante dans le menu) pour livrer les enveloppes. Deuxièmement, si la connexion entre eux est toujours vérifiée, cela ne garantit pas la livraison, car le problème peut être dans l'un des canaux inter-serveurs.
Dans des cas non évidents, il est possible de diagnostiquer le passage des enveloppes à travers des canaux interserveurs ou entre un client et un coordinateur en utilisant la file d'attente du journal et des enveloppes, ainsi que des logs sur le coordinateur. En outre, le module de transport du client ViPNet peut être configuré pour la livraison directe des enveloppes, la livraison via un dossier partagé ou SMTP / POP3 (mais c'est une option complètement exotique). Nous ne nous plongerons pas dans ces paramètres.
Conséquences du clignotement
Il peut être problématique de mettre à niveau vers la version actuelle d'anciens matériels qui sont utilisés depuis longtemps, par exemple comme pièce de rechange. Dans le processus, une erreur «matériel non pris en charge» peut apparaître, ce qui indique que vous avez une plate-forme matérielle vraiment non prise en charge de la ligne G1 obsolète (il s'agit de HW100 E1 / E2 et HW1000 Q1), ou des problèmes de configuration du BIOS ou des informations incorrectes intégrées DMI. Que ce soit pour gérer seul le DMI, chacun décide pour lui-même, car il y a un risque de transformer l'équipement en une «brique» inutile. Avec le BIOS, c'est un peu plus facile: les paramètres système incorrects sont dans la fonction HT (Hyper Threading) désactivée ou le mode ACHI (Advanced Host Controller Interface) désactivé pour le disque dur. Afin de ne pas deviner quel est exactement le problème, vous pouvez vous référer à la clé USB à partir de laquelle le micrologiciel est produit.Des fichiers avec des informations de diagnostic y sont créés, en particulier, toutes les plates-formes prises en charge sont répertoriées dans le fichier verbose.txt avec le résultat de la vérification avec la vôtre. Par exemple, l'erreur cpu :: Vendor (# 3) == 'GenuineIntel' 24 fois => [Failed] indique très probablement que HT est désactivé. À propos, le clignotement est souvent confondu avec la mise à jour, mais ce sont des processus différents. Lors de la mise à jour, tous les paramètres sont enregistrés et les paramètres décrits ci-dessus ne sont pas vérifiés. Et lorsque vous reflasher, vous revenez aux paramètres d'usine.Lors de la mise à jour, tous les paramètres sont enregistrés et les paramètres décrits ci-dessus ne sont pas vérifiés. Et lorsque vous reflasher, vous revenez aux paramètres d'usine.Lors de la mise à jour, tous les paramètres sont enregistrés et les paramètres décrits ci-dessus ne sont pas vérifiés. Et lorsque vous reflasher, vous revenez aux paramètres d'usine.
Configurations non informatives
Le fichier de configuration principal pour HW est "iplir.conf", mais il ne reflète pas toujours les paramètres actuels. Le fait est qu'au moment du chargement du pilote IPlir, cette configuration est interprétée conformément à la logique définie, et toutes les informations ne peuvent pas être chargées dans le pilote (par exemple, s'il y a des conflits d'adresses IP). Les ingénieurs qui ont travaillé avec le coordinateur de logiciels Linux sont probablement au courant de la commande "iplirdiag", qui affiche les paramètres de nœud actuels chargés dans le pilote. Dans HW, cette commande est également présente en mode "admin escape".
Les sorties les plus populaires sont:
iplirdiag -s ipsettings --node-info <node id> ## afficher des informations sur un nœud
iplirdiag -s ipsettings --v-tun-table ## afficher tous les tunnels chargés dans le pilote
Arrêtons-nous un peu sur le mode "admin escape". En fait, c'est une sortie du shell ViPNet vers bash. Ici, je suis d'accord avec le vendeur, qui recommande d'utiliser ce mode uniquement pour les diagnostics et d'apporter des modifications uniquement sous la supervision du support technique du vendeur. Ce n'est pas votre Debian habituel, ici tout mouvement imprudent peut désactiver le système d'exploitation, dont les mécanismes de protection percevront votre «initiative» comme une menace potentielle. En conjonction avec le BIOS verrouillé par défaut, cela vous condamne à des réparations non couvertes par la garantie (lire «coûteuses»).
(Un) split tunneling
Autre fait que tout le monde ne sait pas: par défaut, le client ViPNet fonctionne en mode tunnel partagé (lorsque vous pouvez spécifier quel trafic encapsuler dans le tunnel et lequel non). ViPNet dispose de la technologie "Open Internet" (renommée plus tard en "Protected Internet Gateway"). De nombreuses personnes attribuent à tort cette fonctionnalité au coordinateur plutôt qu'au client. Sur un client enregistré auprès d'un coordinateur avec cette fonction, deux ensembles de filtres prédéfinis sont créés. Le premier autorise l'interaction uniquement avec le coordinateur lui-même et ses tunnels, le second - avec d'autres objets, mais refuse l'accès au coordinateur OI et à ses tunnels. De plus, selon le concept du vendeur, dans le premier cas, le coordinateur doit soit tunneliser le serveur proxy, soit être le serveur proxy lui-même. Trafic de service, ainsi que réception et transmission d'enveloppes (à la fois service,et applications) fonctionnent dans n'importe quelle configuration.
TCP-
Une fois, je suis tombé sur une application qui ne voulait en aucun cas fonctionner par l'intermédiaire du coordinateur. C'est ainsi que j'ai appris que le coordinateur a des ports de service à travers lesquels le trafic non chiffré est bloqué sans possibilité de configuration. Il s'agit notamment de UDP / 2046,2048,2050 (services ViPNet de base), TCP / 2047,5100,10092 (pour ViPNet Statewatcher) et TCP / 5000-5003 (MFTP). Ici, j'ai résumé les fonctions du tunnel TCP. Ce n'est un secret pour personne que les FAI aiment filtrer les ports UDP élevés, de sorte que les administrateurs, dans un effort pour améliorer la disponibilité de leurs CN, activent la fonction de tunnel TCP. Dans ce cas, les ressources de la DMZ (via le port de tunnel TCP) deviennent indisponibles. Cela est dû au fait que le port de tunnel TCP devient également un port de service et qu'il n'y a plus de règles de pare-feu et de règles NAT (Network Address Translation). Il est difficile de diagnostiquer le fait queque ce trafic n'est pas enregistré dans le journal des paquets IP comme s'il n'y était pas du tout.
Remplacement du coordinateur
Tôt ou tard, la question se pose de remplacer le coordinateur par une option plus productive ou temporaire. Par exemple, en remplaçant HW1000 par HW2000 ou le coordinateur logiciel par PAK et vice versa. La difficulté réside dans le fait que chaque représentation a son propre «rôle» dans le NCC (Network Control Center). Comment bien changer de rôle sans perdre de cohésion? Premièrement, dans la CCN, nous changeons le rôle pour un nouveau rôle, formons des répertoires, mais ne les envoyons pas (!). Ensuite, nous publions un nouveau fichier DST dans l'UCC et initialisons le nouveau coordinateur. Après cela, nous faisons un remplacement et, après nous être assurés que toutes les interactions sont fonctionnelles, nous envoyons les livres de référence.
Clustering et crash de nœud
Une réserve chaude est indispensable pour tout grand site, c'est pourquoi un groupe d'anciens modèles (HW1000, HW2000, HW5000) leur a toujours été acheté. Cependant, la création d'un cluster à partir de passerelles cryptographiques plus compactes (HW50 et HW100) était impossible en raison de la politique de licence du fournisseur. En conséquence, les propriétaires de petits sites ont dû payer trop cher et acheter HW1000 (enfin, ou pas de tolérance aux pannes). Cette année, le fournisseur a finalement créé des licences supplémentaires pour les modèles de coordinateur junior. Ainsi, avec la sortie des versions 4.2.x, il est devenu possible de les rassembler dans un cluster.
Lorsque vous configurez un cluster pour la première fois, vous pouvez gagner beaucoup de temps en ne configurant pas les interfaces en mode assistant ou en utilisant les commandes CLI. Vous pouvez saisir immédiatement les adresses nécessaires dans le fichier de configuration du cluster (modification de la configuration du basculement), n'oubliez pas de spécifier les masques. Lorsque le démon de basculement est démarré en mode cluster, il attribuera lui-même des adresses aux interfaces correspondantes. En même temps, beaucoup ont peur d'arrêter le démon, en supposant que les adresses sont changées en adresses passives ou monomodes. Ne vous inquiétez pas: les interfaces conserveront les adresses qui étaient au moment où le démon a été arrêté.
Dans la version cluster, il existe deux problèmes courants: le redémarrage cyclique du nœud passif et son échec de basculement en mode actif. Afin de comprendre l'essence de ces phénomènes, comprenons le mécanisme de l'opération de cluster. Ainsi, le nœud actif compte les paquets sur l'interface et, s'il n'y a pas de paquets dans le temps imparti, envoie un ping à testip. Si le ping réussit, le compteur est redémarré, s'il ne réussit pas, l'échec de l'interface est enregistré et le nœud actif est redémarré. En même temps, le nœud passif envoie des requêtes ARP régulières sur toutes les interfaces décrites dans failover.ini (le fichier de configuration du cluster, qui contient les adresses que les nœuds actifs et passifs reçoivent). Si l'enregistrement ARP d'au moins une adresse disparaît, le nœud passif passe en mode actif.
Revenons aux problèmes de cluster. Je vais commencer par un simple - ne pas passer en mode actif. S'il n'y a pas de nœud actif, mais que son adresse mac est toujours présente sur le passif dans la table ARP (inet show mac-address-table), vous devez vous rendre aux administrateurs du commutateur (soit le cache ARP est configuré de cette façon, soit il s'agit d'une sorte d'échec ). Le rechargement cyclique du nœud passif est un peu plus compliqué. Ceci est dû au fait que le passif ne voit pas l'enregistrement ARP actif, passe en mode actif et (attention!) Interroge le voisin via la liaison HB. Mais notre voisin est en mode actif et a plus de temps de disponibilité. À ce moment, le nœud passif se rend compte que quelque chose ne va pas, car un conflit d'état est survenu, et se lance dans un redémarrage. Cela continue indéfiniment. Si ce problème se produit, vous devez vérifier les paramètres d'adresse IP dans failover.ini et la commutation.Si tous les paramètres du coordinateur sont corrects, il est temps de connecter les ingénieurs réseau à la question.
Adresses de passage
Dans notre pratique, nous rencontrons souvent l'intersection d'adresses tunnel derrière différents coordinateurs.
C'est pour de tels cas qu'il y a virtualisation des adresses dans les produits ViPNet. La virtualisation est une sorte de NAT sans surveillance de l'état d'une connexion un-à-un ou d'une plage à l'autre. Par défaut, cette fonction est désactivée sur les coordinateurs, bien que vous puissiez trouver des adresses virtuelles potentielles dans iplir.conf dans la ligne «tunnel» après «to» dans les sections des coordinateurs voisins. Pour activer la virtualisation globalement pour toute la liste, dans la section [visibilité], changez le paramètre "tunneldefault" en "virtual". Si vous souhaitez activer pour un voisin spécifique, vous devez ajouter le paramètre "tunnelvisibility = virtual" à sa section [id]. Il convient également de s'assurer que le paramètre tunnel_local_networks est défini sur "on". Pour éditer des adresses virtuelles, le paramètre tunnel_virt_assignment doit être défini sur le mode "manuel".De l'autre côté, vous devez effectuer des actions similaires. Les paramètres "usetunnel" et "exclude_from_tunnels" sont également responsables des paramètres du tunnel. Le résultat du travail effectué peut être vérifié à l'aide de l'utilitaire "iplirdiag", que j'ai mentionné ci-dessus.
Bien entendu, les adresses virtuelles présentent des inconvénients, les administrateurs d'infrastructure préfèrent donc minimiser leur utilisation. Par exemple, lorsque des organisations se connectent aux systèmes d'information (SI) de certaines agences gouvernementales, ces organisations reçoivent un fichier DST avec une plage fixe de tunnels à partir du plan d'adresses SI. Comme on peut le voir, les souhaits de la personne qui se connecte ne sont pas pris en compte. Comment s'intégrer dans cette piscine, chacun décide par lui-même. Quelqu'un migre les postes de travail vers un nouvel adressage, et quelqu'un utilise SNAT sur le chemin des hôtes vers le coordinateur. Ce n'est un secret pour personne que certains administrateurs utilisent SNAT pour contourner les restrictions de licence des plates-formes inférieures. Nous ne nous engageons pas à évaluer l'éthique d'un tel «hack de vie», mais n'oublions pas que les performances des plateformes elles-mêmes ont encore une limite,et en cas de surcharge, la qualité du canal de communication commencera à se dégrader.
Incapacité de travailler GRE
Bien sûr, chaque solution informatique a ses propres limites sur les cas d'utilisation pris en charge, et ViPNet Coordinator ne fait pas exception. Un problème plutôt ennuyeux est l'incapacité de travailler GRE (et les protocoles qui l'utilisent) à partir de plusieurs sources vers une seule destination via SNAT. Prenons, par exemple, un système banque-client qui met en place un tunnel PPTP vers l'adresse publique d'une banque. Le problème est que le protocole GRE n'utilise pas de ports, donc après que le trafic passe par NAT, le socketpair de ce trafic devient le même (nous avons la même adresse de destination, le protocole est le même, et nous venons de traduire l'adresse source en une seule adresse). Le coordinateur réagit à cela en bloquant le trafic sur le fond de l'erreur 104 - La connexion existe déjà. Cela ressemble à ceci:
Par conséquent, si vous utilisez plusieurs connexions GRE, vous devez éviter d'appliquer NAT à ces connexions. En dernier recours, effectuez une diffusion 1: 1 (bien que, lors de l'utilisation d'adresses publiques, cette solution soit plutôt peu pratique).
N'oublie pas le temps
Nous continuons le sujet du blocage avec l'événement numéro 4 - Délai d'expiration des paquets IP. Tout est banal ici: cet événement se produit lorsqu'il y a un décalage entre le temps absolu (hors fuseaux horaires) entre les nœuds du réseau ViPNet (coordinateurs et clients ViPNet). Sur les coordinateurs HW, la différence maximale est de 7200 secondes et est définie dans le paramètre "timediff" du fichier de configuration IPlir. Je ne considère pas les coordinateurs HW-KB dans cet article, mais il convient de noter que dans la version KB2, le timediff est de 7 secondes par défaut, et dans KB4, il est de 50 secondes, et l'événement peut être généré non pas 4, mais 112, ce qui peut prêter à confusion un ingénieur habitué au matériel "normal".
Trafic non chiffré au lieu de chiffré
Il peut être difficile pour les débutants de comprendre la nature de l'événement 22 - Paquet IP non chiffré du nœud du réseau - dans le journal des paquets IP. Cela signifie que le coordinateur attendait du trafic crypté de cette adresse IP, mais que du trafic non crypté est arrivé. Le plus souvent, cela se passe comme ceci:
- ViPNet-, , . IPlir , , , . , : ViPNet-, – . , , , . , , , ViPNet-, . , ViPNet-, ;
- . , , ( ). , , , ;
- . , . , «» . , , , 22 .
(ALG)
De nombreux pare-feu, y compris ViPNet Coordinator, peuvent avoir des problèmes avec SIP passant par NAT. Étant donné que les adresses virtuelles sont des NAT internes, le problème peut survenir même lorsque NAT explicitement n'est pas utilisé et que seules les adresses virtuelles sont utilisées. Le coordinateur dispose d'un module de traitement de protocole d'application (ALG) qui devrait résoudre ces problèmes, mais il ne fonctionne pas toujours comme souhaité. Je ne m'attarderai pas sur le mécanisme de l'ALG (un article séparé peut être écrit sur ce sujet), le principe est le même pour toutes les UIT, seules les rubriques du niveau applicatif changent. Pour le bon fonctionnement du protocole SIP via le coordinateur, vous devez connaître les éléments suivants:
- ALG doit être activé lors de l'utilisation de NAT;
- lors de l'utilisation de l'adressage virtuel, ALG doit être activé sur les deux nœuds participant à l'interaction (coordinateur-coordinateur, coordinateur-client), même si la visibilité virtuelle est définie d'un seul côté;
- lorsque vous utilisez une visibilité réelle et qu'il n'y a pas de NAT, vous devez désactiver ALG pour qu'il n'interfère pas avec SIP;
- Les lignes ALG 3.x et 4.x sont incompatibles (à proprement parler, à la ligne 3.x, il n'y avait aucun moyen de la contrôler). Dans un tel scénario, le fournisseur ne peut garantir le bon fonctionnement de SIP.
Le module est piloté par les commandes du groupe "alg module" à partir du mode privilégié (enable).
finalement
J'ai essayé de considérer les problèmes les plus urgents, d'identifier leurs racines et de parler de solutions. Bien sûr, ce ne sont pas toutes les fonctionnalités de ViPNet, donc je recommande de ne pas être timide - de contacter le support et de demander des conseils dans la communauté (sur le forum du vendeur, dans le canal de télégramme, dans les commentaires sous ce post). Et si vous ne voulez pas vous plonger dans toutes les difficultés de travailler avec ViPNet ou si c'est trop laborieux, vous pouvez toujours laisser la gestion de votre réseau ViPNet entre les mains de professionnels.
Auteur: Igor Vinokhodov, ingénieur de la 2e ligne d'administration, Rostelecom-Solar