🥇1.5 Skizzen für inländisches IPsec VPN. Ich teste die Demoversionen

Situation

Ich habe die Demoversion der S-Terra VPN Produkte Version 4.3 für drei Monate erhalten. Ich möchte herausfinden, ob sich mein Ingenieurleben nach dem Wechsel zur neuen Version erleichtert.

Heute ist es nicht schwierig, ein Päckchen löslichen 3-in-1-Kaffees sollte ausreichen. Ich werde erzählen, wie man Demoversionen erhält. Ich werde versuchen, GRE-over-IPsec und IPsec-over-GRE-Schemata zu erstellen.

Wie man eine Demoversion erhält

Die Abbildung zeigt, dass man eine Demoversion wie folgt erhält:

Eine E-Mail an presale@s-terra.ru von einer Unternehmensadresse schreiben;
Im Schreiben die TAN Ihrer Organisation angeben;
Die Produkte und deren Anzahl auflisten.

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

Ich entpacke das Image

Die Demoversion des Sicherheitsgateways ist ein virtueller Maschinen-Image. Ich benutze VMWare Workstation. Eine vollständige Liste der unterstützten Hypervisoren und Virtualisierungsumgebungen ist auf der Website des Anbieters zu finden.

Bevor Sie aktiv werden, beachten Sie, dass das virtuelle Maschinen-Image standardmäßig keine Netzwerkschnittstellen enthält:

Es ist klar, der Benutzer muss so viele Schnittstellen hinzufügen, wie er benötigt. Ich werde gleich vier hinzufügen:

Jetzt starte ich die virtuelle Maschine. Direkt nach dem Start verlangt das Gateway nach einem Benutzernamen und einem Passwort.

Im C-Terra Gateway gibt es mehrere Konsolen mit verschiedenen Konten. Ich werde ihre Anzahl in einem separaten Artikel berechnen. In der Zwischenzeit:
Anmelden als: Administrator Passwort: s-terra

Ich initiiere das Gateway. Die Initialisierung ist eine Abfolge von Schritten: Lizenz eingeben, den biologischen Zufallszahlengenerator (Tastaturtrainer – mein Rekord 27 Sekunden) konfigurieren und die Karte der Netzwerkschnittstellen erstellen.

Karte der Netzwerkschnittstellen. Es wurde einfacher.

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

IPsec-Daemon startet….. fehlgeschlagen FEHLER: Verbindung mit dem Daemon konnte nicht hergestellt werden

Ein aktiver Benutzer (laut anonymem Ingenieur) ist ein Benutzer, der in der Lage ist, alles schnell und ohne Dokumentation zu konfigurieren.

Etwas lief schief, noch bevor ich versuchte, die IP-Adresse an der Schnittstelle einzustellen. Das Problem lag in der Karte der Netzwerkschnittstellen. Es mussten folgende Schritte durchgeführt werden:

/bin/netifcfg enum > /home/map /bin/netifcfg map /home/map Netzwerkdienste neu starten

In der Folge wird eine Karte der Netzwerkschnittstellen erstellt, die das Mapping der Namen physischer Schnittstellen (0000:02:03.0) und deren logischen Bezeichnungen im Betriebssystem (eth0) und 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

Logische Bezeichnungen der Schnittstellen werden Aliase genannt. Aliase werden in der Datei /etc/ifaliases.cf gespeichert.
In der Version 4.3 wird beim ersten Start der virtuellen Maschine die Schnittstellenkarte automatisch erstellt. Wenn Sie die Anzahl der Netzwerkinterfaces in der virtuellen Maschine ändern, erstellen Sie bitte die Schnittstellenkarte erneut:

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

Schema 1: GRE-über-IPsec

Ich richte zwei virtuelle Gateways ein und verdrahte sie wie in der Abbildung dargestellt:

Schritt 1. Ich konfiguriere IP-Adressen und Routen

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

Ich überprüfe die IP-Konnektivität:

root@VG1:~# ping 172.16.1.254 -c 4
PING 172.16.1.254 (172.16.1.254) 56(84) Bytes Daten.
64 Bytes von 172.16.1.254: icmp_seq=1 ttl=64 Zeit=0.545 ms
64 Bytes von 172.16.1.254: icmp_seq=2 ttl=64 Zeit=0.657 ms
64 Bytes von 172.16.1.254: icmp_seq=3 ttl=64 Zeit=0.687 ms
64 Bytes von 172.16.1.254: icmp_seq=4 ttl=64 Zeit=0.273 ms

--- 172.16.1.254 Ping-Statistiken ---
4 Pakete übertragen, 4 empfangen, 0 % Paketverlust, Zeit 3005 ms
rtt min/avg/max/mdev = 0.273/0.540/0.687/0.164 ms

Schritt 2. Ich konfiguriere GRE

Das Beispiel für die GRE-Konfiguration habe ich aus den offiziellen Szenarien. Ich erstelle die Datei gre1 im Verzeichnis /etc/network/interfaces.d mit folgendem 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 hebe das Interface im System an:

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

Ich überprüfe:

root@VG1:~# ip address show
8: gre1@NONE:  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

