🥇1.5 schemi su VPN IPsec nazionali. Testing delle versioni demo

Situazione

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

Oggi non è difficile, un pacchetto di caffè solubile 3 in 1 dovrebbe bastare. Racconterò come ottenere le versioni di prova. Proverò a configurare schemi GRE-over-IPsec e IPsec-over-GRE.

Come ottenere una versione di prova

Dal disegno risulta che per ottenere una versione di prova è necessario:

Scrivere un'email a presale@s-terra.ru da un indirizzo aziendale;
Nell'email indicare il codice fiscale della tua organizzazione;
Elencare i prodotti e le loro quantità.

Le versioni di prova sono valide per tre mesi. Il fornitore non limita la loro funzionalità.

Sto avviando l'immagine

La versione di prova del gateway di sicurezza è un'immagine di macchina virtuale. Sto usando VMWare Workstation. L'elenco completo degli hypervisor e degli ambienti di virtualizzazione supportati è disponibile sul sito del fornitore.

Prima di iniziare azioni attive, fai attenzione che nell'immagine della macchina virtuale non ci sono interfacce di rete per impostazione predefinita:

La logica è chiara, l'utente deve aggiungere tante interfacce quante ne ha bisogno. Ne aggiungerò subito quattro:

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

In C-Terra Gateway ci sono più console con diverse credenziali. Conterò il loro numero in un articolo separato. Ma per ora:
Accedi come: amministratore Password: s-terra

Inizializzo il gateway. L'inizializzazione è una sequenza di operazioni: inserimento della licenza, configurazione del generatore biologico di numeri casuali (il simulatore di tastiera – il mio record è di 27 secondi) e creazione della mappa delle interfacce di rete.

Mappa delle interfacce di rete. Ora è più facile.

La versione 4.2 accoglieva l'utente attivo con messaggi:

Avvio del demone IPsec….. fallito ERRORE: Impossibile stabilire una connessione con il demone

