16.06.2019, aktualisiert um 00:30:13 Uhr

9808

Synology NAS in anderem Subnetz nicht erreichbar

Hallo Leute,

ich bin Software-Entwickler und daher auch etwas bewandert in den Grundkenntnissen der Netzwerktechnik. Aktuell habe ich allerdings ein kleines Problem, für dessen Lösung ich etwas Hilfe benötige bzw. ein paar Tipps, mit welchen Tools ich das Problem debuggen kann.

Und zwar folgendes:
Ich habe seit kurzem über zwei Mikrotik HEX S Router und eine MM-Glasfaserverbindung mein privates Heimnetz mit dem meines Nachbarn gekoppelt, so dass wir über diese Netzwerkleitung Backups auf dem NAS bzw. dem Server des jeweils anderen machen zu können.

Die Topologie habe ich hier aufgezeichnet:

Beide Netze haben ihren eigenen Internet-Router mit DHCP und allem, was man typischerweise so zu Hause im Einsatz hat. Zusätzlich hat jeder in seiner FritzBox eine statische Route in das jeweilige andere Netz eingerichtet, Gateway ist jeweils die interne IP des Mikrotik Routers.

Über die beiden SFP-Ports sind die beiden Router im Netz 10.1.1.0/30 miteinander verbunden und haben entsprechende statische Routen, die in das andere Netz zeigen (siehe Topologie-Grafik).

Das alles funktioniert prinzipiell auch einwandfrei - mit einer einzigen Ausnahme: Das Synology-NAS im Netz meines Nachbarn kann ich nur sehr sporadisch erreichen. Nach einem Neustart des Geräts konnte ich es für ein paar Sekunden anpingen, danach ging nichts mehr. Zugriff über den Browser konnte ich einmal erreichen, zwei Minuten später ging aber auch nix mehr. Ein Muster ist allerdings nicht erkennbar.
Alle (!) anderen Geräte im Netz kann ich ganz normal erreichen.

Der Ping-Befehl gibt "Destination Host Unreachable" zurück. Heißt das, dass das NAS die Anfragen blockt?

ping 192.168.1.3
PING 192.168.1.3 (192.168.1.3) 56(84) bytes of data.
From 192.168.0.1: icmp_seq=1 Redirect Host(New nexthop: 192.168.0.2)
From 10.1.1.2 icmp_seq=1 Destination Host Unreachable
From 10.1.1.2 icmp_seq=2 Destination Host Unreachable
From 10.1.1.2 icmp_seq=3 Destination Host Unreachable

Traceroute:

traceroute 192.168.1.3
traceroute to 192.168.1.3 (192.168.1.3), 30 hops max, 60 byte packets
 1  fritz.box (192.168.0.1)  0.271 ms  0.390 ms  0.378 ms
 2  192.168.0.2 (192.168.0.2)  0.618 ms  0.513 ms  0.460 ms
 3  10.1.1.2 (10.1.1.2)  0.595 ms  0.642 ms  0.624 ms
 4  10.1.1.2 (10.1.1.2)  2995.773 ms !H  2995.789 ms !H  2995.756 ms !H

Zum Vergleich eine andere IP, die funktioniert:

traceroute 192.168.1.7
traceroute to 192.168.1.7 (192.168.1.7), 30 hops max, 60 byte packets
 1  fritz.box (192.168.0.1)  0.792 ms  0.750 ms  0.720 ms
 2  192.168.0.2 (192.168.0.2)  3.193 ms  3.165 ms  3.151 ms
 3  10.1.1.2 (10.1.1.2)  3.123 ms  3.092 ms  3.061 ms
 4  192.168.1.7 (192.168.1.7)  3.031 ms  2.949 ms  2.917 ms

Laut dem Nachbarn ist die Firewall allerdings deaktiviert. Nach diversen Recherchen haben wir auf dem NAS auch mal IPv4-Forwarding aktiviert. Danach konnte ich ein paar Sekunden nach einem Neustart das Gerät anpingen, aber dann war es auch schon wieder rum.

Wenn die Firewall deaktiviert ist, was kann mir da noch dazwischengrätschen? SSH-Zugriff auf die Kiste ist möglich, ich weiß nur nicht genau, nach was ich da schauen muss.

