Schémas 1.5 sur un VPN IPsec national. Je teste des versions de démonstration

Situation

J'ai reçu une version d'essai des produits S-Terra VPN version 4.3 pour trois mois. Je veux comprendre si ma vie d'ingénieur sera plus facile après le passage à la nouvelle version.

Aujourd'hui, ce n'est pas compliqué, un sachet de café soluble 3 en 1 devrait suffire. Je vais vous expliquer comment obtenir des versions d'essai. J'essaierai de rassembler les schémas GRE-over-IPsec et IPsec-over-GRE.

Comment obtenir une version d'essai

D'après le schéma, pour obtenir une version d'essai, il faut :

• Écrire un e-mail à presale@s-terra.ru depuis l'adresse de l'entreprise;
• Indiquer le numéro d'identification fiscale (TIN) de votre organisation dans l'e-mail;
• Énumérer les produits et leur quantité.

Les versions d'essai sont valides pendant trois mois. Le fournisseur ne limite pas leur fonctionnalité.

Je déploie l'image

La version d'essai de la passerelle de sécurité est une image de machine virtuelle. J'utilise VMware Workstation. La liste complète des hyperviseurs et environnements de virtualisation pris en charge est disponible sur le site du fournisseur.

Avant de commencer les actions actives, veuillez noter qu'il n'y a par défaut pas d'interfaces réseau dans l'image de la machine virtuelle :

La logique est claire, l'utilisateur doit ajouter autant d'interfaces qu'il le souhaite. J'en ajouterai quatre tout de suite :

Je démarre maintenant la machine virtuelle. Juste après le démarrage, la passerelle demande un identifiant et un mot de passe.

Dans S-Terra Gateway, il y a plusieurs consoles avec différents comptes. Je compterai leur nombre dans un article séparé. En attendant :
Connectez-vous en tant que : administrateur
Mot de passe : s-terra

J'initialise la passerelle. L'initialisation est une séquence d'actions : saisie de la licence, configuration du générateur de nombres aléatoires biologique (mon record au simulateur de clavier est de 27 secondes) et création de la carte des interfaces réseau.

Carte des interfaces réseau. C'est devenu plus facile

La version 4.2 saluait les utilisateurs actifs avec des messages :

Démarrage du démon IPsec….. échec
ERREUR : Impossible d'établir la connexion avec le démon

Un utilisateur actif (selon un ingénieur anonyme) est un utilisateur capable de configurer n'importe quoi rapidement et sans documentation.

Quelque chose ne se passait pas bien, même avant d'essayer de configurer l'adresse IP sur l'interface. Tout était dans la carte des interfaces réseau. Il fallait exécuter :

/bin/netifcfg enum > /home/map
/bin/netifcfg map /home/map
service networking restart

En conséquence, une carte des interfaces réseau est créée, contenant le mappage des noms des interfaces physiques (0000:02:03.0) et leurs désignations logiques dans le système d'exploitation (eth0) et dans la console de type Cisco (FastEthernet0/0) :

#Unique ID iface type OS name Cisco-like name

0000:02:03.0 phye eth0 FastEthernet0/0

Les désignations logiques des interfaces s'appellent des alias. Les alias sont stockés dans le fichier /etc/ifaliases.cf.
Dans la version 4.3, lors du premier démarrage de la machine virtuelle, la carte des interfaces est créée automatiquement. Si vous modifiez le nombre d'interfaces réseau dans la machine virtuelle, veuillez créer la carte des interfaces à nouveau :

/bin/netifcfg enum > /home/map
/bin/netifcfg map /home/map
systemctl redémarrer le réseau

Schéma 1 : GRE-sur-IPsec

Je déploie deux passerelles virtuelles, les connectant comme indiqué sur l'image :

Étape 1. Configurez les adresses IP et les routes

VG1(config) #
interface fa0/0
ip address 172.16.1.253 255.255.255.0
no shutdown
interface fa0/1
ip address 192.168.1.253 255.255.255.0
no shutdown
ip route 0.0.0.0 0.0.0.0 172.16.1.254

VG2(config) #
interface fa0/0
ip address 172.16.1.254 255.255.255.0
no shutdown
interface fa0/1
ip address 192.168.2.254 255.255.255.0
no shutdown
ip route 0.0.0.0 0.0.0.0 172.16.1.253

Je vérifie la connectivité IP :

root@VG1:~# ping 172.16.1.254 -c 4
PING 172.16.1.254 (172.16.1.254) 56(84) bytes de données.
64 bytes de 172.16.1.254: icmp_seq=1 ttl=64 time=0.545 ms
64 bytes de 172.16.1.254: icmp_seq=2 ttl=64 time=0.657 ms
64 bytes de 172.16.1.254: icmp_seq=3 ttl=64 time=0.687 ms
64 bytes de 172.16.1.254: icmp_seq=4 ttl=64 time=0.273 ms

