OpenVPN-Paket

[MaxMuster]

Wenn du kein Netz hast, müsstest du m.E. nach den Client gar nicht eintragen, dann sollte er eine belibige IP bekommen, und die sollte auch Problemlos erreichbar sein.
Auf der "sicheren Seite" bist du natürlich, wenn du genau das machst, was du vorgeschlagen hast, die VPN-IP des Clients mit /32 als Netz beim Client eintragen. Dann bekommt der auch die Routen zu den anderen Netzen mitgeteilt (soweit die Theorie, wenn ich dabei alles richtig gemacht habe ;-)). Fehler bitte gleich melden.

Jörg

 

[knox]

@knox: Meinst du [...] das Starten mehrerer Instanzen von OpenVPN? [...] hätte ich schon mehr Bedenken, zum einen wegen der Ressourcen, zum anderen, wie diese dann "auseinanderhaltbar" sein sollten

Ich meinte zwei oder mehr seperate OpenVPN Konfigurationen, die parallel laufen.
OpenVPN "unterscheidet" die anhand der Dateinamen und kommt damit an sich prima klar.
Ich hab auch schon erfolgreich zwei OpenVPN Prozesse parallel auf meiner 7170 laufen gehabt. Es ist nur ein ziemlicher Aufwand, das in die ds-mod Package Logik zu übertragen...

 

[m.kress]

Hi,
falls man an die Box aufgrund eines Konfigfehlers des VPN Paketes nicht mehr erreicht, wie kann man am einfachsten den OpenVPN für den nächsten Reboot abschalten (ggf. über den adam2 ftp)?
Gruß
Markus

 

[wengi]

Ich kann Deine Frage zwar nicht direkt beantworten, aber für solche Fälle sind bei mir alle Boxen mit dyndns und ssh ausgestattet.

wengi

 

[m.kress]

@wengi:
Das meinte ich nicht. Ich habe aus unwissendheit die in "Netzwerksegment (nur für TUN-Server)" das Netz des LANs eingetragen. Die Box war darauf hin nicht mehr erreichbar (auch nicht per ssh). Da ich aber zum Glück VPN (nich) nicht automatisch starte, konnte ich mich Stromziehen retten. Wäre VPN auf autostart, würde ich womöglich nicht mehr drankommen. Nur ein Flashen ohne VPN über ADAM2 würde helfen. Jedoch wären evtl. die Einstellungen beim erneuten Flash mit VPN wieder vorhanden.

Gruß
Markus

 

[wengi]

Es geht also um eine Fehlkonfiguration, die die komplette Box unerreichbar macht? Dann müsste man ( -> MaxMuster ) eine Plausibilitätsprüfung ins Webinterface einbauen.

Wenn "Netzwerksegment (nur für TUN-Server)" = LAN Segment dann Fehlermeldung.

Ich hab jetzt natürlich nicht überprüft, ob die Box danach wirklich unerreichbar ist, will ich aber auch nicht

wengi

 

[MaxMuster]

Ja, es gibt mehrere Möglichkeiten der "Verkonfiguration", wenn du per VPN-Konfig irgendwie dein LAN nach woanders hinkonfigurierst.
Diesen Fehler (das eigene LAN-Segment eintragen, was dann dazu führt, dass er die Antworten für das LAN dann ins VPN routet) könnte man noch abfangen, das gleiche würde dir aber auch passieren, wenn du die Client-Konfiguration nur ein klein wenig verdrehst und das Netz der Clients vertauscht. Dann wolltest du z.B. dem Client1 "sagen", er solle das LAN von Client2 über das VPN schicken, sagst ihm aber, er soll das Netz von Client1 übers VPN schicken (also sein eigenes). Das könntest du in der Config ja nicht erkennen...

Weil die Routing-Einstellungen aber vom Programm selbst initiiert werden, sehe ich da keine großen Möglichkeiten, das wirklich Sinnvoll zu verhindern. Allerdings ist ja der Server "gefährdeter", denn der Client kriegt die Infos ja nur, wenn das VPN aufgebaut wird, was man ja zur Not noch unterbinden kann.

Kommt drauf an, wieviel Aufwand eine Prüfung wäre, ich werde es im Hinterkopf behalten.


Jörg

 

[m.kress]

Mir ging es eigentlich gar nicht um eine Plausibilitätsprüfung, aber sinnvoll wäre sie sicherlich. Aber wenn's doch mal passiert (es muß ja gar nicht mal durchs VPN sein). Passt zwar nicht 100%ig zum Thread, aber interessieren tut's mich doch.

 

[MaxMuster]

Soweit ich weiß, bleiben alle ds-mod Einstellungen auch beim Flashen vorhanden. Vermutlich hätte da nur ein Recover geholfen (da ist dann der DS-Mod ja nicht mehr aktiv), oder der Zugriff über die Not-IP, wenn die im anderen Netz ist. Alternativ könnte man natürlich einen dsmod ohne OpenVPN über das pushfirmware Skript einspielen und dann die Konfig ändern.

Jörg

 