Un utente attivo (secondo l'ingegnere anonimo) è un utente in grado di configurare qualsiasi cosa rapidamente e senza documentazione.

Qualcosa non andava, già prima di tentare di configurare l'indirizzo IP sull'interfaccia. Tutto dipende dalla mappa delle interfacce di rete. Era necessario eseguire:

/bin/netifcfg enum > /home/map /bin/netifcfg map /home/map riavviare il servizio di rete

Di conseguenza, viene creata una mappa delle interfacce di rete, che contiene il mapping 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, al primo avvio della macchina virtuale, la mappa delle interfacce viene creata automaticamente. Se cambi il numero delle interfacce di rete nella virtual machine, assicurati di ricreare la mappa delle interfacce.

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

Schema 1: GRE-over-IPsec

Distribuisco due gateway virtuali, collegandoli come mostrato nell'immagine:

Passo 1. Configuro gli indirizzi IP e le rotte

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

Controllo la 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 statistiche ping ---
4 pacchetti trasmessi, 4 ricevuti, 0% perdita di pacchetti, tempo 3005ms
rtt min/avg/max/mdev = 0.273/0.540/0.687/0.164 ms

Passo 2. Configuro GRE

Prendo un esempio di configurazione GRE dagli scenari ufficiali. Creo un file gre1 nella directory /etc/network/interfaces.d con il contenuto.

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

Attivando l'interfaccia nel sistema:

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

Controllo:

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

In C-Terra, il Gateway ha un pacchetto sniffer integrato — tcpdump. Registrerò un dump del traffico in un file pcap:

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

Avvio 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 statistiche ping ---
4 pacchetti trasmessi, 4 ricevuti, 0% perdita di pacchetti, tempo 3006ms
rtt min/avg/max/mdev = 0.850/0.915/0.974/0.043 ms

Il tunnel GRE è attivo e funzionante:

Passo 3. Criptiamo con GOST il GRE

Imposto il tipo di identificazione: per indirizzo. Autenticazione tramite chiave predefinita (secondo le Regole di Utilizzo è necessario utilizzare certificati digitali):

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

Imposto i parametri IPsec Fase I:

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

Imposto i parametri IPsec Fase II:

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

Creo una lista di accesso per la crittografia. Traffico target — 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 associo 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:

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

--- statistiche ping 1.1.1.2 ---
4 pacchetti trasmessi, 4 ricevuti, 0% perdita di pacchetti, tempo 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 sessioni: 0 avviate, 0 risposte

Connessioni ISAKMP:
Num Conn-id (Indirizzo locale, Porta)-(Indirizzo remoto, Porta) Stato Inviato Ricevuto
1 1 (172.16.1.253,500)-(172.16.1.254,500) attivo 1086 1014

Connessioni IPsec:
Num Conn-id (Indirizzo locale, Porta)-(Indirizzo remoto, Porta) Protocollo Azione Tipo Inviato Ricevuto
1 1 (172.16.1.253,*)-(172.16.1.254,*) 47 ESP tunn 480 480

Nel dump del traffico non ci sono pacchetti GRE:

Output: la configurazione GRE-over-IPsec funziona correttamente.

Schema 1.5: IPsec-over-GRE

Non ho intenzione di utilizzare IPsec-over-GRE nella rete. Lo impostiamo, solo per curiosità.

Per rovesciare lo schema GRE-over-IPsec è necessario:

Modificare l'elenco di accesso per la crittografia – traffico di destinazione da LAN1 a LAN2 e viceversa;
Configurare la routing tramite GRE;
Attaccare la chiave crittografica all'interfaccia GRE.

Di default nella console simile a Cisco del gateway non esiste un'interfaccia GRE. Essa esiste solo nel sistema operativo.

Aggiungo l'interfaccia GRE nella console simile a Cisco. Per fare ciò modifico il file /etc/ifaliases.cf:

interfaccia (nome="FastEthernet0/0" modello="eth0")
interfaccia (nome="FastEthernet0/1" modello="eth1")
interfaccia (nome="FastEthernet0/2" modello="eth2")
interfaccia (nome="FastEthernet0/3" modello="eth3")
interfaccia (nome="Tunnel0" modello="gre1")
interfaccia (nome="default" modello="*")

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: Operazione riuscita.

Adesso l'interfaccia Tunnel0 è apparsa nella console in stile Cisco:

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

Correggo l'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 la routing attraverso 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 mappa crittografica da Fa0/0 e la collego all'interfaccia GRE:

VG1(config)#
interface Tunnel0
crypto map CMAP

Per VG2 è analogo.

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) da 192.168.1.253 : 56(84) byte di dati.
64 byte da 192.168.2.254: icmp_seq=1 ttl=64 time=492 ms
64 byte da 192.168.2.254: icmp_seq=2 ttl=64 time=1.08 ms
64 byte da 192.168.2.254: icmp_seq=3 ttl=64 time=1.06 ms
64 byte da 192.168.2.254: icmp_seq=4 ttl=64 time=1.07 ms

--- statistiche del ping su 192.168.2.254 ---
4 pacchetti trasmessi, 4 ricevuti, 0% di perdita, tempo 3006ms
rtt min/avg/max/mdev = 1.064/124.048/492.972/212.998 ms

Statistiche ISAKMP/IPsec:

root@VG1:~# sa_mgr show
Sessioni ISAKMP: 0 iniziate, 0 risposte

Connessioni ISAKMP:
Num Conn-id (Indirizzo locale,Porta)-(Indirizzo remoto,Porta) Stato Inviati Ricevuti
1 2 (172.16.1.253,500)-(172.16.1.254,500) attivo 1094 1022

Connessioni IPsec:
Num Conn-id (Indirizzo locale,Porta)-(Indirizzo remoto,Porta) Protocollo Tipo Azione Inviati Ricevuti
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, pacchetti ESP incapsulati in GRE:

Risultato: IPsec-over-GRE funziona correttamente.