🥇1.5 skemaer på indenlandsk IPsec VPN. Tester demo-versioner

Situation

Jeg har modtaget en demo-version af S-Terra VPN version 4.3 i tre måneder. Jeg vil finde ud af, om mit ingeniør-liv bliver lettere efter overgangen til den nye version.

I dag er det ikke svært; en pakke med instant kaffe 3 i 1 skulle være nok. Jeg vil fortælle, hvordan man får demo-versioner. Jeg vil forsøge at samle GRE-over-IPsec og IPsec-over-GRE skjemaer.

Hvordan man får en demo-version

Fra diagrammet fremgår det, at for at få en demo-version, skal man:

Skrive en e-mail til presale@s-terra.ru fra en arbejdsmailadresse;
Angive CVR-nummeret for din organisation i e-mailen;
Nævne produkterne og deres antal.

Demo-versioner er gyldige i tre måneder. Leverandøren begrænser ikke deres funktionalitet.

Jeg opretter billedet

Demo-versionen af sikkerhedsgatewayen er et billede af en virtuel maskine. Jeg bruger VMWare Workstation. Den fulde liste over understøttede hypervisorer og virtualiseringsmiljøer er placeret på leverandørens hjemmeside.

Før jeg går i gang, skal jeg bemærke, at der som standard ikke er netværksgrænseflader i billedet af den virtuelle maskine:

Logikken er klar, brugeren skal tilføje så mange grænseflader, som han har brug for. Jeg vil tilføje fire med det samme:

Nu starter jeg den virtuelle maskine. Lige efter starten kræver gatewayen login og password.

I S-Terra Gateway er der flere konsoller med forskellige konti. Jeg vil tælle dem i en separat artikel. Indtil da:
Log ind som: administrator Adgangskode: s-terra

Jeg initierer gatewayen. Initiering er en sekvens af handlinger: indtastning af licens, opsætning af en biologisk tilfældighedsgenerator (tastaturtræner – min rekord er 27 sekunder) og oprettelse af kort over netværksgrænseflader.

Kort over netværksgrænseflader. Det er blevet lettere

Version 4.2 bød aktive brugere velkommen med beskeder:

Start af IPsec-daemon..... mislykkedes FEJL: Kunne ikke oprette forbindelse til daemon

Aktiv bruger (ifølge en anonym ingeniør) – en bruger, der er i stand til at konfigurere hvad som helst hurtigt og uden dokumentation.

Der gik noget galt, allerede før forsøgene på at konfigurere IP-adressen på grænsefladen. Alt var et spørgsmål om kortet over netværksgrænseflader. Det skulle udføres:

/bin/netifcfg enum > /home/map /bin/netifcfg map /home/map genstart netværkstjenesten

Resultatet er et kort over netværksgrænseflader, der indeholder mapping af navne på fysiske grænseflader (0000:02:03.0) og deres logiske betegnelse i operativsystemet (eth0) og Cisco-lignende konsol (FastEthernet0/0):

#Unique ID iface type OS name Cisco-like name

0000:02:03.0 phye eth0 FastEthernet0/0

De logiske betegnelser for grænseflader kaldes aliaser. Aliaser opbevares i filen /etc/ifaliases.cf.
I version 4.3 oprettes interfacekortet automatisk ved første opstart af den virtuelle maskine. Hvis du ændrer antallet af netværksinterfaces i den virtuelle maskine, er du venligst nødt til at oprette interfacekortet på ny:

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

Diagram 1: GRE-over-IPsec

Jeg opsætter to virtuelle gateways og forbinder dem som vist på billedet:

Trin 1. Konfigurerer IP-adresser og ruter

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

Jeg tjekker IP-forbindelsen:

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-statistik ---
4 pakker sendt, 4 modtaget, 0% pakke tab, tid 3005ms
rtt min/avg/max/mdev = 0.273/0.540/0.687/0.164 ms

Trin 2. Konfigurerer GRE

Jeg tager GRE-konfigurationen fra de officielle scripts. Jeg opretter filen gre1 i mappen /etc/network/interfaces.d med indholdet.

For 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

For 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

Jeg aktiverer interfaced i systemet:

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

Jeg tjekker:

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 for evigt foretrukken_lft for evigt

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

