IPv6 Portmapper

Crys

Lt. Commander
Registriert
Apr. 2009
Beiträge
1.634
Hallo miteinander,

ich muss einen DS-Lite Anschluss mit privater Cloud betreuen. Diese ist aktuell nur per IPv6 erreichbar. Deshalb wurde mir [1] ein IPv6 Portmapper (von feste-ip.net) empfohlen.
Ich habe mich daran versucht und kann leider den entsprechenden Support nicht erreichen und das dortige Forum ist gerade zu.

Nach der Anleitung [2] "V2 - PORTMAPPER FÜR IPV6 FÄHIGE ENDGERÄTE OHNE AVM MYFRITZ!" habe ich
  • im Router Port 80 und 443 für IPv4 und IPv6 freigegeben (Zugang per Domain auf IPv6 oder direkt per IPv6 funktioniert schon lange)
  • dann habe ich einen Portmapper erstellt (wie in Anleitung beschrieben) und Domain, ID, PW und URL (Schema: de3.portmap64.net:40088) erhalten.
  • In der Cloud (Ubuntu 18) habe ich im DDClient Einstellungen gemacht [3].
  • Wenn ich die neue Domain EXAMPLE.feste-ip.net jetzt öffne, komme ich auf die Cloud, aber weiterhin nur per IPv6
  • Wenn ich dig -t AAAA EXAMPLE.feste-ip.net (IPv6) untersuche, komme ich auf die korrekt IPv6 (der Cloud)
  • Wenn ich dig -t A EXAMPLE.feste-ip.net (IPv4) untersuche, komme ich auf die falsche IPv4 Adresse, über welche ein DS-Lite Anschluss nicht erreichbar ist.
In meiner /etc/ddclient.conf
Code:
protocol=dyndns2
usev6=if, if=enp2s0
if-skip=Scope:Link
server=members.feste-ip.net
web=checkip.feste-ip.net
daemon=75
pid=/var/run/ddclient.pid
login=123456
password=PWD
EXAMPLE.feste-ip.net
Per ddclient -daemon=0 -debug -verbose -noquiet kommt kein Fehler

Die Weiterleitung sieht auch korrekt aus!?
1650885999056.png


Mit dieser URL habe ich aber nie etwas angefangen:
1650886079094.png


Wie bekomme ich den IPv6 Portmapper zum laufen?

Vielen Dank!



[1] https://www.computerbase.de/forum/t...pv4-netzwerken-auf-ipv6-heimnetzwerk.2077976/ @Web-Schecki @riversource @Mr. Robot et al
[2] https://www.feste-ip.net/dslite-ipv6-portmapper/ddns-portmapper/
[3] https://www.feste-ip.net/ddns-service/einrichtung/linux/
 
Erstmal muss ich sagen: Top Beitrag!

Crys schrieb:
  • Wenn ich dig -t AAAA EXAMPLE.feste-ip.net (IPv6) untersuche, komme ich auf die korrekt IPv6 (der Cloud)
  • Wenn ich dig -t A EXAMPLE.feste-ip.net (IPv4) untersuche, komme ich auf die falsche IPv4 Adresse, über welche ein DS-Lite Anschluss nicht erreichbar ist.
Warum erwartest du unter A EXAMPLE.feste-ip.net eine IPv4 Adresse, die korrekt sein soll? Es läuft doch über de3.portmap64.net, welches dann von feste-ip auf deine AAAA Adresse weiterleitet.
Oder versteh ich dich falsch?
 
  • Gefällt mir
Reaktionen: Crys
gaym0r schrieb:
Warum erwartest du unter A EXAMPLE.feste-ip.net eine IPv4 Adresse, die korrekt sein soll?
Das erwarte ich nicht. Das ist nur eine Feststellung.
Das einzige, was ich erwarte, ist, wenn ich per IPv4-Anschluss die Domain aufrufe, dass ich dann korrekt weitergeleitet werde. Wie teste ich das korrekt?
 
Achso, das klang für mich irgendwie so als wäre das ein Problem. :)
Ich würde https://de3.portmap64.net:xxxxx ansurfen und schauen was passiert.
 
  • Gefällt mir
Reaktionen: Belgeron
gaym0r schrieb:
Ich würde https://de3.portmap64.net:xxxxx ansurfen und schauen was passiert.
Ich habe mal den Port (mittlere Spalte) auf 80 und 443 geändert. Jetzt komme ich mit den URLs auch auf die Cloud, aber nur vom IPv6 Anschluss.
Am IPv4 Anschluss wird bei diesen beiden URL die Verbindung abgebrochen. Bei der EXAMPLE.feste-ip.net Domain kommt nach einpaar Minuten immer ein Timeout ...

... irgendwas stimmt da nicht.
Ergänzung ()

