1.5-skemoj pri hejma IPsec VPN. Testado de demonstraĵoj

1.5-skemoj pri hejma IPsec VPN. Testado de demonstraĵoj

La situacio

Mi ricevis demo-version de C-Terra VPN-produktoj versio 4.3 dum tri monatoj. Mi volas ekscii, ĉu mia inĝenieristiko fariĝos pli facila post ŝanĝado al la nova versio.

Hodiaŭ ne estas malfacila, unu sako da tuja kafo 3 en 1 devus sufiĉi. Mi diros al vi kiel akiri demonstraĵojn. Mi provos konstrui la skemojn GRE-over-IPsec kaj IPsec-over-GRE.

Kiel akiri demo

1.5-skemoj pri hejma IPsec VPN. Testado de demonstraĵoj

El la figuro sekvas, ke por akiri demonstraĵon vi devas:

  • Skribu leteron al [retpoŝte protektita] de kompania adreso;
  • En la letero, indiku la TIN de via organizo;
  • Listigu la produktojn kaj iliajn kvantojn.

Demonstraĵoj validas por tri monatoj. La vendisto ne limigas ilian funkciecon.

Pligrandigante la bildon

La Security Gateway-demo estas virtuala maŝina bildo. Mi uzas VMWare Workstation. Kompleta listo de subtenataj hiperviziiloj kaj virtualigmedioj estas havebla en la retejo de la vendisto.

Antaŭ ol komenci, bonvolu noti, ke ne estas retaj interfacoj en la defaŭlta virtuala maŝino bildo:

1.5-skemoj pri hejma IPsec VPN. Testado de demonstraĵoj

La logiko estas klara, la uzanto devas aldoni tiom da interfacoj kiom li bezonas. Mi aldonos kvar samtempe:

1.5-skemoj pri hejma IPsec VPN. Testado de demonstraĵoj

Nun mi ekfunkciigas la virtualan maŝinon. Tuj post lanĉo, la enirejo postulas uzantnomon kaj pasvorton.

Estas pluraj konzoloj en S-Terra Gateway kun malsamaj kontoj. Mi kalkulos ilian numeron en aparta artikolo. Nuntempe:
Login as: administrator
Password: s-terra

Mi pravalorigas la enirejon. Iniciatigo estas sinsekvo de agoj: enigo de licenco, starigo de biologia hazarda nombro-generatoro (klavarsimulilo - mia rekordo estas 27 sekundoj) kaj kreado de retinterfaco-mapo.

Mapo de retaj interfacoj. Ĝi fariĝis pli facila

Versio 4.2 salutis la aktivan uzanton per mesaĝoj:

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

Aktiva uzanto (laŭ anonima inĝeniero) estas uzanto, kiu povas agordi ion ajn rapide kaj sen dokumentado.

Io misfunkciis antaŭ ol provi agordi IP-adreson en la interfaco. Ĉio temas pri la retinterfaco mapo. Necesis fari:

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

Kiel rezulto, retinterfaca mapo estas kreita kiu enhavas la mapadon de fizikaj interfacnomoj (0000:02:03.0) kaj iliajn logikaj nomoj en la operaciumo (eth0) kaj Cisco-simila konzolo (FastEthernet0/0):

#Unique ID iface type OS name Cisco-like name

0000:02:03.0 phye eth0 FastEthernet0/0

La logikaj nomoj de interfacoj estas nomitaj kaŝnomoj. Kaŝnomoj estas konservitaj en la dosiero /etc/ifaliases.cf.
En versio 4.3, kiam la virtuala maŝino unue estas komencita, interfacmapo estas kreita aŭtomate. Se vi ŝanĝas la nombron da retaj interfacoj en la virtuala maŝino, bonvolu rekrei la interfacmapon:

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

Skemo 1: GRE-super-IPsec

Mi deplojas du virtualajn enirejojn, mi ŝanĝas kiel montrite en la figuro:

