Netzwerkbereiche miteinander verbinden
- Ersteller hanspeter
- Erstellt am
rednag
Well-known member
Die Fritz!Box kennt erstmal nur Geräte welche sich im gleichen Subnetz wie sie befinden.
Es gilt der Fritz!Box mitzuteilen über welchen Weg man das 192.168.8. Netz erreicht. Das sollte man mit einer statischen Route abbilden können. Erstmal die Fragen von @the other klären. Vielleicht ergeben sich dann andere Möglichkeiten
Es gilt der Fritz!Box mitzuteilen über welchen Weg man das 192.168.8. Netz erreicht. Das sollte man mit einer statischen Route abbilden können. Erstmal die Fragen von @the other klären. Vielleicht ergeben sich dann andere Möglichkeiten
the other
Well-known member
Moinsen,
da ja auch bereits der erste Router (die Fritzbox) durchaus als VPN Server arbeiten kann, verstehe ich dein Konstrukt trotzdem nicht.
Die Fritzbox als Internetrouter (1. Router) kann VPN (wenn es denn richtig eingestellt wird). Warum als der 2. Router? Muss der als Router laufen oder ginge auch zB IP client?
da ja auch bereits der erste Router (die Fritzbox) durchaus als VPN Server arbeiten kann, verstehe ich dein Konstrukt trotzdem nicht.
Die Fritzbox als Internetrouter (1. Router) kann VPN (wenn es denn richtig eingestellt wird). Warum als der 2. Router? Muss der als Router laufen oder ginge auch zB IP client?
Hallo @hanspeter,
siehe mal hier:
https://www.photovoltaikforum.com/thread/217299-volkszähler-uuid-in-homeassistant-einbinden/?postID=3504445#post3504445
Hier wurden aus verschiedenen Netzwerken die Daten in ein anderes Netzwerk zugänglich gemacht.
Vielleicht hilft Dir das?
siehe mal hier:
https://www.photovoltaikforum.com/thread/217299-volkszähler-uuid-in-homeassistant-einbinden/?postID=3504445#post3504445
Hier wurden aus verschiedenen Netzwerken die Daten in ein anderes Netzwerk zugänglich gemacht.
Vielleicht hilft Dir das?
the other
Well-known member
Moinsen,
Ansätze gibt es einige...es ist eben dir Frage: muss da ein 2. Router überhaupt sein? Denn wenn nicht, dann ist das Problem kein Problem, Router raus oder als IP Client, VPN macht die Fritzbox selber...ein Netzwerkbereich, Problem gelöst.
Oder aber anders, aber so ist es leider auch an dieser Stelle eher Raten als Wissen...daher: mehr Infos bitte!
Ansätze gibt es einige...es ist eben dir Frage: muss da ein 2. Router überhaupt sein? Denn wenn nicht, dann ist das Problem kein Problem, Router raus oder als IP Client, VPN macht die Fritzbox selber...ein Netzwerkbereich, Problem gelöst.
Oder aber anders, aber so ist es leider auch an dieser Stelle eher Raten als Wissen...daher: mehr Infos bitte!
Die Fritzbox läuft über einen Meshverbund mit anderen Fritz Repeatern. Dieses System möchte ich sauber für sich laufen lassen. Der andere Router hat eine eingebaute WireGuard App für meinen VPN Anbieter inkl. Killswitch. Das möchte ich ganz gerne vom Rest des Systems getrennt haben.
blurrrr
Well-known member
Der Versuch in allen Ehren, aber das eine hat hier eher rein garnichts mit dem anderen zu tun
Variante 1) NAT beim 2. Router abschalten + statische Route für das 2. Netz in der Fritzbox eintragen (via Gateway WAN-IP-2.-Router)
Variante 2) Portfreigabe auf das gewünschte Gerät am 2. Router und dann aus dem Netz der Fritzbox über die WAN-IP des 2. Routers mittels vorher angelegter Portfreigabe darauf zugreifen
Variante 2 ist "intern" ziemlicher Blödsinn, wäre aber noch eine Möglichkeit, wenn man NAT nicht auf dem 2. Router deaktivieren kann. Eine ganz andere Variante wäre noch folgende:
2. Router LAN-seitig(!) auf das Netz der Fritzbox konfigurieren (z.B. 178.2), dabei alles an Diensten deaktivieren (DHCP, DNS) damit sich das nicht mit der Fritzbox in die Quere kommt. Gastzugang an LAN4 der Fritzbox aktivieren, 2. Router WAN-seitig mit LAN4 der Fritzbox verbinden. Innerhalb des Netzes müssen nun die Geräte - welche den 2. Router als Default-Gatweay haben sollen - statisch konfiguriert werden.
blurrrr
Well-known member
"ACCEPT - Disable address rewriting" wäre dann das richtige. Achte aber - falls Du Dich grade hinter dem 2. Router befindest - darauf, dass Du zunächst die Routen in der Fritzbox einträgst (Netz hinter 2. Router + Netzmaske, Gateway ist dann die "WAN"-Adresse des 2. Routers im Fritzbox-Netzwerk). Wenn das eingetragen ist, kannst Du die o.g. Einstellung auf dem 2. Router vornehmen. Damit stimmt das reine Routing schon mal (Wege/Strecken sind bekannt), Firewall-Regeln (wer darf wohin) sind nochmal ein anderes Thema 
Ich habe jetzt als Test diese NAT rule erstellt, um von meinem Handy 192.168.178.20 (Fritz Subnet) auf die Oberfläche des Gli Routers (192.168.8.1) zuzugreifen. Das klappt aber leider nicht. Hast du eine Idee warum? Die Statische Route auf der FRITZ!Box müsste doch korrekt sein (s. letzter Screenshot)
blurrrr
Well-known member
Firewall-Regel auf dem 2. Router, welche den Zugriff auf das Webinterface aus dem Fritzbox-Netz untersagt bzw. andersrum: Es müsste auf den 2. Router erstmal eine Firewall-Regel erstellt werden, welche den Zugriff auf das LAN-seitige Webinterface zulässt.
Die NAT-Regel auf dem 2. Router sieht derweil in Ordnung aus (wenn es raus geht, nicht maskieren). Was jetzt noch fehlt, wären entsprechend gewünschte Firewall-Regeln. Für den Einstieg und eher nur zum testen, wäre es z.B. etwas in diese Richtung auf dem 2. Router:
Fritzbox-Netz -> alle Protokolle -> LAN -> erlauben
blurrrr
Well-known member
Finde ich etwas fragwürdig, ausser es war vorher eine Regel vorhanden, welche aktiv für eine Umschreibung der Adressen gesorgt hat. Sowas ist bei den meisten Routern standardmässig aktiviert. Wenn "nichts" da ist, oder explizit gesagt wird, dass bei bestimmten Dingen nicht maskiert werden soll, dann werden die Pakete auch entsprechend nicht maskiert. Aber wie auch immer, schön, dass es nun funktioniert
EDIT: Die o.g. genannte Regel solltest Du aber ggf. noch etwas verfeinern bzw. besser löschen und eher mehrere einzelne Regeln anliegen, damit auch nur bestimmte Dinge erlaubt sind.
Ja, hab ich anschließend eingegrenzt 
Mein Fazit:
1. Erstellt eine statische Route am ersten Router, die aufzeigt welches Netzwerk sich hinter der IP verbirgt, die den zweiten Router beherbergt.
2. Erlaubt eingehende Verbindungen am WAN des zweiten Routers zum gewünschten Ziel
3. Falls das nicht klappt, versucht es mit den NAT Einstellungen
Mein Setup war FRITZ!Box -> Gli.Net (OpenWrt)
Mein Fazit:
1. Erstellt eine statische Route am ersten Router, die aufzeigt welches Netzwerk sich hinter der IP verbirgt, die den zweiten Router beherbergt.
2. Erlaubt eingehende Verbindungen am WAN des zweiten Routers zum gewünschten Ziel
3. Falls das nicht klappt, versucht es mit den NAT Einstellungen
Mein Setup war FRITZ!Box -> Gli.Net (OpenWrt)
blurrrr
Well-known member
Bei Clients hinter einem Router, welcher die IP-Adressen via NAT maskiert, wird die Quell-IP der Pakete umgeschrieben. Heisst alles aus dem Netz des 2. Routers ist für Teilnehmer des Fritzbox-Netzwerkes mit der WAN-IP des 2. Routers in Erscheinung getreten, das Netzwerk dahinter war den Fritzbox-Netz-Teilnehmern völlig unbekannt.
Durch die Route in der Fritzbox wurde das Netz hinter dem 2. Router bekannt gemacht, so dass man nun weiss, dass sich dieses Netz hinter dem 2. Router befindet (wusste man ja vorher nicht). Damit das dann auch "sauber" funktioniert, "muss" NAT abgeschaltet werden, denn ansonsten wird eine Anfrage z.B. SSH an einen Rechner im 2. Netzwerk geschickt - das funktioniert auch "eingehend", aber "ausgehend" würde der 2. Router halt wieder hingehen und die Antwort maskieren.
Somit hättest Du dann z.B. die 192.168.8.100 (SSH-Server) angefragt, würdest aber eine Antwort von der 192.168.178.2 (2. Router WAN Fritzbox-Netzwerk) bekomme, welche Dein Client sofort verwerfen würde, denn von dieser IP erwartet er keine Antwort. NAT abschalten ist also in diesem Konstrukt "Pflicht", da es ansonsten sowieso nicht funktionieren würde
Durch die Route in der Fritzbox wurde das Netz hinter dem 2. Router bekannt gemacht, so dass man nun weiss, dass sich dieses Netz hinter dem 2. Router befindet (wusste man ja vorher nicht). Damit das dann auch "sauber" funktioniert, "muss" NAT abgeschaltet werden, denn ansonsten wird eine Anfrage z.B. SSH an einen Rechner im 2. Netzwerk geschickt - das funktioniert auch "eingehend", aber "ausgehend" würde der 2. Router halt wieder hingehen und die Antwort maskieren.
Somit hättest Du dann z.B. die 192.168.8.100 (SSH-Server) angefragt, würdest aber eine Antwort von der 192.168.178.2 (2. Router WAN Fritzbox-Netzwerk) bekomme, welche Dein Client sofort verwerfen würde, denn von dieser IP erwartet er keine Antwort. NAT abschalten ist also in diesem Konstrukt "Pflicht", da es ansonsten sowieso nicht funktionieren würde
blurrrr
Well-known member
Najo, das ist eigentlich ganz einfach, wenn man das mal aus IPv4-Sicht sieht: Wieviele "öffentliche" IP-Adressen hattest Du früher? Genau... "eine". Da hätten jetzt "mehrere" Geräte durchaus ein Problem. Das Problem wurde zwar schon vor langer Zeit "gelöst" in Form von IPv6, wo jedes Gerät seine eigene öffentliche IP-Adresse bekommt, es kommt aber nur sehr schleppend voran (wobei schon viel umgestellt ist).
Bei IPv4 hat man damals einfach zwischen öffentlichen und privaten Bereichen unterschieden. Privat ist z.B. 192.168.0.0/16. Verlassen Pakete mit diesen Quell-IPs das lokale Netz und wandern ins Internet, werden sie sofort verworfen. Das kann man ein bisschen mit folgendem Szenario vergleichen: Du fragst mich, wo ich wohne. Meine Antwort lautet: Zimmer 3 in Hausnummer 5! (192.168.5.3), faktisch kann das aber "überall" sein. Das gleiche gilt für den privaten IP-Bereich.
Nun war man damals nicht so gönnerhaft mit IP-Adressen, das ursprüngliche alte Konstrukt (1 Rechner -> 1 Modem) war so langsam auch überholt. Findige Leute haben sich damals mittels Linux-Servern eigene Router für die LAN-Party, etc. gebaut. Heisst: Ein Rechner hat "Router" gespielt (Pakete rein, Pakete raus und vor allem auch: Pakete mit der WAN-IP maskieren). Später kamen dann die Router, die man heutzutage halt so kennt. Wählen sich beim Provider ein, nehmen die Maskierung automatisch vor und stellen intern ein Netz bereit inkl. weiteren benötigten Diensten (DHCP/DNS).
Damit der kleine Kasten dann noch mehr konnte, hat man auch direkt noch WLAN mit dazu gepackt. Das hat sich eine geraume Zeit gehalten, aber mittlerweile stopft man halt alles rein, was nur irgendwie geht, das gleiche sieht man derzeit auch bei den NAS-Geräten. Bei mir ist die Fritzbox halt was sie "ist" - ein Router. Da läuft kein WLAN, kein Smarthome-Zeugs, nix mit irgendwelchen USB-Speichern, kein Telefon, nada. Einfach nur "Pakete rein, Pakete raus, Maskierung für alles was ins Internet geht", dahinter läuft allerdings eine Firewall - ganz ähnlich wie bei Dir, nur mit mehreren Netzen hinter der Firewall.
Was damals noch immer so ein "Argument" war - wo doch die Rechner mit Modem immer "direkt" am Netz hingen - "Sicherheit", denn durch den vorgeschalteten Router (und die damit verbundene Firewall, welche per Standard sagt: "Alles darf raus und nix darf rein (was nicht vorher von innen angefragt wurde)"), zudem wurden die "eigentlichen" IP-Adressen der Clients durch via NAT "verschleiert" und waren somit von aussen bzw. in den Paketen nicht mehr sichtbar, sobald sie das lokale Netz verlassen haben.
Wenn Du irgendwann dann mal mit IPv6 zu tun hast, wirst Du feststellen, dass es da kein NAT mehr gibt bzw. wird es auch nicht mehr benötigt. Es gibt zwar noch "interne" IP-Adressen, aber jedes Gerät kriegt auch seine eigene öffentliche IP, damit ist das Thema "Routing" eigentlich auch direkt durch. Was zum Schluss noch bleibt, sind eben die Firewall-Regeln am WAN-Router.
Btw das mit dem NAT kennst Du sogar schon mehrfach: Dieses "standardmässige" von den Routern ist ein SNAT (Source-NAT / Quell-NAT) und besagt: Alles was von dort kommt, wird mit X übersetzt (LAN -> WAN-IP). Das Gegenstück dazu ist das DNAT (Destination-NAT / Ziel-NAT), bei IPv4 wäre das die klassische Portweiterleitung (externen Port X weiterleiten auf interne IP Port Y). Wenn Du an Deinem WAN-Router eine Portweiterleitung machst, passieren da übrigens "2" Dinge (vielleicht kannst Du es Dir hier schon denken). Zum einen findet ein DNAT statt, zum anderen wird aber auch eine Firewall-Regel erzeugt. Ich erwähne das, da es nicht immer bei allen Systemen so ist. So manch einer hat schon eine Portweiterleitung erstellt und sich gewundert, warum denn nix funktioniert. Alternativ auch gern andersrum - Firewall-Regel erstellt, aber die NAT-Regel hat gefehlt.
Also nochmal kurz zusammengefasst: "IPv4-Geiz" (ist bei IPv6 aber Schluss mit, öffentliche IPs für alle) und "Sicherheit" (durch Verschleierung und zusätzliche Firewall).
Weiss ja nicht, was Du sonst noch so treibst, aber ich geb Dir nochmal ein kurzes praktisches Beispiel mit an die Hand:
2 Netze werden über eine Site2Site-VPN-Verbindung verbunden. Ein Netz davon ist Deins (192.168.101.0/24), das andere ist meins (192.168.102.0/24). Nun kennen unsere Router die jeweilige Gegenstelle, womit Clients aus unseren beiden Netzen sich auch gegenseitig ansprechen können. Jut, soweit klar, aber nun hatte ich ja vorhin irgendwann erwähnt, dass ich mehrere Netze bei mir habe z.B. 192.168.103.0/24. Weil ich nicht möchte, dass Du dieses Netz erreichen kannst, ist es auch nicht Teil der VPN-Verbindung und somit hat Deine Seite auch keinerlei Infos über diese Netze.
So... nun möchte ich aber mit einem Client aus einem Netz - welches nicht Teil der VPN-Verbindung ist (192.168.103.0/24) - auf ein Gerät in Deinem Netz (192.168.101.0/24) zugreifen. Für mich funktioniert das zumindestens ausgehend. Das Paket wird bei Dir ankommen (Quell-IP z.B. 192.168.103.100), das Problem liegt aber darin, dass bei Dir niemand den Weg zu diesem Netz kennt. Was macht man, wenn man den Weg nicht kennt? -> Standard-Gateway, das wird schon Bescheid wissen... Dein Router weiss nur auch nichts von diesem Netz, also schickt er die Antwort weiter an sein Standard-Gateway (Internet), dort wird die Antwort dann einfach verworfen.
Die (unsaubere) Lösung wäre nun, dass ich meinerseits einfach eine NAT-Regel erstelle:
Quelle: 192.168.103.0/24
Ziel: 192.168.101.0/24
Maskierung: IP = z.B. 192.168.102.1
Die Netze 101 und 102 kennen sich ja, also kann das Gerät bei Dir die Antwort zu dem Gerät bei mir schicken, welches das ganze dann wiederum weiterleitet an die ursprüngliche IP des anfragenden Clients.
So, somit haben wir uns nun auch direkt kennengelernt, denn...
Ansonsten wäre die Antwort auch eher Ruhrpott-typisch ausgefallen in Form von "isso" 
Falls noch irgendwas unklar sein sollte, einfach fragen, ich kann ja auch versuchen mich kurz zu fassen
Bei IPv4 hat man damals einfach zwischen öffentlichen und privaten Bereichen unterschieden. Privat ist z.B. 192.168.0.0/16. Verlassen Pakete mit diesen Quell-IPs das lokale Netz und wandern ins Internet, werden sie sofort verworfen. Das kann man ein bisschen mit folgendem Szenario vergleichen: Du fragst mich, wo ich wohne. Meine Antwort lautet: Zimmer 3 in Hausnummer 5! (192.168.5.3), faktisch kann das aber "überall" sein. Das gleiche gilt für den privaten IP-Bereich.
Nun war man damals nicht so gönnerhaft mit IP-Adressen, das ursprüngliche alte Konstrukt (1 Rechner -> 1 Modem) war so langsam auch überholt. Findige Leute haben sich damals mittels Linux-Servern eigene Router für die LAN-Party, etc. gebaut. Heisst: Ein Rechner hat "Router" gespielt (Pakete rein, Pakete raus und vor allem auch: Pakete mit der WAN-IP maskieren). Später kamen dann die Router, die man heutzutage halt so kennt. Wählen sich beim Provider ein, nehmen die Maskierung automatisch vor und stellen intern ein Netz bereit inkl. weiteren benötigten Diensten (DHCP/DNS).
Damit der kleine Kasten dann noch mehr konnte, hat man auch direkt noch WLAN mit dazu gepackt. Das hat sich eine geraume Zeit gehalten, aber mittlerweile stopft man halt alles rein, was nur irgendwie geht, das gleiche sieht man derzeit auch bei den NAS-Geräten. Bei mir ist die Fritzbox halt was sie "ist" - ein Router. Da läuft kein WLAN, kein Smarthome-Zeugs, nix mit irgendwelchen USB-Speichern, kein Telefon, nada. Einfach nur "Pakete rein, Pakete raus, Maskierung für alles was ins Internet geht", dahinter läuft allerdings eine Firewall - ganz ähnlich wie bei Dir, nur mit mehreren Netzen hinter der Firewall.
Was damals noch immer so ein "Argument" war - wo doch die Rechner mit Modem immer "direkt" am Netz hingen - "Sicherheit", denn durch den vorgeschalteten Router (und die damit verbundene Firewall, welche per Standard sagt: "Alles darf raus und nix darf rein (was nicht vorher von innen angefragt wurde)"), zudem wurden die "eigentlichen" IP-Adressen der Clients durch via NAT "verschleiert" und waren somit von aussen bzw. in den Paketen nicht mehr sichtbar, sobald sie das lokale Netz verlassen haben.
Wenn Du irgendwann dann mal mit IPv6 zu tun hast, wirst Du feststellen, dass es da kein NAT mehr gibt bzw. wird es auch nicht mehr benötigt. Es gibt zwar noch "interne" IP-Adressen, aber jedes Gerät kriegt auch seine eigene öffentliche IP, damit ist das Thema "Routing" eigentlich auch direkt durch. Was zum Schluss noch bleibt, sind eben die Firewall-Regeln am WAN-Router.
Btw das mit dem NAT kennst Du sogar schon mehrfach: Dieses "standardmässige" von den Routern ist ein SNAT (Source-NAT / Quell-NAT) und besagt: Alles was von dort kommt, wird mit X übersetzt (LAN -> WAN-IP). Das Gegenstück dazu ist das DNAT (Destination-NAT / Ziel-NAT), bei IPv4 wäre das die klassische Portweiterleitung (externen Port X weiterleiten auf interne IP Port Y). Wenn Du an Deinem WAN-Router eine Portweiterleitung machst, passieren da übrigens "2" Dinge (vielleicht kannst Du es Dir hier schon denken). Zum einen findet ein DNAT statt, zum anderen wird aber auch eine Firewall-Regel erzeugt. Ich erwähne das, da es nicht immer bei allen Systemen so ist. So manch einer hat schon eine Portweiterleitung erstellt und sich gewundert, warum denn nix funktioniert. Alternativ auch gern andersrum - Firewall-Regel erstellt, aber die NAT-Regel hat gefehlt.
Also nochmal kurz zusammengefasst: "IPv4-Geiz" (ist bei IPv6 aber Schluss mit, öffentliche IPs für alle) und "Sicherheit" (durch Verschleierung und zusätzliche Firewall).
Weiss ja nicht, was Du sonst noch so treibst, aber ich geb Dir nochmal ein kurzes praktisches Beispiel mit an die Hand:
2 Netze werden über eine Site2Site-VPN-Verbindung verbunden. Ein Netz davon ist Deins (192.168.101.0/24), das andere ist meins (192.168.102.0/24). Nun kennen unsere Router die jeweilige Gegenstelle, womit Clients aus unseren beiden Netzen sich auch gegenseitig ansprechen können. Jut, soweit klar, aber nun hatte ich ja vorhin irgendwann erwähnt, dass ich mehrere Netze bei mir habe z.B. 192.168.103.0/24. Weil ich nicht möchte, dass Du dieses Netz erreichen kannst, ist es auch nicht Teil der VPN-Verbindung und somit hat Deine Seite auch keinerlei Infos über diese Netze.
So... nun möchte ich aber mit einem Client aus einem Netz - welches nicht Teil der VPN-Verbindung ist (192.168.103.0/24) - auf ein Gerät in Deinem Netz (192.168.101.0/24) zugreifen. Für mich funktioniert das zumindestens ausgehend. Das Paket wird bei Dir ankommen (Quell-IP z.B. 192.168.103.100), das Problem liegt aber darin, dass bei Dir niemand den Weg zu diesem Netz kennt. Was macht man, wenn man den Weg nicht kennt? -> Standard-Gateway, das wird schon Bescheid wissen... Dein Router weiss nur auch nichts von diesem Netz, also schickt er die Antwort weiter an sein Standard-Gateway (Internet), dort wird die Antwort dann einfach verworfen.
Die (unsaubere) Lösung wäre nun, dass ich meinerseits einfach eine NAT-Regel erstelle:
Quelle: 192.168.103.0/24
Ziel: 192.168.101.0/24
Maskierung: IP = z.B. 192.168.102.1
Die Netze 101 und 102 kennen sich ja, also kann das Gerät bei Dir die Antwort zu dem Gerät bei mir schicken, welches das ganze dann wiederum weiterleitet an die ursprüngliche IP des anfragenden Clients.
So, somit haben wir uns nun auch direkt kennengelernt, denn...
...und...
...beisst sich meist, da ich gerne auch mal etwas weiter und ausführlicher aushole
Ansonsten wäre die Antwort auch eher Ruhrpott-typisch ausgefallen in Form von "isso" Falls noch irgendwas unklar sein sollte, einfach fragen, ich kann ja auch versuchen mich kurz zu fassen
