Clever Geek Handbook

1.5 schémas sur VPN IPsec domestique. Tester des démos





Situation



J'ai reçu une version d'essai de trois mois de la version 4.3 de C-Terra VPN. Je veux savoir si ma vie d'ingénieur deviendra plus facile aprÚs la mise à niveau vers 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 les démos. J'essaierai de mettre en place des schémas GRE-over-IPsec et IPsec-over-GRE.



Comment obtenir une démo







À partir de la figure ci-dessous, pour obtenir la dĂ©mo dont vous avez besoin:



  • Écrivez une lettre Ă  presale@s-terra.ru Ă  partir de l'adresse de l'entreprise;
  • Dans la lettre, indiquez le NIF de votre organisation;
  • ÉnumĂ©rez les produits et leurs quantitĂ©s.


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



Agrandir l'image



La démo 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 démarrer l'action, 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 Ă  la fois:







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



C-Terra Gateway dispose de plusieurs consoles avec différents comptes. Je compterai leur nombre dans un article séparé. Jusque là:

Login as: administrator

Password: s-terra


Initialisation de la passerelle. L'initialisation est une séquence d'actions: entrer une licence, mettre en place un générateur de nombres aléatoires biologiques (simulateur de clavier - mon record est de 27 secondes) et créer une carte d'interface réseau.



Carte d'interface de réseau. C'est devenu plus facile



La version 4.2 a accueilli un utilisateur actif avec des messages: Un utilisateur actif (selon un ingĂ©nieur anonyme) est un utilisateur qui peut tout configurer rapidement et sans documentation. Une erreur s'est produite, avant mĂȘme d'essayer de configurer une adresse IP sur l'interface. Tout dĂ©pend de la carte de l'interface rĂ©seau. Il Ă©tait nĂ©cessaire de faire: En consĂ©quence, une carte d'interface rĂ©seau est crĂ©Ă©e, qui contient un mappage des noms des interfaces physiques (0000: 02: 03.0) et de leurs dĂ©signations logiques dans le systĂšme d'exploitation (eth0) et la console de type Cisco (FastEthernet0 / 0): les dĂ©signations logiques des interfaces sont appelĂ©es alias ... Les alias sont stockĂ©s dans le fichier /etc/ifaliases.cf.



Starting IPsec daemon
.. failed

ERROR: Could not establish connection with daemon











/bin/netifcfg enum > /home/map

/bin/netifcfg map /home/map

service networking restart







#Unique ID iface type OS name Cisco-like name



0000:02:03.0 phye eth0 FastEthernet0/0





Dans la version 4.3, la carte d'interface est créée automatiquement lors du premier démarrage de la machine virtuelle. Si vous modifiez le nombre d'interfaces réseau dans la machine virtuelle, veuillez créer à nouveau la carte d'interface:



/bin/netifcfg enum > /home/map

/bin/netifcfg map /home/map

systemctl restart networking



Figure 1: GRE-sur-IPsec



Je déploie deux passerelles virtuelles, je les change comme indiqué dans 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. Configuration de GRE



Un exemple de configuration de GRE est tiré des scripts officiels. Créez 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


J'appelle 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: <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 possÚde un renifleur de paquets intégré - tcpdump. Je vais vider le trafic dans un fichier pcap: 



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


Je cingle 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 actif et fonctionne:







Étape 3. Crypter avec GRE GRE



Définir le type d'identification - par adresse. Authentification à l'aide d'une clé prédéfinie (selon les conditions d'utilisation, vous devez utiliser des certificats numériques): 



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 cible - 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 mise 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


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 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 de trafic GRE:







Conclusion: le schéma GRE-over-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 je le veux.







Pour déployer le schéma GRE-over-IPsec, au contraire, vous avez besoin:



  • Correction de la liste d'accĂšs pour le chiffrement - trafic cible de LAN1 Ă  LAN2 et vice versa;
  • Configurer le routage via GRE;
  • Raccrochez la carte cryptographique sur l'interface GRE.


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



J'ajoute l'interface GRE Ă  la console de type Cisco. Pour ce faire, Ă©ditez 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 d'interface dans le systĂšme d'exploitation, Tunnel0 est la dĂ©signation d'interface dans la console de type Cisco.



Je recalcule le hachage du fichier: 



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

SUCCESS:  Operation was successful.


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


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


Configuration du 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 cryptocard de Fa0 / 0 et la lie Ă  l'interface GRE: 



VG1(config)#
interface Tunnel0
crypto map CMAP


De mĂȘme pour VG2.



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) 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.



RĂ©sultat



Une tasse de café suffisait. Esquissé des instructions sur la façon d'obtenir la démo. Configuré GRE-over-IPsec et déployé dans l'autre sens.



La carte d'interface réseau de la version 4.3 est automatique! Je teste plus loin.



Ingénieur anonyme

t.me/anonimous_engineer


More articles:


All Articles