1.5 su VPN IPsec domestica. Demo di prova

La situazione

Ho ricevuto una versione demo dei prodotti C-Terra VPN versione 4.3 per tre mesi. Voglio scoprire se la mia vita da ingegnere diventerà più facile dopo il passaggio alla nuova versione.

Oggi non è difficile, dovrebbe bastare una bustina di caffè istantaneo 3 in 1. Ti dirò come ottenere demo. Proverò a creare gli schemi GRE-over-IPsec e IPsec-over-GRE.

Come ottenere una demo

Dalla figura segue che per ottenere una demo è necessario:

• Scrivi una lettera a [email protected] da un indirizzo aziendale;
• Nella lettera indicare il TIN della propria organizzazione;
• Elenca i prodotti e la loro quantità.

Le demo sono valide per tre mesi. Il fornitore non limita la loro funzionalità.

Espandere l'immagine

La demo di Security Gateway è un'immagine di macchina virtuale. Sto usando VMWare Workstation. Un elenco completo degli hypervisor e degli ambienti di virtualizzazione supportati è disponibile sul sito Web del fornitore.

Prima di iniziare, tieni presente che non ci sono interfacce di rete nell'immagine della macchina virtuale predefinita:

La logica è chiara, l'utente dovrebbe aggiungere tutte le interfacce di cui ha bisogno. Ne aggiungo quattro in una volta:

Ora avvio la macchina virtuale. Subito dopo l'avvio, il gateway richiede un nome utente e una password.

Ci sono diverse console in S-Terra Gateway con diversi account. Conterò il loro numero in un articolo separato. Per adesso:
Login as: administrator
Password: s-terra

Sto inizializzando il gateway. L'inizializzazione è una sequenza di azioni: immissione di una licenza, impostazione di un generatore di numeri casuali biologici (simulatore di tastiera - il mio record è di 27 secondi) e creazione di una mappa dell'interfaccia di rete.

Mappa delle interfacce di rete. È diventato più facile

La versione 4.2 ha salutato l'utente attivo con messaggi:

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

Un utente attivo (secondo un ingegnere anonimo) è un utente che può configurare qualsiasi cosa rapidamente e senza documentazione.

Qualcosa stava andando storto prima di provare a impostare un indirizzo IP sull'interfaccia. Riguarda la mappa dell'interfaccia di rete. Era necessario fare:

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

Di conseguenza, viene creata una mappa dell'interfaccia di rete che contiene la mappatura dei nomi delle interfacce fisiche (0000:02:03.0) e le loro designazioni logiche nel sistema operativo (eth0) e nella console simile a Cisco (FastEthernet0/0):

#Unique ID iface type OS name Cisco-like name

0000:02:03.0 phye eth0 FastEthernet0/0

Le designazioni logiche delle interfacce sono chiamate alias. Gli alias sono memorizzati nel file /etc/ifaliases.cf.
Nella versione 4.3, quando la macchina virtuale viene avviata per la prima volta, viene creata automaticamente una mappa dell'interfaccia. Se modifichi il numero di interfacce di rete nella macchina virtuale, ricrea la mappa dell'interfaccia:

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

Schema 1: GRE su IPsec

Distribuisco due gateway virtuali, cambio come mostrato nella figura:

Passaggio 1. Configura indirizzi IP e percorsi

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

Verifica della connettività 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

Passaggio 2: configurare GRE

Prendo un esempio di configurazione di GRE dagli script ufficiali. Creo un file gre1 nella directory /etc/network/interfaces.d con i contenuti.

Per 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

Per 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

Sollevo l'interfaccia nel sistema:

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

Controllo:

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 ha uno sniffer di pacchetti integrato - tcpdump. Scriverò un dump del traffico in un file pcap:

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

Comincio a eseguire il ping tra le interfacce 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

Il tunnel GRE è attivo e funzionante:

Passaggio 3. Crittografare con GOST GRE

Ho impostato il tipo di identificazione - per indirizzo. Autenticazione con chiave predefinita (in base alle Condizioni d'uso, devono essere utilizzati certificati digitali):

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

Ho impostato i parametri IPsec Phase I:

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

Ho impostato i parametri IPsec Phase II:

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

Creo un elenco di accesso per la crittografia. Traffico mirato - GRE:

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

Creo una mappa crittografica e la lego all'interfaccia 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

Per VG2, la configurazione è speculare, le differenze sono:

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

Controllo:

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

Statistiche 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

Non ci sono pacchetti nel dump del traffico GRE:

Conclusione: lo schema GRE-over-IPsec funziona correttamente.

Figura 1.5: IPsec su GRE

Non ho intenzione di utilizzare IPsec-over-GRE sulla rete. Colleziono perché voglio.

Per implementare lo schema GRE-over-IPsec al contrario:

• Fix elenco di accesso alla crittografia: traffico mirato da LAN1 a LAN2 e viceversa;
• Configurare il routing tramite GRE;
• Appendi una mappa crittografica sull'interfaccia GRE.

Per impostazione predefinita, non esiste un'interfaccia GRE nella console del gateway simile a Cisco. Esiste solo nel sistema operativo.

Aggiungo l'interfaccia GRE alla console simile a Cisco. Per fare ciò, modifico il file /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="*")

dove gre1 è la designazione dell'interfaccia nel sistema operativo, Tunnel0 è la designazione dell'interfaccia nella console simile a Cisco.

Ricalcolo l'hash del file:

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

SUCCESS:  Operation was successful.

Ora l'interfaccia Tunnel0 è apparsa nella console simile a Cisco:

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

Correzione dell'elenco di accesso per la crittografia:

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

Configuro il routing tramite 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

Rimuovo la cryptomap da Fa0/0 e la associo all'interfaccia GRE:

VG1(config)#
interface Tunnel0
crypto map CMAP

Per VG2 è simile.

Controllo:

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

Statistiche 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

Nel dump del traffico ESP, i pacchetti incapsulati in GRE:

Conclusione: IPsec-over-GRE funziona correttamente.

Risultati di

Bastava una tazza di caffè. Ho abbozzato le istruzioni per ottenere una versione demo. Configurato GRE-over-IPsec e distribuito viceversa.

La mappa delle interfacce di rete nella versione 4.3 è automatica! Sto testando ulteriormente.

Ingegnere anonimo
t.me/anonymous_engineer

Fonte: habr.com