Lokale Serverdienste im Mesh nicht erreichbar, nur über Wireguard

R

rs009

New member
Hallo,
ich habe ein Mesh Netzwerk, als Master dient eine Fritz!Box 7530, über LAN ist eine 7490 verbunden. An letzterer hängt über LAN ein kleiner Proxmox-Server. Ich habe das Problem, dass im WLAN eingewählte Geräte (im richtigen, nicht im „Gäste-Netz“), verbunden über den Master (7530), keine Verbindungen zu einigen Diensten auf dem Server aufbauen können – ein Ping wird aber immer beantwortet. Wenn ich zusätzlich eine VPN Verbindung zur Fritzbox aufbaue, während ich im WLAN bin, klappt es plötzlich! Das Problem betrifft den Paperless Webserver auf Port 8010, der als Docker Container auf einer Debian VM unter Proxmox läuft. Gleiches gilt für Immich, das auf Port 2283 derselben VM läuft. Auf einer anderen VM auf demselben Proxmox-Server läuft HomeAssistant, komischerweise funktioniert die Verbindung zur HomeAssistant Webseite hier auch ohne VPN.
Unter Proxmox oder den Virtuellen Maschinen sind keine Firwall-Regeln o.ä. konfiguriert.
Was kann ich hier ändern, damit das Routing im gesamten Mesh-WLAN korrekt funktioniert?

VG,
Roman
 
Da fehlen ein paar Informationen...
  • Auf welchem Router terminiert die VPN? Auf der 7530 oder 7490?
  • Ist die 7490 als IP-Client und MESH-Repeater konfiguriert? Oder spannt sie ein eigenes Netz?
Es wäre denkbar, dass Du eine Router-Kaskade gebaut hast. In diesem Fall werden die Geräte hinter der 7490 von den Geräten des 7530 isoliert.
 
Der VPN ist auf dem Master, also der 7530, eingerichtet.
Ja, die 7490 ist als IP-Client und Mesh Repeater konfiguriert, es ist ein gemeinsames Netz.
 
Hast Du mal verifiziert, ob in den betreffenden Fällen die aktive IPv & IPv6 Konfiguration der Clients sauber ist?!
Das könnte sich sowohl auf die IP-Adresse selbst als auch DNS beziehen.
Beim Aufbau einer VPN-Verbindung erhält das Endgeräte ja eine "neue" IP-Konfig.
Daher wäre die jeweilige, aktuelle IP-Konfiguration des Clients im Falle der genannten Probleme von Interesse.
 
An Clients habe ich es mit drei Android-Geräten und einem Notebook mit Linux Mint probiert, bei allen dasselbe Verhalten. Deswegen vermute ich das Problem eher nicht bei den Clients.

