1.5 Schemata für inländisches IPsec-VPN. Demos testen

Situation

Ich habe drei Monate lang eine Demoversion der C-Terra VPN-Produkte Version 4.3 erhalten. Ich möchte herausfinden, ob mein Leben als Ingenieur nach der Umstellung auf die neue Version einfacher wird.

Heute ist es nicht schwer, eine Tüte Instantkaffee 3 in 1 sollte ausreichen. Ich erkläre Ihnen, wie Sie an Demos kommen. Ich werde versuchen, die Schemata GRE-over-IPsec und IPsec-over-GRE zu erstellen.

So erhalten Sie eine Demo

Aus der Abbildung geht hervor, dass Sie zum Erhalt einer Demo Folgendes tun müssen:

• Schreiben Sie einen Brief an [E-Mail geschützt] von einer Firmenadresse;
• Geben Sie im Brief die TIN Ihrer Organisation an;
• Listen Sie die Produkte und ihre Mengen auf.

Demos sind drei Monate gültig. Der Anbieter schränkt deren Funktionalität nicht ein.

Das Bild erweitern

Bei der Security Gateway-Demo handelt es sich um ein Image einer virtuellen Maschine. Ich verwende VMWare Workstation. Eine vollständige Liste der unterstützten Hypervisoren und Virtualisierungsumgebungen finden Sie auf der Website des Anbieters.

Bevor Sie beginnen, beachten Sie bitte, dass das Standard-Image der virtuellen Maschine keine Netzwerkschnittstellen enthält:

Die Logik ist klar: Der Benutzer muss so viele Schnittstellen hinzufügen, wie er benötigt. Ich füge gleich vier hinzu:

Jetzt starte ich die virtuelle Maschine. Unmittelbar nach dem Start benötigt das Gateway einen Benutzernamen und ein Passwort.

Es gibt mehrere Konsolen im S-Terra Gateway mit unterschiedlichen Konten. Ich werde ihre Anzahl in einem separaten Artikel zählen. Zur Zeit:
Login as: administrator
Password: s-terra

Ich initialisiere das Gateway. Bei der Initialisierung handelt es sich um eine Abfolge von Aktionen: Eingeben einer Lizenz, Einrichten eines biologischen Zufallszahlengenerators (Tastatursimulator – mein Rekord liegt bei 27 Sekunden) und Erstellen einer Netzwerkschnittstellenkarte.

Karte der Netzwerkschnittstellen. Es wurde einfacher

Version 4.2 begrüßte den aktiven Benutzer mit Nachrichten:

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

Ein aktiver Benutzer (laut einem anonymen Ingenieur) ist ein Benutzer, der schnell und ohne Dokumentation alles einrichten kann.

Beim Versuch, eine IP-Adresse auf der Schnittstelle einzurichten, ist ein Fehler aufgetreten. Es dreht sich alles um die Netzwerkschnittstellenkarte. Es war notwendig:

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

Als Ergebnis wird eine Netzwerkschnittstellenkarte erstellt, die die Zuordnung der physischen Schnittstellennamen (0000:02:03.0) und ihrer logischen Bezeichnungen im Betriebssystem (eth0) und in der Cisco-ähnlichen Konsole (FastEthernet0/0) enthält:

#Unique ID iface type OS name Cisco-like name

0000:02:03.0 phye eth0 FastEthernet0/0

Die logischen Bezeichnungen von Schnittstellen werden Aliase genannt. Aliase werden in der Datei /etc/ifaliases.cf gespeichert.
In Version 4.3 wird beim ersten Start der virtuellen Maschine automatisch eine Schnittstellenzuordnung erstellt. Wenn Sie die Anzahl der Netzwerkschnittstellen in der virtuellen Maschine ändern, erstellen Sie bitte die Schnittstellenzuordnung neu:

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

Schema 1: GRE-over-IPsec

