DS-Lite Anschluss mit SSH-Tunnel aus den Internet erreichen?

[Arjab]

Kurzer Disclaimer, ich verstehe einiges von IT im Allgemeinen, aber wenig von Netzwerken, also bitte habt etwas Nachsicht, wenn ich hier irgendetwas Basales übersehe.

Ich versuche seit geraumer Zeit meinen Raspberry Pi mit Nextcloud (NextCloudPi) aus dem Internet zu erreichen, obwohl ich einen DS-Lite Anschluss habe, der nur eine öffentliche IPv6-Addresse hat.

Also hab' ich mir einen günstigen vServer bei Ionos gemietet und diese Anleitung angeschaut, die sich auf folgenden Befehl runterbrechen lässt, nachdem man den entsprechenden öffentlichen SSH-Schlüssel vom Raspberry Pi auf den vServer kopiert hat.

ssh -p $port1 -N -R $port2:localhost:$port3 root@$IPv4-vServer

Man erstellt also einen Tunnel mit SSH vom Client, also meines Raspberry Pis auf $port1, mappt den $port3 des Clients auf den $port2 und kommt beim Server raus. Wenn ich diesem Befehl eingebe und wie im Video erklärt mit netstat nach aktiven Verbindungen schaue, wird mir der Tunnel auch angezeigt. Aber nachdem ich unterschiedliche Port für $port2 und $port3 ausprobiert habe, z.B. auch Standard-Ports wie 80 für http oder 443 für https komme ich über die IPv4 des Servers im Webrowser zu keiner Verbindung.

Ich habe für den vServer die Ports 22, 80, 433 und auch 4443 im Web-GUI von Ionos in der Firewall erlaubt. Den Port 4443 weil auf dem das Web-GUI der Nextcloud läuft. Aber keine Ahnung, ob das sinnvoll ist.

Leider ist der vServer nicht über die IPv4 im Browser erreichbar und auch nicht über den Hostname, den ich der IPv4 des vServers mit NOIP zugewiesen habe. Ich verstehe leider auch nicht, was das Problem ist und bitte darum hier um eure Hilfe.

 

[madmax2010]

der nur eine öffentliche IPv6-Addresse hat.

nutz doch einfach die
Kann dir doch egal sein obs via IPv6 oder via IPv4 geht

Ergänzung (15. Januar 2022)

Den Port 4443 weil auf dem das Web-GUI der Nextcloud läuft.

nein. das gehoert auf 443.

Ergänzung (15. Januar 2022)

Leider ist der vServer nicht über die IPv4 im Browser erreichbar und auch nicht über den Hostname, den ich der IPv4 des vServers mit NOIP zugewiesen habe. Ich verstehe leider auch nicht, was das Problem ist und bitte darum hier um eure Hilfe.

wenn da alles sauber konfiguriert ist, wird nextcloud auch nur mit dir reden wenn du es direkt ansprichst.
was hast du da wie via no ip konfiguriert? so im detail?

 

[Arjab]

nutz doch einfach die

Wie mache ich das? Hab' gerade diese Anleitung zu DynDNS6 gefunden.

nein. das gehoert auf 443.

Das steht hier aber anders und wenn ich die lokale IP des Raspberry Pi ansurfe, leitet der mich zu dem Port weiter. Bzw. unter dem Port findet man das Web-GUI von NextCloudPi, nicht das Web-Login der eigentlichen Nextcloud. Das war wahrscheinlich mein Denkfehler.

wenn da alles sauber konfiguriert ist, wird nextcloud auch nur mit dir reden wenn du es direkt ansprichst.

Und wie "spreche" ich Nextcloud direkt an? Ich bin irgendwie davon ausgegangen, dass wenn alles richtig konfiguriert ist, ich einfach bei dem Web-GUI von Nextcloud lande.

was hast du da wie via no ip konfiguriert? so im detail?

Gar nicht so viel, ich hab' einen Hostnamen erstellt und die öffentliche IPv4 des vServers eingetragen.

 

[0x8100]

schau mal mit ss oder netstat auf dem server, wo dein $port2 lauscht. es wird wahrscheinlich auf 127.0.0.1 bzw. ::1 sein.

damit auch auf dem externen interface des servers gelauscht wird, brauchst du

ssh -p $port1 -N -R :$port2:localhost:$port3 root@$IPv4-vServer

ssh -p $port1 -N -R 1.2.3.4:$port2:localhost:$port3 root@$IPv4-vServer

