Beiträge von frank_m

Um noch kurz auf die ursprüngliche Frage zu antworten, falls du doch Wireguard auf dem VPS betreiben willst (das könnte spätestens dann interessant werden, wenn es ein zweites Heimnetz gibt, dass integriert werden soll, oder wenn du mehrere Roadwarrior Clients einbinden willst):

Du hast die Hinweise in der AVM Doku nicht beachtet. AVM nutzt kein Transfernetz und routet dann auf die Heimnetz Clients. D.h., die die Fritzbox hat keine 10.8.x.y Adresse, sondern die Wireguard-Konfiguration muss um die Heimnetz-Adresse der Fritzbox herumgestrickt werden. Siehe in dieser Anleitung den Hinweis mit dem blauen Dreieck in Kapitel 2:

https://fritz.com/apps/service/vpn-mit-fritz-box/3687_WireGuard-VPN-zwischen-FRITZ-Box-und-anderem-Router-einrichten

Generell ist das die Anleitung, der du beim Einrichten deines Setups folgen solltest. Dann klappt’s auch mit dem Zugriff aufs Heimnetz.

Wie lange ist es her, dass du Domains und DNS Einträge vorgenommen hast? Vielleicht haben sie sich weltweit noch nicht herumgesprochen? Das dauert durchaus auch mal länger, als in der TTL angegeben.

Dafür müsste man wissen, was das für ein VPN ist und wie es arbeitet. Bei dem VPN scheint einiges krude zu sein, vor allem die DNS Funktionalität.

Die Fehlermeldungen lassen darauf schließen, dass bei der DNS Auflösung was schief geht und am Ende ein Standard-Plesk Zertifikat ausgeliefert wird. Wenn der Zugriff ohne VPN problemlos funktioniert, dann scheint da beim VPN einiges im Argen zu liegen.

Ich könnte mir vorstellen, dass die dedizierte Routing Adresse aus dem Zielsubnetz auf einem Interface außerhalb des eigentlichen docker Adapters Ärger macht. Das Gateway muss ja nicht aus dem Zielsubnetz sein, ich würde da die link-lokale Adresse des Docker Bridge Devices auf dem Host nehmen.

Ist das nicht eher das Problem von Docker im Zusammenhang mit LXC und apparmor? Das wird ja seit einigen Tagen in den Debian/Ubuntu Foren diskutiert.

Wir brauchen die Übersicht der Wireguard Konfiguration, der IP- und Routenkonfiguration des Servers und der Firewall-Regeln, ganz wichtig, inkl. der Forwarding und NAT Regeln. Am besten von Debian 12 und 13.

IPv6 Adressen müssen händisch konfiguriert werden, DHCPv6 oder RAs gibt es nicht.

Und die zusätzlichen Netze hast du schon getestet? Die werden nämlich nicht auf die ::1 geroutet.

Zitat von zgtm

Ich habe das Subnetz auf /64 korrigiert, und jetzt funktioniert alles!

Das ist immer noch falsch. Du hast 2a03:4000::/64 auf deinen Systemen ja nicht in Benutzung. Damit wirst du Systeme aus diesem konkreten Prefix nicht erreichen. Die Route muss komplett weg, und die Prefix-Länge der Adresse muss auf /64 geändert werden.

Daneben sieht man die EUI-64 Adresse nicht, die fürs Routing der zusätzlichen Subnetze erforderlich ist. Wenn du sie nicht weg-editiert hast, musst du noch mal ran an die Konfiguration.

Zitat von zgtm

Ich stelle gerade fest, dass der Server a noch eine Route zusätzliche eingetragen hat: 2a03:4000::/32 dev eth0 proto kernel metric 256 pref medium, aber da eh alles über eth0 geroutet wird, sollte das keinen Unterschied machen, oder?

