Beiträge von henfri

Wer das nicht will, kann sich Mal headscale ansehen.

Aber jetzt Back to topic.

Zitat von henfri

Ah.

Nur doof dass es bei Misserfolg nicht das jeweils Andere ausprobiert.

Hast du nen Link zu dem Teil der Doku, wo du das gefunden hast?

Würde es Mal in der Mailingliste ansprechen.

Danke für den Tipp zu tailscale.

Kann jemand zu dem oben noch was sagen?

Ah.

Nur doof dass es bei Misserfolg nicht das jeweils Andere ausprobiert.

Hast du nen Link zu dem Teil der Doku, wo du das gefunden hast?

Würde es Mal in der Mailingliste ansprechen.

Ok, hast du dann eine Idee, warum er bei mir v4 bevorzugt hat?

Ich hab an Windows nix rumgebastelt, um v4 zu bevorzugen.

Und ich hatte das gleiche Problem auf Android UND Windows.

Ja, aber nur wenn man WG dazu zwingt:

-kein A record

-IP satt domain angeben

https://www.reddit.com/r/WireGuard/co…s_ipv4_instead/

Hallo,

ich habe da noch ein wenig recherchiert: Wie oben beschrieben bevorzugt Windows ja schon v6. Aber bei Wireguard ist bekannt, dass es dies nicht tut. Ist also tatsächlich ein Wireguard-Problem, da wohl ansonsten die Konvention ist v6 zu bevorzugen.

Aber klar, das Problem ist die falsche IPv4 im A-Record.

Gruß,

Hendrik

Hallo,

wo kann man denn an einem Windows-PC einstellen, was bevorzugt wird?

Gruß,

Hendrik

Hallo,

ich hab es jetzt mal auf einem Windows Endgerät ausprobiert:

2021-12-25 21:41:34.580: [TUN] [Heimnetz] Handshake for peer 1 (100.66.40.241:51820) did not complete after 5 seconds, retrying (try 2)
2021-12-25 21:41:34.580: [TUN] [Heimnetz] Sending handshake initiation to peer 1 (100.66.40.241:51820)

Das wiederholt sich ständig.

Ich bin jetzt aber zwei Schritte weiter:

1) wenn ich als Endpoint die ipv6 Adresse angebe, statt meine Dyndns-Domain, dann kommt der Tunnel richtig zu Stande.

2) wenn ich die IP meines Servers angebe, dann komme ich auch auf den Webserver und SSH Server meines Servers. Die Namensauflösung funktionierte aber vorher auch nicht (selbst mit der Fritz.Box als DNS)

Das Problem zu (1) scheint, dass die IPv4 Adresse, die hinter meiner dyndns-Adresse liegt keine öffentlich erreichbare ist, aber Wireguard wohl per default diese verwendet.

[Interface]
PrivateKey = xx
Address = 10.192.122.2/32
DNS = 8.8.8.8

[Peer]
PublicKey = yy
AllowedIPs = 0.0.0.0/0
Endpoint = [1234:1234:1234:1234:222:4dff:feaa:27bb]:51820

Edit:

So, es funktioniert:

1) bei meinem Dyndns-Provider habe ich die IPv6 Adresse gelöscht. Das zwingt Wireguard dann IPv6 zu nutzen.

2) DNS= [IP der Fritzbox] und dann funktionier die Namensauflösung über hostname.fritz.box. Wäre noch schön, wenn auch hostname (ohne .fritz.box) funktionieren würde. Aber ansonsten bin ich zufrieden.

Gruß,

Hendrik

Gruß,

Hendrik

Ja, gerade geprüft.

Die die Wireguard App sagt übrigens

Gesendet 134 Byte

Empfangen 0 Byte.

Wenn ich als Adresse statt meiner dyndns Adresse bewusst eine falsche angebe, meckert Wireguard auch und kann keine Verbindung aufbauen.

Will sagen: es scheint ja tatsächlich eine Verbindung aufgebaut zu werden.

Hallo,

ich hatte Wireguard auf meinem Debian Server und meinem Android Handy eingerichtet und es funktionierte an meinem DSL Anschluss wunderbar.

Nun habe ich ja mit DG Carrier Grade NAT und nur noch eine IPv6 Adresse.

Ich hätte jetzt erwartet, dass Wireguard mit folgenden Änderungen weiter funktioniert:

1) Statt der myfritz-Domain wird eine Dyndns-Domain welche auf die IPv6 meines Servers verweist verwendet (z.b. server.dynv6.net)

2) In der FritzBox sind keine Änderungen nötig, vorausgesetzt, unter Portforwarding war vorher auch schon die Freigabe der IPv6 des Wireguard-Port (UDP) eingestellt.