Über hilfreiche Tipps würde ich mich sehr freuen!
Vielen Dank im Voraus und viele Grüße
Mathias

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 462698

Url: https://administrator.de/contentid/462698

Ausgedruckt am: 13.11.2024 um 12:11 Uhr

31 Kommentare

Neuester Kommentar

Sind die Zwischenstationen dann noch pingbar? Sind andere Geräte im Netz des NAS pingbar?

Ja, ich kann alle Geräte im Nachbarsnetz anpingen und auch umgekehrt. Nur das Synology-NAS weigert sich. Das Gerät bietet ja auch nicht gerade wenige Einstellmöglichkeiten bezüglich Netzwerke an. Von daher vermute ich, dass da möglicherweise IP-Adressen aus anderen Subnetzen geblockt werden. Im Internet findet man auch eine Reihe von Beiträgen, dass Nutzer auch beispielsweise bei der Nutzung von VPN Probleme mit Synology-Geräte haben und diese nicht anpingbar sind, alle anderen Geräte hingegen schon. Leider war die richtige Lösung für uns noch nicht dabei.

Moin,

wenn ich mir deinen tracert so anschaue, macht mir das schon stutzig:

Zitat von @Tech1Konni:
10.1.1.2 (10.1.1.2) 2995.773 ms 2995.789 ms 2995.756 ms

Die Laufzeiten sind immens hoch, ggf. schlicht zu hoch, um darüber irgendeine vernünftige Verbindung zusammen zu bekommen.
Der nächste tracert zeigt dann auch, dass es eigentlich anders aussehen sollte:

192.168.1.7 (192.168.1.7) 3.031 ms 2.949 ms 2.917 ms

Meiner Meinung nach passt da was mit dem Routing/NAT nicht?

Cheers,
jsysde

Im ersten Traceroute antwortet die 192.168.1.3 ja gar nicht. Nur die 10.1.1.2 im Hop 3 und 4.

Interessant wäre noch ein Traceroute jeweils von der anderen Seite aus. Evtl habt ihr ein asynchrones routing?

Ich würde in dem NAS mal direkt das Gateway eintragen und nicht auf der fritzbox. Ebenfalls auf deinem PC eine fixe Route direkt über den mikrotik.

Moin,

wie man am traceroute sieht, antwortet das nicht dem Mikrotik und der wartet halt relativ lange, bis er bescheidgibt, daß das NAS nicht antwortet.

Ich würde per tcpdump/wireshark auf dem NAS nachschauen, ob die Pakete bist zum NAS lkommen oder ob sie gf der Managed switch oder die Fritzbox schluckt.

Außerdem solltest Du auf dem NAS schauen, ob da irgendwelche Einschränkungen für "fremde" IP-Betze sind, btw explizit freigegeben werden müssen.

lks

Zitat von @jsysde:

Zitat von @Tech1Konni:
10.1.1.2 (10.1.1.2) 2995.773 ms 2995.789 ms 2995.756 ms

Die Laufzeiten sind immens hoch, ggf. schlicht zu hoch, um darüber irgendeine vernünftige Verbindung zusammen zu bekommen.

Moin,

ich denke eher, daß der Mikrotik eher "wartet" bis er meldet, daß sich dss NAS nicht meldet, d.h. in einen timeout läuft.

Das ist ja die "unreacheable"-Meldung und nicht die Meldung, daß das TTL abgelaufen ist.

lks

Zitat von @jsysde:
Meiner Meinung nach passt da was mit dem Routing/NAT nicht?

Cheers,
jsysde

Das Routing (zumindest auf den beiden bzw. vier Routern) müsste eigentlich passen und ist von den Regeln her ja auch recht simpel. NAT habe ich gar nicht aktiviert - wird meiner Meinung nach in unserem Setup (zwei überschneidungsfreie private Netze) nicht benötigt.

Zitat von @farddwalling:

Im ersten Traceroute antwortet die 192.168.1.3 ja gar nicht. Nur die 10.1.1.2 im Hop 3 und 4.

Interessant wäre noch ein Traceroute jeweils von der anderen Seite aus. Evtl habt ihr ein asynchrones routing?

