🌳 🦏 🧔🏽 IPSec Allmächtig 🧝 👨🏾‍💼 👇🏾

Guten Nachmittag Freunde. Es ist kein Geheimnis, dass viele von uns mindestens einmal haben, sich aber mit der Notwendigkeit befassen mussten, ein VPN zu konfigurieren. Als aktiver Leser von Habr bemerkte ich, dass es trotz der Fülle an Artikeln über IPSec für viele immer noch etwas Kompliziertes und Überladenes zu sein scheint. In diesem Artikel werde ich versuchen, diese Mythen anhand meiner eigenen voll funktionsfähigen Konfiguration zu zerstreuen. In vier Beispielen werden wir die Konfiguration der beliebtesten Linux-Lösung (Strongswan) vollständig durchgehen, von einem einfachen Tunnel mit Seitenauthentifizierung mit PSK-Schlüsseln bis zu einer Host-zu-Host-Verbindung mit Authentifizierung beider Seiten basierend auf Zertifikaten von Let's Encrypt. Interessant? Willkommen bei Katze!

Hintergrund

Ursprünglich war das VPN nur für die Organisation des Kanals zwischen dem Mini-Router der Eltern und dem Heim-Server am Krankenbett geplant, der gleichzeitig als Router fungiert.

Nach kurzer Zeit wurde Keenetic von zwei Geräten zu diesem Unternehmen hinzugefügt.
Aber als es anfing, stellte sich heraus, dass es schwierig war aufzuhören, und bald tauchten Telefone und ein Laptop auf dem Diagramm auf, die sich vor dem allsehenden Werbeauge von MT_Free und anderen unverschlüsselten WiFi-Netzwerken verstecken wollten.

Dann wurde der geliebte ILV endlich stärker, der Banhammer, in den er sich unglaublich verliebt hatte, öffentlich in alle Richtungen zu schwingen, und um seine Sorge um bloße Sterbliche zu neutralisieren, musste er ~~den ausländischen IT-Sektor unterstützen~~ , um VPS im Ausland zu erwerben.
Darüber hinaus verschwendet eine bestimmte Bürgerin, die wie Shapoklyak aussieht, überall mit ihrem ~~Fadenkreuz durch das~~ Paket ~~herum~~ und glaubt wahrscheinlich, dass „Wer Menschen hilft, Zeit verschwendet. Du kannst nicht berühmt werden für gute Taten. “Ich wollte heimlich einen Blick auf den Verkehr eines anderen werfen und ihn mit Bleistift aufnehmen. Wir müssen uns auch gegen solche unaufgeforderte Liebe und VPN verteidigen, in diesem Fall genau das, was der Arzt angeordnet hat.

Um eine kurze Zusammenfassung zusammenzufassen. Es musste eine Lösung gefunden werden, mit der im Idealfall mehrere Aufgaben gleichzeitig abgeschlossen werden konnten:

Verbindung zwischen Linux-Routern herstellen
Baue einen Tunnel zwischen Linux und Keenetic Household
Ermöglichen Sie tragbaren Geräten (Telefonen, Laptops) aus nicht vertrauenswürdigen Netzwerken den Zugriff auf Heimressourcen und das Internet
Erstellen Sie einen sicher verschlüsselten Tunnel zum Remote-VPS

Vergessen Sie nicht das wunderbare KISS-Prinzip - Halten Sie es einfach, dumm. Je weniger Komponenten beteiligt sind und je einfacher die Konfiguration der einzelnen Komponenten ist, desto zuverlässiger.

Übersicht bestehender Lösungen

Gehen Sie kurz auf das ein, was jetzt ist:

PPTP-

Großvater Lenin aller Protokolle. Gestorben, "Verfallen auf Schimmel und Lindenhonig."

L2TP

Verwendet dies nur ein Anbieter?

Das Wireguard-

Projekt entwickelt sich. Aktiv gesägt. Es ist einfach, einen Tunnel zwischen zwei Peers mit einer statischen IP zu erstellen. In anderen Fällen sind Krücken, Fahrräder mit Vierkanträdern und ein blaues Isolierband immer bereit zu helfen, aber das ist nicht unser Weg.

OpenVPN-

Vorteile:

Unterstützung für mehrere Plattformen - Windows, Linux, OpenWRT und seine Derivate, Android
Starke Verschlüsselung und Zertifikatsunterstützung.
Flexibilität der Anpassung.

Und Nachteile:

Arbeiten Sie vollständig im Benutzerbereich.
Eingeschränkte Unterstützung durch Heimrouter - krenenko-kosenko auf Mikrotik (ohne die anderen Vorteile der Drüsen zu beeinträchtigen) und normal in OpenWRT.
Schwierigkeiten beim Einrichten mobiler Clients: Sie müssen Konfigurationen irgendwo herunterladen oder ein eigenes Installationsprogramm erstellen.
Wenn es mehrere Tunnel gibt, warten Tänze mit der Bearbeitung der Systemeinheiten auf dem Server.

OpenConnect (Open-Source-Implementierung des Cisco Anyconnect-Protokolls)
Eine sehr interessante Lösung, über die leider einige Informationen vorliegen .

Vorteile:

Relativ breite Unterstützung für verschiedene Plattformen - Windows, Android, Mac basierend auf der nativen Cisco Anyconnect-Anwendung aus dem Store - ist eine ideale Option, um Zugriff auf das interne Netzwerk tragbarer Geräte zu erhalten.
Starke Verschlüsselung, Zertifikatunterstützung, 2FA-Konnektivität
Das Protokoll selbst ist vollständig TLS-basiert (im Gegensatz zu OpenVPN, das an Port 443 leicht erkannt werden kann). Neben TLS wird auch DTLS unterstützt. Während der eingerichteten Sitzung kann der Client auf die Datenübertragung über UDP umschalten und umgekehrt.
Hervorragende Koexistenz an einem Port eines VPN und eines vollwertigen Webservers mit Sniproxy.
Einfache Einrichtung von Server und Clients.

