WireGuard -> wg0 existiert bereits

[uan]

Code: Alles auswählen

/usr/bin/wg-quick: line 295: iptables: command not found

Code: Alles auswählen

apt policy iptables
which iptables

?

EDIT:

BTW: Wenn Du systemd-networkd benutzt und dort etwas konfigurierst, das iptables benutzen soll und iptables nicht installiert ist, wird iptables-legacy benutzt. Eigentlich sollte nftables benutzt werden, statt iptables-legacy, aber damit tun sich die devs von systemd anscheinend noch schwer.

Nachdem ich iptables nachinstalliert hatte, hab ich dann noch in der wg0.conf angepasst, dass das bei mir gar nicht eth0 heisst, sondern enp1s0 und schon ist die route da, route zeigt jetzt

Code: Alles auswählen

route

Code: Alles auswählen

Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    100    0        0 enp1s0
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 wg0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 wg0
192.168.178.0   0.0.0.0         255.255.255.0   U     100    0        0 enp1s0

jetzt kann ich auch den Tunnel auf jeder Seite selbst anpingen, die gegenüberliegende Seite des Tunnels erreiche ich jedoch nicht.

Code: Alles auswählen

apt policy iptables

Code: Alles auswählen

iptables:
  Installiert:           1.8.9-2
  Installationskandidat: 1.8.9-2
  Versionstabelle:
 *** 1.8.9-2 500
        500 http://deb.debian.org/debian bookworm/main amd64 Packages
        100 /var/lib/dpkg/status

Code: Alles auswählen

which iptables

Code: Alles auswählen

/usr/sbin/iptables

Allerding komme ich noch nicht auf die jeweils andere Seite durch den Tunnel.

[mat6937]

Nachdem ich iptables jetzt auf beiden Seiten nachinstalliert hab, sieht das alles schon anders aus.

OK, wenn es jetzt passt, siehe die Ausgaben von:

Code: Alles auswählen

ip a
wg show

dann kannst Du auch die service unit aktivieren, ... wenn das nocht nicht der Fall ist:

Code: Alles auswählen

systemctl status wg-quick@wg0.service
systemctl enable wg-quick@wg0.service
reboot

EDIT:

Wie ist die Ausgabe von:

Code: Alles auswählen

iptables -nvx -L -t nat

?
Was hast Du bei den AllowedIPs konfiguriert (... wegen dem WG-Tunnel)?

[uan]

Code: Alles auswählen

ip a

Code: Alles auswählen

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 90:1b:0e:87:22:5a brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.91/24 brd 192.168.178.255 scope global dynamic noprefixroute enp1s0
       valid_lft 849522sec preferred_lft 849522sec
    inet6 fe80::921b:eff:fe87:225a/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
6: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 10.0.0.3/24 scope global wg0
       valid_lft forever preferred_lft forever

Code: Alles auswählen

wg show

Code: Alles auswählen

interface: wg0
  public key: public key
  private key: (hidden)
  listening port: 34472     <--- den versteh ich nicht, müsste da nicht 51820 stehen?

peer: anderer key
  endpoint: hierstehtneipdieichnichtkenne:51820
  allowed ips: 10.0.0.0/24, 192.168.0.0/24
  transfer: 0 B received, 117.94 KiB sent
  persistent keepalive: every 25 seconds

Code: Alles auswählen

iptables -nvx -L -t nat

Code: Alles auswählen

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

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

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

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination
      12     1028 MASQUERADE  0    --  *      enp1s0  0.0.0.0/0            0.0.0.0/0

[uan]

Es funktioniert!

Dank eurer Hilfe steht der Tunnel, ich habe mich gerade auf der Fritzbox im Laden anmelden können.

Danke, Danke, Danke!

[debilian]

die Youtube Anleitungen guck ich vielleicht, wenn ich ein Notebook öffnen muß,
aber wenn es irgendwie geht, such ich mir eine gute Webseite mit Text und am End Bildern.

die ist ganz gut: https://www.howtoforge.de/anleitung/wir ... tallieren/

gruss

[uan]

Danke für den Tip, werde ich beherzigen.

Bei dem YT Video sah das alles so easy-peasy aus, klicken hier, schreiben da, ab und an mal Enter drücken und du bist im Olymp...
Pfiffkaas.

Dank eurer freunlichen Hilfe hat das gestern abend also wunderbar geklappt, jetzt weiss ich schonmal, was damit machbar ist und das das genau das ist, was ich brauche.

Nur: heute morgen war der Tunnel schon wieder tot.

Diesseits alles erreichbar, der Tunnelausgang im Laden nicht. Gut, ich war noch nicht im Laden, die FB läuft, sonst hätte ich keinen Zugriff auf die Kameras. Kann das sein, dass der Tunnel sich abgebaut hat, weil zb Unterbrechung Provider etc, oder wer mir auch wochenlang dazwischengefunkt hat, war das debian Powermanagement. Ich hatte gemeint, das mit

