🥇1.5 scheme pe VPN IPsec autohton. Testez versiunile demo

Situația

Am primit versiunea de probă a produselor S-Terra VPN 4.3 pe o perioadă de trei luni. Vreau să înțeleg dacă viața mea profesională va fi mai ușoară după trecerea la noua versiune.

Astăzi nu este greu, un plic de cafea solubil 3 în 1 ar trebui să fie suficient. Voi explica cum să obțin versiunile demo. Voi încerca să adun schemele GRE-over-IPsec și IPsec-over-GRE.

Cum să obții versiunea de probă

Din desen reiese că pentru a obține versiunea de probă, trebuie:

Să scrii un e-mail la presale@s-terra.ru de pe adresa de e-mail a companiei;
În e-mail, să specifici codul de identificare fiscală al organizației tale;
Să enumeri produsele și cantitatea acestora.

Versiunile de probă sunt valabile timp de trei luni. Furnizorul nu limitează funcționalitatea acestora.

Desfac imaginea

Versiunea de probă a gateway-ului de securitate este o imagine a unei mașini virtuale. Folosesc VMWare Workstation. Lista completă a hipervizorilor și mediilor de virtualizare suportate este disponibilă pe site-ul furnizorului.

Înainte de a începe acțiunile active, rețineți că în imaginea mașinii virtuale, în mod implicit, nu există interfețe de rețea:

Logica este clară, utilizatorul trebuie să adauge atâtea interfețe câte are nevoie. Voi adăuga imediat patru:

Acum pornesc mașina virtuală. Imediat după pornire, gateway-ul cere un nume de utilizator și o parolă.

În S-Terra Gateway există mai multe console cu diferite conturi. Voi număra numărul acestora într-un articol separat. Între timp:
Conectare ca: administrator Parolă: s-terra

Inițializez gateway-ul. Inițializarea este o succesiune de acțiuni: introducerea licenței, configurarea generatorului biologic de numere aleatorii (antrenor de tastatură - recordul meu este de 27 de secunde) și crearea hărții interfețelor de rețea.

Harta interfețelor de rețea. A devenit mai ușor

Versiunea 4.2 saluta utilizatorul activ cu mesaje:

Pornind daemonul IPsec….. eșuat EROARE: Nu s-a putut stabili conexiunea cu daemonul

Utilizator activ (conform unui inginer anonim) – utilizator capabil să configureze orice rapid și fără documentație.

Ceva nu mergea bine, încă înainte de a încerca să configurez IP-ul pe interfață. Totul ține de harta interfețelor de rețea. Era necesar să se execute:

/bin/netifcfg enum > /home/map /bin/netifcfg map /home/map serviciul rețelei repornire

În rezultat, se creează o hartă a interfețelor de rețea, care conține mapparea numelui interfețelor fizice (0000:02:03.0) și denumirile lor logice în sistemul de operare (eth0) și consola Cisco-like (FastEthernet0/0):

#Unique ID iface type OS name Cisco-like name

0000:02:03.0 phye eth0 FastEthernet0/0

Denumirile logice ale interfețelor se numesc aliasuri. Aliasurile sunt stocate în fișierul /etc/ifaliases.cf.
În versiunea 4.3, la prima pornire a mașinii virtuale, harta interfețelor este creată automat. Dacă schimbați numărul de interfețe de rețea în mașina virtuală, vă rugăm să creați din nou harta interfețelor:

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

Schema 1: GRE peste IPsec

Desfășor două gateway-uri virtuale, le conectez așa cum este ilustrat în imagine:

Pasul 1. Configurez adresele IP și rutele

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

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

--- statistici ping 172.16.1.254 ---
4 pachete transmise, 4 primite, 0% pierdere de pachete, timp 3005ms
rtt min/med/max/mdev = 0.273/0.540/0.687/0.164 ms

Pasul 2. Configurez GRE

Exemplul de configurare GRE este preluat din scenariile oficiale. Creez fișierul gre1 în directorul /etc/network/interfaces.d cu conținutul.

Pentru 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

Pentru 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

Activez interfața în sistem:

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