Auch hier waren nicht ohne Nachteile:

Arbeiten Sie vollständig im Benutzerbereich.
TCP über TCP ist eine schlechte Idee.
Es gibt keine Unterstützung durch Geräte vom Kunden.
Die Komplexität der Installation von Tunneln zwischen zwei Linux: theoretisch möglich, praktisch - es ist besser, Zeit mit etwas Nützlicherem zu verbringen.
Wenn es mehrere Tunnel gibt, warten Tänze mit mehreren Konfigurationen und Bearbeitungssystemen.

Es scheint eine Sackgasse zu sein, aber nachdem ich genauer hinschaute und ein wenig Zeit mit dem Lernen verbracht hatte, wurde mir klar, dass IPSec auf IKEv2-Basis alles andere ersetzen kann.

IKEv2 IPSEC-Vorteile

:

Mit dem Aufkommen von IKEv2 ist das Protokoll selbst im Vergleich zur vorherigen Version einfacher zu konfigurieren, jedoch auf Kosten des Verlusts der Abwärtskompatibilität.
Dank der Standardisierung wird überall und an allem gearbeitet - die Liste kann unbegrenzt gepflegt werden. Linux, Mikrotik (in den neuesten Versionen von RouterOS), OpenWRT, Android, iPhone. Windows bietet ab Windows 7 auch native Unterstützung.
Hohe Geschwindigkeit: Verkehrsverarbeitung komplett im Kernel-Space. Der User-Space-Teil wird nur zum Festlegen von Verbindungsparametern und zum Überwachen des Kanalzustands benötigt.
Die Möglichkeit, mehrere Authentifizierungsmethoden zu verwenden: sowohl PSK als auch Zertifikate und in beliebiger Kombination.
Verschiedene Betriebsarten: Tunnel und Transport. Wie sie sich unterscheiden, kann man auch auf Habré nachlesen.
Unerwünschte Einstellungen für Zwischenknoten: Wenn in der ersten Version von IKE Probleme durch NAT verursacht wurden, verfügt IKEv2 über integrierte Mechanismen zur Überwindung von NAT und der nativen Fragmentierung von IKE-Nachrichten, mit denen Sie eine Verbindung auf Kanälen mit einer MTU-Kurve herstellen können. Mit Blick auf die Zukunft werde ich sagen, dass ich in der Praxis noch nie auf ein WiFi-Netzwerk gestoßen bin, wo immer ein Client eine Verbindung herstellen kann.

Nachteile haben jedoch auch:

Sie müssen einige Zeit damit verbringen, zu studieren und zu verstehen, wie es funktioniert.
Eine Funktion, die einen Neuling verwirren kann: IPSec erstellt im Gegensatz zu herkömmlichen VPN-Lösungen keine Netzwerkschnittstellen. Es werden nur Richtlinien für die Verkehrsverarbeitung festgelegt, alles andere wird mithilfe einer Firewall gelöst.

Bevor wir mit dem Setup fortfahren, gehen wir davon aus, dass der Leser mit den grundlegenden Konzepten und Begriffen bereits ein wenig vertraut ist. Um Anfängern zu helfen, können Sie einen Artikel von Wikipedia und Habr selbst empfehlen , zu dem es bereits interessante und nützliche Artikel zu diesem Thema gibt.

Erste Schritte beim Einrichten

Nachdem wir uns für die Entscheidung entschieden haben, fahren wir mit der Konfiguration fort. Das Netzwerkdiagramm hat in meinem Fall das folgende Formular (unter dem Spoiler entfernt)

Netzwerkdiagramm

ipsecgw.example.com ist der Heimserver, der das Zentrum des Netzwerks darstellt. Externe IP 1.1.1.1. Ein internes Netzwerk 10.0.0.0/23 und eine andere Adresse 10.255.255.1/30 zum Einrichten einer privaten BGP-Sitzung mit VPS;
mama ist ein Linux-Router, der auf einem kleinen, leisen Nettop basiert, das von den Eltern installiert wurde. Der ISP gibt eine dynamische IP-Adresse aus. Internes Netzwerk 10.0.3.0/24;
scharfetic - Keenetic Router mit installiertem IPSec. Der ISP gibt eine dynamische IP-Adresse aus. Internes Netzwerk 10.0.4.0/24;
Straßenkämpfer - tragbare Geräte, die Verbindungen von nicht vertrauenswürdigen Netzwerken herstellen. Adressen werden dynamisch an Clients ausgegeben, wenn sie über den internen Pool verbunden sind (10.1.1.0/24).
rkn.example.com- VPS außerhalb der Gerichtsbarkeit eines angesehenen ILV. Externe IP - 5.5.5.5, interne Adresse 10.255.255.2/30 zum Einstellen einer privaten BGP-Sitzung.

Erster Schritt. Von einfach bis komplex: Tunnel mit Pre-Shared Keys (PSK)

Auf beiden Linux-Boxen installieren wir die notwendigen Pakete:

sudo yum install strongswan

Öffnen Sie auf beiden Hosts die Ports 500 / udp, 4500 / udp und lassen Sie den Durchgang des ESP-Protokolls zu.
Bearbeiten Sie die Datei /etc/strongswan/ipsec.secrects (auf der Hostseite ipsecgw.example.com) und fügen Sie die folgende Zeile hinzu:

mama@router.home.local: PSK "Very strong PSK"

Auf der zweiten Seite ähnlich:

root@root.mama.local: PSK "Very strong PSK"

In diesem Fall ist die ID eine fiktive E-Mail-Adresse. Weitere Informationen finden Sie im offiziellen Wiki .

Geheimnisse gespeichert, weitergehen.

