1.5 régimes sur VPN IPsec domestique. Tester des démos

La situation

J'ai reçu une version de démonstration des produits C-Terra VPN version 4.3 pendant trois mois. Je veux savoir si ma vie d'ingénieur deviendra plus facile après le passage à la nouvelle version.

Aujourd'hui ce n'est pas difficile, un sachet de café instantané 3 en 1 devrait suffire. Je vais vous dire comment obtenir des démos. Je vais essayer de construire les schémas GRE sur IPsec et IPsec sur GRE.

Comment obtenir une démo

Il découle de la figure que pour obtenir une démo, vous devez :

• Écrivez une lettre à [email protected] à partir d'une adresse professionnelle ;
• Dans la lettre, indiquez le NIF de votre organisation ;
• Listez les produits et leur quantité.

Les démos sont valables trois mois. Le fournisseur ne limite pas leur fonctionnalité.

Agrandir l'image

La démonstration de Security Gateway est une image de machine virtuelle. J'utilise VMWare Workstation. Une liste complète des hyperviseurs et des environnements de virtualisation pris en charge est disponible sur le site Web du fournisseur.

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

La logique est claire, l'utilisateur doit ajouter autant d'interfaces qu'il en a besoin. J'en ajouterai quatre d'un coup :

Maintenant, je démarre la machine virtuelle. Immédiatement après le lancement, la passerelle nécessite un nom d'utilisateur et un mot de passe.

Il existe plusieurs consoles dans S-Terra Gateway avec différents comptes. Je compterai leur nombre dans un article séparé. Pour l'instant:
Login as: administrator
Password: s-terra

J'initialise la passerelle. L'initialisation est une séquence d'actions : saisir une licence, configurer un générateur de nombres aléatoires biologiques (simulateur de clavier - mon enregistrement est de 27 secondes) et créer une carte d'interface réseau.

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

La version 4.2 a accueilli l'utilisateur actif avec des messages :

Starting IPsec daemon….. failed
ERROR: Could not establish connection with daemon

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

Quelque chose n'allait pas avant d'essayer de configurer une adresse IP sur l'interface. Il s'agit de la carte d'interface réseau. Il fallait faire :

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

En conséquence, une carte d'interface réseau est créée qui contient le mappage des noms d'interface physique (0000:02:03.0) et leurs désignations logiques dans le système d'exploitation (eth0) et 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 sont appelées 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, une carte d'interface est créée automatiquement. Si vous modifiez le nombre d'interfaces réseau dans la machine virtuelle, veuillez recréer la carte d'interface :

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

Schéma 1 : GRE sur IPsec

Je déploie deux passerelles virtuelles, je bascule comme indiqué sur la figure :

Étape 1. Configurer 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

Vérification de la connectivité IP :

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

--- 172.16.1.254 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 0.273/0.540/0.687/0.164 ms

Étape 2 : Configurer GRE

Je prends un exemple de configuration de GRE à partir de scripts officiels. Je crée un 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 soulève l'interface dans le système:

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

Vérification:

root@VG1:~# ip address show
8: gre1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> 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 scope global 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

C-Terra Gateway dispose d'un renifleur de paquets intégré - tcpdump. Je vais écrire un vidage du 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 of data.
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=0.918 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=0.850 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=0.918 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=0.974 ms

--- 1.1.1.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 0.850/0.915/0.974/0.043 ms

Le tunnel GRE est opérationnel :

Étape 3. Crypter avec GOST GRE

J'ai défini le type d'identification - par adresse. Authentification avec une clé prédéfinie (conformément aux Conditions 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

J'ai défini les paramètres IPsec Phase I :

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

J'ai défini 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 cryptage. Trafic ciblé - 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 map et la lie à 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 en miroir, les différences sont :

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

Vérification:

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 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 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 initiated, 0 responded

ISAKMP connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd
1 1 (172.16.1.253,500)-(172.16.1.254,500) active 1086 1014

IPsec connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd
1 1 (172.16.1.253,*)-(172.16.1.254,*) 47 ESP tunn 480 480

Il n'y a aucun paquet dans le vidage du trafic GRE :

Conclusion : le schéma GRE sur IPsec fonctionne correctement.

Figure 1.5 : IPsec sur GRE

Je ne prévois pas d'utiliser IPsec-over-GRE sur le réseau. Je collectionne parce que j'en ai envie.

Pour déployer le schéma GRE sur IPsec dans l'autre sens :

• Correction de la liste d'accès au cryptage - trafic ciblé de LAN1 à LAN2 et vice versa ;
• Configurer le routage via GRE ;
• Accrochez un cryptomap sur l'interface GRE.

Par défaut, il n'y a pas d'interface GRE dans la console de passerelle de type Cisco. Il n'existe que dans le système d'exploitation.

J'ajoute l'interface GRE à 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 hash du fichier :

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

SUCCESS:  Operation was successful.

L'interface Tunnel0 est maintenant apparue dans la console de type Cisco :

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

Correction de 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 supprime la cryptomap de Fa0/0 et la lie à l'interface GRE :

VG1(config)#
interface Tunnel0
crypto map CMAP

Pour VG2, c'est similaire.

Vérification:

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) from 192.168.1.253 : 56(84) bytes of data.
64 bytes from 192.168.2.254: icmp_seq=1 ttl=64 time=492 ms
64 bytes from 192.168.2.254: icmp_seq=2 ttl=64 time=1.08 ms
64 bytes from 192.168.2.254: icmp_seq=3 ttl=64 time=1.06 ms
64 bytes from 192.168.2.254: icmp_seq=4 ttl=64 time=1.07 ms

--- 192.168.2.254 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 1.064/124.048/492.972/212.998 ms

Statistiques ISAKMP/IPsec :

root@VG1:~# sa_mgr show
ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd
1 2 (172.16.1.253,500)-(172.16.1.254,500) active 1094 1022

IPsec connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd
1 2 (192.168.1.0-192.168.1.255,*)-(192.168.2.0-192.168.2.255,*) * ESP tunn 352 352

Dans le vidage du trafic ESP, les paquets encapsulés dans GRE :

Conclusion : IPsec-over-GRE fonctionne correctement.

Les résultats de

Une tasse de café suffisait. J'ai esquissé des instructions pour obtenir une version de démonstration. GRE sur IPsec configuré et déployé vice versa.

La cartographie des interfaces réseaux en version 4.3 est automatique ! Je teste plus loin.

Ingénieur anonyme
t.me/ingénieur_anonyme

Source: habr.com