🥇1.5 schematy na krajowym IPsec VPN. Testuję wersje próbne

Sytuacja

Otrzymałem wersję demonstracyjną produktów S-Terra VPN w wersji 4.3 na trzy miesiące. Chcę zrozumieć, czy moje inżynieryjne życie stanie się łatwiejsze po przejściu na nową wersję.

Dziś nie jest trudno, jedna saszetka kawy rozpuszczalnej 3 w 1 powinna wystarczyć. Opowiem, jak uzyskać wersje demonstracyjne. Spróbuję zebrać schematy GRE-over-IPsec i IPsec-over-GRE.

Jak uzyskać wersję demonstracyjną

Z rysunku wynika, że aby uzyskać wersję demonstracyjną, należy:

Napisać wiadomość na presale@s-terra.ru z adresu korporacyjnego;
W wiadomości podać NIP swojej organizacji;
Wymienić produkty i ich ilość.

Wersje demonstracyjne są ważne przez trzy miesiące. Producent nie ogranicza ich funkcjonalności.

Wdrążam obraz

Wersja demonstracyjna bramki bezpieczeństwa to obraz maszyny wirtualnej. Używam VMWare Workstation. Pełna lista wspieranych hypervisorów i środowisk wirtualizacji jest dostępna na stronie producenta.

Przed rozpoczęciem aktywnych działań zwróć uwagę, że w obrazie maszyny wirtualnej domyślnie brakuje interfejsów sieciowych:

Logika jest jasna, użytkownik musi dodać tyle interfejsów, ile potrzebuje. Dodam od razu cztery:

Teraz uruchamiam maszynę wirtualną. Zaraz po uruchomieniu bramka wymaga loginu i hasła.

W S-Terra Brama jest kilka konsol z różnymi kontami. Policzę ich liczbę w osobnym artykule. A na razie:
Zaloguj się jako: administrator Hasło: s-terra

Inicjuję bramkę. Inicjacja to sekwencja działań: wprowadzenie licencji, konfiguracja biologicznego generatora liczb losowych (trening na klawiaturze – mój rekord to 27 sekund) oraz stworzenie mapy interfejsów sieciowych.

Mapa interfejsów sieciowych. Stało się łatwiej

Wersja 4.2 witała aktywnego użytkownika wiadomościami:

Rozpoczynanie demona IPsec..... nie powiodło się BŁĄD: Nie można nawiązać połączenia z demonem

Aktywny użytkownik (według anonimowego inżyniera) – użytkownik, który potrafi skonfigurować cokolwiek szybko i bez dokumentacji.

Coś poszło nie tak, jeszcze przed próbą skonfigurowania adresu IP na interfejsie. Wszystko tkwi w mapie interfejsów sieciowych. Należało wykonać:

/bin/netifcfg enum > /home/map /bin/netifcfg map /home/map usługa ponownego uruchomienia sieci

W rezultacie tworzona jest mapa interfejsów sieciowych, która zawiera mapowanie nazw fizycznych interfejsów (0000:02:03.0) i ich logicznych oznaczeń w systemie operacyjnym (eth0) oraz konsoli w stylu Cisco (FastEthernet0/0):

#Unique ID iface type OS name Cisco-like name

0000:02:03.0 phye eth0 FastEthernet0/0

Logiczne oznaczenia interfejsów nazywane są aliasami. Aliasy są przechowywane w pliku /etc/ifaliases.cf.
W wersji 4.3 przy pierwszym uruchomieniu wirtualnej maszyny mapa interfejsów jest tworzona automatycznie. Jeśli zmienisz liczbę interfejsów sieciowych w wirtualnej maszynie, bądź tak miły i stwórz mapę interfejsów na nowo:

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

Schemat 1: GRE-over-IPsec

Rozkładam dwie wirtualne bramy, łączę je tak, jak pokazano na obrazku:

Krok 1. Konfiguruję adresy IP i trasy

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

Sprawdzam spójność IP:

root@VG1:~# ping 172.16.1.254 -c 4
PING 172.16.1.254 (172.16.1.254) 56(84) bajtów danych.
64 bajty z 172.16.1.254: icmp_seq=1 ttl=64 czas=0.545 ms
64 bajty z 172.16.1.254: icmp_seq=2 ttl=64 czas=0.657 ms
64 bajty z 172.16.1.254: icmp_seq=3 ttl=64 czas=0.687 ms
64 bajty z 172.16.1.254: icmp_seq=4 ttl=64 czas=0.273 ms

--- statystyki ping dla 172.16.1.254 ---
4 pakiety wysłane, 4 odebrane, 0% utraty pakietów, czas 3005ms
rtt min/avg/max/mdev = 0.273/0.540/0.687/0.164 ms

Krok 2. Konfiguruję GRE

Przykład konfiguracji GRE biorę z oficjalnych scenariuszy. Tworzę plik gre1 w katalogu /etc/network/interfaces.d z treścią.

Dla 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

Dla 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

Uruchamiam interfejs w systemie:

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

Sprawdzam:

root@VG1:~# ip address show
8: gre1@NONE:  mtu 1400 qdisc noqueue stan UNKNOWN grupa domyślna qlen 1
    link/gre 172.16.1.253 peer 172.16.1.254
    inet 1.1.1.1/30 brd 1.1.1.3 zakres globalny gre1
       valid_lft forever preferred_lft forever

root@VG1:~# ip tunnel show
gre0: gre/ip zdalnie dowolnie lokalnie dowolnie ttl inherit nopmtudisc
gre1: gre/ip zdalnie 172.16.1.254 lokalnie 172.16.1.253 ttl 64 tos inherit key 1

W C-Terra Brama jest wbudowany sniffer pakietów – tcpdump. Zapiszę zrzut ruchu w pliku pcap:

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

Uruchamiam ping między interfejsami GRE:

root@VG1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) bajtów danych.
64 bajty z 1.1.1.2: icmp_seq=1 ttl=64 czas=0.918 ms
64 bajty z 1.1.1.2: icmp_seq=2 ttl=64 czas=0.850 ms
64 bajty z 1.1.1.2: icmp_seq=3 ttl=64 czas=0.918 ms
64 bajty z 1.1.1.2: icmp_seq=4 ttl=64 czas=0.974 ms

--- statystyki ping dla 1.1.1.2 ---
4 pakiety wysłane, 4 odebrane, 0% utraty pakietów, czas 3006ms
rtt min/avg/max/mdev = 0.850/0.915/0.974/0.043 ms

Tunel GRE jest aktywny i działa:

Krok 3. Szyfruję GRE według GOST

Ustawiam typ identyfikacji – po adresie. Uwierzytelnianie na podstawie wcześniej ustalonego klucza (zgodnie z zasadami użytkowania należy używać certyfikatów cyfrowych):

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

Ustalam parametry IPsec Fazy I:

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

Ustalam parametry IPsec Fazy II:

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

Tworzę listę dostępu do szyfrowania. Docelowy ruch — GRE:

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

Tworzę mapę kryptograficzną i przypisuję ją do interfejsu WAN:

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

Dla VG2 konfiguracja jest lustrzana, różnice:

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

Sprawdzam:

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) bajtów danych.
64 bajty z 1.1.1.2: icmp_seq=1 ttl=64 czas=1128 ms
64 bajty z 1.1.1.2: icmp_seq=2 ttl=64 czas=126 ms
64 bajty z 1.1.1.2: icmp_seq=3 ttl=64 czas=1.07 ms
64 bajty z 1.1.1.2: icmp_seq=4 ttl=64 czas=1.12 ms

--- statystyka ping 1.1.1.2 ---
4 pakiety wysłane, 4 odebrane, 0% utraty pakietów, czas 3006ms
rtt min/avg/max/mdev = 1.077/314.271/1128.419/472.826 ms, pipe 2

Statystyki ISAKMP/IPsec:

root@VG1:~# sa_mgr show
Sesje ISAKMP: 0 rozpoczętych, 0 odpowiedzianych

