WireGuard VPN Server mit Web Interface einrichten

Ursprünglich veröffentlicht unter: WireGuard VPN Server mit Web Interface einrichten - adminForge

Wer aktuell OpenVPN und IPsec als VPN Software einsetzt und sich schon immer mal mit WireGuard auseinander setzen wollte, dem helfe ich mit diesem Tutorial auf die Sprünge.

WireGuard ist eine freie Software zum Aufbau eines virtuellen privaten Netzwerkes (VPN) über eine verschlüsselte Verbindung.

WireGuard ist im Aufbau wesentlich einfacher gestaltet als beispielsweise OpenVPN und verwendet nur ein eingeschränktes Set an Algorithmen. So wird unter anderem für den Schlüsselaustausch das Verfahren Curve25519 und für die eigentliche Verschlüsselung ChaCha20 verwendet.

Vorteile von WireGuard zusammengefasst:

  • schneller, auch auf älteren und schwächeren Systemen
  • sicherer, dank neuster Verschlüsselungstechnologie
  • wirklich einfach einzurichten dank wireguard-ui

Was wird für dieses Tutorial benötigt?

Ziel in diesem Tutorial?

  • Ein VPN Netzwerk mit Server und Client innerhalb weniger Minuten einrichten
  • Ein Web Interface zur einfachen Einrichtung von Server und Clients
  • Mobile Clients einfach per QR Code einrichten

Punkt 1: Debian Pakete installieren

Quelle: https://www.wireguard.com/install/

Wir installieren alle nötigen Pakete und wechseln den Ordner.

apt update && apt install -y wireguard curl tar
cd /etc/wireguard

Punkt 2: Firewall Port öffnen

Der Port 51820 für das UDP Protokoll muss auf dem Server erreichbar sein. Beispielsweise so zu öffnen:

ufw allow 51820/udp

Punkt 3: IP Forwarding aktivieren

Das IP Forwarding sorgt dafür, dass alle Pakete der WireGuard-Schnittstelle weitergeleitet werden.

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
echo "net.ipv6.conf.all.forwarding=1" >> /etc/sysctl.conf
sysctl -p

Punkt 4: WireGuard UI Startscript erstellen

Dieses Startscript wird von der Systemd Service Unit (Punkt 5) verwendet um WureGuard UI zu staren und die Datenbank im Ordner /etc/wireguard/db/ abzulegen.

cat <<EOF > /etc/wireguard/start-wgui.sh
#!/bin/bash

cd /etc/wireguard
./wireguard-ui -bind-address 0.0.0.0:5000
EOF

ACHTUNG: Die -bind-address 0.0.0.0:5000 sollte aus Sicherheitsgründen, sobald der erste Tunnel steht, gegen die WireGuard Server IP-Adresse 10.252.1.0 ausgetauscht werden!

Wir machen das Script ausführbar.

chmod +x start-wgui.sh

Punkt 5: WireGuard UI

Quelle: https://github.com/ngoduykhanh/wireguard-ui

Zuerst legen wir die Systemd Service Unit an.

cat <<EOF > /etc/systemd/system/wgui-web.service
[Unit]
Description=WireGuard UI

[Service]
Type=simple
ExecStart=/etc/wireguard/start-wgui.sh

[Install]
WantedBy=multi-user.target
EOF

Nun legen wir das WireGuard UI Download und Update Script an.

cat <<EOF > /etc/wireguard/update.sh
#!/bin/bash

