Frage ist halt, ist netplan überhaupt gewollt, oder versehentlich in der ISO gelandet?
Aus https://wiki.debian.org/Netplan/FAQ :
[...] It's also used as the default network stack in Debian cloud-images, as of the "Bookworm" release [...]
Betrifft also aktuell nur die cloud-init images.
Das klingt gut. Auf welcher Unterseite kann man das machen lassen? Hab die nicht gefunden?
Unten im Footer auf "Submit a data correcton".
Neben der von dir genannten Möglichkeit über sysctl gibt es auch noch die Möglichkeit IPv6 über den Kernel zu deaktivieren.
Dazu einfach "ipv6.disable=1" an die Kernel Cmdline anhängen. Über den Bootloader grub würdest du das in /etc/default/grub unter dem Konfigurationsparameter GRUB_CMDLINE_LINUX="ipv6.disable=1" eintragen und mit update-grub scharfschalten.
Dadurch wird IPv6 komplett deaktiviert.
Dass das ganze keine gute Idee ist, haben dir meine Vorredner ja bereits mitgeteilt. Ich gebe hier außerdem noch zu Beachten, dass einige Software sich anfängt merkwürdig, bis hin zu instabil zu verhalten, oder schlicht komplett den Dienst verweigert wenn du den IPv6 Stack deaktivierst.
Gerade in Verbindung mit Docker führt dies sehr häufig zu Mehrarbeit, wenn der Dienst innerhalb des Containers konfiguriert wurde sich auf IPv4 und IPv6 zu binden.
EDIT: kleiner Nachtrag, nach update-grub ist natürlich noch ein reboot notwendig.
Bei besagtem Hoster würde ich persönlich rein gar nichts mieten 
https://www.heise.de/news/Webh…und-erpresst-2777957.html
stehen da irgendwo 70 GBit/s Backplane?
Nein, sind sogar 87 Gbit/s an Layer 2 switching capacity, die dort angegeben werden 
Das eingebaute DDNS von Mikrotik kannst du nicht nutzen?
Zu finden unter IP -> Cloud und dann anschließend einen CNAME deiner Domain hier auf Netcup auf den unter "DNS Name" angezeigten FQDN setzen.
Allerdings musste ich feststellen, dass der Internet Zugriff durch den IPv6 S2S Wireguard VPN Tunnel auf verschiedene Internet Dienste (z.B. twitch.tv) extrem langsam ist, und der Zugriff manchmal auch gar nicht funktioniert.
Hast du MSS clamping für TCP Traffic aktiviert? (via iptables auf dem Server)
und hier Server A zu Server B (A läuft im Rescue System): https://pastebin.com/J8fNKhXk
Meiner Meinung nach ist das MTR bereits aussagekräftig genug, die Pakete gehen unregelmäßig bereits am ersten Netcup Gateway (gw02) flöten (>66% über 500 Pakete ist schon krass ...).
Hier muss netcup dann eigentlich so langsam mal tätig werden.
Vielleicht noch mal etwas deutlicher im Ticket hervorheben, dass auch aus dem Rescue heraus getestet schon am ersten Gateway Pakete in unregelmäßigen Abständen verloren gehen und dieses MTR dann entsprechend anhängen. Vielleicht auch eine Ticket-Eskalation nach weiter oben versuchen ...
Wenn "netplan apply" die Internetverbindung auch nicht wiederherstellt und ggf. fehler wirft, solltest du via
ip link set up dev eth0
ip addr add 202.61.241.240/22 dev eth0
ip route add default via 202.61.240.1 dev eth0
zumindest temporär das Interface mit der IPv4 Adresse wieder hochbringen können.
Danach kannst du dich dann entweder um die Behebung des grundlegenden Problems kümmern (durch Logauswertungen o.ä.), oder aber ein Backup deiner wichtigen Daten ziehen und anschließend die Kiste neu installieren, denn du scheinst aktuell nicht mal zu wissen welcher Dienst bei der Kiste für das Herstellen der Netzwerkverbindung verantwortlich ist.
Meine .wtf Domain kostet mittlerweile das dreifache wie vor 6 Jahren
Bei Cloudflare zahl ich nicht mal die hälfte davon ... wtf (im wahrsten Sinne des Wortes)
Okay also im Grunde nur ne Point to Point Verbindung. Dann musst du in deiner Wireguard Config auf dem VPS nur die Direktive "AllowedIPs = 0.0.0.0/0" ändern.
Von jetzt 0.0.0.0/0 auf das innerhalb von Wireguard benutzte Netz. In deinem oben geschilderten Fall also 10.66.66.X/YY.
Damit routest du dann nicht mehr den gesamten Traffic des VPS zu deinem Heimserver, sondern nur noch das Netz innerhalb von Wireguard.
Da wie du schreibst noch weitere Clients darauf zugreifen sollen, musst du diese entsprechend auch in die AllowedIPs aufnehmen, entweder als Netz, oder als /32 EinzelIPs.
Beispiel
AllowedIPs = 10.66.66.0/30, 10.77.77.0/24, 10.88.88.8/32
Sofern noch nicht geschehen, muss außerdem das IPv4 Forwarding auf deinem Heimserver aktiv sein, damit mehr als nur der Traffic Heimserver <=> VPS geroutet wird.
Was genau ist denn dein Vorhaben? Einfach nur ein Point to Point Tunnel zwischen Heimserver und VPS, oder wirklich den VPS über deinen Heimanschluss erreichbar zu machen?
Auf Clientseite Sprich idealerweise auf dem Router.
Vielleicht doch ein MTU-Problem?
Das klingt in der Tat schon sehr danach. ICMP geblockt und SSL Handshake funktioniert nicht mehr sind sehr typische Symptome für ein MTU Problem. Da das ganze bei mainziman über einen Tunnel geht (wo die MTU verringert ist), würde ich dort mal ansetzen.
Vielleicht könnte man mal probieren via iptables die MSS runterzudrehen
ip6tables -t mangle -A FORWARD -o **TUNNEL** -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1281:1536 -j TCPMSS --set-mss 1280
Ich muss korrigieren! Klappt nicht mehr, sobald ich ich wieder auf "internet.v6.telekom" umstelle.
Wie schon mehrfacht im Thread erwähnt:
Wenn du nur eine IPv6 Adresse im Mobilfunk bekommst, muss auf dem Client die Zeile "Endpoint = 185.207.105.144:51820" auf die IPv6 Adresse des Servers abgeändert werden. Also z.B. "Endpoint = [2a03:4000:1e:742:a85f:b7ff:fe5f:c8cc]:51820".
Möchte man es umgehen ständig die Endpoint Direktive zu ändern, kann man das durch Nutzung einer (Sub-)Domain umgehen.(A Record 185.207.105.144; AAAA Record 2a03:4000:1e:742:a85f:b7ff:fe5f:c8cc) Danach bei Endpoint dann vpn.domain.xyz:51820 verwenden. Der Client nimmt sich dann die Adresse, mit der er Umgehen kann.
Der Vorschlag wurde auch bereits mehrfach im Thread geäußert, du bist aber leider bisher nicht darauf eingegangen.
EDIT:
Und nun gehe bitte als nächstes das Thema Abschottung deiner PiHole an. Die löst weiterhin fröhlich für die ganze Welt auf.
Nicht wirklich on-topic, aber bitte sorge unbedingt dafür, dass deine PiHole nicht allen im Internet antwortet. Wenn du es nicht bereits bist, dann landest du sehr wahrscheinlich bald auf einer DNS Reflection DDoS Liste.
#dig google.com @2a03:4000:1e:742:a85f:b7ff:fe5f:c8cc
; <<>> DiG 9.16.1-Ubuntu <<>> google.com @2a03:4000:1e:742:a85f:b7ff:fe5f:c8cc
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40173
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 300 IN A 172.217.16.142
;; Query time: 31 msec
;; SERVER: 2a03:4000:1e:742:a85f:b7ff:fe5f:c8cc#53(2a03:4000:1e:742:a85f:b7ff:fe5f:c8cc)
;; WHEN: Wed Sep 29 16:51:11 CEST 2021
;; MSG SIZE rcvd: 55
=============================================================================================
# dig google.com @185.207.105.144
; <<>> DiG 9.16.1-Ubuntu <<>> google.com @185.207.105.144
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63384
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 89 IN A 172.217.16.142
;; Query time: 15 msec
;; SERVER: 185.207.105.144#53(185.207.105.144)
;; WHEN: Wed Sep 29 16:54:42 CEST 2021
;; MSG SIZE rcvd: 55funktioniert das auch mit ner Domain statt ner IP?
Ja, das war mit DDNS(DynDNS) gemeint, sorry. Ohne wirds dann doch etwas nervig ständig die IP im AP zu ändern.
Geht um die reine Konfiguration, ohne Traffic Monitoring etc.
Da auf der UDM ein vollwertiger UniFi Controller läuft, wüsste ich nicht was dagegen spricht.
Auf der UDM die Ports fürs Inform freischalten (default ist das 8080) und im AP im Restaurant via SSH die inform URL entsprechend setzen.
Die Befehle dafür sind
mca-cli
set-inform http://[DDNS/IP des Heimanschlusses]:8080/informTraffic Monitoring würde wohl eh ohne UDM oder USG vor Ort nicht funktionieren, oder irre ich?
Das ist korrekt. Könnte mir aber vorstellen, dass man das durch einen VPN Tunnel zwischen AP und UDM irgendwie doch abbildbar wäre.
Ich lese diesen Thread mit zunehmendem Unverständnis.
Ich auch, aber eher in die umgekehrte Richtung. Wie sich einige hier echauffieren das von MeisterYoda angedachte Setup auseinanderzunehmen geht eigentlich gar nicht. Netcup ist ein Anbieter für mietbare Ressourcen (e.g. vServer), was der- oder diejenige dann letztenendes damit macht bleibt völlig dem Kunden überlassen.
Daraus abgeleitet hier so Stimmung gegen Netcup zu machen, ist imho nicht in Ordnung, denn Dir wurde nie etwas anderes gesagt oder versprochen. Warum und wieso Netcup sich auf 64er Netzwerke beschränkt ist da doch völlig irrelevant.
Man darf netcup hier aber sehr wohl den Finger dafür in die Wunde legen, dass hier keine Rücksicht auf das architectuelle Design von IPv6 Rücksicht genommen wird und man entgegen der Empfehungen von z.B. rfc6177 und der Registries agiert.
Netcup ist ein Server- und kein "Gateway-für-Homenetzwerke"-Anbieter. Daher braucht der Anbieter imho hier keine Rücksicht zu nehmen.
Und ein Server kann also kein "Gateway-für-Homenetzwerke" sein? Das musst du mir bitte ein mal genauer erläutern wo da technisch der Unterschied besteht. Auch darfst du mir gerne erklären wer oder was dir das Recht gibt festzulegen zu welchem Zweck die mietbaren Ressourcen verwendet werden dürfen.
Vermutlich bist Du der einzige, der sowas über Netcup abziehen will. Und es macht halt für eine Firma nunmal keinen wirtschaftlichen Sinn, auf Einzelbedürfnisse so spezifisch einzugehen.
Gerade im Hinblick auf die zunehmende Verbreitung von DS-Lite wirst du dich wundern wie viele sich auf die hier beschriebene Weise dazu verhelfen eine öffentliche IPv4 am heimischen Anschluss zu bekommen. Ich habe selbst lange Zeit bei Netcup entsprechende Gateways für Freunde und Bekannte, die CGN geplagte Vodafone/Kabel Deutschland Kunden sind, betrieben. Mangels größerer Netze bedeutete das allerdings keine IPv6 Anbindung über netcup aus den entsprechenden Heimnetzen, da z.B. sämtliche Android Geräte weiterhin kein DHCPv6 unterstützen und auch vmtl. nie unterstützen werden.
Die Gateways sind inzwischen alle zu einem Anbieter gewandet, der ohne Aufstand ein größeres Netz bereitstellen kann.
Weiterhin nutzen auch einige von der Peering Politik der Telekom geplagten User netcup als günstiges Gateway zu einem nicht verstopften Internet.
Ebenfalls ein valider use-case.
Nur weil dir keine (sinnvollen) Gründe einfallen soetwas zu betreiben, heißt es nicht, dass es sie nicht gibt.
