Ich dachte ich brauche IPv4 (und eben auch IPv&) forwarding um die Pakete über der WireGuard-Schnittstelle weiterzuleiten?
Ich dachte, du hattest bereits einen Wireguard Server, der für IPv4 funktioniert und nun auch für IPv6 laufen soll. Wenn du den in der gewohnten Weise weiterbenutzen willst, musst du im Grunde nur IPv6 als Server-Adresse aktivieren. Im Tunnel kann alles bleiben, wie es ist, und auch Forwarding Rules brauchst du keine neuen.
Nein, aktuell habe ich noch keinen WireGuard-Server am laufen. Bin noch in der verwirrenden Einlese-Phase 
Aber ich denke ich werde es heute mal testen - je nachdem.
Nutzen möchte ich ihn auf zweierlei Art:
1) VPN für mehrere Geräte ins WWW
2) Tunnel zwischen diversen Geräten und dem Vereins- bzw. meinem Heimnetz, um lokalen Zugriff von überall zu haben. Zum Beispiel auf die Vereinssoftware oder meinen Home Assistant.
Dann sollte dieses Tutorial dir eigentlich helfen: https://community.netcup.com/e…to-setup-wireguard-ubuntu
Für IPv6 musst du halt noch IPv6-Adressen hinzufügen. Da reichen aber ULAs (z.B. hiermit dir eine generieren lassen: https://www.unique-local-ipv6.com/)
Bei Schritt 3.1 musst du dann noch net.ipv6.conf.all.forwarding=1 hinzufügen.
Ich würde dir aber empfehlen erstmal mit IPv4 anzufangen. Wenn dann alles so läuft, wie du es dir wünschst, kannst du ja IPv6 hinzufügen. Direkt beides einzubauen erhöht nur die möglichen Fehlerquellen.
und denk' an #765 -> wireguard-ui
das kannst du auch lokal installieren, und hilft dann trotzdem ungemein.
wireguard-ui ist mit eingeplant
Für IPv6 musst du halt noch IPv6-Adressen hinzufügen. Da reichen aber ULAs (z.B. hiermit dir eine generieren lassen: https://www.unique-local-ipv6.com/)
Edit: Wieso nicht die "eigenen" IPv6-Adressen des Servers verwenden?
Wieso nicht die "eigenen" IPv6-Adressen des Servers verwenden?
Es sind zwei verschiedene Netze: Das Netz deines Servers und das WireGuard-Netz. Wenn würdest du ein zusätzliches IPv6-Subnetz benötigen.
Ich habe mich damals an Mullvad orientiert, die auch nur ULA-Adressen und für IPv6 auch NAT verwenden. Die Geräte im WireGuard-Netz können sich dann gegenseitig über die ULA-Adressen ansprechen. Sobald sie nach außen kommunizieren wollen, wird die öffentliche IPv6 deines Servers verwendet.
Vielleicht kann das jemand aber nochmal genauer begründen. Wirklich sicher, wie und ob man auch die IPv6-Adressen des eigenen Servers verwenden kann, bin ich mir nicht.
Es sind zwei verschiedene Netze: Das Netz deines Servers und das WireGuard-Netz. Wenn würdest du ein zusätzliches IPv6-Subnetz benötigen.
Man kann diese auch kleiner fassen mit Subnetting und die im Tunnel verwenden.
Das wird aber ein wenig komplexer. Ob ich die IPv6 Adressen nun im Tunnel, oder für LXC Container verwende, spielt keine Rolle.
Laufen tut dieser allerdings nicht.
Was heißt sie läuft nicht? Werden die Zertifikate aktualisiert, der Webserver aber ggf. nicht neu gestartet?
Werden die Zertifikate aktualisiert,
Nein, ein stat aller Dateien in /etc/letsencrypt/live/example.com/ zeigt:
Modifiziert: 2023-11-21 08:29:51.974869208 +0100
Geändert: 2023-11-21 08:29:51.974869208 +0100
Geburt: 2023-11-21 08:29:51.974869208 +0100Nein, ein stat aller Dateien in /etc/letsencrypt/live/example.com/ zeigt:
Im live Verzeichnis sind doch nur Symlinks zu den richtigen Zertifikaten?
Was zeigt denn ein certbot certificates bzw. stat -L an?
root@netcup:~# certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
Certificate Name: example.com
Serial Number: h6g123456789h6g123456789h6g123456789
Key Type: ECDSA
Domains: example.com www.example.com
Expiry Date: 2024-02-19 06:29:48+00:00 (INVALID: EXPIRED)
Certificate Path: /etc/letsencrypt/live/example.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/example.com/privkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -In der debug log habe ich folgende Zeile gefunden:
Failed to renew certificate example.com with error: Could not bind TCP port 80 because it is already in use by another process on this system (such as a web server). Please stop the program in question and then try again.
Dies lässt vermuten, ich hätte --standalone als Attribut gesetzt hat, was ich aber nicht habe, sondern wie man in #789 sieht --apache. Ich habe das ganze mit history überprüft:
Zitat63 sudo apt install certbot python3-certbot-apache
66 sudo certbot --apache --agree-tos --redirect --hsts --staple-ocsp --email letsencrypt@example.com -d example.com -d http://www.example.com
Vermutlich könnte ich Apache stoppen, das Zertifikat erneuern, und dann Apache wieder starten – aber das ist ja nicht Sinn der Sache 
Ich schau gleich mal weiter die logs durch, ob ich noch was Interessantes finde, weil aktuell weiß ich nicht wirklich weiter... Danke dir schon mal bis hierhin H6G
EDIT: Nevermind, habe noch was via history gefunden:
116 sudo certbot certonly --standalone -d example.com -d www.example.comKeine Ahnungwas mich da geritten hat, aber das wirds sein. Ich werd einfach die Zertifikate mit certbot löschen und neu anlegen mit --apache
Du könntest mit einer entsprechenden Pre- und Post Hook arbeiten, das dann aber mit systemd in dem certbot-renew Service.
Der Cron Service wird nichts tun, weil er prüft, ob systemd vorhanden ist
https://letsencrypt.org/de/docs/challenge-types/#dns-01-challenge
und man hat mit so Zeuch einfach gar keine Probleme mehr - und kann sich auch Wildcard Zertifikate *.meinedomain.de ziehen.
https://letsencrypt.org/de/doc…e-types/#dns-01-challenge
und man hat mit so Zeuch einfach gar keine Probleme mehr - und kann sich auch Wildcard Zertifikate *.meinedomain.de ziehen.
Hatte ich mich bisher noch nie beschäftigt, aber sehe ich das richtig, das ein Client auf meinem Server dann (über API) vollen Zugriff auf die DNS der domain hat?
Würde ich eigentlich ungern haben. 
aRaphael japp, so ist es.
Könntest aber auch in der 'wichtigen' Domain einen festen Alias hinterlegen und die Challenge dann über den Alias ablaufen lassen - sofern hier andere Zugänge für's DNS zum Tragen kommen, bekäme der LE-Client zumindest nicht die Logindaten für die primäre Domain.
Bietet sich auch an, wenn man für Domain A keinen API-Zugang hat, jedoch für Domain B und koppelt diese beiden dann per Alias.
siehe zb acme.sh:
https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mode
Welche Distri verwendest Du?
Code: /etc/cron.d/certbot... test ... \! -d /run/systemd/system ...Laufen tut dieser allerdings nicht.
Sorgt dafür, das der CRON-Job auf Systemen mit systemd nicht ausgeführt wird.
Da sollte es einen certbot.timer (o.s.ä.) geben, der das erledigt.
Hatte ich mich bisher noch nie beschäftigt, aber sehe ich das richtig, das ein Client auf meinem Server dann (über API) vollen Zugriff auf die DNS der domain hat?
Würde ich eigentlich ungern haben.
Bei Cloudflare hat man die folgenden Möglichkeiten das Token zu konfigurieren:
Insbesondere das Einschränken auf eine IP von der der Zugriff kommen kann ist da schon hilfreich.
Wenn Du jemanden auf dem Server hast, die/der den Token lesen und verwenden kann, hast Du ganz andere Probleme...
Ich verwende die Funktion übrigens so gut wie nicht direkt, sondern eigentlich nur im https://nginxproxymanager.com/ für Container.
Zu dem Thema würde ich auch https://github.com/joohoi/acme-dns in den Raum werfen. Über eine einfache REST-Schnittstelle die nötigen TXT-Records auf einem kleinen DNS-Server bereitstellen.
