IPv4-Erreichbarkeit via Portfreigabe auf einem VPS

  • Einleitung

    Ergänzend zum Beitrag IPv4-Erreichbarkeit via VPS und VPN (WireGuard) möchte ich weitere Möglichkeiten aufzeigen, einzelne Dienste im Heimnetz erreichbar zu machen.

    Übersichtszeichnung

    Auch hier zunächst eine Übersicht, was erreicht werden soll:

    Auf den ersten Blick hat sich nicht viel getan. Es besteht weiterhin eine WireGuard-Verbindung zwischen einem VPS und dem Heimnetzwerk.

    Daher gehe ich hier nicht weiter auf diese Verbindung ein, bitte im anderen Thread nachlesen.

    Der Unterschied ist, dass hier nun eine Möglichkeit besteht, auf bestimmte Ports/Dienste direkt zuzugreifen, also ohne, dass der (mobile) Client Teil des WireGuard-Netzes wird.

    Das kann durchaus gewünscht oder notwendig sein, wenn ich zum Beispiel möchte, dass meine aufwändig und mit viel Liebe gestaltete Webseite von meinem eigenen "Server" ausgeliefert wird. Dafür gäbe es weitere unzählige Optionen, gerade bei externen Hostern. Aber manchmal möchte man das vielleicht nicht nach extern geben. Zum Beispiel seine eigene Nextcloud-Instanz. Da kann es sinnvoll und einfacher sein, wenn diese an einem öffentlichen Endpunkt verfügbar ist.

    6tunnel

    Ich gehe davon aus, dass die eigentlichen Voraussetzungen bereits geschaffen wurden:

    • Die öffentliche IP des VPS ist sinnvoll im DNS registriert
    • Die WireGuard-Verbindung zwischen VPS und Heimnetz funktioniert
    • Firewall des Hosters ist konfiguriert und auch verstanden
    • Wenn konfiguriert, muss die Paket-Firewall des VPS eingehende Verbindungen zum weiterzuleitenden Port akzeptieren

    Es ist dabei unerheblich, wie die WireGuard-Verbindung etabliert ist: mit oder ohne zusätzlichem Server.

    Ich gehe daher jetzt nur auf die Kernkomponente ein, in diesem Beispiel 6tunnel (https://github.com/wojtekka/6tunnel).

    Es ist ein Applikationstunnel. Ziel ist es, dass eingehende Anfragen an den VPS transparent an das eigentliche Ziel im Heimnetz getunnelt werden.

    Dabei kann sich 6tunnel sowohl zu IPv4 als auch IPv6-Adressen verbinden. In einem abgewandelten Beispiel wird klar, warum 6tunnel hier eine gute Lösung ist.

    Zunächst muss 6tunnel installiert werden, unter Debian-basierten Systemen via:

    Code
    sudo apt install 6tunnel

    Danach lässt sich bereits ein einfacher Test machen.

    Auf dem VPS möchte ich eingehend Port 80 an Port 80 meines NAS weiterleiten:

    Code
    sudo 6tunnel 80 192.168.178.110 80
    6tunnel: warning: both local and remote addresses are IPv4
    
    sudo netstat -anp|grep 6tunnel
    tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      12705/6tunnel

    Da es eigentlich um eine Tunnelung zu einem IPv6-Ziel geht, warnt uns 6tunnel, arbeitet aber völlig korrekt.

    Im zweiten Schritt sehen wir, dass 6tunnel brav auf eingehende Verbindungen wartet.

    Testen wir von einem Client im weltweiten Netz:

    Code
    nc -v vps.meinefabelhaftedomain.de 80
    Connection to vps.meinefabelhaftedomain.de (80.90.100.110) 80 port [tcp/http] succeeded!

    Wenn wir jetzt wieder via netstat auf dem VPS die Verbindungen prüfen, sehen wir den Erfolg:

    Code
    sudo netstat -anp|grep 6tunnel
    tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      12705/6tunnel
    tcp        0      0 10.99.99.1:55188        192.168.178.110:80      ESTABLISHED 12744/6tunnel
    tcp        0      0 80.90.100.110:80        110.111.112.113:59704   ESTABLISHED 12744/6tunnel

    Wir sehen, dass der Client im weltweiten Netz (110.111.112.113) sich mit dem Ports 80 des VPS verbunden hat. Der wiederum baut zum Port 80 des fabehaften NAS eine Verbindung auf und tunnelt den Datenverkehr.

    Damit ist das Ziel bereits erreicht. Man verfährt analog zu anderen Ports, z.B. Port 443.

    Automatischer Start

    Nachteil ist, dass 6tunnel keine fertigen systemd-Units mitbringt. Nach Neustart des Servers sind die Tunnel also wieder verschwunden und müssen manuell gestartet werden.

    Schöner ist es, wenn systemd sich darum kümmert.

    Auf die Schnelle habe ich keine fertigen Beispiele gefunden, daher habe ich ein Beispiel gebastelt.

    Zunächst legen wir ein Verzeichnis an, wo wir die Konfigurationsdateien ablegen:

    Code
    sudo mkdir /etc/6tunnel

    Danach legen wir für jede Weiterleitung eine Datei an:

    Code
    ll /etc/6tunnel/
    total 16
    drwxr-xr-x  2 root root 4096 Oct 30 15:52 ./
    drwxr-xr-x 95 root root 4096 Oct 30 15:43 ../
    -rw-r--r--  1 root root   28 Oct 30 15:52 443
    -rw-r--r--  1 root root   27 Oct 30 15:50 80

    Wir brauchen nur wenige Informationen:

    Code
    cat /etc/6tunnel/80
    TARGET=192.168.178.110
    PORT=80
    
    cat /etc/6tunnel/443
    TARGET=192.168.178.110
    PORT=443

    Wir legen eine Template-Unit an:

    Ich habe eine Abhängigkeit zum WireGuard-Tunnel gesetzt. Aber selbst ohne, dürfte das kein Problem sein.

    Nun aktivieren wir je eine Unit je Freigabe:

    Code
    sudo systemctl enable 6tunnel@80
    Created symlink /etc/systemd/system/multi-user.target.wants/6tunnel@80.service → /lib/systemd/system/6tunnel@.service.
    
    sudo systemctl enable 6tunnel@443
    Created symlink /etc/systemd/system/multi-user.target.wants/6tunnel@443.service → /lib/systemd/system/6tunnel@.service.

    Nach Neustart sehen wir, dass die Units geladen wurden und 6tunnel seine Arbeit aufgenommen hat.

    Das geht bestimmt noch ausgefeilter, erfüllt aber zunächst seinen Zweck.

    Ausblick

    In weiteren Abwandlungen geht es um die Idee, Ports durch den TCP/IP-Stack mithilfe von iptables weiterzuleiten.

    Ebenso wird es um eine Lösung gehen, wo der VPS sich ohne Hilfe von WireGuard direkt mit dem IPv6-Ziel des Heimnetzes verbindet.

    Dafür gibt es natürlich auch (kostenpflichtige) Lösungen am Markt, wie z.B. https://www.feste-ip.net/dslite-ipv6-po…-informationen/.

    Diese Lösung ist nicht besser oder schlechter und ohne Hilfe eines VPS einrichtbar. Wer Lust und Erfahrung hat, kann ja dazu vielleicht ein kleines Tutorial erstellen.

    3 Mal editiert, zuletzt von mbo77 (31. Oktober 2023 um 14:00)

  • Variation mit iptables

    Die oben beschriebene Lösung lässt sich auch direkt im Linux-Kernel lösen. Das hat den Vorteil, dass keine weitere Software gebraucht wird und die Lösung potenziell performanter ist.

    Übersichtszeichnung

    Wie schaut das ganze aus? Ziemlich ähnlich zur 6tunnel-Lösung.

    Anstelle der 6tunnel-Software konfigurieren wir die Paket-Firewall.

    NAT-Tabelle

    Zunächst einmal setzen wir in der NAT-Tabelle ein paar Regeln, welche eingehende Pakete mittels S(ource)NAT und D(estination)NAT zwischen den Systemen entsprechend umbaut:

    Code
    sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.178.110:80
    sudo iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination 192.168.178.110:443

    Damit werden eingehende Pakete, die für tcp/80 und tcp/443 für andere Ziele umgebaut, also auf ein neues Ziel ge-DNAT-et.

    Wenn Pakete nun so maskiert zurückkommen, müssen wir das wieder umkehren:

    Code
    sudo iptables -t nat -A POSTROUTING -p tcp --dport 80 -d 192.168.178.110 -j SNAT --to-source 10.99.99.1
    sudo iptables -t nat -A POSTROUTING -p tcp --dport 443 -d 192.168.178.110 -j SNAT --to-source 10.99.99.1

    Da die Pakete an das eigentliche Ziel zuvor von der Adresse 10.99.99.1 verschickt wurden, bauen wir die Pakete wieder zurück, SNAT-en sie also wieder zurück für die Quelle.

    Zur Kontrolle werfen wir jetzt einen Blick auf die Tabelle:

    Damit durchlaufen eingehende Pakete die NAT-Tabelle und werden bei Bedarf entsprechend umgebaut.

    FORWARD-Tabelle

    Im ersten Schritt sind die Pakete für ein FORWARDing vorbereitet und manipuliert worden.

    Jetzt gilt es in der FORWARD-Tabelle dafür passende Regeln anzulegen.

    Code
    sudo iptables -A FORWARD -i ens6 -o wg0 -p tcp --syn --dport 80 -m conntrack --ctstate NEW -j ACCEPT
    sudo iptables -A FORWARD -i ens6 -o wg0 -p tcp --syn --dport 443 -m conntrack --ctstate NEW -j ACCEPT

    Damit werden neue Weiterleitungen akzeptiert. Damit auch die dazugehörigen Pakete akzeptiert werden, müssen wir diese Pakete in der Tabelle auch zulassen.

    Code
    sudo iptables -A FORWARD -i ens6 -o wg0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
    sudo iptables -A FORWARD -i wg0 -o ens6 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

    Ich hätte die Regeln zwar auch ein wenig zusammenfassen können, aber zum Zwecke der Nachvollziehbarkeit lasse ich sie so.

    Kontrolle und Sicherung der Arbeit

    Damit ist die Arbeit getan, Zeit für eine konkrete Kontrolle aus dem weltweiten Netz:

    Code
    nc -v vps.meinefabelhaftedomain.de 80
    Connection to vps.meinefabelhaftedomain.de (80.90.100.110) 80 port [tcp/http] succeeded!
    
    nc -v vps.meinefabelhaftedomain.de 443
    Connection to vps.meinefabelhaftedomain.de (80.90.100.110) 443 port [tcp/https] succeeded!

    Das sieht schon mal gut aus.

    Schauen wir auf dem fabelhaften NAS mal nach diesen Verbindungen:

    Code
    sudo netstat -anp|grep 10.99.99
    tcp6       0      0 192.168.178.110:80          10.99.99.1:37970        SYN_RECV    -
    
    sudo netstat -anp|grep 10.99.99
    tcp6       0      0 192.168.178.110:443         10.99.99.1:52682        SYN_RECV    -

    Wenig überraschend geht die Verbindung nun von 10.99.99.1 aus, also dem System, was im weltweiten Netz die Anfragen via IPv4 entgegennimmt.

    Für die grundlegende WireGuard-Verbindung hatte wir ja schon Regeln angelegt. Nachdem wir nun weitere ergänzt haben, gilt es diese auch zu speichern:

    In meinem Beispiel habe ich die Firewall noch so konfiguriert, dass sie eingehende Verbindungen zum SSH-Port 22 und natürlich udp/52823 für WireGuard akzeptiert.

    Das habe zwecks Anschauung drin gelassen.

    Abschließend

    Zudem bitte folgendes beachten: In der Regel sind die Policies für die Tabellen auf ACCEPT gestellt. Das heißt, unsere ganzen schönen Regeln sind nutzlos, wenn wir das Tor ohnehin weit aufsperren.

    Im Basissetup mit dem Wireguard-Anteil habe ich die Policy für FORWARD daher zunächst auf DROP gestellt, bevor konkrete Regeln bestimmten Traffic wieder zulassen.

    Es gilt bei dem VPS zu beachten, ob der Hoster das bereits mit einer externen Firewall sichert.

    Die muss alle Ports zulassen, mit denen ihr arbeiten wollt. Also eingehend Richtung Port 22, falls ihr SSH wünscht. Aber auch die Ports für WireGuard und auch die weiterzuleitenden Ports.

    Aber nicht irritieren lassen: In der Paket-Firewall des VPS müssen die Ports, die weitergeleitet werden sollen, in der INPUT-Tabelle nicht geöffnet werden. Die Pakete für die Ports 80 und 443 erreichen diese Tabelle nämlich nie, sondern laufen durch NAT->FORWARD->NAT.

    Und das ist ein technischer wesentlicher Unterschied zur 6tunnel-Lösung. Dort wird die eingehende Verbingung von 6tunnel terminiert und eine neue Verbindung zum Ziel aufgebaut. Hier manipulieren wir die Pakete und leiten sie direkt in der Paket-Firewall/TCP-Stack weiter.

    Einmal editiert, zuletzt von mbo77 (31. Oktober 2023 um 07:42) aus folgendem Grund: Firewall-Regeln waren unvollständig.

  • mbo77 30. Oktober 2023 um 17:50

    Hat den Titel des Themas von „IPv4-Erreichbarkeit via Portfreigabe auf einem VPS und VPN (WireGuard)“ zu „IPv4-Erreichbarkeit via Portfreigabe auf einem VPS“ geändert.
  • Variation ohne WireGuard und 6tunnel

    Im letzten Beispiel zeige ich eine Möglichkeit auf, wie man Freigaben im Heimnetz via IPv4 erreichbar machen kann, wenn die Ziele bereits via IPv6 erreichbar sind.

    Dazu ist dann keine WireGuard-Konfiguration mehr notwendig.

    Ich habe versucht, im bekannten Diagramm die Änderungen so übersichtlich wie möglich einzubauen - gar nicht so trivial.

    IPv6-Konfiguration

    Wesentlich für die Lösung ist, dass unser fabelhaftes NAS über eine öffentliche IPv6-Adresse erreichbar ist.

    Im fiktiven Beispiel wurde durch die FritzBox ein Prefix 2003:e1:2222:3333::/64 für die Teilnehmer festgelegt.

    Das fabelhafte NAS sollte sich entsprechend eine IPv6-Adresse darin vergeben haben. Dies kann man am System ermitteln und ist abhängig vom (Betriebs-)System.

    Portfreigabe im Router

    Unabhängig davon, ob man später die Freigabe per IPv4 oder IPv6 erreichen möchte, muss dieser aber im Router vorhanden sein.

    In der FritzBox geht man dabei genauso vor, wie bei einer IPv4-Freigabe. Es gibt dabei die Option, Freigaben für IPv4, IPv6 oder beides einzurichten.

    Zudem habt ihr die Möglichkeit, den Host-Anteil zu setzen. Dies sollte man sich ansehen, insbesondere Apekte wie EUI-64, Stable-Privacy und sich ändernden Host-Anteilen (Privacy Extensions). Die FritzBox soll sich ändernde Host-Anteile zwar automatisch erkennen, aber da habe ich widersprüchliche Erfahrungen gemacht.

    IPv6-Adresse im (Dyn-)DNS registrieren

    Unser Ziel soll/muss natürlich via Name erreichbar sein.

    Hierbei ist es wichtig zu verstehen, dass nicht mehr die FritzBox die Registrierung übernimmt, denn jedes Endgerät hat ja nun seine eigene öffentliche IPv6-Adresse. Hier gibt es eine Vielzahl von Lösungen, z.B. https://ddclient.net/.

    Unser fabelhaftes NAS, was vielleicht ein Gerät von Synology oder QNAP ist, bietet hier möglicherweise Optionen in der GUI.

    Man hat jetzt verschiedene Möglichkeiten, entsprechende Records anlegen zu lassen.

    Denkbar ist, dass man einen AAAA-Record für nas.meinefabelhaftedomain.de vornimmt.

    Auch denkbar ist, dies logisch weiter zu strukturieren, z.B. via nas.ipv6.meinefabelhaftedomain.de.

    Dies bleibt jedem selbst überlassen.

    Sobald alles vorbereitet ist, kann man vom VPS die Verbindung prüfen:

    Code
    nc -v nas.ipv6.meinefabelhaftedomain.de 80
    Connection to nas.ipv6.meinefabelhaftedomain.de (2003:e1:2222:3333:1:2:3:4) 80 port [tcp/http] succeeded!

    6tunnel

    Wie im ersten Beitrag kommt jetzt wieder 6tunnel zum Einsatz, um zwischen IPv4 und IPv6 zu tunneln.

    Dabei müssen wir das Ziel für den Tunnel etwas anpassen:

    Code
    cat /etc/6tunnel/80
    TARGET=nas.ipv6.meinefabelhaftedomain.de
    PORT=80
    
    cat /etc/6tunnel/443
    TARGET=nas.ipv6.meinefabelhaftedomain.de
    PORT=443

    Anstatt auf private Adresse via WireGuard zu verbinden, baut 6tunnel nun eine direkte Verbidung zur Freigabe im IPv6-Netz auf.

    Wir testen aus dem weltweiten Netz:

    Code
    nc -v vps.meinefabelhaftedomain.de 80
    Connection to vps.meinefabelhaftedomain.de (80.90.100.110) 80 port [tcp/http] succeeded!

    Kontrolle auf dem VPS:

    Code
    sudo netstat -anpW|grep 6tunnel
    tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      1219/6tunnel
    tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      1215/6tunnel
    tcp        0      0 80.90.100.110:80        110.111.112.113:43390   ESTABLISHED 1235/6tunnel
    tcp6       0      0 2a02:247a:2222:3333:1::1:42680 2003:e1:2222:3333:1:2:3:4:80 ESTABLISHED 1235/6tunnel

    Das sieht gut aus. Eingehend wird eine IPv4-Verbindung genutzt, ausgehend zum Ziel dann eine IPv6-Verbindung.

    Epilog ;)

    Und das soll es jetzt erstmal gewesen sein. In beiden Threads sind verschiedene Optionen aufgezeigt, um das Problem der Erreichbarkeit via IPv4 zu lösen.

    Dabei gibt es sogar eine Lösung, wenn der Provider nicht mal IPv6 anbietet und zudem IPv4 mittels CG-NAT realisiert. Wie ich gehört habe, soll es so etwas geben.

    Das hat keinen Anspruch auf Vollständigkeit. Es sind auch Optionen wie ein Reverse-Proxy o.ä. denkbar.

    Aber das darf dann gerne jemand anderes erklären.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Hier noch eine knappe Betrachtung bzgl. der Performance.

    Ich habe gegen meinen VDSL-Anschluss mit 40 Mbps Upload getestet. Diese konnte ich auch voll ausreizen.

    Der besagte VPS für 1€/Monat kommt ja mit nur einer vCPU. In Zeiten, wo jedes Smartphone etliche Kerne mitbringt, mag das wenig erscheinen, aber es geht ja auch nur darum, etwas Traffic zu verarbeiten.

    Es gibt zwei Komponenten, die CPU-Zeit benötigen: WireGuard und 6tunnel.

    Wenn der Kernel selbst filtert und weiterleitet, lag das im Grundrauschen des Systems und wurde durch WireGuard überdeckt.

    Im Mittel konnte ich 90% idle am System beobachten. Wenn 6tunnel den Traffic direkt zu einem IPv6-Ziel transportiert hat oder wenn iptables/WireGuard die Pakete verarbeitet hat.

    Selbst im schlechtesten Fall, wenn WireGuard und 6tunnel zu tun hatten, lag das System noch bei mindestens 75% idle.

    WireGuard hat dabei den größten Impact, da der Traffic verschlüsselt wird. 6tunnel bleibt moderat unter 10% Last.

    So ein VPS mit 1 vCPU ist wohl ohne Bedenken für mehrere hundert Mbps gut. Danach müsste man ggf. über ein potenteres VPS nachdenken. ;)

    PS: Speicher ist ohnehin unerheblich. Der verfügbare Speicher von 0,85/1 GB ist nur zu ca. 250 MB genutzt.

  • Hallo und danke erst einmal für die tollen Anleitungen.

    Ich habe nun eine Verbindung von meiner Fritzbox auf einen VPS mit Wireguard herstellen können. Auf dem VPS habe ich NGNIX Proxy Manager installiert und alles ist auch soweit von außen erreichbar auf meinen Unraid Server.

    Nur bei einen Server habe ich Probleme, dabei gehts um einen game Server welcher als Docker läuft, welcher aber nur über ipv4 funktioniert. Nun ist es aber so, dass dieser Server immer über meine öffentliche IP geht welche hinter den cgnat liegt.

    Und irgendwie habe ich noch einen Knoten im Kopf, wie ich diesen Server dazu bringe nur über den VPS zu gehen und nicht über den carrier.

    Man kann zwar bei der Fritzbox allen ipv4 Traffic über wireguard laufen lassen, dass wollte ich aber vermeiden, mir würde hier nur der eine Server reichen und alles andere von außen geht eh über den ngnix. wäre über einen Tip dankbar?

  • Und irgendwie habe ich noch einen Knoten im Kopf, wie ich diesen Server dazu bringe nur über den VPS zu gehen und nicht über den carrier.

    Vermutlich ein Routing Problem. Macht der VPN Endpoint auf dem Unraid NAT? Wie routest du in den Container? Visualisiere am besten mal den ganzen Pfad vom VPS in den Container mit allen IPs und Routen.

    Vermutlich brauchst du policy based Routing dafür.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • ja es war ein Routing Problem. Ich musste in der fritzbox den Server Definieren und dann im VPS über die iptables von wg0 auf den öffentlichen Port gehen. jetzt muss ich nur noch Herausfinden wie ich die UDP Ports vom VPS zum eigenen Server forwarden. 6Tunnel scheint ja nur TCP zu machen.

  • Hallo,

    leider funktioniert es bei mir mit 6tunnel auch nicht. Folgendes Szenario:

    ich habe eine NAS hierauf läuft in der "webstation" eine Nexcloud instanz. Aus einem ipv6 Netzwerk erreiche ich auch meine Nexcloud instanz. Im ipv4 leider nicht auch ein ping ist nicht möglich. Ich habe über einen vps server 6tunnel 443 ipv6 adresse der nas 443 und auch über port 80 versucht. Beide Ports sind auch in der Fritzbox freigeschaltet.

    Kann mir jemand weiterhelfen. Diverse Anleitung durchgegangen überhaupt kein Erfolg. Wireguard ist keine Option, da ich teilweise Freigaben über nextcloud habe und nicht die Benutzer noch wireguard erklären möchte.

    Gruß coldjack

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Aus einem ipv6 Netzwerk erreiche ich auch meine Nexcloud instanz.

    Bedeutet das "irgendein" IPv6 Netz oder deins zu Hause? Und wie genau erreichst du sie, falls es ein Zugriff von außen ist? Direkt über die IPv6 Freigabe deines Routers?

    Ich habe über einen vps server 6tunnel 443 ipv6 adresse der nas 443 und auch über port 80 versucht.

    Zu 6tunnel gehören ja noch deutlich mehr Parameter, vor allem auch die lokalen Adressen des Servers. Wie ist denn die gesamte Konfiguration?

  • Hallo, also sowohl aus meinem ipv6 Netzwerk als auch einem externen ipv6 Netzwerk erreiche ich die synology/nextcloud Instanz.

    Die ports sind in der fritzbox freigegeben.

    6tunnel 443 ipv6 Adresse der nas 443.

    Einmal editiert, zuletzt von coldjack (6. Juli 2024 um 11:20)

  • 6tunnel 443 ipv6 Adresse der nas 443.

    Das beantwortet noch nicht meine Frage. Zeige mal mit "netstat -tulpen", ob 6tunnel die Ports auf deinem Server richtig öffnet. Und dann musst du noch die Firewall-Regeln zeigen, ob die 6tunnel Ports eingehend und ausgehend offen sind.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Welche Prozesse laufen denn, wenn du mit

    Code
    ps -ef|grep 6tunnel

    prüfst?

    Du kannst die notwendigen Tunnel auch einfach in deiner Session starten, um erstmal die Funktion zu prüfen.

    Ist denn ein "nc -v" auf die Zieladresse und Port erfolgreich?

  • ps - ef | grep 6 tunnel:

    root 1208124 1 0 Jul05 ? 00:00:00 6tunnel 1194 ds218.x.myfritz.net 1194

    root 1820571 1820564 0 14:07 pts/0 00:00:00 grep 6tunnel

    mehr läuft da nicht.

    Wenn ich manuell 6tunnel 443 ipv6 nas Adresse 443 eingebe kommt

    bind: Address already in use

    nc -v ipv6 adresse 443

    forward host lookup failed: Unknown host

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • OK, schau mal in deine Liste. Auf dem VPS läuft ja bereits etwas auf Port 443.

    Bitte prüf das System und schalte alles aus, was da nicht laufen soll/muss. Zum Beispiel Web-Server.

  • Genau. Das Problem ist, dass andere Dienste die Ports blockieren.

    Wenn ich die Liste der offenen Ports sehe, dann kann ich nur inständig hoffen, dass du die Firewall restriktiv konfiguriert hast. Da sind unverschlüsselte Mail und POP3 Ports etc. offen. Das ist in heutigen Zeiten sicherheitstechnisch eine Vollkatastrophe.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Wenn ich die Liste der offenen Ports sehe, dann kann ich nur inständig hoffen, dass du die Firewall restriktiv konfiguriert hast. Da sind unverschlüsselte Mail und POP3 Ports etc. offen. Das ist in heutigen Zeiten sicherheitstechnisch eine Vollkatastrophe.

    Du weißt aber schon, dass gerade Mail, POP3 und IMAP auch erst innerhalb der Verbindung Verschlüsselung aktivieren können. STARTTLS ist hier das Stichwort.

  • Mag sein. Trotzdem ist ein offener Port 25 für die meisten Blacklists ein Grund, den Mailserver zu sperren. Und dafür gibt es Gründe - und zwar mehr als einen.