1.5 schema's op binnenlandse IPsec VPN. Demo's testen

De situatie

Ik heb drie maanden lang een demoversie van C-Terra VPN-producten versie 4.3 ontvangen. Ik wil weten of mijn technische leven gemakkelijker zal worden na het overstappen op de nieuwe versie.

Vandaag is niet moeilijk, één zak oploskoffie 3 in 1 zou voldoende moeten zijn. Ik zal je vertellen hoe je demo's kunt krijgen. Ik zal proberen de GRE-over-IPsec- en IPsec-over-GRE-schema's te bouwen.

Hoe u een demo kunt krijgen

Uit de figuur volgt dat om een ​​demo te krijgen, je het volgende moet doen:

• Schrijf een brief aan [e-mail beveiligd] vanaf een zakelijk adres;
• Vermeld in de brief het TIN van uw organisatie;
• Maak een lijst van de producten en hun aantal.

Demo's zijn drie maanden geldig. De leverancier beperkt hun functionaliteit niet.

Het vergroten van de afbeelding

De Security Gateway-demo is een image van een virtuele machine. Ik gebruik VMWare Workstation. Een volledige lijst met ondersteunde hypervisors en virtualisatie-omgevingen is beschikbaar op de website van de leverancier.

Houd er voordat u begint rekening mee dat er geen netwerkinterfaces zijn in de standaardafbeelding van de virtuele machine:

De logica is duidelijk, de gebruiker moet zoveel interfaces toevoegen als hij nodig heeft. Ik zal er vier tegelijk toevoegen:

Nu start ik de virtuele machine. Direct na het opstarten heeft de gateway een gebruikersnaam en wachtwoord nodig.

Er zijn verschillende consoles in S-Terra Gateway met verschillende accounts. Ik zal hun aantal tellen in een apart artikel. Voor nu:
Login as: administrator
Password: s-terra

Ik initialiseer de gateway. Initialisatie is een opeenvolging van acties: het invoeren van een licentie, het opzetten van een biologische willekeurige nummergenerator (toetsenbordsimulator - mijn record is 27 seconden) en het maken van een netwerkinterfacekaart.

Kaart van netwerkinterfaces. Het werd makkelijker

Versie 4.2 begroette de actieve gebruiker met berichten:

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

Een actieve gebruiker (volgens een anonieme engineer) is een gebruiker die snel en zonder documentatie alles kan instellen.

Er ging iets mis voordat u probeerde een IP-adres op de interface in te stellen. Het draait allemaal om de netwerkinterfacekaart. Het was nodig om te doen:

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

Als resultaat wordt een netwerkinterfacekaart gemaakt die de toewijzing van fysieke interfacenamen (0000:02:03.0) en hun logische aanduidingen in het besturingssysteem (eth0) en Cisco-achtige console (FastEthernet0/0) bevat:

#Unique ID iface type OS name Cisco-like name

0000:02:03.0 phye eth0 FastEthernet0/0

De logische benamingen van interfaces worden aliassen genoemd. Aliassen worden opgeslagen in het bestand /etc/ifaliases.cf.
In versie 4.3 wordt, wanneer de virtuele machine voor het eerst wordt gestart, automatisch een interfacekaart gemaakt. Als u het aantal netwerkinterfaces in de virtuele machine wijzigt, maakt u de interfacekaart opnieuw:

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

Schema 1: GRE-over-IPsec

Ik implementeer twee virtuele gateways, ik schakel zoals weergegeven in de afbeelding:

Stap 1. Stel IP-adressen en routes in

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

IP-connectiviteit controleren:

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

Stap 2: Stel GRE in

Ik neem een ​​voorbeeld van het instellen van GRE vanuit officiële scripts. Ik maak een gre1-bestand in de map /etc/network/interfaces.d met de inhoud.

Voor 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

Voor 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

Ik verhoog de interface in het systeem:

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

Controleren:

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 heeft een ingebouwde pakketsniffer - tcpdump. Ik zal een verkeersdump naar een pcap-bestand schrijven:

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

Ik begin te pingen tussen GRE-interfaces:

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-tunnel is in gebruik:

Stap 3. Versleutel met GOST GRE

Ik heb het type identificatie ingesteld - op adres. Authenticatie met een vooraf gedefinieerde sleutel (volgens de gebruiksvoorwaarden moeten digitale certificaten worden gebruikt):

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

Ik heb de IPsec Phase I-parameters ingesteld:

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

Ik heb de IPsec Phase II-parameters ingesteld:

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

Ik maak een toegangslijst voor codering. Gericht verkeer - GRE:

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

Ik maak een cryptomap en bind deze aan de 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

Voor VG2 is de configuratie gespiegeld, de verschillen zijn:

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

Controleren:

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

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

Er zijn geen pakketten in de GRE-verkeersdump:

Conclusie: het GRE-over-IPsec-schema werkt correct.

Afbeelding 1.5: IPsec-over-GRE

Ik ben niet van plan IPsec-over-GRE op het netwerk te gebruiken. Ik verzamel omdat ik dat wil.

Om het GRE-over-IPsec-schema andersom te implementeren:

• Fix encryptie toegangslijst - gericht verkeer van LAN1 naar LAN2 en vice versa;
• Routering configureren via GRE;
• Hang een cryptomap aan de GRE-interface.

Standaard is er geen GRE-interface in de Cisco-achtige gatewayconsole. Het bestaat alleen in het besturingssysteem.

Ik voeg de GRE-interface toe aan de Cisco-achtige console. Om dit te doen, bewerk ik het bestand /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="*")

waar gre1 de interface-aanduiding in het besturingssysteem is, is Tunnel0 de interface-aanduiding in de Cisco-achtige console.

Ik herbereken de hash van het bestand:

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

SUCCESS:  Operation was successful.

Nu is de Tunnel0-interface verschenen in de Cisco-achtige console:

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

De toegangslijst corrigeren voor codering:

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

Ik configureer routering via 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

Ik verwijder de cryptomap van Fa0 / 0 en bind deze aan de GRE-interface:

VG1(config)#
interface Tunnel0
crypto map CMAP

Voor VG2 is het vergelijkbaar.

Controleren:

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

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

In de ESP-verkeersdump, de pakketten ingekapseld in GRE:

Conclusie: IPsec-over-GRE werkt correct.

Resultaten van

Een kopje koffie was voldoende. Ik schetste instructies voor het verkrijgen van een demoversie. GRE-over-IPsec geconfigureerd en vice versa geïmplementeerd.

De kaart van netwerkinterfaces in versie 4.3 is automatisch! Ik test verder.

Anonieme ingenieur
t.me/anonieme_ingenieur

Bron: www.habr.com