UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[bommel_030]

@grizzelbee said in Tester für WireGuard Adapter gesucht:

Was war denn dein Problem? Vieleicht kann ich ja an der Doku oder am Handling etwas verbessern.

Nein, wenn ich im ersten Host wg show all dump eintragen und im zweiten nur wg show all ist das eigene Dummheit ;-)

@grizzelbee said in Tester für WireGuard Adapter gesucht:

Hmmm. Ich bin bei der Entwicklung davon ausgegangen, dass sich die WG-Hosts im lokalen Netz befinden.
Vielleicht gibt es da tatsächlich etwas zu beachten, wenn sie extern sind. Oder verstehe ich dich da gerade falsch?

Zwei lokal getrennte Standorte. Beide via FritzVPN (soll perspektivisch durch Wireguard abgelöst werden) verbunden. An beiden Standorten jeweils ein NUC mit Proxmox und wireguard im Container. Iobroker läuft in einem Container am Heimatstandort. Der entfernte bekommt alle 24h durch den ISP eine neue IP. Da meckert der Adapter nur wenn er zufällig abfragt und der entfernte Standort ist noch nicht wieder online. Spätestens nach der nächsten Abfrage ist aber alles wieder chic. Wenn der Heimatstandort mal ne neue IP bekommt (wird offensichtlich gewürfelt wann die Zwangstrennung kommt, definitv >24h) bekomme ich im Abfrageintervall einen Eintrag ins LOG er kann den Heimatstandort nicht erreichen. Wenn ich dann den Adapter einmal neu starte ist alles wieder in Ordnung.

@grizzelbee said in Tester für WireGuard Adapter gesucht:

Das klingt tatsächlich interessant und die Idee gefällt mir!
Die Frage ist aber tatsächlich - wie wird das realisiert?

Freut mich, dann besteht ja Hoffnung. Aber alles was ich bis jetzt finden konnte ist quasi das "auskommentieren" des entsprechenden Peers in der JSON.

[Grizzelbee]

@bommel_030 sagte in Tester für WireGuard Adapter gesucht:

Der entfernte bekommt alle 24h durch den ISP eine neue IP. Da meckert der Adapter nur wenn er zufällig abfragt und der entfernte Standort ist noch nicht wieder online. Spätestens nach der nächsten Abfrage ist aber alles wieder chic.

Das klingt vollkommen logisch für mich: Wenn die Leitung unterbrochen ist, geht die Abfrage kaputt. Damit bin ich fein.

Wenn der Heimatstandort mal ne neue IP bekommt (wird offensichtlich gewürfelt wann die Zwangstrennung kommt, definitv >24h) bekomme ich im Abfrageintervall einen Eintrag ins LOG er kann den Heimatstandort nicht erreichen. Wenn ich dann den Adapter einmal neu starte ist alles wieder in Ordnung.

Das verstehe ich noch nicht richtig. Am Heimatstandort laufen doch der Broker und Wireguard auf der selben Maschine - nur eben wegen der Container in einem virtuellen Netzwerk - aber eben auf der selben Maschine. Da ist doch der ISP gar nicht im Spiel. Also ist dem Adapter die Zwangstrennung doch vollkommen egal. Im Moment klingt das nach einem Konfigurationsfehler. Ich würde erwarten das du für den Heimatserver die lokale IP des WG-Containers angeben musst.
Bei mir zum Beispiel habe ich - weil Broker und WireGuard normal installiert sind (keine Container) - schlicht "localhost" bei der Hostadresse angegeben.

Freut mich, dann besteht ja Hoffnung. Aber alles was ich bis jetzt finden konnte ist quasi das "auskommentieren" des entsprechenden Peers in der JSON.

Habe gerade mal ein bisschen gelesen und herumgespielt. Es gibt einen besseren Weg (den ich vermutlich auch programmieren kann - auch wenn ich noch keine Idee habe wie - das übersteigt gerade mein Linux/sudoers know how):

• wg set <interface> peer <pubKey> remove löscht ein peer aus der aktuellen config. Wichtig dabei ist, dass "nur" die aktive (eingelesene/gecachete) config der aktuelle laufenden Instanz ist - nicht das config file.
• wg syncconf <interface> </path/to/config.conf>wiederum liest die config aus dem angegebenen file wieder ein und aktiviert sie bzw. vorher mittels remove deaktivierte peers.