[m.kress]

Hab ich mir auch so gedacht.

 

[wengi]

@Jörg
Mir ist gerade aufgefallen, dass in Deiner letzten Config-Version "verb 6" bzw. export OPENVPN_LZO_VERBOSE='6' gesetzt ist.
Dies sollte entweder über das WebIF einstellbar sein oder wieder auf den Standard 3 zurückgesetzt werden.

"verb 6" flutet den Syslog doch etwas zu viel.

wengi

 

[MaxMuster]

... ich weiss es jetzt nicht mehr genau, das sollte aber bei aktivem "Debug-Mode" einstellbar sein?!?
Sinnvoll ist natürlich, das ohne debug "zurückzudrehen". Ich werde heute oder morgen mal meinem "aktuellen Stand" posten (noch ohne die "Mehrfach-Konfig", die knox vorgeschlagen hat. Da bin ich noch am Kämpfen, wie ich das am besten realisiere, damit es auch in der "übersichtsseite" auftaucht, die sonst ja keine echte Übersicht wäre...)

Jörg

 

[MaxMuster]

So, hier mal wie "versprochen" mein aktueller Stand (noch als "Arbeitsversion").

Damit sollte auch schon "ein Anfang" der von knox vorgeschlagenen "Multi-Config-Version" möglich sein. Mein Ansatz (wenns was sinnvolleres gibt, immer her damit) war, die Dateien Mehrfachnutzbar zu machen. Da ginge wie folgt:

Anlegen/Kopieren von folgenden Dateien:

/mod/etc/init.d/rc.openvpn-config2      (Kopie von rc.openvpn-lzo, "lzo" durch "config2" ersetzt)

/mod/etc/default.openvpn-config2/      (Anlegen, darin 
- openvpn-config2.cfg/_conf als "lzo-Kopie", auch mit LZO durch CONFIG2 ersetzt
- die key Dateien kopiert

/mod/usr/lib/cgi-bin/openvpn-config2.cgi    als Symlink auf /mod/usr/lib/cgi-bin/openvpn-lzo.cgi


modreg cgi  openvpn-config2 ovpn-Client2
modconf load openvpn-config2

Wenn man dann noch das "save-cgi" in /usr/mww/cgi-bin/save.cgi mit dem beiliegenden "übermountet" kann man zumindest schonmal die zweite GUI zum Speichern nutzen.
Wie gesagt, ein "Arbeitsstand", ich würde zumindest das "_conf" Skript auch "Aufrufsabhängig" machen wie das cgi, so dass ein Symlink reicht.

Bleiben z.B. die Fragen, ob man mehrere Key/Zertifikats-Sätze vorsehen sollte oder nicht und wie ich dann den zusätzlichen Dienst in die "Dienste-Seite" reinbekomme...

Jörg

 

[EasyRider]

MTU ändern, Port für OpenVPN

Ich beschäftige mich seit Kurzem mit dem OpenVPN Paket und habe mich zunächst in das Thema eingelesen. Dabei ist mir aufgefallen, dass in den gefundenen (Beispiel-) files server.conf und client.conf immer wieder die mtu von 1500 durch fragment = 1300 begrenzt wird. Selbst in den man-pages von openvpn wird diese Kombination ergänzt durch mssfix vorgeschlagen, da der Protokoll-Overhead für den Tunnel ca. 150Byte beträgt und damit der generelle Overhead begrenzt wird um die (Nutz-)Bandbreite zu erhöhen. Warum findet sich dieser Eintrag (also fragment = 1300) nicht in den Konfig-Files für das OpenVPN-Paket der Fritzbox wieder? Wie kann ich das nachträglich ändern?

Den OpenVPN-Port kann ich im WebUI frei wählen. Muss ich nachträglich auch noch manuell die ar7.cfg um den OpenVPN-Port ergänzen, wie im Wiki beschrieben, oder entfällt das mit ds26-15.2?

 

[MaxMuster]

Moin,

ich hätte das mit der Zwangsfragmentierung per fragment durchaus anders interpretiert:

Enable internal datagram fragmentation so that no UDP datagrams are sent which are larger than max bytes.
[...]
It is only meant as a last resort when path MTU discovery is broken. Using this option is less efficient than fixing path MTU discovery for your IP link and using native IP fragmentation instead.
Having said that, there are circumstances where using OpenVPN's internal fragmentation capability may be your only option, such as tunneling a UDP multicast stream which requires fragmentation.

Eine "grundsätzliche Empfehlung" lese ich daraus nicht ;-).
Allerdings ist es wohl in der Tat eine Möglichkeit, eine einfache Zeile für "zuzätzlche Parameter" einzufügen um die Config nicht nachträglich editieren zu müssen (mit dem Nebeneffekt, dass falsche Einträge den Start verhindern). Mal sehen...

Der Port-Parameter wird in die Config mit übernommen.

Jörg

EDIT Ich muss das oben gesagte wohl doch etwas relativieren, denn weiter unten steht das, was man durchaus als "Empfehlung" sehen könnte:

--mssfix and --fragment can be ideally used together, where --mssfix will try to keep TCP from needing packet fragmentation in the first place, and if big packets come through anyhow (from protocols other than TCP), --fragment will internally fragment them.

 

[hermann72pb]

Warum findet sich dieser Eintrag (also fragment = 1300) nicht in den Konfig-Files für das OpenVPN-Paket der Fritzbox wieder? Wie kann ich das nachträglich ändern?

1. Man kann nicht alles in GUI realisieren. Bei mir funktioniert es mit diesen Einstellungen.
2. Es gibt die Möglichkeit eine config-Datei im Flash anzulegen. Suche bitte in diesem Thread 1-2 Seiten davor, oder vielleicht irgendwo anders im Forum. Es wurde vor kurzem ausgiebig diskutiert.

Den OpenVPN-Port kann ich im WebUI frei wählen. Muss ich nachträglich auch noch manuell die ar7.cfg um den OpenVPN-Port ergänzen, wie im Wiki beschrieben, oder entfällt das mit ds26-15.2?

Nein, es muss immer noch per Hand gemacht werden. Du kannst es alternativ mit VirtualIP versuchen, es wurde aber hier öfteres über Probleme zwischen VirtualIP und OpenVPN berichtet. Deswegen ar7.cfg

Edit: ist es wirklich so, dass OpenVPN automatisch ar7.cfg ändert? Das war mir bis jetzt nicht bekannt.

MfG

 

[wengi]

Ich musst die ar7 auch per Hand bearbeiten.
Keine Automatik.

wengi

 

[MaxMuster]

Hi,

das mit dem Port habe ich auch erst Miss-verstanden:
Der Port in der GUI besagt nur, auf welchem Port der OpenVPN-Prozess arbeiten soll. Die zusätzlichen Einträge (z.B. in der ar7.cfg) sind dafür, dass dieser Port "von außen" erreichbar gemacht wird, "bohrt" also das entsprechende "Loch" in die Firewall. Das ist nicht automatisiert und daran würde ich auch nicht gehen wollen, denn Fehler in der ar7.cfg sind fatal.
Zudem sind dabei wieder viele Dinge zu beachten, z.B. welcher Port soll "draußen" sichtbar sein? Das kann/soll/muss ja vielleicht ein anderer sein, als der, auf dem der Prozess lauscht...

Kurzum: Die Einträge in der ar7.cfg sind weiterhin "von Hand" zu machen.

Jörg

 

[wengi]

Andere Frage: ich bin gerade dabei mein Friboli anzupassen, um beim Build schon die aktuellen openvpn-Dateien mit im Image zu haben.
Bei dieser Gelegenheit möchte ich auch gleich die Zertifikate (ca.crt usw) mit einbauen. Die liegen ja normalerweise in /var/tmp/flash. Aber wo muss ich die im ds-mod Verzeichnis hinkopieren?

wengi

EDIT: Ich vermute, die müssen in die Datei /ds26-15.2/build/original/filesystem/var.tar. Aber ein tar -tv bringt kein Ergebnis. auch -z und -j schon probiert..

 

[MaxMuster]

Mein Vorschlag wäre, du baust dir dafür ein "fwmod_custom", was das übernimmt:

Entweder steht da dann sowas wie z.B.:

all() {
        cp ../../box.crt ./firmware/var/tmp/box.crt
        cp ../../box.key ./firmware/var/tmp/box.key
}

oder

all() {
        cp ../../box.crt ./kernel/var.tar/var/tmp/box.crt
        cp ../../box.key ./kernel/var.tar/var/tmp/box.key
}

und danach noch was, was dafür sorgt, dass die Dateien kopiert werden (im Skript "/var/install" z.B.) oder du machst da dann selbst.
Der Vorteil der ersten Variante wäre, dass die Dateien nur "während des Updates" da sind, aber (meine Vermutung) ein zweifaches Update nötig wäre, da während des ersten Updates (auf eine Original-Box) die DSMOD Strukturen erst erzeugt werden müssten, also z.B. var/tmp/flash noch nicht existiert...
Bei der zweiten Methode lägen die Dateien wohl immer beim Starten in /var/tmp ...

Wenn ich so drüber nachdenke:
Einfacher wäre wohl ein "Pseudo-Update" dafür, was nach dem ersten eingespeilt wird:
lege dir ein Verzeichnis "var" an, kopiere die Dateien hinein, baue ein Mini-Skript mit Namen "install" darin, was in etwa so aussieht:

#!/bin/sh
cp /var/box.crt /var/tmp/flash/box.crt
cp /var/box.key /var/tmp/flash/box.key

# ctlmgr wird vorher gestoppt, daher gibt es sonst danach kein WebIF mehr
ctlmgr

# Wir hatten einen "unbekannten Fehler", ein reboot tut also nicht not
exit 0

Die datei muss ausfürhbar sein (chmod +x install). Danach mit einem "alten" tar zusammenpacken ("tools/tar cvf meinupdate.image var") und als Update hochladen.

Jörg