Ich würde in dem NAS mal direkt das Gateway eintragen und nicht auf der fritzbox. Ebenfalls auf deinem PC eine fixe Route direkt über den mikrotik.

Eine traceroute von der anderen Seite kann ich später mal testen. Die Konfiguration der Routen ist in beiden Netzen identisch aufgebaut.
Du meinst asymmetrisches Routing? Ja, die jeweiligen Geräte im Netz haben natürlich immer die eigene FritzBox als Default-Gateway und im Normalfall sonst auch kein weiteres Gateway. Das heißt, dass die Geräte immer über die Fritz-Box und dann die beiden Router geroutet werden. Das stört mich prinzipiell auch nicht, da es die Konfiguration aller Geräte in den Netzen vereinfacht. Sonst müsste ich ja auf jedem Endgerät separate Routen definieren.

Aber für einen Test kann ich natürlich auf dem NAS mal ein zweites Gateway einrichten, welches direkt auf den Mikrotik zielt und nicht über die FB geht.

Hallo,

Wie sehen denn die Standartrouten der Router und des NAS aus?

Grüße

lcer

Zitat von @Lochkartenstanzer:

Moin,

wie man am traceroute sieht, antwortet das nicht dem Mikrotik und der wartet halt relativ lange, bis er bescheidgibt, daß das NAS nicht antwortet.

Ich würde per tcpdump/wireshark auf dem NAS nachschauen, ob die Pakete bist zum NAS lkommen oder ob sie gf der Managed switch oder die Fritzbox schluckt.

Außerdem solltest Du auf dem NAS schauen, ob da irgendwelche Einschränkungen für "fremde" IP-Betze sind, btw explizit freigegeben werden müssen.

lks

Okay, tcpdump ist klar, da weiß ich, was zu tun ist. Einstellungen ala fremde IP-Netze hat mein Nachbar bislang noch nicht gesehen und die Firewall ist ja auch deaktiviert. Wo müsste ich denn unter Linux typischerweise nachsehen, wenn dies vielleicht irgendein Setting ist, welches nicht im Webinterface von Synology angeboten wird?

Zitat von @lcer00:

Hallo,

Wie sehen denn die Standartrouten der Router und des NAS aus?

Grüße

lcer

Die Routen auf einem (meiner) der Mikrotik-Router:

ip route print      
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit 
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 A S  0.0.0.0/0                          192.168.0.1               1
 1 ADC  10.1.1.0/24        10.1.1.1        sfp1                      0
 2 ADC  192.168.0.0/24     192.168.0.2     bridge                    0
 3 A S  192.168.1.0/24                     10.1.1.2                  1

In meiner Fritzbox zusätzlich diese Route:

Aktiv	        Netzwerk 	Subnetzmaske 	Gateway 	
ja		192.168.1.0	255.255.255.0	192.168.0.2

Das Default Gateway seines NAS zielt auf seine Fritzbox (192.168.1.1), die die analoge statische Route zu meiner hat (also nur die Netzsegmente vertauscht).

Stimmt, asymmetrisch ist der richtige Ausdruck.
Im Prinzip ist das ja, wenn du von der einen Seite z.B. 4 Hops bis zum Ziel hast und von der anderen Seite aber 3 oder 5. da können auch komische Sachen bei rauskommen.

Dein erster Ping-Versuch zeigt, dass irgendwer einen ICMP-Redirect schickt, den dein Mikrotik akzeptiert, daraus resultierend aber keine Gegenstelle mehr erreichen kann.

Das Versenden und auch das Akzeptieren von ICMP-Redirect sollte also abgestellt werden.

Deshalb bleibt die spannende Frage ob der TO beim Mikrotik die Default Konfig gelöscht hat vor dem Konfigurieren ?!!
Ohne das macht der NAT auf dem WAN Port was dann schon mal zu solchen Routing Einbahnstrassen führen kann.
Siehe auch hier:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router