<interface> und <pubKey> stehen mir im Adapter zur Verfügung. Einziges Problem hier ist: Wie trage ich das im sudoers file ein - weil variabel?
</path/to/config.conf> steht mir nicht zur Verfügung und kann für jeden Host unterschiedlich ein. Auch hier: Wie trage ich das im sudoers file und im Adapter ein - weil variabel?

[bommel_030]

@grizzelbee
Mit dem fernen bin ich auch völlig fein. Kein Internet, kein Problem, reconnect sobald wieder verfügbar.
Wireguard und iObroker sind in getrennten Containern installiert. Verbunden über die lokale IP. Von daher verstehe ich noch weniger was die Internetverbindung damit zu tun hat...
Das mit dem remove klingt interessant, das muss ich mir Mal am Rechner anschauen.

[Grizzelbee]

@bommel_030 sagte in Tester für WireGuard Adapter gesucht:

Wireguard und iObroker sind in getrennten Containern installiert. Verbunden über die lokale IP. Von daher verstehe ich noch weniger was die Internetverbindung damit zu tun hat...

Wie gesagt: Eigentlich sollte sie nichts damit zu tun haben. Schreib doch bitte mal ein Debug-Log. Vielleicht sehen wir da mehr.

Das mit dem remove klingt interessant, das muss ich mir Mal am Rechner anschauen.

Habe mal einen issue angelegt:

https://github.com/Grizzelbee/ioBroker.wireguard/issues/33

[Grizzelbee]

@bommel_030 sagte in Tester für WireGuard Adapter gesucht:

Das mit dem remove klingt interessant, das muss ich mir Mal am Rechner anschauen.

Ich habe das mal implementiert und gerade ins latest geschoben. Version 1.3.0 des Adapters kann jetzt also einzelne peers suspendieren und alle peers eine interfaces wieder aktivieren (wg kann das reaktivieren nicht selektiv).

v1.3.0 (2022-06-25)

• (grizzelbee) Fixed: #33 Added buttons to suspend single and restore all peers of an interface
• (grizzelbee) Upd: dependencies got updated

Edit:
Ach Ja! Bitte Readme beachten. Es muss im Admin config ergänzt und sudoers erweitert werden damit das klappt.

[bommel_030]

@grizzelbee
Ein Träumchen! Das Wetter leider ebenso ;-) Teste heute Abend sobald der Kurze im Bett ist!

[bommel_030]

@grizzelbee
So, suspend klappt sofort. Restore leider nicht. Erst wenn ich den wireguard service manuell neu starte.
Gibt es einen Grund warum ich nur alle reaktivieren kann und nicht auch einzelne restoren kann?

[Grizzelbee]

@bommel_030 sagte in Tester für WireGuard Adapter gesucht:

So, suspend klappt sofort. Restore leider nicht.

Komisch. Bei mir funktiniert beides sauber.
Nutzt du sudo? Wenn ja -> hast Du die beiden neuen sudoers Regeln eingetragen?

Erstelle bitte mal ein Debug-log und schau ob da was hilfreiches drin steht. Kannst es auch gerne mir schicken oder hier posten. Dann gucke ich mal rein.

@bommel_030 sagte in Tester für WireGuard Adapter gesucht:

Gibt es einen Grund warum ich nur alle reaktivieren kann und nicht auch einzelne restoren kann?

Ja - weil ich gerade erst (quasi durch deine Nachfrage) rausgefunden habe, das man auch einzelne Peers wieder aktivieren kann ;) Ich hatte zuerst nur die all-peers Methode gefunden.

Ich baue das noch ein ...

[bommel_030]

@grizzelbee
So, auch mit der neuen Version "nur" Teilerfolg. Suspend eines Peers klappt umgehend. Sowohl einzelner Peer, sowie alle Peers resume wird im Log zwar korrekt aufgeführt, zeigt aber keine Wirkung, aber auch keine Fehler. Vollständiges Debug Log gerne per PN oder Mail, was dir lieber ist.

Spoiler

wireguard.0
2022-06-27 08:17:12.207	debug	Executing command: [sudo wg syncconf wg0 ]

