[solved] Verbindungen über Netzwerkgrenzen hinweg
-
Ich habe etwas über virtuelle IPs gelesen, könnten die bei folgendem Problem helfen?
Habe hier ein Programm namens DVBViewer Recording Service, welches partout nicht außerhalb seines Subnets arbeiten will. Der Autor hat es seinerzeit mal upgedatet und wollte erneut Kohle sehen, darauf hatte ich keine Lust.
Nun ist es bei mir so, dass pfSense als VM in Hyper-V auf dem Host läuft, auf dem selbst auch besagten Programm läuft. Momentan habe ich den Host nur mittels eines virtuellen (10Gb) Interfaces mit der Sense verbunden. Da aber nur der Host dieses Interface direkt nutzen kann, sind nun DVBViewer Clients quasi ausgesperrt. Ich könnte den Host auch mit LAN verbinden, aber möchte ich nicht, da eigentlich unnötig und das Ganze dann durch einen echten 1Gb-Switch ginge.
Lange rede kurzer Sinn, welche Möglichkeiten habe ich auf der Sense, außer einer Brücke, mit solchen Programmen umzugehen, die nicht über Netzgrenzen hinweg funktionieren?
-
@Bob-Dig said in Verbindungen über Netzwerkgrenzen hinweg:
Nun ist es bei mir so, dass pfSense als VM in Hyper-V auf dem Host läuft, auf dem selbst auch besagten Programm läuft. Momentan habe ich den Host nur mittels eines virtuellen (10Gb) Interfaces mit der Sense verbunden. Da aber nur der Host dieses Interface direkt nutzen kann, sind nun DVBViewer Clients quasi ausgesperrt.
Verstehe ich nicht. DVBViewer Recording Service läuft am Host, der Host ist mit der pfSense verbunden über ein konfiguriertes Interface, aber zum Service gibt es keine Verbindung
-
@viragomann Die "Clients" sind über ein anderes Interface (LAN) mit der Sense verbunden als der Host selbst. Und das ist ein Problem für den "Recording Service". Regeln erlauben natürlich die Verbindung.
Wenn ich hier bridgen will, wird es gefährlich, weil es halt auch LAN betrifft. Werd ich aber wohl machen, wenn keiner ne andere Idee hat.
-
Okay, verstehe. Die pfSense kann also ganz normal mit dem Server kommunizieren.
Das Outound NAT der pfSense ist hier dein Freund. Es ersetzt die Quell-IP in Paketen, die zu dem Server von den Clients laufen, mit der Interface-IP der pfSense Schnittstelle.
Das Outbound NAT mus im manuellen oder hybriden Modus gestellet werden. Dann einfach eine Standard-Regel erstellen:
Quelle: das Netz, in dem die Clients beheimatet sind.
Ziel: der Host
Translation: Interface AdresseWas in die Richtung darf, kontrollierst du mit Firewall-Regeln.
-
@viragomann Danke, es läuft.
Als Interface habe ich hier die Verbindung des Hosts zu pfSense ausgewählt.
-
@Bob-Dig said in Verbindungen über Netzwerkgrenzen hinweg:
Als Interface habe ich hier die Verbindung des Hosts zu pfSense ausgewählt.
Ja, natürlich, das Interface, das hier auszuwählen ist, muss jenes sei, an dem die Pakete die pfSense Richtung Ziel verlassen.
Als Translation Address ist dann die Interface-IP naheliegend, kann aber auch eine andere virtuelle IP sein, die du dem Interface zuvor zugeordnet hast, aber eben eine aus demselben Subnetz. -
@viragomann Habe jetzt aber Probleme mit einem anderen Rechner in LAN, der bekommt keine IP Adresse mehr... Vielleicht ist die Regel doch nicht korrekt?
-
@Bob-Dig
Mit dieser Outbound NAT Regel kann das nichts zu tun haben. Die behandelt ausschließlich Pakete, die zum Host gehen. -
Können die Clients jetzt mit dem Server reden? Ist für den Server echt nur die Source IP ein Problem? Dann ist das ganz schön gruselige Software ;) Aber hey wenns so funktioniert, warum nicht :)
-
Etwas anderes ist viel gruseliger, meine pfSense ist gerade über den Jordan gegangen, ich habe nur noch Link-local IPv4 Adressen bekommen, nur der DNS-Server stimmte noch. So konnte ich auch nicht mehr auf die pfSense verbinden (bzw. hab es auf die Link-local IPv4 Adresse auch nicht versucht).
Ich hatte Gott sei Dank noch ein passenden Backup von gestern.Könnte Ihr bitte noch mal drauf schauen, ob die NAT-Regel wirklich in Ordnung ist? Ich hatte sie zuerst auf LAN gesetzt, nachdem das nicht ging dann auf das andere Interface, weil Noob. Und die besagte Verbindung ging dann, aber die Sense hat sich irgendwie verabschiedet, Neustart der Sense und des ganzen Host brachte keine Verbesserung mehr.
Veeam hat mir in Punkto pfSense nun schon mehrfach den Arsch gerettet, danke Veeam.
-
Findet sich nichts im System-Log zu dem Vorfall?
Bei der Regel kann nicht viel schief gehen. Sie hat ein Interface angegeben, auf dem sie angewandt wird, ein Quell-Netz und eine Ziel-IP und -Port und eben die Interface-IP, auf die die Quell-IPs der Pakete transferiert werden.
Die Regel bewirkt hinterher für die pfSense, dass der Zielhost sämtliche Antworten wieder an die pfSense-IP adressiert anstatt direkt auf die Clients (was aber auch über die pfSense laufen würde) und diese setzt dann wieder anhand ihrere States die Ziel-IP auf die ursprüngliche Quell-IP um. Also möglicherweise ein klein wenig mehr Speicherbedarf, aber das kann doch nicht das Problem sein.
-
@viragomann Danke. Was ich noch heute gemacht hatte, eine virtuelle IP angelegt, ohne es wirklich zu verstehen, aber dann auch nicht groß was damit gemacht.
Das Log hätte ich mir wie ansehen können, in der Console? Oder mittels SSH auf die Link-local IPv4 Adresse verbinden? Hab die vhdx-Datei noch hier, aber Windows kann damit nix anfangen und ich auch nicht.
Gut, werde die NAT-Regel noch mal versuchen, Backup ist ja offensichtlich gegeben.Habe jetzt die Regel noch mal weiter präzisiert und die Ports auf alle mir bekannten Ports erweitert.
Mein subjektiver Eindruck ist, dass die Clients langsamer starten als vorher, was vielleicht bedeuten könnte, dass zwar der eingebaute Test erfolgreich verläuft, aber noch nicht alles rund läuft...Bis jetzt keine Auffälligkeiten was die Sense betrifft.
-
@Bob-Dig said in Verbindungen über Netzwerkgrenzen hinweg:
Link-local IPv4 Adresse
was für Link local bitte?
logs ansehen
mit: clog <logfile>
-
@JeGr said in Verbindungen über Netzwerkgrenzen hinweg:
was für Link local bitte?
Na so was:
169.254.0.0/16 -
Das ist APIPA nicht link-local. Sprich DHCP gescheitert, automatisch ne private Adresse vergeben. Heißt also effektiv nur, dass deine Kiste DHCP wollte und keine bekommen hat. Fände ich jetzt im ersten Moment bei ner Firewall eher komisch weil die außer ggf aufm WAN eigentlich kein DHCP Client spricht :)
Ansonsten auf Konsole in
/var/logsich das Log mitclog system.logbspw. anschauen. -
@JeGr said in Verbindungen über Netzwerkgrenzen hinweg:
Das ist APIPA nicht link-local.
Dann muss jemand mal den Wikipedia Eintrag anpassen. Ich vermute einfach mal, beides ist korrekt.
Deswegen, die Sense ist hops gegangen oder mindestens der DHCP-Dienst. Aber Backup hat den Tag gerettet, mal wieder.