Es ist ja auch richtig das die lokale FritzBüx bei Traffic ins andere Netz einen ICMP Redirect schickt auf den Client um via Mikrotik zu gehen. Wenn das Endgerät allerdings ein Winblows Client ist dann blockt dieser per Default alle ICMP Steuerpakete in der lokalen Firewall. Das müsste man also erstmal anpassen damit es dann klappt.
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
So oder so ist das aber nicht der Fehler, denn ein fehlgeschlagener ICMP Redirect würde dann nur bewirken das der gesamte Traffic ins andere Netz dann weiter als "Durchlauferhitzer" immer über die FritzBüx geht statt direkt zum Mikrotik. Performanceverlust aber die Funktion an sich beeinträchtigt das nicht.

Die statischen Routen sind soweit auch richtig eingetragen, allerdings fehlt die statische Default Route auf den beiden Mikrotiks zu jeweils ihrer FritzBox im lokeln LAN. 0.0.0.0 /0 <ip_addr_lokaler_Router>
Diese sollte in jedem Falle noch nachgetragen werden damit das sauber ist !!!

Dem NAS IP Forwarding zu konfigurieren ist natürlich sinnfrei. Das ist ja als Endgerät zu sehen. Dem reicht ein Gateway auf den lokalen Router.

Ja, habe ich auch gerade gesehen

Der Redirect selbst ist scheinbar nur Beiwerk, nicht aber Ursache des Problems.
Das NAS könnte Schwierigkeiten mit den ICMP-Redirects der FritzBox haben, das würde sich aber nicht in den gezeigten "Host unreachable"-Meldungen äußern.

Dazu ist vielleicht diese Lektüre hilfreich

Man könnte testweise mal das Default Gateway der NAS Systeme auf den MT legen und checken ob das eine Veränderung im Routing Verhalten gibt.
So oder so ist das komisch und sollte so nicht passieren. Das es generell funktioniert zeigt ja auch die Tatsache das alles andere, mit Ausnahme der NAS Systeme, sauber geroutet wird.

Hat das NAS eine eigene Firewall? Oder evtl eine Virtualisierung/Docker, das die Netzwerkbrücke verzögert startet?

Zitat von @aqui:

Deshalb bleibt die spannende Frage ob der TO beim Mikrotik die Default Konfig gelöscht hat vor dem Konfigurieren ?!!
Ohne das macht der NAT auf dem WAN Port was dann schon mal zu solchen Routing Einbahnstrassen führen kann.
Siehe auch hier:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router

Nein, habe ich nicht. Ich bin aber alle Einstellungen durchgegangen und habe diese manuell geändert bzw. angepasst. NAT ist daher auch deaktiviert, genauso wie aktuell alle Firewall Rules.

Es ist ja auch richtig das die lokale FritzBüx bei Traffic ins andere Netz einen ICMP Redirect schickt auf den Client um via Mikrotik zu gehen. Wenn das Endgerät allerdings ein Winblows Client ist dann blockt dieser per Default alle ICMP Steuerpakete in der lokalen Firewall. Das müsste man also erstmal anpassen damit es dann klappt.
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen

Ich habe zwar von meinem Windows Client getestet, aber auch mein Linux-Server zeigt die gleichen Probleme. Und der Ziel-Client ist ja auch keine Win-Maschine.

So oder so ist das aber nicht der Fehler, denn ein fehlgeschlagener ICMP Redirect würde dann nur bewirken das der gesamte Traffic ins andere Netz dann weiter als "Durchlauferhitzer" immer über die FritzBüx geht statt direkt zum Mikrotik. Performanceverlust aber die Funktion an sich beeinträchtigt das nicht.

Sollte ich ICMP Redirect dann lieber deaktivieren? Reicht es, wenn ich das auf den MikroTiks mache oder müssen dann alle Geräte im Netz gleich konfiguriert sein (die Fritzboxen meine ich jetzt)?

Die statischen Routen sind soweit auch richtig eingetragen, allerdings fehlt die statische Default Route auf den beiden Mikrotiks zu jeweils ihrer FritzBox im lokeln LAN. 0.0.0.0 /0 <ip_addr_lokaler_Router>
Diese sollte in jedem Falle noch nachgetragen werden damit das sauber ist !!!

Habe ich doch? Direkt die erste Zeile in der Routes-Tabelle.

Danke schonmal für den Input. Das hilft mir doch sehr weiter bei meiner weiteren Recherche.