--- statistiques de ping pour 172.16.1.254 ---
4 paquets transmis, 4 reçus, perte de paquet à 0%, temps 3005ms
rtt min/avg/max/mdev = 0.273/0.540/0.687/0.164 ms

Étape 2. Configurez GRE

J'utilise un exemple de configuration GRE issu des scénarios officiels. Je crée le fichier gre1 dans le répertoire /etc/network/interfaces.d avec le contenu.

Pour VG1 :

auto gre1
iface gre1 inet static
address 1.1.1.1
netmask 255.255.255.252
pre-up ip tunnel add gre1 mode gre remote 172.16.1.254 local 172.16.1.253 key 1 ttl 64 tos inherit
pre-up ethtool -K gre1 tx off > /dev/null
pre-up ip link set gre1 mtu 1400
post-down ip link del gre1

Pour VG2 :

auto gre1
iface gre1 inet static
address 1.1.1.2
netmask 255.255.255.252
pre-up ip tunnel add gre1 mode gre remote 172.16.1.253 local 172.16.1.254 key 1 ttl 64 tos inherit
pre-up ethtool -K gre1 tx off > /dev/null
pre-up ip link set gre1 mtu 1400
post-down ip link del gre1

Je lève l'interface dans le système :

root@VG1:~# ifup gre1
root@VG2:~# ifup gre1

Je vérifie :

root@VG1:~# ip address show
8: gre1@NONE:  mtu 1400 qdisc noqueue state UNKNOWN group default qlen 1
    link/gre 172.16.1.253 peer 172.16.1.254
    inet 1.1.1.1/30 brd 1.1.1.3 portée globale gre1
       valid_lft forever preferred_lft forever

root@VG1:~# ip tunnel show
gre0: gre/ip remote any local any ttl inherit nopmtudisc
gre1: gre/ip remote 172.16.1.254 local 172.16.1.253 ttl 64 tos inherit key 1

Dans C-Terra Gateway, il y a un sniffer de paquets intégré — tcpdump. Je vais enregistrer un dump de trafic dans un fichier pcap :

root@VG2:~# tcpdump -i eth0 -w /home/dump.pcap

Je lance un ping entre les interfaces GRE :

root@VG1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) bytes de données.
64 bytes de 1.1.1.2: icmp_seq=1 ttl=64 time=0.918 ms
64 bytes de 1.1.1.2: icmp_seq=2 ttl=64 time=0.850 ms
64 bytes de 1.1.1.2: icmp_seq=3 ttl=64 time=0.918 ms
64 bytes de 1.1.1.2: icmp_seq=4 ttl=64 time=0.974 ms

--- statistiques de ping pour 1.1.1.2 ---
4 paquets transmis, 4 reçus, perte de paquet à 0%, temps 3006ms
rtt min/avg/max/mdev = 0.850/0.915/0.974/0.043 ms

Le tunnel GRE est actif et fonctionne :

Étape 3. Chiffrons avec le GOST GRE