Ich stelle zwei virtuelle Gateways bereit und wechsle wie in der Abbildung gezeigt:

Schritt 1: IP-Adressen und Routen einrichten

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

Überprüfung der IP-Konnektivität:

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

Schritt 2: GRE einrichten

Ich nehme ein Beispiel für die Einrichtung von GRE aus offiziellen Skripten. Ich erstelle eine gre1-Datei im Verzeichnis /etc/network/interfaces.d mit dem Inhalt.

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

Ich erhebe die Schnittstelle im System:

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

Überprüfung:

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 verfügt über einen integrierten Paket-Sniffer – tcpdump. Ich werde einen Traffic-Dump in eine PCAP-Datei schreiben:

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

Ich beginne mit dem Ping zwischen GRE-Schnittstellen:

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

Der GRE-Tunnel ist aktiv und läuft:

Schritt 3. Mit GOST GRE verschlüsseln

Ich stelle die Art der Identifikation ein – nach Adresse. Authentifizierung mit einem vordefinierten Schlüssel (laut Nutzungsbedingungen müssen digitale Zertifikate verwendet werden):

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

Ich habe die IPsec-Phase-I-Parameter eingestellt:

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

Ich habe die IPsec Phase II-Parameter eingestellt:

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

Ich erstelle eine Zugriffsliste zur Verschlüsselung. Gezielter Traffic – GRE:

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

Ich erstelle eine Kryptokarte und binde sie an die WAN-Schnittstelle:

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 ist die Konfiguration gespiegelt, die Unterschiede sind:

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

Überprüfung:

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

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

Es gibt keine Pakete im GRE-Verkehrsspeicherauszug:

Fazit: Das GRE-over-IPsec-Schema funktioniert korrekt.

Abbildung 1.5: IPsec-over-GRE

Ich habe nicht vor, IPsec-over-GRE im Netzwerk zu verwenden. Ich sammle, weil ich es will.

Um das GRE-over-IPsec-Schema umgekehrt bereitzustellen:

• Korrigieren Sie die Verschlüsselungszugriffsliste – gezielter Datenverkehr von LAN1 zu LAN2 und umgekehrt;
• Konfigurieren Sie das Routing über GRE.
• Hängen Sie eine Kryptomap an die GRE-Schnittstelle.

Standardmäßig gibt es in der Cisco-ähnlichen Gateway-Konsole keine GRE-Schnittstelle. Es existiert nur im Betriebssystem.

Ich füge die GRE-Schnittstelle zur Cisco-ähnlichen Konsole hinzu. Dazu bearbeite ich die Datei /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="*")

Dabei ist gre1 die Schnittstellenbezeichnung im Betriebssystem und Tunnel0 die Schnittstellenbezeichnung in der Cisco-ähnlichen Konsole.

Ich berechne den Hash der Datei neu:

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

SUCCESS:  Operation was successful.

Jetzt ist die Tunnel0-Schnittstelle in der Cisco-ähnlichen Konsole aufgetaucht:

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

Korrigieren der Zugriffsliste für die Verschlüsselung:

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

Ich konfiguriere das Routing über 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

Ich entferne die Kryptomap von Fa0/0 und binde sie an die GRE-Schnittstelle:

VG1(config)#
interface Tunnel0
crypto map CMAP

Bei VG2 ist es ähnlich.

Überprüfung:

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

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

Im ESP-Verkehrsspeicherauszug sind die in GRE gekapselten Pakete:

Fazit: IPsec-over-GRE funktioniert korrekt.

Ergebnisse

Eine Tasse Kaffee reichte. Ich habe Anweisungen zum Erhalt einer Demoversion skizziert. GRE-over-IPsec konfiguriert und umgekehrt bereitgestellt.

Die Karte der Netzwerkschnittstellen in Version 4.3 erfolgt automatisch! Ich teste weiter.

Anonymer Ingenieur
t.me/anonymous_engineer

Source: habr.com