noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29041
Wohnort: WW
|
Hallo, ich habe die letzte Änderung von Mytril zurückgesetzt. Grund: inhaltlich IMHO ok, aber was Wortwahl und Syntax angeht so Wiki-unkonform, dass eine Korrektur "on the fly" schwierig gewesen wäre. Der Nutzer wurde per PN informiert. Gruß, noisefloor
|
Mytril
Anmeldungsdatum: 24. September 2012
Beiträge: 55
|
Hallo, ich würde meinen Teil gerne verbessern wenn ich darf. Verschiebt den Artikel dafür bitte in die Baustelle.
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29041
Wohnort: WW
|
Hallo, Artikel ist in der Baustelle. Das Fertigstellungsdatum bitte ggf. anpassen. Und wenn du fertig bis hier nochmal kurz Bescheid sagen. Gruß, noisefloor
|
Mytril
Anmeldungsdatum: 24. September 2012
Beiträge: 55
|
Hallo nochmal, ich glaube ich bin fertig... bitte schaut mal drüber.
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29041
Wohnort: WW
|
Hallo, Danke für die Ergänzung. Habe noch ein paar Sachen korrigiert. @Mytril: für zukünftige Edits - sowas wie sudo nano irgendwas kommt grundsätzlich nicht im Wiki vor. An so Stellen immer auf den Wissensblock verweisen. Der Schritt muss ja nicht mit nano gemacht werden, geht mit jedem anderen Editor auch. Inhaltlich kann ich zur Ergänzung nichts sagen - klingt aber plausibel 😉 Gruß, noisefloor
|
Mytril
Anmeldungsdatum: 24. September 2012
Beiträge: 55
|
Dann könnte der Artikel nun zurückverschoben werden...
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29041
Wohnort: WW
|
Hallo, Artikel ist wieder im Wiki - Danke für die Ergänzung ☺ Gruß, noisefloor
|
hyde123
Anmeldungsdatum: 22. Juli 2015
Beiträge: 1
|
Zitat Artikel: tar -cf client1.key client1.crt ca.crt
Stehe ich auf dem Schlauch oder ist das Unsinn? Mit diesem Befehl wird die vorher erstellte client1.key Datei doch durch das tar Archiv mit dem Namen client1.key ÜBERSCHRIEBEN, oder nicht? Ich glaube, es sollte tar -cf client1.tar client1.key client1.crt ca.crt heißen.
|
B601
Anmeldungsdatum: 10. Juli 2009
Beiträge: Zähle...
Wohnort: Wien
|
Hallo, da ist noch ein Fehler beim Sperren von Zertifikaten drinnen. Der Eintrag: crl-verify ./easy-rsa2/keys/crl.pem
in server.conf funktioniert so nicht, wenn man - aus Sicherheitsgründen - den OpenVPN-Prozess auf nouser:nogroup deeskaliert, da crl.pem als root angelegt wird und die Zugriffsrechte 600 hat. Der OpenVPN-Prozess kann also nicht darauf zugreifen und beendet sich mit einem entsprechenden Fehler. Selbst, wenn man die Zugriffsrechte auf 644 setzt, gibt es Probleme. Der Prozess startet dann zwar, aber anschließend ist keinerlei Verbindung mit dem VPN mehr möglich! Korrekt vorgegangen, müssen die Datei crl.pem ins /etc/openvpn -Verzeichnis kopiert, die Zugriffsrechte gesetzt und die Zeile in server.conf entsprechend angepasst werden.
|
lock-3
Anmeldungsdatum: 11. Dezember 2011
Beiträge: 82
|
hyde123 schrieb: Zitat Artikel: tar -cf client1.key client1.crt ca.crt
Stehe ich auf dem Schlauch oder ist das Unsinn? Mit diesem Befehl wird die vorher erstellte client1.key Datei doch durch das tar Archiv mit dem Namen client1.key ÜBERSCHRIEBEN, oder nicht? Ich glaube, es sollte tar -cf client1.tar client1.key client1.crt ca.crt heißen.
Ist mir gestern auch aufgefallen. Du hast natürlich recht, zu dem Befehl gehört die Angabe eines Archivnamens das angelegt wird:
tar -cf client1.tar client1.key client1.crt ca.crt Änderst du das entpsrechend bzw. soll ich es ändern? Grüße, Locke
|
Mytril
Anmeldungsdatum: 24. September 2012
Beiträge: 55
|
lock-3 schrieb: hyde123 schrieb: Zitat Artikel: tar -cf client1.key client1.crt ca.crt
Stehe ich auf dem Schlauch oder ist das Unsinn? Mit diesem Befehl wird die vorher erstellte client1.key Datei doch durch das tar Archiv mit dem Namen client1.key ÜBERSCHRIEBEN, oder nicht? Ich glaube, es sollte tar -cf client1.tar client1.key client1.crt ca.crt heißen.
Ist mir gestern auch aufgefallen. Du hast natürlich recht, zu dem Befehl gehört die Angabe eines Archivnamens das angelegt wird:
tar -cf client1.tar client1.key client1.crt ca.crt Änderst du das entpsrechend bzw. soll ich es ändern? Grüße, Locke
Habe es nun geändert... Im Artikel fehlt vielleicht noch die Darstellung der Möglichkeit, mehrere virtuelle Netze mithilfe von mehreren server.conf Datein zu erstellen. Sollten wir das aufnehmen, was man dazu ändern sollte?
|
Silent-PC
Anmeldungsdatum: 2. November 2007
Beiträge: 20
|
Hallo alle! OpenVPN ist eine feine Sache.
Allerdings war mir persönlich die vorhandene Dokumentation an vielen Stellen zu ungenau.
Beim Umsetzen einiger VPN-Lösungen bin ich immer wieder an verschiedenen Stellen gescheitert. Es gab bei mir oft mehrere Probleme und Fragen die häufig auftraten:
tun/tap - wo ist nun genau der Unterschied? Und auch wenn man es wusste, war nicht immer 100% klar muss ich den Befehl/Parameter nun aktivieren ja oder nein? Meiner Meinung nach sollte man die Dokumentation splitten. Ich teste und betreibe derartige Lösungen gerne in VMs. Da man diese leichter komplett sichern kann. Leider stieß ich hier insbesondere beim Bridging ganz schön Probleme (ich sag nur Promiscuous-Mode). Weiterhin wollte ich ein System aufsetzen welches vorerst garantiert 100% sicher ist. Ich wollte also möglichst die stärkste Verschlüsselung einsetzen auch wenn dies anderswo oft belächelt und als Unsinn abgestempelt wird. Weiterhin fehlte mir eine Protokollierung der Zugänge. Was nützt der tollste sicherste Zugang wenn dieser missbraucht wird und man davon nichts mitbekommt?
Aus diesen und noch weiteren Gründen entschloss ich mich dazu eine eigene Dokumentation zu schreiben.
Diese Dokumentation behandelt nun tun (routing) zu 100% getrennt von tap (bridging), des weiteren wird auch Logging mit berücksichtigt.
Ich habe diese Lösung jetzt mehrfach unter Ubuntu Server 14.04 aufgesetzt und diese funktioniert unter VirtualBox zu 100%.
Es ist eine sozusagen Schritt-für-Schritt Anleitung - nahezu 100% DAU sicher.
Da diese Lösung wirklich gut geworden ist möchte ich euch diese jetzt hier vorstellen.
An die Anpassung des Wiki-Artikels habe ich mich nicht getraut - gern könnt ihr Teile meiner Dokumentation übernehmen. Hier nun die Links: tun/NAT : routing _: Layer 3 : Protokollierung
http://ctaas.de/openvpn_routing tap/NAT : bridging : Layer 2 : Protokollierung
http://ctaas.de/openvpn_bridging Ich hoffe das ist so ok.
Falls nicht dann löschen. PS:
Die Darstellung der Dokumentation wurde für alle erdenkliche Systeme optimiert, sie ist immer perfekt lesbar - egal ob PC, Smartphone, Tablet oder Drucker.
Neuere Ubuntu-Versionen und kompatible Systeme wie z. B. Linux Mint oder Raspberry werden auch unterstützt (Ubuntu basierende Systeme).
|
sciencejedi
Anmeldungsdatum: 5. Juni 2016
Beiträge: 3
|
Hallo, kleine Anmerkung nur: Bei der OpenVPN Version 2.3.11 war DH2048 in der vars-Datei und auch in der server.conf-Datei standardmäßig angegeben. Viele Grüße
|
Red-Killer
Anmeldungsdatum: 21. Februar 2013
Beiträge: 21
|
Ab ubuntu 16.04
musste ich den server starten via:
sudo systemctl start openvpn@server Damit Internet verbindung richtig lief habe ich: /etc/sysctl.conf
net.ipv4.ip_forward=1 eingetragen und in
/etc/rc.local
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j SNAT --to-source SERVER_IP
und in
Server.conf:
push "redirect-gateway def1 bypass-dhcp"
Vllt. läuft es so ja auch bei wenn, viel spaß beim testen ☺
|
Silent-PC
Anmeldungsdatum: 2. November 2007
Beiträge: 20
|
Red-Killer schrieb: Ab ubuntu 16.04
musste ich den server starten via:
sudo systemctl start openvpn@server Damit Internet verbindung richtig lief habe ich: /etc/sysctl.conf
net.ipv4.ip_forward=1
Das Steht in meiner Dokumentation so unter Punkt 12.
eingetragen und in
/etc/rc.local
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j SNAT --to-source SERVER_IP
Kurze Frage meinerseits:
Muss man 'SERVER_IP' durch die echte Server IP-Adresse ersetzen, oder lässt man das so als Begriff stehen?
Bin mit iptables nicht so 100% fit. Fakt ist das die erste Netzwerkschnittstelle bei neueren Versionen meist nicht mehr 'eth0' heist.
Sondern diese trägt je nach dem welchen Anschluss/Interface die Netzwerkkarte hat einen anderen Namen.
Sprich ob die Karte über USB/PCIE usw. angeschlossen wurde, jede Variante hat einen anderen Namen.
Z. B. 'enp0S3' Die Zeile aus Punkt 13 (siehe meiner Dokumentation):
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
müsste demnach dann so lauten:
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o enp0S3 -j MASQUERADE Welche Anschlüsse vorhanden sind sollte man mittels 'ifconfig' sehen.
und in
Server.conf:
push "redirect-gateway def1 bypass-dhcp"
Das steht auch so in meiner Dokumentation.
Dies sorgt dafür das die DNS-Anfragen komplett über den Tunnel gehen. Ohne diesen Eintrag sollte die Verbindung auch gehen.
Man kann die entsprechenden gegenstellen, dann aber ggf. nur über die IP-Adresse erreichen.
Vllt. läuft es so ja auch bei wenn, viel spaß beim testen ☺
Schön das es läuft...
|