Beim Linux MINT diesem liefert ohne aktiven VPN "ip addr show":

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: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether f8:75:a4:6e:51:88 brd ff:ff:ff:ff:ff:ff
4: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 4c:1d:96:b4:d3:04 brd ff:ff:ff:ff:ff:ff
inet 192.168.205.49/24 brd 192.168.205.255 scope global dynamic noprefixroute wlp0s20f3
valid_lft 861256sec preferred_lft 861256sec
inet6 2003:e5:971c:9a00:e618:b8cc:6d72:6a75/64 scope global temporary dynamic
valid_lft 7011sec preferred_lft 1610sec
inet6 2003:e5:971c:9a00:1d1b:341f:8460:16c4/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 7011sec preferred_lft 1610sec
inet6 fd4c:689d:bbbb:0:2333:7cb0:a84a:a1b1/64 scope global temporary dynamic
valid_lft 7011sec preferred_lft 3411sec
inet6 fd4c:689d:bbbb:0:2c5d:a2e9:6678:7456/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 7011sec preferred_lft 3411sec
inet6 fe80::1253:8a0f:bb15:ae37/64 scope link noprefixroute
valid_lft forever preferred_lft forever
55: wwan0: <BROADCAST,MULTICAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether ea:48:08:72:e8:b8 brd ff:ff:ff:ff:ff:ff

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: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether f8:75:a4:6e:51:88 brd ff:ff:ff:ff:ff:ff
4: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 4c:1d:96:b4:d3:04 brd ff:ff:ff:ff:ff:ff
inet 192.168.205.49/24 brd 192.168.205.255 scope global dynamic noprefixroute wlp0s20f3
valid_lft 861256sec preferred_lft 861256sec
inet6 2003:e5:971c:9a00:e618:b8cc:6d72:6a75/64 scope global temporary dynamic
valid_lft 7011sec preferred_lft 1610sec
inet6 2003:e5:971c:9a00:1d1b:341f:8460:16c4/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 7011sec preferred_lft 1610sec
inet6 fd4c:689d:bbbb:0:2333:7cb0:a84a:a1b1/64 scope global temporary dynamic
valid_lft 7011sec preferred_lft 3411sec
inet6 fd4c:689d:bbbb:0:2c5d:a2e9:6678:7456/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 7011sec preferred_lft 3411sec
inet6 fe80::1253:8a0f:bb15:ae37/64 scope link noprefixroute
valid_lft forever preferred_lft forever
55: wwan0: <BROADCAST,MULTICAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether ea:48:08:72:e8:b8 brd ff:ff:ff:ff:ff:ff

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: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether f8:75:a4:6e:51:88 brd ff:ff:ff:ff:ff:ff
4: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 4c:1d:96:b4:d3:04 brd ff:ff:ff:ff:ff:ff
inet 192.168.205.49/24 brd 192.168.205.255 scope global dynamic noprefixroute wlp0s20f3
valid_lft 861256sec preferred_lft 861256sec
inet6 2003:e5:971c:9a00:e618:b8cc:6d72:6a75/64 scope global temporary dynamic
valid_lft 7011sec preferred_lft 1610sec
inet6 2003:e5:971c:9a00:1d1b:341f:8460:16c4/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 7011sec preferred_lft 1610sec
inet6 fd4c:689d:bbbb:0:2333:7cb0:a84a:a1b1/64 scope global temporary dynamic
valid_lft 7011sec preferred_lft 3411sec
inet6 fd4c:689d:bbbb:0:2c5d:a2e9:6678:7456/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 7011sec preferred_lft 3411sec
inet6 fe80::1253:8a0f:bb15:ae37/64 scope link noprefixroute
valid_lft forever preferred_lft forever
55: wwan0: <BROADCAST,MULTICAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether ea:48:08:72:e8:b8 brd ff:ff:ff:ff:ff:ff

Die Datei /etc/resolv.conf enthält:
nameserver 127.0.0.53
options edns0 trust-ad
search fritz.box


"ip route show" liefert
default via 192.168.205.1 dev wlp0s20f3 proto dhcp src 192.168.205.49 metric 600
192.168.205.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.205.49 metric 600
 
Moinsen,
wie versuchst du die fraglichen Dienste denn aufzurufen?
Per IP.Adresse und Port oder mit hostname/domainname: Port oder über einen reverseproxy?
Was genau gibst du denn in der Browserzeile ein, dass es nicht klappt?
Deine Angaben sind etwas verwirrend (und dreifach?). Du hast IPv4 und 6 aktiv?
Hast du (wenn du via VPN gehst) da auch IPv6 aktiv? Oder da nur IPv4?
 
Zuletzt bearbeitet von einem Moderator:
rs009 schrieb:
Die Datei /etc/resolv.conf enthält:
nameserver 127.0.0.53
options edns0 trust-ad
search fritz.box
Zum Vergrößern anklicken....

Dann läuft Dein System mit systemd ... in dem Fall bekommst Du die "echte" DNS-konfig über:
resolvectl status


the other schrieb:
Deine Angaben sind etwas verwirrend (und dreifach?). Du hast IPv4 und 6 aktiv?
Hast du (wenn du via VPN gehst) da auch IPv6 aktiv? Oder da nur IPv4?
Zum Vergrößern anklicken....
Ja, er hat IPv4 und IPv6 aktiv... der Client hat eine private IPv4 192.168.205.49, sowie 2 GA, 2 ULA und eine LLA.
 
the other schrieb:
Moinsen,
wie versuchst du die fraglichen Dienste denn aufzurufen?
Per IP.Adresse und Port oder mit hostname/domainname: Port oder über einen reverseproxy?
Was genau gibst du denn in der Browserzeile ein, dass es nicht klappt?
Deine Angaben sind etwas verwirrend (und dreifach?). Du hast IPv4 und 6 aktiv?
Hast du (wenn du via VPN gehst) da auch IPv6 aktiv? Oder da nur IPv4?
Zum Vergrößern anklicken....
Der Zugriff erfolgt direkt über die IP, also beispielsweise http://192.168.205.104:8010/ für Paperless. Im Fall von Immich habe ich auch die App installiert, die verhält sich genauso. Einen reverseproxy habe ich meines Wissens nach nicht. Die Standard-Einstellungen für IPv6 habe ich auf keinem der Geräte angefasst, nur IPv4 Adressen habe ich teilweise statisch vergeben oder in der Fritzbox 7530 fest zugewiesen. Handy und so weiter erhalten über DHCP von der 7530 eine IP zugeteilt.