Ist das richtig?

Das Problem:

Ich habe die Verbindung zuhause ausprobiert und es schien zu funktionieren. Jetzt bin ich im Urlaub und ich habe keinen Zugriff auf meinen Server. Ich weiß nicht, woran das liegen kann... Ob ich beim Test vielleicht noch im WLAN war...?

Wie auch immer: auch unter meiner myfritz-Adresse habe ich keinen Zugriff auf meine Fritzbox. Ich kann also (2) nicht verifizieren. (1) habe ich verifiziert. Woran kann das liegen?

Gibt es noch etwas, was ich von hier aus machen kann?

Gruß,

Hendrik

Hallo,

danke für den Tipp. Ich denke, so komme ich weiter. Wenn ich eine Lösung habe, poste ich sie hier. Danke!

Gruß,

Hendrik

Zitat von frank_m

Bei IPv6 hat jedes Gerät seine eigene öffentliche IP. Es ist nicht wie bei IPv4, wo der Router eine öffentliche IP hat, die dann auf jedes Gerät per Portweiterleitung durchgereicht werden muss. Auch das steht bereits hundertfach in den anderen Threads zu IPv6 und Portweiterleitungen hier im Forum.

genau das meinte ich doch mit

Zitat

(ich weiß dass es bei ipv6 keine Port-Weiterleitung ist, sondern eher ein umbiegen auf den enstprechenden lokalen teil der IPv6 ist).

Zitat

Für dich heißt das: Anstatt der IPv6 Adresse seiner Fritzbox musst du die IPv6 Adresse des Servers angeben, und dann in der Fritzbox eine entsprechende Portöffnung auf die Host-ID des Endgerätes einrichten. "meine.dynv6.com" zeigt also offensichtlich auf die falsche IPv6:

Ja. Weil feste-ip.net in den Anleitungen zeigt, wie man die Aktualisierung der IP in der Fritzbox einrichtet.

Es muss also der Host, der erreicht werden will das IP-Update bei feste-ip machen.

Zitat

Wenn du schreibst, dass dein Alexa Skill kein IPv6 kann, dann hilft dir das natürlich überhaupt nicht weiter.

Warum nicht? Der Port-Mapper bei feste-ip.net leitet doch eine v4 frage auf meine.feste-ip.net:1234 auf meine ipv6 weiter, dachte ich.

Zitat

Ich kenne uberspace nicht, aber es sieht nicht so aus, als wäre das im Moment hilfreich. Oder erlauben die das aufbauen eines VPN Tunnels? Um die IPv4 Verbindung über socat zu tunneln, müsstest du sie aus deinem Heimnetz heraus triggern, und auch das halte ich für irgendwas zwischen heikel und unmöglich.

Nein, ein VPN-Tunnel geht nicht.
Aber was geht ist

socat tcp4-listen:42580,fork,reuseaddr tcp6-connect:meine.dynv6.net:443

Das leitet alle Anfragen auf meineUberspaceDomain:42580 auf meine.dynv6.net:443 weiter. Das certifikat von meineUberspaceDomain kann ich mir über scp regelmäßig holen.

Gruß,

Hendrik

Bei mir jetzt auch. Es lag an den falschen credentials.

Hallo,

ich nutze aktuell Wireguard. Das sollte aber doch auch über IPv6 funktionieren, oder?

Hier geht es ja nur um meinen Alexa Skill der kein IPv6 kann.

Ich habe es jetzt mal mit uberspace probiert. Das ist aber nur ein VServer.

Der Plan ist:

Uberspace hat ein ssl-cert für meine.domain. Das kann ich mir runterladen und in meinem nginx nutzen

In Uberspace leite ich meine.domain:1234 auf meine.dynv6.com weiter (socat).

Das funktioniert soweit. Aber wenn ich jetzt meine.domain:1234 öffne, dann strahlt mich das Webinterface der Fritzbox an - obwohl ich in der Fritzbox doch eine Weiterleitung von port 443 auf meinen Server (ich weiß dass es bei ipv6 keine Port-Weiterleitung ist, sondern eher ein umbiegen auf den enstprechenden lokalen teil der IPv6 ist).

Wie kommt das?

HubeBube: Also 25% hab ich verstanden, sorry.

Dass der Port für das Zertifikat egal ist, weiß ich. Aber wenn ich feste-ip und deren port-weiterleitung nutze komme ich ja nicht an ein SSL-Zertifikat von ich.feste-ip.net:64757 Denn der letsencrypt-certbot braucht ja port 80 oder 443 für den NAchweis, dass ich.feste-ip.net auch mir gehört.

Gruß,

