OpenVPN Blockierung aus Hotspots umgehen
-
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. -
Ok, das bringt wohl auch nichts. Habe jetzt seit 18 Uhr gestern Abend WLAN abgeschaltet und nur mit mobilem Netz getestet. Alles beim Alten - das iPhone verbindet sich nach wie vor teilweise mehrmals pro Minute. Naja, dann lass ich es einfach sein, wird schon laufen. Akku lebt auch noch und hat sich bisher sehr gut geschlagen, muss man sich nicht wirklich Sorgen machen.
Zur TCP vs UDP Problematik: diese besteht weiterhin und die mobilen Geräte verbinden sich (jetzt aber eher sehr selten) trotzdem noch mit dem 443-TCP Server. Ich werde da wohl nur noch weiter mühselig testet müssen, um die optimalen Einstellungen zu finden. So aus der Ferne, wird man mir wohl nicht wirklich helfen können.
Trotzdem vielen Dank für den Input bis hierhin!
-
Also ich glaube die Lösung für die langen Verbindungszeiten gefunden zu haben. Kann es sein, dass Vodafone und Unitymedia sich nicht mögen und untereinander schlechtes Routing haben?
Jedenfalls glaube ich, dass es daran gelegen hat. Habe einige Traceroutes aus dem Mobilfunknetz zu meinem heimischen Anschluss gemacht und es dauerte halt etwas länger bzw. gab an 2 Stellen diese langen Timeouts.
Danach habe ich Traceroute zur öffentlichen IP eines in der pfSense eingerichteten OpenVPN Clients gemacht und siehe da - alles lief schnell und in 1-2 Hops weniger durch.So habe ich auf der Serverseite des VPN Tunnels eine Portweiterleitung und als WAN meines pfSense VPN Servers eben die o.g. öffentliche IP eingerichtet. Gleichzeitig den server-poll-timeout auf 3(!) Sekunden runtergesetzt. Was soll ich sagen? Läuft top und nur absolut selten brauchen die Clients länger als 3 Sekunden, noch deutlich seltener als beim 5-sekündigen Verbindungsaufbau zu meiner WAN IP.