Doch, natürlich, genau die ist das Problem. Damit sucht dein Server die Pakete aus den anderen Prefixes dieses Netzes im LAN, also über NDP und Schicht 2. Das wird für die meisten dieser Prefixes nicht funktionieren. Exakt sowas hab ich erwartet, deshalb die Frage nach den Prefix Längen der Routen.

Zitat von zgtm

Hmm, ne, das sollten verschiedene Prefixe sein, oder nicht?

Das /32 ist für alle das Gleiche. Und genau das ist in diesem Fall das Problem.

Zitat von zgtm

Das Problem ist: Die beiden Server erreichen sich gegenseitig nicht über IPv6.

Zeig das doch mal anhand von Traces auf die jeweiligen Adressen beim Zugriff von außen und beim Zugriff zwischen den VServern.

Kommen die Adressen der beiden Server aus dem gleichen Prefix? Passen die Prefix-Längen der Routen auf deinen Servern? Du schreibst von mehreren Subnetzen. Das Routing dieser zusätzlichen Netze auf die Standard-EUI-64 Adresse des Servers funktioniert einwandfrei?

Da wäre es hilfreich, wenn du das caddyfile auch posten würdest. Im Moment sieht man nur, dass offensichtlich in Zeile 5 ein Fehler ist.

Wie gesagt, ich halte es noch für denkbar, dass die Quell-Adresse eine Rolle spielt. Allerdings wundert mich dann, dass man nicht schon öfter davon gehört hat. Deshalb die Frage nach dem verwendeten Subnetz.

Zitat von Homer3k

Funktioniert im übrigen auch von meinem lokalen System aus nicht, k.A. was da los.

Gut, das ist klar. Der Netcup Nameserver wird natürlich nur Anfragen von Netcup Systemen erlauben.

Zitat von Homer3k

Um aber nochmal auf die vorgegebenen Nameserver zu kommen... Von meinem Server aus, können beide nicht angesprochen werden bzw. bekommen eine Ablehnung...

REFUSED: Das deutet darauf hin, dass die Server die Anfrage aufgrund einer unbekannten Absender-IP abgelehnt haben. Aus welchem Subnetz ist deine IP? Hast du Dinge wie VPNs oder sowas laufen? Hast du IPv6 eingerichtet?

Die beiden Nameserver versehen ihren Dienst klaglos.

nslookup www.heise.de 46.38.225.230
Server:         46.38.225.230
Address:        46.38.225.230#53

Non-authoritative answer:
Name:   www.heise.de
Address: 193.99.144.85
Name:   www.heise.de
Address: 2a02:2e0:3fe:1001:7777:772e:2:85

nslookup www.heise.de 46.38.252.230
Server:         46.38.252.230
Address:        46.38.252.230#53

Non-authoritative answer:
Name:   www.heise.de
Address: 193.99.144.85
Name:   www.heise.de
Address: 2a02:2e0:3fe:1001:7777:772e:2:85

Nur weil sie nicht auf Pings antworten, heißt das nicht, dass sie nicht funktionieren.

Zitat von Homer3k

Sobald jedoch der resolved-service neugestartet wird oder der Server an sich neustartet, werden wieder die "alten" conf-Files hergestellt und die nicht funktionierenden IPs werden wieder eingetragen.

Wenn du den resolved nutzt, dann ändere die Konfig auch da.: /etc/systemd/resolved.conf. Es macht wenig Sinn, die Konfiguration an Stellen zu ändern, die du gar nicht benutzt.

nftables?

Firewall?

Is the rescue system in general capable of using IPv6?

I have mentioned several times, what I want to see.

No. The config does not show it. That is one reason why, I think, there is something else playing around in your network config. But you also told us, that you entered commands manually. This can also be responsible, why the output if "ip r" and "ip a" is not consistent. And therefore I asked to see the configuration directly after a reboot, in order to see, if there is some generic configuration error, or if you made your system weird with your manual commands.

Be prepared: We will do the same for firewall, for tcpdump traces, and maybe more. And we will go to the next step, when I have seen all I wanted to see.

You configured your system with noprefixroutes, but there are prefix routes.