Code: Alles auswählen

systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

abgeklemmt zu haben, aber diese Meldung

Code: Alles auswählen

Broadcast message from Debian-gdm@WireGuardS2S on tty1 (Fri 2024-05-31 09:47:00 CEST):

The system will suspend now!

kam dann doch, aber nur die Meldung, das System hat nicht gepennt, mit Enter war der Prompt wieder da.

https://wiki.debian.org/Suspend
Hier geguckt und dann noch diesen Block

Code: Alles auswählen

[Sleep]
AllowSuspend=no
AllowHibernation=no
AllowSuspendThenHibernate=no
AllowHybridSleep=no

in die Datei

Code: Alles auswählen

/etc/systemd/sleep.conf.d/nosuspend.conf

geschrieben, hoffentlich ist dann jetzt Ruhe, ich möchte gerne, dass der Tunnel 24/7 steht.

Ich hatte gedacht, dass dies mit dem Befehl in der wg0.conf

Code: Alles auswählen

PersistentKeepalive = 25

erledigt sei... aber das wars wohl doch nicht, das ist ja die unterste Ebene, da wird von weiter oben das eine oder andere noch dazwischenfunken, oder?

[mat6937]

..., weil zb Unterbrechung Provider etc, ...

Ja, wenn Du keine feste/statische IP-Adresse für den Endpoint (WG-Server) hast, kann so etwas schon passieren.
Von WG gibt es das reresolv-Script, das Du mit einem cronjob oder mit einer timer-unit (oder gleichwertig) benutzen kannst
Z. B. siehe: https://github.com/WireGuard/wireguard- ... lve-dns.sh

[uan]

..., weil zb Unterbrechung Provider etc, ...

Ja, wenn Du keine feste/statische IP-Adresse für den Endpoint (WG-Server) hast, kann so etwas schon passieren.
Von WG gibt es das reresolv-Script, das Du mit einem cronjob oder mit einer timer-unit (oder gleichwertig) benutzen kannst
Z. B. siehe: https://github.com/WireGuard/wireguard- ... lve-dns.sh

Und das muss dann auch nur auf dem WG-Server installiert werden? Oder auch auf der anderen Seite des Tunnels? Ist das völlig unnötig, oder schadet das sogar auf der anderen Seite?

[mat6937]

Und das muss dann auch nur auf dem WG-Server installiert werden?

Nein, nicht auf dem Server sondern auf dem WG-Client. Denn es ist der WG-Client, der die Verbindung zum Endpoint (WG-Server) herstellt und dazu nicht mehr in der Lage ist, wenn sich die öffentliche IP-Adresse vom Endpoint geändert hat.
Das kannst Du auch manuell machen mit z. B.:

Code: Alles auswählen

wg-quick down wg0
wg-quick up wg0

wenn Du in der config vom WG-Client die richtige/brauchbare dyndns-Adresse eingetragen hast und die Namensauflösung (DNS) beim up des wg0-Interfaces auch richtig funktioniert.

[uan]

Ahhh okay, ja ich verstehe.
Ist ja auch vollkommen schlüssig.

Das heisst, ich müsste das am Client wg0 runterfahren, neu starten, und dann läuft die Chose.
Um das dann alle 30 sekunden durchzuführen, müsste die Connection einmal neu hergestellt werden, und dann zeitgesteuert auf dem Client regelmäßig erneuert werden, dann rummst alles wieder?

Das wäre so toll, wie schön.

Ich danke Dir herzlich.

[mat6937]

..., dann rummst alles wieder?

Downloade das Script in das Verzeichnis /etc/wireguard und poste danach die Ausgabe von:

Code: Alles auswählen

ls -la /etc/wireguard

[uan]

Code: Alles auswählen

ls -la /etc/wireguard

Code: Alles auswählen

insgesamt 32
drwx------   2 root root  4096 31. Mai 17:22 .
drwxr-xr-x 125 root root 12288 31. Mai 10:18 ..
-rw-------   1 root root    45 30. Mai 18:07 privatekey
-rw-------   1 root root    45 30. Mai 18:07 publickey
-rw-r--r--   1 root root  1351 31. Mai 17:22 resolve-dns.sh
-rw-------   1 root root   497 31. Mai 17:16 wg0.conf

[mat6937]

Code: Alles auswählen

-rw-r--r--   1 root root  1351 31. Mai 17:22 resolve-dns.sh

Jetzt das Script ausführbar machen:

Code: Alles auswählen

chmod 750 /etc/wireguard/resolve-dns.sh

danach testen:

Code: Alles auswählen

bash -x /etc/wireguard/resolve-dns.sh wg0