Bearbeiten Sie auf dem Host ipsecgw.example.com die Datei /etc/strongswan/ipsec.conf:

config setup //   charon
    charondebug = "dmn 0, mgr 0, ike 0, chd 0, job 0, cfg 0, knl 0, net 0, asn 0, enc 0, lib 0, esp 0, tls 0, tnc 0, imc 0, imv 0, pts 0" //  
conn %default //    
    reauth = yes
    rekey = yes
    keyingtries = %forever
    keyexchange = ikev2 //      - IKEv2
    dpdaction = hold
    dpddelay = 5s // 5   DPD (Dead Peer Detection)   
    mobike = yes // Mobile IKE -     IP    
conn mama //  
    left = %defaultroute //Left -  .  %defaultroute       IKE- ,    default route
    right = %any //     IP-
    authby = psk //   -   
    leftid = mama@router.home.local // ID,   ipsec.secrets
    rightid = root@router.mama.local //ID  
    leftsubnet = 10.0.0.0/23,10.1.1.0/24 
    rightsubnet = 10.0.3.0/24
    type = tunnel 
    ike = aes256-aes192-aes128-sha256-sha384-modp2048-modp3072-modp4096-modp8192,aes128gcm16-sha384-x25519!
    esp = aes256-aes192-aes128-sha256-sha384-modp2048-modp3072-modp4096-modp8192,aes128gcm16-sha256-sha384-x25519! 
    auto = add //  charon

In ähnlicher Weise bearbeiten wir auf dem Remote-Peer /etc/strongswan/ipsec.conf:

config setup
    charondebug = "dmn 0, mgr 0, ike 0, chd 0, job 0, cfg 0, knl 0, net 0, asn 0, enc 0, lib 0, esp 0, tls 0, tnc 0, imc 0, imv 0, pts 0"
conn %default
    reauth = yes
    rekey = yes
    keyingtries = %forever
    keyexchange = ikev2
    dpdaction = restart
    dpddelay = 5s
    mobike = yes
conn mama
    left = %defaultroute
    right = ipsecgw.example.com
    authby = psk
    leftid = root@router.mama.local
    rightid = mama@router.home.local
    leftsubnet = 10.0.3.0/24
    rightsubnet = 10.0.0.0/23,10.1.1.0/24
    type = tunnel
    ike = aes128gcm16-sha384-x25519!
    esp = aes128gcm16-sha384-x25519!
    auto = route

Wenn Sie die Konfigurationen vergleichen, können Sie sehen, dass sie fast gespiegelt sind. Nur die Definitionen von Peers werden ausgetauscht.

Die Anweisung auto = route bewirkt, dass charon eine Falle für Datenverkehr setzt, der in die Anweisungen left / rightsubnet (Verkehrsselektoren) fällt. Die Koordination der Tunnelparameter und des Schlüsselaustauschs beginnt unmittelbar nach dem Auftreten von Verkehr, der unter die gegebenen Bedingungen fällt.

Auf dem Server ipsecgw.example.com in den Firewall-Einstellungen verbieten wir das Maskieren für ein 10.0.3.0/24-Netzwerk. Paketweiterleitung zwischen 10.0.0.0/23 und 10.0.3.0/24 zulassen und umgekehrt. Auf dem Remote-Host führen wir ähnliche Einstellungen durch, indem wir die Maskierung für das 10.0.0.0/23-Netzwerk deaktivieren und die Weiterleitung einrichten.

Wir starten strongswan auf beiden Servern neu und versuchen, den zentralen Knoten zu pingen:

sudo systemctl restart strongswan
ping 10.0.0.1

Stellen Sie sicher, dass alles funktioniert:

sudo strongswan status
Security Associations (1 up, 0 connecting):
        mama[53]: ESTABLISHED 84 minutes ago, 1.1.1.1[mama@router.home.local]...2.2.2.2[root@router.mama.local]
        mama{141}:  INSTALLED, TUNNEL, reqid 27, ESP in UDP SPIs: c4eb45fe_i ca5ec6ca_o
        mama{141}:   10.0.0.0/23 10.1.1.0/24 === 10.0.3.0/24

Es ist auch nützlich sicherzustellen, dass der Parameter make_before_break in der Datei /etc/strongswan/strongswan.d/charon.conf bei allen Peers auf yes gesetzt ist. In diesem Fall löscht der Charon-Daemon, der das IKEv2-Protokoll bedient, die aktuelle Sicherheitszuordnung während des Schlüsseländerungsvorgangs nicht, sondern erstellt zuerst eine neue.

Schritt zwei Das Erscheinen von Keenetic

Eine angenehme Überraschung war das in die offizielle Keenetic-Firmware integrierte IPSec-VPN. Um es zu aktivieren, gehen Sie einfach zu den KeeneticOS-Komponenteneinstellungen und fügen Sie das IPSec VPN- Paket hinzu .

Wir bereiten die Einstellungen auf dem zentralen Knoten dafür vor:

Bearbeiten Sie /etc/strongswan/ipsec.secrects und fügen Sie die PSK für den neuen Peer hinzu:

keenetic@router.home.local: PSK "Keenetic+PSK"

Bearbeiten Sie /etc/strongswan/ipsec.conf und fügen Sie am Ende eine weitere Verbindung hinzu:

conn keenetic
    left = %defaultroute
    right = %any
    authby = psk
    leftid = keenetic@router.home.local
    rightid = root@router.keenetic.local
    leftsubnet = 10.0.0.0/23
    rightsubnet = 10.0.4.0/24
    type = tunnel
    ike = aes256-aes192-aes128-sha256-sha384-modp2048-modp3072-modp4096-modp8192,aes128gcm16-sha384-x25519!
    esp = aes256-aes192-aes128-sha256-sha384-modp2048-modp3072-modp4096-modp8192,aes128gcm16-sha256-sha384-x25519!
    auto = add