Verific:

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

În S-Terra Gateway există un sniffer de trafic integrat — tcpdump. Voi salva dump-ul de trafic într-un fișier pcap:

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

Execut ping între interfețele 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

--- statistici ping 1.1.1.2 ---
4 pachete transmise, 4 primite, 0% pierdere de pachete, timp 3006ms
rtt min/med/max/mdev = 0.850/0.915/0.974/0.043 ms

Tunelul GRE este activ și funcționează:

Pasul 3. Criptăm GRE cu GOST

Setez tipul de identificare – pe adresă. Autentificarea se face printr-o cheie prestabilită (conform Regulilor de Utilizare, trebuie folosite certificate digitale):

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

Set parameters for IPsec Phase I:

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

Set parameters for IPsec Phase II:

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

Creating an access list for encryption. Target traffic — GRE:

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

Creating a crypto map and binding it to the WAN interface:

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

For VG2, the configuration is mirrored, with differences:

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

Verific:

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

Statistics 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

No GRE packet found in the traffic dump:

Conclusion: the GRE-over-IPsec scheme works correctly.

Diagram 1.5: IPsec-over-GRE

I do not plan to use IPsec-over-GRE in the network. I'm assembling it just because I want to.

To deploy the GRE-over-IPsec scheme in reverse, you need to:

Correct the access list for encryption – target traffic from LAN1 to LAN2 and vice versa;
Configure routing through GRE;
Attach the crypto map to the GRE interface.

By default, in the Cisco-like gateway console, there is no GRE interface. It exists only in the operating system.

I add the GRE interface to the Cisco-like console. For this, I edit the 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="*")

where gre1 is the designation of the interface in the operating system, Tunnel0 is the designation of the interface in the Cisco-like console.

Recalculating the hash of the file:

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

SUCCESS:  Operation was successful.

Now the Tunnel0 interface has appeared in the Cisco-like console:

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

Adjusting the access list for encryption:

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

Configuring routing through GRE:

VG1(config)#
nu 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

Îndepărtez criptocarta de la Fa0/0 și o atașez la interfața GRE:

VG1(config)#
interfața Tunnel0
crypto map CMAP

Pentru VG2 similar.

Verific:

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) de la 192.168.1.253 : 56(84) bytes de date.
64 bytes de la 192.168.2.254: icmp_seq=1 ttl=64 timp=492 ms
64 bytes de la 192.168.2.254: icmp_seq=2 ttl=64 timp=1.08 ms
64 bytes de la 192.168.2.254: icmp_seq=3 ttl=64 timp=1.06 ms
64 bytes de la 192.168.2.254: icmp_seq=4 ttl=64 timp=1.07 ms

--- statistici ping 192.168.2.254 ---
4 pachete transmise, 4 primite, 0% pierdere de pachete, timp 3006ms
rtt min/med/max/mdev = 1.064/124.048/492.972/212.998 ms

Statistics ISAKMP/IPsec:

root@VG1:~# sa_mgr show
Sesiuni ISAKMP: 0 inițiate, 0 răspunse

Conexiuni ISAKMP:
Num Conn-id (Adresă Locală,Port)-(Adresă Remote,Port) Stare Trimise Primite
1 2 (172.16.1.253,500)-(172.16.1.254,500) activ 1094 1022

Conexiuni IPsec:
Num Conn-id (Adresă Locală,Port)-(Adresă Remote,Port) Protocol Tip Acțiune Trimise Primite
1 2 (192.168.1.0-192.168.1.255,*)-(192.168.2.0-192.168.2.255,*) * ESP tunn 352 352

În dump-ul de trafic, pachetele ESP sunt încapsulate în GRE:

Rezultatul: IPsec-over-GRE funcționează corect.

Concluzii

O cană de cafea a fost suficientă. Am schițat o instrucțiune pentru obținerea unei versiuni demo. Am configurat GRE-over-IPsec și am desfășurat invers.

Harta interfețelor de rețea în versiunea 4.3 este automată! Testez mai departe.

Inginer anonim
t.me/anonimous_engineer

Sursa: habr.com