I C-Terra Gateway er der en indbygget paketsniffer — tcpdump. Jeg vil optage trafikdumpen i en pcap-fil:

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

Jeg starter ping mellem GRE-interface:

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-statistik ---
4 pakker sendt, 4 modtaget, 0% pakke tab, tid 3006ms
rtt min/avg/max/mdev = 0.850/0.915/0.974/0.043 ms

GRE-tunnelen er aktiv og fungerer:

Trin 3. Krypterer GRE med GOST

Jeg angiver identifikationstypen – baseret på adresse. Godkendelse med en forudbestemt nøgle (ifølge Brugsbetingelserne skal digitale certifikater bruges):

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

Jeg angiver IPsec Phase I parametre:

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

Jeg angiver IPsec Phase II parametre:

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

Jeg opretter en adgangsliste til kryptering. Måltrafik — GRE:

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

Jeg opretter en kryptokort og binder den til WAN-interfacet:

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 er konfigurationen spejlet, med forskelle:

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

Jeg tjekker:

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 statistik ---
4 pakker sendt, 4 modtaget, 0% pakken tabt, tid 3006ms
rtt min/avg/max/mdev = 1.077/314.271/1128.419/472.826 ms, pipe 2

ISAKMP/IPsec statistik:

root@VG1:~# sa_mgr show
ISAKMP sessioner: 0 initieret, 0 reageret

ISAKMP forbindelser:
Num Conn-id (Lokal Addr,Port)-(Fjern Addr,Port) Tilstand Sendt Modtaget
1 1 (172.16.1.253,500)-(172.16.1.254,500) aktiv 1086 1014

IPsec forbindelser:
Num Conn-id (Lokal Addr,Port)-(Fjern Addr,Port) Protokol Handling Type Sendt Modtaget
1 1 (172.16.1.253,*)-(172.16.1.254,*) 47 ESP tunn 480 480

I dumpen af trafik er der ingen GRE pakker:

Konklusion: GRE-over-IPsec opsætningen fungerer korrekt.

Diagram 1.5: IPsec-over-GRE

Jeg planlægger ikke at bruge IPsec-over-GRE i netværket. Jeg samler det, fordi jeg har lyst.

For at implementere GRE-over-IPsec omvendt skal jeg:

Rette adgangslisten til kryptering – måltrafik fra LAN1 til LAN2 og omvendt;
Konfigurere routning gennem GRE;
Binde kryptokortet til GRE-interfacet.

Som standard er der ingen GRE-interface i Cisco-lignende konsol på gatewayen. Det eksisterer kun i operativsystemet.

Jeg tilføjer GRE-interface til Cisco-lignende konsol. For at gøre dette redigerer jeg filen /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="*")

hvor gre1 er betegnelsen for interface i operativsystemet, Tunnel0 er betegnelsen for interface i Cisco-lignende konsol.

Jeg tjekker filens hash:

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

SUCCESS:  Operation was successful.

Nu er interface Tunnel0 dukket op i Cisco-lignende konsol:

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

Jeg retter adgangslisten til kryptering:

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

Jeg konfigurerer routning gennem 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

Fjerner kryptokortet fra Fa0/0 og tilknytter det til GRE-interfacet:

VG1(config)#
interface Tunnel0
crypto map CMAP

For VG2 er det det samme.

Jeg tjekker:

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

--- 192.168.2.254 ping-statistik ---
4 pakker sendt, 4 modtaget, 0% pakke tabt, tid 3006ms
rtt min/gennemsn./maks/mdev = 1.064/124.048/492.972/212.998 ms

ISAKMP/IPsec statistik:

root@VG1:~# sa_mgr show
ISAKMP sessioner: 0 initieret, 0 besvaret

ISAKMP forbindelser:
Num Conn-id (Lokal Addr,Port)-(Fjern Addr,Port) Status Sendt Modtaget
1 2 (172.16.1.253,500)-(172.16.1.254,500) aktiv 1094 1022

IPsec forbindelser:
Num Conn-id (Lokal Addr,Port)-(Fjern Addr,Port) Protokol Handling Type Sendt Modtaget
1 2 (192.168.1.0-192.168.1.255,*)-(192.168.2.0-192.168.2.255,*) * ESP tunn 352 352

I trafikdumpen er ESP-pakker indkapslet i GRE:

Output: IPsec-over-GRE fungerer korrekt.