Auf der Keenetic-Seite erfolgt die Konfiguration in der WebUI über den Pfad: Internet -> Verbindungen ->
Andere Verbindungen . Es ist ziemlich einfach

(3 Bilder)

Wenn Sie vorhaben, ein erhebliches Verkehrsaufkommen durch den Tunnel zu leiten, können Sie versuchen, die Hardwarebeschleunigung zu aktivieren, die von vielen Modellen unterstützt wird. Aktiviert durch den Hardwarebefehl der Crypto Engine in der CLI. So deaktivieren und verarbeiten Sie Verschlüsselungs- und Hashing-Prozesse mithilfe allgemeiner CPU-Anweisungen - Crypto Engine-Software

Nach dem Speichern der Einstellungen stellen wir strongswan wieder her und lassen Keenetic eine halbe Minute nachdenken. Dann sehen wir im Terminal eine erfolgreiche Verbindung:

Alles arbeitet:

sudo strongswan status
Security Associations (2 up, 0 connecting):
    keenetic[57]: ESTABLISHED 39 minutes ago, 1.1.1.1[keenetic@router.home.local]...3.3.3.3[root@router.keenetic.local]
    keenetic{146}:  INSTALLED, TUNNEL, reqid 29, ESP SPIs: ca8f556e_i ca11848a_o
    keenetic{146}:   10.0.0.0/23 === 10.0.4.0/24
        mama[53]: ESTABLISHED 2 hours ago, 1.1.1.1[mama@router.home.local]...2.2.2.2[root@router.mama.local]
        mama{145}:  INSTALLED, TUNNEL, reqid 27, ESP in UDP SPIs: c5dc78db_i c7baafd2_o
        mama{145}:   10.0.0.0/23 10.1.1.0/24 === 10.0.3.0/24

Schritt drei Schutz mobiler Geräte

Nach dem Lesen einer Reihe von Handbüchern und Artikeln wurde beschlossen, bei einer Reihe von kostenlosen Zertifikaten von Let's Encrypt anzuhalten, um den Server und die klassische Autorisierung durch Login und Passwort für Clients zu authentifizieren. Auf diese Weise müssen wir keine eigene PKI-Infrastruktur mehr unterhalten, den Ablauf von Schlüsseln überwachen und unnötige Gesten mit Mobilgeräten ausführen, indem wir selbstsignierte Zertifikate in der vertrauenswürdigen Liste installieren.

Installieren Sie die fehlenden Pakete:

sudo yum install epel-release
sudo yum install certbot

Wir erhalten das Standalone-Zertifikat (vergessen Sie nicht, zuerst 80 / tcp in den iptables-Einstellungen zu öffnen):

sudo certbot certonly --standalone -d ipsecgw.example.com

Nachdem certbot seine Arbeit abgeschlossen hat, müssen wir Strongswan beibringen, unser Zertifikat zu sehen:

Erstellen Sie im Verzeichnis /etc/strongswan/ipsec.d/cacerts zwei symbolische Links: einen zum Stammspeicher vertrauenswürdiger Zertifikate in / etc / pki / tls / certs; und eine Sekunde mit dem Namen ca.pem, der auf /etc/letsencrypt/live/ipsecgw.example.com/chain.pem verweist
Im Verzeichnis /etc/strongswan/ipsec.d/certs werden außerdem zwei Symlinks erstellt: Der erste mit dem Namen certificate.pem bezieht sich auf die Datei /etc/letsencrypt/live/ipsecgw.example.com/cert.pem. Und die zweite mit dem Namen fullchain.pem, die auf /etc/letsencrypt/live/ipsecgw.example.com/fullchain.pem verweist
Platzieren Sie im Verzeichnis /etc/strongswan/ipsec.d/private den Symlink key.pem, der auf den von certbot generierten privaten Schlüssel verweist und auf dem Pfad /etc/letsencrypt/live/ipsecgw.example.com/privkey.pem liegt

Fügen Sie ipsec.secrets eine Authentifizierung über RSA und eine Reihe von Anmeldungen / Kennwörtern für neue Benutzer hinzu:

ipsecgw.example.com     : RSA key.pem
username phone          : EAP "Q1rkz*qt"
username notebook       : EAP "Zr!s1LBz"

Wir starten Strongswan neu und wenn wir sudo strongswan listcerts aufrufen, sollten wir die Zertifikatinformationen sehen:

List of X.509 End Entity Certificates

  subject:  "CN=ipsecgw.example.com"
  issuer:   "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3"
  validity:  not before May 23 19:36:52 2020, ok
             not after  Aug 21 19:36:52 2020, ok (expires in 87 days)
  serial:    04:c7:70:9c:a8:ce:57:cc:bf:6f:cb:fb:d3:a9:cf:06:b0:a8
  altNames:  ipsecgw.example.com
  flags:     serverAuth clientAuth
  OCSP URIs: http://ocsp.int-x3.letsencrypt.org
  certificatePolicies:
             2.23.140.1.2.1
             1.3.6.1.4.1.44947.1.1.1
             CPS: http://cps.letsencrypt.org

Dann beschreiben wir die neue Verbindung in ipsec.conf :

conn remote-access
    dpddelay = 30s //   DPD ,     
    left = %defaultroute
    leftid = "CN=ipsecgw.example.com"
    leftcert = fullchain.pem //         
    leftsendcert = always
    leftsubnet = 0.0.0.0/0 //      
    right = %any
    rightid = %any
    rightauth = eap-mschapv2 // ,  EAP-MSCHAP2
    rightsendcert = never
    eap_identity = %identity 
    rightsourceip = 10.1.1.0/24 //Strongswan       
    rightdns = 10.0.0.1,10.0.0.3 //   DNS
    type = tunnel
    ike = aes256-aes192-aes128-sha256-sha384-modp2048-modp3072-modp4096-modp8192,aes128gcm16-sha384-x25519!
    esp = aes256-aes192-aes128-sha256-sha384-modp2048-modp3072-modp4096-modp8192,aes128gcm16-sha256-sha384-x25519!
    auto = add //      
    dpdaction = restart // ,      DPD

