... bitte nicht gleich grillen wenn es ein bisschen OT ist:
Ich bin seit jeher von der fhem-Einbindung von Telegram begeistert.
Vor allem, dass der RPi nach außen keine Ports offen haben muss und them trotzdem steuerbar bleibt ...
Ich habe zu Hause einen RPi1, der über ssh und OpenVPN von außen erreichbar ist.
In meinem Wochenendhäuschen habe ich einen RPi2 mit 4G-Modem und benutze Telegram zum Fernsteuern.
Was ich gerne erreichen würde:
* Keyword über Telegram an RPi2
* RPi2 verbindet sich (zB stunnel) zu meinem RPi1
* ich kann mich per ssh remote zu meinem RPi2 verbinden
* Keyword über Telegram an RPi2
* RPi2 trennt Verbindung ...
Ist das möglich?
Hi,
denke mal ein bisschen "näher" - FHEM kann fast alles. ;)
Mal ohne Telegramm und ohne FHEM nachgedacht:
- kannst Du Dich denn von deinem RPI2 über stunnel zum RPi1 verbinden, kann user fhem das?
- kann sich denn Dein user fhem über ssh zum RPi2 verbinden?
Warum eigentlich vom RPi1 zum RPi2 die ssh Verbindung aufbauen? Dazu müsstest Du dem RPi1 sagen das der RPi2 jetzt da ist - ok geht über PRESENCE.
Gruß Otto
Die Idee ist, dass RPi2 zwar dauernd Zugriff aufs Internet hat, aber von Remote NICHT zugegriffen werden kann (also kein Port nach außen offen ist).
Für Wartungsarbeiten würde ich mich aber - nach einem bestimmten ,,Signal" - zu RPi2 verbinden wollen.
Nach einem anderen ,,Signal" ist RPi2 dann wieder nicht von außen erreichbar.
Als ,,Signal" dachte ich zB an eine Telegram-Message.
Als Reaktion darauf zB Aktivieren des sshd (oder Aufbau eines stunnels zu meinem RPi1)
Da waren drei Fragezeichen ::)
Was hat denn ein laufender ssh mit offenen Ports zu tun?
Wenn Dein Pi1 eine Einwahl per OpenVPN ermöglicht, dann lass doch den Pi2 bei "Telegram" eine VPN Verbindung aufbauen und dann hast Du über diesen Tunnel Zugriff vom Pi1 auf den Pi2.
genau das habe ich nun gemacht
vermutlich etwas umständlich, aber es erfüllt den Zweck:
if (sudo lsof -i -P -n|grep openvpn) ; then
# disconnect
echo "signal SIGTERM"|nc 127.0.0.1 999;
else
# connect
sudo openvpn --config openvpn/xxx.ovpn --management 127.0.0.1 999
fi
RPi1 (at home)
eth0:192.168.1.1/255.255.0.0
tun0:10.8.0.25 (OpenVPN Server)--\
|
RPi2 (remote) |
tun0:10.8.0.26 (OpenVPN Client)--/
eth0:192.168.0.2----------\
|
Internet Modem (remote) |
eth0:192.168.0.1----------/
was mir jetzt noch fehlt (vlt kann mir da jemand untern die Arme greifen :o):
Nachdem RPi2 zu RPi1 verbunden ist, brauche ich Browser-Zugriff (ich vermute mit ssh-tunnel sollte das gehen ...)
1: vom "at home"-Netzwerk auf den FHEM-WebClient auf RPi2
2: vom "at home"-Netzwerk auf den Webserver auf dem Internet Modem (remote)
bin für jede Hilfe dankbar!!!!
Warum verwendest Du stunnel UND ssh? ssh KANN Port von sich aus tunneln. Gerade bei solch einem Aufbau ist damit ein "Tunnel per ssh" eigentlich viel Sinnvoller.
Also auf "ping" mach der entfernte PI eine SSH Verbindung mit Port-Forwarding (Interer PI Port X auf externen Pi Port X) zum nahen PI auf. Dann kannst Du über den "Port-Tunnel" alles machen.
Hi,
die Lösung für 1. und 2. heisst (eventuell) Routingeintrag. Kann man an unterschiedlichen Stellen einrichten. Ich rede mal Beispielhaft vom Windows Host:
route add Ziel gateway
route add 192.168.0.2 10.8.0.25
Damit wird eine Hostroute gesetzt (mask 255.255.255.255) kann man auch als Netzwerkroute (192.168.0.0 mask 255.255.255.0 10.8.0.25) machen.
Damit das funktioniert:
- muss das Gateway bekannt sein: 10.8.0.25
- Muss der Client 192.168.0.2 eine Route bekommen ins Netzwerk deines Windows Host. (Vielleicht hat er die automatisch durch die Einwahl - muss aber nicht so sein)
- muss der VPN Server 10.8.0.25 wirklich routen
192.168.0.1 kann diese Route nicht kennen, den musst Du sie also eintragen, falls er das kann.
Der
Gruß Otto
Ansonsten relativ gut beschrieben im Ubuntu HowTo zu openvpn:
https://wiki.ubuntuusers.de/OpenVPN/ (https://wiki.ubuntuusers.de/OpenVPN/)
Hallo zusammen,
ich schalte mich mal hier dazu.
Vorweg: EIN DICKES, FETTES Lob an dieses Forum!!! Ich nutze seit ca. 3-4Jahren FHEM und hab ganz klein angefangen und hab inzwischen ein recht ausgewachsenes System. Vor allem durch fleißiges Lesen hier im Forum. Bisher konnte ich mir eigentlich immer selbst helfen...wenn auch manchmal eher - nennen wir's einmal - kreativ. Aus Programmierersicht wahrscheinlich eher umständlich bis katastrophal ;-)
Nun zu meiner Frage bzw. Ausgangssituation: ich arbeite an einer Hochschule, und die bietet nen VPN-Zugang. Diesen möchte ich nutzen, um von außerhalb auf mein System zuzugreifen. Über die Fritzbox ansich klappts nicht, dual stack lite (oder so) und Vodafon Kabelanschluss sei Dank :-(
Wie auch immer. ich habe folgenden Plan: per Telegram ein Kommando an fhem (funktioniert!) -> FHEM triggert auf die Telegram-Nachricht(krieg ich problemlos hin) und FHEM soll an das darunterliegende Linux-System den Befehl für das Aufbauen der VPN-Verbindung schicken (PROBLEM!) An der Stelle wirds (für mich) kniffelig: FHEM läuft in einem LXC-Container unter Proxmox. OpenVpn im entsprechenden Fhem-Container installiert und über Kommandozeile als root-user erfolgreicher Verbindungsaufbau möglich ("openvpn /etc/openvpn/client.ovpn"). Per "sudo visudo" dem fhem-user noch die rechte passwortlosen ausführen für openvpn gegeben. Dann per "passwd fhem" mal ein PW für fhem gesetzt und mich an der Konsole erolgreich per fhem-user angemeldet und erfolgreich die VPN-Verbindung aufbauen können...auch mal reboots dazwischen.
Wenn ich jetzt aber aus FHEM heraus per z.B. notify probiere den Befehl abzusetzen, klappt's nicht. Nagut..bauste dir halt noch ein script mit entsprechenden Rechten in /opt/fhem/FHEM zum Starten und Stoppen des ganzen. Als FHEM-user an der Konsole kein Problem, aus FHEM heraus aber auch nicht erfolgreich. Ich hab viel probiert, inklusive Befehle per ssh von einem System aufs nächste schicken (was aus der Konsole heraus auch funktioniert) usw....ALLES ERFOLGLOS.
Ich schreibe jetzt hier ganz bewußt nicht jeden Schritt auf, da ich hoffe, Ihr könnt mir so unvorbelasteter helfen.
Besten Dank schon mal und nen schönen Feierabend
Grüße Benni
Also wenn es als User fhem auf der Cosole damit:
openvpn /etc/openvpn/client.ovpn
geht, dann sollte das hier (inkl. Anführungszeichen!!):
"openvpn /etc/openvpn/client.ovpn"
oben in das FhemWeb-Fenster auch gehen.
Evtl. noch VOR openvpn den Pfad (z.B. mittels "which openvpn" abfragen) angeben, sicher ist mal sicher... ;)
Und wenn das dann geht, einfach in deinem Telegram-Empfangs-notify genauso, also:
define nTele notify Telebot:msg.* "openvpn /etc/openvpn/client.ovpn"
Den vorderen Teil des notify musst du nat. passend machen, das ist hier nur "beispielhaft"...
EDIT: solltest du im notify Perl nutzen (wollen), dann eben so: define nTele notify Telebot:msg.* {if(something){fhem("\"openvpn /etc/openvpn/client.ovpn\"")}}
Gruß, Joachim
P.S.: du darfst auch ruhig einen eigenen Thread aufmachen ;)
Hi,
ZitatDann per "passwd fhem" mal ein PW für fhem gesetzt und mich an der Konsole erolgreich per fhem-user angemeldet und erfolgreich die VPN-Verbindung aufbauen können...auch mal reboots dazwischen.
Wenn ich jetzt aber aus FHEM heraus per z.B. notify probiere den Befehl abzusetzen, klappt's nicht. Nagut..bauste dir halt noch ein script mit entsprechenden Rechten in /opt/fhem/FHEM zum Starten und Stoppen des ganzen. Als FHEM-user an der Konsole kein Problem, aus FHEM heraus aber auch nicht erfolgreich. Ich hab viel probiert, inklusive Befehle per ssh von einem System aufs nächste schicken (was aus der Konsole heraus auch funktioniert) usw....ALLES ERFOLGLOS.
geht auch mit sudo -su fhem ... ohne Passwort setzen - aber egal.
Was hasste denn in FHEM probiert? Befehle, Scripts - Glaskugelkanal?
Gruß Otto
Hi zusammen,
danke für die Antworten/Gegenfragen. Also, wie gesagt, das mit dem Telegram-Notify bekomme ich hin...irgendwie :-) das Problem ist tatsächlich, dass ich mein linux nicht davon überzeugen kann, den Befehl von fhem korrekt auszuführen.
Was hab ich aus FHEM probiert?:
{ system(Befehl)}
{ system('Befehl')}
{ system("Befehl")}
{qx(Befehl)}
{qx('Befehl')}
{qx("Befehl")}
aus der FHEM-Kommandozeile wie aus einem Test-notify heraus. Mal mit, mal ohne sudo vorweg. Mal per script, mal im script per sudo, mal ohne. Alles erfolglos.
...Bin echt am Verzweifeln :-(
Und wenn ich zulange an der LXC-Kiste probiert habe, spiele ich ein unverbasteltes Backup zurück, um immer wieder quasi neu anzusetzen (und jedesmal "protokolliere" ich in notepad++ meine Schritte). Das aber nur am Rande
Wie gesagt: ich werde da echt nicht schlau draus: als fhem-user im terminal klappts ja!!!
Grüße
Benni
Es wäre hilfreich statt "Befehl" wirklich zu schreiben was du probiert hast ;)
Hast du schon eines der Vorschläge probiert?
Gruß, Joachim
Hi Benni,
Du zeigst nur pseudos, der Teufel steckt im Detail.
Aus FHEM würde ich erstmal das machen "Shell Befehl".
Zeig bitte was echtes. { system(Befehl)}, {qx('Befehl')} und {qx("Befehl")} ist grundlegend falsch - kannst Du streichen :) Da musst Du Fehlermeldungen bekommen!
Mal noch meine Notiz zu dem Thema (https://heinz-otto.blogspot.com/2018/02/in-fhem-externe-programme-aufrufen.html).
BTW: sudo ist kein Allheilmittel! Wenn Du sudo brauchst um eine vpn Verbindung zu öffnen hast Du ALLES falsch gemacht!
Gruß Otto
Und arbeite, wie MadMax schon schrieb, am besten mit vollen Pfaden. In einer Deamon-Umgebung muß es nicht immer funktionieren.
Also wie geschrieben, den vollen Pfad kannst Du raus finden mit
whereis <Commando>
Hier natürlich <Commando> durch openvpn ersetzen
ok, ok :-)
erstmal danke für den "whereis"... Hinweis. Kannte ich noch nicht und ist schon in meiner sammlung drin.
Dann zu dem Platzhalter "Befehl":
mit { system()}:
{ system(openvpn /etc/openvpn/client.ovpn)}{ system('openvpn /etc/openvpn/client.ovpn')}{ system("openvpn /etc/openvpn/client.ovpn")}{ system(sudo openvpn /etc/openvpn/client.ovpn)}{ system('sudo openvpn /etc/openvpn/client.ovpn')}{ system("sudo openvpn /etc/openvpn/client.ovpn")}dann mit {qx()}:
{ qx(openvpn /etc/openvpn/client.ovpn)}{ qx('openvpn /etc/openvpn/client.ovpn')}{ qx("openvpn /etc/openvpn/client.ovpn")}{ qx(sudo openvpn /etc/openvpn/client.ovpn)}{ qx('sudo openvpn /etc/openvpn/client.ovpn')}{ qx("sudo openvpn /etc/openvpn/client.ovpn")}dann die Versuche, bei denen ich anstelle des direkten Aufrufs den Umweg mit einem Script gelaufen bin. Ich Spar mir aber an der Stelle die einzelnen Code-Aufrufe bzw. schreibe halt nur einmal den eigentlichen code und den Inhalt der Scripte:
{ system(bash /opt/fhem/FHEM/startVPN.sh)}usw. wie oben
{ system(sudo bash /opt/fhem/FHEM/startVPN.sh)}usw. wie oben.
Inhalt des Scripts (einmal mit und einmal ohne sudo probiert)
Zitat#!/bin/bash
openvpn /etc/openvpn/client.ovpn
auf die scripte habe ich ein "chmod +x startVPN.sh" losgelassen.
Ich hoffe ich erschlag euch jetzt nicht. Aber ihr seht, ich bin nicht faul und gehe (meinem Wissensstand nach) systemmatisch vor. Oder probiers jedenfalls :-)
Auf jeden Fall danke für die Unterstützung und auch Geduld.
Grüße
Benni
Hast du jetzt schon mal einen der Vorschläge probiert!!?
Gruß, Joachim
@MadMax-FHEM
jup, habe ich...erfolglos :-(
Das Mistdings fuchst mich echt!!!
Gruß Benni
Zitat von: Ben_Ni am 28 April 2021, 20:24:09
@MadMax-FHEM
jup, habe ich...erfolglos :-(
Das Mistdings fuchst mich echt!!!
Gruß Benni
Und WAS hast du probiert!?
Wie wäre es das zu posten...
Steht was im Log?
Gruß, Joachim
@MadMax-FHEM
na das, was du vorgeschlagen hast ;-)
in der in FHEM obigen Kommadozeile
"openvpn /etc/openvpn/client.ovpn"
erfolglos.
Dann ein Testnotify auf ein dummy namens d_VPNtester getriggert
define nTesterVPN notify d_VPNtester:connect "openvpn /etc/openvpn/client.ovpn"
wieder nix :-(
sorry fürs nicht-gleich-mit-code-schreiben
Grüße
Benni
p.s. logfile checken!!! hab ich noch nicht gemacht
Und warum OHNE Pfad?
Steht was im Log!!!?
Ist echt anstrengend, wenn man alles aus der Nase ziegen muss... ;)
Das was als User fhem in der Linux Console auf dem fhem Rechner (im fhem Container) geht, geht eigentlich auch in FhemWeb-cmd, wenn man das in Anführungszeichen packt...
Warum das bei dir nicht geht: rätselhaft...
Aber ohne weitere Infos wie beispielsweise: steht was im Log etc. schwierig...
Gruß, Joachim
@MadMax-FHEM im speziellen und an jeden anderen hier,
sorry fürs "nose-pulling"
wie MadMax-FHEM richtig nachvollzieht: es erschließt sich mir nicht, wie und warum das in der Konsole als angemelderter fhem-user klappt, und aus fhem herraus nicht.
zum Thema-Logfile: da habe ich gerade etwas sehr mysteriöses entdeckt - hat allerdings nichts mit meiner Problematik zu tun.
(...conbee2: http request failed: 192.168.178.120: no route to host...was seltsam ist, da das device conbee2 gar nicht mehr existiert, und den server 192.168.178.120 gibts auch nicht mehr, weshalb ja der request fehlschlägt...hmmm. Ich glaube darum muss ich mich jetzt zuerst kümmern).
Halte euch auf dem laufenden!!!
Vielen herzlichsten Dank soweit. Aber mit openVPN bin ich definitv noch nicht fertig ;-)
Grüße
Benni
Hi Benni,
ich habe das Gefühl Du ignorierst jedes Log, die Ausgabe auf dem Schirm oder hast keinen Monitor oder spielst blinde Kuh?
Deine ganzen Versuche laufen nicht ab ohne irgendwelche Fehlermeldungen.
Gruß Otto
@Otto123
so in der Richtung! Bin bisher gut ohne zurecht gekommen. ABER, man lernt ja nie aus!!!
Ich werde morgen nochmal intensiver testen UND dabei das log-file sehr genau im Auge behalten.
Ernsthaft, bin euch sehr dankbar!!! Würde mich am Ende noch mehr freuen, wenn ich den Knoten mit eurer Hilfe zum platzen bekäme.
Nehmts mir nicht übel, dass ihr so viel nachfragen müßt. Ich muss mich erstmal an das Schreiben und nicht nur Lesen im Forum gewöhnen. Bitte um Nachsicht.
In diesem Sinne:
Benni
Und gib uns Auszüge der Logfiles ...
Wir braucnen Input für Output!!!
OK, hier kommt also das ausführliche Protokoll des Versagens :-)
Nur zur Info: die eigentlichen IP-Adressen zum VPN-Server meines Arbeitgebers habe ich mit XXX.XXX.XXX.XXX unkenntlich gemacht.
in einer Terminal-Konsole als user "root" angemeldet:
openvpn /etc/openvpn/client.ovpn
Rückgabe im Terminal-Fenster
Thu Apr 29 12:32:44 2021 WARNING: file '/etc/openvpn/losung.txt' is group or others accessible
Thu Apr 29 12:32:44 2021 OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 14 2019
Thu Apr 29 12:32:44 2021 library versions: OpenSSL 1.1.1 11 Sep 2018, LZO 2.08
Thu Apr 29 12:32:44 2021 TCP/UDP: Preserving recently used remote address: [AF_INET]XXX.XXX.XXX.XXX:443
Thu Apr 29 12:32:44 2021 Socket Buffers: R=[131072->131072] S=[16384->16384]
Thu Apr 29 12:32:44 2021 Attempting to establish TCP connection with [AF_INET]XXX.XXX.XXX.XXX:443 [nonblock]
Thu Apr 29 12:32:45 2021 TCP connection established with [AF_INET]XXX.XXX.XXX.XXX:443
Thu Apr 29 12:32:45 2021 TCP_CLIENT link local: (not bound)
Thu Apr 29 12:32:45 2021 TCP_CLIENT link remote: [AF_INET]XXX.XXX.XXX.XXX:443
Thu Apr 29 12:32:46 2021 TLS: Initial packet from [AF_INET]XXX.XXX.XXX.XXX:443, sid=2064d75b 63cd3500
Thu Apr 29 12:32:46 2021 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Thu Apr 29 12:32:46 2021 VERIFY OK: depth=1, O=WatchGuard_Technologies, OU=Fireware, CN=Fireware SSLVPN (SN 80DA03E8E66B7 2016-04-14 06:20:36 GMT) CA
Thu Apr 29 12:32:46 2021 Validating certificate extended key usage
Thu Apr 29 12:32:46 2021 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Thu Apr 29 12:32:46 2021 VERIFY EKU OK
Thu Apr 29 12:32:46 2021 VERIFY OK: depth=0, O=WatchGuard_Technologies, OU=Fireware, CN=Fireware SSLVPN Server
Thu Apr 29 12:32:46 2021 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Thu Apr 29 12:32:46 2021 [Fireware SSLVPN Server] Peer Connection Initiated with [AF_INET]XXX.XXX.XXX.XXX:443
Thu Apr 29 12:32:47 2021 SENT CONTROL [Fireware SSLVPN Server]: 'PUSH_REQUEST' (status=1)
Thu Apr 29 12:32:52 2021 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,block-outside-dns,dhcp-option DOMAIN XXX.de,dhcp-option DNS 172.17.1.12,dhcp-option DNS 172.17.1.11,dhcp-option WINS 172.17.1.12,dhcp-option WINS 172.17.1.11,route-gateway 192.168.241.1,topology subnet,ping 10,ping-restart 60,ifconfig 192.168.241.6 255.255.255.0,peer-id 0'
Thu Apr 29 12:32:52 2021 Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:2: block-outside-dns (2.4.4)
Thu Apr 29 12:32:52 2021 OPTIONS IMPORT: timers and/or timeouts modified
Thu Apr 29 12:32:52 2021 OPTIONS IMPORT: --ifconfig/up options modified
Thu Apr 29 12:32:52 2021 OPTIONS IMPORT: route options modified
Thu Apr 29 12:32:52 2021 OPTIONS IMPORT: route-related options modified
Thu Apr 29 12:32:52 2021 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Thu Apr 29 12:32:52 2021 OPTIONS IMPORT: peer-id set
Thu Apr 29 12:32:52 2021 OPTIONS IMPORT: adjusting link_mtu to 1626
Thu Apr 29 12:32:52 2021 Outgoing Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Thu Apr 29 12:32:52 2021 Outgoing Data Channel: Using 256 bit message hash 'SHA256' for HMAC authentication
Thu Apr 29 12:32:52 2021 Incoming Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Thu Apr 29 12:32:52 2021 Incoming Data Channel: Using 256 bit message hash 'SHA256' for HMAC authentication
Thu Apr 29 12:32:52 2021 ROUTE_GATEWAY 192.168.178.1/255.255.255.0 IFACE=eth0 HWADDR=22:ed:fc:e3:5a:9e
Thu Apr 29 12:32:52 2021 TUN/TAP device tun0 opened
Thu Apr 29 12:32:52 2021 Note: Cannot set tx queue length on tun0: Operation not permitted (errno=1)
Thu Apr 29 12:32:52 2021 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Thu Apr 29 12:32:52 2021 /sbin/ip link set dev tun0 up mtu 1500
Thu Apr 29 12:32:52 2021 /sbin/ip addr add dev tun0 192.168.241.6/24 broadcast 192.168.241.255
Thu Apr 29 12:32:52 2021 /sbin/ip route add XXX.XXX.XXX.XXX/32 via 192.168.178.1
Thu Apr 29 12:32:52 2021 /sbin/ip route add 0.0.0.0/1 via 192.168.241.1
Thu Apr 29 12:32:52 2021 /sbin/ip route add 128.0.0.0/1 via 192.168.241.1
Thu Apr 29 12:32:52 2021 Initialization Sequence Completed
Ein "ip addr" bestätigt mir, das die VPN-Verbindung steht, bzw. ich komme z.B. übers Handy (welches ebenfalls ein VPN-Verbindung hat) auf meinen Server. LÄUFT!!!
Jetzt
Als root-User "passwd fhem" ausgührt, um ein Passwort für den User "fhem" zu setzen.
Als root-User "nano /etc/passwd" die Zeile "fhem:x:999:20::/opt/fhem:/bin/false" zu "fhem:x:999:20::/opt/fhem:/bin/bash" geändert.
Als root-User dem User "fhem" sudo-Rechte verpasst mit "adduser fhem sudo".
Um openvpn passwortlos mit sudo-rechten auszuführen: "sudo visudo" -> und am Ende "fhem ALL=NOPASSWD: /usr/sbin/openvpn" hinzugefügt
Sicherheitshalber mal neugestartet.
Als User "fhem" auf dem Terminal eingeloggt:
sudo openvpn /etc/openvpn/client.ovpn"
-> keine Passwort-Abfrage, die Initializierung der VPN-Verbindung läuft wie gewünscht durch und klappt!
Auszug dem Terminal-Fenster
Thu Apr 29 15:20:06 2021 WARNING: file '/etc/openvpn/losung.txt' is group or others accessible
Thu Apr 29 15:20:06 2021 OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 14 2019
Thu Apr 29 15:20:06 2021 library versions: OpenSSL 1.1.1 11 Sep 2018, LZO 2.08
Thu Apr 29 15:20:06 2021 TCP/UDP: Preserving recently used remote address: [AF_INET]XXX.XXX.XXX.XXX:443
Thu Apr 29 15:20:06 2021 Socket Buffers: R=[131072->131072] S=[16384->16384]
Thu Apr 29 15:20:06 2021 Attempting to establish TCP connection with [AF_INET]XXX.XXX.XXX.XXX:443 [nonblock]
Thu Apr 29 15:20:07 2021 TCP connection established with [AF_INET]XXX.XXX.XXX.XXX:443
Thu Apr 29 15:20:07 2021 TCP_CLIENT link local: (not bound)
Thu Apr 29 15:20:07 2021 TCP_CLIENT link remote: [AF_INET]XXX.XXX.XXX.XXX:443
Thu Apr 29 15:20:07 2021 TLS: Initial packet from [AF_INET]XXX.XXX.XXX.XXX:443, sid=d4dffc4f 098407de
Thu Apr 29 15:20:07 2021 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Thu Apr 29 15:20:08 2021 VERIFY OK: depth=1, O=WatchGuard_Technologies, OU=Fireware, CN=Fireware SSLVPN (SN 80DA03E8E66B7 2016-04-14 06:20:36 GMT) CA
Thu Apr 29 15:20:08 2021 Validating certificate extended key usage
Thu Apr 29 15:20:08 2021 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Thu Apr 29 15:20:08 2021 VERIFY EKU OK
Thu Apr 29 15:20:08 2021 VERIFY OK: depth=0, O=WatchGuard_Technologies, OU=Fireware, CN=Fireware SSLVPN Server
Thu Apr 29 15:20:08 2021 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Thu Apr 29 15:20:08 2021 [Fireware SSLVPN Server] Peer Connection Initiated with [AF_INET]XXX.XXX.XXX.XXX:443
Thu Apr 29 15:20:09 2021 SENT CONTROL [Fireware SSLVPN Server]: 'PUSH_REQUEST' (status=1)
Thu Apr 29 15:20:09 2021 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,block-outside-dns,dhcp-option DOMAIN XXX.de,dhcp-option DNS 172.17.1.12,dhcp-option DNS 172.17.1.11,dhcp-option WINS 172.17.1.12,dhcp-option WINS 172.17.1.11,route-gateway 192.168.241.1,topology subnet,ping 10,ping-restart 60,ifconfig 192.168.241.17 255.255.255.0,peer-id 0'
Thu Apr 29 15:20:09 2021 Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:2: block-outside-dns (2.4.4)
Thu Apr 29 15:20:09 2021 OPTIONS IMPORT: timers and/or timeouts modified
Thu Apr 29 15:20:09 2021 OPTIONS IMPORT: --ifconfig/up options modified
Thu Apr 29 15:20:09 2021 OPTIONS IMPORT: route options modified
Thu Apr 29 15:20:09 2021 OPTIONS IMPORT: route-related options modified
Thu Apr 29 15:20:09 2021 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Thu Apr 29 15:20:09 2021 OPTIONS IMPORT: peer-id set
Thu Apr 29 15:20:09 2021 OPTIONS IMPORT: adjusting link_mtu to 1626
Thu Apr 29 15:20:09 2021 Outgoing Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Thu Apr 29 15:20:09 2021 Outgoing Data Channel: Using 256 bit message hash 'SHA256' for HMAC authentication
Thu Apr 29 15:20:09 2021 Incoming Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Thu Apr 29 15:20:09 2021 Incoming Data Channel: Using 256 bit message hash 'SHA256' for HMAC authentication
Thu Apr 29 15:20:09 2021 ROUTE_GATEWAY 192.168.178.1/255.255.255.0 IFACE=eth0 HWADDR=22:ed:fc:e3:5a:9e
Thu Apr 29 15:20:09 2021 TUN/TAP device tun0 opened
Thu Apr 29 15:20:09 2021 Note: Cannot set tx queue length on tun0: Operation not permitted (errno=1)
Thu Apr 29 15:20:09 2021 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Thu Apr 29 15:20:09 2021 /sbin/ip link set dev tun0 up mtu 1500
Thu Apr 29 15:20:09 2021 /sbin/ip addr add dev tun0 192.168.241.17/24 broadcast 192.168.241.255
Thu Apr 29 15:20:09 2021 /sbin/ip route add XXX.XXX.XXX.XXX/32 via 192.168.178.1
Thu Apr 29 15:20:09 2021 /sbin/ip route add 0.0.0.0/1 via 192.168.241.1
Thu Apr 29 15:20:09 2021 /sbin/ip route add 128.0.0.0/1 via 192.168.241.1
Thu Apr 29 15:20:09 2021 Initialization Sequence Completed
ein "ip addr" liefert
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
valid_lft forever preferred_lft forever
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
link/none
inet 192.168.241.17/24 brd 192.168.241.255 scope global tun0
valid_lft forever preferred_lft forever
inet6 fe80::95f:3e63:c174:9fa0/64 scope link stable-privacy
valid_lft forever preferred_lft forever
547: eth0@if548: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 22:ed:fc:e3:5a:9e brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.178.113/24 brd 192.168.178.255 scope global dynamic eth0
valid_lft 862843sec preferred_lft 862843sec
inet6 fe80::20ed:fcff:fee3:5a9e/64 scope link
valid_lft forever preferred_lft forever
-> OK, klappt wunderbar!!!
Jetzt als aus der Kommandozeile in der FHEM-Weboberfläche
{ system('sudo openvpn /etc/openvpn/client.ovpn')}
in dem Terminal-Fenster ein "ip addr":
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
valid_lft forever preferred_lft forever
547: eth0@if548: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 22:ed:fc:e3:5a:9e brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.178.113/24 brd 192.168.178.255 scope global dynamic eth0
valid_lft 862615sec preferred_lft 862615sec
inet6 fe80::20ed:fcff:fee3:5a9e/64 scope link
valid_lft forever preferred_lft forever
-> SCHLECHT, hat nüscht geklappt.
Nun also der Auszug aus dem FHEM-LOG-FILE
2021.04.29 15:26:37 3: FHEMWEB WEB CSRF error: csrf_937113594706965 ne csrf_147813554374641 for client WEB_192.168.178.3_57141 / command { system('sudo openvpn /etc/openvpn/client.ovpn')}. For details see the csrfToken FHEMWEB attribute.
Thu Apr 29 15:26:46 2021 WARNING: file '/etc/openvpn/losung.txt' is group or others accessible
Thu Apr 29 15:26:46 2021 OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 14 2019
Thu Apr 29 15:26:46 2021 library versions: OpenSSL 1.1.1 11 Sep 2018, LZO 2.08
Thu Apr 29 15:26:46 2021 TCP/UDP: Preserving recently used remote address: [AF_INET]XXX.XXX.XXX.XXX:443
Thu Apr 29 15:26:46 2021 Socket Buffers: R=[131072->131072] S=[16384->16384]
Thu Apr 29 15:26:46 2021 Attempting to establish TCP connection with [AF_INET]XXX.XXX.XXX.XXX:443 [nonblock]
Thu Apr 29 15:26:47 2021 TCP connection established with [AF_INET]XXX.XXX.XXX.XXX:443
Thu Apr 29 15:26:47 2021 TCP_CLIENT link local: (not bound)
Thu Apr 29 15:26:47 2021 TCP_CLIENT link remote: [AF_INET]XXX.XXX.XXX.XXX:443
Thu Apr 29 15:26:47 2021 TLS: Initial packet from [AF_INET]XXX.XXX.XXX.XXX:443, sid=7f95cf05 c0362edb
Thu Apr 29 15:26:47 2021 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Thu Apr 29 15:26:47 2021 VERIFY OK: depth=1, O=WatchGuard_Technologies, OU=Fireware, CN=Fireware SSLVPN (SN 80DA03E8E66B7 2016-04-14 06:20:36 GMT) CA
Thu Apr 29 15:26:47 2021 Validating certificate extended key usage
Thu Apr 29 15:26:47 2021 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Thu Apr 29 15:26:47 2021 VERIFY EKU OK
Thu Apr 29 15:26:47 2021 VERIFY OK: depth=0, O=WatchGuard_Technologies, OU=Fireware, CN=Fireware SSLVPN Server
Thu Apr 29 15:26:47 2021 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Thu Apr 29 15:26:47 2021 [Fireware SSLVPN Server] Peer Connection Initiated with [AF_INET]XXX.XXX.XXX.XXX:443
Thu Apr 29 15:26:48 2021 SENT CONTROL [Fireware SSLVPN Server]: 'PUSH_REQUEST' (status=1)
Thu Apr 29 15:26:53 2021 SENT CONTROL [Fireware SSLVPN Server]: 'PUSH_REQUEST' (status=1)
Thu Apr 29 15:26:53 2021 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,block-outside-dns,dhcp-option DOMAIN XXX.de,dhcp-option DNS 172.17.1.12,dhcp-option DNS 172.17.1.11,dhcp-option WINS 172.17.1.12,dhcp-option WINS 172.17.1.11,route-gateway 192.168.241.1,topology subnet,ping 10,ping-restart 60,ifconfig 192.168.241.14 255.255.255.0,peer-id 0'
Thu Apr 29 15:26:53 2021 Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:2: block-outside-dns (2.4.4)
Thu Apr 29 15:26:53 2021 OPTIONS IMPORT: timers and/or timeouts modified
Thu Apr 29 15:26:53 2021 OPTIONS IMPORT: --ifconfig/up options modified
Thu Apr 29 15:26:53 2021 OPTIONS IMPORT: route options modified
Thu Apr 29 15:26:53 2021 OPTIONS IMPORT: route-related options modified
Thu Apr 29 15:26:53 2021 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Thu Apr 29 15:26:53 2021 OPTIONS IMPORT: peer-id set
Thu Apr 29 15:26:53 2021 OPTIONS IMPORT: adjusting link_mtu to 1626
Thu Apr 29 15:26:53 2021 Outgoing Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Thu Apr 29 15:26:53 2021 Outgoing Data Channel: Using 256 bit message hash 'SHA256' for HMAC authentication
Thu Apr 29 15:26:53 2021 Incoming Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Thu Apr 29 15:26:53 2021 Incoming Data Channel: Using 256 bit message hash 'SHA256' for HMAC authentication
Thu Apr 29 15:26:53 2021 ROUTE_GATEWAY 192.168.178.1/255.255.255.0 IFACE=eth0 HWADDR=22:ed:fc:e3:5a:9e
Thu Apr 29 15:26:53 2021 TUN/TAP device tun0 opened
Thu Apr 29 15:26:53 2021 Note: Cannot set tx queue length on tun0: Operation not permitted (errno=1)
Thu Apr 29 15:26:53 2021 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Thu Apr 29 15:26:53 2021 /sbin/ip link set dev tun0 up mtu 1500
Thu Apr 29 15:26:53 2021 Linux ip link set failed: external program fork failed
Thu Apr 29 15:26:53 2021 Exiting due to fatal error
-> HMMM?!?!? letzte Zeile ist klar, Danke fürs Mitteilen ;-) der Fehler in der zweitletzen Reihe ist da schon interessanter. Habe den aber schon öfters mal im openVPN-Zusammenhang gesehen (bin ja nicht erst seit gestern an dem Mist).
Leider waren meiner Recherchen dahingehend erfolglos :-(
SEHR INTERESSANT ist allerdings die erste Zeile mit "FHEMWEB WEB CSRF error: ...". Der ist mir noch nie aufgefallen. Also kurz recherchiert und frei nach dem Motto "denn sie wissen nicht was sie tun..." in WEB-Objekt das Attribut "csrfToken"
auf "none" gestellt und fhem zumindesteinmal neugestartet.
Nochmals "{ system('sudo openvpn /etc/openvpn/client.ovpn')}" ausgeführt mit dem Ergebnis wie der Logeintrag zuvor, nur ohne "FHEMWEB WEB CSRF error: ...".
Ist doch seltsam, oder?
Warum machst du eigentlich nicht endlich mal was wir schon 1Mio mal geschrieben haben!?
Sondern immer neue, eigene Einfälle?
Also einfach mal den Pfad von "openvpn" ermitteln.
Dann "einfach" mit doppelten Anführungszeichen in Fhem-Web-Cmd: "sudo /pfad/openvpn /etc/openvpn/client.ovpn"
Und dann: warum das ganze sudo Zeugs und Passwort Zeugs usw.?
Ich dachte: als User fhem auf der Linux Kommandozeile würde es funktionieren!? (also auch schon vorher/immer OHNE das ganze Zeugs)
Aber spätestens jetzt wo es ja offenbar als User fhem auf der Linux-Console geht: warum nicht wirklich einfach machen was wir geschrieben haben!!?
Viel Spaß noch, Joachim
Hallo Joachim,
ich fass es ja nicht!!! mit "sudo /usr/sbin/openvpn /etc/openvpn/client.ovpn" klappts aus der FHEM-Kommandozeile. Auch im Notify!
Da habe ich den Hinweis zuvor nicht richtig verstanden!!! Shame on me
Ihr seit echt meine Helden!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Jetzt muss ich nur noch das kappen der Verbindung hinbekommen. Dann wirds mal gebackupt und dann probier ichs mal noch ohne das ganze "sudo visudo" usw. Zeugs.
Also ich muss mich wirklich und ganz ernsthaft bedanken. Für die Geduld, fürs Hinweise geben, fürs NICHT gleich angemeckert werden (wie in vielen anderen Foren). Der Umgang hier ist
wirklich angenehm.
Ich werde dann nochmal final berichten
Viele Grüße aus dem Schwabenland
Benni
Benni als Schwabe bist Du doch sparsam?! Also spar Dir das sudo !!!
Wenn vpn sudo braucht hast Du es falsch gemacht!
Abend,
Wie gesagt, will's jetzt nochmal ,,sauber" nachvollziehen bzw. durchtesten. Mal schauen ob es dann immernoch klappt. Dafür liebe ich das proxmox!
Schönen Abend zusammen.
Grüße
Benni