Verständnisproblem mit Port 443

[TomL]

Moin

Ganz kurz die Vorgeschichte:
Vor einigen Tagen hatte ich ein für mich neues Erlebnis. Ich hatte mir auf einer Reise am Zielort einen Zugang für das lokale WiFi gekauft, 2 € für einen Tag, also völlig ok für mich. Normales Surfen funktionierte damit einwandfrei. Um dann meine EMails abzurufen habe ich auf dem Androiden OpenVPN gestartet und war total erstaunt, dass ich keine Verbindung herstellen konnte. Ich habe dann mal zum Testen das WLAN ausgeschaltet, dafür UMTS eingeschaltet und mit dem Browser kontrolliert, ob ich ins Web komme, OpenVPN gestartet.... und siehe da, alles klappt perfekt, sowohl der Zugang in mein Netz als auch die "Surfweiterleitung" über meinen Router. Nun wieder WLAN aktiviert und erneut prüfen, obs nun klappt... keine Chance... ich habe keine Verbindung via OpenVPN herstellen können.

Ich war echt überrascht, dass ein WISP das unterbinden kann, und auch das er das überhaupt macht. Jetzt suche ich eine Möglichkeit, mein OpenVPN so zu konfigurieren, dass es damit klarkommt, in der Hoffnung, daß so etwas keine generell unlösbare Sperre ist.

Nun das Problem:
Ich habe bei meiner Suche nach einer Lösung im Web gelesen, dass die Verwendung des Port 443 möglicherweise eine Lösung wäre, weil der fürs normale Surfen immer offen sein muss. Bei meiner jetzigen Konfiguration (Routing, UDP, Port 555555) ist auf meiner Fritzbox eine Port-Weiterleitung eingerichtet, also auf Port 555555 eingehender UPD-Traffic weiterleiten auf Port 555555->IP_10.10.1.2 (der VPN-Server).

Wenn ich nun aber zur Umgehung der Blockierung einen weiteren VPN-Daemon auf dem Server starten würde, ebenfalls Routing, aber TCP, Port 443, müsste ich ja auch auf der Fritzbox eine entsprechende Weiterleitung einrichten: eingehender Traffic auf Port 443 weiterleiten auf Port 443->IP_10.10.1.2

Aber gibts da nicht einen Interessen-Konflikt...?... denn auf Port 443 der Fritzbox kommt ja in dem Fall nicht nur der mobile Roadwarraior "rein", sondern auch die anderen lokalen (?) Lan-Clients haben ja möglicherweise HTTPS-Traffic über diesen Port. Wären die auf einmal abgeschnitten, da alles auf Port 443 an IP_10.10.1.2 weitergeleitet wird?

[dufty2]

Nehmen wir an, 10.10.1.53 will auf https://debianforum.de surfen, somit
10.10.1.53:>1023 => 144.76.154.165:443
Deine Fritzbox macht daraus:
Deine_Externe_Fritzbox_IP:>1023 => 144.76.154.165:443

Die Rückpakete vom DF in ungekehrter Reihenfolge.

Wo ist da der Konflikt?

[TomL]

Aaaah ja, ich glaube, ich habs jetzt verstanden. Das, was die Lan-Clients als regulären Traffic verursachen, ergibt immer mit der IP versehene adressierte Pakete, und zwar in beiden Richtungen. Das heisst, die Pakete kommen immer an, trotz der Port-Weiterleitung im Router.
Klopft aber der Roadwarrior an die Tür, gibt's erst mal kein adressiertes Paket, weil er ja gar nicht den VPN-Server und dessen IP kennt .... und da greift dann die Weiterleitung im Router. Ich hoffe, dass ich deine Antwort so richtig interpretiert habe.

Gibt es eigentlich Sicherheitsbedenken, wenn der VPN-Server auf TCP Port 443 konfiguriert ist...?...im Vergleich zum bisher genutzten UDP Port 555555?

[uname]

555555

Hatte gedacht es gibt nur die Ports 1 bis 65535. Aber egal.

Die Wahl eines höheren Ports macht Sinn um z.B. Script-Kiddies bei SSH vom Zugriff abzuhalten. Aber wenn man sowieso keine Passwörter nutzt und nicht Angst vor DDoS hat sollte es egal. sein. TCP wird wohl im Gegensatz zu UDP etwas mehr Overhead produzieren. Aber wenn du sicher sein willst, dass der Zugriff funktioniert wirst du wohl TCP nutzen müssen.

[TomL]

555555

Hatte gedacht es gibt nur die Ports 1 bis 65535. Aber egal.

Ja, ich weiss, genau deswegen hatte ich diesen hier gewählt. Im ersten Versuch hatte ich noch 55555555 geschrieben.... aber dann dachte ich mir "och nee, da stolpert bestimmt wieder irgendeiner drüber" und dann habe ichs noch mal auf weniger auffälliges geändert.... aber leider doch erfolglos. *fg*

Ich dachte, wenn ein hoher Port für SSH gut ist, dann ist er es auch aus gleichem Grund für OpenVPN..... ist das quatsch?

Aber wenn man sowieso keine Passwörter nutzt und nicht Angst vor DDoS hat sollte es egal. sein.

Was meinst Du damit? Wo verwende ich ggf. keine Passwörter? Ich denke schon, dass ich überall Passwörter verwende.... beim VPN Zertifikate und Keyfiles.... aber vielleicht habe ich ja was vergessen? Solche Sätze sind wenig hilfreich und verunsichern mich mehr, als mir lieb ist. Ich weiss nicht, ob ich Angst vor DDOS-Attacken haben müsste. Auf meinem Rechner laufen ja keine für die Allgemeinheit offenen Dienste oder so was. Wenn mein Rechner durch irgendeinen Hacker rein zufällig gefunden würde.... tja... keine Ahnung.... was kann der denn machen? Kann er mehr machen, wenn das VPN auf TCP Port 443 anstatt auf UDP Port 555555 läuft?