Barungar schrieb:
Dann läuft Dein System mit systemd ... in dem Fall bekommst Du die "echte" DNS-konfig über:
resolvectl status



Ja, er hat IPv4 und IPv6 aktiv... der Client hat eine private IPv4 192.168.205.49, sowie 2 GA, 2 ULA und eine LLA.
Zum Vergrößern anklicken....
Danke! Der Befehl liefert:

Code: 
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (enp0s31f6)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 4 (wlp0s20f3)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.205.1
       DNS Servers: 192.168.205.1 fd4c:689d:bbbb:0:de39:6fff:fed8:cf36 2003:e5:971c:9a00:de39:6fff:fed8:cf36

Link 69 (wg_config)
    Current Scopes: DNS
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: fd4c:689d:bbbb:0:de39:6fff:fed8:cf36
       DNS Servers: 192.168.205.1 fd4c:689d:bbbb:0:de39:6fff:fed8:cf36
        DNS Domain: fritz.box

Link 71 (wwan0)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Inzwischen habe ich es auch noch mit einem Win11 Rechner und einem Chromebook ausprobiert, auch da habe ich keinen Zugriff ohne VPN (auf diesen Geräten nicht eingerichtet).

Da das Verhalten mit den verschiedenen Clients gleich ist, sehe ich drei mögliche Ursachen
a) Mesh-Konfiguration
b) Proxmox
c) Docker
Habt ihr Tipps, wie ich die Ursache eingrenzen kann?
 
Da Du direkt über IP zugreifst können wir das ganze DNS-Thema aus der Gleichung streichen.

Funktioniert denn ein PING auf die IP-Adresse z.B. des Paperless?

Macht es einen Unterschied in welchem WLAN-Bereich Du bist? Also das Mint-Laptop nutzt WLAN (wlp0s20f3 klingt nach WLAN), geht es nicht egal, ob Du an der 7490 oder 7530 assoziiert bist? Oder beschränken sich die Probleme auf einen AccessPoint?
 
Stimmt, danke!
Ja, ping 192.168.205.104 geht immer, auch wenn die Seiten nicht erreichbar sind

Gerade nochmal ausprobiert: Es macht keinen Unterschied über welche der beiden Boxen das Notebook oder ein Handy im WLAN hängt. Wenn es einen Erkenntnisgewinn gibt, kann ich es auch über LAN an beiden Boxen versuchen, WLAN ist aber die normale Nutzung.
 
Klar, schaden kann es nicht, wenn Du das Laptop (dürfte am einfachsten sein) mal an das Ethernet hängst.
Ich habe auch schon erlebt, dass es per LAN Kabel denn plötzlich ging und über WLAN nicht.

Darüberhinaus ist es interessant, dass der PING immer geht, selbst dann wenn die Webseite nicht geht.
Also kann es schonmal nicht auf Layer 1, Layer 2 und Layer 3 sein, die unterscheiden nämlich nicht, ob es ICMP (PING) oder TCP (Web) ist.
 
Wenn ich es richtig lese geht die VM wo HA drauf läuft und alles was in der anderen VM läuft geht nur per VPN. Klingt für mich irgendwie als wäre die Ursache eine Einstellung zur VM.
 
Spielebernd schrieb:
Wenn ich es richtig lese geht die VM wo HA drauf läuft und alles was in der anderen VM läuft geht nur per VPN. Klingt für mich irgendwie als wäre die Ursache eine Einstellung zur VM.
Zum Vergrößern anklicken....
In Proxmox sind für beide VMs keine Firewallregeln hinterlegt - unter der Rubrik Firewall steht jeweils "No Firewall rule configured here", Aber beim nochmaligen Schauen habe ich einen Unterschied gefunden: Unter "Hardware" war bei der Netzwerkkarte im Fall der Debian VM Firewall=1 gesetzt. Das war ein Schritt nach vorne, auf dem Notebook funktioniert es jetzt ohne Wireguard VPN! Auf dem Handy, das im selben WLAN eingewählt ist, ist aber die Verbindung ohne VPN weiter nicht ohne VPN möglich.
Insgesamt verstehe ich immer noch nicht, was hier los ist.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Neueste Beiträge

Letzte Anleitungen

Statistik des Forums

Themen
7.793
Beiträge
76.410
Mitglieder
8.418
Neuestes Mitglied
Joerg.Osterkamp

Teilen

Zurück
Oben