Połączenia ISAKMP:
Num Conn-id (Adres lokalny, Port)-(Adres zdalny, Port) Stan Wysłane Odebrane
1 1 (172.16.1.253,500)-(172.16.1.254,500) aktywne 1086 1014

Połączenia IPsec:
Num Conn-id (Adres lokalny, Port)-(Adres zdalny, Port) Protokół Akcja Typ Wysłane Odebrane
1 1 (172.16.1.253,*)-(172.16.1.254,*) 47 ESP tun 480 480

W zrzucie ruchu nie ma pakietów GRE:

Wynik: schemat GRE-over-IPsec działa poprawnie.

Schemat 1.5: IPsec-over-GRE

Nie planuję używać IPsec-over-GRE w sieci. Tworzę, bo chcę.

Aby wdrożyć schemat GRE-over-IPsec w odwrotnej kolejności, należy:

Poprawić listę dostępu do szyfrowania – docelowy ruch z LAN1 do LAN2 i odwrotnie;
Skonfigurować trasowanie przez GRE;
Przypiąć mapę kryptograficzną do interfejsu GRE.

Domyślnie w konsoli podobnej do Cisco brakuje interfejsu GRE. Istnieje on tylko w systemie operacyjnym.

Dodaję interfejs GRE do konsoli podobnej do Cisco. W tym celu edytuję plik /etc/ifaliases.cf:

interfejs (nazwa="FastEthernet0/0" wzorzec="eth0")
interfejs (nazwa="FastEthernet0/1" wzorzec="eth1")
interfejs (nazwa="FastEthernet0/2" wzorzec="eth2")
interfejs (nazwa="FastEthernet0/3" wzorzec="eth3")
interfejs (nazwa="Tunnel0" wzorzec="gre1")
interfejs (nazwa="default" wzorzec="*")

gdzie gre1 – oznaczenie interfejsu w systemie operacyjnym, Tunnel0 – oznaczenie interfejsu w konsoli podobnej do Cisco.

Przeliczam hash pliku:

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

SUKCES: Operacja zakończona pomyślnie.

Teraz interfejs Tunnel0 pojawił się w konsoli podobnej do Cisco:

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

Koryguję listę dostępu do szyfrowania:

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

Konfiguruję routowanie przez 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

Zdejmuję kartę kryptograficzną z Fa0/0 i przypisuję do interfejsu GRE:

VG1(config)#
interface Tunnel0
crypto map CMAP

Dla VG2 analogicznie.

Sprawdzam:

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) z 192.168.1.253: 56(84) bajtów danych.
64 bajty z 192.168.2.254: icmp_seq=1 ttl=64 czas=492 ms
64 bajty z 192.168.2.254: icmp_seq=2 ttl=64 czas=1.08 ms
64 bajty z 192.168.2.254: icmp_seq=3 ttl=64 czas=1.06 ms
64 bajty z 192.168.2.254: icmp_seq=4 ttl=64 czas=1.07 ms

--- statystyki ping 192.168.2.254 ---
4 pakiety wysłane, 4 odebrane, 0% utraty pakietów, czas 3006ms
rtt min/avg/max/mdev = 1.064/124.048/492.972/212.998 ms

Statystyki ISAKMP/IPsec:

root@VG1:~# sa_mgr show
Sesje ISAKMP: 0 zainicjowane, 0 odpowiedziane

Połączenia ISAKMP:
Num Conn-id (Adres lokalny, Port)-(Adres zdalny, Port) Stan Wysłane Odebrane
1 2 (172.16.1.253,500)-(172.16.1.254,500) aktywne 1094 1022

Połączenia IPsec:
Num Conn-id (Adres lokalny, Port)-(Adres zdalny, Port) Protokół Akcja Typ Wysłane Odebrane
1 2 (192.168.1.0-192.168.1.255,*)-(192.168.2.0-192.168.2.255,*) * ESP tunn 352 352

W zrzucie ruchu pakiety ESP, zakapsułkowane w GRE:

Wynik: IPsec-over-GRE działa poprawnie.