Frage zu OpenVPN als Tunnel zum eigenen Netzwerk

[arcona]

Hallo,

ich bin die Wiki Anleitung: OpenVPN als Tunnel zum eigenen Netzwerk durch gegangen und habe ein solchs VPN aufgebaut.

In der Server Konfiguration taucht jedoch folgende Zeile auf:

crl-verify /root/easy-rsaVPNgw/keys/crl.pem

Wann oder mit welchem easy-rsa Skript erzeugt?
Oder gibt es die Datei erst, wenn ein Client Zertifikat revoked wird?

Grüße
arcona

[arcona]

Zitat von arcona

H
Oder gibt es die Datei erst, wenn ein Client Zertifikat revoked wird?

OK,
habe es ausprobiert. Die Datei wird wirklich erstellt, wenn man ./revoke-full ausführt.
Allerdings führt das bei mir zu einem Feher:

# ./revoke-full Client1
Using configuration from /openvpn/easy-rsa/openssl.cnf
Revoking Certificate 03.
Data Base Updated
Using configuration from /openvpn/easy-rsa/openssl.cnf
Client1.crt: /C=DE/ST=XXX/L=XXX/O=XXX/CN=Client1/emailAddress=me@myhost.mydomain
error 23 at 0 depth lookup:certificate revoked

Die Datei wird aber mit einem Zertifikat erstellt.

Grüße.
arcona

[hawky]

ich habe openvpn unter openbsd 4.8 am start. hier funktionieren btw. nur die 1.0'er scripte!

lt. meinen aufzeichnungen muss man/ich zum revoken so vorgehen:

cd /etc/openvpn/1.0
. ./vars
./revoke-full client1
cd ..
cp 1.0/key/crl.pem .

# vi server.conf und add:
crl-verify crl.pem


nachtrag:
-----------
komischerweise kann ich dann den serverdienst nicht mehr so:
/usr/local/sbin/openvpn --script-security 2 --config server.conf --daemon

sondern muss ihn so:
cd /etc/openvpn && /usr/local/sbin/openvpn --script-security 2 --config \
server.conf >/var/log/openvpn 2>&1 &

starten, damit es auch werkelt.

--hawky

[dark_angel]

Hi arcona,

ja die Datei wird erst beim revoken des ersten Zertifikates erstellt. Das sollte ich noch mal in den Artikel mit aufnehmen.

Hast du vor dem Ausführen von revoke-full auch ein
# source vars
gemacht?

[arcona]

Zitat von dark_angel

Hast du vor dem Ausführen von revoke-full auch ein
# source vars
gemacht?

Ja, habe ich.

Hast Du schon mal ./build-key-pkcs12 ausprobiert, dann wird, wenn ich alles richtig verstanden habe das CA Zertifikat, Client Zertifikat und Client Schlüssel in eine Datei gepackt? Spart ein wenig Kopierarbeit.

Grüße.
arcona

[arcona]

Zitat von hawky

cd /etc/openvpn/1.0
. ./vars
./revoke-full client1
cd ..
cp 1.0/key/crl.pem .

# vi server.conf und add:
crl-verify crl.pem




--hawky

Muss ich mal probieren, ich dachte, soweit ich mich gerade eingelesen habe, dass ./revoke-full client die crl.pem aktualisiert. Müßte das nicht ausreichen, damit der Server den Client ablehnt?

Grüße.
arcona

[arcona]

@hawky
Also bei mir reicht ein

./recoke-full client

um das Zertifikat zu sperren.

Kann man das eigentlich irgendwie wieder rückgängig machen?
Wird etwa nur in der index.txt das V in ein R geändert?

Grüße.
arcona
EDIT: Beitrag geändert, hatte vorher Unsinn geschrieben!

[dark_angel]

Zitat von arcona

Ja, habe ich.

Hast Du schon mal ./build-key-pkcs12 ausprobiert, dann wird, wenn ich alles richtig verstanden habe das CA Zertifikat, Client Zertifikat und Client Schlüssel in eine Datei gepackt? Spart ein wenig Kopierarbeit.

Grüße.
craano

Hmm komisch. Habe es vorhin nochmal bei mir ausprobiert und es klappt 1a. :S
Wird das Zertifikat trotzdem gesperrt oder ist es immer noch aktiv?

Ne habe ich noch nicht. Weiß auch nicht, ob OpenVPN das dann auch verarbeiten kann. Falls es funktioniert wäre das recht schick. Dann müsste man dem Client nur eine Datei zukommen lassen statt 3.


Ob ne Sperrung rückgängig gemacht werden kann weiß ich nicht. Ich würde sagen ausprobieren und schauen, ob es klappt wäre hier angebracht.

[arcona]

Zitat von dark_angel

Hmm komisch. Habe es vorhin nochmal bei mir ausprobiert und es klappt 1a. :S
Wird das Zertifikat trotzdem gesperrt oder ist es immer noch aktiv?

Ne habe ich noch nicht. Weiß auch nicht, ob OpenVPN das dann auch verarbeiten kann. Falls es funktioniert wäre das recht schick. Dann müsste man dem Client nur eine Datei zukommen lassen statt 3.

OK, habe ich jetzt getestet. Wenn man ein Client Zertifikat mit
build-key-pkcs12 erstellt, dann werden diese Dateien erstellt:

-rw-r--r--  1 root  wheel  3956 Jan 28 18:41 Client4.crt
-rw-r--r--  1 root  wheel   704 Jan 28 18:41 Client4.csr
-rw-------  1 root  wheel   891 Jan 28 18:41 Client4.key
-rw-------  1 root  wheel  3061 Jan 28 18:41 Client4.p12

Also genauso wie bei build-key, nur das man die .p12 Datei zusätzlich erhält. In dieser Datei ist das Client Zertfikat, der Client Key und die ca.crt enthalten. Es genügt also nur diese eine Datei auf den Client zu kopieren.
Wenn jetzt mittels "revoke-full Client4" das Zertifikat gesperrt wird, dann kann der Client sich auch nicht mehr mit der Client4.p12 anmelden.

Aber Auchtung: Bestehende Verbindungen werden nicht gekappt, sondern bleiben bestehen! Nur der Tunnelaufbau wird nicht mehr möglich sein.

Grüße.
arcona

[arcona]

Zitat von dark_angel

Ob ne Sperrung rückgängig gemacht werden kann weiß ich nicht. Ich würde sagen ausprobieren und schauen, ob es klappt wäre hier angebracht.

Eine Sperrung kann mittels

openssl ca -gencrl

rückgängig gemacht werden. Das bekomme ich aber in Kombination mit easy-rsa noch nicht so wirklich hin. Vieleicht kann das noch mal jemand anderes testen.

Ich habe aber einen kleinen Workaround, wie man ein Zertifikat rückgängig machen kann:

1. In der easy-rsa/keys/index.txt muss die Zeile für das entsprechende Zertifikat editiert werden. Das R (revoked) wieder in ein V (valid?) ändern und das Löschdatum entfernen. Das Löschdatum ist der UNIX-Timestamp, inklusive das angehängten Buchstaben, in der 3 Spalte.
2. Nun einfach über ein anderes Zertifikat, welches schon gesperrt war und auch gesperrt bleiben soll, ein ./revoke-full laufen lassen. Dann meckert openssl zwar, dass ein bereits gesperrtes Zertifikat erneut gesperrt werden soll, aber es wird eine neue crl.pem entsprechend den Einträgen in der index.txt erstellt.

Grüße
arcona

[XPectIT]

Eine kleine Anmerkung zum OpenVPN-Howto, da der Autor den Tunnel "aus jedem Netz heraus" aufbauen möchte.

Damit Portsperren in fremden Netzen relativ einfach zu handhaben sind wird der OpenVPN Server auf dem Port 80 lauschen und das TCP Protokoll nutzen. Damit sollte eine Verbindung in jedem Netz zustande kommen, in dem das Surfen erlaubt ist.

Gibt das nicht Probleme mit transparenten Proxies? Wenn man den Port auf 443 (also https) ändert, kommt die Verbindung auch durch einen Proxy "hindurch" zustande.

[dark_angel]

Ist ne sehr gute Anmerkung. Tatsächlich habe ich den Tunnel noch nie mit nem transparenten Proxy getestet. Müsste mir mal n Netz suchen, wo einer steht und das ausprobieren. Nutze das VPN nur für Urlaub, in Hotspots und wenn ich an der Uni bin. Dort bin ich noch nicht (wissentlich) auf transparente Proxies gestoßen.
Falls jemand Zugang zu einem Netz mit transparentem Proxy hat wäre ich froh, wenn dieser das mal ausprobieren würde.

Ich persönlich habe auch net den Port 443 genommen, weil dort schon mein Apache drauf lauscht und ich dort https unbedingt benötige.

[XPectIT]

Mit einem Linux-OpenVPN-Gateway kann ich bestätigen, dass es, beim Vorhandensein eines transparenten Proxies, auf Port 80 nicht geht und auf 443 läuft.

Deshalb liegt die Vermutung nahe, dass es auch mit *BSD geht. Genaueres kann ich Anfang Mai sagen, da bin ich wieder in einer Schulungsumgebung die für die Teilnehmer nur http und https zulässt und deren Datenverkehr nach Außen geproxiet wird.

[Crest]

Port 53/UDP ist auch immer einen Versuch wert. Mehr als "restriktives" Netz lässt Port 53/UDP ungestört durch und hält es für DNS Traffic. Es besteht natürlich die Gefahr das es einem Ratelimiting oder DNS Zwangsproxy unterliegt. Dafür hat man keine hässlichen Probleme mit TCP in TCP sollte es funktionieren. Ein Shellscript das erst Port 53/UDP testet (ping, iperf?) und auf Port 443/TCP zurückfällt bietet sich hier an.

[XPectIT]

Abacus hat hier: http://www.bsdforen.de/showpost.php?...17&postcount=8 geschrieben, dass nginx zum "verteilen" von http-requests auf zwei Jails verwendet wird.
Könnte man das auch:
Mit https machen und für einen Tunnelaufbau über OpenVPN nutzen?
Dann muss natürlich in dem Fall nginx das Paket annehmen, aber da es kein http-request ist, es nicht verwerfen und möglichst unverändert an einen dahinterliegenden openvpn-server weiterschicken.

Also je nachdem ein Browser oder ein vpn-client etwas an den (in diesem Fall) nginx schickt, den Verkehr so weiterleiten, dass entweder eine Webseite ausgeliefert wird, oder der vpn-tunnel aufgebaut wird.