🥇1.5 schema's op binnenlandse IPsec VPN. Ik test demo's

Situatie

Ik heb de demo-versie van de C-Terra VPN producten versie 4.3 ontvangen voor drie maanden. Ik wil begrijpen of mijn ingenieursleven gemakkelijker wordt na de overstap naar de nieuwe versie.

Vandaag is het niet moeilijk, één zakje oploskoffie 3 in 1 zou genoeg moeten zijn. Ik zal uitleggen hoe je demo-versies kunt krijgen. Ik probeer GRE-over-IPsec en IPsec-over-GRE schema's te maken.

Hoe een demo-versie te krijgen

Uit de afbeelding blijkt dat je de demo-versie als volgt kunt krijgen:

Stuur een e-mail naar presale@s-terra.ru vanaf een zakelijk adres;
Vermeld in de e-mail het btw-nummer van uw organisatie;
Lijst de producten en hun hoeveelheid op.

Demo-versies zijn drie maanden geldig. De leverancier beperkt hun functionaliteit niet.

Ik draai het image op

De demo-versie van de beveiligingsgateway is een virtuele machine image. Ik gebruik VMWare Workstation. Een volledige lijst van ondersteunde hypervisors en virtualisatie-omgevingen is te vinden op de website van de leverancier.

Let voordat je actieve stappen onderneemt op dat er standaard geen netwerkinterfaces in de virtuele machine image aanwezig zijn:

De logica is duidelijk, de gebruiker moet zoveel interfaces toevoegen als nodig is. Ik voeg er meteen vier toe:

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

In de C-Terra Gateway zijn er verschillende consoles met verschillende accounts. Ik tel hun aantal in een apart artikel. Voor nu:
Inloggen als: administrator Wachtwoord: s-terra

Ik initialiseer de gateway. Initialisatie is een reeks acties: licentie invoeren, configureren van de biogene random number generator (toetsenbordtrainer - mijn record is 27 seconden) en het maken van de landkaart van netwerkinterfaces.

De landkaart van netwerkinterfaces. Het is verbeterd

Versie 4.2 verwelkomde actieve gebruikers met berichten:

IPsec-daemon starten….. mislukt FOUT: Verbinding met daemon kon niet worden gelegd

Een actieve gebruiker (volgens de anonieme ingenieur) is een gebruiker die in staat is om alles snel en zonder documentatie in te stellen.

Er ging iets mis, zelfs vóór de pogingen om een IP-adres op de interface in te stellen. Het probleem ligt bij de landkaart van netwerkinterfaces. Je moest het volgende doen:

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

Als resultaat wordt een landkaart van netwerkinterfaces gemaakt, die de mapping bevat van de namen van fysieke interfaces (0000:02:03.0) en hun logische aanduidingen in het besturingssysteem (eth0) en de Cisco-achtige console (FastEthernet0/0):

#Unique ID iface type OS name Cisco-like name

0000:02:03.0 phye eth0 FastEthernet0/0

Logische aanduidingen van interfaces worden aliassen genoemd. Aliassen worden opgeslagen in het bestand /etc/ifaliases.cf.
In versie 4.3 wordt bij de eerste opstart van de virtuele machine de interfacekaart automatisch aangemaakt. Als u het aantal netwerkinterfaces in de virtuele machine verandert, maakt u alstublieft de interfacekaart opnieuw aan:

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

Schema 1: GRE-over-IPsec

Ik zet twee virtuele gateways op en verbind ze zoals weergegeven in de afbeelding:

Stap 1. Ik configureer IP-adressen en routes

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

Ik controleer de IP-connectiviteit:

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 statistieken ---
4 pakketten verzonden, 4 ontvangen, 0% pakketverlies, tijd 3005ms
rtt min/avg/max/mdev = 0.273/0.540/0.687/0.164 ms

Stap 2. Ik configureer GRE

Ik neem een voorbeeld van de GRE-configuratie uit de officiële scenario's. Ik maak een bestand gre1 aan 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 activeer de interface in het systeem:

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