Vergessen Sie nicht, die Datei / etc / sysconfig / certbot zu bearbeiten, um anzuzeigen, dass das Zertifikat auch als eigenständig aktualisiert wird, und fügen Sie CERTBOT_ARGS = "- standalone" hinzu.

Vergessen Sie auch nicht, den Timer certbot-erneuern.timer einzuschalten und den Hook so einzustellen, dass Strongswan neu gestartet wird, falls ein neues Zertifikat ausgestellt wird. Platzieren Sie dazu entweder ein einfaches Bash-Skript in / etc / letsencrypt / erneueral-hooks / deploy / oder bearbeiten Sie die Datei / etc / sysconfig / certbot erneut.

Wir starten Strongswan neu, aktivieren die Maskierung für das 10.1.1.0/24-Netzwerk in iptables und konfigurieren anschließend mobile Geräte.

Android

Installieren Sie die Strongswan- Anwendung von Google Play .

Wir starten und erstellen eine neue

Profil

Wir speichern das Profil, stellen eine Verbindung her und müssen uns nach einer Sekunde keine Sorgen mehr machen, dass jemand uns ausspionieren kann.

Wir überprüfen:

sudo strongswan statusall
Security Associations (3 up, 0 connecting):
remote-access[109]: ESTABLISHED 2 seconds ago, 1.1.1.1[CN=ipsecgw.example.com]...4.4.4.4[phone]
remote-access{269}:  INSTALLED, TUNNEL, reqid 55, ESP in UDP SPIs: c706edd1_i e5c12f1d_o
remote-access{269}:   0.0.0.0/0 ::/0 === 10.1.1.1/32
        mama[101]: ESTABLISHED 34 minutes ago, 1.1.1.1[mama@router.home.local]...2.2.2.2[root@router.mama.local]
        mama{265}:  INSTALLED, TUNNEL, reqid 53, ESP in UDP SPIs: c8c83342_i c51309db_o
        mama{265}:   10.0.0.0/23 10.1.1.0/24 === 10.0.3.0/24
    keenetic[99]: ESTABLISHED 36 minutes ago, 1.1.1.1[keenetic@router.home.local]...3.3.3.3[root@router.keenetic.local]
    keenetic{263}:  INSTALLED, TUNNEL, reqid 52, ESP SPIs: c3308f33_i c929d6f1_o
    keenetic{263}:   10.0.0.0/23 === 10.0.4.0/24

Windows

Windows der aktuellen Versionen war angenehm überrascht. Die gesamte Konfiguration des neuen VPN erfolgt durch Aufrufen von zwei PowerShell-Cmdlets:

Add-VpnConnection -Name "IKEv2" -ServerAddress ipsecgw.example.com -TunnelType "IKEv2"
Set-VpnConnectionIPsecConfiguration -ConnectionName "IKEv2" -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES128 -EncryptionMethod AES128 -IntegrityCheckMethod SHA256 -PfsGroup PFS2048 -DHGroup Group14 -PassThru -Force

Und noch etwas, wenn Strongswan so konfiguriert ist, dass es IPv6-Adressen an Clients ausgibt (ja, das kann er auch):

Add-VpnConnectionRoute -ConnectionName "IKEv2" -DestinationPrefix "2000::/3"

Vierter Teil, Finale. Wir haben ein Fenster nach Europa geschnitten

Nachdem die Provider-Stubs „Die Website wurde durch die Entscheidung der linken Ferse des fünften stellvertretenden Staatsanwalts des Dorfes Trudovye Mozoli im Landkreis Bogozabyt blockiert“ erschienen, erschien ein kleiner, unauffälliger VPS (mit dem gut klingenden Domainnamen rkn.example.com) tausend Kilometer von Affen entfernt, die gerne mit einem Banhammer winken und Netzwerke von Größe blockieren / 16 auf einmal. Und dieses kleine VPS zu drehen war eine wundervolle Kreation von Kollegen von NIC.CZ namens BIRD. Der Vogel der ersten Version starb ständig in Panik an der Aktivität von Affen mit Schlagstöcken, die auf dem Höhepunkt ihrer Arbeitstätigkeit fast 4% des Internets verboten und während der Neukonfiguration tief nachdenklich blieben. Daher wurde er auf Version 2.0.7 aktualisiert. Wenn Leser interessiert sind, werde ich einen Artikel über den Übergang von BIRD zu BIRD2 veröffentlichen, in dem sich das Konfigurationsformat dramatisch geändert hat.Die neue Version ist jedoch viel schneller geworden und es gibt keine Probleme bei der Neukonfiguration mit einer großen Anzahl von Routen. Und da wir das dynamische Routing-Protokoll verwenden, muss es eine Netzwerkschnittstelle geben, über die Sie den Verkehr weiterleiten müssen. Standardmäßig erstellt IPSec keine Schnittstellen, aber aufgrund seiner Flexibilität können wir die klassischen GRE-Tunnel verwenden, die wir in Zukunft schützen werden. Als Bonus authentifizieren sich die Hosts ipsecgw.example.com und rkn.example.com gegenseitig mit sich selbst erneuernden Lets Encrypt-Zertifikaten. Kein PSK, nur Zertifikate, nur Hardcore, es gibt nicht viel Sicherheit.Standardmäßig erstellt IPSec keine Schnittstellen, aber aufgrund seiner Flexibilität können wir die klassischen GRE-Tunnel verwenden, die wir in Zukunft schützen werden. Als Bonus authentifizieren sich die Hosts ipsecgw.example.com und rkn.example.com gegenseitig mit sich selbst erneuernden Lets Encrypt-Zertifikaten. Kein PSK, nur Zertifikate, nur Hardcore, es gibt nicht viel Sicherheit.Standardmäßig erstellt IPSec keine Schnittstellen, aber aufgrund seiner Flexibilität können wir die klassischen GRE-Tunnel verwenden, die wir in Zukunft schützen werden. Als Bonus authentifizieren sich die Hosts ipsecgw.example.com und rkn.example.com gegenseitig mit sich selbst erneuernden Lets Encrypt-Zertifikaten. Kein PSK, nur Zertifikate, nur Hardcore, es gibt nicht viel Sicherheit.

