Server administrieren - wo fange ich an?

  • 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.



    [RS] 2000 G9 | Cyber Quack

    [VPS] 2000 ARM G11 | 1000 G9 | 200 G8 | Secret | A | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE

  • 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.

    RS Brezn | VPS 500 G8 Plus | 2× VPS Karneval 2020 | VPS Pocket Admin | RS Cyber Quack | VPS 500 ARM


    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

    Happy Duck 1 Like 1
  • 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?

    [RS] 2000 G9 | Cyber Quack

    [VPS] 2000 ARM G11 | 1000 G9 | 200 G8 | Secret | A | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE

    Edited once, last by Bud ().

  • 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.

    RS Brezn | VPS 500 G8 Plus | 2× VPS Karneval 2020 | VPS Pocket Admin | RS Cyber Quack | VPS 500 ARM


    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

  • Das heißt fürs forwarding ins WWW würde ich das IPv6-Subnetz von netcup verwenden, und für den Tunnel ULA-Adressen?

    [RS] 2000 G9 | Cyber Quack

    [VPS] 2000 ARM G11 | 1000 G9 | 200 G8 | Secret | A | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE

  • 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.

  • Für eine meiner Domains, welche auf einen Server zeigt, ist heute das LE-Zertifikat abgelaufen. Als ich mich in das Thema eingelesen hatte, verstand ich das so, dass certbot automatisch ein cron anlegt

    Code
    sudo certbot --apache --agree-tos --redirect --hsts --staple-ocsp --email letsencrypt@example.com -d example.com -d www.example.com

    Die Datei /etc/cron.d/certbot ist auch vorhanden:

    Code: /etc/cron.d/certbot
    SHELL=/bin/sh
    PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
    
    0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew --no-random-sleep-on-renew

    Laufen tut dieser allerdings nicht. Hat jemand Ideen? Hätte ich trotzdem noch irgendwie selbst tätig werden müssen?

    [RS] 2000 G9 | Cyber Quack

    [VPS] 2000 ARM G11 | 1000 G9 | 200 G8 | Secret | A | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE

  • Werden die Zertifikate aktualisiert,

    Nein, ein stat aller Dateien in /etc/letsencrypt/live/example.com/ zeigt:

    Code: stat cert.pem
    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 +0100

    [RS] 2000 G9 | Cyber Quack

    [VPS] 2000 ARM G11 | 1000 G9 | 200 G8 | Secret | A | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE

  • 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:

    Quote

    63 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:

    Code
    116  sudo certbot certonly --standalone -d example.com -d www.example.com

    Keine Ahnungwas mich da geritten hat, aber das wirds sein. Ich werd einfach die Zertifikate mit certbot löschen und neu anlegen mit --apache

    [RS] 2000 G9 | Cyber Quack

    [VPS] 2000 ARM G11 | 1000 G9 | 200 G8 | Secret | A | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE

    Edited 2 times, last by Bud ().

  • 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 ;)

  • 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:

    pasted-from-clipboard.png


    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.

    RS Ostern L OST22 (~RS "3000" G9.5) (8C,24GB,960GB) | RS Cyber Quack (1C,2GB,40GB)

    Edited 2 times, last by TBT ().