Sytuacja
Otrzymałem wersję demonstracyjną produktów C-Terra VPN w wersji 4.3 na trzy miesiące. Chcę się dowiedzieć, czy moje życie inżynierskie stanie się łatwiejsze po przejściu na nową wersję.
Dziś nie jest trudno, jedna torebka kawy rozpuszczalnej 3w1 powinna wystarczyć. Powiem ci, jak zdobyć dema. Spróbuję zbudować schematy GRE-over-IPsec i IPsec-over-GRE.
Jak uzyskać wersję demonstracyjną
Z rysunku wynika, że aby otrzymać demo należy:
- Napisz list do [email chroniony] z adresu firmowego;
- W liście podaj NIP swojej organizacji;
- Wypisz produkty i ich ilości.
Demo jest ważne przez trzy miesiące. Sprzedawca nie ogranicza ich funkcjonalności.
Rozszerzanie obrazu
Wersja demonstracyjna Security Gateway to obraz maszyny wirtualnej. Używam stacji roboczej VMWare. Pełna lista obsługiwanych hiperwizorów i środowisk wirtualizacji jest dostępna na stronie producenta.
Zanim zaczniesz, pamiętaj, że w domyślnym obrazie maszyny wirtualnej nie ma żadnych interfejsów sieciowych:
Logika jest jasna, użytkownik musi dodać tyle interfejsów, ile potrzebuje. Od razu dodam cztery:
Teraz uruchamiam maszynę wirtualną. Natychmiast po uruchomieniu bramka wymaga podania nazwy użytkownika i hasła.
W S-Terra Gateway jest kilka konsol z różnymi kontami. Ich liczbę policzę w osobnym artykule. Na razie:
Login as: administrator
Password: s-terra
Inicjuję bramę. Inicjalizacja to sekwencja czynności: wpisanie licencji, ustawienie biologicznego generatora liczb losowych (symulator klawiatury - mój rekord to 27 sekund) oraz utworzenie mapy interfejsu sieciowego.
Mapa interfejsów sieciowych. Stało się to łatwiejsze
Wersja 4.2 powitała aktywnego użytkownika komunikatami:
Starting IPsec daemon….. failed
ERROR: Could not establish connection with daemon
Aktywny użytkownik (według anonimowego inżyniera) to użytkownik, który potrafi szybko i bez dokumentacji skonfigurować wszystko.
Coś poszło nie tak przed próbą ustawienia adresu IP w interfejsie. Chodzi o mapę interfejsu sieciowego. Trzeba było zrobić:
/bin/netifcfg enum > /home/map
/bin/netifcfg map /home/map
service networking restart
W efekcie powstaje mapa interfejsu sieciowego zawierająca odwzorowanie nazw fizycznych interfejsów (0000:02:03.0) oraz ich logicznych oznaczeń w systemie operacyjnym (eth0) i konsoli typu 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 maszyny wirtualnej automatycznie tworzona jest mapa interfejsu. Jeśli zmienisz liczbę interfejsów sieciowych w maszynie wirtualnej, utwórz ponownie mapę interfejsu:
/bin/netifcfg enum > /home/map
/bin/netifcfg map /home/map
systemctl restart networking
Schemat 1: GRE-over-IPsec
Wdrażam dwie bramy wirtualne, przełączam tak jak na rysunku:
Krok 1. Skonfiguruj 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.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.253Sprawdzanie łączności IP:
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 msKrok 2: Skonfiguruj GRE
Biorę przykład konfigurowania GRE z oficjalnych skryptów. Tworzę plik gre1 w katalogu /etc/network/interfaces.d z zawartoś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 gre1Dla 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 gre1Podnoszę interfejs w systemie:
root@VG1:~# ifup gre1
root@VG2:~# ifup gre1Kontrola:
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 posiada wbudowany sniffer pakietów - tcpdump. Napiszę zrzut ruchu do pliku pcap:
root@VG2:~# tcpdump -i eth0 -w /home/dump.pcapRozpoczynam pingowanie między interfejsami GRE:
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 msTunel GRE już działa:
Krok 3. Szyfruj za pomocą GOST GRE
Ustawiłem rodzaj identyfikacji - po adresie. Uwierzytelnianie predefiniowanym kluczem (zgodnie z Regulaminem należy stosować certyfikaty cyfrowe):
VG1(config)#
crypto isakmp identity address
crypto isakmp key KEY address 172.16.1.254Ustawiam parametry IPsec Faza I:
VG1(config)#
crypto isakmp policy 1
encr gost
hash gost3411-256-tc26
auth pre-share
group vko2Ustawiam parametry IPsec Phase II:
VG1(config)#
crypto ipsec transform-set TSET esp-gost28147-4m-imit
mode tunnelTworzę listę dostępu do szyfrowania. Ruch docelowy – GRE:
VG1(config)#
ip access-list extended LIST
permit gre host 172.16.1.253 host 172.16.1.254Tworzę mapę kryptograficzną i wiążę ją z interfejsem 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 CMAPW przypadku VG2 konfiguracja jest lustrzana, różnice są następujące:
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.254Kontrola:
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
Statystyki ISAKMP/IPsec:
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 480W zrzucie ruchu GRE nie ma żadnych pakietów:
Wniosek: schemat GRE-over-IPsec działa poprawnie.
Rysunek 1.5: IPsec przez GRE
Nie planuję używać IPsec-over-GRE w sieci. Zbieram, bo chcę.
Aby wdrożyć schemat GRE-over-IPsec na odwrót:
- Napraw listę dostępu do szyfrowania - ruch docelowy z LAN1 do LAN2 i odwrotnie;
- Skonfiguruj routing przez GRE;
- Zawieś kryptomapę na interfejsie GRE.
Domyślnie w konsoli bramy typu Cisco nie ma interfejsu GRE. Istnieje tylko w systemie operacyjnym.
Dodaję interfejs GRE do konsoli podobnej do Cisco. W tym celu edytuję plik /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="*")gdzie gre1 to oznaczenie interfejsu w systemie operacyjnym, Tunnel0 to oznaczenie interfejsu w konsoli podobnej do Cisco.
Ponownie obliczam skrót pliku:
root@VG1:~# integr_mgr calc -f /etc/ifaliases.cf
SUCCESS: Operation was successful.Teraz interfejs Tunnel0 pojawił się w konsoli podobnej do Cisco:
VG1# show run
interface Tunnel0
ip address 1.1.1.1 255.255.255.252
mtu 1400Poprawianie listy 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.255Konfiguruję routing 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.2Usuwam kryptomapę z Fa0/0 i podpinam do interfejsu GRE:
VG1(config)#
interface Tunnel0
crypto map CMAPW przypadku VG2 jest podobnie.
Kontrola:
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 msStatystyki ISAKMP/IPsec:
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 352W zrzucie ruchu ESP pakiety zamknięte w GRE:
Wniosek: IPsec-over-GRE działa poprawnie.
Wyniki
Wystarczyła jedna filiżanka kawy. Naszkicowałem instrukcje uzyskania wersji demonstracyjnej. Skonfigurowano GRE-over-IPsec i wdrożono odwrotnie.
Mapa interfejsów sieciowych w wersji 4.3 jest automatyczna! Testuję dalej.
Anonimowy inżynier
t.me/anonymous_inżynier
Źródło: www.habr.com