ProHoster > Blogg > administration > 1.5-scheman på inhemsk IPsec VPN. Testar demos

1.5-scheman på inhemsk IPsec VPN. Testar demos

1.5-scheman på inhemsk IPsec VPN. Testar demos

Situation

Jag fick en demoversion av S-Terra VPN-produkter version 4.3 i tre månader. Jag vill ta reda på om mitt ingenjörsliv kommer att bli enklare efter att jag bytt till den nya versionen.

Det är inte svårt idag, ett paket 3-i-1 snabbkaffe borde räcka. Jag ska berätta hur man får tag på demoversioner. Jag ska försöka sätta ihop GRE-över-IPsec och IPsec-över-GRE-scheman.

Hur man får en demoversion

1.5-scheman på inhemsk IPsec VPN. Testar demos

Av figuren framgår att för att få demoversionen behöver du:

  • Skriv ett brev till presale@s-terra.ru från din företagsadress;
  • Vänligen ange din organisations skatteidentifikationsnummer i brevet;
  • Lista produkterna och deras kvantiteter.

Demoversionerna är giltiga i tre månader. Leverantören begränsar inte sin funktionalitet.

Jag vecklar ut bilden

Security Gateway-demon är en avbildning av en virtuell maskin. Jag använder VMWare Workstation. En komplett lista över hypervisorer och virtualiseringsmiljöer som stöds finns på leverantörens webbplats.

Innan du påbörjar några aktiva steg, observera att standardavbildningen av den virtuella maskinen inte har några nätverksgränssnitt:

1.5-scheman på inhemsk IPsec VPN. Testar demos

Logiken är tydlig, användaren bör lägga till så många gränssnitt som hen behöver. Jag lägger till fyra på en gång:

1.5-scheman på inhemsk IPsec VPN. Testar demos

Nu startar jag den virtuella maskinen. Omedelbart efter lanseringen kräver gatewayen en inloggning och ett lösenord.

Det finns flera konsoler i S-Terra Gateway med olika konton. Jag kommer att räkna deras antal i en separat artikel. Under tiden:
Login as: administrator
Password: s-terra

Initierar gatewayen. Initialisering är en sekvens av åtgärder: ange en licens, ställa in en biologisk slumptalsgenerator (tangentbordstränare - min rekord är 27 sekunder) och skapa en nätverksgränssnittskarta.

Nätverksgränssnittskarta. Det blev lättare

Version 4.2 hälsade den aktiva användaren med följande meddelanden:

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

En aktiv användare (enligt en anonym ingenjör) är en användare som kan konfigurera vad som helst snabbt och utan dokumentation.

Något gick fel redan innan jag försökte konfigurera IP-adressen på gränssnittet. Det handlar om nätverksgränssnittskartan. Det var nödvändigt att genomföra:

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

Som ett resultat skapas en nätverksgränssnittskarta, som innehåller en mappning av namnen på fysiska gränssnitt (0000:02:03.0) och deras logiska beteckningar i operativsystemet (eth0) och Cisco-liknande konsol (FastEthernet0/0):

#Unique ID iface type OS name Cisco-like name

0000:02:03.0 phye eth0 FastEthernet0/0

Logiska beteckningar för gränssnitt kallas alias. Alias ​​lagras i filen /etc/ifaliases.cf.
I version 4.3 skapas en gränssnittskarta automatiskt första gången du startar en virtuell maskin. Om du ändrar antalet nätverksgränssnitt i den virtuella maskinen, skapa gränssnittskartan igen:

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

Schema 1: GRE-över-IPsec

Jag driftsätter två virtuella gateways och växlar mellan dem enligt bilden:

1.5-scheman på inhemsk IPsec VPN. Testar demos

Steg 1. Konfigurera IP-adresser och rutter

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

Kontrollerar IP-anslutning:

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

Steg 2: Konfigurera GRE

Jag tar exemplet med GRE-inställningar från de officiella skripten. Jag skapar en fil gre1 i katalogen /etc/network/interfaces.d med innehållet.

För 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

För 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

Jag höjer gränssnittet i systemet:

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

Kontroll:

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

S-Terra Gateway har en inbyggd paketavslöjare - tcpdump. Jag skriver trafikdumpen till en pcap-fil:

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

Jag kör ping mellan GRE-gränssnitt:

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-tunneln är aktiv och fungerar:

1.5-scheman på inhemsk IPsec VPN. Testar demos

Steg 3. Kryptera med GOST GRE

Jag anger identifieringstypen – efter adress. Autentisering med fördefinierad nyckel (enligt användarvillkoren måste digitala certifikat användas):

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

Jag ställer in IPsec fas I-parametrarna:

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

Jag ställde in IPsec fas II-parametrarna:

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

Jag skapar en åtkomstlista för kryptering. Riktad trafik - GRE:

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

Jag skapar en kryptokarta och binder den till WAN-gränssnittet:

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

För VG2 är konfigurationen speglad, skillnader:

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

Kontroll:

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

Det finns inga GRE-paket i trafikdumpen:

1.5-scheman på inhemsk IPsec VPN. Testar demos

Slutsats: GRE-över-IPsec-schemat fungerar korrekt.

Schema 1.5: IPsec-över-GRE

Jag planerar inte att använda IPsec-över-GRE i nätverket. Jag samlar för att jag vill.

1.5-scheman på inhemsk IPsec VPN. Testar demos

För att vända GRE-över-IPsec-schemat måste du:

  • Åtgärda åtkomstlista för kryptering - måltrafik från LAN1 till LAN2 och vice versa;
  • Konfigurera routing via GRE;
  • Koppla en kryptokarta till GRE-gränssnittet.

Som standard finns det inget GRE-gränssnitt i den Cisco-liknande gateway-konsolen. Den finns bara i operativsystemet.

Lägga till ett GRE-gränssnitt till en Cisco-liknande konsol. För att göra detta redigerar jag 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="*")

där gre1 är gränssnittsbeteckningen i operativsystemet och Tunnel0 är gränssnittsbeteckningen i den Cisco-liknande konsolen.

Omberäkning av filens hash:

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

SUCCESS:  Operation was successful.

Nu visas Tunnel0-gränssnittet i den Cisco-liknande konsolen:

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

Korrigera åtkomstlistan för 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

Konfigurera 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

Jag tar bort kryptokortet från Fa0/0 och binder det till GRE-gränssnittet:

VG1(config)#
interface Tunnel0
crypto map CMAP

För VG2 är det liknande.

Kontroll:

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-trafikdumpen, paket inkapslade i GRE:

1.5-scheman på inhemsk IPsec VPN. Testar demos

Slutsats: IPsec-över-GRE fungerar korrekt.

Resultat av

En kopp kaffe räckte. Jag har sammanställt instruktioner för hur man får tag på demoversionen. Konfigurerade GRE-over-IPsec och driftsatte det åt andra hållet.

Nätverksgränssnittskartan i version 4.3 är automatisk! Jag testar vidare.

Anonym ingenjör
t.me/anonym_ingenjör

Källa: will.com

Köp pålitlig hosting för webbplatser med DDoS-skydd, VPS VDS-servrar 🔥 Köp pålitlig webbhotell med DDoS-skydd, VPS VDS-servrar | ProHoster