Beiträge von Claas

Meine Wireguard-Tunnel sind jetzt wieder online!

Hallo Heiko,

bei mir hat es auch der Cronjob alle 5 Minuten verraten.

ich komme noch per ssh auf meinen Server, habe auch die Pakete gesnifft mit "tcpdump -i ens3 -u port 51820", aber es gehen nur UDP-Pakete rein, aber nicht mehr raus. Im Wireguard-logging steht auch nichts hilfreiches. Das Problem scheint ein kaputtes UDP-Routing zu sein.

Mein Wireguard-Monitor braucht auch UDP:

$ cat wireguard-monitor
#!/usr/bin/bash
# https://unix.stackexchange.com/questions/22615/how-can-i-get-my-external-ip-address-in-a-shell-script
# https://unix.stackexchange.com/a/81699/37512
#alias wanip='dig @resolver4.opendns.com myip.opendns.com +short'
#alias wanip4='dig @resolver4.opendns.com myip.opendns.com +short -4'
#alias wanip6='dig @resolver1.ipv6-sandbox.opendns.com AAAA myip.opendns.com +short -6'

myip=$( dig @resolver4.opendns.com myip.opendns.com +short )


if [ "$myip" != "185.162.xxx.xxx" ]; then

echo "Unsere externe IP-Adresse ist nicht mehr korrekt!!!"
echo "detected: $myip"
echo

# restart wireguard 
service wg-quick@wg0 restart

# ping our wireguard upstream server 20 times...
ping -c 20 10.0.0.1

fi

Ah, dankeschön.

Im SCP steht, dass auf meinem Server kein qemu-guest-agent installiert sein sollte. Ist aber installiert.

$ qemu-ga -D
[general]
daemon=false
method=virtio-serial
path=/dev/virtio-ports/org.qemu.guest_agent.0
pidfile=/var/run/qemu-ga.pid
statedir=/var/run
verbose=false
retry-path=false
block-rpcs=
allow-rpcs=

Das sieht doch gut aus...

Hallo Leute,

seit heute um ca. 11:00 Uhr sind alle Wireguard-Tunnel zu meinem Server abgebrochen und lassen sich auch nicht wieder herstellen. Irgendwie klappt es nicht mehr mit dem Handshake. Die Konfigurationsdateien wurden nicht verändert.

Hat noch jemand diese Probleme festgestellt?

Viele Grüße
Claas

man wg-quick

[...]
A combination of the `Table', `PostUp', and `PreDown' fields may be used for policy routing as well. For example, the following may be used to send SSH traffic (TCP port 22) traffic through the tunnel:

[Interface] Address = 10.192.122.1/24
PrivateKey = yAnz5TF+lXXJte14tji3zlMNq+hd2rYUIgJBgB3fBmk= 
ListenPort = 51820
Table = 1234
PostUp = ip rule add ipproto tcp dport 22 table 1234
PreDown = ip rule delete ipproto tcp dport 22 table 1234
[Peer]
PublicKey = xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=
AllowedIPs = 0.0.0.0/0
[...]

Hallo Leute,

ich hatte das gleiche Problem, habe den Support angeschrieben, der hat mir empfohlen im Rescue-Boot zu testen und mich danach ggf. wieder zu melden. Ich habe mich dann dazu entschieden, erstmal den Netzwerktreiber von virtio auf e1000 umzustellen. Nach einem Ausschalten und wieder einschalten der Maschine (ich fahre Debian 18.04 LTS) hat alles wieder funktioniert und sah gut aus. Meine Testpings von überall gingen, nur über das Lookinglass von HE (http://lg.he.net) ging es nicht von Frankfurt aus. Ich vermute, dass Frankfurt bei denen defekt ist.

Komischerweise konnte ich von einem Teststandort (Kabel Deutschland Internet, IPv6 Dualstack lite) immer noch nicht auf eine IPv6 meines Servers pingen. Kabelrouter hab ich neugestartet, Laptop auf Kernel 5.6.3 geupdated, usw. Kein Erfolg. Im Webinterface des Routers konnte ich dann aber tatsächlich die erst nicht anpingbare Adresse anpingen, aber am Laptop immer noch nicht. Dann habe ich die IPv6 Privacy-Extensions in /etc/sysctl.d/10-ipv6-privacy.conf ausgeschaltet und das Netzwerk neu gestartet. Jetzt geht es. Keine Ahnung, wo da genau der Bug ist. Auf jeden Fall habe ich nun von 5 verschiedenen Looking-Glasses aus getestet und es klappt nun wieder von überall.

Viele Grüße!