wireguard.0
2022-06-27 08:17:12.207	debug	ssh client :: authenticated

wireguard.0
2022-06-27 08:17:12.040	debug	Executing command [sudo wg syncconf wg0 ] on host 192.168.90.6.

wireguard.0
2022-06-27 08:17:12.040	info	Config: iFace=wg0, host=192.168.90.6

wireguard.0
2022-06-27 08:17:12.040	info	Config: iFace=wg0, host=192.168.10.4

wireguard.0
2022-06-27 08:17:12.040	info	Restoring all peers for interface wg0 on host K

wireguard.0
2022-06-27 08:16:23.994	debug	Executing command: [sudo wg set wg0 peer hierstehtsonstderkey allowed-ips 10.252.90.1/32]

wireguard.0
2022-06-27 08:16:23.994	debug	ssh client :: authenticated

wireguard.0
2022-06-27 08:16:23.823	debug	Executing command [sudo wg set wg0 peer hierstehtsonstderkey allowed-ips 10.252.90.1/32] on host 192.168.90.6.

wireguard.0
2022-06-27 08:16:23.823	info	Restoring peer [hierstehtsonstderkey] of interface wg0 on host 192.168.90.6 with IP [10.252.90.1/32].

wireguard.0
2022-06-27 08:16:23.823	info	Restoring peer hierstehtsonstderkey with IP 10.252.90.1/32 on interface wg0.

Nach einem

sudo wg-quick down wg0
sudo wg-quick up wg0

in der Konsole wird der Client sofort wieder verbunden.
Zu deinen Fragen, ich nutze sudo und habe die neuen/zusätzlichen sudoers Regeln auch eingetragen. Da suspend funktioniert und im Log kein Fehler beim Resume kommt scheinen die auch zu passen.
Ich habe IP´s statt Hostname eingetragen, aber das sollte vermutlich kein Problem sein. Ich nutze die WireguardUI (eigenltich nur um neue Peers anzulegen oder QR Code zu scannen). Die braucht nach jeder Änderung auch einen wg restart (geschieht dort automatisch bei "Einstellungen übernehmen").

[Grizzelbee]

@bommel_030

Hey Bommel,

was ist eigentlich hier aus den Tests geworden? Funktioniert jetzt alles? Kann der Adapter so ins Stable?

[bommel_030]

@grizzelbee
Ich bin noch am testen, kann aber leider noch nicht ausschließen das es an meiner Installation liegt.
Von daher kann er meinetwegen gerne ins stabile.

[bommel_030]

@grizzelbee
Hab Mal dein neuestes Update installiert. Habe in einer Instanz zwei Hosts mit unterschiedlichen Abrufintervallen hinterlegt. Die Anzahl der connected Peers wird bei beiden mit 3 angegeben, obwohl beim ersten Peer einer und beim zweiten Peer zwei verbunden sind. In Summe ist die Anzahl richtig, halt nur "falsch" aufgeteilt.
Weiterhin sind beide definitiv online, es wird aber immer nur der als online=true angezeigt der als letztes gepollt wurde. Es wechseln also im Abrufintervall beide von offline zu online und der andere von online zu offline.
Oder sollten zwei Hosts besser auf zwei Instanzen aufgeteilt werden?

[Grizzelbee]

@bommel_030 sagte in Tester für WireGuard Adapter gesucht:

Hi bommel,
vielen Dank für dein Feedback. Da ich selber nur einen WireGuard host habe, sind mir derartige Spielchen nicht aufgefallen - das muss ich mir dann noch einmal angucken. Das sollte nicht so sein. Die Idee war, das ein interface, das aktiv ist auch als online angezeigt wird.
Mit den connectedPeers spiele ich gerade noch herum - da ist ohnehin noch ein bug drin: Peers, die offline gehen werden nicht von der Summe abgezogen - da hatte ich etwas kurz gedacht.

In Summe ist die Anzahl richtig, halt nur "falsch" aufgeteilt.

Dann habe ich schon eine Idee woran das liegt!

Oder sollten zwei Hosts besser auf zwei Instanzen aufgeteilt werden?

Um Gottes Willen - Nein! Die eine Instanz soll schon beliebig viele Hosts überwachen können.

[Stephan Schleich]

