OpenVPN-Client und MQTT

bartman121 · 12 Mai 2023, 19:43:40

Hallo,

ich ärgere mich derzeit mit einem Problem, wo ich ein wenig ratlos bin.

Situation;
Ein server im lokalen Netz 192.168.2.250
Der Server baut zusätzlich eine openvpn-verbinding als Client zu einem Server auf und bekommt dort eine fixe IP 10.8.0.75

Der Zugriff aus dem Lan funktioniert sowohl per 192.168.2.250
Und 10.8.0.75 (über Routes)

Per SSH, http usw komme ich über beide ips zum Ziel.

Aber MQTT funktioniert nur per IP 10.8.0.75

Der mqtt-server lauscht auf allen ips, also 0.0.0.0:1883

Habt ihr irgendeine Idee was hier das Problem sein kann?

Evtl. Ist es noch wichtig:
Der openVPN-Server steht im gleichen LAN, aktuell ist es ein Testaufbau. Der mqtt-server soll an einen entfernten Standort und über VPN möchte ich das maintainen.

Ich habe exakt den gleichen Aufbau schonmal gemacht (allerdings echtes Debian, kein raspian). Bei dem Debian-Server hatte ich die Probleme nicht.
Grüße

Andreas

bartman121 · 12 Mai 2023, 20:28:00

ich hacke mal ein paar weitere Infos rein:
nmap auf den "Raspberrry":

Code Auswählen

