OpenVPN wieder einrichten

[Rüdiger Kupper]

Nach der Umstellung auf linuxmuster.net 6 mit ipfire musste der OpenVPN-Zugang über den ipfire wieder eingerichtet werden. Die Aufgabe ist bereits abgeschlossen, dieses Ticket dient der Dokumentation.

[Rüdiger Kupper]

Mail von bau

Juhu, OpenVPN tut nun auch wieder.
War eigentlich (wie immer am Ende) ganz einfach.
Die Zertifikate und dir Ordnerstrukur sind bei IPCop und IpFire gleich.

[Rüdiger Kupper]

Hallo Jens,

ich habe herausgefunden, woher meine Probleme mit dem VPN stammten. Ich habe zwei Änderungen an der OpenVPN-Konfiguration des ipfire vorgenommen (da ich das Passwort für's Web-Interface nicht zu kennen schien, habe ich direkt die /var/ipfire/ovpn/server.conf editiert und den Dienst danach manuell neu gestatret).

DNS

Als Nameserver war 10.32.1.1 eingetragen. Ich habe das auf 10.32.1.251 geändert:

push "dhcp-option DNS 10.32.1.251"

Grund:

• der paedml löst einige wichtige Namen nicht auf, z.B. "wpad" und "ltsp1-7". 10.32.1.251 tut das. Das war der Grund, dass die Proxy-Autokonfiguration über das VPN nicht funktionierte.
• 10.32.1.251 ist auch auf den LtspServern als DNS eingetragen. Die Nutzer erhalten damit nun über das VPN genau die gleiche Namensauflösung wie wenn sie lokal an einem Client eingeloggt sind.

Route und Subnetz

Unser VPN war so konfiguriert, dass sämtlicher Netzverkehr darüber lief, wenn man damit verbunden war. Die Verbindung war dann also in allen Aspekten so, als säße man lokal an der Schule.
Das heißt, dass z.B. auch alle http-Anfragen, die der Nutzer in seinem Browser zuhause macht, über das VPN an die Schule gehen und dann von dort aus über unser Gateway nach draußen. Man hat es daran gemerkt, dass man sich am Proxy authentifizieren musste, und dass die Google-Seiten nicht erreichbar waren.

Das ist gar nicht sonderlich wünschenswert. Verbindet sich ein Nutzer von zuhause mit unserem VPN, so sollen alle Anfragen in das grüne Netz darüber laufen, aber doch bitte nicht seine gesamte Surfaktivität.
Man kann dem VPN sagen, dass nur bestimmte Anfragen über das VPN laufen sollen, indem man den VPN-Clients eine Route mitteilt:

push "route 10.32.0.0 255.255.240.0"

Nun muss man dem Ubuntu-OpenVPN-Client noch sagen, dass er diese Route auch beachten soll:
In der VPN-Konfiguration von Ubuntu findest Du unter
VPN-Verbindungen-->VPN konfigurieren-->bau-TO-IPCOP-RED-->IPv4-Einstellungen-->Routen die Option "Diese Verbindung nur für Ressourcen dieses Netzwerks benutzen". Hier einen Haken setzen.
Ab jetzt laufen nur noch Anfragen an das Subnetz 10.32.0.0/255.255.240.0 über das VPN, alle anderen laufen über das gewohnte Gateway des Nutzers. Man merkt es daran, dass man sich in seinem Browser nicht mehr authentifizieren muss und dass die Google-Seiten erreichbar sind.

Das ganze hatte mit dem alten IPCop auch funktioniert, der muss also diese "push route" gehabt haben. Über den ipfire klappte es bisher nicht, daher habe ich erstmal gar keine Daten rüberbekommen.

Die Option "nur für Ressourcen dieses Netzwerks benutzen" ist leider in den OpenVPN-Konfigurationen, die man aus der Schulkonsole herunterlädt, nicht aktiviert. Wäre gut, wenn wir das ändern könnten. Sonst generieren wir unnötig Traffic, falls mal ein paar mehr Nutzer anfangen, das VPN zu nutzen.

[bau]

DNS

Als Nameserver war 10.32.1.1 eingetragen. Ich habe das auf 10.32.1.251 geändert:

push "dhcp-option DNS 10.32.1.251"

Grund:

• der paedml löst einige wichtige Namen nicht auf, z.B. "wpad" und "ltsp1-7". 10.32.1.251 tut das. Das war der Grund, dass die Proxy-Autokonfiguration über das VPN nicht funktionierte.
• 10.32.1.251 ist auch auf den LtspServern als DNS eingetragen. Die Nutzer erhalten damit nun über das VPN genau die gleiche Namensauflösung wie wenn sie lokal an einem Client eingeloggt sind.

Das war keine gute Idee, denn nun versucht mein Firefox immer über den 10.32.1.251 als proxy ins Netz zu gelangen, da bringt mir die Option "Diese Verbindung nur für Ressourcen dieses Netzwerks benutzen" auch nichts mehr :-( -> Bitte rückgängig machen und die benötigten DNS/IP-Einträge auf paedml in /etc/bind9/db.linuxmuster eintragen!

[Rüdiger Kupper]

Ah, verstehe, Du hast in Deiner Firefox-Konfiguration stehen "Proxy automatisch erkennen", und da der Name "wpad" aufgelöst wird, geht Dein Firefox über den Proxy raus.

Ja, stimmt, der Name "wpad" sollte nicht aufgelöst werden, wenn "Diese Verbindung nur für Ressourcen dieses Netzwerks benutzen" gesetzt ist. Ist die Option nicht gesetzt, sollte er allerdings aufgelöst werden, sonst kommt man mit dem Browser gar nicht mehr nach draußen, während das VPN besteht.

Hm. Knifflig.

Okay, ich setze den DNS-Eintrag erst mal auf 10.32.1.1 zurück. Die Namenseinträge in /etc/bind9/db.linuxmuster mache ich dann bei Gelegenheit.

[Rüdiger Kupper]

Okay, jetzt sollte Dein Firefox wieder glücklich sein.

[Rüdiger Kupper]

TODO

Namenseinträge in paedml:/etc/bind9/db.linuxmuster mit denen auf 10.32.1.251 abgleichen (außer "wpad").

[Rüdiger Kupper]

Okay, ich habe die folgenden Einträge in paedml:/etc/bind9/db.linuxmuster hinzugefügt (kopiert vom alten paedml). Bitte prüfen, ob das okay ist:

moodle       IN A 129.143.68.248
proxyl       IN A 10.32.1.250
proxys       IN A 10.32.1.251
rembos       IN A 10.32.1.252
proxmoxs     IN A 10.32.1.253

ltsp1        IN A 10.32.2.1
ltsp2        IN A 10.32.2.2
ltsp3        IN A 10.32.2.3
ltsp4        IN A 10.32.2.4
ltsp5        IN A 10.32.2.5
proxmoxltsp6 IN A 10.32.2.106
ltsp6        IN A 10.32.2.6
ltsp7        IN A 10.32.2.7

cisco0027    IN A 10.32.3.1
cisco118     IN A 10.32.3.2
cisco138     IN A 10.32.3.4
cisco145     IN A 10.32.3.5
cisco006     IN A 10.32.3.6
cisco128     IN A 10.32.3.7