@grizzelbee Hat sich in den letzten Versionen was geändert?
Kann mich nicht mehr mit dem Adapter connecten via Putty gehts aber v1.3.1

Connection to host [WireGuard] can't be established. Please check and fix. =>[Error: All configured authentication methods failed]

[Grizzelbee]

@stephan-schleich

Hat sich in den letzten Versionen was geändert?

Sei mir nicht böse ... aber es fällt mir echt schwer mein Sarkasmus-Gen zu zügeln. ;)

Also: Ja, klar hat sich etwas geändert. Was genau kann ich natürlich nicht sagen, weil ich nicht weiß von welcher Version auf welche Du aktualisiert hast. Ich protokolliere aber meine Änderungen recht ordentlich und gewissenhaft im Changelog auf github (https://github.com/Grizzelbee/ioBroker.wireguard). Schau da doch bitte mal vorbei.

Ich schieße mal wild ins Blaue und sage: Gib bitte einfach das Passwort des Monitoring-Users mal neu ein. Weitere Fragen beantworte ich gerne, wenn ich mehr Informationen bekomme.

[Stephan Schleich]

@grizzelbee Alles gut :)
Ich vermute seit der v1.4.0 hab ich das Problem
Komisch ist das der login via Putty klappt aber via Adapter nicht. im Debug steht auch nicht dazu

[David G.]

@grizzelbee

Hallo,

ich habe eine Frage zur Konfiguration.

Wenn ich unter PUBLIC-KEY-ÜBERSETZUNGEN etwas hinzufüge bleibt der Adapter gelb.

Im Log finde ich aber nicht wirklich was.

Selbiges wenn ich WIREGUARD CONFIG FILES ausfülle.

Trotz gelben Adapter werden laut log Daten abgerufen, was allerdings nicht stimmt.

wireguard.0
2022-11-01 13:35:25.843	debug	Executing command [sudo wg show all dump] on host 192.168.99.33.

wireguard.0
2022-11-01 13:35:25.843	debug	Retrieving WireGuard status of host [iobroker] on address [192.168.99.33]

wireguard.0
2022-11-01 13:34:55.843	debug	Executing command [sudo wg show all dump] on host 192.168.99.33.

wireguard.0
2022-11-01 13:34:55.843	debug	Retrieving WireGuard status of host [iobroker] on address [192.168.99.33]

wireguard.0
2022-11-01 13:34:25.844	debug	Executing command [sudo wg show all dump] on host 192.168.99.33.

wireguard.0
2022-11-01 13:34:25.843	debug	Retrieving WireGuard status of host [iobroker] on address [192.168.99.33]

wireguard.0
2022-11-01 13:33:55.844	debug	Executing command [sudo wg show all dump] on host 192.168.99.33.

wireguard.0
2022-11-01 13:33:55.843	debug	Retrieving WireGuard status of host [iobroker] on address [192.168.99.33]

wireguard.0
2022-11-01 13:33:25.843	debug	Executing command [sudo wg show all dump] on host 192.168.99.33.

wireguard.0
2022-11-01 13:33:25.842	debug	Retrieving WireGuard status of host [iobroker] on address [192.168.99.33]

[Grizzelbee]

@david-g sagte in Tester für WireGuard Adapter gesucht:

ich habe eine Frage zur Konfiguration.
Wenn ich unter PUBLIC-KEY-ÜBERSETZUNGEN etwas hinzufüge bleibt der Adapter gelb.

Hallo David,

also ... die Sache ist nicht ganz trivial ...
Um den Adapter zum Laufen zu bringen, brauchst Du nur die Basis-Konfig. Der Rest ist optional und nur für Komfortfunktionen interessant. Aber dröseln wir das mal auf:
Wenn die Basis Konfig okay ist (und danach sieht es lt. Log bei dir aus) wird der Adapter frühestens nachdem er den ersten Poll-Intervall geschafft hat (default 2 Minuten) grün - vorher bleibt der gelb. Der wird aber auch nur dann grün, wenn er überhaupt mindestens ein aktives WireGuard Interface findet. Ohne das bleibt er auch gelb. Also gibt es grundsätzlich schon mal zwei gewollte Situationen in denen der Adapter gelb sein darf:

