Hat ein wenig Nerven gekostet und der Artikel ist auch was länger geworden 🙂 Viel Spaß beim Lesen und testen!
Redis Replication über Wireguard
-
Heutiges Kaffethema, Redis Replication über Wireguard
Die Idee / Das Problem
Ich setze als eine Sicherung der Daten der Redis Datenbank, die Redis Funktion Replication ein.
Redis tauscht die Daten im Klartext aus!
Da ich das weiß, hatte ich die Kommunikation zwischen zwei Servern in der Hetzner Cloud über ein privates Netz abgewickelt. Da ich aber da nicht sicher bin, wer da so alles dran käme, machen wir das Ganze noch einen Tick sicherer
Vorab, man kann die Serververbindung auch mittels TLS absichern. Da ich aber ein großer Freund von Wireguard bin, machen wir es mit einem verschlüsselten Tunnel So bleibt man in Übung...
Installation Wireguard
Meine Server sind alle Debian Buster 10.
apt install linux-headers-$(uname -r) apt install wireguard
Danach die Kisten durchstarten.Siehe die Ergänzungen / Kommentare weiter unten!Kontrolle
lsmod | grep wireguard wireguard 225280 0 ip6_udp_tunnel 16384 1 wireguard udp_tunnel 16384 1 wireguard
Wireguard Konfiguration
Server 1 (Redis Master)
[Interface] #Address = 10.10.1.2 PrivateKey = <private Key> ListenPort = 58380 [Peer] PublicKey = <public Key> PresharedKey = <PSK Key> Endpoint = <IP vom Endpoint>:58380 AllowedIPs = 10.10.1.1/32
Server 2 (Redis Slave)
[Interface] #Address = 10.10.1.1 PrivateKey = <private Key> ListenPort = 58380 [Peer] PublicKey = <public Key> PresharedKey = <PSK Key> Endpoint = <IP vom Endpoint>:58380 AllowedIPs = 10.10.1.2/32
Wireguard starten
ip link add dev wg0 type wireguard ip link set up dev wg0 wg-quick up wg0
Testen
wg interface: wg0 public key: <public Key> private key: (hidden) listening port: 58380 peer: <peer Key> endpoint: <IP>:58380 allowed ips: 10.10.1.2/32 latest handshake: 1 minute, 39 seconds ago transfer: 66.83 MiB received, 839.15 KiB sent
Ok, das funktioniert so weit.
Redis Konfiguration
Master
bind 127.0.0.1 ::1 10.10.1.2
Slave
bind 127.0.0.1 ::1 10.10.1.1 replicaof 10.10.1.2 6379
Beide Redis Instanzen ausschalten
service redis stop
Danach erst den Master starten, danach den Slave.
service redis start
Kontrolle /var/log/redis/redis-server.log
3643:S 06 Jun 2020 08:44:05.673 * Discarding previously cached master state. 3643:S 06 Jun 2020 08:44:06.089 * MASTER <-> REPLICA sync: receiving 21888363 bytes from master 3643:S 06 Jun 2020 08:44:06.549 * MASTER <-> REPLICA sync: Flushing old data 3643:S 06 Jun 2020 08:44:06.780 * MASTER <-> REPLICA sync: Loading DB in memory 3643:S 06 Jun 2020 08:44:07.323 * MASTER <-> REPLICA sync: Finished with success 3643:S 06 Jun 2020 08:49:06.054 * 10 changes in 300 seconds. Saving... 3643:S 06 Jun 2020 08:49:06.058 * Background saving started by pid 3775 3775:C 06 Jun 2020 08:49:06.527 * DB saved on disk 3775:C 06 Jun 2020 08:49:06.530 * RDB: 10 MB of memory used by copy-on-write 3643:S 06 Jun 2020 08:49:06.559 * Background saving terminated with success 3643:S 06 Jun 2020 08:54:07.033 * 10 changes in 300 seconds. Saving... 3643:S 06 Jun 2020 08:54:07.036 * Background saving started by pid 3885 3885:C 06 Jun 2020 08:54:07.623 * DB saved on disk
So MUSS das aussehen. Wenn ihr so was seht
3312:S 06 Jun 2020 08:43:45.231 * Connecting to MASTER 10.10.1.2:6379 3312:S 06 Jun 2020 08:43:45.231 * MASTER <-> REPLICA sync started 3312:S 06 Jun 2020 08:43:45.232 # Error condition on socket for SYNC: Connection refused
dann habt ihr ein Kommunikationsproblem. Firewall usw.
iptables
Master
-
Wir erlauben Wireguard
#========================= # Wireguard (IN) from Datenbank Server #========================= $IP4TABLES -A INPUT -p udp --src <IPv4> --dport 58380 -j ACCEPT
-
Wir erlauben Redis-Replication
#========================= # Redis-Server Replication Port (IN) from Datenbank Server #========================= $IP4TABLES -A INPUT -p tcp --src 10.10.1.1 --dport 6379 -j ACCEPT
Slave
Wir erlauben Wireguard
#========================= # Wireguard (IN) from Webserver2 #========================= $IP4TABLES -A INPUT -p udp --src <IPv4> --dport 58380 -j ACCEPT
Nicht vergessen, die Regeln dauerhaft abzuspeichern. Ich mache das so -> https://forum.frank-mankel.org/topic/661/iptables-dauerhaft-speichern
Das ist eine sehr knapp gefasste Version, dessen was man machen muss. Für Einsteiger vermutlich ungeeignet, lest bitte in dem Fall die anderen Beiträge von mir zu den Themen.
Was hier jetzt noch nicht abgehandelt ist, der Wireguard Tunnel startet nicht wenn der Server neugestartet wird. Kommt noch ...
ToDo (für mich)Wireguard bei Server Neustart starten
In /etc/network/interfaces.d/ die Datei 70-wg0.cfg erzeugen.
# Wireguard auto wg0 iface wg0 inet static address 10.10.1.1 netmask 255.255.255.0 pre-up ip link add $IFACE type wireguard pre-up wg setconf $IFACE /etc/wireguard/$IFACE.conf post-down ip link del $IFACE
Beim nächsten Start steht der Wireguard Tunnel automatisch. Bitte drauf achten, wenn man das so macht, braucht man in der wg0.conf keine Zuordnung der IP-Adresse. Ich habe diese oben auskommentiert.
psk Key
Was ist das?
If an additional layer of symmetric-key crypto is required (for, say, post-quantum resistance), WireGuard also supports an optional pre-shared key that is mixed into the public key cryptography. When pre-shared key mode is not in use, the pre-shared key value used below is assumed to be an all-zero string of 32-bytes.
Für mich, als nicht Sicherheitsexperte, liesst sich das so: Dieser Key erhöht die Sicherheit. So mit ist es sicherlich sinnvoll diesen immer mit anzugeben.
Oben in der Konfiguration den PSK Key hinzugefüht. Der muss auf beiden Seiten gleich sein.
interface: wg0 public key: <public Key> private key: (hidden) listening port: 58380 peer: <perr Key> preshared key: (hidden) endpoint: <IPv4>:58380 allowed ips: 10.10.1.1/32 latest handshake: 35 seconds ago transfer: 205.20 KiB received, 22.28 MiB sent
-
-
@FrankM sagte in Redis Replication über Wireguard:
die Kisten durchstarten
moin,
vermutlich offtopic, entschuldigung: Du musst vermutlich bei einem install nicht "die Kisten durchstarten". Habe das schon öfter gelesen und sah oft keinen grund dafür. So nach aktuellem Kenntnisstand auch hier, wenn du das modul reinwerfen kannst/musst zu laufzeit (modprobe/insmod) und den service starten, warum sollte das nicht gehen..man kann aber auch falsch liegen, richtig
gruß -
@kosmonaut-pirx Ich denke, du liegst da richtig. DKMS baut ja das Kernelmodul und lädt es danach auch!? Damit sollte dieser Schritt überflüssig sein.
Da ich das Morgen auf einem weiteren Server einbaue, werde ich das mal beobachten
-
Guten Morgen. Oben noch meine ToDo-Liste abgearbeitet
Zum Kernelmodul. Das wird ja von DKMS gebaut.
Building initial module for 4.19.0-9-amd64 Done. wireguard.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/4.19.0-9-amd64/updates/dkms/ depmod.... DKMS: install completed. Setting up wireguard (1.0.20200513-1~bpo10+1) ... Processing triggers for man-db (2.8.5-2) ...
Danach ist das Kernelmodul installiert.
dkms status wireguard wireguard, 1.0.20200506, 4.19.0-9-amd64, x86_64: installed
Das Modul ist aber nicht geladen.
lsmod | grep wireguard
ist leer! Erst ein
modprobe wireguard
lädt das Kernelmodul.
lsmod | grep wireguard wireguard 225280 0 ip6_udp_tunnel 16384 1 wireguard udp_tunnel 16384 1 wireguard
@kosmonaut-pirx Ich denke, du hast Recht, auf den Server Neustart kann verzichtet werden. Man lernt nie aus
-
spart bischen zeit
-
-
Quartz64 - Wireguard
Verschoben Quartz64 -
-
ROCKPro64 - Projekt Wireguard Server
Verschoben ROCKPro64 -
-
-
-
Redis Replication
Angeheftet Verschoben Redis