Wir glauben, dass der VPS vorbereitet ist, Strongswan und Certbot bereits installiert sind.

Auf dem Host ipsecgw.example.com (seine IP ist 1.1.1.1) beschreiben wir die neue gif0-Schnittstelle:

sudo vi /etc/sysconfig/network-scripts/ifcfg-gif0
DEVICE="gif0"
MY_OUTER_IPADDR="1.1.1.1"
PEER_OUTER_IPADDR="5.5.5.5"
MY_INNER_IPADDR="10.255.255.1/30"
PEER_INNER_IPADDR="10.255.255.2/30"
TYPE="GRE"
TTL="64"
MTU="1442"
ONBOOT="yes"

Auf dem Host vps.example.com gespiegelt (seine IP ist 5.5.5.5):

sudo vi /etc/sysconfig/network-scripts/ifcfg-gif0
DEVICE="gif0"
MY_OUTER_IPADDR="5.5.5.5"
PEER_OUTER_IPADDR="1.1.1.1"
MY_INNER_IPADDR="10.255.255.2/30"
PEER_INNER_IPADDR="10.255.255.1/30"
TYPE="GRE"
TTL="64"
MTU="1442"
ONBOOT="yes"

Wir erhöhen die Schnittstellen, aber da iptables keine Regel hat, die das GRE-Protokoll zulässt, wird der Datenverkehr nicht unterbrochen (was wir brauchen, da es in GRE keinen Schutz gegen Fans jeglicher Art von gesetzgeberischen „Paketen“ gibt).

Kochen VPS

Zuerst erhalten wir ein weiteres Zertifikat für den Domainnamen rkn.example.com. Erstellen Sie Symlinks in /etc/strongswan/ipsec.d, wie im vorherigen Abschnitt beschrieben.

Bearbeiten Sie ipsec.secrets, indem Sie eine einzelne Zeile hinzufügen:

rkn.example.com     : RSA key.pem

Bearbeiten Sie die ipsec.conf:

config setup
    charondebug = "dmn 0, mgr 0, ike 0, chd 0, job 0, cfg 0, knl 0, net 0, asn 0, enc 0, lib 0, esp 0, tls 0, tnc 0, imc 0, imv 0, pts 0"
    strictcrlpolicy = yes
conn %default
    reauth = yes
    rekey = yes
    keyingtries = %forever
    keyexchange = ikev2
    dpdaction = restart
    dpddelay = 5s
    mobike = yes
conn rkn
    left = %defaultroute
    right = ipsecgw.example.com
    authby = pubkey
    leftcert = fullchain.pem
    leftsendcert = always
    leftauth = pubkey
    rightauth = pubkey
    leftid = "CN=rkn.example.com"
    rightid = "CN=ipsecgw.example.com"
    rightrsasigkey = /etc/strongswan/ipsec.d/certs/ipsecgw.example.com.pem
    leftsubnet = %dynamic
    rightsubnet = %dynamic
    type = transport
    ike = aes256gcm16-sha384-x25519!
    esp = aes256gcm16-sha384-x25519!
    auto = route

Auf der Hostseite wird ipsecgw.example.com auch zu ipsec.conf im Setup-Abschnitt mit dem Parameter strictcrlpolicy = yes hinzugefügt, der eine strikte CRL-Prüfung umfasst. Und beschreiben Sie eine andere Verbindung:

conn rkn
    left = %defaultroute
    right = rkn.example.com
    leftcert = fullchain.pem
    leftsendcert = always
    leftauth = pubkey
    rightauth = pubkey
    rightrsasigkey = /etc/strongswan/ipsec.d/certs/rkn.exapmle.com.pem
    leftid = "CN=ipsecgw.example.com"
    rightid = "CN=rkn.example.com"
    leftsubnet = %dynamic
    rightsubnet = %dynamic
    type = transport
    ike = aes256gcm16-sha384-x25519!
    esp = aes256gcm16-sha384-x25519!
    auto = route
    dpdaction = restart

Konfigurationen werden fast gespiegelt. Der aufmerksame Leser konnte bereits einige Punkte beachten:

left / rightsubnet =% dynamic - Weist Strongswan an, Richtlinien auf alle Arten von Datenverkehr zwischen Peers anzuwenden
rightrsasigkey. IKE SA IKE AUTH ERROR , Strongswan RSA- . openssl. (ipsecgw RKN) sudo /usr/bin/openssl rsa -in /etc/letsencrypt/live/ipsecgw.example.com/privkey.pem -pubout > ~/ipsecgw.example.com.pem sudo /usr/bin/openssl rsa -in /etc/letsencrypt/live/rkn.example.com/privkey.pem -pubout > ~/rkn.example.com.pem, scp ,

Vergessen Sie nicht, die Firewall zu konfigurieren und Zertifikate automatisch zu erneuern. Beginnen Sie nach dem Neustart von Strongswan auf beiden Servern mit dem Ping auf der anderen Seite des GRE-Tunnels und sehen Sie eine erfolgreiche Verbindung. Auf VPS (rkn):

sudo strongswan status
Routed Connections:
         rkn{1}:  ROUTED, TRANSPORT, reqid 1
         rkn{1}:   5.5.5.5/32 === 1.1.1.1/32