Zitat von @NordicMike:

Hat das NAS eine eigene Firewall? Oder evtl eine Virtualisierung/Docker, das die Netzwerkbrücke verzögert startet?

Es hat eine Firewall, die aber laut GUI deaktiviert ist. Virtualisierung kann ich mir nicht vorstellen. Synology kann ja prinzipiell ein VM Host sein, aber das System selbst wird darüber ja wahrscheinlich nicht virtuell laufen.

Zitat von @Tech1Konni:

Hi,

Das Default Gateway seines NAS zielt auf seine Fritzbox (192.168.1.1), die die > analoge statische Route zu meiner hat (also nur die Netzsegmente vertauscht)

Aqui hat es schon gesagt, änder das GW der NAS auf den Mikrotik.
Für dein Vorhaben mit Transfernetz zwischen den Mikrotiks bräuchtest du PBR auf der Fritte, weil du 3 Netze verarbeitest. Was Fritten aber nicht können.

Warum kannst Du Dir eine Virtualisierung nicht vorstellen? Es geht dabei nicht um das System selbst. Überprüfe es einfach. Schau nach ob Du in den NAS Netzwerkeinstellungen eine Brücke findest. Es scheint ja irgendwas zu sein, was verzögert gestartet wird.

Nein, habe ich nicht.

Oha ! Böses Faul !!
Das ist natürlich großer Mist !! Besser ist du nimmst das WinBox Tool und resettest die Konfig OHNE die Default Konfig !!
Dann ist der MT Router wirklich nackig und dann setzt du deine Konfig nochmal neu auf. Das sind max. 3 Mausklicks bei deinem sehr einfachen Setup.
Das ist allemal besser als die Frickelei mit der bestehenden Default Konfig.
Sehr gut möglich das das dein Fehler ist, denn eine aktive NAT Firewall sorgt genau für solche Routing Einbahnstrassen wie sie bei dir auftreten. Zudem haben sie ja auch in deinem Setup rein gar nichts zu suchen.
Zu 99% wird das in einer sauberen Routing Umgebung auch fehlerfrei funktionieren !

Hallo,

Bei der Topologie ist ja die Hinroute nicht gleich der Rückroute. Ob die Firewall hier die eingehenden Pakete den ausgehenden korrekt zuordnet? Bei einigen Routern kann man einstellen (Überprüfung der Rückroute) . Wie die Fritzbox und Microtic das handhabt, weiß ich nicht. Man könnte zumindest der Firewall dahingehend prüfen.

Grüße

lcer

Zitat von @aqui:

Nein, habe ich nicht.

Sind die Mikrotik-Geräte denn bekannt dafür, dass Einstellungen nicht zu dem passen, was im GUI bzw. im Terminal ersichtlich ist? Ich habe mir die komplette Config nach allen Einstellarbeiten via "export" ausgeben lassen und geprüft. Das sieht für mich völlig normal aus.

Die NAT-Einstellung habe ich komplett gelöscht, ebenso diverse andere Einstellungen. Ich werde es aber mal machen, sofern die anderen Maßnahmen nicht greifen. Mein Nachbar ist leider noch unterwegs, so dass ich noch nicht alles testen kann.

nicht zu dem passen, was im GUI bzw. im Terminal ersichtlich ist?

Nein, das sind sie natürlich nicht.
Nur die Default Konfig zuverwenden die quasi einen Internet NAT Router aus der Kiste macht mit 4 Ports im Bridging Mode und ein WAN Port mit NAT ist natüprlich völliger Unsinn in deiner Umgebung.
Warum sollte man diese für dich vollkommen nutzlose Grundkonfig nutzen wenn du sie dann doch nachträglich mühsam wieder löschen und anpassen musst. Wie gesagt...völlig überflüssige Mehrarbeit und auch fehlerträchtig.

Sinnvoller ist es erst gar nicht diese für dich sinnfreie Default Konfig zu laden und den MT als reine sauberen Router OHNE diese Konfig hochzufahren. Dann IP Adressen auf den Ports setzen, Routing einstellen und gut ist.
Die Frickelei mit der Default Konfig und NAT ist in jedem Falle kontraproduktiv für dein Setup.
Aktuellstes Image solltest du auch gleich flashen mit dem WinBox Tool:
https://mikrotik.com/download