und wenn OK, in die systemweite /etc/crontab, als letzte Zeilen eintragen:

Code: Alles auswählen

*/5 *	* * *	root	/etc/wireguard/resolve-dns.sh wg0 > /dev/null 2>&1
# - - - 

[uan]

Supi, Danke, werd ich machen.
Ich bin jetzt nochmal inn Laden, den Server neu starten, den Client daheim hab ich runtergefahren.

Wenn ich dann wieder zuhause bin, werde ich das machen und berichten.

Thanks a lot

[mat6937]

Ich bin jetzt nochmal inn Laden, den Server neu starten, ...

Konfiguriere deinen Server so, das Du zwei unabhängige Zugangsmöglichkeiten hast. D. h., nicht nur via WG-Tunnel, sondern auch per ssh mit pub-key-authentication. Wenn der WG-Tunnel mal nicht funktioniert, kannst Du per ssh zum Server und nachschauen.

[uan]

okay, das wäre der nächste Schritt,
erstmal kriege ich den Tunnel nicht ans laufen.

Server neu gestartet

Dann am Client alles gemacht, was gestern den Zugriff ermöglichte...

jetzt kann ich den Tunnel wieder nicht am Server anpingen. Es ist zum Kotzen...



Edit
nix zu machen, der baut den Tunnel nicht mehr auf

[mat6937]

jetzt kann ich den Tunnel wieder nicht am Server anpingen. Es ist zum Kotzen...

Wie ist auf dem Client die Ausgabe von:

Code: Alles auswählen

wg show

? Benutzt der Client die richtige IP-Adresse für den Endpoint?

[uan]

Ich hab ja die wg0.conf mit nem dyndns Eintrag im Endpoint.
Mit duckdns verglichen, war das mittlerweile ne ganz andere Adresse.

Daraufhin hab ich die dyndns nochmal eingetragen - leider auch ohne durchschlagenden Erfolg

Ich schreib ein paar Anmerkungen rein

wg show

interface: wg0
public key: korrekter key
private key: (hidden)
listening port: 43447 kenne ich nicht

peer: auch korrekt
endpoint: die ip ist die gerade aktuelle laut duckdns:51820
allowed ips: 10.0.0.0/24, 192.168.0.0/24
transfer: 0 B received, 7.37 KiB sent
persistent keepalive: every 25 seconds

[uan]

Ich bin mit meinem Latein am ende

[mat6937]

transfer: 0 B received, 7.37 KiB sent

Es kommt keine Antwort vom WG-Server. Jetzt wäre der unabhängige ssh-Zugang zum Server, nützlich um dort nachzuschauen.

[uan]

Hast Du denn eine Idee, was klemmen könnte?

[mat6937]

Hast Du denn eine Idee, was klemmen könnte?

Nein, ohne Zugang zum Server ...

[uan]

Dann fahre ich nochmal rüber
Den Dienst nochmal neu starten?

wg0.conf nochmal neu aufkopieren?

[uan]

Ich glaube, ich habs.

Mit dem Abstand einer gut geschlafenen Nacht, hab ich nochmal in aller Ruhe die Clientseite durchleuchtet.

Wie du ja gestern schon vermutet hast, scheint der endpoint strubbelig zu sein. Und in der wg0.conf stand eine IP Adresse, die nicht passte. Wie du weisst, hab ich meine duckdns da eingetragen. Aber auf der Duckdns Seite steht meines Wissens nach immer die aktuelle IP - und die passte nicht.
Dann hab ich (und ich Schussel meine das gestern nicht gemacht zu haben) zuerst mal

Code: Alles auswählen

wg-quick down wg0

lahmgelegt und dann die IP als Versuch im Klartext in die wg0.conf eingetragen.

Tunnel im wahrsten Sinne des Wortes wieder hochgefahren - und er lief, der Tunnel.

Same prozedur, nur das ich die duckdns wieder eingetragen hab - und er lief.
Jetzt heisst abwarten, ob der cron-Job seine Arbeit tut - das werde ich bald wissen...
Nochmals von ganzem Herzen Danke

[mat6937]

Same prozedur, nur das ich die duckdns wieder eingetragen hab - und er lief.
Jetzt heisst abwarten, ob der cron-Job seine Arbeit tut - das werde ich bald wissen...

BTW: Der cronjob kann seine Arbeit nur dann gut machen, wenn das auch der dyndns-Client des WG-Servers (Endpoint) richtig macht. D. h. wenn sich die öffentliche IP-Adresse beim Endpoint ändert, muss der dortige dyndns-Client das sehr zeitnah erkennen und sofort updaten. Ist das der Fall? Macht das am Endpoint, der dyndns-Client der FritzBox/Router/"border device" (oder gleichwertig) oder hast Du einen zuverlässigen und richtig konfigurierten dyndns-Client, auf dem WG-Server?