Security Associations (1 up, 0 connecting):
         rkn[33]: ESTABLISHED 79 minutes ago, 5.5.5.5[CN=rkn.example.com]...1.1.1.1[CN=ipsecgw.example.com]
         rkn{83}:  INSTALLED, TRANSPORT, reqid 1, ESP SPIs: cb4bc3bb_i c4c35a5a_o
         rkn{83}:   5.5.5.5/32 === 1.1.1.1/32

Und auf der Hostseite ipsecgw

unter dem Spoiler

Routed Connections:
         rkn{1}:  ROUTED, TRANSPORT, reqid 1
         rkn{1}:   1.1.1.1/32 === 5.5.5.5/32
Security Associations (4 up, 0 connecting):
remote-access[10]: ESTABLISHED 5 seconds ago, 1.1.1.1[CN=ipsecgw.example.com]...4.4.4.4[phone]
remote-access{12}:  INSTALLED, TUNNEL, reqid 7, ESP in UDP SPIs: c7a31be1_i a231904e_o
remote-access{12}:   0.0.0.0/0 === 10.1.1.1/32
    keenetic[8]: ESTABLISHED 22 minutes ago, 1.1.1.1[keenetic@router.home.local]...3.3.3.3[root@router.keenetic.local]
    keenetic{11}:  INSTALLED, TUNNEL, reqid 6, ESP SPIs: cfc1b329_i c01e1b6e_o
    keenetic{11}:   10.0.0.0/23 === 10.0.4.0/24
        mama[4]: ESTABLISHED 83 minutes ago, 1.1.1.1[mama@router.home.local]...2.2.2.2[root@router.mama.local]
        mama{8}:  INSTALLED, TUNNEL, reqid 3, ESP in UDP SPIs: c4a5451a_i ca67c223_o
        mama{8}:   10.0.0.0/23 10.1.1.0/24 === 10.0.3.0/24
         rkn[3]: ESTABLISHED 83 minutes ago, 1.1.1.1[CN=ipsecgw.example.com]...5.5.5.5[CN=rkn.example.com]
         rkn{7}:  INSTALLED, TRANSPORT, reqid 1, ESP SPIs: c4c35a5a_i cb4bc3bb_o
         rkn{7}:   1.1.1.1/32 === 5.5.5.5/32

Der Tunnel ist installiert, Pings gehen, in tcpdump ist sichtbar, dass nur ESP zwischen Hosts geht. Es scheint möglich zu sein, sich zu freuen. Aber Sie können sich nicht entspannen, ohne alles bis zum Ende zu überprüfen. Wir versuchen, das Zertifikat für VPS und ...

Chef, es ist alles kaputt

Wir beginnen ein unangenehmes Merkmal von Let's Encrypt zu verstehen und zu stolpern, das in allem anderen schön ist - bei jeder Neuausstellung des Zertifikats ändert sich auch der damit verbundene private Schlüssel. Der private Schlüssel hat sich geändert - und der öffentliche hat sich geändert. Auf den ersten Blick ist die Situation für uns hoffnungslos: Selbst wenn wir den öffentlichen Schlüssel während der erneuten Ausstellung des Zertifikats mithilfe des Hooks in certbot leicht extrahieren und über SSH an die Remote-Seite weitergeben können, ist nicht klar, wie der Remote-Strongswan ihn erneut lesen kann. Die Hilfe kam jedoch von dort, wo sie nicht gewartet haben - systemd kann Änderungen am Dateisystem überwachen und die mit dem Ereignis verbundenen Dienste ausführen. Dies werden wir verwenden.

Wir werden auf jedem der Hosts mit den am stärksten eingeschränkten Rechten einen Keywatcher-Dienstbenutzer erstellen, für jeden von ihnen SSH-Schlüssel generieren und diese zwischen den Hosts austauschen.

Erstellen Sie auf dem Host ipsecgw.example.com das Verzeichnis / opt / ipsec-pubkey, in dem wir zwei Skripte ablegen.

sudo vi /opt/ipsec-pubkey/pubkey-copy.sh

#!/bin/sh
if [ ! -f /home/keywatcher/ipsecgw.example.com.pem ]; then
  /usr/bin/openssl rsa -in /etc/letsencrypt/live/ipsecgw.example.com/privkey.pem -pubout > /home/keywatcher/ipsecgw.example.com.pem;
  /usr/bin/chown keywatcher:keywatcher /home/keywatcher/ipsecgw.example.com.pem;
  /usr/bin/chmod 0600 /home/keywatcher/ipsecgw.example.com.pem;
  sudo -u keywatcher /usr/bin/scp /home/keywatcher/ipsecgw.example.com.pem rkn.example.com:/home/keywatcher/ipsecgw.example.com.pem;
  status=$?;
  if [ $status -eq 0 ]; then
    rm -f /home/keywatcher/ipsecgw.example.com.pem;
    logger "Public key ipsecgw.example.com.pem has been successfully uploaded to remote host";
  else
    logger "Public key ipsecgw.example.com.pem has not been uploaded to remote host due to error";
  fi
  else
    logger "Public key ipsecgw.example.com.pem already exist on /home/keywatcher directory, something went wrong";
fi
exit 0

sudo vi /opt/ipsec-pubkey/key-updater.sh

#!/bin/sh
/usr/bin/cp /home/keywatcher/rkn.example.com.pem /etc/strongswan/ipsec.d/certs/rkn.example.com.pem
/usr/bin/chown root:root /etc/strongswan/ipsec.d/certs/rkn.example.com.pem
/usr/bin/chmod 0600 /etc/strongswan/ipsec.d/certs/rkn.example.com.pem
logger "Public key of server rkn.example.com has been updated, restarting strongswan daemon to re-read it"
/usr/bin/systemctl restart strongswan
exit 0