Je définis le type d'identification – par adresse. L'authentification se fait par clé prédéterminée (selon les règles d'utilisation, des certificats numériques doivent être utilisés) :

VG1(config)#
crypto isakmp identity address
crypto isakmp key KEY address 172.16.1.254

Je définis les paramètres IPsec Phase I :

VG1(config)#
crypto isakmp policy 1
encr gost
hash gost3411-256-tc26
auth pre-share
group vko2

Je définis les paramètres IPsec Phase II :

VG1(config)#
crypto ipsec transform-set TSET esp-gost28147-4m-imit
mode tunnel

Je crée une liste d'accès pour le chiffrement. Le trafic cible est GRE :

VG1(config)#
ip access-list extended LIST
permit gre host 172.16.1.253 host 172.16.1.254

Je crée une crypto-carte et l'associe à l'interface WAN :

VG1(config)#
crypto map CMAP 1 ipsec-isakmp
match address LIST
set transform-set TSET
set peer 172.16.1.253
interface fa0/0
  crypto map CMAP

Pour VG2, la configuration est miroir, différences :

VG2(config)#
crypto isakmp key KEY address 172.16.1.253
ip access-list extended LIST
permit gre host 172.16.1.254 host 172.16.1.253
crypto map CMAP 1 ipsec-isakmp
set peer 172.16.1.254

Je vérifie :

root@VG2:~# tcpdump -i eth0 -w /home/dump2.pcap

root@VG1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data.
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=1128 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=126 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=1.07 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=1.12 ms

--- 1.1.1.2 statistiques ping ---
4 paquets transmis, 4 reçus, 0% perte de paquets, temps 3006ms
rtt min/avg/max/mdev = 1.077/314.271/1128.419/472.826 ms, pipe 2

Statistiques ISAKMP/IPsec :

root@VG1:~# sa_mgr show
ISAKMP sessions: 0 initiées, 0 répondues

Connexions ISAKMP :
Num Conn-id (Adresse locale,Port)-(Adresse distante,Port) État Envoyé Reçu
1 1 (172.16.1.253,500)-(172.16.1.254,500) actif 1086 1014

Connexions IPsec :
Num Conn-id (Adresse locale,Port)-(Adresse distante,Port) Protocole Action Type Envoyé Reçu
1 1 (172.16.1.253,*)-(172.16.1.254,*) 47 ESP tunn 480 480

Il n'y a pas de paquets GRE dans le dump de trafic :

Conclusion : le schéma GRE-over-IPsec fonctionne correctement.

Schéma 1.5 : IPsec-over-GRE

Je ne prévois pas d'utiliser IPsec-over-GRE dans le réseau. Je le mets en place juste pour le plaisir.

Pour inverser le schéma GRE-over-IPsec, il faut :

• Corriger la liste d'accès pour le chiffrement – le trafic cible de LAN1 à LAN2 et vice versa ;
• Configurer le routage via GRE ;
• Attacher la crypto-carte à l'interface GRE.

Par défaut, il n'y a pas d'interface GRE dans la console de type Cisco du routeur. Elle existe seulement dans le système d'exploitation.

J'ajoute l'interface GRE dans la console de type Cisco. Pour cela, j'édite le fichier /etc/ifaliases.cf :

interface (name="FastEthernet0/0" pattern="eth0")
interface (name="FastEthernet0/1" pattern="eth1")
interface (name="FastEthernet0/2" pattern="eth2")
interface (name="FastEthernet0/3" pattern="eth3")
interface (name="Tunnel0" pattern="gre1")
interface (name="default" pattern="*")

où gre1 est la désignation de l'interface dans le système d'exploitation, Tunnel0 est la désignation de l'interface dans la console de type Cisco.

Je recalcule le hachage du fichier :

root@VG1:~# integr_mgr calc -f /etc/ifaliases.cf

SUCCÈS : L'opération a réussi.

Maintenant, l'interface Tunnel0 est apparue dans la console de type Cisco :

VG1# show run
interface Tunnel0
ip address 1.1.1.1 255.255.255.252
mtu 1400

Je corrige la liste d'accès pour le chiffrement :

VG1(config)#
ip access-list extended LIST
permit ip 192.168.1.0 0.0.0.255 192.168.3.0 0.0.0.255

Je configure le routage via GRE :

VG1(config)#
no ip route 0.0.0.0 0.0.0.0 172.16.1.254
ip route 192.168.3.0 255.255.255.0 1.1.1.2

Je retire la carte crypto de Fa0/0 et je l'associe à l'interface GRE :

VG1(config)#
interface Tunnel0
crypto map CMAP

Pour VG2, c'est la même chose.

Je vérifie :

root@VG2:~# tcpdump -i eth0 -w /home/dump3.pcap

root@VG1:~# ping 192.168.2.254 -I 192.168.1.253 -c 4
PING 192.168.2.254 (192.168.2.254) depuis 192.168.1.253 : 56(84) octets de données.
64 octets de 192.168.2.254 : icmp_seq=1 ttl=64 temps=492 ms
64 octets de 192.168.2.254 : icmp_seq=2 ttl=64 temps=1.08 ms
64 octets de 192.168.2.254 : icmp_seq=3 ttl=64 temps=1.06 ms
64 octets de 192.168.2.254 : icmp_seq=4 ttl=64 temps=1.07 ms

--- statistiques ping 192.168.2.254 ---
4 paquets transmis, 4 reçus, 0% de perte de paquets, temps 3006ms
rtt min/avg/max/mdev = 1.064/124.048/492.972/212.998 ms

Statistiques ISAKMP/IPsec :

root@VG1:~# sa_mgr show
Sessions ISAKMP : 0 initiées, 0 répondues

Connexions ISAKMP :
Num Conn-id (Adresse locale,Port)-(Adresse distante,Port) État Envoyé Reçu
1 2 (172.16.1.253,500)-(172.16.1.254,500) actif 1094 1022

Connexions IPsec :
Num Conn-id (Adresse locale,Port)-(Adresse distante,Port) Protocole Type d'action Envoyé Reçu
1 2 (192.168.1.0-192.168.1.255,*)-(192.168.2.0-192.168.2.255,*) * ESP tunn 352 352

Dans le dump de trafic, paquets ESP encapsulés dans GRE :

Sortie : IPsec-over-GRE fonctionne correctement.

Résultats

Une tasse de café a suffi. J'ai esquissé une instruction pour obtenir la version de démonstration. J'ai configuré GRE-over-IPsec et j'ai déployé l'inverse.

La carte des interfaces réseau dans la version 4.3 est automatique ! Je teste davantage.

Ingénieur anonyme
t.me/anonimous_engineer

Source : habr.com