1.5 ordninger på indenlandsk IPsec VPN. Test af demoer

Situationen

Jeg modtog en demoversion af C-Terra VPN-produkter version 4.3 i tre måneder. Jeg vil gerne finde ud af, om mit ingeniørliv bliver lettere efter at have skiftet til den nye version.

I dag er det ikke svært, en pose instant kaffe 3 i 1 burde være nok. Jeg vil fortælle dig, hvordan du får demoer. Jeg vil prøve at bygge GRE-over-IPsec- og IPsec-over-GRE-skemaerne.

Sådan får du en demo

Det følger af figuren, at for at få en demo skal du:

• Skriv et brev til [e-mail beskyttet] fra en virksomhedsadresse;
• Angiv din organisations TIN i brevet;
• Angiv produkterne og deres mængder.

Demoer er gyldige i tre måneder. Sælgeren begrænser ikke deres funktionalitet.

Udvidelse af billedet

Security Gateway-demoen er et virtuel maskinbillede. Jeg bruger VMWare Workstation. En komplet liste over understøttede hypervisorer og virtualiseringsmiljøer er tilgængelig på leverandørens websted.

Før du begynder, skal du være opmærksom på, at der ikke er nogen netværksgrænseflader i standardbilledet for den virtuelle maskine:

Logikken er klar, brugeren skal tilføje så mange grænseflader, som han har brug for. Jeg tilføjer fire på én gang:

Nu starter jeg den virtuelle maskine. Umiddelbart efter lanceringen kræver gatewayen et brugernavn og en adgangskode.

Der er flere konsoller i S-Terra Gateway med forskellige konti. Jeg vil tælle deres antal i en separat artikel. For nu:
Login as: administrator
Password: s-terra

Jeg initialiserer gatewayen. Initialisering er en sekvens af handlinger: indtastning af en licens, opsætning af en biologisk tilfældig talgenerator (tastatursimulator - min rekord er 27 sekunder) og oprettelse af et netværkskort.

Kort over netværksgrænseflader. Det blev nemmere

Version 4.2 hilste den aktive bruger med beskeder:

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

En aktiv bruger (ifølge en anonym ingeniør) er en bruger, der kan sætte alt op hurtigt og uden dokumentation.

Noget gik galt, før du forsøgte at konfigurere en IP-adresse på grænsefladen. Det hele handler om netværksgrænsefladekortet. Det var nødvendigt at gøre:

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

Som et resultat oprettes et netværksgrænsefladekort, der indeholder kortlægningen af ​​fysiske grænsefladenavne (0000:02:03.0) og deres logiske betegnelser 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 er gemt i filen /etc/ifaliases.cf.
I version 4.3, når den virtuelle maskine startes første gang, oprettes et interfacekort automatisk. Hvis du ændrer antallet af netværksgrænseflader i den virtuelle maskine, skal du genskabe grænsefladekortet:

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

Skema 1: GRE-over-IPsec

Jeg implementerer to virtuelle gateways, jeg skifter som vist på figuren:

Trin 1. Konfigurer 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

Kontrol af IP-forbindelse:

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

Trin 2: Konfigurer GRE

Jeg tager et eksempel på opsætning af GRE fra officielle scripts. Jeg opretter en gre1-fil i mappen /etc/network/interfaces.d med indholdet.

Til 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

Til 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 hæver grænsefladen i systemet:

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

Tjekker:

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 har en indbygget pakkesniffer - tcpdump. Jeg vil skrive et trafikdump til en pcap-fil:

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

Jeg begynder at pinge mellem GRE-grænseflader:

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

GRE-tunnelen er oppe at køre:

Trin 3. Krypter med GOST GRE

Jeg indstiller typen af ​​identifikation - efter adresse. Autentificering med en foruddefineret nøgle (i henhold til brugsbetingelserne skal der bruges digitale certifikater):

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

Jeg indstiller IPsec Phase I-parametrene:

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

Jeg indstiller IPsec Phase II-parametrene:

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

Jeg opretter en adgangsliste til kryptering. Målrettet trafik - GRE:

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

Jeg opretter et kryptokort og binder det til WAN-grænsefladen:

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, forskellene er:

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

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

ISAKMP/IPsec statistik:

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

Der er ingen pakker i GRE-trafikdumpet:

Konklusion: GRE-over-IPsec-skemaet fungerer korrekt.

Figur 1.5: IPsec-over-GRE

Jeg planlægger ikke at bruge IPsec-over-GRE på netværket. Jeg samler ind, fordi jeg gerne vil.

For at implementere GRE-over-IPsec-ordningen omvendt:

• Fix krypteringsadgangsliste - målrettet trafik fra LAN1 til LAN2 og omvendt;
• Konfigurer routing gennem GRE;
• Hæng et kryptokort på GRE-grænsefladen.

Som standard er der ingen GRE-grænseflade i den Cisco-lignende gateway-konsol. Det findes kun i operativsystemet.

Jeg tilføjer GRE-grænsefladen til den 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 grænsefladebetegnelsen i operativsystemet, Tunnel0 er grænsefladebetegnelsen i den Cisco-lignende konsol.

Jeg genberegner filens hash:

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

SUCCESS:  Operation was successful.

Nu er Tunnel0-grænsefladen dukket op i den Cisco-lignende konsol:

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

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

Jeg fjerner kryptokortet fra Fa0 / 0 og binder det til GRE-grænsefladen:

VG1(config)#
interface Tunnel0
crypto map CMAP

For VG2 er det lignende.

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

ISAKMP/IPsec statistik:

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

I ESP-trafikdumpet er pakkerne indkapslet i GRE:

Konklusion: IPsec-over-GRE fungerer korrekt.

Resultaterne af

En kop kaffe var nok. Jeg skitserede instruktioner til at få en demoversion. Konfigureret GRE-over-IPsec og implementeret omvendt.

Kortet over netværksgrænseflader i version 4.3 er automatisk! Jeg tester videre.

Anonym ingeniør
t.me/anonym_ingeniør

Kilde: www.habr.com