Zwei Hausnetze verbinden

So, ich habe mich mal an der Skizze versucht. Heute Abend habe ich wieder Zugriff, dann kann ich noch Screenshots von den 3 Routern ergänzen.
Zum Fehlerbild:
Aus Haus A kann ich ohne Probleme auf die Weboberflächen von Haus B zugreifen, konkret auf Gatewayrouter (0.3) und ISP-Router (0.1) .
Umgekehrt komme ich aus Haus B aber nicht auf die Oberflächen in Haus A, der des Gatewayrouter (178.41) und ISP-Router (178.1). Tracert zeigt aber die richtige Route an (0.1->0.3->178.1)
 

Anhänge

  • Netz.jpg
    Netz.jpg
    202,9 KB · Aufrufe: 365
Zuletzt bearbeitet:
Das Routing sieht in Ordnung aus. Ich würde vermuten das die Firewalleinstellungen vom ER-X nicht passen bzw. das er Einseitig NAT'tet. Mit welcher Source-IP kommst du den im anderen Netz an? Lässt sich das in den Logdateien des Technicolor sehen?
 
  • Gefällt mir
Reaktionen: Tranceport
MoinMoin,

Tranceport schrieb:
So, ich habe mich mal an der Skizze versucht.

Wenn Du Angaben zu Routen machst, dann bitte auch die Subnetzmaske mit angeben: z.B. 192.168.0.0/24 via 192.168.178.41. Die Angaben in Deiner Skizze helfen da aktuell nur bedingt.

Aus Haus A kann ich ohne Probleme auf die Weboberflächen von Haus B zugreifen, konkret auf Gatewayrouter (0.3) und ISP-Router (0.1) .
Umgekehrt komme ich aus Haus B aber nicht auf die Oberflächen in Haus A, der des Gatewayrouter (178.41) und ISP-Router (178.1). Tracert zeigt aber die richtige Route an (0.1->0.3->178.1)

Mit den Angaben scheint das Routing zu funktionieren, daher bleibt nur wie Harrdy schon schrieb die Prüfung der NAT- und Firewall-Einstellungen (in beide Richtungen).


Viel Erfolg bei der Suche,
Christian
 
  • Gefällt mir
Reaktionen: Tranceport
Ich sehe da jetzt auf den ersten Blick auch keinen Fehler - gesetzt den Fall die Subnetzmasken sind korrekt wie @Joe Dalton angemerkt hat. Der EdgeRouter darf natürlich kein NAT machen, (SNAT bzw. masquerade).

Ausgehend von den Werkseinstellungen, die außer einer IP auf eth0 keinerlei Firewall, NAT, etc. enthalten, sollte es ausreichend sein, dem Port Richtung Haus A bzw. B eine passende IP zu verpassen. Das Routing ist out-of-the-box aktiviert und ohne weitere Einstellungen würde der ER ohne Mucks hin und her routen.

Wenn du magst, kannst du mal rechts oben in der Toolbox in die CLI gehen und "show configuration | cat" eingeben. Den Output hier in einem Spoiler-Tag posten. Den Part mit dem Login, etc. kannst du dabei weglassen, es geht nur um die Konfiguration der Interfaces, Firewall, Services bzw. NAT, das sind unkritische Daten mit denen man von außen sowieso nix anfangen kann.
 
  • Gefällt mir
Reaktionen: Tranceport
Raijin schrieb:
Wenn du magst, kannst du mal rechts oben in der Toolbox in die CLI gehen und "show configuration | cat" eingeben.
Der Output sieht wie folgt aus (soweit ich mich erinnere habe ich da nichts angefasst, bei der Durchsicht ist mir aber schon aufgefallen, dass der EdgeRouter als Gateway besser keine Adresse per DHCP bezieht, sondern eine feste IP braucht):