TCP wird wohl im Gegensatz zu UDP etwas mehr Overhead produzieren. Aber wenn du sicher sein willst, dass der Zugriff funktioniert wirst du wohl TCP nutzen müssen.

Ja, ich weiss, TCP ist stabiler, dafür langsamer als UPD.

[eggy]

TCP in TCP ist oftmals keine wirklich gute Idee. Und da gehts nicht um den "Overhead" der ist in dem Fall vernachlässigbar, sondern darum dass sich die "Verstopfungsvermeidungstaktiken" der beiden TCP Kanäle gegenseitig das Wasser abgraben. Je nach TCP Variante und Umständen kann das ganz schön übel enden.
http://de.wikipedia.org/wiki/Transmissi ... _Avoidance

[TomL]

Moin

Wenn TCP in TCP nicht gut ist verstehe ich die ganzen Anleitungen nicht mehr. Ich habe im Web Högis Wiki gefunden, der das auch über TCP macht... und dafür Debian nutzt. Im OpenVPN-Wiki gibts auch Beispiele mit TCP. Sind die alle "nicht so sinnvoll"?

Irgendwie bewege ich mich immer weiter weg von einer Lösung. Was mach ich denn, wenn UDP aufgrund einer Blockade des ISP nicht funktioniert? Irgendeine Lösung wirds doch geben...oder?

[eggy]

Klar kannst Du TCP benutzen, Du solltest Dir nur bewusst sein, dass es (je nach Fall) eben nicht optimal ist, "etwas langsam" ist immer noch schneller als "garnicht".

[uname]

DDoS usw.:
Ein SSH-Key bzw. ein VPN-Zertifikat ist eine ganz andere Sicherheitsstufe als ein Passwort. Nur meistens erlaubt man eben doch noch nebenbei Passwörter (für den Notfall?) und so können Script-Kiddies versuchen den SSH-Server (Standard-Port 22) zu attakieren. Das ist zwar zwecklos aber lästig. Daher macht dann ein höherer Port etwas Sinn. Bei SSH-Keys und VPN-Zertifikaten sehe ich die Notwendigkeit nicht. Vielleicht kannst du den Passwort-Zugriff bei SSH ganz deaktivieren und im Notfall pyhsikalischen Zugriff bzw. eine Notfallkonsole (Provider) nutzen.

TCP für openVPN:
Natürlich ist UDP für openVPN schneller und bestimmt nicht unsicherer. Für Performance kannst du dir noch TUN vs.TAP anschauen.

Ich hatte mir auf einer Reise am Zielort einen Zugang für das lokale WiFi gekauft

Nur wenn du unterwegs bist und dir dein Gast-Provider kein UDP gibt wirst du froh sein, wenn du openVPN für TCP-Port 443 konfiguriert hast. Im übrigen kann man es wohl auch irgendwie durch HTTP-Proxies tunneln. Das wäre dann natürlich noch besser bei noch mehr Restriktionen. Das Netz ist voll von Anleitungen. Auch kannst du z.B. SSH durch einen HTTP-Proxy tunneln (connect-proxy). Leider weiß ich nicht ob das auch mit transparenten Proxies funktioniert.

[TomL]

Nur wenn du unterwegs bist und dir dein Gast-Provider kein UDP gibt wirst du froh sein, wenn du openVPN für TCP-Port 443 konfiguriert hast.

Es funktioniert genial gut Wie ich an anderer Stelle schon indirekt erwähnte, toure ich im Moment und die nächsten 3 Monate durch Skandinavien und brauche deshalb jetzt "mein" Web. Und die Generalprobe hatte ich auf der Fähre nach Trelleborg. UDP ging nicht, TCP lief super... ich hatte Spass ohne Ende. Aber erst heute habe ich zum ersten Mal ein wirklich freies Netz gefunden.

Aber an der Stelle beschäftigt mich gerade eine neue Frage. Wenn ich hier auf einem Campingplatz mit dem Lokalen WiFI (über meinen TL-WA7210N) mit dem Gastgeber-Netz verbunden bin und dieses "WAN" dann weitergebe an meinen TL-WR841N zur Verteilung als Board-Netzwerk an meine Clients, muss ich mir da über meine Datensicherheit auf meinem Laptop gedanken machen?

Der TL-WA7210N ist mit dem WISP connect'ed, und dann weiter via Patchkabel auf den WLAN-Router TL-WR841N. Meine Clients melden sich alle nur am WLAN-Router an. Imho sieht der WISP eigentlich nur den AccessPoint.. Von den Clients hinter dem WLAN-Router sollte der WISP doch eigentlich nix wissen.... oder gibts da noch irgendwelche Hintertüren, die ich vielleicht dicht machen müsste? Damals unter Windows hatte ich für solche Fälle immer die Firewall aktiviert.... ohne wirklich zu wissen, wie sinnvoll das war..... ... aber einen solchen "Schalter" gibts ja hier auf meinem Jessie nicht.

Nachtrag:
Ich bin total baff... jetzt bin ich bald 2 Stunden online.... und alles läuft via openvpn über meinen Server zuhause. Und beim normalen Surfen merke ich so gut wie keinen Geschwindigkeitsverlust.... und das, wo ich sogar doppelt WLAN'e, vom WISP zum AP und dann vom WLAN-Router zum Client.... eigentlich hätte ich erwartet, dass das träge ist, oder zäh.... isses aber nicht...