1. Noch kein Pollintervall abgeschlossen
2. Kein aktives WireGuard interface gefunden.

Fall 1 scheint bei Dir kein Ding zu sein - ich sehe mehrere Poll-Versuche.

• Was ist mit Fall 2?
• Was passiert, wenn Du dich mit dem Monitoring-User interaktiv anmeldest und das Kommando sudo wg show all dump absetzt?
• Hast Du die sudoers Datei wie in der readme beschrieben angepasst?

Ich kenne allerdings auch einen User, der den Adapter tatsächlich nicht ans Laufen bekommen hat. Da bekam der Adapter von dem LXC-Container in dem WireGuard läuft keine Daten zurück geliefert. Das hat wohl etwas mit Linux-pseudo-terminals zu tun. Das Thema haben wir leider nicht geknackt. Bei anderen Usern mit LXC-Containern läuft er aber durchaus. Das ist also kein generelles LXC Thema.

Public-Key-Übersetzungen:

Die dienen nur dazu einen verständlichen Namen an die Peers zu bekommen - weil die public Keys etwas unhandlich und schwer zu merken sind:

Ohne die Übersetzung siehst Du halt nur die public Keys - das ist alles. Mehr passiert nicht. Die Funktion als solche wird nicht beeinträchtigt.

Wireguard Konfig Files (eins pro WG-Interface)

Die wiederum werden nur gebraucht, wenn man den Restore all suspended peers Button nutzen möchte - man also mehrere Peers suspendiert hat und alle gleichzeitig wieder aktivieren will.

[Grizzelbee]

@stephan-schleich

Ich habe das Admin-interface in der 1.4.0 auf jsonConfig umgestellt - das erzwingt leider das das Passwort und der Benutzername neu eingeben werden müssen - da sollte es eigentlich auch einen Hinweisdialog zu geben.

Ich erneuere also meine Bitte:
Gib mal im Adamin der Monitoring-User und dessen Passwort neu ein - ich bin ganz zuversichtlich das es dann wieder läuft.

[David G.]

@grizzelbee

Danke für die ausführliche Antwort.

Gehe jetzt mal alles genau durch.

Wenn ich im Adapter nur das einstelle:

läuft alles und der Adapter wird grün.

Wenn ich die config files ausfülle bleibt er gelb.

Wenn ich mit den Namen übersetzen lassen möchte kopiere ich mir den öffentlichen key aus dem Datenpunkt des clients.

Sobald ich diesen eingebe bleibt der Adapter gelb.

root@pi:/etc/wireguard# dir
configs  keys  wg0.conf

(bin nur root um die Dateien zu sehen).

Das kommt, wenn ich den dump in der Konsole Abfrage:

 pi@pi:~ $ sudo wg show all dump
/etc/sudoers:28:4: syntax error
<pi> ALL=NOPASSWD:/usr/bin/wg show all dump
   ^
/etc/sudoers:29:10: syntax error
<iobroker> ALL=NOPASSWD:/usr/bin/wg show all dump
         ^
wg0     xxxxxxxxxx       51820   off
wg0     xxxxxxxxxx       84.171.74.123:36311     10.189.255.2/32    1667380952      7527016 106836416       off
wg0     xxxxxxxx       87.177.22.167:47148     10.189.255.3/32    1667330049      1013028 7267524 off
pi@pi:~ $

Das ist meine sudoers:

#
# This file MUST be edited with the 'visudo' command as root.
  GNU nano 5.4              /etc/sudoers.tmp                       #
# Please consider adding local content in /etc/sudoers.d/ instead ># directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults        env_reset
Defaults        mail_badpass
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/s>
# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL:ALL) ALL

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

# See sudoers(5) for more information on "@include" directives:

@includedir /etc/sudoers.d
<pi> ALL=NOPASSWD:/usr/bin/wg show all dump
<iobroker> ALL=NOPASSWD:/usr/bin/wg show all dump


^G Help      ^O Write Out ^W Where Is  ^K Cut       ^T Execute
^X Exit      ^R Read File ^\ Replace   ^U Paste     ^J Justify

Edit:
Seitdem ich die sudoers angepasst habe, bleibt der Adapter immer gelb.

EDIT 2:
Im dump hab ich einen Fehler in der sudoers gesehen. Den hab ich behoben.