Anhang anzeigen 1211895
Was muss hier unter IPv6 und IPv4 stehen?
 
Ich habe es an einem anderen IPv4 Anschluss getestet, dort gehen die beiden "Per IPv4 erreichbar über" URLs:
1650912999045.png

Die EXAMPLE.feste-ip.net Domain geht aber auch nicht.

An meinen anderen IPv4 Anschluss sind ausgehende Ports blockiert, inklusive den beiden :5xxx6 und :1xxx4 Port. Deshalb geht es dort nicht.

Aber wieso geht die EXAMPLE.feste-ip.net generell nie in Netzwerken, die kein IPv6 können?
 
Hi,

EXAMPLE.feste-ip.net ist nur via IPv6 erreichbar. Ohne IPv6 Adresse am Anschluss, von welchem darauf zugegriffen wird, wird das nichts ;) Für legacy IPv4 Anschlüsse musst du "de3.portmap64.net:<deine zugewiesenen Portnummer>" verwenden. Die Anfrage wird dann von IPv4 auf IP6 zum hinterlegten Ziel auf EXAMPLE.feste-ip.net gemappt und erreicht das Ziel dann per hinterlegter IPv6 Adresse.
 
  • Gefällt mir
Reaktionen: Web-Schecki und Crys
Tom_123 schrieb:
Für legacy IPv4 Anschlüsse musst du "de3.portmap64.net:<deine zugewiesenen Portnummer>" verwenden. Die Anfrage wird dann von IPv4 auf IP6 zum hinterlegten Ziel auf EXAMPLE.feste-ip.net gemappt und erreicht das Ziel dann per hinterlegter IPv6 Adresse.
Der Nutzen der EXAMPLE.feste-ip.net ist dann aber hinfällig!? Als Nutzer benötigt man diese Domain dann ja wirklich nie!?

Man muss aber immer den festen Post (:12345) mit angeben!?
In meinem Fall ist es ja der Sinn, dass die bestehende Domain "cloud.example.com" verwendet werden soll. Dies ist dann aber nicht möglich, außer man gibt hier auch immer die Portnummer "cloud.example.com:12345" mit an!?

Dann kommt in meinem Fall nur ein dedizierter Portmapper infrage, weil dort "IPv6 Host" URL der "Per IPv4 erreichbar über" URL entspricht!?
Oder ein vServer?
 
Crys schrieb:
Der Nutzen der EXAMPLE.feste-ip.net ist dann aber hinfällig!? Als Nutzer benötigt man diese Domain dann ja wirklich nie!?
Da sich der IPv6-Präfix durchaus mal ändern kann, ist es evtl. schon praktisch. Das Problem hast du aber schon für cloud.example.com gelöst? Dann brauchst du technisch gssehen nicht noch einen weiteren DynDNS-Dienst.

Crys schrieb:
Man muss aber immer den festen Post (:12345) mit angeben!?
Ja. Deswegen heißt das Ding "Portmapper": Der Anbieter mappt einen IPv4-Port irgendeines Servers von ihm auf deinen IPv6-Port. Wenn er nicht gerade Port 443 auf 443 oder 80 auf 80 mappt, dann musst du den Port entsprechend mit angeben.
Willst du das nicht, dann brauchst du eine IPv4-Adresse, deren Port 80 bzw. 443 du in Eigenregie mappen kannst. Ein vServer wäre eine Möglichkeit.
 
  • Gefällt mir
Reaktionen: Crys
Ok, dann wir langsam alles klarer. Auch, dass es einfach das Falsche für meinen Anwendungsfall ist.


Dann bleibt nur noch ein vServer mit eigenem Portmapper übrig?
Eine statische IPv4-Adresse [1] heißt hier schon eine einmalige IPv4-Adresse? (nicht wie bei DS-Lite geteilt?)

Es werden mehrere Domains über diesen vServer laufen. Deshalb muss ich mit nginx oder Apache arbeiten!?
Ich finde aber keine Anleitung zu "6tunnel mit Apache" oder Ähnliches, dass je nach (angefragter) Domain anders gehandhabt wird. Habt ihr da was für mich?

[1] https://www.netcup.de/vserver/vps.php#v-server-details
 
Crys schrieb:
Dann bleibt nur noch ein vServer mit eigenem Portmapper übrig?

Oder ein kommerzieller Anbieter, der dir auch Port 443 (oder alle Ports) mappt. Das dürfte natürlich teurer sein, weil er eine IP quasi nur für dich braucht, statt sie mit 65000 Kunden zu teilen.

Edit: feste-ip.net bietet das wohl für 35 € / Jahr an.

Crys schrieb:
Eine statische IPv4-Adresse [1] heißt hier schon eine einmalige IPv4-Adresse? (nicht wie bei DS-Lite geteilt?)