Auf VPS (dem Host rkn.example.com) erstellen wir auf ähnliche Weise ein Verzeichnis mit demselben Namen, in dem wir auch ähnliche Skripte erstellen und nur den Namen des Schlüssels ändern. Code, um den Artikel nicht zu überladen, unter

Spoiler

sudo vi /opt/ipsec-pubkey/pubkey-copy.sh

#!/bin/sh
if [ ! -f /home/keywatcher/rkn.example.com.pem ]; then
  /usr/bin/openssl rsa -in /etc/letsencrypt/live/rkn.example.com/privkey.pem -pubout > /home/keywatcher/rkn.example.com.pem;
  /usr/bin/chown keywatcher:keywatcher /home/keywatcher/rkn.example.com.pem;
  /usr/bin/chmod 0600 /home/keywatcher/rkn.example.com.pem;
  sudo -u keywatcher /usr/bin/scp /home/keywatcher/rkn.example.com.pem ipsecgw.example.com:/home/keywatcher/rkn.example.com.pem;
  status=$?;
  if [ $status -eq 0 ]; then
    rm -f /home/keywatcher/rkn.example.com.pem;
    logger "Public key rkn.example.com.pem has been successfully uploaded to remote host";
  else
    logger "Public key rkn.example.com.pem has not been uploaded to remote host";
  fi
  else
    logger "Public key rkn.example.com.pem already exist on /home/keywatcher directory, something went wrong";
fi
exit 0

sudo vi /opt/ipsec-pubkey/key-updater.sh


#!/bin/bash
/usr/bin/cp /home/keywatcher/ipsecgw.example.com.pem /etc/strongswan/ipsec.d/certs/ipsecgw.example.com.pem;
/usr/bin/chown root:root /etc/strongswan/ipsec.d/certs/ipsecgw.example.com.pem
/usr/bin/chmod 0600 /etc/strongswan/ipsec.d/certs/ipsecgw.example.com.pem
logger "Public key of server ipsecgw.example.com has been updated, restarting connection"
/usr/bin/systemctl restart strongswan
exit 0

Das Skript pubkey-copy.sh wird benötigt, um den öffentlichen Teil des Schlüssels zu extrahieren und auf den Remote-Host zu kopieren, wenn ein neues Zertifikat ausgestellt wird. Erstellen Sie dazu im Verzeichnis / etc / letsencrypt / erneueral-hooks / deploy auf beiden Servern ein weiteres Mikroskript:


#!/bin/sh
/opt/ipsec-pubkey/pubkey-copy.sh > /dev/null 2>&1
/usr/bin/systemctl restart strongswan
exit 0

Die Hälfte des Problems ist behoben, Zertifikate werden erneut ausgestellt, öffentliche Schlüssel werden extrahiert und zwischen den Servern kopiert, und es ist Zeit für systemd mit seinen Pfadeinheiten.

Erstellen Sie auf dem Server ipsecgw.example.com im Verzeichnis / etc / systemd / system die Datei keyupdater.path

[Unit]
Wants=strongswan.service
[Path]
PathChanged=/home/keywatcher/rkn.example.com.pem
[Install]
WantedBy=multi-user.target

Ähnliches gilt für den VPS-Host:

[Unit]
Wants=strongswan.service
[Path]
PathChanged=/home/keywatcher/ipsecgw.example.com.pem
[Install]
WantedBy=multi-user.target

Und schließlich erstellen wir auf jedem Server einen diesem Gerät zugeordneten Dienst, der gestartet wird, wenn die Bedingung (PathChanged) erfüllt ist - die Datei ändern und nach der Aufzeichnung schließen. Wir erstellen die Dateien /etc/systemd/system/keyupdater.service und schreiben:

[Unit]
Description= Starts the IPSec key updating script
Documentation= man:systemd.service
[Service]
Type=oneshot
ExecStart=/opt/ipsec-pubkey/key-updater.sh
[Install]
WantedBy=multi-user.target

Vergessen Sie nicht, die Systemd-Konfigurationen mit sudo systemctl daemon-reload erneut zu lesen und den Pfadeinheiten über sudo systemctl enable keyupdater.path && sudo systemctl start keyupdater einen Autostart zuzuweisen.

Sobald der Remote-Host die Datei mit dem öffentlichen Schlüssel in das Home-Verzeichnis des Keywatcher-Benutzers schreibt und der Dateideskriptor geschlossen wird, startet systemd automatisch den entsprechenden Dienst, der den Schlüssel an den gewünschten Speicherort kopiert und Strongswan neu startet. Der Tunnel wird mit dem richtigen öffentlichen Schlüssel der zweiten Seite installiert.

Sie können ausatmen und das Ergebnis genießen.

Anstelle einer Schlussfolgerung

Wie wir gerade die sahen die ~~Hölle~~ ist IPSec nicht so gefährlich , wie es gemalt ist. Es wurde lediglich eine voll funktionsfähige Konfiguration beschrieben, die derzeit verwendet wird. Auch ohne viel Wissen können Sie ein VPN konfigurieren und Ihre Daten zuverlässig schützen.

Natürlich blieben die Momente der Einrichtung von iptables außerhalb des Geltungsbereichs des Artikels, aber der Artikel selbst erwies sich als bereits umfangreich, und es wurde viel über iptables geschrieben.

Es gibt Punkte in dem Artikel, die verbessert werden können, sei es die Weigerung, den Strongswan-Dämon neu zu starten und seine Konfigurationen und Zertifikate erneut zu lesen, aber ich konnte dies nicht erreichen.

Die Neustarts des Daemons waren jedoch nicht beängstigend: Ein oder zwei Pings zwischen Peers gehen verloren, mobile Clients stellen die Verbindung selbst wieder her.

Ich hoffe, dass die Kollegen in den Kommentaren die richtige Lösung finden.

IPSec Allmächtig