Im C-Terra Gateway gibt es einen integrierten Paket-Sniffer – tcpdump. Ich werde einen Traffic-Dump in eine pcap-Datei aufzeichnen:

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

Ich starte einen Ping zwischen den GRE-Interfaces:

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

Schritt 3. Verschlüsselung mit GOST für GRE

Ich lege den Identifizierungstyp fest – nach Adresse. Die Authentifizierung erfolgt über einen vordefinierten Schlüssel (laut Nutzungsbedingungen sind digitale Zertifikate zu verwenden):

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

Ich lege die IPsec Phase I Parameter fest:

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

Ich lege die IPsec Phase II Parameter fest:

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

Ich erstelle eine Zugriffs-Listen für die Verschlüsselung. Zielverkehr – 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 das WAN-Interface:

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 spiegelbildlich, Unterschiede:

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

Ich überprüfe:

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

root@VG1:~# sa_mgr show
ISAKMP-Sitzungen: 0 initiiert, 0 geantwortet

ISAKMP-Verbindungen:
Num Conn-id (Lokale Adresse,Port)-(Remote Adresse,Port) Status Gesendet Empfangen
1 1 (172.16.1.253,500)-(172.16.1.254,500) aktiv 1086 1014

IPsec-Verbindungen:
Num Conn-id (Lokale Adresse,Port)-(Remote Adresse,Port) Protokoll Aktionsart Gesendet Empfangen
1 1 (172.16.1.253,*)-(172.16.1.254,*) 47 ESP tunn 480 480

Im Datenverkehrs-Dump von GRE-Paketen gibt es keine:

Ausgabe: GRE-over-IPsec-Schema funktioniert korrekt.

Schema 1.5: IPsec-over-GRE

Ich plane nicht, IPsec-over-GRE im Netzwerk zu verwenden. Ich richte es ein, weil ich es möchte.

Um das GRE-over-IPsec-Schema umzukehren, muss man:

Die Zugriffssteuerungsliste für die Verschlüsselung korrigieren – Zielverkehr von LAN1 zu LAN2 und umgekehrt;
Die Routing-Konfiguration über GRE einstellen;
Die Kryptokarte am GRE-Interface anbringen.

Standardmäßig hat die Cisco-ähnliche Konsole des Gateways kein GRE-Interface. Es existiert nur im Betriebssystem.

Ich füge das GRE-Interface in die Cisco-ähnliche Konsole ein. 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="*")

wobei gre1 – die Bezeichnung des Interfaces im Betriebssystem, Tunnel0 – die Bezeichnung des Interfaces in der Cisco-ähnlichen Konsole ist.

Ich berechne den Hash der Datei:

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

ERFOLG:  Die Operation war erfolgreich.

Jetzt erscheint das Tunnel0-Interface in der Cisco-ähnlichen Konsole:

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

Passe die Zugriffslisten für die Verschlüsselung an:

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

Richte das Routing über GRE ein:

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

Entferne die Krypto-Karte von Fa0/0 und binde sie an das GRE-Interface:

VG1(config)#
interface Tunnel0
crypto map CMAP

Für VG2 entsprechend.

Ich überprüfe:

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) von 192.168.1.253 : 56(84) Bytes Daten.
64 Bytes von 192.168.2.254: icmp_seq=1 ttl=64 Zeit=492 ms
64 Bytes von 192.168.2.254: icmp_seq=2 ttl=64 Zeit=1.08 ms
64 Bytes von 192.168.2.254: icmp_seq=3 ttl=64 Zeit=1.06 ms
64 Bytes von 192.168.2.254: icmp_seq=4 ttl=64 Zeit=1.07 ms

--- 192.168.2.254 Pingstatistiken ---
4 Pakete gesendet, 4 empfangen, 0% Paketverlust, Zeit 3006ms
rtt min/avg/max/mdev = 1.064/124.048/492.972/212.998 ms

ISAKMP/IPsec Statistik:

root@VG1:~# sa_mgr show
ISAKMP-Sitzungen: 0 initiiert, 0 beantwortet

ISAKMP-Verbindungen:
Num Conn-id (Lokale Adresse,Port)-(Remote Adresse,Port) Zustand Gesendet Empfangen
1 2 (172.16.1.253,500)-(172.16.1.254,500) aktiv 1094 1022

IPsec-Verbindungen:
Num Conn-id (Lokale Adresse,Port)-(Remote Adresse,Port) Protokoll Aktion Typ Gesendet Empfangen
1 2 (192.168.1.0-192.168.1.255,*)-(192.168.2.0-192.168.2.255,*) * ESP tunn 352 352

Im Datenverkehrs-Dump sind ESP-Pakete, die in GRE eingekapselt sind:

Fazit: IPsec-over-GRE funktioniert korrekt.

Ergebnisse

Eine Tasse Kaffee genügte. Ich habe eine Anleitung zur Erlangung der Demoversion entworfen. Ich habe GRE über IPsec konfiguriert und umgekehrt implementiert.

Die Netzwerkschnittstellenkarte in Version 4.3 ist automatisch! Ich teste weiter.

Anonymer Ingenieur
t.me/anonimous_engineer

Quelle: habr.com