Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- knb:rpb4_wg [2020/12/17 09:29] – [Installation] Django
+++ knb:rpb4_wg [2021/01/10 21:31] – [WireGuard-Healthcheck] django
@@ Zeile 13: / Zeile 13: @@
 <WRAP center round info 90%>
-Diese Anleitung funktioniert auf quasi allen Linux basierten Betriebssystemen, mit ein paar Anpassungen. \\
+Diese Anleitung geht von einem Linux Hostrechner aus - sie funktioniert auf quasi allen Linux basierten Betriebssystemen, mit ein paar Anpassungen. \\
 \\
 In den nachfolgenden Beispielen zu den Shell-/Konsolen-Befehlen gelt folgende Formatierungen:
-  * Ein vorangestelltes Dollarzeichen **''$''** bedeutet, dass der bzw. die Befehle mit Userrechten des gerade angemldeten Benutzers ausgeführt werden können.
+  * Ein vorangestelltes Dollarzeichen **''$''** bedeutet, dass der bzw. die Befehle mit Userrechten des gerade angemeldeten Benutzers ausgeführt werden können.
-  * Ein vorangestelltes Raute-Symbol **''#''** hingegen bedeutet, dass zum Ausführen des Befehls bzw. der befehle Root-Rechte benötigt werden, die man z.b. mit Hilfe von **'' $ sudo su -''** erlangen kann.
+  * Ein vorangestelltes Raute-Symbol **''#''** hingegen bedeutet, dass zum Ausführen des Befehls bzw. der Befehle Root-Rechte benötigt werden, die man z.b. mit Hilfe von **'' $ sudo su -''** erlangen kann.
 \\
 Sollten trotz des eingehenden Studiums dieser Anleitung dennoch Fragen offen bleiben, oder unvorhergesehenen Problemstellungen auftreten, findet man im **[[https://chat.ffmuc.net/freifunk/channels/technik-offloader|Chat]]** sicher schnell Hilfe und Unterstützung.
@@ Zeile 23: / Zeile 23: @@
 </WRAP>
-Mit dem [[https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711/rpi_DATA_2711_1p0_preliminary.pdf|Raspberry PI 4]] ist es das erste Mal möglich, einen Offloader sinnvoll auf einem PI zu betreiben. Denn in dieser Version bietet der Ethernet Anschluss genug Durchsatz und die CPU ist leistungsfähig genug um eine ordentliche **wireguard** Performance zu bieten. Dies war bei den Vorgänger Modellen so leider **nicht** der Fall.
+Mit dem [[https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711/rpi_DATA_2711_1p0_preliminary.pdf|Raspberry PI 4]] ist es das erste Mal möglich, einen Offloader sinnvoll auf einem PI zu betreiben. Denn in dieser Version bietet der Ethernet Anschluss genug Durchsatz, und die CPU ist leistungsfähig genug um eine ordentliche **WireGuard** Performance zu bieten. Dies war bei den Vorgänger Modellen so leider **nicht** der Fall.
 <WRAP center round important 60%>
@@ Zeile 34: / Zeile 34: @@
 {{:knb:raspberry:rpi.jpg?405|Bild: Raspberry 4 - Lieferung/Verpackung}} \\
 {{:knb:raspberry:19-06-26_14-06-10_2041.jpg?405|Bild: Raspberry 4 - Platine in Verpackung}}
+===== Ansible-Playbook gesteuerter Bau des Offloaders =====
+<WRAP center round tip 60%>
+Wer nicht  die nachfolgenden gut dokumentierten Schritte per Hand ausführen möchte, kann sich auch mit Hilfe von **[[https://www.ansible.com/|Ansible]]** binnen 20 Minuten automatisiert einen Offloader Menü geführt und scriptiert erstellen lassen.
+<html><center>Das entsprechende <b><a href="https://wiki.mailserver.guru/doku.php/centos:ansible:ffmuc-rpb4-ol" class="urlextern" target="_tab" title="https://wiki.mailserver.guru/doku.php/centos:ansible:ffmuc-rpb4-ol" rel="nofollow noopener">HOWTO</a></b> findet man in <b><a href="https://wiki.mailserver.guru" class="urlextern" target="_tab" title="https://wiki.mailserver.guru" rel="nofollow noopener">Djangos WIKI</a></b>.</center></html>
+</WRAP>
 ===== Raspberry Pi OS =====
@@ Zeile 60: / Zeile 67: @@
 ==== Kopieren des Images auf die MicroSD-Karte ====
-Nun können wir das Image auf die MicroSD-Karte, die wir später in den Raspberry 4B stecken kopieren. Wir werfen also am besten einmal einen Blick in das syslog unseres Arbeitsrechners und erkennen so das Device unserer Speicherkarte.
+Nun können wir das Image auf die MicroSD-Karte, die wir später in den Raspberry 4B stecken, kopieren. Wir werfen also am besten einmal einen Blick in das syslog unseres Arbeitsrechners und erkennen so das Device unserer Speicherkarte.
    # tail -f /var/log/messages
 bzw.
@@ Zeile 77: / Zeile 84: @@
 Sep  5 21:11:09 BOFHs-X230 gnome-terminal-[8119]: g_menu_insert_item: assertion 'G_IS_MENU_ITEM (item)' failed</code>
-In dem gezeigtem Fall handelt es sich also um die Gerätedatei **''/dev/mmcblk0''**. Wir wissen also wie wir nun die zuvor heruntergeladene **[[#download|Debian Buster Image-Datei]]** auf die MicroSD-Karte kopieren müssen. In der Regel hat der "normale Nutzer" keine Rechte um diese Gerätedatei anzusprechen, wir müssen also als Benutzer **root** oder mir den Rechten des Benutzers **root** die  Gerätedatei **''/dev/mmcblk0''** in diesem Konfigurationsbeispiel ansprechen.
+Aus der zweiten Zeile ergibt sich, dass die MicroSD-Karte über die Gerätedatei **''/dev/mmcblk0''** angesprochen werden kann. Die nachfolgenden Zeilen zeigen an, wie das Linux-System den bestehenden Inhalt der Karte interpretiert - tut aber für unsere Zwecke nichts zur Sache, weil wir die Karte eh gleich überschreiben. Achtung: schließt man die MicroSD-Karte z.B. über einen USB-Adapter an, kann sie auch unter einem anderen Namen erscheinen, z.B. **''/dev/sde''**. Und hier ist Gefahr in Verzug, weil die System-Platte des Host-Rechners auch unter **''/dev/sd<irgendwas>''** erscheint, und es auch erfahrenen Benutzern passiert, die Buchstaben zu verwechseln, und beim nachfolgenden Schreibvorgang sein System zerschießt.
+Mit Hilfe der Gerätedatei können wir das heruntergeladene **[[#download|Debian Buster Image-Datei]]** auf die MicroSD-Karte kopieren. In der Regel hat der "normale Nutzer" keine Rechte um diese Gerätedatei anzusprechen, wir müssen also als Benutzer **root** oder mit den Rechten des Benutzers **root** den Kopiervorgang aufrufen:
    # dd if=~/2020-08-20-raspios-buster-armhf-lite.img of=/dev/mmcblk0  bs=4M status=progress conv=fsync
@@ Zeile 83: / Zeile 92: @@
    $ sudo dd if=/home/django/Freifunk/2020-08-20-raspios-buster-armhf-lite.img of=/dev/mmcblk0 bs=4M status=progress conv=fsync</code>
-Da wir später weder Tastatur noch Monitor an unseren Raspberry 4B anstecken wollen, diesen demnach im **headless**-Mode betreiben wollen und werden, legen wir noch eine Datei **''/boot/ssh''** auf der SD-Karte ab. Nach dem erneuten Anstecken der MicroSD-Karte wir der Speicher in der Regel im Verzeichnis **''/run/media/''** oder auch **''/media/''**gemountet. Zum Anlagen der betreffenden Datei  **''ssh''** in dem Verzeichnis reicht also folgender Aufruf, bei dem wir den Usernamen natürlich unseren Gegebenheiten entsprechend anpassen.:
+Wenn der Kopiervorgang abgeschlossen ist, Karte entfernen und wieder einstecken. Das System erkennt die beiden Partitions auf der Karte. Je nach Systemeinstellungen mountet sie die Partitions automatisch - in der Regel im Verzeichnis **''/run/media/''** oder auch **''/media/''**. Oder es erscheint in der Systemleiste ein Icon für einen neu erkannten Wechseldatenspeicher, den man dann per Mausklick mounten kann. Wer unsicher ist, kann
+   # mount
+aufrufen, und feststellen, wo die **root-Partition** und die **boot-Partition** zu finden ist.
+Da wir später weder Tastatur noch Monitor an unseren Raspberry 4B anstecken wollen, diesen demnach im **headless**-Mode betreiben wollen und werden, legen wir noch eine leere Datei **''ssh''** auf der **boot**-Partition ab. Damit wird beim Hochfahren der ssh-Server auf dem RPi gestartet, mit dessen Hilfe wir uns über das Netzwerk einloggen können. Zum Anlagen dieser Datei  **''ssh''** reicht folgender Aufruf, bei dem wir den Pfad, und insbesondere den Usernamen im Pfad, natürlich unseren Gegebenheiten entsprechend anpassen:
    # touch /run/media/django/boot/ssh
 bzw.
    $ touch /media/django/boot/ssh
-Anschließend können wir nach einem Unmounten des Gerätes **''/dev/sdb''** die Micro-SD-Karte in den Kartenslot des Raspberry 4B stecken und den Kleinstcomputer mit dem Netzwerk sowie dem zugehörigen Netzteil verbinden und starten.
+Anschließend können wir nach einem Unmounten der Partitions **''/dev/mmcblk0p*''** die Micro-SD-Karte in den Kartenslot des Raspberry 4B stecken und den Kleinstcomputer mit dem Netzwerk sowie dem zugehörigen Netzteil verbinden und starten.
 ===== Vorbereitende Konfigurationsschritte =====
@@ Zeile 160: / Zeile 175: @@
 ==== Änderung des Hostnamens ====
-Damit unser neuer Offloader auch sauber mit seinem Namen angesprochen und dieser Name dann auch weiterverwendet werden kann, passen wir diesen nun erst einmal an. In unserem Konfigurationsbeispiel soll dies der Name **''rpb4-wg-ol''** lauten.
+Unser neuer Offloader braucht einen eigenen Namen, mit dem er sich von anderen eigenen Raspberry P4 unterscheiden lässt. In unserem Konfigurationsbeispiel soll der Name **''rpb4-wg-ol''** lauten. Das Setzen des Nodenamens, mit der unser Offloader dann auch auf der Freifunk-Karte später erscheinen wird, erfolgt im Abschnitt **[[#ext-respondd|Konfiguration des ext-respondd]]**!
-Nun setzen wir den Hostnamen wie folgt:
+Wir setzen den Hostnamen wie folgt:
    # hostnamectl set-hostname rpb4-wg-ol
-Damit beim späteren Wechsel der Userrechte zu keiner Warnmeldung kommt, da der Hostname nicht aufgelöst werden konnte, korrigieren wir gleich noch die Konfigurationsdatei **''/etc/hosts''** und ändern dort in der letzten Zeile den Defaultwert von **''raspberrypi''** auf unseren neuen individuellen Namen **''rpb4-wg-ol''** ab.
+Damit es beim späteren Wechsel der Userrechte zu keiner Warnmeldung kommt, weil der Hostname nicht aufgelöst werden konnte, korrigieren wir gleich noch die Konfigurationsdatei **''/etc/hosts''**, und ändern auch dort den Standardnamen **''raspberrypi''** auf unseren neuen individuellen Namen **''rpb4-wg-ol''** ab.
    # vim /etc/hosts
 <file bash /etc/hosts>127.0.0.1	localhost
@@ Zeile 184: / Zeile 199: @@
 <WRAP center round alert 80%>
-Möchte man vom Raspberry später auch ein WLAN ausstrahlen lassen so ist es zwingend von Nöten, dass WIFI explizit via **rfkill** freizugeben!
+Möchte später auch das WLAN des Raspberry verwenden, so ist es zwingend von Nöten, dass WIFI explizit via **rfkill** freizugeben!
 Hier loggen wir uns per SSH ein und setzen folgenden Befehl ab:
    # rfkill unblock wifi
-Zum Aktivieren ist noch ein Reboot unseres Raspberry 4 nötig!
+Erst ein Reboot unseres Raspberry 4 aktiviert das WLAN tatsächlich!
    # systemctl reboot
 </WRAP>
@@ Zeile 197: / Zeile 212: @@
    # apt-get upgrade -y
-Nun ist es an der Zeit, das wir unseren Kleinstrechner **rpb4-wg-ol** neu zu starten.
+Nun ist es dann doch an der Zeit, dass wir unseren Kleinstrechner **rpb4-wg-ol** neu zu starten.
    # systemctl reboot
 ===== BATMAN =====
-Für das Routing der Layer-2-Verbindungen innerhalb des Freifunknetzes wird als Mesh-Protokoll **[[https://de.wikipedia.org/wiki/B.A.T.M.A.N.|B.A.T.M.A.N.-Advanced]]** kurz **''batman-adv''** benötigen, welches wir uns nun in diesem Abschnitt installieren und konfigurieren wollen.
+Für das Routing der Layer-2-Verbindungen innerhalb des Freifunknetzes wird als Mesh-Protokoll **[[https://de.wikipedia.org/wiki/B.A.T.M.A.N.|B.A.T.M.A.N.-Advanced]]** kurz **''batman-adv''** eingesetzt, welches wir uns nun in diesem Abschnitt installieren und konfigurieren wollen.
 <WRAP center round tip 60%>
@@ Zeile 223: / Zeile 238: @@
 ==== Kernelmodule ====
-Nachdem das Kernelmodul manuell gebaut wird, wollen wir natürlich dass das auch Bestand hat, wenn ein Kernelupdate eingespielt wird. Dazu brauchen wir nun einige Pakete, die wir erst einmal installieren werden.
+Nachdem das Kernelmodul manuell gebaut wird, wollen wir natürlich, dass das auch Bestand hat, wenn ein Kernelupdate eingespielt wird. Dazu brauchen wir nun einige Pakete, die wir erst einmal installieren werden.
    # apt update && apt install dkms raspberrypi-kernel-headers
-Anschließend müssen wir auf Grund dessen, dass der Raspberry PI Kernel crosscompiled wurde, die make Skripte neu generieren.
+Anschließend müssen wir die make Skripte neu generieren, weil der Raspberry PI Kernel ursprünglich crosscompiliert wurde.
    # cd linux-headers-$(uname -r)
@@ Zeile 246: / Zeile 261: @@
 </WRAP>
-Da nun alle nötigen vorbereitenden Installations- und Konfigurationsschritte abgearbeitet wurden, machen wir uns an das Anlegen der für B.A.T.M.A.N. notwendigen Konfigurationsdatei **''dkms.conf''**.
+Da nun alle nötigen vorbereitenden Installations- und Konfigurationsschritte abgearbeitet sind, machen wir uns an das Anlegen der für B.A.T.M.A.N. notwendigen Konfigurationsdatei **''dkms.conf''**.
    # cd ../batman-adv-2020.4/
@@ Zeile 267: / Zeile 282: @@
 Zum Speichern und Verlassen des Editors **vim** benutzen wir den **Vim**-Syntax **''ESC :x''**.
-Nun sind wir mit unserer Konfiguration soweit dass wir die B.A.T.M.A.N-Kernelmodule bauen können.
+Nun sind wir mit unserer Konfiguration soweit, dass wir die B.A.T.M.A.N-Kernelmodule bauen können.
    # dkms add -m batman-adv -v 2020.4
@@ Zeile 331: / Zeile 346: @@
  * BATMAN_V</code>
-Nun kommen wir zur Interface Konfiguration. In diesem Beispiel, werden wir das Raspberry PI im Segment "**welt**" ansiedeln, deswegen benennen wir das zugehörige Interface **''br-welt''** auch entsprechend. Hierzu benötigen wir noch die **''bridge-utils''** die wir uns nun noch nachinstallieren werden.
+Nun kommen wir zur Interface Konfiguration. In diesem Beispiel werden wir den RPi-Offloader im Segment "**welt**" ansiedeln, deswegen benennen wir das zugehörige Interface **''br-welt''** auch entsprechend. Hierzu benötigen wir noch die **''bridge-utils''**, die wir uns noch installieren:
    # apt install bridge-utils -y
-Wir können mit nachfolgendem Befehl noch überprüfen, ob die Version von **''batctl''** auch zur installierten Version von **''batman-adv''** passt.
+Wir können mit nachfolgendem Befehl überprüfen, ob die Version von **''batctl''** auch zur installierten Version von **''batman-adv''** passt.
    # batctl -v
@@ Zeile 377: / Zeile 392: @@
 ===== WIREGUARD =====
 ==== Grundlagen / Hintergründe ====
-Für die Verbindung unseres Offloaders/Nodes zum Freifunk München Netz greifen wir auf den VPN-Tunnel Mechanismus von **[[https://www.wireguard.com/|wireguard]]** zurück. Hintergründe zum Wechsel von **[[https://github.com/NeoRaider/fastd/wiki|FASTD]]** hin zu **[[https://www.wireguard.com/|WireGuard]]** ist in diesem **[[https://ffmuc.net/freifunkmuc/2020/12/03/wireguard-firmware/|BlogPost]]** ausführlich beschrieben.
+Für die Verbindung unseres Offloaders/Nodes zum Freifunk München Netz greifen wir auf den VPN-Tunnel Mechanismus von **[[https://www.wireguard.com/|WireGuard]]** zurück. Hintergründe zum Wechsel von **[[https://github.com/NeoRaider/fastd/wiki|FASTD]]** hin zu **[[https://www.wireguard.com/|WireGuard]]** ist in diesem **[[https://ffmuc.net/freifunkmuc/2020/12/03/wireguard-firmware/|BlogPost]]** ausführlich beschrieben.
 <WRAP center round important 80%>
@@ Zeile 386: / Zeile 401: @@
    * **(remote) publickey** : Öffentliche Schlüssel des VPN-Gatway-Endpunktes
    * **lokale link-local-Adresse** : IPv6 Adresse des VPN-Endpunktes am Offloader
-   * **(client) privatekey** : Private :!: Schlüssel für den wireguard-Endpunkt am Offloader
+   * **(client) privatekey** : Private :!: Schlüssel für den WireGuard-Endpunkt am Offloader
-   * **(client) publickey** : Öffentliche Schlüssel für den wireguard-Endpunkt am Offloader
+   * **(client) publickey** : Öffentliche Schlüssel für den WireGuard-Endpunkt am Offloader
 Bitte informiert euch vorher in welches Segment ihr wollt, dementsprechend müssen die Daten aus nachstehender Tabelle entnommen bzw. lokal generiert werden!
@@ Zeile 463: / Zeile 478: @@
 </html>
-Wir erzeugen nun als erstes das Schlüsselpaar (private-/public-key) für unseren VPN-Client.
+Wir erzeugen nun im ersten Schritt das Schlüsselpaar (private-/public-key) für unseren VPN-Client.
    # wg genkey | tee /etc/wireguard/client_private.key | wg pubkey | tee /etc/wireguard/client_public.key
-Im Konfigurationsverzeichnis von wireguard haben wir nun beide Schlüssel. Die Dateiberechtigungen passen wir gleich mal noch an, damit nur der User **root** auf diese zugreifen kann.
+Im Konfigurationsverzeichnis von WireGuard finden wir nun beide Schlüssel. Die Dateiberechtigungen passen wir gleich mal noch an, damit nur der User **root** auf diese zugreifen kann.
    # chmod 600 /etc/wireguard/*.key
-Die link-local IPv6-Adresse unseres lokalen VPN-Entpunktes ermitteln wir mit hilfe folgenden Befehls, nachdem wir den public.key zuvor erfolgreich erstellt hatten.
+Die link-local IPv6-Adresse unseres lokalen VPN-Entpunktes ermitteln wir mit Hilfe folgenden Befehls, nachdem wir den public.key zuvor erfolgreich erstellt hatten.
    # cat /etc/wireguard/client_public.key | md5sum | sed 's/^\(..\)\(..\)\(..\)\(..\)\(..\).*$/fe80::02\1:\2ff:fe\3:\4\5/' > /etc/wireguard/link-local
@@ Zeile 515: / Zeile 530: @@
 **WICHTIG**:
-Der  (client) privatekey unseres Clients ist natürlich nicht publik zu machen uns ist nur hier im Rahmen deieses How2s abgedruckt, damit die weitere Konfiguration leichter zu verstehen ist. Im Relalife-Betrieb hüten wir diesen Schlüssel natürlich wie immer obligatorisch!
+Der private Schlüssel unseres Clients (privatekey) ist natürlich nicht publik zu machen und ist nur hier im Rahmen dieses How2s abgedruckt, damit die weitere Konfiguration leichter zu verstehen ist. Im Relalife-Betrieb hüten wir diesen Schlüssel natürlich wie immer "wie unseren Augapfel"!
 </WRAP>
+Damit nun das Gateway auch VPN-Verbindungen unseres WireGuard-clients akzeptieren kann benötigt dieses natürlich unseren **public-key**, den wir nun an das Gateway schicken müssen:
-Damit nun das Gateway auch VPN-Verbindungen unseres wireguard-clients akzeptieren kann benötigt dieses natürlich unseren **public-key**, den wir nun an das Gateway schicken müssen:
    # wget -q -O- --post-data='{"domain": "ffmuc_welt","public_key": "HjDRCwE4Q7UPAKXrmM4s6VOgMK+HJZCixWTaVC8KiRU="}' http://broker.ffmuc.net/api/v1/wg/key/exchange
   {"Message":"OK"}
-Die Bestätigung **''"Message":"OK"''** zeigt uns dass der Broker auf der Zielseite, also auf den Gatewasy unseren Pblic-key akzeptiert hat und diesen beim nachfolgenden Tunnelaufbau auch akzeptieren wird!
+Die Bestätigung **''"Message":"OK"''** zeigt uns, dass der Broker auf der Zielseite, also auf den Gatewasy unseren Pblic-key akzeptiert hat und diesen beim nachfolgenden Tunnelaufbau auch verwenden wird!
-Damit nun der Broker vor dem Starten unseres Tunnels auch immer unseren öffentlichen Schlüssel hat, stellen wir nun noch sicher, dass dieser automatisiert vor dem Starten des WireGurad-Daemon einmal zum Broker|Gateway übertragen wird. HIerzu legen wir uns ein systemd-Startscript an.
+Damit nun der Broker vor dem Starten unseres Tunnels auch immer unseren öffentlichen Schlüssel hat, stellen wir nun noch sicher, dass dieser automatisiert vor dem Starten des WireGuard-Daemon einmal zum Broker|Gateway übertragen wird. Hierzu legen wir uns ein systemd-Startscript an.
    # vim /etc/systemd/system/broker.service
@@ Zeile 557: / Zeile 571: @@
   Created symlink /etc/systemd/system/default.target.wants/broker.service → /etc/systemd/system/broker.service.
-Was unser Client noch benötigt ist eine rudimentäre Konfigurationsdatei für unseren wireguard-client, die wir nun als nächstes anlegen müssen.
+Was unser Client noch benötigt ist eine rudimentäre Konfigurationsdatei für unseren WireGuard-client, die wir nun als nächstes anlegen müssen.
    # vim /etc/wireguard/wg-welt.conf
 <file bash /etc/wireguard/wg-welt.conf># Django : 2020-12-15
@@ Zeile 580: / Zeile 594: @@
 </code>
-Den Status unseres wireguard-clients können wir mit Hilfe der Option **show** beim Aufruf von **''wg''** bzw. nur dur Aufruf von **''wg''** ermitteln
+Den Status unseres WireGuard-clients können wir mit Hilfe der Option **show** beim Aufruf von **''wg''** bzw. nur dur Aufruf von **''wg''** ermitteln
    # wg show
 oder einfach nur
@@ Zeile 600: / Zeile 614: @@
 Da sowohl bei **''transfer''** wie auch bei **''received''** die Werte steigen sobald wie den Status erneut abfragen, können wir im ersten Schritt davon ausgehen, dass der WireGuard-Tunnel steht und auch benutzt werden kann.
-Wir sollten auch nun den Tunnelenpunkt am Gateway anpingen können. in unserem Konfiguratiosnbeispiel wäre dies demnach die Ziel-IP-Adresse **''fe80::27c:16ff:fec0:6c74''** auf dem Netzwerk-Device **''wg-welt''**.
+Wir sollten auch nun den Tunnelenpunkt am Gateway anpingen können. In unserem Konfiguratiosnbeispiel wäre dies demnach die Ziel-IP-Adresse **''fe80::27c:16ff:fec0:6c74''** auf dem Netzwerk-Device **''wg-welt''**.
    # ping6 -c4 fe80::27c:16ff:fec0:6c74%wg-welt
 <code>PING fe80::27c:16ff:fec0:6c74%wg-welt(fe80::27c:16ff:fec0:6c74%wg-welt) 56 data bytes
@@ Zeile 620: / Zeile 634: @@
    # systemctl start wg-quick@wg-welt
-Der stop des wireguard-deamon erfolgt entsprechend mit:
+Der Stop des WireGuard-Deamon erfolgt entsprechend mit:
    # systemctl stop wg-quick@wg-welt
-Den Status des wireguard-Client-daemon fragen wir mit der Option **status** ab.
+Den Status des WireGuard-Client-daemon fragen wir mit der Option **status** ab.
    # systemctl status wg-quick@wg-welt
@@ Zeile 652: / Zeile 666: @@
   Created symlink /etc/systemd/system/multi-user.target.wants/[email protected] → /lib/systemd/system/[email protected].
-/*
-<code>root@rpb4-ansible-v4-wireguard:/home/pi# history
+==== WireGuard-Healthcheck ====
-  ip a
-  cat /etc/network/interfaces
-  /usr/sbin/batctl ra BATMAN_V
-  /sbin/ip link add dummy-welt type dummy
-  /sbin/ip link set address $(ip -br l | grep eth0 | egrep -o '([0-9A-Fa-f]{2}[:-]){5}([0-9A-Fa-f]{2})' | head -1) dev dummy-welt
-  /sbin/ip link set dummy-welt up
-  /usr/sbin/batctl -m bat-welt if add dummy-welt
-  ip a
-  man batctl
-  /usr/sbin/batctl meshif bat-welt if add dummy-welt
-  vim /etc/network/interfaces
-  ip link del dummy-welt
-  ip link del bat-welt
-  ip a
-  systemctl reboot
-  ip a
-  cat /etc/network/interfaces
-  ip addr
-  vatctl -v
-  batctl -v
-  echo /etc/network/interfaces
-  vim /usr/local/bin/genkeys
-  whereis chmod
-  vim /usr/local/bin/genkeys
-  apt install wireguard --assume-yes
-  wg genkey | tee /etc/wireguard/client_private.key | wg pubkey | tee /etc/wireguard/client_public.key
-  chmod 600 /etc/wireguard/*.key
-  ll /etc/wireguard/
-  ls -alF /etc/wireguard/
-  cat /etc/wireguard/client_private.key
-  cat /etc/wireguard/client_public.key
-  vim /usr/local/bin/genlinklocal
-  cat  /usr/local/bin/genlinklocal
-  chmod +x /usr/local/bin/genlinklocal
-  genlinklocal
-  vim /usr/local/bin/genlinklocal
-  genlinklocal
-  vim /usr/local/bin/genlinklocal
-  genlinklocal
-  # cat /etc/wireguard/client_public.key | md5sum | sed 's/^\(..\)\(..\)\(..\)\(..\)\(..\).*$/fe80::00\1:\2ff:fe\3:\4\5/'
-  cat /etc/wireguard/client_public.key | md5sum | sed 's/^\(..\)\(..\)\(..\)\(..\)\(..\).*$/fe80::00\1:\2ff:fe\3:\4\5/'
-  cat /etc/wireguard/client_public.key | md5sum | sed 's/^\(..\)\(..\)\(..\)\(..\)\(..\).*$/fe80::02\1:\2ff:fe\3:\4\5/'
-  genlinklocal
-  cat /etc/wireguard/client_public.key | md5sum | sed 's/^\(..\)\(..\)\(..\)\(..\)\(..\).*$/fe80::02\1:\2ff:fe\3:\4\5/'
-  cat /usr/local/bin/genlinklocal
-  cat /etc/wireguard/client_public.key | md5sum | sed 's/^\(..\)\(..\)\(..\)\(..\)\(..\).*$/fe80::02\1:\2ff:fe\3:\4\5/' > /etc/wireguard/link-local
-  cat /etc/wireguard/link-local
-  vim /usr/local/bin/wg-setup
-  chmod +x /usr/local/bin/wg-setup
-  wg-setup
-  ip a
-  ip link del wg-welt
-  vim /usr/local/bin/wg-setup
-  wg-setup
-  ip a
-  vim /usr/local/bin/wg-setup
-  ip a
-  ip link del wg-welt
-  ip a
-  wg-setup
-  ip a
-  wg show
-  wg show
-  wg
-  wg
-  wg
-  cat /etc/wireguard/client_public.key
-  wg
-  ip a
-  wg-setup
-  vim /usr/local/bin/wg-setup
-  vim /usr/local/bin/wg-setup
-  wg-setup
-  ip a
-  wg
-  wg
-  wg
-  ip a
-  batctl meshif bat-welt gw
-  batctl meshif bat-welt if
-  cat /sys/devices/virtual/net/mesh-vpn/batman_adv/throughput_override
-  ip a
-  batctl meshif bat-welt if
-  batctl meshif bat-welt gwl
-   ping6 -c4 fe80::27c:16ff:fec0:6c74%wg-welt
-  wg show
-  wg show
-  wg show
-  ip a
-  batctl meshif bat-welt if
-  batctl meshif bat-welt if add mesh-vpn
-  batctl meshif bat-welt if
-  batctl meshif bat-welt gwl
-  ip a
-  ip a
-  ip a
-  ip a
-  ls /sys/devices/virtual/net/mesh-vpn/batman_adv/throughput_override
-  ls /sys/devices/virtual/net/mesh-vpn/upper_bat-welt/
-  batctl meshif bat-welt throughput_override 10000
-  batctl hardif bat-welt throughput_override 10000
-  ip a
-  batctl hardif bat-welt throughput_override 10000
-  3:41 PM
-  batctl hardif mesh-vpn throughput_override 10000
-  whereis batctl
-  vim /usr/local/bin/wg-setup
-  🦥 🏴‍☠️
-  🏴‍☠️
-  🔓
-  apt install git python3-netifaces
-  git clone https://github.com/freifunkMUC/ext-respondd /opt/ext-respondd/
-  cp /opt/ext-respondd/ext-respondd.service.example /etc/systemd/system/ext-respondd.service
-  systemctl daemon-reload
-  systemctl enable ext-respondd
-  vim /opt/ext-respondd/alias.json
-  vi /opt/ext-respondd/config.json
-  vi /opt/ext-respondd/config.json
-  systemctl start ext-respondd
-  systemctl status ext-respondd
-  apt install hostapd
-  echo 'DAEMON_OPTS="-d"' >> /etc/default/hostapd
-  vi /etc/hostapd/hostapd.conf
-  systemctl unmask hostapd
-  systemctl enable hostapd
-  systemctl start hostapd
-  systemctl status hostapd
-  vim /etc/rc.local
-   /sbin/brctl addif br-welt wlan0
-  ip a
-  vim /opt/ext-respondd/alias.json
-  systemctl restart ext-respondd
-  history
-</code>
-*/
-==== wiregurad-Healthcheck ====
 Im Betrieb kann es ab und an passieren, dass der WireGuard-Tunnel zusammenbricht, weil z.B. die Netzwerkverbindung abgerissen sit, oder ein Rebot der Gateways notwendig war. Damit in einem solchen Fall unser Offloader nicht **__offload__** geht, müssen wir die Verfügbar- und Nutzzbarkeit deer Tunnelverbindung in regelmäßigen Abständen prüfen und ggf. einschreiten und die Verbindung neu aufbauen.
@@ Zeile 811: / Zeile 689: @@
         /usr/bin/wget -q -O- --post-data='{"domain":"ffmuc_welt","public_key":"HjDRCwE4Q7UPAKXrmM4s6VOgMK+HJZCixWTaVC8KiRU="}' http://broker.ffmuc.net/api/v1/wg/key/exchange
         logger -t checkuplink "Starting wireguard-daemon."
-        systemctl start wg-quick@wg-uplink
+        systemctl start wg-quick@wg-welt
         logger -t checkuplink "Starting vxlan-meshing."
         vxlan
@@ Zeile 867: / Zeile 745: @@
 <WRAP center round alert 60%>
 **WICHTIG**: \\
-Die hierzu nötige **vxlan id** darf nicht mit der VX-LAN.ID verwechslet werden, die wir ggf. später zum Meshen hinter unserem Offloadedr anbieten möchten.
+Die hierzu nötige **vxlan id** darf nicht mit der VX-LAN-ID verwechselt werden, die wir ggf. später zum Meshen hinter unserem Offloader anbieten möchten.
 </WRAP>
@@ Zeile 924: / Zeile 802: @@
    # chmod +x /usr/local/bin/vxlan
-Damit das vxlan-Meshing automatisch beim Starten unseres Offloaders gestartet wird, legen wir uns auch hier ein antsprechendes systemd-Startscript an.
+Damit das vxlan-Meshing automatisch beim Starten unseres Offloaders gestartet wird, legen wir uns auch hier ein entsprechendes systemd-Startscript an.
    # vim /etc/systemd/system/vxlan.service
 <file bash /etc/systemd/system/vxlan.service># Django : 2020-12-15
@@ Zeile 944: / Zeile 822: @@
 </file>
-Wie schon zuvor bei unserem Broker-Informations-systemd-Startscriot informieren wir hier nun systemd über unsere neue systemd-Startupdatei.
+Wie schon zuvor bei unserem Broker-Informations-systemd-Startscript informieren wir hier nun systemd über unsere neue systemd-Startupdatei.
    # systemctl daemon-reload
@@ Zeile 950: / Zeile 828: @@
    # systemctl start vxlan.service
-Für den automatischen Start beim Hochfahren unseres Offloaders aktivieren wir nun noch das entsprechende script.
+Für den automatischen Start beim Hochfahren unseres Offloaders aktivieren wir nun noch das entsprechende Script.
    # systemctl enable vxlan.service
@@ Zeile 962: / Zeile 840: @@
 ==== Werteermittlung ====
-Wir ermitteln also am einfachsten die Geo-Koordinaten aus der Feifunk München Karte: https://map.ffmuc.net
+Wir ermitteln also am einfachsten die Geo-Koordinaten aus der Freifunk München Karte: https://map.ffmuc.net
-{{ :knb:raspberry:ffmuc_map_01.png?900 |Bild: Kartenauschnitt der Freifunk München Karte zur Ermittlung der Geo-Koordinaten}}
+{{ :knb:raspberry:ffmuc_map_01.png?900 |Bild: Kartenausschnitt der Freifunk München Karte zur Ermittlung der Geo-Koordinaten}}
@@ Zeile 1013: / Zeile 891: @@
 </WRAP>
-Wir tragen demach folgende Daten ein:
+Wir tragen demnach folgende Daten ein:
 \\
 <html>
@@ Zeile 1104: / Zeile 982: @@
 </pre></html>
-Nach kurzer Zeit taucht unser Node auf der Karte auf.
+Nach kurzer Zeit taucht unser Node dann auch auf der Karte auf.
 {{ :knb:raspberry:ffmuc_map_02.png?700 |Bild: Freifunk München Karte mit eingetragenem neune Node}}
@@ Zeile 1127: / Zeile 1005: @@
   br-welt          UP             10.80.204.2/21 2001:678:e68:109:dea6:32ff:fe5c:4607/64 fe80::dea6:32ff:fe5c:4607/64
-Wir sehen somit die Adresen auf unseren Interfaces aus dem gewählten Segment.
+Wir sehen somit die Adressen auf unseren Interfaces aus dem gewählten Segment.
 Als nächstes prüfen wir, ob die beiden Interfaces **''dummy-welt''** und **''mesh-vpn''** aktiv sind.
@@ Zeile 1141: / Zeile 1019: @@
 a:5d:44:50:c3:f8    0.220s (       10.0) [  mesh-vpn]</code>
-Zu guter letzt sehen wir uns noch die Gateway-Liste an über bzw. mit denen unser Offloader verbunden ist.
+Zu guter Letzt sehen wir uns noch die Gateway-Liste an über bzw. mit denen unser Offloader verbunden ist.
    # batctl meshif bat-welt gwl
 <code>[B.A.T.M.A.N. adv 2020.4, MainIF/MAC: dummy-welt/dc:a6:32:5c:46:07 (bat-welt/dc:a6:32:5c:46:07 BATMAN_V)]
@@ Zeile 1269: / Zeile 1147: @@
    # echo 'DAEMON_OPTS="-d"' >> /etc/default/hostapd
-==== Konfiguartion ====
+==== Konfiguration ====
- Nun legen wir uns eine entsprechende KOnfigurationsdatei an.
+ Nun legen wir uns eine entsprechende Konfigurationsdatei an.
    # vim /etc/hostapd/hostapd.conf
@@ Zeile 1277: / Zeile 1155: @@
 ssid=muenchen.freifunk.net/welt
-country_code=US
+country_code=DE
 interface=wlan0
@@ Zeile 1308: / Zeile 1186: @@
 </file>
-Anschließend ativieren und starten wir den **''hostapd''**-Daemon.
+Anschließend aktivieren und starten wir den **''hostapd''**-Daemon.
    # systemctl unmask hostapd
    # systemctl enable hostapd
@@ Zeile 1339: / Zeile 1217: @@
 </file>
-Am Besten nochmal rebooten um sicher zugehen dass alles passt, danach einfach mit dem ClientWifi verbinden.
+Am Besten nochmal rebooten um sicher zugehen, dass alles passt, danach einfach mit dem ClientWifi verbinden.
    # systemctl reboot
 ===== LAN Clients =====
-Will man LAN Clients versorgen, so erstellt man am einfachsten ein VLAN getaggtes Clientnetz. Dazu erstellt man in der Konfigurationsdatei **''/etc/network/interfaces''** diezugehörige Konfiguration. Im folgenden Beispiel nutzen wir die VLAN-ID **''333''** und definieren zunächst einmal das VLAn-Interface und fügen es anschließend in der vorhandenen Bridge hinzu.
+Will man LAN Clients versorgen, so erstellt man am einfachsten ein VLAN getaggtes Clientnetz. Dazu erstellt man in der Konfigurationsdatei **''/etc/network/interfaces''** die zugehörige Konfiguration. Im folgenden Beispiel nutzen wir die VLAN-ID **''333''** und definieren zunächst einmal das VLAn-Interface und fügen es anschließend in der vorhandenen Bridge hinzu.
    # vim /etc/network/interfaces
 <file bash /etc/network/interfaces>
@@ Zeile 1450: / Zeile 1328: @@
 ==== Installation der Software-Bibliotheken ====
-Jetzt installieren wir die notwendige Python Library um das Display ansteuern zu können.
+Jetzt installieren wir die notwendige Python Bibliotheken  um das Display ansteuern zu können.
    # apt install git fonts-freefont-ttf -y
    # cd /usr/local/src/
@@ Zeile 1738: / Zeile 1616: @@
 </file>
-Anschließend Informieren wir unser System über unser definiertes Daemon-Startscript und aktivieren dies auch gleich noch.
+Anschließend informieren wir unser System über unser definiertes Daemon-Startscript und aktivieren dies auch gleich noch.
    # systemctl daemon-reload
    # systemctl enable oled-bandwidth.service
-Zu guter letzte rebooten wir nun unseren Rechner.
+Zu guter Letzt rebooten wir nun unseren Rechner.
    # systemctl reboot