Ich möchte sofort darauf hinweisen, dass ich hier mehr Wert auf die Einrichtung der Zertifizierungsstelle als auf OpenVPN lege.
Bevor wir anfangen, werde ich jemandem sagen, der es mit meinem Beispiel verwenden kann.
Ich hatte die Aufgabe, ein System für ein großes Unternehmen so zu erstellen, dass die OpenVPN-Serverzertifikate nur von einer Person signiert wurden, es gibt viele VPN-Server, für jede Abteilung wurden mehrere VPN-Server eingerichtet. Jedes Mal, wenn ein Mitarbeiter eine sehr schwere Belastung erleidet / verlässt (ganz zu schweigen von Zeitarbeitskräften), gibt es noch mehr Mitarbeiter- (Kunden-) und Kontrollzertifikate (ausstellen / widerrufen). Die Mitarbeiter jeder Abteilung werden vom Abteilungsleiter überwacht, der Zertifikate für neue bzw. alte Mitarbeiter ausstellt oder widerruft.
Für welche Zertifikate und digitalen Schlüssel benötigt wird, wurde viel gesagt und ich werde andere Autoren nicht wiederholen, aber kurz gesagt:
- Um die Zuverlässigkeit zu überprüfen (ein "doppelter Handshake" tritt auf), stellen der Client und der Server sicher, wer sie sind, ob sie sich gegenseitig vertrauen und eine Verbindung herstellen können.
- Verschlüsselung / Entschlüsselung;
- Ausnahmen "Man in the Middle (MITM)", um sicherzustellen, dass jemand keine Nachrichten / Datenverkehr abfängt;
- verschlüsselte Passwörter zu erstellen, was die Sicherheit erhöht und es Angreifern erschwert, auf den Host zuzugreifen.
Das Funktionsprinzip der mehrstufigen CA-Hierarchie besteht darin, dass die oberste CA (RootCA) ihr Zertifikat für einen ausreichend langen Zeitraum für sich selbst signiert (dies ist jedoch eine rein individuelle Angelegenheit), wobei jede nächstniedrigere CA-Hierarchie oder jeder CA-Dienst ihre Zertifikate mit einer übergeordneten CA signiert (üblich) Bürokratie) mit der Maßgabe, dass das untergeordnete Zertifikat eine Gültigkeitsdauer von höchstens der Hälfte der Gültigkeitsdauer des übergeordneten Zertifikats haben darf.
Beim Erstellen einer Zertifizierungsstelle werden zwei Dateien erstellt: ca.crt - der öffentliche Schlüssel und ca.key - der private Schlüssel.
Der private Schlüssel muss geschützt sein und darf nicht an Dritte weitergegeben werden.
Wenn wir eine untergeordnete / signierende Zertifizierungsstelle erstellen müssen, erstellen wir darauf einen privaten Schlüssel und eine Anforderung zum Signieren von RootCA.
Woher wissen Computer und Benutzer auf der ganzen Welt, dass sie einem Dienst oder einer Site vertrauen können? Es ist einfach (theoretisch), der öffentliche CA-Schlüssel (RootCA) wird auf Benutzercomputern abgelegt, und diese Computer vertrauen allen Zertifikaten, die von dieser Zertifizierungsstelle ausgestellt wurden. In der Praxis ist dies sicherlich schwieriger und nicht billig. Aber in Ihrem eigenen Unternehmen ist das ganz einfach.
Für die Implementierung benötigen wir drei Server. In diesem Tutorial verwenden wir Debian 9. Wir benennen die Server entsprechend ihrer Anwendung: OpenVPN, SubCA, RootCA.
Alle Aktionen werden unter dem Benutzer nicht root ausgeführt.
Dazu muss sich Ihr Benutzer in der Sudo-Gruppe befinden.
Wenn sudo nicht auf dem Server installiert ist, melden Sie sich als root an:
# su - root
# apt-get install sudo -y
# usermod -aG sudo username
# exitWir installieren die erforderlichen Dienstprogramme auf allen Servern (Dienstprogramme können je nach Überzeugung und Überzeugung unterschiedlich sein, wget, ufw, vim sind obligatorisch, da ich hier Befehle mit diesen Dienstprogrammen gegeben habe):
# sudo apt-get update
# sudo apt-get upgrade
# sudo apt-get install wget curl net-tools ufw vim -y
# cd ~
# wget -P ~/ https://github.com/OpenVPN/easy-rsa/releases/download/v3.0.4/EasyRSA-3.0.4.tgz
# tar xvf EasyRSA-3.0.4.tgzInstallieren Sie openvpn auf dem OpenVPN-Server:
# sudo apt-get install openvpn -yGehen Sie zum RootCA-Server. Hier müssen wir eine Datei erstellen, aus der easyrsa die Werte der Variablen übernimmt:
# mv ~/EasyRSA-3.0.4 ~/easyrsa/
# cd ~/easyrsa/
# cp vars.example vars
# vim vars
Suchen Sie den Block, löschen Sie # und ersetzen Sie unsere Werte. Um unsere Daten beim Signieren von Zertifikaten nicht einzugeben, schreiben wir sie hier:
#set_var EASYRSA_REQ_COUNTRY "US"
#set_var EASYRSA_REQ_PROVINCE "California"
#set_var EASYRSA_REQ_CITY "San Francisco"
#set_var EASYRSA_REQ_ORG "Copyleft Certificate Co"
#set_var EASYRSA_REQ_EMAIL "me@example.net"
#set_var EASYRSA_REQ_OU "My Organizational Unit"Suchen Sie als Nächstes die folgenden Einstellungen, löschen Sie # und bearbeiten Sie deren Werte. Diese Anweisungen sind für die Lebensdauer von Zertifikaten verantwortlich (die erste gilt für die Lebensdauer des CA-Zertifikats, die zweite für die Lebensdauer des zu signierenden Zertifikats):
#set_var EASYRSA_CA_EXPIRE 3650 #--> 3650
#set_var EASYRSA_CERT_EXPIRE 3650 #--> 1825
Des Weiteren:
# ./easyrsa init-pkiWenn Sie den nächsten Befehl ausführen, werden Sie nach CN gefragt. Sie können die Standardeinstellung beibehalten, es ist jedoch besser, einen Hostnamen-Identifizierungsnamen (RootCA) einzugeben. Der Wert "nopass" bedeutet, dass Sie kein Passwort erstellen müssen:
# ./easyrsa build-ca nopassGehen Sie zum SubCA-Server und führen Sie ähnliche Schritte mit geringfügigen Änderungen aus:
# mv ~/EasyRSA-3.0.4 ~/easyrsa/
# cd ~/easyrsa/
# cp vars.example vars
# vim varsSuchen Sie den Block, löschen Sie # und ersetzen Sie unsere Werte:
#set_var EASYRSA_REQ_COUNTRY "US"
#set_var EASYRSA_REQ_PROVINCE "California"
#set_var EASYRSA_REQ_CITY "San Francisco"
#set_var EASYRSA_REQ_ORG "Copyleft Certificate Co"
#set_var EASYRSA_REQ_EMAIL "me@example.net"
#set_var EASYRSA_REQ_OU "My Organizational Unit"Suchen Sie als Nächstes die folgenden Einstellungen, löschen Sie # und bearbeiten Sie deren Werte:
#set_var EASYRSA_CA_EXPIRE 3650 #--> 1825
#set_var EASYRSA_CERT_EXPIRE 3650 #--> 365
Des Weiteren:
# ./easyrsa init-pkiWenn Sie den nächsten Befehl ausführen, werden Sie nach CN gefragt. Sie können die Standardeinstellung beibehalten, es ist jedoch besser, einen Host-ID-Namen (SubCA) einzugeben. Der Wert "subca" gibt an, dass wir eine untergeordnete Zertifizierungsstelle erstellen und eine Zertifikatsignierungsanforderung erstellen müssen:
# ./easyrsa build-ca subca nopassAls nächstes finden wir die Datei ~ / easyrsa / pki / reqs / ca.req (dies ist genau die Anfrage) und übertragen sie auf den RootCA-Server (Sie können zwei Methoden verwenden: WinSCP und scp):
# scp ~/easyrsa/pki/reqs/ca.req user@ip_RootCA:/tmpGehen Sie zum RootCA-Server und signieren Sie die Anforderung. Bevor wir die Anfrage signieren, müssen wir sie in das Arbeitsverzeichnis importieren. Um das Zertifikat für die untergeordnete Zertifizierungsstelle zu signieren, verwenden wir das Attribut "ca" und den Namen des Zertifikats (Sie können es ca nennen, aber um nicht verwirrt zu werden, nennen wir es den Namen des Servers, auf den wir es signieren, und wenn wir es auf den Server übertragen, benennen wir es um):
# cd ~/easyrsa/
# ./easyrsa import-req /tmp/ca.req SubCA
# ./easyrsa sign-req ca SubCAEine Bestätigung wird angefordert, Sie müssen "Ja" eingeben.
Wir senden das von SubCA signierte Zertifikat zurück.
# scp ~/easyrsa/pki/issued/SubCA.crt user@ip_SubCA:/tmpGehen Sie zum SubCA-Server und verschieben Sie das Zertifikat in das easyrsa-Arbeitsverzeichnis:
# mv /tmp/SubCA.crt ~/easyrsa/pki/ca.crtZu diesem Zeitpunkt haben wir bereits eine Stammzertifizierungsstelle und eine signierte sekundäre Stammzertifizierungsstelle.
Kommen wir nun zum OpenVPN-Server. Beim Einrichten werden einige der vorherigen Schritte wiederholt. Wechseln Sie zum OpenVPN-Server.
# cd ~/easyrsa/
# ./easyrsa init-pkiBeginnen wir nun mit der Erstellung von Zertifikaten zum Signieren. Wir werden einen Diffie-Hellman-Schlüssel (dh.pem / dh2048.pem / dh1024.pem) erstellen, der für den Schlüsselaustausch verwendet wird, und eine HMAC-Signatur (ta.key) erstellen, um die TLS-Integritätsprüfungsfunktion zu verbessern.
Wir werden Zertifikate für den OpenVPN-Server auf RootCA signieren, und wir werden Zertifikate für Benutzer auf SubCA signieren. Erstellen Sie sofort ein Verzeichnis, in dem wir Schlüssel, Zertifikate und Client-Konfigurationen hinzufügen.
# mkdir -p ~/client-configs/files/
# mkdir ~/client-configs/keys/
# chmod 700 ~/client-configs/
# sudo mkdir /etc/openvpn/vpnsrv1/
# ./easyrsa gen-req vpnsrv1 nopass
# ./easyrsa gen-req dumasti nopass
# ./easyrsa gen-dh
# sudo openvpn --genkey --secret ta.key
# cp /home/dumasti/easyrsa/pki/private/dumasti.key ~/client-configs/keys/
# sudo cp /home/dumasti/easyrsa/pki/dh.pem /etc/openvpn/vpnsrv1/
# sudo cp /home/dumasti/easyrsa/ta.key /etc/openvpn/vpnsrv1/
# sudo cp /home/dumasti/easyrsa/ta.key ~/client-configs/keys/
# sudo cp /home/dumasti/easyrsa/pki/private/vpnsrv1.key /etc/openvpn/vpnsrv1/
# scp ~/easyrsa/pki/reqs/vpnsrv1.req user@ip_RootCA:/tmp
# scp ~/easyrsa/pki/reqs/dumasti.req user@ip_SubCA:/tmpGehen Sie zum RootCA-Server und signieren Sie das Zertifikat. Um das Zertifikat für den Server zu signieren, verwenden wir das Attribut "Server" für den Client "Client":
# cd ~/easyrsa/
# ./easyrsa import-req /tmp/vpnsrv1.req vpnsrv1
# ./easyrsa sign-req server vpnsrv1Eine Bestätigung wird angefordert, Sie müssen "Ja" eingeben.
# scp ~/easyrsa/pki/issued/vpnsrv1.crt user@ip_OpenVPN:/tmp
# scp ~/easyrsa/pki/ca.crt user@ip_OpenVPN:/tmp/RootCA.crtGehen Sie zum SubCA-Server und signieren Sie das Zertifikat:
# cd ~/easyrsa/
# ./easyrsa import-req /tmp/dumasti.req dumasti
# ./easyrsa sign-req client dumastiEine Bestätigung wird angefordert, Sie müssen "Ja" eingeben.
# scp ~/easyrsa/pki/issued/dumasti.crt user@ip_OpenVPN:/tmp
# scp ~/easyrsa/pki/ca.crt user@ip_OpenVPN:/tmp/SubCA.crtWir kehren zum OpenVPN-Server zurück und übertragen die signierten Zertifikate in die erforderlichen Verzeichnisse:
# cd /tmpDamit der OpenVPN-Server Clientschlüssel akzeptieren kann, müssen die öffentlichen Schlüssel des Clients und der untergeordneten / signierenden Zertifizierungsstelle in einer Datei zusammengefasst werden:
# cat dumasti.crt SubCA.crt > ~/client-configs/keys/dumasti.crt
# cp /tmp/RootCA.crt ~/client-configs/keys/ca.crt
# sudo mv /tmp/RootCA.crt /etc/openvpn/vpnsrv1/
# sudo mv /tmp/vpnsrv1.crt /etc/openvpn/vpnsrv1/Wir haben jetzt alle erforderlichen Zertifizierungen an den richtigen Stellen. Es bleibt noch die Konfiguration des OpenVPN-Servers und -Clients zu erstellen (jeder hat möglicherweise seine eigenen Überzeugungen und Ansichten in dieser Angelegenheit, aber es wird beispielsweise die folgende Konfiguration geben).
Sie können die Server- und Client-Konfigurationsvorlage verwenden und selbst bearbeiten:
# sudo cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/
# sudo gzip -d /etc/openvpn/server.conf.gz
# cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf ~/client-configs/base.confAber unten werde ich den Inhalt der vorgefertigten Konfigurationsdateien (Symbole; und # Kommentar aus der Zeile) geben:
# sudo cat /etc/openvpn/vpnsrv1.conf
port 1194
proto udp
dev tun
ca vpnsrv1/RootCA.crt
cert vpnsrv1/vpnsrv1.crt
key vpnsrv1/vpnsrv1.key
dh vpnsrv1/dh.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
;push "route 192.168.10.0 255.255.255.0"
;push "route 192.168.20.0 255.255.255.0"
;client-config-dir ccd
;client-config-dir ccd
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
client-to-client
;duplicate-cn
keepalive 10 120
tls-auth vpnsrv1/ta.key 0
key-direction 0
cipher AES-256-CBC
auth SHA256
max-clients 100
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log-append /var/log/openvpn/openvpn.log
verb 3
;mute 20
explicit-exit-notify 1
# cat ~/client-configs/base.conf
client
dev tun
proto udp
remote your_server_ip 1194
;remote my-server-2 1194
;remote-random
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
remote-cert-tls server
;tls-auth ta.key 1
cipher AES-256-CBC
auth SHA256
key-direction 1
verb 3
;mute 20
# script-security 2
# up /etc/openvpn/update-resolv-conf
# down /etc/openvpn/update-resolv-confWir müssen auch die Firewall und die Paketweiterleitung konfigurieren. Es ist möglich, iptables zu konfigurieren, aber hier sehen wir uns ufw an.
Lassen Sie uns zuerst den Namen unserer Schnittstelle herausfinden:
# ip addr Lassen Sie uns die folgenden Ports öffnen (ich habe ssh auf Port 22 und openvpn auf 1194, wenn Sie andere haben, dann handeln Sie entsprechend):
# sudo ufw allow 1194
# sudo ufw allow 22Öffnen Sie als Nächstes die ufw-Konfigurationsdatei und fügen Sie vor dem Start der Filterkette Folgendes ein (ersetzen Sie meine Werte durch Ihre eigenen):
# sudo vim /etc/ufw/before.rules
# START OPENVPN RULES
# NAT table rules
*nat
:POSTROUTING ACCEPT [0:0]
# Allow traffic from OpenVPN client to eth0 (change to the interface you discovered!)
-A POSTROUTING -s 10.8.0.0/8 -o ens192 -j MASQUERADE
COMMIT
# END OPENVPN RULESDavor:
# Don't delete these required lines, otherwise there will be errors
*filterSie müssen standardmäßig die UFW-Weiterleitung von Paketen aktivieren. Suchen Sie die gewünschte Zeile und ändern Sie den Wert "DROP" in "ACCEPT":
# sudo vim /etc/default/ufw
DEFAULT_FORWARD_POLICY="ACCEPT"
Paketweiterleitung konfigurieren. Suchen Sie die Zeile # net.ipv4.ip_forward = 0 oder # net.ipv4.ip_forward = 1, löschen Sie #, wenn der Wert 0 ist, und ändern Sie ihn in 1:
# sudo vim /etc/sysctl.conf
net.ipv4.ip_forward=1
# sudo sysctl -p
# sudo ufw enableAls nächstes starten wir unser VPN:
# sudo systemctl start openvpn@vpnsrv1Überprüfen des Starts:
# ip addrEs sollte eine neue tun0-Netzwerkschnittstelle mit IP 10.8.0.1 geben
# sudo systemctl status openvpn@vpnsrv1Wenn das VPN nach dem Neustart von selbst gestartet werden muss, fügen Sie den Dienst zur automatischen Ausführung hinzu:
# sudo systemctl enable openvpn@vpnsrv1Als nächstes erstellen wir eine Client-Konfiguration. Zuvor haben wir alle Schlüssel und Zertifikate im Verzeichnis ~ / client-configs / keys / abgelegt.
Erstellen wir ein Skript, das die Konfiguration, Schlüssel und Zertifikate in einer Datei user.ovpn sammelt:
# cd ~/client-configs/
# vim configs-maker.sh
#!/bin/bash
# First argument: Client identifier
KEY_DIR=/home/dumasti/client-configs/keys
OUTPUT_DIR=/home/dumasti/client-configs/files
BASE_CONFIG=/home/dumasti/client-configs/base.conf
cat ${BASE_CONFIG} \
<(echo -e '<ca>') \
${KEY_DIR}/ca.crt \
<(echo -e '</ca>\n<cert>') \
${KEY_DIR}/${1}.crt \
<(echo -e '</cert>\n<key>') \
${KEY_DIR}/${1}.key \
<(echo -e '</key>\n<tls-auth>') \
${KEY_DIR}/ta.key \
<(echo -e '</tls-auth>') \
> ${OUTPUT_DIR}/${1}.ovpnDieses Skript nimmt Dateien mit dem Namen auf, den Sie beim Start angegeben haben, und konfiguriert eine Datei im Dateiverzeichnis.
Lassen Sie uns die Datei ausführbar machen:
# chmod +x configs-maker.shLassen Sie es uns laufen:
# sudo ./configs-maker.sh dumastiJetzt übertragen wir die Client-Konfiguration aus dem Verzeichnis / home / dumasti / client-configs / files / auf Ihren Computer
. Starten Sie VPN.
Aus Sicherheitsgründen sollten die Server, auf denen sich die Zertifizierungsstelle befindet, nur zum Signieren von Zertifikaten deaktiviert und aktiviert werden.
Wir werden den Widerruf von Zertifikaten nicht ignorieren. Um das Zertifikat zu widerrufen, gehen wir zu dem CA-Server, auf dem das Zertifikat signiert wurde, und gehen wie folgt vor (z. B. widerrufen wir das Benutzerzertifikat (dumasti), das wir auf dem SubCA-Server signiert haben). Wir gehen zum SubCA-Server:
# cd ~/easyrsa/
# ./easyrsa revoke dumastiSie werden aufgefordert, den Widerruf zu bestätigen. Geben Sie "Ja" ein.
# ./easyrsa gen-crlDie Datei crl.pem wurde generiert. Wir müssen es auf den OpenVPN-Server stellen und die Direktive und den Pfad zur Datei in der Serverkonfiguration hinzufügen:
# scp ~/easyrsa/pki/crl.pem user@ip_OpenVPN:/tmpGehen Sie zum OpenVPN-Server:
# sudo mv /tmp/crl.pem /etc/openvpn/vpnsrv1/
# sudo vim /etc/openvpn/vpnsrv1.confFügen Sie die folgende Zeile hinzu, in der die Schlüssel und Zertifikate geschrieben sind:
crl-verify vpnsrv1/crl.pemStarten Sie openvpn neu:
# sudo systemctl restart openvpn@vpnsrv1Jetzt kann der Dumasti-Client keine Verbindung zum VPN herstellen.
Danke für die Aufmerksamkeit!