Hendrik

Hallo,

ja ich fürchte, da gibt es keine gute Lösung.

Kannst du einen V-Server empfehlen?

Gruß,

Hendrik

Ok, ich habe zwei mögliche Ursachen gefunden:

1) der SIP Account gehört zu einer noch nicht portierten Nummer

2) es war durch copy&paste noch ein Leerzeichen an die Nummer angehängt.

Ohne das Leerzeichen und mit dem anderen Account funktioniert es jetzt.

Danke!!

Hallo,

da hast du Recht. Aber ich sehe noch nicht ganz, wie das gehen soll:

Als Dyndns nutze ich ich.twodns.de. Dafür kann ich (über ipv6) auch ein LE Zertifikat erstellen.

ABER: Mein Alexa-Skill kann kein ipv6.

Daher habe ich dafür über feste-ip.com den universellen portmapper eingerichtet.

Der leitet jetzt weiter: meine-alexa.feste-ip.net:64757 nach ich.twodns.de:443 - dafür habe ich ja das LE Zert.

Bei Amazon mache ich jetzt meine-alexa.feste-ip.net:64757 bekannt. Mein Server antwortet jetzt aber doch mit dem ich.twodns.de Zertifikat - und das passt nicht zur Domain, die Amazon erwartet (jetzt meine-alexa.feste-ip.net).

Oder übersehe ich etwas?

Darüber hinaus bekomme ich unter meine-alexa.feste-ip.net:64757 aktuell ein ERR_CONNECTION_RESET

Gruß,

Hendrik

Hallo,

ich habe einen Anschluss von Deutsche Glasfaser der nur IPv6 anbietet.

Ich habe daraufhin in der Fritzbox IPv6 aktiviert und mein dyndns-Anbieter (twodns) scheint ipv6 zu unterstützen - ich komme jedenfals unter meine.dyndns.domain auf die Dienste, die ich zuvor eingerichtet habe.

Allerdings habe ich einen Dienst (einen Custom-Alexa-Skill), welcher ein gültiges (nicht self-signed) SSL-Zertifikat hat UND IPv6 nicht kann.

Das habe ich bisher über letsencrypt gemacht, indem ich für meine dyndns-Adresse ein Zertifikat erstellt habe. Das erfordert allerdings, dass Port 80 oder 443 von Letsencrypt.

Wenn ich jetzt den Universellen Portmapper von feste-ip verwende, bekomme ich ja nicht den Port 80 oder 443. Somit bekomme ich kein Letsencrypt Zertifikat.

Lange Rede, kurzer Sinn: Wie bekomme ich eine

Eine (sub)Domain

Eine IPv4 Adresse

mit SSL-Zertifikat für meinen Anschluss

Gruß&Danke,

Hendrik

Hallo,

einen Punkt "Rufnummer für die Anmeldung verwenden" gibt es nicht, wenn man als Anbieter DG wählt - wohl aber, wenn man "Anderer Anbieter" wählt.

Das habe ich jetzt mal gemacht - ohne Besserung.

Mal sehen, was DG dazu sagt...

Gruß,

Hendrik

Hallo,

so, jetzt war ich erfolgreich:

1) das Rücksetzen der FB hat erstmal nix gebracht.

2) Reset ONT nach AUfforderung DG auch nicht

3) DG ist mit mir die Einstellungen der FB durchgegangen und meinte, ich bräuchte bei den Interneteinstllungen einen User und Pass. Wurde mir per Telefon diktiert. Dann "Synchronisation" von ONT und FB seitens DG angestoßen -- keine Besserung (es sollte laut DG nach 1h funktionieren

4) Nochmal angerufen. ONT Reset und DG hat "einen Prozess" gestartet

5) Immernoch kein Internet

6) Nochmal beherzt "es werden keine Zugangsdaten benötigt" ausgewählt unter "Internet" --> Funktioniert

7) Gespeicherte Einstellungen in der FritzBox wiederhergestellt. Dabei die DSL-Einstellungen NICHT wiederhergestellt --> Alle Einstellungen wie früher. Sogar die DECT Telefone funktionieren und: Die SIP-Nummern von 1und1 funktionieren auch noch!

Soweit so gut. Danke für eure Hilfe!

User und Pass aus (3) die mir DG gegeben hat waren übrigens die SIP Daten. Ich glaube, die Dame war nicht so kompetent...

Nur SIP über DG funktioniert noch nicht. Fehler 404. Da habe ich mal ein Ticket bei DG aufgemacht. Mal schaun.

Ich bin überrascht: Die FB 7490 schaft die vollen 1Gbit (na gut, 940 Mbit).

Gruß,

Hendrik