interfaces {
ethernet eth0 {
address 192.168.1.1/24
duplex auto
speed auto
}
ethernet eth1 {
address dhcp
duplex auto
poe {
output off
}
speed auto
}
ethernet eth2 {
duplex auto
speed auto
}
ethernet eth3 {
duplex auto
speed auto
}
ethernet eth4 {
duplex auto
speed auto
}
ethernet eth5 {
address 192.168.0.3/24
duplex auto
speed auto
}
loopback lo {
}
switch switch0 {
mtu 1500
}
}
protocols {
static {
}
}
service {
dhcp-server {
disabled false
hostfile-update disable
shared-network-name 20 {
authoritative disable
subnet 192.168.178.0/24 {
default-router 192.168.178.1
dns-server 1.1.1.1
lease 86400
start 192.168.178.10 {
stop 192.168.178.250
}
}
}
shared-network-name 20a {
authoritative disable
subnet 192.168.0.0/24 {
default-router 192.168.0.1
dns-server 1.1.1.1
dns-server 8.8.8.8
lease 86400
start 192.168.0.10 {
stop 192.168.0.250
}
}
}
}
gui {
https-port 443
}
ssh {
port 22
protocol-version v2
}
}
system {
host-name ubnt
login {
user *****{
authentication {
encrypted-password ****************
}
level admin
}
}
ntp {
server 0.ubnt.pool.ntp.org {
}
server 1.ubnt.pool.ntp.org {
}
server 2.ubnt.pool.ntp.org {
}
server 3.ubnt.pool.ntp.org {
}
}
syslog {
global {
facility all {
level notice
}
facility protocols {
level debug
}
}
}
time-zone Europe/Berlin
}
Im Anhang habe ich noch die IP-Routen Übersicht von meinem Router gepackt.
Sry, dass es etwas gedauert hat, bin gerade Mitten im Umzug ;-)
Grüße,
Chris
 

Anhänge

  • technocolor.png
    technocolor.png
    25,3 KB · Aufrufe: 269
Moin,

wie Du schon sagtest: Gateways sollten fix konfiguriert sein und nicht per DHCP.

[Quatsch...]

Wie schaut das ganze aus, wenn Du Deine fixe IP-Adresse vergeben hast und ein show ip route ausgeben lässt?

Grüße,
Christian

EDIT: Screenshot dem falschen Router zugeordnet.
 
Schönes Projekt! Werde demnächst daheim etwas ganz ähnliches umsetzen.

Routing scheint in Ordnung, denn sonst würde ganz grundsätzlich auch die Antwort zurück ins 0er Netz fehlschlagen. Die Echo-Reply kommt aber an, weswegen Routing rausfällt; Tracert/Ping nutzen ja ICMP welches als "Kontrollinstanz" von IP im dritten OSI-Layer zu Hause ist.

Das Problem scheint also ab dem vierten OSI-Layer aufzutreten...

Was ich an deiner Stelle prüfen würde
Bekommst du eine Antwort von einer anderen Maschine (bei Windows die FW deaktivieren) aus dem 178er Netz oder geht "nur" das Webfrontend der Fritzbox und des Ubiquiti nicht? Lass einfach mal einen Portscan über das Netz laufen und sieh was antwortet - gerade Netzwerkdrucker sind richtige Quasselstrippen und haben in aller Regel einige Ports offen. Mglw. lauscht hinter 178.41 kein Managementinterface und die Fritz!Box will aus einem fremden Netz nicht konfiguriert werden können.

EDIT:
Und natürlich - gibt es irgendwo in diesen beiden Netzen Regeln, die auf Basis von Ports filtern?
 
Zuletzt bearbeitet:
So, habe mir am Wochenende jetzt das Wlan Passwort geben und mich in den Mac-Filter eintragen lassen. Habe dann mit dem handy UPNP für mein 178.41 Gateway angeschalten und mich gefreut, dass es endlicht geht.
Dann hat sich herausgestellt, dass ich nur mit dem handy von meinem Netz auf das andere Netz komme, der Übeltäter war also der Mac-Filter der Fritzbox =/
Jetzt stehe ich nur noch vor dem Problem, wie ich aus meinem Netz das Internetgateway im anderen Subnetz verwenden kann.
 
Tranceport schrieb:
Jetzt stehe ich nur noch vor dem Problem, wie ich aus meinem Netz das Internetgateway im anderen Subnetz verwenden kann.

Möglichkeit 1: Als Standardgateway die Ubiquiti angeben (bzw. das Bein, das sie in dem Netz hat) und da dann entsprechend mit deren Standardroute auf den anderen Router zeigen
Nachteil: Das funktioniert nicht für beide Anschlüsse gleichzeitig. Entweder man kann aus Netz A den Anschluss von B nutzen oder umgekehrt. A kann aber nicht den Anschluss von B nutzen, während B den Anschluss von A nutzt.

Möglichkeit 2: Raspberry Pi oder andere Linuxmaschine im anderen Netz betreiben und dann den Webtraffic über SSH zur Linuxmaschine tunneln. Der nutzt dann für den weiteren Weg sein Gateway.
Nachteil: Für Webtraffic mit FireFox oder Chrome (braucht eine Erweiterung) trivial einzurichten - für andere Anwendungen kann das etwas frickelig werden.

Möglichkeit 3: Dedizierter Proxy wie Squid im anderen Netz. Bei Bedarf dann den Proxyserver bei den Internetoptionen von Windows angeben. Einmal konfiguriert die komfortabelste und leistungsfähigste Variante.
 
  • Gefällt mir
