Frage zu OpenVPN als Tunnel zum eigenen Netzwerk

A

arcona

Well-Known Member
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:
Code: 
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 schrieb:
H
Oder gibt es die Datei erst, wenn ein Client Zertifikat revoked wird?
Zum Vergrößern anklicken....
OK,
habe es ausprobiert. Die Datei wird wirklich erstellt, wenn man ./revoke-full ausführt.
Allerdings führt das bei mir zu einem Feher:
Code: 
# ./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
 
Zuletzt bearbeitet:
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
 
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?
 
dark_angel schrieb:
Hast du vor dem Ausführen von revoke-full auch ein
# source vars
gemacht?
Zum Vergrößern anklicken....
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
 
Zuletzt bearbeitet:
hawky schrieb:
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
Zum Vergrößern anklicken....

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
 
Zuletzt bearbeitet:
@hawky
Also bei mir reicht ein
Code: 
./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!
 
Zuletzt bearbeitet:
arcona schrieb:
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
Zum Vergrößern anklicken....

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. ;)
 
dark_angel schrieb:
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.
Zum Vergrößern anklicken....
OK, habe ich jetzt getestet. Wenn man ein Client Zertifikat mit
build-key-pkcs12 erstellt, dann werden diese Dateien erstellt:
Code: 
-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
 
Zuletzt bearbeitet:
dark_angel schrieb:
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. ;)
Zum Vergrößern anklicken....
Eine Sperrung kann mittels
Code: 
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
 
Zuletzt bearbeitet:
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.
Zum Vergrößern anklicken....
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.
 
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.
 
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.
 
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.
 
Abacus hat hier: http://www.bsdforen.de/showpost.php?p=224617&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.
 
@XPectIT Die Idee klingt gut, aber ich glaube das klappt nicht da OpenVPN ja keinen http request macht, soweit ich mich nicht irren, das heißt nginx könnte mit dem request dann nix anfangen, weil er nicht weiß wie er damit umgehen sollte.
 
Klingt interessant. Leider werde ich es erst in nem guten Monat ausprobieren können (akuell Klausurphase und dann mache ich mich übern Teich). Werde mir es auf jeden Fall auf meine Liste schreiben.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben