OpenVPN Blockierung aus Hotspots umgehen
-
Vielen Dank für deine Antwort, viragomann!
Ok super zu hören, dass es sicherheitstechnisch keine Probleme geben sollte. Ich verwende beides: Client-Zertifikate und sichere Passwörter, dabei auch den Abgleich des Nutzernamens mit dem CN des Zertifikats.
Zur Sicherheit hätte ich noch eine kurze Frage: seit (glaube ich) der 2.4 Version gibt es die Option unter TLS Key Usage Mode neben TLS Authentication auch noch TLS Encryption and Authentication auszuwählen. Ich dachte, dass das die Sicherheit nochmal steigern sollte (obwohl für die normale Nutzung evtl. sogar nicht wirklich notwendig und würde nur mehr CPU Power verbrauchen?) und habe dies ausprobiert. Aber so kam bei mir keine Verbindung zustande, es kam ein Fehler mit dem Inhalt - irgendwie HMAC zu kurz o.ä. Hast du eine Idee, was das Problem sein könnte?Ja, die Idee war natürlich das TCP Protokoll zu nutzen, weil eben - wie du schon sagtest - auch UDP Verbindungen geblockt werden könnten. Da TCP ggü. UDP tatsächlich schlechtere Performance bietet, so dachte ich mir es folgendermaßen zu realisieren. Ich erstelle 2 OpenVPN Server mit identischen Authentifizierungsmethoden und passe halt die jeweiligen .ovpn Config-Files entsprechend an, sodass man sich mit einer .ovpn Config an beiden Servern anmelden kann. So würde halt standardmäßig immer der UDP1194 Tunnel verwendet werden und bei problematischen Hotspots der automatische Umschwung auf TCP443 erfolgen. Generell funktioniert das wohl gut, habe jetzt schon mal ein wenig herumgetestet, allerdings mit anderen Ports.
Hat jetzt nicht viel mit dem Thema zu tun, aber in dem Zusammenhang mit der Portänderung des WebGUI würde ich gerne noch folgendes wissen, vllt. kann hier jemand an der Stelle weiterhelfen. Wäre es irgendwie möglich die pfSense (z.B. über Unbound) bei bestimmten Domains die festgelegten Ports selbst ergänzen zu lassen? Also man ruft pfsense.example.net auf und wird zu pfsense.example.net:8443 weitergeleitet? Geht mir jetzt nicht um die eine einzige Web-Configurator Weiterleitung, sondern auch um die anderen Geräte/Dienste im Heimnetz, wie bspw. NAS oder AP.
-
Mit den neuen OpenVPN Optionen der 2.4 habe ich mich noch nicht beschäftigt, ich weiß nicht, was diese Einstellung bewirkt.
Aber möglicherweise musst die die Konfig am Client dementsprechend anpassen bzw. neu exportieren, wenn du das Export Tool installiert hast.Ich erstelle 2 OpenVPN Server mit identischen Authentifizierungsmethoden und passe halt die jeweiligen .ovpn Config-Files entsprechend an, sodass man sich mit einer .ovpn Config an beiden Servern anmelden kann. So würde halt standardmäßig immer der UDP1194 Tunnel verwendet werden und bei problematischen Hotspots der automatische Umschwung auf TCP443 erfolgen.
Das sollte kein Problem sein. Aber warum die Konfig immer anpassen? Du hast eben 2 Konfigs am Client und wählst bei der Einwahl die entsprechende aus.
Wäre es irgendwie möglich die pfSense (z.B. über Unbound) bei bestimmten Domains die festgelegten Ports selbst ergänzen zu lassen? Also man ruft pfsense.example.net auf und wird zu pfsense.example.net:8443 weitergeleitet? Geht mir jetzt nicht um die eine einzige Web-Configurator Weiterleitung, sondern auch um die anderen Geräte/Dienste im Heimnetz, wie bspw. NAS oder AP.
Das kann nur ein Proxy. Wenn du mehrere Dienst hast, die von außen alle über 443 angesprochen werden sollen, aber nur eine öffentliche IP, ist ein Proxy das Mittel deiner Wahl.
Bei Fragen dazu würde ich dir aber empfehlen, einen eigenen Thread mit entsprechenden Thema zu eröffnen, ich kann dir dabei leider nicht viel weiter helfen.Grüße
-
TLS Encryption and Authentication
Bedeutet das das control channel komplett verschlüsselt wird (tls-crypt) anstatt nur das data channel (cipher).
Ich erstelle 2 OpenVPN Server mit identischen Authentifizierungsmethoden und passe halt die jeweiligen .ovpn Config-Files entsprechend an, sodass man sich mit einer .ovpn Config an beiden Servern anmelden kann.
Sehe <connection>im OpenVPN Manual:
https://community.openvpn.net/openvpn/wiki/Openvpn24ManPageEventuell gibt`s auch noch die port-share Option.
Such mal nach "OpenVPN port-share" hier ins Forum, vielleicht geht das im pfSense.Sehe auch –port-share im OpenVPN Manual.</connection>
-
zu TLS Key Usage Mode
Naja, dann wird bei der Config halt der TLS Teil mit angepasst und es wird aus <tls-auth>[…]</tls-auth> => <tls-crypt>[…]</tls-crypt> gemacht. Ich hab's ja die entsprechende Config verwendet, aber irgendwie wollte es trotzdem nicht. Na mal sehen, vllt. muss ich dann noch alles durchchecken.Das sollte kein Problem sein. Aber warum die Konfig immer anpassen? Du hast eben 2 Konfigs am Client und wählst bei der Einwahl die entsprechende aus.
Ne ne, du hast mich falsch verstanden. Mit "anpassen" meinte ich die einmalige Anpassung. Man kann in der Config mehrere Ziele eintragen und es wird dann (denke ich mal) nach der Reihenfolge abgearbeitet. So würde dann in meiner Config stehen:
[…]
remote wan.example.net 1194 udp
remote wan.example.net 443 tcp
[…]
Wenn der UDP Port 1194 unerreichbar ist, weil geblockt, erfolgt automatisch der Umschwung in die nächste Zeile und es wird der TCP Port 443 probiert. Dauert dann halt ein paar Sekunden, bis die Verbindung steht (ich habe gestern so 10-12 Sekunden gemessen; weiß nicht, ob man die Time-Out Zeiten irgendwie anpassen kann). So muss ich nicht mal die Configs wechseln (zumal das für einige Nutzer fast schon eine Zumutung wäre ;D), sondern das läuft alles automatisch im Hintergrund ab.Das kann nur ein Proxy. Wenn du mehrere Dienst hast, die von außen alle über 443 angesprochen werden sollen, aber nur eine öffentliche IP, ist ein Proxy das Mittel deiner Wahl.
Bei Fragen dazu würde ich dir aber empfehlen, einen eigenen Thread mit entsprechenden Thema zu eröffnen, ich kann dir dabei leider nicht viel weiter helfen.Ne, mir geht es nicht um das von außen erreichbar machen, sondern innerhalb des Heimnetzes. Ich dachte da an so etwas wie einen SRV Record bei den Domains. Ist jetzt aber nichts Weltbewegendes, sondern eher Feintunig. Ich werde noch recherchieren, wenn ich Zeit und Lust dafür habe, ansonsten frage ich hier nochmal nach.
@Pippin: danke auch! Ich schaue mich mal um. Habe mittlerweile schon zufällig folgendes gefunden: https://forum.pfsense.org/index.php?topic=138110.0
Scheinbar muss dann tatsächlich noch port-share localhost 443 in die advanced box rein beim 443-er VPN. -
Also, nachdem ich kurz alles nötige umgestellt habe, klappt nun alles wie es soll!
Wenn man noch die folgende Zeile in die Config mit reinnimmt, dann kann man die Timeout Dauer bestimmen: server-poll-timeout 5 (also in dem Fall 5 Sekunden). Ich denke mal, auch nur 2-3 Sekunden sollten reichen, da bei mir die Verbindung (was ich jetzt so zu Testzwecken gesehen habe) in weniger als 1 Sekunde aufgebaut wird. So würde dann der Umschwung auf den 443 Port nicht so lange dauern.
Getestet habe ich in meinem Gastnetz und wenn ich dort die UDP1194 gesperrt habe, dann klappte der automatische Verbindungsaufbau über den TCP443 Tunnel.
Soweit bin ich sehr zufrieden, jetzt muss ich nur noch Zeit finden, um das für alle Teilnehmer einzurichten :)
PS. Bzgl. tls-crypt und der möglichen Ursache, warum es bei mir nicht funktionierte: habe mal in einer Rezension zur OpenVPN Connect App gelesen, dass bisher der auth-crypt Support fehlt und tatsächlich finde ich nichts dazu - weder in der Beschreibung, noch irgendwo auf der Webseite. Ich habe es bisher nur auf dem iPhone mit der App probiert, weil der Großteil der Clients eben nur die mobilen Geräte sind.
-
Wenn der UDP Port 1194 unerreichbar ist, weil geblockt, erfolgt automatisch der Umschwung in die nächste Zeile und es wird der TCP Port 443 probiert.
Ja, habe ich auch schon mal gelesen, dass das möglich ist, bislang aber noch nicht benötigt. Für mein Heimnetzwerk-Projekt allerdings, das in naher Zukunft ansteht, kann ich das aber ganz gut gebrauchen. Muss ich mir gleich vormerken. Danke dafür! :)
Ne, mir geht es nicht um das von außen erreichbar machen, sondern innerhalb des Heimnetzes. Ich dachte da an so etwas wie einen SRV Record bei den Domains. Ist jetzt aber nichts Weltbewegendes, sondern eher Feintunig. Ich werde noch recherchieren, wenn ich Zeit und Lust dafür habe, ansonsten frage ich hier nochmal nach.
Verstehe ich nicht. Im Heimnetz hast du die Services wohl auf unterschiedlichen IP-Adressen laufen, da reicht ein normales DNS. SRV-Einträge bringen ohnehin nur was, wenn sie vom Client interpretiert werden können.
-
Nein, SRV war nur ein Beispiel. Mir geht es halt darum, dass ich mir nicht für jede Heimnetz Anwendung die Ports merken und diese jedes mal eingeben möchte. Ich habe z.B. den Unifi Controller auf der pfSense Box laufen, nun ein neuer Port für das WebGUI, außerdem noch nTop… und das nur bei der Sense. Daneben noch 2 Netzwerkfähige Geräte, wo mehrere Dienste laufen.
Ich habe das jetzt aber folgendermaßen gelöst: Virtuelle IP's angelegt und im Outbound diesen IP's bestimmte Hostnamen zugeordnet. Danach NAT Regeln angelegt, sodass der Aufruf der jeweiligen Virtuellen IP (bzw. des zugehörigen Hostnamen) + Port 443 auf den jeweils festgelegten Port des bestimmten Services leiten soll. Funktioniert soweit recht gut.
Kann man so machen oder? Dürften ja keine Nachteile dadurch entstehen?
-
Sehe kein Problem damit.
Ich bleibe aber bei meinen Lesezeichen im Browser zu den diversen IPs und Ports. Verwirrt mich wengier ;)
-
Ja gut, Lesezeichen kann man machen, wenn man nur von seinen Geräten auf die Dienste zugreift. Würde mir aber nichts bringen, wenn ich auf einem anderen Gerät meine Lesezeichen nicht zur Verfügung stehen habe ;)
-
Bzgl. der Dienste mit DNS: Nein das geht nicht. Es gibt m.E. keine Erweiterung im DNS, die irgendeine Weiterleitung spezifiziert wie du sie haben möchtest. DNS weiß auch nichts über Dienste, somit kann man zwar eine Domain per se weiterleiten (CNAME, ALIAS, etc.) aber keine URL Weiterleitung. Es gibt Dienste, die das anbieten, aber Vorsicht: DAS IST KEIN DNS!
Diese Dienste regeln das meist intern so, dass für solch eine Weiterleitung dann ein DNS Alias oder CNAME erstellt wird und auf einen anderen Webservice zeigt, der dann eben die URL Redirection übernimmt. Wie gesagt: DNS kennt keine Dienste, und kann somit auch nicht bspw. Webdienste per Domainname auf andere Ports weiterleiten etc. da das kein Bestandteil von DNS ist. :)Du kannst zwar TXT Einträge o.ä. definieren, müsstest dir aber selbst irgendwas dazu basteln, was diese Einträge ausliest oder sonstwie verarbeitet :)
Ansonsten war das, was Pippin schrieb (DANKE dafür übrigens @Pippin!) schon korrekt. Mit OpenVPN 2.4 gibt es nun komplette <connection>Sektionen, in denen NICHT nur der Remote Eintrag enthalten sein kann, sondern ein komplettes Verbindungsprofil, das nacheinander abgearbeitet wird, also bspw. eine Verbindung via TCP/443 und mit aktivem Proxy Setting und danach eines mit UDP/1194 ohne alles. Das ist wesentlich flexibler als zwei reine Remote Einträge :) Einfach mal einen Blick in die verlinkte Manpage werfen, da wird das sehr schön gezeigt
(Auch an @viragomann weil er das ja ggf. demnächst auch braucht :))Gruß</connection>
-
Hallo!
@JeGr
Danke für den Hinweis, passt aber nicht in diesem Thread. Hier ist DNS vor deinem Post nur ein einziges mal erwähnt worden und zwar in diesem Satz von mir:
@viragomann:Im Heimnetz hast du die Services wohl auf unterschiedlichen IP-Adressen laufen, da reicht ein normales DNS.
Diesen hast du offenbar nicht ordentlich gelesen. Hier war die Rede von unterschiedlichen IP, die man über DNS differenzieren könnte.
???Grüße
-
Mit OpenVPN 2.4 gibt es nun komplette <connection>Sektionen, in denen NICHT nur der Remote Eintrag enthalten sein kann, sondern ein komplettes Verbindungsprofil, das nacheinander abgearbeitet wird, also bspw. eine Verbindung via TCP/443 und mit aktivem Proxy Setting und danach eines mit UDP/1194 ohne alles.</connection>
Jetzt mal eine Frage, weil ich das bisher nie verstanden habe: wozu genau sollte man sich über einen Proxy zum OpenVPN Server verbinden bzw. was bezweckt man dadurch?
-
Jetzt mal eine Frage, weil ich das bisher nie verstanden habe: wozu genau sollte man sich über einen Proxy zum OpenVPN Server verbinden bzw. was bezweckt man dadurch?
Weil man sich in einem Netz befindet was einen Proxy voraussetzt? Weil man einen Proxy zum Verbindungsaufbau benötigt? Gründe gibts genug :)
Danke für den Hinweis, passt aber nicht in diesem Thread. Hier ist DNS vor deinem Post nur ein einziges mal erwähnt worden und zwar in diesem Satz von mir:
Dann hast aber du nicht gelesen, was @un1que gefragt/geschrieben hat. Das war hier eindeutig:
Ich dachte da an so etwas wie einen SRV Record bei den Domains. Ist jetzt aber nichts Weltbewegendes, sondern eher Feintunig. Ich werde noch recherchieren, wenn ich Zeit und Lust dafür habe, ansonsten frage ich hier nochmal nach.
Da geht es genau um DNS und darauf hab ich geantwortet.
-
Danke für den Hinweis, passt aber nicht in diesem Thread. Hier ist DNS vor deinem Post nur ein einziges mal erwähnt worden und zwar in diesem Satz von mir:
Dann hast aber du nicht gelesen, was @un1que gefragt/geschrieben hat. Das war hier eindeutig:
Ich dachte da an so etwas wie einen SRV Record bei den Domains. Ist jetzt aber nichts Weltbewegendes, sondern eher Feintunig. Ich werde noch recherchieren, wenn ich Zeit und Lust dafür habe, ansonsten frage ich hier nochmal nach.
Da geht es genau um DNS und darauf hab ich geantwortet.
Ich zitiere mal:
@JeGr:Bzgl. der Dienste mit DNS: Nein das geht nicht. Es gibt m.E. keine Erweiterung im DNS, die irgendeine Weiterleitung spezifiziert wie du sie haben möchtest. DNS weiß auch nichts über Dienste, somit kann man zwar eine Domain per se weiterleiten (CNAME, ALIAS, etc.) aber keine URL Weiterleitung. Es gibt Dienste, die das anbieten, aber Vorsicht: DAS IST KEIN DNS!
CNAME, ALIAS sind aber doch etwas ganz anderes und dass SRV-Einträge so nicht funktionieren hatte ich schon zuvor erwähnt gehabt. ???
Aber gut… -
Geht zwar OT aber:
Ich dachte da an so etwas wie einen SRV Record bei den Domains
"An sowas wie SRV Einträge" - da gehts klar um DNS. Und das einzige was dann in Frage käme, wo es bei DNS bzw. Hostnamen um Services gehen "könnte" sind eben CNAME, ALIAS (unspezifiziert) und andere DNS Erweiterungen und das habe ich da beantwortet. Ist doch auch in Ordnung? Verstehe nicht wo das Problem war, es war gefragt ob das vielleicht mit irgendwas wie DNS gehen könnte, ich bin da nochmal drauf eingegangen. Kann ich in Zukunft auch lassen wenns zu OT wird. Gute Güte :o Wenns sonst noch weiter OT wird ists jedem egal, jetzt schreib ich was im Detail in der Hoffnung dass es erhellend bei der Frage ist, und es ist auch nicht OK? :-\
-
Mal BTT, ich hätte noch ein paar Fragen ;D
Ich habe die beiden Server eingerichtet und nun können alle mobilen Geräte die Verbindungen zu beiden Servern aufbauen. Was mir jetzt aber nicht so sehr gefällt, dass recht häufig die Verbindung zum 443-Server aufgebaut wird, welcher ja eigentlich nur in "Notfällen" benutzt werden sollte.
Habe mittlerweile den Timeout mit server-poll-timeout auf 5 Sekunden erhöht (anfangs mit nur 3 versucht). Unter Laborbedingungen (also die Tests, die ich zu Hause aus dem Gast-WLAN und 4G-Netz ausprobiert habe) wird die Verbindung innerhalb von einer Sekunde aufgebaut, in der Realität dauert es wohl - teilweise doch deutlich - länger. Habt ihr eine Idee, wie man das evtl. noch weiter feintunen kann, damit die Verbindung zum 443-Server nicht so -unnötigerweise- oft aufgebaut werden soll? Ich will da, ehrlich gesagt, nicht mehr als 5 Sekunden einstellen - das wäre dann im Falle der Fälle viel zu lange, denke ich.
Oder mache ich mir zu viele Gedanken und der Performance Unterschied zwischen 443-TCP und 1194-UDP ist doch nicht so groß, v.a. bei den Verbindungen mobiler Geräte nicht wirklich spürbar und es somit auch egal wäre, wenn diese sich trotzdem zum 443-Server connecten, statt dem 1194 (also Timeout wieder auf nur 3 Sekunden runterregeln)?Weil ich die Logs wegen der o.g. "Problematik" jetzt so genau verfolgt habe, ist mir aufgefallen, dass manche Geräte sich recht häufig anmelden und teilweise sogar alle paar Minuten (es ist ein Inaktivitätszeitraum von 2 Minuten eingestellt, bis die Verbindung automatisch getrennt wird). Wisst ihr, was für den Akku schonender wäre: die Verbindung länger aktiv zu halten (bspw. 15 Minuten, statt 2) oder eben bei Bedarf ein paar mal öfter aufzubauen und dann schneller zu beenden? Aus dem Bauch heraus würde ich sagen - ersteres…
-
Aus dem Bauch heraus hätte ich auch gesagt, dass 5 Sekunden eigentlich ausreichend sein sollten. Scheint dann aber doch nicht ganz so zu sein, allerdings weiß ich nicht, wie und wann deine Geräte ein VPN aufbauen. Sind die ggf. noch gar nicht im WLAN angemeldet und versuchen da schon eine Verbindung aufzubauen? Oder machen sie das nur on demand? Ansonsten würde ich da ggf. auf 10s hoch gehen, das halte ich immer noch für einen relativ geringen Zeitraum der verschmerzbar ist. Ich weiß ja nicht was bei dir in deinem Fall viel zu lang ist (und warum) :)
Je nach Anwendungsfall kann der Performance Unterschied schon deutlich sein (tcp vs udp) aber das ist sehr stark Anwendungs- und einzelfallabhängig. Wenn du den Unterschied aber nicht merkst und es dir damit egal ist, wäre es wirklich unerheblich, über was die Verbindung passiert. Gerade bei Traffic-intensiven Sachen sollte sich das aber bemerkbar machen, kurzes stoßweises surfen eher nicht.
Die häufigen Verbindungswechsel/-aufbauten beziehen sich auf Mobilgeräte? Smartphone etc? Da ist das recht normal, da die Geräte ja gern im Ruhemodus WLAN abschalten und damit der Träger wegfällt bzw. sich ändert und das wieder einen VPN Neuaufbau triggert. Hältst du das VPN aktiv, wird auch WLAN und Co aktiv bleiben und du wirst das am Akku bemerken. Hängt wieder ganz an deinem Anwendungsfall - ich baue mein VPN Mobil immer nur on demand auf um da den Akku zu schonen. :)
Grüße
-
Ja sorry, ich hätte es tatsächlich erwähnen sollen, es geht (zumindest vorerst) nur um die mobilen Geräte und überall ist eine on-demand Verbindung sowohl für WLAN als auch für Mobilfunk konfiguriert. Dort habe ich dann entsprechend auch die 2 Minuten Idle festgelegt und wenn sich in der Zeit nichts tut, dann wird die Verbindung wieder getrennt.
Im Moment werden die Verbindungen meist über das 3G/4G Netz aufgebaut und eher selten über das WLAN. Ab und zu reichen aber die 5 Sekunden nicht aus, vorher bei 3 Sekunden kam die Verbindung fast nur über den 443-Server zustande. Wobei man hier sagen muss, dass das Client-abhängig ist (ich denke mal aber, dass es dann auch am Standort und den dortigen Gegebenheiten liegt).
Aber auch per WLAN (im Moment nur aus den Unitymedia‘s Hotspots getestet) schaffen die Geräte es nicht innerhalb von 3 Sekunden, auch 5 sind teilweise sehr knapp, hmm… Wie gesagt, ist sehr komisch, da beim manuellen Eingriff die Verbindung innerhalb von einer Sekunde aufgebaut wird.Ich habe jetzt halt beobachten können, dass manchmal 2-3 mal pro Viertelstunde (teilweise aber öfter - evtl. liegt es aber am schlechten Empfang?) eine Verbindung aufgebaut wird und habe mir deswegen überlegt, man könnte den Idle Intervall erhöhen, weil dort eh kaum etwas passiert, aber beim Verbindungsaufbau mehr "Aufwand" betrieben werden muss. Oder liege ich damit daneben und es sollte sich dann besser machen alles bei den 2 Minuten zu belassen? Wie gesagt, an der Stelle, geht es mir zunächst nur um die mobilen Geräte und Schonung derer Akkus.
Wobei, mein iPhone liegt hier neben mir mit gutem 4G Empfang und verursacht sogar 2-3 Verbindungen / Minute und das teilweise im minütlichen Takt :o Im iPhone selbst wird die Verbindungsdauer aber mit 25 Minuten angegeben.
Dann wird das Gerät es wohl irgendwie schon selbst regeln und es macht wahrscheinlich keinen Sinn hier den Idle Intervall zu erhöhen.Zu den 5s vs. 10s: naja, die 10s sind natürlich noch verschmerzbar, aber das wäre auf der anderen Seite unnötig lange Wartezeit im Falle der Fälle. Ich meine, wenn es nun tatsächlich keine große Bedeutung hat, ob sich die mobilen Geräte von unterwegs über TCP oder UDP verbinden, dann könnte man ja bei 5s bleiben. Oder alternativ auf 3s runtergehen und die Reihenfolge tauschen ;D
-
Ich habe bei mobilen Geräten selbst meist nur Laptops oder Android Geräte im Test und dort nicht den OpenVPN Client des Herstellers, sondern meist den von Arne Schwab, da damit Debugging und Einstellungen einfacher änderbar/kontrollierbar sind.
https://play.google.com/store/apps/details?id=de.blinkt.openvpn&hl=de
Ansonsten kommt eine Neuverbindung auch immer bei Wechsel der IP zustande. Kann also mitunter daran liegen, dass du dich 3G/4G gerade woanders eingebucht hast oder gerade an einer Grenze zwischen 2 unterschiedlichen Spots bist, dein Smartphone bspw. zwischen WLAN und 4G hin und her schaltet (neue Geräte haben da eine "tolle" Funktion, die bei schlechtem WLAN bspw. LTE Verbindungen bevorzugt…) und mehr. Ist also schwierig zu sagen woran es klemmt. Mein Test-Klopper (ein Nexus 6) bspw. verbindet sich mit unserem Firmen-VPN binnen 1-2s (via UDP) bei 3G und LTE. Geht also echt flott. Und die App legt sich dann quasi auch mit schlafen, wenn das Gerät nicht gebraucht wird - sobald man es aber aufweckt, sieht man kurz in der Statusleiste den Schlüssel wieder aufbauen und kurz darauf ist wieder alles da. Deshalb kann ich die langen Timeouts bzw. Verbindungsaufbauten gerade schlecht deuten bei dir ;)
Aber durch das anhalten und weiterführen des VPNs ist es recht akkuschonend. Kommt natürlich drauf an was man erreichen will. Wenn das Gerät NUR per VPN funktionieren SOLL wird es natürlich schwierig ;) -
Ich habe hier zunächst nur iOS Geräte (bei Laptops habe ich noch nicht herausgefunden, wie ich dort on-demand Verbindungen einrichte - muss ich mich noch damit beschäftigen) und nutze die offizielle OpenVPN Connect App. Was anderes geht wohl nicht, aber ich bin damit schon sehr zufrieden.
Ne, zwischen WLAN und Mobilfunk umschalten, tun die iOS Geräte zum Glück nicht bzw. man kann es in den Einstellungen verhindern. Aber es könnte ja tatsächlich an den IP Änderungen liegen. Weiß zwar nicht, wie das CGN genau funktioniert, aber z.B. bei Unitymedia's DS-lite hieß es ja, dass sich die IP sogar 2-3 mal pro Minute ändern kann, obwohl nach wie vor dieselbe als externe angezeigt wird. Wenn es im Mobilfunk ähnlich abläuft, dann könnte das ja tatsächlich zum Neuaufbau der Verbindungen führen.
Ich habe mir jetzt noch einmal die Einstellungen der OpenVPN Connect App angeschaut und folgende 2 Punkte gefunden, die interessant sein könnten:
1.
Reconnect on wakeup — Automatically reconnect a VPN profile if it was active prior to device sleep. -Werde ich wohl ausschalten, da die Verbindung bei Notwendigkeit eh aufgebaut wird und das wohl überflüssig wäre.
2.
Network state detection — How should OpenVPN handle network state changes or network reconfiguration events where the network comes up, goes down, or transitions between WiFi and Cellular data?
- Active (default) : When connected, always attempt to reconnect after network reconfiguration events.
- Lazy : When connected, attempt to preserve existing connection during network reconfiguration events. (wobei diese Möglichkeit bei mir fehlt) - Disabled : Don't consider network state when initially connecting, and don't use network state changes to trigger pause/reconnect/disconnect behaviour. -Was genau passiert, wenn ich diesen Punkt probiere? Wird dadurch evtl. verhindert, dass die App dann mit den vorkonfigurierten on-demand rules (bspw. bei bestimmten SSID's keine VPN Verbindung aufzubauen) nicht mehr richtig umgehen kann?
Habe das jetzt mal ausprobiert und das iPhone lag hier knapp 1,5h rum. Ergebnis: es wurde nur ein Verbindungsaufbau verzeichnet. Hmm, ich könnt's ja mal testen, wie sich das im Alltag bemerkbar macht.