Ja.
Wobei dir eine öffentliche, aber dynamische IP-Adresse reichen dürfte.
Statisch bedeutet, dass sie sich nie ändert. Das ist meist teurer.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Crys
Crys schrieb:
Eine statische IPv4-Adresse [1] heißt hier schon eine einmalige IPv4-Adresse? (nicht wie bei DS-Lite geteilt?)
DS-lite ist eine Tunneltechnik, die meines Wissens nur für die Anbindung von Endkunden zum Einsatz kommt. NAT wäre im Rechenzentrum theoretisch eine Möglichkeit, gerade bei vServern. Meines Wissens aber eher unüblich.
Wenn du eine statische IPv4-Adresse bekommst, dann würde ich davon ausgehen, dass diese öffentlich routbar ist und kein NAT eingesetzt wird.

Crys schrieb:
Es werden mehrere Domains über diesen vServer laufen. Deshalb muss ich mit nginx oder Apache arbeiten!?
Ich finde aber keine Anleitung zu "6tunnel mit Apache" oder Ähnliches, dass je nach (angefragter) Domain anders gehandhabt wird.
Ich glaube, du wirfst hier etwas gewaltig durcheinander. 6tunnel und Apache haben schlicht nichts miteinander zutun.
6tunnel ist ein Programm, mit dem du über einen IPv6-Tunnel einen Portmapper realisieren kannst. Der komplette eingehende IPv4-Traffic auf Port x wird an die angegebene IPv6-Adresse auf Port y "gemappt" (und die Antworten umgekehrt genauso). Zwischendrin wird der Traffic nicht angefasst oder gar verändert.

Du sagst, es werden mehrere Domains über diesen Server laufen. Das ist grundsätzlich mit 6tunnel kein Problem, aber die Anfragen auf Port 443 können damit halt nur zu genau einem IPv6-Server getunnelt werden. Wenn diese Domains also zu unterschiedlichen Servern gehören, dann wird das wieder nichts, wenn du nicht auch zusätzliche Ports einsetzen willst.

In diesem Fall kannst du einen sogenannten Reverse Proxy auf dem vServer konfigurieren. Dafür kommen z.B. Apache oder nginx in Frage. Hierbei wird der Traffic nicht einfach nur getunnelt: Wenn der Reverse Proxy eine eingehende (korrekte) HTTP-Anfrage erhält, dann stellt er eine neue Anfrage an den hinterlegten "Content"-Server (via IPv6). Dessen Antwort wird dann, eventuell verändert, als Antwort an die ursprüngliche Anfrage zurückgesendet.
Im Gegensatz zu einem Tunnel werden also nicht nur Ports gemappt und der Traffic stumpf hin- und hergeschoben, sondern Anfragen entgegengenommen und interpretiert. Das ganze geht also in höhere OSI-Schichten. Der Rechenaufwand ist höher; u.a. muss man ja die Anfrage lesen, interpretieren, usw. Die Verschlüsselung zum Client via TLS musst du entsprechend auch nochmal machen, weil sie logischerweise nicht bis zum Content-Server gehen kann - sonst könnte der Reverse Proxy in der Mitte die Anfrage nicht lesen.

Der Vorteil für diese ganzen Mehraufwand: Da der Reverse Proxy die Antwort liest und interpretiert, kann er sie auch - je nach angegebenem Host - an den entsprechenden Content-Server weiterleiten.
Du kannst also alle Domains auf den Reverse Proxy zeigen lassen und diesen auf 80/443 hören lassen.
Kommt dann eine Anfrage an den Host a.example.com, befragt der Proxy z.B. den Content-Server abc.dyndns.com.
Kommt hingegen.eine Anfrage an b.example.com, dann befragt er xyz.dyndns.com.

Zur Konfiguration gibt es sicher zahlreiche Anleitungen unter dem Stichwort "Reverse Proxy" - ganz trivial ist es aber sicherlich nicht. Ich rate dir, dich damit genau auseinanderzusetzen - du solltest genau wissen, was du tust, sonst bekommst du schnell Probleme.
 
  • Gefällt mir
Reaktionen: Crys
@Web-Schecki ja.

Auf meinem vServer:
IPv4 Anfrage: Reverse Proxy auf die IPv6-Adresse der Cloud.
IPv6 Anfrage: Der Reverse Proxy geht auch, aber ich möchte Traffic-Schonender arbeiten: Wie leite ich nur für IPv6 Anfragen auf eine spezielle Domain die Anfrage um, ohne Traffic zu verursachen (oder zumindest nur minimalen)?
Per hosts, iptables, ...?

