OpenVPN Verbindung aufrecht, trotzdem nicht möglich Service zu erreichen

  • Hey,


    bin ein etwas neuerer Kunde von Netcup, aber durchaus zufrieden.


    Ich miete aktuell einen KVM-Server und habe neulich versucht, einen OpenVPN-Server zu installieren.

    Auf meinem früheren Server hatte ich einen solchen schon problemlos am laufen, allerdings habe ich bei meinem neuem jetzt hier das Problem, das ich trotz aufrechter VPN-Verbindung, meinen SSH-Server nicht erreichen kann.

    Ich sitze hinter einer Schul-Firewall und da sind ziemlich alle Ports gesperrt, deshalb kann ich meinen SSH-Port nicht erreichen, das ist der Grund für mein Vorhaben.


    Also, kurz und knapp:

    VPN-Verbindung aufrecht und Serverkommunikation mit diesem möglich (TCP), Internetzugriff funktioniert ohne Probleme (d.h. google.com funktioniert), trotzdem kann ich keine SSH-Verbindung aufbauen weil der Port noch blockiert zu sein scheint = Situation im Prinzip gleich wie wenn ich keine VPN-Verbindung hätte.

    Meine IP ist die Server-IP des OpenVPN-Servers, DNS-Server-Abfrage über ipleak.net zeigt auch das die DNS-Server nicht die lokalen sind.


    Ich weiß nicht ob Netcup da irgendwas blockiert oder es einfach eine Fehlkonfiguration ist ... habe schon Google zerbombt mit meinen Suchanfragen aber ich komme einfach nicht zum Lösungsansatz.


    Ich entschuldige mich schon mal vorweg, ich bin schlecht im Beginnen einer solchen Konversation, d.h. wenn ihr zusätzliche Informationen oder Daten braucht, fragt mich - und seid mir nicht böse. :P


    Betriebssystem: Debian 10 (testing)

    Kernel / Betriebssystem: 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15) x86_64
    OpenVPN läuft über TCP - hab UDP aber auch schon ausprobiert. Keine Änderung des Problems.

    OpenVPN-Clientkonfiguration:

    Port 53 ist übrigens einer der wenigen der in der Firewall offen ist. Ich habe auf meinem Server auch keinen DNS Server laufen, d.h. das sollte kein Problem sein, hat ja auf meinem alten Server auch funktioniert.


    OpenVPN-Log zeigt nichts relevantes, keinerlei Fehler weil ich mich ja problemlos verbinden kann, gerne kann ich ihn aber zusätzlich anhängen wenn nötig.


    Sollte noch irgendwas benötigt werden, einfach Fragen. :P
    Ich bedanke mich schon mal im voraus, die Hoffnung stirbt zuletzt, ich bin schon verzweifelt.^^

  • [...] keinerlei Fehler weil ich mich ja problemlos verbinden kann, gerne kann ich ihn aber zusätzlich anhängen wenn nötig.

    Der Satz erschließt sich mir nicht. Stehen da nun wirklich keine Fehler drin oder gehst du davon aus, dass keine Fehler drin sind, weil du dich verbinden kannst? Das hat leider überhaupt nichts miteinander zu tun, von daher bitte mal die Logs hier reinposten (nachdem die Verbindung aufgebaut wurde und versucht wurde, was zu pingen). OpenVPN hat einen Control- und einen Data-Channel. Verbindungen aufbauen läuft über den Control-Channel, Glückwunsch, der scheint dann zu gehen. Den Data-Channel kann man ganz schnell über eine doofe Wahl der Komprimierung kaputtmachen, ohne, dass da viele aufschlussreiche Fehler gelogged werden. Oder das Routing ist kaputt. Oder es ist was ganz anderes. Jedenfalls: Logs würden massiv helfen den Fehler mehr zu erforschen als zu erraten. Gerne auch mit höherer Verbosität und unter Nutzung eines Paste-Services.

  • In "/var/log/openvpn" ist bei mir leider keine Log-Datei vorhanden, habe aber das in syslog angefunden.:

    Auf meinem lokalen Windows PC ist in "C:\Program Files\OpenVPN\log" ebenso nichts vorhanden. :/

    Ich habe nun interessanterweise nach ein paar Spielereien herausgefunden, das ich doch blockierte Websiten erreichen kann - allerdings komme ich trotzdem noch nicht auf meinen SSH-Server - der ist der gleiche Server mit dem ich mich per OpenVPN verbinde. Das könnte eventuell doch auf ein Routing Problem rückschließen?

  • Auf welche IP hört denn dein SSH Server?

    Code
    1. netstat -tulpn

    Überwelche IP versuchst du den SSH Server zu erreichen?


    Wie ist der SSH Port über die Firewall eingeschränkt?

    Meine (Netcup) Produkte: VPS 1000 G7 SE, S 1000 G7, VPS 200 G8 Ostern 2019, IPs, Failover..

  • Code
    1. Active Internet connections (only servers)
    2. Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
    3. tcp 0 0 0.0.0.0:PORT 0.0.0.0:* LISTEN 784/sshd

    Auf alle Interfaces wie ersichtlich.

    Ich versuche meinen Server über die ganz normale, einzige IPv4-Adresse zu erreichen. Das funktioniert ja auch ganz normal ohne VPN.^^

    Der SSH Port ist nicht eingeschränkt, er ist offen.

  • Ich versuche meinen Server über die ganz normale, einzige IPv4-Adresse zu erreichen. Das funktioniert ja auch ganz normal ohne VPN.^^

    Da liegt wahrscheinlich das Problem, damit gehst du ja am VPN vorbei und bleibst in der Firewall deiner Schule hängen.

    Versuch doch mal SSH über die VPN-Interne IP deines Servers zu erreichen.. dann geht die SSH Verbindung auch DURCH den VPN Tunnel

    Meine (Netcup) Produkte: VPS 1000 G7 SE, S 1000 G7, VPS 200 G8 Ostern 2019, IPs, Failover..

  • Lukay Ahhh ja, danke dir. Das war's, das ist die Problemlösung.
    Zugegeben, da wäre ich nie draufgekommen, da ich auf Google nicht mal einen Ansatz diesen Riechers gehabt hätte.

    Komischerweise hat es auf meinem alten Server mit der externen IPv4-Adresse funktioniert.


    Na gut, vielen Dank.^^

  • Kein Problem :)


    Bist du dir sicher, dass der Traffic wirklich durch deinen VPN läuft?


    Oder das da keine Firewall regel zwischen rein geht?


    Eigentlich müsste das auch funktionieren, aber ich bin (seit ich meine OpenVPN server aufgesetzt habe) da nicht mehr so drin..

    Meine (Netcup) Produkte: VPS 1000 G7 SE, S 1000 G7, VPS 200 G8 Ostern 2019, IPs, Failover..

  • Habe in meiner UFW Firewall meine Schul-IP und sogar die IPv4 des Servers für alle Ports auf allen Interfaces freigegeben - von daher sollte das eigentlich funktionierten.^^


    EDIT: Kann aber höchstwahrscheinlich auch daran liegen^^:

    Code
    1. *nat
    2. :POSTROUTING ACCEPT [0:0]
    3. -A POSTROUTING -s 10.8.0.0/8 -o eth0 -j MASQUERADE
    4. COMMIT
  • iptables -t nat -A POSTROUTING -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to <server-addresse>

    iptables -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

    iptables -I FORWARD -s 10.8.0.0/24 -j ACCEPT

    iptables -I INPUT -p udp --dport 1194 -j ACCEPT

    iptables -t nat -A PREROUTING -p tcp --dport 8013 -j DNAT --to 10.8.0.7:22

    iptables -t nat -A PREROUTING -p tcp --dport 8014 -j DNAT --to 10.8.0.7:80

    iptables -t nat -A PREROUTING -p tcp --dport 8088 -j DNAT --to 10.8.0.7:8088

    iptables -t nat -A PREROUTING -p tcp --dport 8901 -j DNAT --to 10.8.0.12:80

    iptables -t nat -A PREROUTING -p tcp --dport 8922 -j DNAT --to 10.8.0.12:22