wobei 1.2.3.4 die ip des servers ist. ohne angabe der ip (nur mit :) wird auf allen interfaces gelauscht. zusätzlich brauchst du in der /etc/ssh/sshd_config die zeile GatewayPorts clientspecified. ein restart/reload vom ssh dienst nicht vergessen.

 

[Arjab]

zusätzlich brauchst du in der /etc/ssh/sshd_config die zeile GatewayPorts clientspecified.

Auf dem Client? Und wenn ich die IP des Servers vor den $port2 schreibe, taucht das in netstat auf dem Server auch als 127.0.0.1:443 auf.

 

[0x8100]

Auf dem Client?

auf dem server. sonst bleibt es bei 127.0.0.1

edit: ich muss mich korrigieren. GatewayPorts clientspecified bedeutet, dass der client bestimmen kann, wer sich auf den server mit dem port verbinden kann.

ssh -p $port1 -N -R 1.2.3.4:$port2:localhost:$port3 root@$IPv4-vServer

bedeutet also, dass nur clients mit der ip 1.2.3.4 sich verbinden können. das ist zwar sicherer, aber wohl nicht das, was du möchtest. du brauchst also

ssh -p $port1 -N -R :$port2:localhost:$port3 root@$IPv4-vServer

GatewayPorts clientspecified oder GatewayPorts yes in der server-config brauchst du trotzdem. siehe auch https://www.ssh.com/academy/ssh/tunneling/example#remote-forwarding

 

[Arjab]

Oh mein Gott, vielen Dank, ich hab' gerade über die IPv4 des Servers die Nextcloud-GUI angesurft. Junge, nach gescheiterten Versuchen mit Wireguard, 6tunnel und dem ganzen Tag heute rumfrickeln mit endlich mal ein Lichtblick.

Noch eine anschließend Frage. Wenn ich auf die Nextcloud über den Browser zugreife, bekomme ich eine Meldung, dass ein Zertifikat fehlt. Weiß jemand, wie ich jetzt mit z.B. Let's Encrypt meinen vServer bzw. die DynDNS Domain "zertifiziere"?

 

[Web-Schecki]

Weiß jemand, wie ich jetzt mit z.B. Let's Encrypt meinen vServer bzw. die DynDNS Domain "zertifiziere"?

Mit Certbot ist es am einfachsten. Du musst alle Hostnamen, über die der Webserver erreichbar sein soll, in der Konfiguration des Webservers eingetragen haben. Bei Apache2 gibt es dafür die Direktiven ServerName und ServerAlias. Der Webserver muss jeweils darüber per Port 80 öffentlich erreichbar sein.

Alternativ geht die Verifizierung auch über DNS TXT-Records, aber ich denke, das ist hier aufwändiger. Zumindest, falls du bei NextcloudPi beliebig an der Apache2-Konfiguration herumpfuschen kannst, das weiß ich nicht genau. Diese Anleitung erklärt das ganze nur für diese DNS-Methode und eine andere habe ich dort nicht gefunden, also womöglich gibt es dafür auch Gründe.

 

[Arjab]

Danke, aber funktioniert das für meine Konfiguration überhaupt? Die eigentliche Nextcloud läuft ja auf meinem Raspberry Pi, während öffentliche IP und dazugehörige Domain zu dem vServer gehören.

 

[mici01]

Danke, aber funktioniert das für meine Konfiguration überhaupt? Die eigentliche Nextcloud läuft ja auf meinem Raspberry Pi, während öffentliche IP und dazugehörige Domain zu dem vServer gehören.

Ja, bei der DNS-Methode von Let's Encrypt isses im Endeffekt egal was im A oder im AAAA-Eintrag steht. Let's Encrypt interresiert eigentlich nur ob die Domäne auch wirklich die gehört. Das wird hier über den TXT-Eintrag überprüft.

 

[Web-Schecki]

Das wird hier über den TXT-Eintrag überprüft.

Oder über die ACME-Challenge. Aber auch da ist es egal, wo der Webserver steht, der antwortet. Wichtig ist nur, dass er unter der Domain erreichbar ist. Ob du danach über 6 Zwischenstellen tunnelst und erst am Ende ein Webserver steht, der tatsächlich antwortet, oder ob der Webserver direkt auf dem Host läuft, auf den die Domain zeigt, ist von außen nicht zu erkennen und spielt keine Rolle.

 

[Arjab]

Ich hab' mich jetzt nochmal hingesetzt und DynDNS für IPv6 vernünftig konfiguriert. Damit ist der SSH-Tunnel auch überflüssig und Let's Encrypt funktioniert einfach. Danke trotzdem für eure Hilfe.