Und wie lasse ich die IPs automatisch aktualisieren? Bisher nutze ich WebServerApps mit ddclient. Einen offiziellen ddserver finde ich nicht!?
 
Eventuell kannst du den Reverse Proxy entsprechend konfigurieren. Wenn die Domain relevant ist, an die die Anfrage geht, wirst du weiter unten in der OSI-Schicht nichts erreichen können. Die ist nämlich Teil vom HTTP-Request (Host-Headerfeld) und damit in der Anwedungsschicht...

Welche IPs willst du aktualisieren? Die von den Content-Servern? Würde einfach weiterhin mit einem DynDNS-Dienst arbeiten...
 
  • Gefällt mir
Reaktionen: Crys
Web-Schecki schrieb:
Eventuell kannst du den Reverse Proxy entsprechend konfigurieren.
Das würde dann aber ja in jeden Fall dazu führen, dass der volle Traffic über den Reverse Proxy Server läuft!?
Ich dachte eher an einen AAAA-Record vor dem Proxy!?

Web-Schecki schrieb:
Welche IPs willst du aktualisieren? Die von den Content-Servern? Würde einfach weiterhin mit einem DynDNS-Dienst arbeiten...
Das es von meinem Proxy zum externen DynDNS-Dienst geht!? Ja, daran hatte ich noch gar nicht gedacht. Ohne Umweg geht es nicht (ohne weiteres)?
 
Crys schrieb:
Das würde dann aber ja in jeden Fall dazu führen, dass der volle Traffic über den Reverse Proxy Server läuft!?
Naja, ich dachte an eine simple HTTP-Weiterleitung an die DynDNS-Adresse, falls per IPv6 zugegriffen wird. Entsprechend liefe da kein signifikanter Traffic über den Reverse Proxy. Optimal ist die Lösung aber sicherlich nicht.
Per DNS gäbe es evtl. eine saubere Lösung, wenn dein DNS-Provider eine API für automatische DNS-Updates hat. Dann könntest du den AAAA-Record dynamisch updaten, während der A-Record fest auf den Reverse Proxy zeigt. Ich glaube, Hetzner bietet eine solche API, aber ich habe mich damit nicht genau beschäftigt. Eventuell ist die auch unhandlich oder so, also sieh das nicht als Empfehlung.
Wenn sich die IPv6-Adresse aber häufig ändert und keine solche API vorhanden ist, müsste das Update immer per Hand erfolgen - was offenbar mühsam ist. Wenn du einen CNAME-Record auf die DynDNS-Adresse hast, dann darf kein weiterer Record vorhanden sein. Ansonsten wüsste ich nicht, wie das per DNS gehen sollte.

Crys schrieb:
Ohne Umweg geht es nicht (ohne weiteres)?
Welcher Umweg? Zum DynDNS-Dienst geht von dir aus gar nichts, außer halt ein Nachricht, wenn sich die IPv6-Adresse geändert hat.
 
du kannst das ganze auch hinter cloudflares proxy hängen und von dort per ipv6 auf deine cloud zeigen.
Cloudflare macht dann v4 und v6 :)

Cloudflare hat auch eine API um per ddclient die AAAA Records upzudaten.
Und als Bonbon, deine wahre IP ist auch noch geschützt ;)
 
  • Gefällt mir
Reaktionen: Crys
Genau das will er nicht, denn der IPv6-Traffic soll nicht über den Proxy. Ansonsten könnte das alles auch mit dem vServer realisiert werden.
Die DNS-API ist natürlich hilfreich - allerdings ist das eben Sache des DNS-Betreibers und hat mit dem Proxyserver selbst grundsätzlich erstmal nichts zutun. Wenn es sich preislich lohnt, spricht natürlich nichts gegen Cloudflare - aber technisch auch nicht wirklich etwas dafür...
 
  • Gefällt mir
Reaktionen: Crys
Eine andere Idee:
Meine "Hauptdomain" (DDNS-Adresse, die aktuelle, welche der Benutzer nur sieht) hat einen A-Record zu meinem vServer und einen AAAA-Record direkt zur Cloud (den DS-Lite Heimanschluss).
Vom vServer geht es dann per RevProxy wieder zur DDNS-Adresse, aber nun per IPv6, deshalb kommt jetzt der AAAA-Record zum Einsatz. Könnte das funktionieren?
 
Zuletzt bearbeitet:
Es geht ihm bei IPv6 ja darum Traffic schonend zu arbeiten wegen der kosten, was bei Cloudflare irrelevant ist da kostenlos.
er braucht also weder ein vserver noch feste-ip zu bezahlen :)

ausserdem besteht die möglichkeit bei cloudlfare den v6 traffic nicht über den proxy laufen zu lassen.
du kannst für jeden DNS record auswählen ob Proxy oder nicht.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Crys
Zurück
Oben