ubuntuusers.de

Silent-PC schrieb:

/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.

Jap Server IP muss dann mit der echten IP ersetzt werden.

Mein größtes problem bei Ubuntu 16.04 war das er VPN server anders gestaret werden muss via systemctl start openvpn@server sollte man vllt erwähnen habe damit stunden verbracht eh ich das rausgefuden habe ^^

Hi!

bzgl. der letzten Änderung: Ich habe den Hinweis in eine Box gepackt, und etwas Wiki-konformer gestaltet, allerdings ist mir nicht ganz klar, welche Schritte denn nun genau von dem Skript ausgeführt werden...

so long
hank

Hallo,

IMHO gehört das gar nicht ins Wiki, ergo: Version zurück setzen.

Grund: klar kann man viele Installationen über ein Skript automatisieren, aber "irgendein" von "irgendwo" empfehlen / verlinken halte ich für falsch und grundsätzlich riskant.

Gruß, noisefloor

Hi!

OK, hab den Hinweis rausgenommen; Link auf das Video ist am Ende des Artikels noch drin, aber das ist imho auch "statthaft"...

so long
hank

Hi. Ich war dabei und wollte OpenVPN installieren. In der vars-Datei habe ich die Einträge, die meinen Bedürfnissen nicht entsprachen frei gelassen. Beim erstellen gab es dann ein Problem und es ging nicht weiter. In der offiziellen Dokumentation von OpenVPN steht, dass diese Einträge nicht freigelassen werden dürfen. Ich würde vorschlagen, dass dieser Hinweis, dass die Einträge unbedingt ausgefüllt sein müssen gerne mit ins Wiki nehmen.

Ich wüsste jetzt nicht, was an

Diese Einträge müssen ggf. auf die eigenen Verhältnisse angepasst werden.

nicht eindeutig genug wäre.

Da steht nirgends "Teile dieser Einträge können leer gelassen werden" oder ähnliches.

Hallo,

auch als nicht-VPN Nutzer / Kenner sehe ich da nicht, dass da in irgendeiner Form suggeriert wird, ein Schlüssel ohne Wert wäre ein gültiger Eintrag. Im Beispiel sind ja auch alle Schlüssel mit Werten belegt.

Gruß, noisefloor

Durch Zufall bin ich auf einen sicherheitsrelevanten Fehler in der Doku gestoßen: Unter Sicherheit erhöhen → Verschlüsselungsalgorithmus ändern wird empfohlen

cipher AES-256-CBC

in den *.conf von Server und Client zu setzen.

Das entspricht seit mindestens OpenVPN v2.4 einem Downgrade des Ciphers. Dort ist inzwischen AES-GCM der empfohlene und auch default. Dies Verfahren ist deutlich sicherer als der Chained Block Cipher und zudem auch multithreadfähig. TLS 1.3 verbietet sogar den CBC.

Ei Auszug aus /etc/openvpn/server.conf

# Select a cryptographic cipher.
# This config item must be copied to
# the client config file as well.
# Note that 2.4 client/server will automatically
# negotiate AES-256-GCM in TLS mode.
# See also the ncp-cipher option in the manpage

Ich kenne mich mit den Ubuntu-Vesionen nicht mehr so gut aus, aber zumindest in Debian-Stretch (und damit wohl auch Ubuntu 18.04?) gilt es und man sollte dies korrigieren.

Hallo ingo2,

danke für den Hinweis, das ist in der Tat etwas unschön.

OpenVPN (Abschnitt „Verschluesselungsalgorithmus-aendern“)

Sowohl in der server.conf als auch in der client.conf ist der Verschlüsselungsalgorithmus als Standard auf "BF-CBC" gesetzt.

Der Artikel ist aktuell für Xenial und Trusty getestet. Könntest du evtl. mal prüfen, wie es unter Xenial aussieht? Dort wird noch die Version 2.3.10 verwendet.

Wenn der obige Satz noch für Xenial und Trusty gilt, kann man ihn entsprechend einschränken. Wenn du den Artikel für Bionic oder Cosmic testen möchtest (optimalerweise Bionic, weil LTS), kann Trusty bei Bedarf auch raus, wenn das einfacher zu testen und zu überarbeiten ist.

Beforge schrieb:

Der Artikel ist aktuell für Xenial und Trusty getestet. Könntest du evtl. mal prüfen, wie es unter Xenial aussieht?

Sorry, hatte es schon oben im Posting angedeutet: Ich habe momentan keine Ubuntu-Inbstallation mehr, alle Rechner laufen unter Debian-Stretch. Nur so bin ich überhaupt darauf gestoßen. Dennoch, das Wiki ist auch da hilfreich und deshalb gehe ich auch ab und zu fremd 😉 . Außerdem, Korrekturen daort anzubringen traue ich mich nicht bei Euren strengen Syntax- und Design-Regeln. Sonst täte es ja auch ein kurzer Hinweis auf die Dokumentation im Paket oder man-page.

Gruß, Ingo

EDIT: Ach ja, und natürlich muß noch die libssl mitspielen und den Cipher unterstützen:

openvpn --show-cyphers

EDIT 2: Aus der offiziellen Doku zu v2.4 von hier zitiere ich:

–auth alg Authenticate data channel packets and (if enabled) tls-auth control channel packets with HMAC using message digest algorithm alg. (The default is SHA1 ). HMAC is a commonly used message authentication algorithm (MAC) that uses a data string, a secure hash algorithm, and a key, to produce a digital signature.The OpenVPN data channel protocol uses encrypt-then-mac (i.e. first encrypt a packet, then HMAC the resulting ciphertext), which prevents padding oracle attacks.

If an AEAD cipher mode (e.g. GCM) is chosen, the specified –auth algorithm is ignored for the data channel, and the authentication method of the AEAD cipher is used instead. Note that alg still specifies the digest used for tls-auth.

Dabei den letzen Abschnitt beachten. Da AES-256-GCM ein "AEAD cipher", d.h. incl. Authentication ist, wird die Option -auth hierfür ignoriert. Ob da ansonmsten wirklich SHA1 noch default ist ???

Moin,

der OpenVPN-Artikel ist mittlerweile etwas veraltet. Er bezieht sich beispielsweise immer noch auf Upstart und folgt nicht ganz der aktuell empfohlenen Herangehensweise.

Da das bei mir gerade alles noch frisch ist, biete ich mich an ihn zu überarbeiten. Gibt es Einwände?

Matthias

Kannst du gerne machen. Ich habe dazu eine Baustelle für dich erstellt. Bitte Fertigstellungsdatum ggf. anpassen.

Zum Testen: Trusty darf gerne ignoriert (und in der getestet-Box entfernt) werden.

Wenn du fertig bist (oder Fragen hast) bitte wieder hier posten.

Viele Grüße

BillMaier

Danke. Im Abschnitt Schlüssel und Zertifikate generieren gibt es eine Grafik, die aktualisiert werden müsste. Besteht da eine Chance an das Rohmaterial zu gelangen, so dass man die nicht ganz neu machen muss?

Wenn, dann nur beim Ersteller der Grafik. Bis wir jetzt aber raus finden, von wem die kommt, hast du sie vermutlich selbst wieder erstellt. Geht zum Beispiel mit https://www.draw.io absolut fix.

Gruß BillMaier

BillMaier schrieb:

Wenn, dann nur beim Ersteller der Grafik. Bis wir jetzt aber raus finden, von wem die kommt, hast du sie vermutlich selbst wieder erstellt.

Zumindest der Upload 2014 kam von Matthias-K. Ich würde mir da allerdings keine großen Hoffnungen machen...