Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Frage zum VPN: VPN über UDP in vielen öffentlichen Hotspots nicht nutzbar?
ich bin noch nicht so erfahren bzgl. VPN.
Nun habe ich mir auf meinem Raspberry Pi 3 b+ einen OpenVPN Server eingerichtet und dieser funktioniert im Mobilfunk auch prima.
Pi Hole kann ich so auch nutzen und bekomme keine Werbung angezeigt wenn ich uber das Mobilfunk surfe.
Nun habe ich das ganze auch mal testweise mit einem öffentlichen WLAN Hotspot vom Sonnenstudio direkt gegenüber meiner Wohnung getestet.
Allerdings kann ich darüber keine VPN Verbindung herstellen.
Woran könnte das liegen? Ist es ratsamer TCP statt UDP zu nutzen, da der UDP Port in öffentlichen Hotspots oft blockiert wurde vom Hotspot Betreiber?
Wenn ja, welche Nachteile hat man mit TCP und warum wird UDP blockiert?
Es kann auch sein dass bei dem Hotspot ein Proxy am arbeiten ist und der nur http bzw. https zulässt. Dann geht auch nichts weiter, weder UDP noch TCP (und auch kein VPN).
TCP over TCP kann halt scheiße sein (weil wenn du Pakete verlierst, beide Layer neue Pakete generieren, sodass das quasi ein Lawineneffekt geben kann). I.d.R. funktioniert das heutzutage aber trotzdem.
Das Problem mit UDP ist immer, dass sich der Router bei NAT merken muss, wer mit wem über welche Ports kommuniziert und er nicht erkennen kann, wann das vorbei ist. Auch renummeriert der gerne die Quellports, sodass dein VPN mglw. verwirrt ist.
Bei TCP ist das halt einfacher, da der Hotspot erkennen kann, wann eine Verbindung zu Ende ist, da TCP das Konzept einer Verbindung hat (UDP nicht).
Kleiner Tip: du kannst am OpenVPN TCP und Port 443 verwenden, dann gehts auch über nen Proxy :=) (hatte ich schon am Laufen ...)
Ergänzung ()
@leipziger1979 : du kannst beim default Port 1194 bei OpenVPN zwischen TCP und UDP wählen, die beiden und auch andere Ports wie tcp/3389 würden nicht gehen ... dachte das war verständlich :=)
Nicht zwingend. Ein OpenVPN Paket sieht anders aus als ein HTTPS Paket. Neuere Proxies schauen gerne tiefer in die Pakete rein und erkennen den anderen Aufbau.
Man muss die Pakete durch einen echten HTTPS Tunnel leiten, z.B. per stunnel.
Da sollte man dann aber wie @Hancock erwähnte nicht TCP over TCP machen, sondern UDP over TCP. OpenVPN also auf UDP belassen.
siehe hier: https://security.stackexchange.com/a/20820
"It will defend against deep packet inspection that reads the content of the application layer, but not against DPI at lower levels of the protocol wrapping."
Die Header sind auch eine Schwachstelle.
Ergänzung ()
d2boxSteve schrieb:
Dann ist aber nicht nur ein Proxy sondern eine deep inspection Instanz ....
a) OpenVPN ist doch ein SSL-VPN und verpackt die Pakete genauso wie https, das muss dafür ja nichts ändern im Ablauf
b) DPI hat nichts mehr mit Proxy zu tun
Ergänzung ()
Naja, ich bezweifle daß ein kleiner öffentlicher Hotspot DPI macht ... das wird nur ein einfacher squid sein :=)
Kommt halt wieder darauf an, wer den betreibt. In Köln z.B. werden sehr viele Hotspots zentral von NetCologne verwaltet. Da könnte ich mir das eher vorstellen.
Ansonsten sollte man es einfach mal mit dem bereits erwähnten OpenVPN over TCP mit Port 443 probieren.
Das liegt nicht an den Hotspots. Ich nutze meine Fritz-VPN ausschließlich an Hotspots. In Hannover habe ich noch keinen entdeckt, an dem es nicht funzt. Selbst die Freifunk Hotspots funzen.
Also mit dem 53er kann ich gar keine Verbindung aufbauen, ebenso der 80er.
Mit dem 443 kommt eine Verbindung zur Stande, aber es wird keine Seite geladen und auch wenn ich ping google.de oder meine URL vom Server eingebe passiert nichts.
Im Mobilfunk klappt mit dem 443 aber alles.
Der Hotspot vom Sonnenstudio wird von Socialwave betrieben. Vielleicht kennt diesen Anbieter jemand von euch?
TCP ist für VPN in der Regel eine ganz schlechte Idee und sollte gemieden werden soweit möglich. Das Problem ist das TCP-Handshake. Dabei wird der Eingang eines TCP-Pakets mit einem Antwort-Paket bestätigt, ähnlich wie ein Einschreiben mit Rückschein.
Wenn nun eine Anwendung eine TCP-Verbindung inkl. Handshakes über ein TCP-VPN laufen lässt, wird das komplette Handshake der Anwendung ebenfalls mittels Handshake des TCP-VPNs gegenseitig bestätigt. Wie ein Einschreiben in einem Einschreiben, dessen Rückscheine auch nochmal per Einschreiben geschickt werden.
Dazu vielleicht eine kleine Geschichte zur Veranschaulichung, wenngleich der zugrundeliegende Prozess leicht vereinfacht(!) dargestellt wurde:
Anton möchte einen Liebesbrief zum Ankreuzen (Anwendung) an Berta schicken (Oldschool ^^). Natürlich erwartet Anton von Berta eine Antwort (TCP). Damit aber niemand von außen sehen kann, dass es ein Liebesbrief ist tütet Anton den Liebesbrief in einem großen, braunen Briefumschlag ein (VPN). Um sicherzugehen, dass der Brief auch ankommt, schickt er den großen braunen Briefumschlag (VPN) per Einschreiben mit Rückschein an Berta (VPN mit TCP). Anton drückt dem Postboten den braunen Briefumschlag in die Hand (1).
Ein paar Tage später klingelt der Postbote bei Berta. Überraschung, ein Einschreiben mit Rückschein. Berta guckt verdutzt, unterschreibt den Rückschein und gibt ihn dem Postboten zurück (Empfangsbestätigung VPN-Paket). Der Postbote macht sich schon mal auf den Weg zu Anton (2) und übergibt ihm den Rückschein, sie hat den Brief also bekommen.
Währenddessen öffnet Berta in ihrer Wohnung gerade das Einschreiben (VPN) und siehe da ein Liebesbrief zum Ankreuzen (Anwendung). Berta denkt sich "Was fällt dem ein?" und kreuzt "Nö" an. Nu will sie den beantworteten Liebesbrief wieder an Anton zurückschicken, aber halt(!), das kann dann ja jeder lesen! Also tütet Berta die Antwort ihrerseits in einen braunen Umschlag als Einschreiben ein, damit sie auch ja sichergehen kann, dass der olle Anton ihre Antwort auch bekommt - ab damit zum Briefkasten!
Der Postbote leert den Briefkasten, nimmt den neuen brauen Briefumschlag als Einschreiben (inkl. Bertas Absage) mit und macht sich auf den Weg zu Anton (3) - mal wieder. Dort angekommen, klingelt er und übergibt Anton den neuen braunen Briefumschlag. Anton ist schon ganz aufgeregt, muss aber vorher noch den Rückschein für Bertas Brief unterschreiben. Für den Postboten geht's dann wieder ab zu Berta, den Rückschein abliefern (4). Allmählich tun ihm schon ziemlich die Beine weg vom ganzen Gelatsche.
Derweil reißt Anton Bertas Briefumschlag mit zittrigen Händen auf und fischt den Liebesbrief heraus. Ihm weicht alle Farbe aus dem Gesicht als er sieht, dass Berta ihm mit einem schnöden "Nö" vor den Kopf stößt; er ist am Boden zerstört...
Als Berta vom Postboten den Rückschein entgegen nimmt, kommen ihr Zweifel.. War sie zu hart zu Anton? Eigentlich ist er ja doch ganz süß! Vielleicht überlegt sie es sich ja nochmal..
Am Ende des Tages weiß der Postbote was er getan hat, ihm brennen die Beine. Er ist 4x hin und her gelaufen.
----------------------
Wenn man sich obige Geschichte nun ohne die Rückscheine vorstellt, muss der Postbote deutlich weniger laufen. Anton tütet den Liebesbrief ein, der Postbote läuft los (1). Berta packt den Brief aus, liest ihn, kreuzt an (TCP), tütet ihn wieder ein und schickt ihn zurück an Anton (2). Das wäre dann eine TCP-Verbindung (der Liebesbrief zum Ankreuzen) über eine UDP-Verbindung (Briefumschlag ohne Rückschein). Einmal hin, einmal zurück.
Das ganze wird noch verrückter, wenn der Postbote unzuverlässig oder einfach nur überlastet ist. Die Rückscheine kommen nicht an, die braunen Briefe (VPN) werden nochmal geschickt. Und wenn die Rückscheine angekommen sind, dann fehlt aber plötzlich der neue braune Umschlag mit dem Liebesbrief. Also muss man auch dann nochmal schicken, natürlich immer wieder mit Rückscheinen und so...
Lange Rede, kurzer Sinn: Über instabile Verbindungen oder solche mit hoher Latenz, kann ein TCP-VPN mit TCP-Inhalt absurd viel Overhead produzieren, weil gleich zwei TCP-Handshakes parallel arbeiten und laufend Pakete neu geschickt werden. Es sollte daher für die VPN-Verbindung stets UDP gewählt werden, da so die Entscheidung TCP ja/nein der Anwendung obliegt. Das Irre ist nämlich, dass bei einem TCP-VPN auch UDP-Anwendungen in ein TCP-Korsett gezwängt werden.
Was nun VPN von einem öffentlichen Hotspot aus angeht, kommt es wie meine Vorredner schon geschrieben haben auf die Ports an. Wenn der Hotspot-Betreiber ausschließlich Surfen zulässt, dann sind in der Regel nur Port 80/443 und ggfs auch noch 53 (DNS) erlaubt. Mit Glück wird nur der Port getriggert, nicht das Protokoll.
Gängige Ports für ein VPN aus einem Fremdnetzwerk mit restriktiver Firewall heraus sind daher 53 / 80 / 443, nach Möglichkeit UDP, im Notfall TCP. Mittels DPI (Deep Packet Inspection) könnte die Firewall zwar auch erkennen ob es sich wirklich zB um DNS-Traffic auf Port 53 handelt, aber DPI schluckt Performance und ich bezweifle, dass ein simpler Hotspot in einem Cafe DPI macht.
*edit
Sorry für die lange Story, aber da durfte mal wieder der alte Pen&Paper Rollenspieler raus
