situasjon
Jeg mottok en demoversjon av C-Terra VPN-produkter versjon 4.3 i tre måneder. Jeg vil finne ut om ingeniørlivet mitt vil bli enklere etter å ha byttet til den nye versjonen.
I dag er ikke vanskelig, én pose pulverkaffe 3 i 1 burde være nok. Jeg skal fortelle deg hvordan du får demoer. Jeg skal prøve å bygge GRE-over-IPsec og IPsec-over-GRE-skjemaene.
Hvordan få en demo
Det følger av figuren at for å få en demo må du:
- Skriv et brev til [e-postbeskyttet] fra en bedriftsadresse;
- I brevet, angi TIN-nummeret til organisasjonen din;
- List opp produktene og deres mengde.
Demoene er gyldige i tre måneder. Leverandøren begrenser ikke funksjonaliteten deres.
Utvider bildet
Security Gateway-demoen er et virtuell maskinbilde. Jeg bruker VMWare Workstation. En komplett liste over støttede hypervisorer og virtualiseringsmiljøer er tilgjengelig på leverandørens nettsted.
Før du begynner, vær oppmerksom på at det ikke er noen nettverksgrensesnitt i standardbildet for virtuell maskin:
Logikken er klar, brukeren må legge til så mange grensesnitt han trenger. Jeg legger til fire samtidig:
Nå starter jeg den virtuelle maskinen. Umiddelbart etter lansering krever gatewayen et brukernavn og passord.
Det er flere konsoller i S-Terra Gateway med forskjellige kontoer. Jeg vil telle antallet deres i en egen artikkel. For nå:
Login as: administrator
Password: s-terra
Jeg initialiserer gatewayen. Initialisering er en sekvens av handlinger: legge inn en lisens, sette opp en biologisk tilfeldig tallgenerator (tastatursimulator - rekorden min er 27 sekunder) og lage et nettverksgrensesnittkart.
Kart over nettverksgrensesnitt. Det ble lettere
Versjon 4.2 hilste den aktive brukeren med meldinger:
Starting IPsec daemon….. failed
ERROR: Could not establish connection with daemon
En aktiv bruker (ifølge en anonym ingeniør) er en bruker som kan sette opp hva som helst raskt og uten dokumentasjon.
Noe gikk galt før du prøvde å sette opp en IP-adresse på grensesnittet. Alt handler om nettverkskartet. Det var nødvendig å gjøre:
/bin/netifcfg enum > /home/map
/bin/netifcfg map /home/map
service networking restart
Som et resultat opprettes et nettverksgrensesnittkart som inneholder kartleggingen av fysiske grensesnittnavn (0000:02:03.0) og deres logiske betegnelser i operativsystemet (eth0) og Cisco-lignende konsoll (FastEthernet0/0):
#Unique ID iface type OS name Cisco-like name
0000:02:03.0 phye eth0 FastEthernet0/0
De logiske betegnelsene til grensesnitt kalles aliaser. Aliaser er lagret i filen /etc/ifaliases.cf.
I versjon 4.3, når den virtuelle maskinen først startes, opprettes et grensesnittkart automatisk. Hvis du endrer antall nettverksgrensesnitt i den virtuelle maskinen, må du gjenskape grensesnittkartet:
/bin/netifcfg enum > /home/map
/bin/netifcfg map /home/map
systemctl restart networking
Skjema 1: GRE-over-IPsec
Jeg distribuerer to virtuelle gatewayer, jeg bytter som vist i figuren:
Trinn 1. Sett opp 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.254VG2(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.253Sjekker IP-tilkobling:
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 msTrinn 2: Sett opp GRE
Jeg tar et eksempel på å sette opp GRE fra offisielle skript. Jeg lager en gre1-fil i katalogen /etc/network/interfaces.d med innholdet.
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 gre1For 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 gre1Jeg hever grensesnittet i systemet:
root@VG1:~# ifup gre1
root@VG2:~# ifup gre1Sjekker:
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 1C-Terra Gateway har en innebygd pakkesniffer – tcpdump. Jeg vil skrive en trafikkdump til en pcap-fil:
root@VG2:~# tcpdump -i eth0 -w /home/dump.pcapJeg begynner å pinge mellom GRE-grensesnitt:
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 msGRE-tunnelen er i gang:
Trinn 3. Krypter med GOST GRE
Jeg angir type identifikasjon - etter adresse. Autentisering med en forhåndsdefinert nøkkel (i henhold til bruksvilkårene må digitale sertifikater brukes):
VG1(config)#
crypto isakmp identity address
crypto isakmp key KEY address 172.16.1.254Jeg stiller inn IPsec Phase I-parametrene:
VG1(config)#
crypto isakmp policy 1
encr gost
hash gost3411-256-tc26
auth pre-share
group vko2Jeg stiller inn IPsec Phase II-parametrene:
VG1(config)#
crypto ipsec transform-set TSET esp-gost28147-4m-imit
mode tunnelJeg lager en tilgangsliste for kryptering. Målrettet trafikk – GRE:
VG1(config)#
ip access-list extended LIST
permit gre host 172.16.1.253 host 172.16.1.254Jeg lager et kryptokart og binder det til WAN-grensesnittet:
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 CMAPFor VG2 er konfigurasjonen speilvendt, forskjellene 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.254Sjekker:
root@VG2:~# tcpdump -i eth0 -w /home/dump2.pcaproot@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-statistikk:
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 480Det er ingen pakker i GRE-trafikkdumpen:
Konklusjon: GRE-over-IPsec-ordningen fungerer riktig.
Figur 1.5: IPsec-over-GRE
Jeg har ikke tenkt å bruke IPsec-over-GRE på nettverket. Jeg samler fordi jeg vil.
For å distribuere GRE-over-IPsec-ordningen omvendt:
- Fiks krypteringstilgangsliste - målrettet trafikk fra LAN1 til LAN2 og omvendt;
- Konfigurer ruting gjennom GRE;
- Heng et kryptokart på GRE-grensesnittet.
Som standard er det ikke noe GRE-grensesnitt i den Cisco-lignende gateway-konsollen. Det finnes bare i operativsystemet.
Jeg legger til GRE-grensesnittet til den Cisco-lignende konsollen. For å gjø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="*")der gre1 er grensesnittbetegnelsen i operativsystemet, Tunnel0 er grensesnittbetegnelsen i den Cisco-lignende konsollen.
Jeg regner om hashen til filen:
root@VG1:~# integr_mgr calc -f /etc/ifaliases.cf
SUCCESS: Operation was successful.Nå har Tunnel0-grensesnittet dukket opp i den Cisco-lignende konsollen:
VG1# show run
interface Tunnel0
ip address 1.1.1.1 255.255.255.252
mtu 1400Korrigering av tilgangslisten for 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.255Jeg konfigurerer ruting gjennom 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.2Jeg fjerner kryptokartet fra Fa0 / 0 og binder det til GRE-grensesnittet:
VG1(config)#
interface Tunnel0
crypto map CMAPFor VG2 er det likt.
Sjekker:
root@VG2:~# tcpdump -i eth0 -w /home/dump3.pcaproot@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 msISAKMP/IPsec-statistikk:
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 352I ESP-trafikkdumpen er pakkene innkapslet i GRE:
Konklusjon: IPsec-over-GRE fungerer korrekt.
Resultater av
En kopp kaffe var nok. Jeg skisserte instruksjoner for å få tak i en demoversjon. Konfigurert GRE-over-IPsec og distribuert omvendt.
Kartet over nettverksgrensesnitt i versjon 4.3 er automatisk! Jeg tester videre.
Anonym ingeniør
t.me/anonym_ingeniør
Kilde: www.habr.com