AW: Server hinter Glasfasermodem nicht erreichbar(IPv6)
Das wäre in diesem Fall gar nicht mal das Problem.
Das Procedere, um einen IPv6-only-Server (Wie Deinen) erreichbar zu machen ist immer das selbe:
- Zuerst einmal machst Du Deinen Server per IPv6 erreichbar, das scheint ja beim Minecraft-Server kein Problem zu sein.
Ob er per IPv6 erreichbar ist, siehst Du übrigens gut mit
(Auf Linux-Servern)
Du solltest dabei eine Zeile a la
finden, in der der hier grün markiere Port und der Daemon-/Programmname mit Deinem Server übereinstimmt.
An den hier violett markierten Adressen mit Doppelpunkten drin (Hier "::" für "jede IP(v6)") siehst Du, daß der Server (auch) per IPv6 lauscht.
In diesem Beispiel ist es noch simpler, weil ganz vorne schon "tcp6" steht.
Auf Servern die nur busybox statt einem vollwertigen netstat haben steht dort aber auch bei IPv6 "tcp", deshalb der Verweis auf die angegebenen Adressen, die sind als Indiz zuverlässiger.
- Diesen Port auf der IPv6 des Servers gibst Du in Deinem Router frei.
- Für den Server bzw. seine öffentliche IPv6 legst Du einen DynDNS-Hostname an, z.B. "feldt.us.to".
- Hast Du ausschließlich IPv6-Clients (Das ist z.B. mein Ziel), dann bist Du jetzt fertig.
Es ist hierbei vollkommen egal, ob es sich bei dem Server um OpenVPN, Minecraft, oscam, MySQL, Blah, Blubb oder Superduperserver handelt, er muß nur IPv6 können (Aber selbst für IPv4-only-Server gäbe es einen Ausweg).
Nun kommen wir zu den IPv4-only-Clients und es ist hierbei egal,
warum die IPv4-only sind (Fehlende IPv6-Anbindung, blöder Client - was bei CCcam verbindet zu oscam der Fall ist, oder oder oder).
Im Kern ist das Procedere hier auch immer gleich.
IPv4-only-Clients können nicht zu IPv6-only-Servern verbinden und umgekehrt, aber man kann problemlos zwischen den beiden Protokollen umsetzen (proxien).
Die schlichteste Variante ist:
- Einen zweiten DynDNS-Hostname für den Server anlegen, wobei dem vorhandenen einfach nur "ipv6." vorangestellt wird, also z.B. ipv6.feldt.us.to
Dieser dient uns später als Weiterleitungsziel. Der "Normalname" kriegt nämlich später auch eine IPv4 (Die des Weiterleitungsservers) und weil ich schon aus Prinzip die Möglichkeit einer "Weiterleitung im Kreis" vermeiden will, empfehle ich grundsätzlich für das Weiterleitungsziel einen zusätzlichen Host anzulegen, für den nur eine IPv6 hinterlegt wird, also "ipv6.<restlicher DynDNS>".
- Einen Weiterleitungsserver auf einem beliebigen per IPv4 erreichbaren Rechner mit IPv6-Anbindung einrichten
- Mit Linux
für Port 13000 auf ipv6.feldt.us.to also z.B.
- Mit Windows
Wie oben, nur mit "nt6tunnel" oder
also z.B.
Dieser Weiterleitungs-Server (Proxy) kann wirklich überall auf der Welt sein, im Extremfall ist es sogar das Client-Gerät selber!
Auf dem Client-Gerät selber macht es dann Sinn, wenn das Client-Gerät zwar IPv6 kann und auch eine IPv6-Anbindung hat, aber das Client-Programm IPv4-only ist.
Als Beispiel verbinde ich mich aus Spaß an der Freude über diesen Trick von meinem DVBViewer/Hadu-Plugin (Kann nur IPv4) aus mit meinem oscam-Server (Der kann IPv6).
In Hadu wird dazu als Server einfach "127.0.0.1" (Und der listenport aus o.g. Beispielen) eingetragen und im Port-Proxy dann die tatsächliche Server-IPv6 bzw. der tatsächliche Server-Hostname.
Deine Minecraft-Clients auf IPv6-tauglichen Systemen bräüchten also ebenfalls nur einen solchen Port-Proxy und könnten dann - aus obigem Beispiel - 127.0.0.1 Port 13000 als Server nutzen.
Diese Variante macht also aus einem IPv4-only-Client um die Ecke doch noch einen IPv6-Client, Du siehst auf dem Server damit sogar die richtige IPv6 des Clients.
Den Port-Proxy kann man aber auch beliebig weit vom Client-Gerät weg und zum Server hinziehen (Nur nicht in das LAN des Servers, das ist ja per IPv4 nicht erreichbar).
Ein Schritt weiter wäre dann also z.B. ein anderer Rechner im LAN des Clients, z.B. ein
NAS.
Das bietet sich an, wenn man IPv4-only-Clientgeräte in einem ansonsten IPv6-fähigen Client-LAN oder auch einfach nur mehrere Clients im selben LAN hat, da man damit alle Clients in dem LAN mit nur einem Proxy versorgt kriegt.
Hier im Forum ist normalerweise ein Diablo-CAM-Modul oder eine Ariva-Box ein gutes Beispiel. Die Teile können nur IPv4, selbst wenn es im LAN auch IPv6 gibt. Um die jetzt mit einem externen IPv6-only-oscam zu verbinden könnte man auf einem IPv6-fähigen Gerät im LAN genau wie oben beschrieben einen Port-Proxy einrichten.
Das Diablo-CAM kriegt dann die interne IPv4 dieses Proxies als Server eingetragen, also z.B. 192.168.1.10 Port 13000 und der Proxy auf 192.168.1.10 verbindet dann durch zum IPv6-Server ipv6.feldt.us.to
Noch einen Schritt weiter sitzt der Port-Proxy auf irgendeinem Server im Internet.
Das kann ein eigener vServer sein (Die IPv4-Clients kriegen dann als IPv4 die des vServers), es gibt aber auch die Möglichkeit nur genau diesen einen Service (Also einen v4tov6-Proxy) zu buchen, z.B. bei feste-ip.net.
Für den Serverbetreiber ist das die am wenigsten elegante Möglichkeit, da dann alle IPv4-Clients über dieselbe IPv6 reinkommen (Die des Proxies), umgekehrt kriegt man damit aber alle IPv4-Clients mit nur einem Proxy versorgt.
In diesem Fall kommen dann auch weitere (Dyn)DNS-Hosts/-Records ins Spiel:
Zusätzlich zu der bereits dem Hostname "feldt.us.to" zugeordneten IPv6 (= AAAA record) kannst Du in diesem Fall auch noch die IPv4 (= A record) des Proxies eintragen, in der Regel (Also bei einem vServer oder einem Anbieter wie feste-ip.net) ändert sich diese auch nie und braucht daher nicht weiter gepflegt werden.
Der Vollständigkeit halber hinterlegt man dieselbe IPv4 auch noch als ipv4.<restlicher DynDNS>, also ipv4.feldt.us.to
Die Hosts lösen danach wie folgt auf:
feldt.us.to in Deine eigene IPv6 und die IPv4 des Proxies -> Dual-Stack-Clients werden IPv6 bevorzugen, IPv4-Clients nutzen IPv4 über den Port-Proxy, IPv6-Clients nutzen IPv6
ipv6.feldt.us.to in Deine eigene IPv6 -> IPv6-only-Clients und Dual-Stack-Clients nutzen (zwangsweise) IPv6, IPv4-Clients können nicht verbinden,
ipv4.feldt.us.to in die IPv4 des Proxies -> IPv4-Clients und Dual-Stack-Clients nutzen (zwangsweise) IPv4 über den Proxy, IPv6-only-Clients können nicht verbinden
Damit ist auch klar, wozu die Hosts:
feldt.us.to ist der Host, den Du normal nutzen würdest, da er eigentlich immer in der bestmöglichen Verbindung (Also bei Verfügbarkeit eine direkte Verbindung per IPv6) resultiert.
ipv6.feldt.us.to ist für Clients, die sicherstellen wollen, daß sie auf gar keinen Fall auf IPv4 und damit den Port-Proxy zurückfallen und natürlich als Weiterleitungsziel für den Proxy selber.
ipv4.feldt.us.to ist für Clients, die mit feldt.us.to Probleme haben. Das sind
immer Probleme des Clients bzw. dessen LAN, aber wenn man nett ist, bietet man diesen halt diesen Workaround an.
Jetzt nochmal der gängigste Weg (Proxy ist im Internet) in der Ultrakurzfassung:
- Server per IPv6 unter den Hostnames feldt.us.to und ipv6.feldt.us.to erreichbar machen (Siehe ganz oben)
- Einen Portmapper auf feste-ip.net anlegen, dessen Weiterleitungsziel "ipv6.feldt.us.to" und der Port/die Ports des Servers/der Server ist/sind.
Dabei darauf achten, daß der/die Portmapper 1:1 mapped/mappen, also der Port auf z.B. feldt.feste-ip.net sollte derselbe sein wie auf dem Server selber. Ggf. andere Ports probieren und den Server-Port am Ende entsprechend anpassen, wenn man einen 1:1-Mapper hat.
- Den Hostname, den einem feste-ip.net zugewiesen hat, also z.B. "feldt.feste-ip.net" mit host oder nslookup auflösen und diese IPv4 dann als A-Record dem Hostname feldt.us.to zufügen und als zusätzlichen Hostname ipv4.feldt.us.to anlegen.
Resultat:
Für den Normalbetrieb
ein Hostname und selber Port, egal ob der Client IPv4 oder IPv6 nutzt.
Für das Beispiel bin ich von
als DynDNS-Anbieter ausgegangen, da kriegt man kostenlos fünf "Records", also genug für die o.g. vier und AAAA-Records (IPv6-Adressen) sowie A-Records (IPv4-Adressen) sind getrennte und damit auch separat zu pflegende Records.
Das ist wichtig, weil man ja unter Umständen eine dynamische IPv6 hat (Die man entsprechend aktualisieren muß), die IPv4 aber die des Port-Proxies ist und bleibt und daher nicht aktualisiert werden muß.