andreas@srvhelper:~$ nmap 192.168.2.250 -p1883
Starting Nmap 7.80 ( https://nmap.org ) at 2023-05-12 20:20 CEST
Nmap scan report for srvwdf.localdomain (192.168.2.250)
Host is up (0.097s latency).

PORT     STATE SERVICE
1883/tcp open  mqtt

Nmap done: 1 IP address (1 host up) scanned in 0.18 seconds

und über seine VPN-Adresse:

Code Auswählen

andreas@srvhelper:~$ nmap 10.8.0.75 -p1883
Starting Nmap 7.80 ( https://nmap.org ) at 2023-05-12 20:21 CEST
Nmap scan report for 10.8.0.75
Host is up (0.0055s latency).

PORT     STATE SERVICE
1883/tcp open  mqtt

Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds

Der Port wird auf beiden IPs als offen erkannt, d.h. der MQTT-Server müsste eigentlich erreichbar sein.

Hier mal die Interfaces des Raspi:

Code Auswählen

andreas@srvwdf:~ $ ifconfig
eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether b8:27:eb:8c:75:fa  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 2483  bytes 1958151 (1.8 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2483  bytes 1958151 (1.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.8.0.75  netmask 255.255.255.0  destination 10.8.0.75
        inet6 fe80::d73d:5e0b:38e1:a76a  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
        RX packets 32098  bytes 2479407 (2.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 30594  bytes 3518077 (3.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.2.250  netmask 255.255.255.0  broadcast 192.168.2.255
        inet6 fe80::dbb4:3bcd:ca24:6b2f  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:d9:20:af  txqueuelen 1000  (Ethernet)
        RX packets 188663  bytes 17154287 (16.3 MiB)
        RX errors 0  dropped 1  overruns 0  frame 0
        TX packets 105362  bytes 14480435 (13.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Irgendwo habe ich gelesen, dass es möglich wäre, dass die Verbindung nicht klappt, weil der der MQTT-Server eine Art Handshake durchführen will (sorry, bin da nur laie) und seine Rückantwort ggfs. über VPN/TUN senden will, wegen einer geringeren Metric. Aber ich bin weißgott kein Netzwerk-Experte.

Hier mal die ovpn-Client-Datei:

Code Auswählen

root@srvwdf:/home/andreas# cat /root/srvwdf.ovpn
client
dev tun
proto udp
remote ovpn.tld 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
ignore-unknown-option block-outside-dns
block-outside-dns
verb 3

[...]KEYS entfernt[...]

Hier die Open-VPN-Server-Conf des Server:

Code Auswählen

root@srvopenvpn:/etc/openvpn/server# cat server.conf
local 192.168.2.123
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt tc.key
topology subnet
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 192.168.2.1"
push "dhcp-option ADAPTER_DOMAIN_SUFFIX localdomain"
push "dhcp-option DOMAIN-SEARCH localdomain"
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
verb 3
crl-verify crl.pem
explicit-exit-notify
client-config-dir ccd

Hier mal noch die Routing-Tabellen auf dem Raspi:

Code Auswählen

andreas@srvwdf:~ $ netstat -r
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.8.0.1        128.0.0.0       UG        0 0          0 tun0
default         unifi.localdoma 0.0.0.0         UG        0 0          0 wlan0
10.8.0.0        0.0.0.0         255.255.255.0   U         0 0          0 tun0
p5b313599.dip0. unifi.localdoma 255.255.255.255 UGH       0 0          0 wlan0
128.0.0.0       10.8.0.1        128.0.0.0       UG        0 0          0 tun0
192.168.2.0     0.0.0.0         255.255.255.0   U         0 0          0 wlan0

Vielleicht hilft das ja....

Grüße

Andreas

rudolfkoenig · 12 Mai 2023, 21:45:05

ZitatIrgendwo habe ich gelesen, dass es möglich wäre, dass die Verbindung nicht klappt, weil der der MQTT-Server eine Art Handshake durchführen will (sorry, bin da nur laie) und seine Rückantwort ggfs. über VPN/TUN senden will, wegen einer geringeren Metric

Routing ist keine Userlevel-Aufgabe, das macht der Kernel.
Je nach Protokoll unterschiedliche Wege gehoert fuer mich zu "Hohe Kunst des Routings", und unwahrscheinlich, dass es aus Versehen so konfiguriert wurde.

Steht was in FHEM-Log, notfalls mit "attr global verbose 5"?
Was meldet "sudo tcpdump -i wlan0 port 1883" bei einem MQTT-Kontaktversuch?

bartman121 · 12 Mai 2023, 22:00:06

Hallo Rudi,

im Log taucht aus meiner Sicht auch bei verbose 5 am MQTT2-Server auch an global nichts brauchbares auf, aber ich kriege bei verbose 5 auch andere Meldungen, weil ich über einen reverse Proxy auf das FHEM zugreife, daher würde ich das nicht unterschreiben wollen, dass im Log nichts brauchbares steht.

Hinsichtlich TCPDUMP:

Code Auswählen

andreas@srvwdf:~ $ sudo tcpdump -i wlan0 port 1883
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
21:55:44.077570 IP wled-WLED.21724 > srvwdf.localdomain.1883: Flags [S], seq 855                                                                                                                                                             6, win 5840, options [mss 1460], length 0
21:55:45.025861 IP wled-WLED.21724 > srvwdf.localdomain.1883: Flags [S], seq 855                                                                                                                                                             6, win 5840, options [mss 1460], length 0
21:55:46.049943 IP wled-WLED.21724 > srvwdf.localdomain.1883: Flags [S], seq 855                                                                                                                                                             6, win 5840, options [mss 1460], length 0
21:55:47.052741 IP wled-WLED.21724 > srvwdf.localdomain.1883: Flags [S], seq 855                                                                                                                                                             6, win 5840, options [mss 1460], length 0
21:55:48.102563 IP wled-WLED.21724 > srvwdf.localdomain.1883: Flags [S], seq 855                                                                                                                                                             6, win 5840, options [mss 1460], length 0
21:55:49.066268 IP wled-WLED.21724 > srvwdf.localdomain.1883: Flags [S], seq 855                                                                                                                                                             6, win 5840, options [mss 1460], length 0
21:55:50.163134 IP wled-WLED.21724 > srvwdf.localdomain.1883: Flags [S], seq 855                                                                                                                                                             6, win 5840, options [mss 1460], length 0
21:55:55.661052 IP wled-WLED.2077 > srvwdf.localdomain.1883: Flags [S], seq 6512                                                                                                                                                             , win 5840, options [mss 1460], length 0
21:55:56.590442 IP wled-WLED.2077 > srvwdf.localdomain.1883: Flags [S], seq 6512                                                                                                                                                             , win 5840, options [mss 1460], length 0
21:55:56.590828 IP wled-WLED.19845 > srvwdf.localdomain.1883: Flags [S], seq 652                                                                                                                                                             2, win 5840, options [mss 1460], length 0
21:55:57.637797 IP wled-WLED.19845 > srvwdf.localdomain.1883: Flags [S], seq 652                                                                                                                                                             2, win 5840, options [mss 1460], length 0
21:55:57.638410 IP wled-WLED.2077 > srvwdf.localdomain.1883: Flags [S], seq 6512                                                                                                                                                             , win 5840, options [mss 1460], length 0
21:55:58.716712 IP wled-WLED.19845 > srvwdf.localdomain.1883: Flags [S], seq 652                                                                                                                                                             2, win 5840, options [mss 1460], length 0
21:55:58.717023 IP wled-WLED.2077 > srvwdf.localdomain.1883: Flags [S], seq 6512                                                                                                                                                             , win 5840, options [mss 1460], length 0
21:55:59.700996 IP wled-WLED.19845 > srvwdf.localdomain.1883: Flags [S], seq 652                                                                                                                                                             2, win 5840, options [mss 1460], length 0
21:55:59.701602 IP wled-WLED.2077 > srvwdf.localdomain.1883: Flags [S], seq 6512                                                                                                                                                             , win 5840, options [mss 1460], length 0
21:56:00.896612 IP wled-WLED.19845 > srvwdf.localdomain.1883: Flags [S], seq 652                                                                                                                                                             2, win 5840, options [mss 1460], length 0
21:56:00.897277 IP wled-WLED.2077 > srvwdf.localdomain.1883: Flags [S], seq 6512                                                                                                                                                             , win 5840, options [mss 1460], length 0
21:56:01.925500 IP wled-WLED.19845 > srvwdf.localdomain.1883: Flags [S], seq 652                                                                                                                                                             2, win 5840, options [mss 1460], length 0
21:56:01.925898 IP wled-WLED.2077 > srvwdf.localdomain.1883: Flags [S], seq 6512                                                                                                                                                             , win 5840, options [mss 1460], length 0
21:56:02.875113 IP wled-WLED.19845 > srvwdf.localdomain.1883: Flags [S], seq 652                                                                                                                                                             2, win 5840, options [mss 1460], length 0
21:56:25.171079 IP wled-WLED.10586 > srvwdf.localdomain.1883: Flags [S], seq 6930, win 5840, options [mss 1460], length 0
21:56:25.931483 IP wled-WLED.10586 > srvwdf.localdomain.1883: Flags [S], seq 6930, win 5840, options [mss 1460], length 0
21:56:27.015786 IP wled-WLED.10586 > srvwdf.localdomain.1883: Flags [S], seq 6930, win 5840, options [mss 1460], length 0
21:56:28.021784 IP wled-WLED.10586 > srvwdf.localdomain.1883: Flags [S], seq 6930, win 5840, options [mss 1460], length 0
21:56:29.059002 IP wled-WLED.10586 > srvwdf.localdomain.1883: Flags [S], seq 6930, win 5840, options [mss 1460], length 0
21:56:30.027147 IP wled-WLED.10586 > srvwdf.localdomain.1883: Flags [S], seq 6930, win 5840, options [mss 1460], length 0
21:56:31.033184 IP wled-WLED.10586 > srvwdf.localdomain.1883: Flags [S], seq 6930, win 5840, options [mss 1460], length 0

also da scheint ein WLED-Geräte die Verbindung aufbauen zu wollen, aber mehr sehe ich da nicht....

Damit hier kein falscher Eindruck entsteht, das Problem tritt sowohl bei mqtt2-server, als auch bei einem mosqiitto-server. Das Problem dürfte kein fhem-problem sein

rudolfkoenig · 12 Mai 2023, 22:17:01

Normalerweise sieht man auch das Antwort-Paket auf dem gleichen Port.
Scheint wirklich was mit dem Routing nicht in Ordnung zu sein.

So im Nachhinein finde ich die Routing-Tabelle komisch.
Insb. die Zeile mit 0.0.0.0 verstoert mich, ich wuerde es testweise entfernen.
Die Zeile mit 128.0.0.0 finde ich auch merkwuerdig.
Und bevor alles sauber laeuft, wuerde ich DNS ueber OpenVPN abschalten.

bartman121 · 13 Mai 2023, 06:13:04

Hallo Rudi,

du bist ein Traum

Also ich habe jetzt einfach die Route mit Destination 128.0.0.0 gelöscht, danach funktionierte der Verbindungsaufbau per MQTT über beide IPs.

Code Auswählen

andreas@srvwdf:~ $ netstat -r
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
[...]
128.0.0.0       10.8.0.1        128.0.0.0       UG        0 0          0 tun0
[...]

Jetzt gilt es nur herauszufinden woher diese Route kommt und wofür sie gedacht ist.

Auf dem angesprochen Debian-Rechner der sich an einem entfernten Standort befindet ist die Route auch vorhanden, aber dort funktioniert die MQTT-Verbindung über die lokale IP.

Daher wären jetzt die Netzwerk-Experten gefragt.

Hinsichtlich des DNS, diesen benötige ich, denn das VPN wird auch verwendet wenn ich mich von außen einwähle, dann möchte ich natürlich auch meine Rechnet im LAN erreichen, natürlich mit hostname und nicht nur per IP.

Grüße

Andreas

bartman121 · 19 Mai 2023, 08:01:59

Hierzu noch die Rückmeldung, dass der Raspi jetzt in den entfernten Standort umgezogen ist. Dort funktioniert die MQTT-Verbindung über beide IPs.

Die Ursache war also mein "komisches" Testszenario mit LAN-Verbindung und OpenVPN-Verbindung ins eigene LAN.