Reaktionen: Tranceport
emulbetsup schrieb:
A kann aber nicht den Anschluss von B nutzen, während B den Anschluss von A nutzt
Hm? Das Zauberwort heißt PBR, Policy-Based-Routing. Je nach Quelle der Verbindung kann man im ER aktiv ein anderes Gateway ansteuern.
 
Ich denke, die einfachste (für mich) Lösung ist, meinen Rpi mit Squid drüben ins Netz zu hängen, oder alternativ der Diskstation drüben einen Proxy Server zu verpassen =)
Ich hätte nie damit gerechnet, dass es so ein langwieriges Thema ist :rolleyes: Vielen Dank für eure Antworten!
 
Mensch, ich trau mich schon garnicht mehr zu schreiben, weil es sich so zieht :rolleyes:
Scheinbar war es doch nicht der Mac-Filter, unabhängig davon kommen alle Handys und Tablets mit Android ins andere Subnetz, bei Windows 10 Laptops und PCs funktioniert es hingegen nicht (nur tracert...). So als Laie habe ich IPv6 im Verdacht, mal sehen ob ich dafür auch eine Route hinbekommen.
 
Grundsätzlich gibt es drei Varianten der IPv6-Autokonfiguration:

1. Stateless Address Autoconfiguration (SLAAC)
Der Knoten fordert mit einer multicast Router Solicitation eine Router Advertisement an. Diese enthält unter anderem das 64 Bit lange globale Präfix, dass der Knoten seiner zuvor selbst erstellen 64 Bit großen Interface-ID voranstellt. Die Kombination aus beidem ergibt seine 128 Bit lange globale IPv6 Adresse. Bevor er diese jedoch verwenden kann, überprüft er mit einer ICMPv6 Neighbor-Solicitation-Nachricht auf eben diese Adresse, ob diese nicht schon von einem anderen Client verwendet wird. Ist die Adresse bereits belegt, würfelt er sich einen eine neue Interface-ID zu und überprüft diese ebenfalls.
Zu seinem Standardgateway macht er die Link-Local-Adresse des Routers.

2. Stateful DHCPv6
Auch hier fordert der Knoten mit einer multicast Router Solicitation eine Router Advertisement an. Ist in der RA jedoch das M-Flag gesetzt, wird dem Knoten dadurch mitgeteilt, dass er sämtliche Konfigurationsdetails bis auf den Standardgateway von einem DHCPv6 erfragen muss. Zu seinem Standardgateway macht er wiederrum die Link-Local-Adresse des Routers, von dem er die RA erhalten hat.

3. Stateless DHCPv6
Wiederrum fordert der Knoten via einer multicast Router Solicitation eine Router Advertisement an. Ist in der RA das O-Flag gesetzt, wird dem Knoten dadurch mitgeteilt, dass er sich mit Hilfe der Informationen der RA selbst eine IPv6 Adresse generieren darf. Weitere Konfigurationen wie die IPv6-Adresse von DNS-Servern soll er wiederrum von einem DHCPv6 Server erfragen.

Neben dieser Global-Scope IPv6 generiert das Interface auch eine Local-Scope-Adresse, die allerdings nur in dem Subnetz des Clients gültig ist und nicht geroutet werden kann Diese beginnt mit FE80::/10 und ist am ehesten mit dem 169.254.0.0/16 Bereich aus IPv4 vergleichbar. Für Routing zwischen Subnetzen benötigst du aber mindestens eine Unique local address die aus dem Bereich fc00::/7 kommt.

IPv6 ist die Zukunft und wird sich sicher in den nächsten Jahr(zehnten) durchsetzen, aber wenn du bei deiner jetzigen Konfiguration und deinen Anwendungen auf IPv6 verzichten kannst, würde ich das bei der Konfiguration vermeiden. Außer du suchst die Herausforderung. Dann musst du die beiden DHCP entsprechend so konfigurieren, dass Sie mindestens als Stateless DHCPv6 arbeiten und für die beiden IPv6 Subnetze entsprechende Routen anlegen.

Wobei ich mich gerade frage, wieso du IPv6 im Verdacht hast. Du rufst das andere Subnetz doch über IPv4 auf, oder?
 
  • Gefällt mir