Ik controleer:

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 de C-Terra Gateway is er een ingebouwde pakket-sniffer — tcpdump. Ik registreer een dump van het verkeer in een pcap-bestand:

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

Ik start de ping tussen de 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 statistieken ---
4 pakketten verzonden, 4 ontvangen, 0% pakketverlies, tijd 3006ms
rtt min/avg/max/mdev = 0.850/0.915/0.974/0.043 ms

GRE-tunnel is actief en werkt:

Stap 3. We versleutelen GRE met GOST

Ik stel het identificatietype in – op adres. Authenticatie met een vooraf gedefinieerde sleutel (volgens de gebruiksregels moeten digitale certificaten worden gebruikt):

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

Ik stel de IPsec Phase I parameters in:

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

Ik stel de IPsec Phase II parameters in:

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

Ik maak een toegangslist aan voor versleuteling. Doelverkeer — GRE:

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

Ik maak een cryptomap aan en koppel 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 spiegelbeeldig, met de volgende verschillen:

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

Ik controleer:

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-statistieken ---
4 pakketten verzonden, 4 ontvangen, 0% pakketverlies, tijd 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 sessies: 0 geïnitieerd, 0 gereageerd

ISAKMP verbindingen:
Num Conn-id (Lokaal Addr,Port)-(Afstands Addr,Port) Status Verzonden Ontvangen
1 1 (172.16.1.253,500)-(172.16.1.254,500) actief 1086 1014

IPsec verbindingen:
Num Conn-id (Lokaal Addr,Port)-(Afstands Addr,Port) Protocol Actie Type Verzonden Ontvangen
1 1 (172.16.1.253,*)-(172.16.1.254,*) 47 ESP tunn 480 480

In de dump van het verkeer zijn er geen GRE-pakketten:

Conclusie: de GRE-over-IPsec configuratie werkt correct.

Schema 1.5: IPsec-over-GRE

Ik ben niet van plan om IPsec-over-GRE in het netwerk te gebruiken. Ik verzamel het omdat ik het leuk vind.

Om het GRE-over-IPsec schema om te draaien, moet je:

De toegangslist voor versleuteling aanpassen – doelverkeer van LAN1 naar LAN2 en omgekeerd;
Routing via GRE configureren;
Een cryptomap aan de GRE-interface hangen.

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

Ik voeg de GRE-interface toe aan de Cisco-achtige console. Hiervoor 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="*")

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

Ik bereken de hash van het bestand opnieuw:

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

SUCCESS:  De operatie was succesvol.

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

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

Ik pas de toegangslist voor versleuteling aan:

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 routing 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 cryptokaart van Fa0/0 en koppel deze aan de GRE-interface:

VG1(config)#
interface Tunnel0
crypto map CMAP

Voor VG2 hetzelfde.

Ik controleer:

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

--- 192.168.2.254 pingstatistieken ---
4 pakketten verzonden, 4 ontvangen, 0% pakketverlies, tijd 3006ms
rtt min/avg/max/mdev = 1.064/124.048/492.972/212.998 ms

ISAKMP/IPsec statistieken:

root@VG1:~# sa_mgr show
ISAKMP-sessies: 0 geïnitieerd, 0 gereageerd

ISAKMP-verbindingen:
Num Conn-id (Lok. Addr, Poort)-(Remote Addr, Poort) Status Verzonden Ontvangen
1 2 (172.16.1.253,500)-(172.16.1.254,500) actief 1094 1022

IPsec-verbindingen:
Num Conn-id (Lok. Addr, Poort)-(Remote Addr, Poort) Protocol Actie Type Verzonden Ontvangen
1 2 (192.168.1.0-192.168.1.255,*)-(192.168.2.0-192.168.2.255,*) * ESP tunn 352 352

In de datastroomdump zijn er ESP-pakketten, ingekapseld in GRE:

Resultaat: IPsec-over-GRE werkt correct.