So, nach ein paar Tagen möchte ich Euch noch ein Feedback geben. Auch mit all den Tipps hat das Synology NAS sich nicht recht ansprechen lassen wollen.

Mein Nachbar hat daraufhin den zweiten LAN-Port des NAS direkt an seinen HEX S angeklemmt und dort eine zweite statische IP-Adresse vergeben (192.168.1.15). Der zweite LAN-Port hat dabei als Default-Gateway den Mikrotik-Router, der erste LAN-Port zeigt weiterhin auf die FritzBox.

Das Ergebnis:
Das NAS lässt sich jetzt problemlos über beide IP-Adressen ansprechen, traceroute sieht gut aus und auch sonst klappt alles. Ich gehe davon aus, dass das NAS entweder einen Bug hat oder eine fehlerhafte Systemeinstellung, die nicht über das GUI ersichtlich ist, sondern in irgendeiner Systemdatei schlummert.

traceroute 192.168.1.3
traceroute to 192.168.1.3 (192.168.1.3), 30 hops max, 60 byte packets
 1  192.168.0.2 (192.168.0.2)  0.188 ms  0.139 ms  0.137 ms
 2  10.1.1.2 (10.1.1.2)  0.240 ms  0.236 ms  0.264 ms
 3  192.168.1.3 (192.168.1.3)  0.791 ms  0.850 ms  0.791 ms

traceroute 192.168.1.15
traceroute to 192.168.1.15 (192.168.1.15), 30 hops max, 60 byte packets
 1  fritz.box (192.168.0.1)  0.302 ms  0.336 ms  0.278 ms
 2  192.168.0.2 (192.168.0.2)  0.432 ms  0.398 ms  0.430 ms
 3  10.1.1.2 (10.1.1.2)  0.547 ms  0.473 ms  0.456 ms
 4  192.168.1.15 (192.168.1.15)  0.805 ms  0.810 ms  0.785 ms

Ich vermute, dass wir die wirkliche Ursache nicht ausfindig machen können, um das Problem nachhaltig verstehen zu können.
Solange es aber läuft, bin ich erst einmal zufrieden.

Vielen Dank nochmal für alle Tipps!

Viele Grüße
Mathias

Der zweite LAN-Port hat dabei als Default-Gateway den Mikrotik-Router, der erste LAN-Port zeigt weiterhin auf die FritzBox.

Das kann prinzipienbedingt niemals funkltionieren !
Ein Endgerät kann doch niemals 2 Default Gateways haben ! Damit kann kein Betriebssystem richtig umgehen und zeugt eher von einem Konfig Fehler des NAS.
Auch so ein Gerät kann nur immer ein einziges Default Gateway haben.

dass wir die wirkliche Ursache nicht ausfindig machen können,

Es liegt zweifelsohne an eurer falschen oder fehlerhaften IP Konfig des NAS Systemes !

Entschuldige bitte, da habe ich mich natürlich verschrieben. Natürlich kein Default Gateway aber ein zusätzliches Gateway für das zweite Interface.

Wieso "zusätzlich" ?? Auch bei 2 Interfaces kann es immer nur ein einziges Default Gateway geben was global für alle NICs gilt. Das ist in allen Betriebssystemen so ob Windows, Mac OS oder Linux was auf deinem NAS werkelt.

Man kann dedizierte statische Routen definieren aber das geht dann nicht über das GUI. Das geht nur über ein SSH Login und dann über die Konsole.
Ob das dann ein Reboot überlebt ist immer eine zweite Frage. Denn auch mit einem Admin Shell Login aufs NAS hast du keine vollständigen Root Rechte.

Zitat von @Tech1Konni:
dass das NAS entweder einen Bug hat oder eine fehlerhafte Systemeinstellung, die nicht über das GUI ersichtlich ist, sondern in irgendeiner > Systemdatei schlummert.

Nope, bei dir ist alles "works as designed", du hast nur die erweiterten Netzwerkkonfigurationen ignoriert und nicht umgesetzt, die aqui und ich dir mitgegeben haben.