🥇1.5 schemi su VPN IPsec nazionali. Testo versioni demo

Situazione

Ho ricevuto la versione demo dei prodotti S-Terra VPN versione 4.3 per tre mesi. Voglio capire se la mia vita ingegneristica 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 demo. Proverò a raccogliere gli schemi GRE-over-IPsec e IPsec-over-GRE.

Come ottenere una versione demo

Dalla figura si evince che per ottenere la versione demo è necessario:

Scrivere un'email a presale@s-terra.ru da un'email aziendale;
Nel messaggio indicare il codice fiscale della vostra organizzazione;
Elencare i prodotti e il loro numero.

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

Sto distribuendo l'immagine

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

Prima di intraprendere azioni attive, notate 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 S-Terra Gateway ci sono diverse console con conti diversi. Ne conterò il numero in un articolo separato. Nel frattempo:
Accedi come: amministratore Password: s-terra

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

Mappa delle interfacce di rete. È diventato 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

L'utente attivo (secondo la definizione di un ingegnere anonimo) è un utente capace di configurare qualsiasi cosa rapidamente e senza documentazione.

Qualcosa stava andando storto, anche prima dei tentativi 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 servizio di networking riavvio

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 vengono 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 modifichi il numero delle interfacce di rete nella macchina virtuale, ti prego di ricreare la mappa delle interfacce:

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

Schema 1: GRE su IPsec

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

Passaggio 1. Configuro gli indirizzi IP e le route

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

--- statistiche del ping di 172.16.1.254 ---
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

Passaggio 2. Configuro GRE

Prendo un esempio di configurazione GRE dagli scenari ufficiali. Creo il 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

Attivo 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 S-Terra Gateway c'è un pacchetto sniffer incorporato — tcpdump. Registrerò il dump del traffico in un file pcap:

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

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

--- statistiche del ping di 1.1.1.2 ---
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:

Passaggio 3. Cripto con il GOST GRE

Imposto il tipo di identificazione – per indirizzo. L'autenticazione avviene tramite una chiave predefinita (secondo le Normative d'Uso si devono utilizzare certificati digitali):

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

Imposto i parametri IPsec Phase I:

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

Imposto i parametri IPsec Phase II:

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

Creo una lista di accesso per la crittografia. Traffico di destinazione — GRE:

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

Creo una critto-mappa e la levo 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) byte di dati.
64 byte da 1.1.1.2: icmp_seq=1 ttl=64 time=1128 ms
64 byte da 1.1.1.2: icmp_seq=2 ttl=64 time=126 ms
64 byte da 1.1.1.2: icmp_seq=3 ttl=64 time=1.07 ms
64 byte da 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
Sessioni ISAKMP: 0 iniziate, 0 risposte

Connessioni ISAKMP:
Num Conn-id (Indirizzo Locale,Porta)-(Indirizzo Remoto,Porta) Stato Inviati Ricevuti
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 Tipo Azione Inviati Ricevuti
1 1 (172.16.1.253,*)-(172.16.1.254,*) 47 ESP tunn 480 480

Nella cattura del traffico non ci sono pacchetti GRE:

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

Schema 1.5: IPsec-over-GRE

Non ho intenzione di utilizzare IPsec-over-GRE nella rete. Lo creo perché voglio.

Per rovesciare lo schema GRE-over-IPsec bisogna:

Correggere la lista di accesso per la crittografia – traffico di destinazione da LAN1 a LAN2 e viceversa;
Configurare la routing attraverso GRE;
Attaccare la critto-mappa all'interfaccia GRE.

Per impostazione predefinita nella console simile a Cisco 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 (name="FastEthernet0/0" pattern="eth0")
interfaccia (name="FastEthernet0/1" pattern="eth1")
interfaccia (name="FastEthernet0/2" pattern="eth2")
interfaccia (name="FastEthernet0/3" pattern="eth3")
interfaccia (name="Tunnel0" pattern="gre1")
interfaccia (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: Operazione riuscita.

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

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

Correggo la lista 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 scheda di crittografia da Fa0/0 e la collego 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) 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 ping per 192.168.2.254 ---
4 pacchetti trasmessi, 4 ricevuti, 0% perdita di pacchetti, 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 Tipologia 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 i pacchetti ESP, incapsulati in GRE:

Risultato: IPsec-over-GRE funziona correttamente.