19
Völlig "transparenter" VPN
Hallo zusammen,
ich habe einen etwas speziellen Fall. Meine Ausgangslage:
Habe hier ein (Heim-)Netzwerk stehen. Angebunden per FB 7490, zwei Debian Server vorhanden.
An einem anderen Standort steht ein Photovoltaik Wechselrichter. Dieser soll ausgelesen werden, die Daten sollen aufbereitet werden und per Weboberfläche zur Verfügung gestellt.
Aber das soll hier garnicht Thema sein. Am Standort des Wechselrichters steht mir ein fremder Internetzugang zur Verfügung. Über diesen soll ein VPN-Tunnel zu mir nachhause aufgebaut werden.
Bedingung: Über dieses Fremdnetzwerk soll der VPN-Tunnel laufen. Weitergehende Verbindungen von meinem Netzwerk in das Fremde, oder umgekehrt sind zu unterbinden. Eine Portöffnung im fremden Netz ist weder möglich noch erwünscht.
Neben dem Wechselrichter soll ein ARM-Board mit Debian hängen, welches sich per W-Lan ins fremde Netz einhängt. Über seine Lan-Schnittstelle soll es mein Heimnetz an den Wechselrichter ausgeben. Ausserdem loggt es die Produktion des Wechselrichters.
Soweit so gut, der eigentliche Knackpunkt:
Ist es denkbar, den VPN so zu konfigurieren, dass er völlig "transparent" arbeitet, quasi wie ein sehr langes Ethernetkabel? Optimal wäre es wenn der Wechselrichter und das Board selbst (bzw. nur das virtuelle Netzwerkinterface an dem die Logginanwendung hängt) mit IP-Adressen aus dem Adressbereich der Fritzbox arbeiten, und in deren Weboberfläche sichtbar sind.
Geht das, oder muss ich umdenken und mit getrennten Netzen arbeiten?
Vielen Dank im Voraus,
Grüße,
PVNiederbayern
ich habe einen etwas speziellen Fall. Meine Ausgangslage:
Habe hier ein (Heim-)Netzwerk stehen. Angebunden per FB 7490, zwei Debian Server vorhanden.
An einem anderen Standort steht ein Photovoltaik Wechselrichter. Dieser soll ausgelesen werden, die Daten sollen aufbereitet werden und per Weboberfläche zur Verfügung gestellt.
Aber das soll hier garnicht Thema sein. Am Standort des Wechselrichters steht mir ein fremder Internetzugang zur Verfügung. Über diesen soll ein VPN-Tunnel zu mir nachhause aufgebaut werden.
Bedingung: Über dieses Fremdnetzwerk soll der VPN-Tunnel laufen. Weitergehende Verbindungen von meinem Netzwerk in das Fremde, oder umgekehrt sind zu unterbinden. Eine Portöffnung im fremden Netz ist weder möglich noch erwünscht.
Neben dem Wechselrichter soll ein ARM-Board mit Debian hängen, welches sich per W-Lan ins fremde Netz einhängt. Über seine Lan-Schnittstelle soll es mein Heimnetz an den Wechselrichter ausgeben. Ausserdem loggt es die Produktion des Wechselrichters.
Soweit so gut, der eigentliche Knackpunkt:
Ist es denkbar, den VPN so zu konfigurieren, dass er völlig "transparent" arbeitet, quasi wie ein sehr langes Ethernetkabel? Optimal wäre es wenn der Wechselrichter und das Board selbst (bzw. nur das virtuelle Netzwerkinterface an dem die Logginanwendung hängt) mit IP-Adressen aus dem Adressbereich der Fritzbox arbeiten, und in deren Weboberfläche sichtbar sind.
Geht das, oder muss ich umdenken und mit getrennten Netzen arbeiten?
Vielen Dank im Voraus,
Grüße,
PVNiederbayern
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 561924
Url: https://administrator.de/contentid/561924
Printed on: April 20, 2024 at 13:04 o'clock
19 Comments
Latest comment
Das ist mit getrennten IP Bereichen machbar, aber nicht ohne Kenntnisse. Ohne Portöffnung keine Kommunikation. Du musst jemanden damit beauftragen, der es routiniert und sicher bauen kann.
Durchaus machbar, das stichwort dazu dürfte Layer 2 VPN sein. Aber was z.B. heißt keine Portöffnungen erwünscht? Ich hoffe das gilt nur für eingehende Verbindungen sonst wird es schwer.
den VPN so zu konfigurieren, dass er völlig "transparent" arbeitet
Wie die Vorredner schon richtig gesagt haben macht man dann Bridging über die Tunnel Interfaces. Das erzwingt aber das dein Heimnetz und das des Wechselrichters im gleichen IP Netz liegen. Ein großer Nachteil !Ein weiterer noch größerer ist die Tatsache das dann auch von beiden lokalen Netzsegmenten der gesamte Broad- und Multicast Traffic den VPN Tunnel belastet und massiv dessen Performance einschränkt.
Kein Netzwerker macht normalerweise ein dummes, flaches Bridging über einen VPN Tunnel aus eben genau diesen gravierenden Nachteilen. Es gilt die goldene Netzwerker Regel: "Route wherever you can, bridge where you must !"
Keine gute Idee also die du besser nochmal überdenken solltest. Man kann dir hier nur dringenst davon abraten.
Der Rest ist dann eine Lachnummer: OpenVPN mit apt install openvpn auf den beiden Debian Servern installieren, Konfig aufsetzen und einen VPN Site to Site Tunnel etablieren. Fertisch...
Alternativ kannst du auch StrongSwan nehmen. OpenVPN ist aber durch seinen SSL Unterbau einfacher über NAT Router und Firewall zu bringen.
Das ist in 15 Minuten erledigt und das VPN dann online.
Eine OpenVPN Konfig findest du hier:
Merkzettel: VPN Installation mit OpenVPN
Bzw. zu einer Site 2 Site Kopplung detailliert hier:
OpenVPN - Erreiche Netzwerk hinter Client nicht
1
Hi pvniederbayern,
Du solltest auf einem Deiner Debian-Server einen OpenVPN-Server einrichten. Auf deiner Fritte ein Portforwarding für den Tunnelport (z.B. 1194) machen.
Dein Debian des ARM-Boards hat über das Fremdnetz Internetanschluss, richtig? Dort richtest Du einen OpenVPN-Client ein, dessen Config auf die öffentliche IP bzw. Dyn-DNS Deines Home-Anschlusses verweist und gut iss es.
Du brauchst am Standort des OpenVPN-Clients kein Portforwarding.
Der Tunnel läuft dann zwischen Deinem Home-Server und Deinem ARM-Board und es sollten, so Du Layer 3 mit dem TUN-Device nutzt, auch unterschiedliche IP-Netze zwischen Home und Remote sein.
Gruß orcape
Du solltest auf einem Deiner Debian-Server einen OpenVPN-Server einrichten. Auf deiner Fritte ein Portforwarding für den Tunnelport (z.B. 1194) machen.
Dein Debian des ARM-Boards hat über das Fremdnetz Internetanschluss, richtig? Dort richtest Du einen OpenVPN-Client ein, dessen Config auf die öffentliche IP bzw. Dyn-DNS Deines Home-Anschlusses verweist und gut iss es.
Du brauchst am Standort des OpenVPN-Clients kein Portforwarding.
Der Tunnel läuft dann zwischen Deinem Home-Server und Deinem ARM-Board und es sollten, so Du Layer 3 mit dem TUN-Device nutzt, auch unterschiedliche IP-Netze zwischen Home und Remote sein.
Gruß orcape
Grüße,
ich möchte an dieser Stelle auf ZeroTier als Alternative hinweisen, einfach weil ich im privaten Bereich damit gute Erfahrungen gemacht habe.
ZeroTier baut mit Hilfe eines zentralen Servers der für die Vermittlung zuständig ist eine P2P VPN Verbindung auf. Du brauchst also kein ProtForwarding und kein DynDNS, egal auf welcher Seite. Die Kommunikation selbst läuft von Client zu Client verschlüsselt.
Man kann darüber auch ein Bridging machen wenn man dies möchte, dabei hast du dann zusätzlich die Möglichkeit diverse Filter zu setzen - z.B. um dennoch Broadcasts zu blocken und zu verhindern dass jemand am externen Ende auf dein LAN Zugriff bekommt.
Die gesamte Konfiguration des VPN läuft dabei über ein Webinterface des zentralen Servers (den man selbst hosten kann, wenn man möchte, oder man nutzt den den ZeroTier kostenfrei bereitstellt), man muss also kaum Angst haben sich bei einem kleinen Tippfehler von der Gegenseite abgeschnitten zu haben.
Leider hab ich keine ganz konkrete Anleitung wie du dein Netz damit im angesprochenen Fall einrichten würdest... Aber ich empfehle es einfach mal anzuschauen.
ich möchte an dieser Stelle auf ZeroTier als Alternative hinweisen, einfach weil ich im privaten Bereich damit gute Erfahrungen gemacht habe.
ZeroTier baut mit Hilfe eines zentralen Servers der für die Vermittlung zuständig ist eine P2P VPN Verbindung auf. Du brauchst also kein ProtForwarding und kein DynDNS, egal auf welcher Seite. Die Kommunikation selbst läuft von Client zu Client verschlüsselt.
Man kann darüber auch ein Bridging machen wenn man dies möchte, dabei hast du dann zusätzlich die Möglichkeit diverse Filter zu setzen - z.B. um dennoch Broadcasts zu blocken und zu verhindern dass jemand am externen Ende auf dein LAN Zugriff bekommt.
Die gesamte Konfiguration des VPN läuft dabei über ein Webinterface des zentralen Servers (den man selbst hosten kann, wenn man möchte, oder man nutzt den den ZeroTier kostenfrei bereitstellt), man muss also kaum Angst haben sich bei einem kleinen Tippfehler von der Gegenseite abgeschnitten zu haben.
Leider hab ich keine ganz konkrete Anleitung wie du dein Netz damit im angesprochenen Fall einrichten würdest... Aber ich empfehle es einfach mal anzuschauen.
Deine FritzBox muss über eine IP von außen erreichbar sein. Das funktioniert gut mit einem MyFRITZ-Konto, denn der DNS-Name ist kryptisch und nicht leicht zu erraten.
Dann wird über die FritzBox eine VPN-Definition erstellt - Anleitung: https://avm.de/service/fritzbox/fritzbox-7490/wissensdatenbank/publicati ...
Jetzt kannst du dich von überall auf der Erde auf deine FritzBox und die Gräte dahinter per VPN anmelden ohne dass im Netz, in dem du die Anmeldung durchführst, irgendeine Freischaltung erforderlich ist. Diesen Zugang kannst du auch von offenen Netzen verwenden, da deine FritzBox dann der Zugang zum weltweiten Internet ist.
Ich habe diese seit ein paar Jahren im Einsatz.
Dann wird über die FritzBox eine VPN-Definition erstellt - Anleitung: https://avm.de/service/fritzbox/fritzbox-7490/wissensdatenbank/publicati ...
Jetzt kannst du dich von überall auf der Erde auf deine FritzBox und die Gräte dahinter per VPN anmelden ohne dass im Netz, in dem du die Anmeldung durchführst, irgendeine Freischaltung erforderlich ist. Diesen Zugang kannst du auch von offenen Netzen verwenden, da deine FritzBox dann der Zugang zum weltweiten Internet ist.
Ich habe diese seit ein paar Jahren im Einsatz.
Die FritzBox kann kein Bridging im Tunnel !!!
Der VPN Server auf der FritzBox kann einzig nur routen (sinnvollerweise !) und supportet keine Layer 2 Kopplung (Bridging) !
Zudem hat der TO ja auch gar keine FritzBox in seinem VPN Netz. Also mal den Thread wirklich durchlesen und verstehen. Das hilft hier wirklich.
Die Antwort ging also technisch am Thema des TO völlig vorbei !
Der VPN Server auf der FritzBox kann einzig nur routen (sinnvollerweise !) und supportet keine Layer 2 Kopplung (Bridging) !
Zudem hat der TO ja auch gar keine FritzBox in seinem VPN Netz. Also mal den Thread wirklich durchlesen und verstehen. Das hilft hier wirklich.
Die Antwort ging also technisch am Thema des TO völlig vorbei !
Zu Hause hat er eine Fritzbox, das ändert aber nichts an der Tatsache, das er Remote keine hat, bzw. diese dort, wenn vorhanden wäre, gar nicht einrichten kann/darf.
Deshalb ja StrongSwan auf dem Debian, damit ist das VPN zur heimischen FB dann in 10 Minuten erledigt !
Aber das fehlende Feedback vom TO zeigt ja das er vermutlich so oder so das Interesse an einer zielführenden Lösung verloren hat.
Kann man dann nur hoffen das es dann noch für ein
How can I mark a post as solved?
reicht ?!
Aber das fehlende Feedback vom TO zeigt ja das er vermutlich so oder so das Interesse an einer zielführenden Lösung verloren hat.
Kann man dann nur hoffen das es dann noch für ein
How can I mark a post as solved?
reicht ?!
Hallo und erstmal vielen Dank,
nein ich habe keineswegs das Interesse verloren. Bin leider die letzten Tage nicht
dazu gekommen zu antworten, sorry. Eure Ausführungen zum Bridging oder Routing waren genau das Stichwort das ich brauchte um mich selbst zu informieren. Ich habe die Sache jetzt in Grundzügen verstanden und einen Ansatzpunkt zum Weitermachen.
Möglicherweise werden aber im Laufe des Setups aber doch noch Fragen aufkommen, ist es ok wenn ich den Thread vorerst noch nicht auf gelöst setze?
Viele Grüße,
PVNiederbayern
nein ich habe keineswegs das Interesse verloren. Bin leider die letzten Tage nicht
dazu gekommen zu antworten, sorry. Eure Ausführungen zum Bridging oder Routing waren genau das Stichwort das ich brauchte um mich selbst zu informieren. Ich habe die Sache jetzt in Grundzügen verstanden und einen Ansatzpunkt zum Weitermachen.
Möglicherweise werden aber im Laufe des Setups aber doch noch Fragen aufkommen, ist es ok wenn ich den Thread vorerst noch nicht auf gelöst setze?
Viele Grüße,
PVNiederbayern
Ich habe die Sache jetzt in Grundzügen verstanden und einen Ansatzpunkt zum Weitermachen.
👍im Laufe des Setups aber doch noch Fragen aufkommen, ist es ok wenn ich den Thread vorerst noch nicht auf gelöst setze?
Na klar !!Dann Fragen einfach hier posten !
Viel Erfolg mit dem (Routing) Setup !
Hallo zusammen,
bin jetzt einen Schritt weiter.
Im Heimnetz steht ein Raspberry Pi als OpenVPN-Server. Eine Portweiterleitung (UDP 1194) erlaubt den Zugriff von extern.
Ein Orange Pi ist als OpenVPN Client konfiguriert, und kann aus einem fremden Netzwerk (angebunden via WIFI-Stick) heraus einen gerouteten Tunnel aufbauen, der als tun0 sichtbar ist. Eine statische Route in der Fritzbox des Servernetzes erlaubt, den Orange Pi aus dem Heimnetz anzupingen.
Vom Orangepi ins Servernetz pingen ist noch nicht möglich, aber das denke ich krieg ich hin.
Nun die Frage: Was muss ich tun, damit der Orangepi den VPN-Tunnel auf eth0 zur Verfügung stellt? Ich habe versucht eth0 und tun0 mittels br0 zu bridgen, aber tun0 ließ sich nicht hinzufügen. Ich habe ein bisschen recherchiert und bin zur Erkenntnis gekommen, dass ich das wohl mittels iptables lösen muss.
(Habe in dieser Anleitung folgendes gefunden:
Ich weiß aber weder, auf was sich die angegebene IP-Adresse bezieht, noch ob das für mich überhaupt zielführend ist.)
Da kommt sogar schon die nächste Frage auf: Die meisten Anleitungen gehen von zwei bestehenden Netzen aus, ich möchte den Pi aber nicht als VPN-Gateway für das bestehende Netz nutzen, sondern nur ein kleines Netz für den Pi selbst und den Wechselrichter (und evtl. gelegentlich einen PC zu Wartungsarbeiten) aufspannen. Brauche ich dazu ein drittes (bzw. wenn man das fremde Netz mitrechnet viertes) Subnet, oder kann der Wechselrichter mit im VPN-Subnet liegen? Kann der Pi selbst den Tunnel auch noch nutzen, wenn ich diesen auf eth0 ausgebe?
Vielen Dank schonmal
Grüße
PVNiederbayern
bin jetzt einen Schritt weiter.
Im Heimnetz steht ein Raspberry Pi als OpenVPN-Server. Eine Portweiterleitung (UDP 1194) erlaubt den Zugriff von extern.
Ein Orange Pi ist als OpenVPN Client konfiguriert, und kann aus einem fremden Netzwerk (angebunden via WIFI-Stick) heraus einen gerouteten Tunnel aufbauen, der als tun0 sichtbar ist. Eine statische Route in der Fritzbox des Servernetzes erlaubt, den Orange Pi aus dem Heimnetz anzupingen.
Vom Orangepi ins Servernetz pingen ist noch nicht möglich, aber das denke ich krieg ich hin.
Nun die Frage: Was muss ich tun, damit der Orangepi den VPN-Tunnel auf eth0 zur Verfügung stellt? Ich habe versucht eth0 und tun0 mittels br0 zu bridgen, aber tun0 ließ sich nicht hinzufügen. Ich habe ein bisschen recherchiert und bin zur Erkenntnis gekommen, dass ich das wohl mittels iptables lösen muss.
(Habe in dieser Anleitung folgendes gefunden:
sh -c ‚echo 1 > /proc/sys/net/ipv4/ip_forward‘
iptables -A FORWARD -o tun0 -i eth0 -s 192.168.1.0/24 -m conntrack –ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack –ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A POSTROUTING -t nat -j MASQUERADE
iptables-save | tee /etc/iptables.savIch weiß aber weder, auf was sich die angegebene IP-Adresse bezieht, noch ob das für mich überhaupt zielführend ist.)
Da kommt sogar schon die nächste Frage auf: Die meisten Anleitungen gehen von zwei bestehenden Netzen aus, ich möchte den Pi aber nicht als VPN-Gateway für das bestehende Netz nutzen, sondern nur ein kleines Netz für den Pi selbst und den Wechselrichter (und evtl. gelegentlich einen PC zu Wartungsarbeiten) aufspannen. Brauche ich dazu ein drittes (bzw. wenn man das fremde Netz mitrechnet viertes) Subnet, oder kann der Wechselrichter mit im VPN-Subnet liegen? Kann der Pi selbst den Tunnel auch noch nutzen, wenn ich diesen auf eth0 ausgebe?
Vielen Dank schonmal
Grüße
PVNiederbayern
Eine statische Route in der Fritzbox des Servernetzes erlaubt, den Orange Pi aus dem Heimnetz anzupingen.
Vorbildliche Standard Konfig wie sie ja auch hier beschrieben ist:Merkzettel: VPN Installation mit OpenVPN
Vom Orangepi ins Servernetz pingen ist noch nicht möglich, aber das denke ich krieg ich hin.
Und da ist genau wie vermutet das sinnfreie Masquerading (IP Adress Translation) für verantwortlich !! Siehe Konfig oben.Damit hast du eine NAT Firewall etabliert die kein transparentes Routing beider IP Netze erlaubt. Du hast also einen Routing technische Einbahnstrasse wie sie bei NAT immer üblich ist. Guckst du dazu auch HIER.
Was muss ich tun, damit der Orangepi den VPN-Tunnel auf eth0 zur Verfügung stellt?
Zuallererst mal die richtige Client Konfig implementieren. Sie hier:OpenVPN - Erreiche Netzwerk hinter Client nicht
Und das unsägliche Masquerading deaktivieren im Tunnel. Im Grunde sind die iptables dafür bei lokalen VPNs auf nicht öffentlichen Geräten eher hinderlich als sinnvoll.
Das normale Armbian Image (Debian) auf dem Orange Pi nutzt diese im Default auch gar nicht, deshalb solltest du diesen Masquerading Unsinn auch komplett weglassen.
Damit wird das dann auch sofort funktionieren.
Übrigens nebenbei hat der Orange Pi ein onboard WLAN Interface ! Jedenfalls der Zero. Also warum einen Stick ?
Diese Konfig funktioiniert fehlerlos mit einem RasPi Server ! Siehe Tutorial oben !
Das tun Interface ist ein Routing Interface. Das ist technisch unmöglich einer Bridge zuzuordnen. Das geht nur wenn du ein tap Interface benutzt !
Siehe dazu auch hier: https://openvpn.net/community-resources/ethernet-bridging/
Wie bereits mehrfach gesagt:
Man kann dir nur dringenst vom Bridging abraten wenn du eine LAN zu LAN Kopplung damit realisierst ! Routing ist immer erste Wahl.
Bridging ist immer das Schlechteste was man machen kann bei einem VPN, es sei denn man ist dazu wirklich gezwungen weil man Protokolle einsetzt die nicht routebar sind. Sowas gibt es aber heutzutage fast gar nicht mehr.
Fragt sich also warum du so am schlechteren, da kontraproduktivem Bridging klebst ?!
1
Hallo und danke erstmal,
ich bin ja wie von euch empfohlen bereits von einer Bridge abgekommen und nutze einen gerouteten Tunnel (daher tun0). Die br0 hätte nur dazu gedient, den eth0 mitanzubinden. Sorry, da hatte ich wohl einen Denkfehler. Ich habe die zitierten iptables Befehle übrigens nicht ausgeführt, ich hatte die nur drin, weil ich dachte das könnte die Lösung sein.
Beim Orange Pi handelt es sich um den Orange Pi PC, eine olle Klamotte aus der Bastelkiste mit Allwinner H3 SoC. Der hat leider kein WIFI intern. Wie du richtig vermutest läuft darauf die aktuelle Version von Armbian.
Ansonsten bin ich zuversichtlich, mithilfe deines aktuellen Beitrags die Sache ins Laufen zu kriegen.
Top! - Danke.
Grüße,
pvniederbayern
ich bin ja wie von euch empfohlen bereits von einer Bridge abgekommen und nutze einen gerouteten Tunnel (daher tun0). Die br0 hätte nur dazu gedient, den eth0 mitanzubinden. Sorry, da hatte ich wohl einen Denkfehler. Ich habe die zitierten iptables Befehle übrigens nicht ausgeführt, ich hatte die nur drin, weil ich dachte das könnte die Lösung sein.
Beim Orange Pi handelt es sich um den Orange Pi PC, eine olle Klamotte aus der Bastelkiste mit Allwinner H3 SoC. Der hat leider kein WIFI intern. Wie du richtig vermutest läuft darauf die aktuelle Version von Armbian.
Ansonsten bin ich zuversichtlich, mithilfe deines aktuellen Beitrags die Sache ins Laufen zu kriegen.
Top! - Danke.
Grüße,
pvniederbayern
ich hatte die nur drin, weil ich dachte das könnte die Lösung sein.
Ein Denkfehler, denn das ist ja bekanntlich die Firewall und macht alles noch schlimmer wenn man nicht weiss was man tut ! Wie du richtig vermutest läuft darauf die aktuelle Version von Armbian.
Gibt ja 2: Debian und Ubuntu Ansonsten bin ich zuversichtlich, die Sache ins Laufen zu kriegen.
Wir sind gespannt...! 
Ich denke mal, Dein Problem wird noch in der OpenVPN-Server.conf, bzw. der CCD liegen.
Wenn Du nicht weiter kommst, mal Routingtabelle und Configs posten.
Gruß und schöne Ostern... orcape
Wenn Du nicht weiter kommst, mal Routingtabelle und Configs posten.
Gruß und schöne Ostern... orcape
Hallo Leute, nach vieler Bastelei hab ich einfach mal alte Zöpfe abgeschnitten und das System komplett neu aufgesetzt - und voila, es funktioniert. Vielen Dank an alle, die mir geholfen haben, insbesondere an aqui.
Eine Frage bleibt aber noch: Dadurch, dass ich einen gerouteten Tunnel habe, bleibt Multicast Traffic hängen. Für den eigentlichen Anwendungszweck - dem Logging - nicht weiter schlimm, es wäre aber schön auch das zum Wechselrichter gehörige Konfigurationsprogramm (SMA Sunny Explorer) nutzen zu können. Dummerweise hält es SMA für schlau, nicht mal optional die manuelle Eingabe der IP des Wechselrichters zu ermöglichen, sondern der Wechselrichter wird ausschließlich per Multicast gesucht. Dieses Multicast über den VPN zu routen ist wohl zwecklos, richtig? (Ich werde jedenfalls deshalb nicht mehr auf Bridging wechseln, wenn's nicht geht, dann lass ich's halt...)
Grüße,
PVNiederbayern
Eine Frage bleibt aber noch: Dadurch, dass ich einen gerouteten Tunnel habe, bleibt Multicast Traffic hängen. Für den eigentlichen Anwendungszweck - dem Logging - nicht weiter schlimm, es wäre aber schön auch das zum Wechselrichter gehörige Konfigurationsprogramm (SMA Sunny Explorer) nutzen zu können. Dummerweise hält es SMA für schlau, nicht mal optional die manuelle Eingabe der IP des Wechselrichters zu ermöglichen, sondern der Wechselrichter wird ausschließlich per Multicast gesucht. Dieses Multicast über den VPN zu routen ist wohl zwecklos, richtig? (Ich werde jedenfalls deshalb nicht mehr auf Bridging wechseln, wenn's nicht geht, dann lass ich's halt...)
Grüße,
PVNiederbayern
dass ich einen gerouteten Tunnel habe, bleibt Multicast Traffic hängen.
Aber nur weil du kein Multicast Routing mit PIM aktiviert hast Es gibt 2 Möglichkeiten:
- GRE Tunnel über das VPN aufsetzen und PIM Multicast Routing machen darüber
- IGMP Proxy aufsetzen und Multicast darüber abfackeln.
Das solltest du verher zwingend prüfen !!
Es gibt sog. Link Local Multicast Adressen 224.0.0.0/24 deren TTL fest auf 1 gesetzt ist und die nicht routebar sind !
Wenn deine SMA Anwendung das nutzt kannst du nur mit einem Proxy arbeiten wie z.B. AVAHI. Das kann man dann mit einem 30 Euro Raspberry Pi ganz einfach lösen:
Netzwerk Management Server mit Raspberry Pi
Wenn du diese Info von SMA nicht bekommst, dann ist hier wie immer der Wireshark dein bester Freund. Einfach damit mal checken welche Multicast Adressen die SMA Anwendung auf dem Netzwerk nutzt und et voila schon kannst du das zum Fliegen bringen.
Hey,
nur mal als Zwischenstand:
Die Sache mit dem Multicast-Routing ist noch nicht gelöst, ich bin leider momentan sehr eingespannt. Da ich aber wahrscheinlich erst Ende Juli wieder Zeit finden werde, möchte ich nicht solange damit warten, meine Wertschätzung für eure Hilfe auszudrücken. Also schonmal herzlichen Dank. Ihr seid super! Ich markiere den Thread mal als gelöst, da die Ausgangsfrage ja mittlerweile wunderbar läuft.
Bleibt alle gesund!
nur mal als Zwischenstand:
Die Sache mit dem Multicast-Routing ist noch nicht gelöst, ich bin leider momentan sehr eingespannt. Da ich aber wahrscheinlich erst Ende Juli wieder Zeit finden werde, möchte ich nicht solange damit warten, meine Wertschätzung für eure Hilfe auszudrücken. Also schonmal herzlichen Dank. Ihr seid super! Ich markiere den Thread mal als gelöst, da die Ausgangsfrage ja mittlerweile wunderbar läuft.
Bleibt alle gesund!