VER=$(curl -s Release wireguard-ui v0.3.5 · ngoduykhanh/wireguard-ui · GitHub | cut -d „/“ -f8 | cut -d „“" -f1)

echo „downloading wireguard-ui $VER“
curl -sL „https://github.com/ngoduykhanh/wireguard-ui/releases/download/$VER/wireguard-ui-$VER-linux-amd64.tar.gz“ -o wireguard-ui-$VER-linux-amd64.tar.gz

echo -n "extracting "; tar xvf wireguard-ui-$VER-linux-amd64.tar.gz

echo „restarting wgui-web.service“
systemctl restart wgui-web.service
EOF

Jetzt können wir das WireGuard UI Update Script das erste Mal ausführen. Der Download startet automatisch und das Web Interface von WireGuard wird gestartet.

chmod +x /etc/wireguard/update.sh
cd /etc/wireguard; ./update.sh

Punkt 6: WireGuard Konfigurationsdatei von Systemd überwachen lassen

Die folgenden beiden Systemd Units erstellen wir um die WireGuard Konfiguration wg0.conf zu überwachen und den Service automatisch bei Änderung neustarten zu lassen.
cat <<EOF > /etc/systemd/system/wgui.service
[Unit]
Description=Restart WireGuard
After=network.target

[Service]
Type=oneshot
ExecStart=/bin/systemctl restart wg-quick@wg0.service

[Install]
RequiredBy=wgui.path
EOF

cat <<EOF > /etc/systemd/system/wgui.path
[Unit]
Description=Watch /etc/wireguard/wg0.conf for changes

[Path]
PathModified=/etc/wireguard/wg0.conf

[Install]
WantedBy=multi-user.target
EOF

Punkt 7: Dienste aktivieren und starten

touch /etc/wireguard/wg0.conf
systemctl enable wgui.{path,service} wg-quick@wg0.service wgui-web.service
systemctl start wgui.{path,service}

Punkt 8: WireGuard UI öffnen und einstellen

  1. Das WireGuard UI öffnen wir nun im Webbrowser: http://<PUBLIC IP>:5000
  2. Melden uns als Benutzer admin und dem Passwort admin an
  3. Klicken links im Menü auf Global Settings
    ![|1024x596](upload://bAy0O004tAcjLK0iJKgbMht9Iz5.png)
  4. Wir prüfen zuerst ob die Endpoint Address stimmt (kann eine Public IP oder Hostname sein)
  5. Nun löschen wir 1.1.1.1 unter DNS Servers
  6. Fügen diese beiden dnsforge.de DNS Server hinzu: 176.9.93.198, 176.9.1.117
  7. Drücken Save
  8. Im Menü gehen wir nun auf Wireguard Server

  9. Damit die VPN Clients auch ins Internet können, tragen wir bei Post Up Script diese Zeile ein (anstelle eth0 trage dein öffentliches Interface vom Server ein):
    iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
  10. Bei Post Down Script (anstelle eth0 trage dein öffentliches Interface vom Server ein):
    iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
  11. Save anklicken
  12. Im Menü auf Wireguard Clients gehen
  13. Oben rechts auf New Client klicken
  14. Einen Namen eingeben
  15. Email kann auch leer bleiben
  16. IP Allocation ist die IP, die der Client erhält (WireGuard UI zählt die IP automatisch hoch für jeden neuen Client)
  17. Allowed IPs ist das Netzwerk, welches der Client über den VPN Tunnel erreichen darf. Default ist das komplette Internet und somit auch das Routing des gesamten Traffics durch den Tunnel. Ihr könnt dort auch eure internen Netzwerke eintragen und der normale Internet Traffic geht dann nicht mehr durch den VPN Tunnel.
  18. Mit Use server DNS werden die WireGuard Nameserver im Client verwendet
  19. Auf Submit drücken
  20. Um alles zu aktivieren drücken wir oben rechts auf Apply Config dann auf Apply

Der WireGuard Server ist fertig konfiguriert und eine erste Client-Konfiguration wurde erstellt.

Punkt 9: Android App installieren und einrichten

  1. Wir installieren uns aus dem Google Play Store die WireGuard App (gibt es auch für iOS):
    https://play.google.com/store/apps/details?id=com.wireguard.android
  2. Öffnen die App und klicken unten rechts auf das Plus Zeichen
  3. Nun drücken wir auf VON QR_CODE SCANNEN und lesen den QR Code des erstellten Clients ein
  4. Der Tunnel erhält nun einen Namen
  5. Wir klicken auf den Tunnel und aktivieren diesen am Schalter
  6. Der Tunnel ist erfolgreich aufgebaut wenn ihr unter Transfer ein paar gesendete Daten seht
  7. Im Webinterface unter dem Menüpunkt Status seht ihr die aktive Verbindung

Punkt 10: Windows Client einrichten

Der Windows Client lässt sich hier herunterladen: https://www.wireguard.com/install/ (auch für andere Betriebssysteme werdet ihr dort fündig).

  1. Im WireGuard Webinterface auf Download klicken
  2. Startet WireGuard
  3. Klickt auf Tunnel hinzufügen und wählt eure test.conf Datei aus
  4. Nun klicken wir auf Aktivieren
  5. Der Tunnel ist nun Aktiv und es werden Daten übermittelt
  6. Automatisch verbinden bei Windows Start erreichen wir mit diesem Befehl – Eingabeaufforderung als Administrator öffnen (einmalig ausführen reicht!):
    wireguard.exe /installtunnelservice "C:\Program Files\WireGuard\Data\Configurations\test.conf.dpapi"

Punkt 11: Absichern

Auf dem Server bearbeiten wir nun unser Startscript und setzen folgende bind-address.

#!/bin/bash

cd /etc/wireguard
./wireguard-ui -bind-address 10.252.1.0:5000

Das default Passwort admin ändern wir in dieser Datei ab.

{
        "username": "admin",
        "password": "<neues passwort>"
}

Nun starten wir den WireGuard UI Dienst neu.

systemctl restart wgui-web.service

Ab sofort ist euer Webinterface unter http://10.252.1.0:5000 mit eurem neuen Passwort erreichbar.

Euer adminForge Team

![Unterstützen|58x50](upload://vnhaBR8SynnGFzvNaOhL9M3TXyG.png "Unterstützen")Das Betreiben der Dienste, Webseite und Server machen wir gerne, kostet aber leider auch Geld.
Unterstütze unsere Arbeit mit einer Spende.

hey, thx fuer das tut :slight_smile:

leider geht bei mir nur die connection zum srv direkt, weder domains noch andere ip´s kann ich anpingen:

mit aktiver vpn verbindung:

"server addi" ping xx.xx.xx.xx

Ping wird ausgeführt für xx.xx.xx.xx mit 32 Bytes Daten:
Antwort von xx.xx.xx.xx: Bytes=32 Zeit=54ms TTL=64
Antwort von xx.xx.xx.xx: Bytes=32 Zeit=37ms TTL=64
Antwort von xx.xx.xx.xx: Bytes=32 Zeit=38ms TTL=64
Antwort von xx.xx.xx.xx: Bytes=32 Zeit=40ms TTL=64

Ping-Statistik für xx.xx.xx.xx:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 37ms, Maximum = 54ms, Mittelwert = 42ms

ping 10.252.1.0

Ping wird ausgeführt für 10.252.1.0 mit 32 Bytes Daten:
Antwort von 10.252.1.0: Bytes=32 Zeit=78ms TTL=64
Antwort von 10.252.1.0: Bytes=32 Zeit=41ms TTL=64
Antwort von 10.252.1.0: Bytes=32 Zeit=37ms TTL=64
Antwort von 10.252.1.0: Bytes=32 Zeit=39ms TTL=64

Ping-Statistik für 10.252.1.0:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 37ms, Maximum = 78ms, Mittelwert = 48ms

wireguard webinterface:

status:
Name	Email	Public Key	ReceiveBytes	TransmitBytes	Connected (Approximation)	LastHandshakeTime
0	hguard		G4aPZE4=	96364	501252	true	2021-12-12 22:22:16.348955517 +0100 CET

Post Up Script:
iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o enp8s0 -j MASQUERADE

Post Down Script:
iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o enp8s0 -j MASQUERADE

ssh: wg
interface: wg0
  public key: lsA0gyI=
  private key: (hidden)
  listening port: 51820

peer: 0rkZ32E4=
  preshared key: (hidden)
  endpoint: xx.xx.xx.xx:7126
  allowed ips: 10.252.1.1/32
  latest handshake: 20 seconds ago
  transfer: 135.14 KiB received, 45.37 KiB sent

ip a:
enp8s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet xx.xx.xx.xx/26 brd xx:xx:xx:xx scope global enp8s0

hab unter debian 11 statt ufw iptables in use:

sudo iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  any    any     host48-45-237-212.serverdedicati.aruba.it  anywhere
    0     0 DROP       all  --  any    any     fra07s28-in-f227.1e100.net  anywhere
   18  3168 ACCEPT     udp  --  any    any     anywhere             anywhere             udp dpt:51820

packete gehen auch durch, nur funzt der dns scheinbar nicht richtig, hab deine beiden dns forge bzw. 1.1.1.1 drinn… selbe fehlerbild!

event hast du ein denkanstoss fuer mich :scream: :upside_down_face:

greetz

mhh hast du denn net.ipv4.ip_forward=1 aktiviert auf dem Server?

Siehst du Traffic durch die FORWARD Chain laufen?

# iptables -vnL FORWARD
Chain FORWARD (policy ACCEPT 4216K packets, 5091M bytes)
 pkts bytes target     prot opt in     out     source               destination
2756K 1410M ACCEPT     all  --  wg0    *       0.0.0.0/0            0.0.0.0/0

Ansonsten versucht einmal deine iptables zu leeren und bei 0 zu beginnen rein für WG.

hey,

Chain FORWARD (policy DROP 5175 packets, 458K bytes)
 pkts bytes target     prot opt in     out     source               destination
 1089 67555 ACCEPT     all  --  wg0    *       0.0.0.0/0            0.0.0.0/0

yepp… hab gestern ein port scanner drueber laufen lassen und siehe da der port 51820 scheint nicht offen zu sein.

event steckt hier schon der fehler:

sudo iptables -A INPUT -p udp -m udp --dport 51820 -j ACCEPT

sudo iptables -A OUTPUT -p udp -m udp --dport 51820 -j ACCEPT

scheinbar mach ich hier was falsch.

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 7641 1215K ACCEPT     udp  --  any    any     anywhere             anywhere             udp dpt:51820

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    3   999 ACCEPT     udp  --  any    any     anywhere             anywhere             udp dpt:51820

ein paar packete gehen durch

greetz

deine INPUT Policy steht doch auf ACCEPT, dann müsstest du keine Regel hinzufügen.
OUTPUT ist irrelevant da die chain auch auf ACCEPT steht.

am besten leerst du einmal alles und beginnst von neu:

sudo iptables -P INPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
sudo iptables -P OUTPUT ACCEPT

sudo iptables -t nat -F
sudo iptables -t mangle -F
sudo iptables -F
sudo iptables -X

ok, also sollte der befehl schon passen:

sudo iptables -A INPUT -p udp -m udp --dport 51820 -j ACCEPT

hatte gestern nacht noch kurz den output befehl probiert

sudo iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  any    any     host48-45-237-212.serverdedicati.aruba.it  anywhere
    0     0 DROP       all  --  any    any     muc11s11-in-f3.1e100.net  anywhere
 7641 1215K ACCEPT     udp  --  any    any     anywhere             anywhere             udp dpt:51820

Chain FORWARD (policy DROP 5425 packets, 482K bytes)
 pkts bytes target     prot opt in     out     source               destination
8701K 7488M DOCKER-USER  all  --  any    any     anywhere             anywhere
8701K 7488M DOCKER-ISOLATION-STAGE-1  all  --  any    any     anywhere             anywhere
5214K 5045M ACCEPT     all  --  any    br-ab8dff2eebeb  anywhere             anywhere             ctstate RELATED,ESTABLISHED
13884  832K DOCKER     all  --  any    br-ab8dff2eebeb  anywhere             anywhere
3463K 2441M ACCEPT     all  --  br-ab8dff2eebeb !br-ab8dff2eebeb  anywhere             anywhere
13603  816K ACCEPT     all  --  br-ab8dff2eebeb br-ab8dff2eebeb  anywhere             anywhere
    0     0 ACCEPT     all  --  any    docker0  anywhere             anywhere             ctstate RELATED,ESTABLISHED
    0     0 DOCKER     all  --  any    docker0  anywhere             anywhere
    0     0 ACCEPT     all  --  docker0 !docker0  anywhere             anywhere
    0     0 ACCEPT     all  --  docker0 docker0  anywhere             anywhere
  225 13808 ACCEPT     all  --  wg0    any     anywhere             anywhere

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    3   999 ACCEPT     udp  --  any    any     anywhere             anywhere             udp dpt:51820

Chain DOCKER (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     tcp  --  !br-ab8dff2eebeb br-ab8dff2eebeb  anywhere             172.23.0.2           tcp dpt:https
    0     0 ACCEPT     tcp  --  !br-ab8dff2eebeb br-ab8dff2eebeb  anywhere             172.23.0.2           tcp dpt:http
   18  2372 ACCEPT     udp  --  !br-ab8dff2eebeb br-ab8dff2eebeb  anywhere             172.23.0.4           udp dpt:10000
   11   512 ACCEPT     tcp  --  !br-ab8dff2eebeb br-ab8dff2eebeb  anywhere             172.23.0.4           tcp dpt:4443
  252 13352 ACCEPT     tcp  --  !br-ab8dff2eebeb br-ab8dff2eebeb  anywhere             172.23.0.9           tcp dpt:3000

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
 pkts bytes target     prot opt in     out     source               destination
3463K 2441M DOCKER-ISOLATION-STAGE-2  all  --  br-ab8dff2eebeb !br-ab8dff2eebeb  anywhere             anywhere
    0     0 DOCKER-ISOLATION-STAGE-2  all  --  docker0 !docker0  anywhere             anywhere
 196M  124G RETURN     all  --  any    any     anywhere             anywhere

Chain DOCKER-ISOLATION-STAGE-2 (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  any    br-ab8dff2eebeb  anywhere             anywhere
    0     0 DROP       all  --  any    docker0  anywhere             anywhere
  93M   47G RETURN     all  --  any    any     anywhere             anywhere

Chain DOCKER-USER (1 references)
 pkts bytes target     prot opt in     out     source               destination
 196M  124G RETURN     all  --  any    any     anywhere             anywhere

sollte der befehl -D nicht schon ausreichen:

sudo iptables -D INPUT -p udp -m udp --dport 51820 -j ACCEPT

sudo iptables -D OUTPUT -p udp -m udp --dport 51820 -j ACCEPT


sudo iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  any    any     host48-45-237-212.serverdedicati.aruba.it  anywhere
    0     0 DROP       all  --  any    any     muc11s11-in-f3.1e100.net  anywhere

Chain FORWARD (policy DROP 5425 packets, 482K bytes)
 pkts bytes target     prot opt in     out     source               destination
8790K 7612M DOCKER-USER  all  --  any    any     anywhere             anywhere
8790K 7612M DOCKER-ISOLATION-STAGE-1  all  --  any    any     anywhere             anywhere
5273K 5103M ACCEPT     all  --  any    br-ab8dff2eebeb  anywhere             anywhere             ctstate RELATED,ESTABLISHED
14277  856K DOCKER     all  --  any    br-ab8dff2eebeb  anywhere             anywhere
3493K 2508M ACCEPT     all  --  br-ab8dff2eebeb !br-ab8dff2eebeb  anywhere             anywhere
13984  839K ACCEPT     all  --  br-ab8dff2eebeb br-ab8dff2eebeb  anywhere             anywhere
    0     0 ACCEPT     all  --  any    docker0  anywhere             anywhere             ctstate RELATED,ESTABLISHED
    0     0 DOCKER     all  --  any    docker0  anywhere             anywhere
    0     0 ACCEPT     all  --  docker0 !docker0  anywhere             anywhere
    0     0 ACCEPT     all  --  docker0 docker0  anywhere             anywhere
  225 13808 ACCEPT     all  --  wg0    any     anywhere             anywhere

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain DOCKER (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     tcp  --  !br-ab8dff2eebeb br-ab8dff2eebeb  anywhere             172.23.0.2           tcp dpt:https
    0     0 ACCEPT     tcp  --  !br-ab8dff2eebeb br-ab8dff2eebeb  anywhere             172.23.0.2           tcp dpt:http
   18  2372 ACCEPT     udp  --  !br-ab8dff2eebeb br-ab8dff2eebeb  anywhere             172.23.0.4           udp dpt:10000
   11   512 ACCEPT     tcp  --  !br-ab8dff2eebeb br-ab8dff2eebeb  anywhere             172.23.0.4           tcp dpt:4443
  264 13976 ACCEPT     tcp  --  !br-ab8dff2eebeb br-ab8dff2eebeb  anywhere             172.23.0.9           tcp dpt:3000

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
 pkts bytes target     prot opt in     out     source               destination
3493K 2508M DOCKER-ISOLATION-STAGE-2  all  --  br-ab8dff2eebeb !br-ab8dff2eebeb  anywhere             anywhere
    0     0 DOCKER-ISOLATION-STAGE-2  all  --  docker0 !docker0  anywhere             anywhere
 197M  124G RETURN     all  --  any    any     anywhere             anywhere

Chain DOCKER-ISOLATION-STAGE-2 (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  any    br-ab8dff2eebeb  anywhere             anywhere
    0     0 DROP       all  --  any    docker0  anywhere             anywhere
  93M   47G RETURN     all  --  any    any     anywhere             anywhere

Chain DOCKER-USER (1 references)
 pkts bytes target     prot opt in     out     source               destination
 197M  124G RETURN     all  --  any    any     anywhere             anywhere

jetzt sind beide regeln wieder raus, quasi nur die docker regeln vorhanden

und das fehlerbild ist unveraendert, kann nur die beiden ip bereiche anpingen, als ob er glatt die regel ignoriert!

meld mich nachm essen nochmal :slight_smile:

greetz

dein FORWARD für wg0 scheint ja Traffic zu bekommen, wie schauts mit POSTROUTING bei dir aus? Ist enp8s0 auch wirklich dein Interface zum Internet?

iptables -vnL -t nat
Chain POSTROUTING (policy ACCEPT 756K packets, 186M bytes)
 pkts bytes target     prot opt in     out     source               destination
 103K 6538K MASQUERADE  all  --  *      eth0   0.0.0.0/0            0.0.0.0/0

welche routing tabelle hast du?
ip r ls

laut ip a bzw. r ls schon:

enp8s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether xx:xx:xx:9c:15:56 brd ff:ff:ff:ff:ff:ff
    inet meinesrvip/26 brd 65.108.13.255 scope global enp8s0
       valid_lft forever preferred_lft forever
    inet6 meinesrvip::2/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::7e10:c9ff:fe9c:1556/64 scope link
       valid_lft forever preferred_lft forever
ip r ls
default via 65.108.13.193 dev enp8s0 onlink
10.252.1.0/24 dev wg0 proto kernel scope link src 10.252.1.0
65.108.13.192/26 via 65.108.13.193 dev enp8s0
65.108.13.192/26 dev enp8s0 proto kernel scope link src meine srv ip
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.23.0.0/16 dev br-ab8dff2eebeb proto kernel scope link src 172.23.0.1
iptables -vnL -t nat
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 1537 96268 MASQUERADE  all  --  *      !br-ab8dff2eebeb  172.23.0.0/16        0.0.0.0/0
   16  2096 MASQUERADE  all  --  *      !docker0  172.17.0.0/16        0.0.0.0/0
    0     0 MASQUERADE  tcp  --  *      *       172.23.0.2           172.23.0.2           tcp dpt:443
    0     0 MASQUERADE  tcp  --  *      *       172.23.0.2           172.23.0.2           tcp dpt:80
    0     0 MASQUERADE  udp  --  *      *       172.23.0.4           172.23.0.4           udp dpt:10000
    0     0 MASQUERADE  tcp  --  *      *       172.23.0.4           172.23.0.4           tcp dpt:4443
    0     0 MASQUERADE  tcp  --  *      *       172.23.0.9           172.23.0.9           tcp dpt:3000
 1936  215K MASQUERADE  all  --  *      enp8s0  0.0.0.0/0            0.0.0.0/0

eventuell stimmt der befehl nicht:

sudo iptables -A INPUT -p udp -m udp --dport 51820 -j ACCEPT

will atm kein ufw haben, kam mit iptables bis gestern gut zurecht :upside_down_face: :scream:

man koennte es ja parallel betreiben, nftables greift doch ehh noch nicht?!

aber muss doch moeglich sein den port mit ein korrekten befehl freizubekommen

bannen, forwarding, redirect ging die ganzen jahre :thinking:

man siehts ja auch am port scanner der port bleibt strikt geschlossen…

sudo iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  any    any     host48-45-237-212.serverdedicati.aruba.it  anywhere
    0     0 DROP       all  --  any    any     muc12s03-in-f3.1e100.net  anywhere
    0     0 ACCEPT     udp  --  any    any     anywhere             anywhere             udp dpt:51820

und Wireguard meckert nix an:

2021-12-13 16:31:23.160: [TUN] [hguard5] Starting WireGuard/0.5.2 (Windows 10.0.19043; amd64)
2021-12-13 16:31:23.160: [TUN] [hguard5] Watching network interfaces
2021-12-13 16:31:23.161: [TUN] [hguard5] Resolving DNS names
2021-12-13 16:31:23.161: [TUN] [hguard5] Creating network adapter
2021-12-13 16:31:23.279: [TUN] [hguard5] Using existing driver 0.10
2021-12-13 16:31:23.284: [TUN] [hguard5] Creating adapter
2021-12-13 16:31:23.430: [TUN] [hguard5] Using WireGuardNT/0.10
2021-12-13 16:31:23.430: [TUN] [hguard5] Enabling firewall rules
2021-12-13 16:31:23.411: [TUN] [hguard5] Interface created
2021-12-13 16:31:23.434: [TUN] [hguard5] Dropping privileges
2021-12-13 16:31:23.434: [TUN] [hguard5] Setting interface configuration
2021-12-13 16:31:23.434: [TUN] [hguard5] Peer 1 created
2021-12-13 16:31:23.436: [TUN] [hguard5] Sending keepalive packet to peer 1 (xx.xx.xx.xx:51820)
2021-12-13 16:31:23.436: [TUN] [hguard5] Sending handshake initiation to peer 1 (xx.xx.xx.xx:51820)
2021-12-13 16:31:23.436: [TUN] [hguard5] Interface up
2021-12-13 16:31:23.436: [TUN] [hguard5] Monitoring MTU of default v4 routes
2021-12-13 16:31:23.438: [TUN] [hguard5] Setting device v4 addresses
2021-12-13 16:31:23.441: [TUN] [hguard5] Monitoring MTU of default v6 routes
2021-12-13 16:31:23.441: [TUN] [hguard5] Setting device v6 addresses
2021-12-13 16:31:23.447: [TUN] [hguard5] Startup complete
2021-12-13 16:31:23.476: [TUN] [hguard5] Receiving handshake response from peer 1 (xx.xx.xx.xx:51820)
2021-12-13 16:31:23.476: [TUN] [hguard5] Keypair 1 created for peer 1
2021-12-13 16:32:24.640: [TUN] [hguard5] Shutting down
2021-12-13 16:32:24.640: [MGR] [hguard5] Tunnel service tracker finished

2,12 KiB empfangen, 34,94 KiB gesendet

greetz

Du kannst auf udp keine Portscans machen wie tcp.
Da du verbunden bist, wird der Port offen sein.

Du müsstest jetzt mal mit tcpdump -i wg0 das interface überwachen und dann zeitgleich auf dem wg client versuchen etwas im internet aufzurufen.

Wenn du was auf wg0 siehst schaue dir auch dein public interface mit tcpdump an.

Irgendwo muss er ja deine versuche aufzeichnen. Jetzt gehts also an die suche :anguished:

oke, ich hatte doch vorhin beide regeln entfernt und das selbe fehlerbild gehabt, als ob er die regel strikt ignoriert, ich konnte mich verbinden nur keine seiten aufrufen, nur auf beide ip bereiche einen ping absetzen. ob ich die regel setze oder nicht… selbe fehlerbild :scream:

sobald ich am handy den vpn starte, faengt er auch an zu loggen

sudo tcpdump -i wg0
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
18:34:34.193468 IP 10.252.1.1.63959 > dnsforge.de.domain: 12617+ A? www.apple.com. (31)
18:34:34.193468 IP 10.252.1.1.64175 > dnsforge.de.domain: 14293+ A? www.icloud.com. (32)
18:34:34.208559 IP 10.252.1.1.61986 > dnsforge.de.domain: 55069+ A? fonts.gstatic.com. (35)
18:34:34.209820 IP 10.252.1.1.56220 > dnsforge.de.domain: 52380+ A? fonts.googleapis.com. (38)
18:34:34.234302 IP 10.252.1.1.56941 > dnsforge.de.domain: 41666+ A? p105-keyvalueservice.icloud.com. (49)
18:34:35.216583 IP 10.252.1.1.63959 > dnsforge.de.domain: 12617+ A? www.apple.com. (31)
18:34:35.216583 IP 10.252.1.1.64175 > dnsforge.de.domain: 14293+ A? www.icloud.com. (32)
18:34:35.223584 IP 10.252.1.1.56941 > dnsforge.de.domain: 41666+ A? p105-keyvalueservice.icloud.com. (49)
18:34:37.204575 IP 10.252.1.1.63959 > dnsforge.de.domain: 12617+ A? www.apple.com. (31)
18:34:37.204601 IP 10.252.1.1.64175 > dnsforge.de.domain: 14293+ A? www.icloud.com. (32)
18:34:37.228790 IP 10.252.1.1.56941 > dnsforge.de.domain: 41666+ A? p105-keyvalueservice.icloud.com. (49)
18:34:38.209365 IP 10.252.1.1.63959 > dnsforge.de.domain: 12617+ A? www.apple.com. (31)
18:34:38.209365 IP 10.252.1.1.64175 > dnsforge.de.domain: 14293+ A? www.icloud.com. (32)
18:34:38.235022 IP 10.252.1.1.56941 > dnsforge.de.domain: 41666+ A? p105-keyvalueservice.icloud.com. (49)
18:34:40.227323 IP 10.252.1.1.63959 > one.one.one.one.domain: 12617+ A? www.apple.com. (31)
18:34:40.227348 IP 10.252.1.1.64175 > one.one.one.one.domain: 14293+ A? www.icloud.com. (32)
18:34:40.234331 IP 10.252.1.1.56941 > one.one.one.one.domain: 41666+ A? p105-keyvalueservice.icloud.com. (49)
18:34:41.218719 IP 10.252.1.1.63959 > one.one.one.one.domain: 12617+ A? www.apple.com. (31)
18:34:41.218748 IP 10.252.1.1.64175 > one.one.one.one.domain: 14293+ A? www.icloud.com. (32)
18:34:41.242460 IP 10.252.1.1.56941 > one.one.one.one.domain: 41666+ A? p105-keyvalueservice.icloud.com. (49)
^C
20 packets captured
20 packets received by filter
0 packets dropped by kernel
sudo tcpdump -i enp8s0
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp8s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
18:37:50.468050 IP srvnamen.56139 > ns2.recursivedns.hetzner.com.domain: 25359+ PTR? 4.c.0.0.a.2.ip6.arpa. (90)
18:37:50.492983 IP meine client ip.51944 > srvnamen.51820: UDP, length 112
18:37:50.493041 IP srvnamen.62901 > dnsforge.de.domain: 36780+ A? raveonsnow.streamback.de. (42)
18:37:50.502426 IP p508a454.62101 > srvnamen.port: Flags [.], ack 55944, win 1025, length 0
18:37:50.507840 IP p508a454.62101 > srvnamen.port: Flags [.], ack 56544, win 1022, length 0
18:37:50.518115 IP dnsforge.de.domain > srvnamen.62901: 36780 2/0/0 CNAME streamback.de., A 81.169.213.108 (72)
^C^C18:37:50.549685 IP 220-128-237-1.hinet-ip.hinet.net.53601 > srvnamen.6995: UDP, length 65

485 packets captured
1509 packets received by filter
931 packets dropped by kernel

und scheinbar tut sich auch was am port 51820

tcpdump -i enp8s0 18:37:50.492983 IP meine client ip.51944 > srvnamen.51820: UDP, length 112

wird langsam frickelig @huuu :thinking:

ich habe mir jetzt nochmal eine frische Debian 11 Cloud VM bei Hetzner besorgt und die Anleitung getestet. Wenn ich alles Copy & Paste mache und am ende Apply Config drücke, bin ich mit dem Android Handy im Netz und kann alles ansurfen.

Fazit: Anleitung ist korrekt, irgendwelche iptables Regeln werden bei dir querschießen.

Vielleicht beginnst du bei 0 iptables Regeln um dahinter zukommen was los ist.

oke, ich hab auch noch ein test srv on, will da mal mit ufw mich ausprobieren… bei gleicher konstellation, eventuell komm ich dann weiter :smirk:

dennoch thx fuer deine muehen

atm kp… wo da genau der schuhe drueckt

kurzes update:

hab eben mal die auslastung durch zufall gescheckt:

3877860 www-data 20 0 354068 141240 108132 S 42.9 0.2 4:02.13 php-fpm8.0
3877013 www-data 20 0 426764 155160 121076 S 33.6 0.2 3:11.51 php-fpm8.0
3879807 www-data 20 0 425944 142224 108648 R 33.2 0.2 3:12.03 php-fpm8.0
3875832 www-data 20 0 347964 135084 108084 R 31.6 0.2 3:12.44 php-fpm8.0

cpu auslastung liegt ca. bei 40 prozent pro kern :slight_smile: :upside_down_face: :thinking:

und unter ifconfig geschaut:

enp8s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet srvip netmask 255.255.255.192 broadcast xx.xx.xx
inet6 xx.xx.xx.::2 prefixlen 64 scopeid 0x0
inet6 xx.xx.xx:1556 prefixlen 64 scopeid 0x20
ether xx.xx.xx.xx.xx txqueuelen 1000 (Ethernet)
RX packets 723193707 bytes 930810117233 (866.8 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 276807183 bytes 115456782349 (107.5 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device memory 0xfc200000-fc27ffff

in den grob 2 tagen wo ich wireguard teste, kam fast 1 TB an traffic zusammen nc :slight_smile:

hab wireguard jetzt per purge ohne remove vom system geschmissen, hatte leider nicht mehr per iftop geschaut wie die auslastung war, komischerweise seh ich noch das webinterface und kann es noch connecten?!

ich schau mir das jetzt die tage auf einer testumgebung an und lass es vom produktiven sys weg

greetz

ein reboot und die 3 regeln hatten schon geholfen :slight_smile:

sudo iptables -P INPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
sudo iptables -P OUTPUT ACCEPT

hatte noch mein alten produktiven debian 10 srv on, den hab ich per full-upgrade auf debian 11 gezogen, nach ein reboot und die regeln von dir + dein tut und schwupp funzt es auf beiden server

thx a lot :upside_down_face: :smirk: :ok_hand:

1 Like