1.5-skemoj pri hejma IPsec VPN. Testado de demonstraĵoj

Paŝo 1. Agordu IP-adresojn kaj itinerojn

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

Kontrolante IP-konektecon:

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

Paŝo 2: Agordu GRE

Mi prenas ekzemplon pri agordo de GRE el oficialaj skriptoj. Mi kreas gre1-dosieron en la dosierujo /etc/network/interfaces.d kun la enhavo.

Por 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

Por 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

Mi levas la interfacon en la sistemo:

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

Kontrolado:

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 havas enkonstruitan pakaĵetoflaron - tcpdump. Mi skribos trafikan rubejon al pcap-dosiero:

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

Mi komencas pingi inter GRE-interfacoj:

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-tunelo funkcias:

1.5-skemoj pri hejma IPsec VPN. Testado de demonstraĵoj

Paŝo 3. Ĉifri per GOST GRE

Mi fiksas la tipon de identigo - per adreso. Aŭtentigo per antaŭdifinita ŝlosilo (laŭ la Uzokondiĉoj, ciferecaj atestiloj devas esti uzataj):

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

Mi starigis la parametrojn de IPsec Phase I:

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

Mi starigis la parametrojn IPsec Phase II:

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

Mi kreas alirliston por ĉifrado. Celita trafiko - GRE:

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

Mi kreas kriptan mapon kaj ligas ĝin al la WAN-interfaco:

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

Por VG2, la agordo estas spegulita, la diferencoj estas:

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

Kontrolado:

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

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

Ne estas pakaĵoj en la GRE-trafika rubejo:

1.5-skemoj pri hejma IPsec VPN. Testado de demonstraĵoj

Konkludo: la skemo GRE-over-IPsec funkcias ĝuste.

Figuro 1.5: IPsec-over-GRE

Mi ne planas uzi IPsec-over-GRE en la reto. Mi kolektas ĉar mi volas.

1.5-skemoj pri hejma IPsec VPN. Testado de demonstraĵoj

Por deploji la GRE-super-IPsec-skemon inverse:

  • Ripari ĉifradan alirliston - celita trafiko de LAN1 al LAN2 kaj inverse;
  • Agordi vojigon per GRE;
  • Pendu kriptomapon sur la GRE-interfaco.

Defaŭlte, ne ekzistas GRE-interfaco en la Cisco-simila enirejkonzolo. Ĝi ekzistas nur en la operaciumo.

Mi aldonas la GRE-interfacon al la Cisco-simila konzolo. Por fari tion, mi redaktas la dosieron /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="*")

kie gre1 estas la interfacnomo en la operaciumo, Tunnel0 estas la interfacnomo en la Cisco-simila konzolo.

Mi rekalkulas la haŝon de la dosiero:

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

SUCCESS:  Operation was successful.

Nun la interfaco Tunnel0 aperis en la Cisco-simila konzolo:

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

Korektante la alirliston por ĉifrado:

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

Mi agordas vojigon per 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

Mi forigas la kriptomapon de Fa0 / 0 kaj ligas ĝin al la GRE-interfaco:

VG1(config)#
interface Tunnel0
crypto map CMAP

Por VG2 ĝi estas simila.

Kontrolado:

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

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

En la ESP-trafikdeponejo, la pakaĵetoj enkapsuligitaj en GRE:

1.5-skemoj pri hejma IPsec VPN. Testado de demonstraĵoj

Konkludo: IPsec-over-GRE funkcias ĝuste.

Rezultoj

Sufiĉis unu taso da kafo. Mi skizis instrukciojn por akiri demonstran version. Agordita GRE-over-IPsec kaj deplojita inverse.

La mapo de retaj interfacoj en versio 4.3 estas aŭtomata! Mi testas plu.

Anonima inĝeniero
t.me/anonymous_engineer


fonto: www.habr.com

Aldoni komenton