Reaktionen: Tranceport
Hauptsächlich weil mir wirklich sonst nichts einfällt, warum es mit Android funktioniert, mit Windows aber nicht (Linux probiere ich jetzt dann noch) =(
 
Poste mal bitte die Netzwerkkonfiguration der Windows 10 Clients und die der Android-Geräte. Wenn du ein Gerät über IPv4 aufrufst, kann IPv6 nur bei NAT-Varianten wie NAT64 eine Rolle spielen. Das würde mich aber sehr wundern. Rufst du die Geräte über Ihre IPv4-Adresse (192.168.178.1) oder über ihren Hostnamen (Fritz.Box) auf?

EDIT:
Bei Windows (10) kannst du IPv6 auch über den entsprechenden Dialog in der Systemsteuerung deaktivieren:

1533225478992.png
 
  • Gefällt mir
Reaktionen: Tranceport
Beschreibung. . . . . . . . . . . : Intel(R) Dual Band Wireless-N 7260
Physische Adresse . . . . . . . . : ***********
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
IPv4-Adresse . . . . . . . . . . : 192.168.0.32(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Lease erhalten. . . . . . . . . . : Donnerstag, 2. August 2018 18:08:31
Lease läuft ab. . . . . . . . . . : Freitag, 3. August 2018 00:17:56
Standardgateway . . . . . . . . . : 192.168.0.1
DHCP-Server . . . . . . . . . . . : 192.168.0.1
DNS-Server . . . . . . . . . . . : 192.168.0.1
NetBIOS über TCP/IP . . . . . . . : Aktiviert

Auf dem Handy sieht es auch unverdächtig aus, DHCP an, IP: 192.168.0.27. Mehr Infos finde ich auf Anhieb nicht.
IPv6 habe ich bereits deaktiviert auf dem Laptop, ohne Änderung. Die Geräte rufe ich nur über die jeweilige IPv4 auf.
 
Das scheint soweit zu passen. Nochmal kurz die Frage zum Verständnis: Du kommst mit dem Handy mit der 192.168.0.27 ins andere Netz rein, aber mit dem Laptop und der 192.168.0.32 nicht?

Schalte mal spaßeshalber das Handy ab und konfiguriere das Laptop manuell mit der Netzwerkkonfiguration vom Handy und versuche dann ins andere Netz zu kommen.

Wenn .27 geht und .32 nicht, könnte eine Subnetzmaske an einem Bein des Ubiquiti falsch sein.

255.255.255.224 bzw. /27 statt 255.255.255.0 bzw. /24
 
  • Gefällt mir
Reaktionen: Tranceport
Ja, der erste Absatz ist richtig! Habe es aber vorhin mit meinem home Server (Linux, 192.168.0.10)versucht, damit komme ich ebenfalls nicht drauf. Ping & tracert ist aber auf allen erfolgreich. Mit der IP vom Handy versuche ich es gleich
 
Wenn(!) Ping bzw. Trace-Route von allen Geräten ins andere Netz gehen, dann liegt der Fehler NICHT in den OSI-Layern 1-3. Das würde bedeuteten, dass auch deine IP-Konfiguration inkl. der gesetzten Routen so funktioniert und zwar auf allen Geräten, die erfolgreich eine ICMP-Meldung aus dem Netz erhalten haben.

Mach mal bitte von einer der Windowsmaschinen einen Portscan in das Netz. Da stimmt IMHO irgendwas bei den Ports nicht (Webinterface HTTP 80 vs HTTPS 443)

EDIT
Was passiert, wenn du via Telnet auf Port 80 der FritzBox anklopfst?
 
Zuletzt bearbeitet:
1533244645301.png


Und jetzt wird es noch seltsamer, ich habe nmap für den Portscan per Handy heruntergeladen und auf den Laptop geschoben, installiert (inkl. loopback) und den Portscan gestartet. Und jetzt komme ich mit dem Laptop ins andere Subnetz O.o Allerdings weiterhin nicht mit dem Server (192.168.0.10), wenn ich es dort über RDP im Browser versuche. Ich dreh durch :freak:

Verbunden bin ich jetzt mit dem Npcap Loopback Adapter:

Ethernet-Adapter Ethernet:
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Intel(R) Ethernet Connection I218-LM
Physische Adresse . . . . . . . . : 50-65-F3-B9-3B-6A
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
IPv4-Adresse . . . . . . . . . . : 192.168.0.50(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 192.168.0.1
DNS-Server . . . . . . . . . . . : 8.8.8.8
NetBIOS über TCP/IP . . . . . . . : Aktiviert

Ethernet-Adapter Npcap Loopback Adapter:
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Npcap Loopback Adapter
Physische Adresse . . . . . . . . : 02-00-4C-4F-4F-50
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
IPv4-Adresse (Auto. Konfiguration): 169.254.81.202(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.0.0
Standardgateway . . . . . . . . . :
NetBIOS über TCP/IP . . . . . . . : Aktiviert

1533245000237.png
 
Zuletzt bearbeitet:
Zurück
Oben