AllowedIPs hat zwei Funktionen:
- Erstellen des Routings
- Ob ein Paket auf dem Interface überhaupt angefasst wird
Schau dir die erstellten Routen an.
Sowas wie 0.0.0.0/0 triggert anderen Konfigurationen.
Es wäre schon ganz gut gewesen, wenn du diese entscheidende Änderung gleich zu Beginn benannt hättest.
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820 [#] ip -4 rule add not fwmark 51820 table 51820 [#] ip -4 rule add table main suppress_prefixlength 0 [#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
Hier legt wg eine neue Routing-Tabelle an und schickt Pakete über die entsprechende Tabelle. Weshalb das den Verbindungsaufbau unterbindet, erschließt sich mir momentan auch noch nicht. Da müsste ich das vielleicht mal nachstellen.
Du kannst das im Übrigen auch selbst steuern und im Server mit "Table = off" verhindern, dass Routing-Tabellen angefasst werden. Die notwendigen Routen musst dann selbst setzen.
International sieht es so aus, das der ISP das Netzabschlussgerät stellt, und die Endkunden die Router per RJ45 anschließen.
Der Wind dreht sich in Europa gerade aber um 180°. Siehe Niederlande und Spanien.
Da bleibt es sicherlich spannend. Zudem ist der deutsche Markt mit geschätzten 40 Mio Haushalten sicherlich selbsttragend.
Und wer nicht will, der hat schon. Übernimmt halt nur AVM den Markt.
problemlos bei jedem Anbieter in Betrieb nehmen könnten
Also so wie bei DSL damals und heute üblich?
Mir bleibt es aktuell rätselhaft, wodurch die Kommunikation mit der Applikation blockiert wird.
sudo apt install nftables
sudo nft list rulesetEigentlich müsste man die Regeln, falls vorhanden, auch mittels
sudo iptables -L -vsehen.
Hast du mit
wg-quick down <config>mal zur Laufzeit den Tunnel gestoppt?
Aber mehr fällt mir gerade nicht ein.
Danach könntest du einen Versuch mit einem aktuellen Ubuntu-Image starten.
Für den Test IPv4->6tunnel->IPv6 kannst du dir das Wireguard-Setup sparen.
priorisiert
Ich bleibe bei meiner anscheinend exotischen Meinung, dass das gesuchte Wort hier "provisioniert" lautet. 
Die erste Fritzbox mit integriertem DSL-Modem von 2004 wurde auch Schritt für Schritt durch bessere Modelle ersetzt.
Warum sollte das bei Gf anders laufen?
Insbesondere die Telekom setzt in den Wohneinheiten konsequent auf den vorgeschriebenen passiven Abschluss. Da werden viele alleine wegen der Optik nur noch ein Gerät wollen.
Irgendwann haben sich wie selbstverständlich auch integrierte DSL-Modems in den Routern durchgesetzt.
Wird bei Gf genauso passieren.
Ich denke, dies ist wieder ein Paradebeispiel für einen absolut unqualifizierten Kundensupport/Helpdesk.
Dieser kennt noch nicht einmal die Basisfunktionalität des verkauften Produktes Internetaccess.
So lange Insta und TikTok geht, soll der Kunde sich besser nicht beschweren.
HÜP zwei von außen zugängliche LC/APC Buchsen
Das dürfte der entscheidende Unterschied sein. In deinem Fall ist die geforderte Zugänglichkeit gegeben.
Beim OP ist die Intention des ISP klar erkennbar: Der passive Abschluss (obwohl innen nur gesteckt) ist nicht gegeben, da er dafür den HÜP öffnen müsste.
Das erinnert mich an Anfang der 90er, als die damalige Post den Telefonanschluss meiner Eltern auf TAE umgebaut hat. Damals war der grüne Apparat noch fest in einer Dose verdrahtet angeschlossen.
Geschichte wiederholt sich offenbar.
Ich habe das in Ubuntu nachgestellt. Wenn die Firewall ein Paket mittels DENY blockt, sieht es im tcpdump exakt so aus, wie bei jbb.
Der Client sendet immer wieder Anfragen, aber keine Antwort der Applikation, da 6tunnel das Paket nicht bekommt.
Was noch zu prüfen ist:
sudo apt install ufw
sudo ufw statusMan müsste dann aber etwas in iptables sehen. Es bleibt unklar, warum das Paket die Applikation nicht erreicht.
Wenn der HÜP den Abschluss zugänglich macht, dann wäre das der passive Abschluss.
Aber die Zugänglichkeit scheint mir hier nicht gegeben zu sein.
Deswegen mein Gedanke, dass die Firewall den Traffic blockiert. Dann käme das Paket an, wird aber im Kernel verworfen. Und die Applikation bekommt nix mit.
Bliebe die Variante, das Kabel abzuwickeln und weiter nach außen zu führen (falls das reicht und du musst es einmal öffnen), oder halt zu verlängern.
Die Frage ist: Ist der HÜP für dich als Nutzer zugänglich?
Denn da ist ja noch jede Menge Kabel aufgewickelt und theoretisch könntest du auch ein eigenes, längeres Kabel anschließen.
Falls nicht zugänglich: Vom ONT trennen und verlängern.
Bleibt weiterhin die Frage nach der Provisionierung.
Leider herrscht bei vielen "neuen" ISPs noch eine gewisse Wild-West-Stimmung. Das wird sich sicherlich noch bessern, sobald der Markt weiter konsolidiert wurde.
Was ich noch nicht verstehe: Hat der Netzbetreiber denn nach dem HÜP, der dir nicht zugänglich ist, direkt einen ONT platziert, ohne eine Gf-Dose zu setzen?
Wenn letzteres der Fall wäre, könntest du aber mit einer Kupplung das LWL-Kabel, was zum ONT geht, entsprechend verlängern.
Bliebe immer noch das Problem der Provisionierung im Netz.
Noch ein Hinweis. Wenn du mit 6tunnel oder socat auf ein "natives" IPv6-Ziel gehst, nutzt du keinen Wireguard-Tunnel.
Du kommst per IPv4 am VPS an und 6tunnel verbindet sich per IPv6 zu deinem Zielsystem.
Bitte daher, falls nicht geschehen, die Tests ohne Wireguard fortführen.
Codesudo 6tunnel -d -v 4430 nas6.xxxxx.de 49681 resolving nas6.xxxxx.de resolved to 2a00:6020:5022:c700:xxxxx resolving local address default resolved to 0.0.0.0 local: default,4430; remote: nas6.xxxxx.de,49681; source: defaultNur das, keine Änderung beim Kontaktversuch von außen.
Ein erfolgreicher Kontakt sollte so aussehen:
6tunnel -d -v 80 a.b.c.d 80
resolving a.b.c.d
resolved to 2003:xxx
resolving local address default
resolved to 0.0.0.0
local: default,80; remote: a.b.c.d,80; source: default
<4> connection from 91.x.y.z,60383
<4> connected to a.b.c.d,80Dass das bei dir nicht passiert, dass es folgende Fehler geben könnte:
1) Externer Kontakt kann den Namen des VPS nicht korrekt auflösen
2) Firewall beim Hoster arbeitet nicht korrekt für den gewünschten TCP-Port
3) Firewall auf dem OS verhindert den Aufbau
Aus Spaß an der Freude kannst du auch einen Versuch mit "socat" unternehmen:
sudo socat TCP4-LISTEN:80,reuseaddr,fork TCP6:a.b.c.d:80Was sagt denn da hier?
sudo nft list rulesetBzw. auch das hier?
systemctl status firewalld.servicefalls die Alarmanlage über den Tunnel mit dem FTTH im Netz 2 (mit ipv4 von der Telekom) ans Internet anzubinden wäre.
Ich denke nicht, dass das funktioniert. Aber selbst wenn man da eine abenteuerliche Konstruktion hinbekommt: Nicht machen.
Ein VPS mit einer öffentlichen IPv4 kostet dich 1 €/Monat...
Wähle aus, welche Kategorien Du erlaubst. Für jede Kategorie kannst Du über „Details anzeigen“ sehen, welche Cookies und Skripte konkret geladen werden, welche Empfänger beteiligt sind und wie lange gespeichert wird.
Weitere Informationen: Datenschutzerklärung · Impressum
