9
QNAP + VLAN - Verständnisproblem
Hallo,
ich habe gerade ein Verständnisproblem:
Wenn ich aus VLAN11 (IP10.10.0.101) mein QNAP NAS anpinge, in VLAN22 (IP10.10.4.101), sollte eigentlich keine Antwort kommen, weil ich auf dem NAS-Interface kein Gateway definiert habe.
Das QNAP ist mit einem Bonding-Interface angebunden (VLAN11 als Native-VLAN und VLAN22 tagged vom Switch kommend). Mit je einer IP aus jedem Netz aber ohne Gateway.
Der Ping sollte zwar bis zum NAS kommen, aber wegen des fehlenden Gateways nicht zurück.
Das erstaunliche ist aber, es kommt eine Antwort auf den Ping und zwar mit einer TTL=64 und der IP10.10.4.101 (die ja gar nicht in dem VLAN11) liegt.
Ich werde daraus nicht schlau. Der Router sieht zwar den Ping, aber er sieht keinen Pong (also die Rückantwort) und macht auch kein SNAT. Das bestätigt auch die TTL=64, die müsste ja, wenn es geroutet worden wäre auf 63 (oder 127) stehen. Wie kommt das? Ist das ein Bug von QNAP? Das über das untagged Interface geantwortet wird und nicht über das eigentliche tagged Interface?
Wenn ich das Gleiche mit einem Win-Server teste, verhält es sich wie erwartet. Keine Antwort von der VLAN22-IP.
Bei QNAP, eine Antwort von einem Interface aus einem anderen VLAN und ohne Gateway?! o_O
ich habe gerade ein Verständnisproblem:
Wenn ich aus VLAN11 (IP10.10.0.101) mein QNAP NAS anpinge, in VLAN22 (IP10.10.4.101), sollte eigentlich keine Antwort kommen, weil ich auf dem NAS-Interface kein Gateway definiert habe.
Das QNAP ist mit einem Bonding-Interface angebunden (VLAN11 als Native-VLAN und VLAN22 tagged vom Switch kommend). Mit je einer IP aus jedem Netz aber ohne Gateway.
Der Ping sollte zwar bis zum NAS kommen, aber wegen des fehlenden Gateways nicht zurück.
Das erstaunliche ist aber, es kommt eine Antwort auf den Ping und zwar mit einer TTL=64 und der IP10.10.4.101 (die ja gar nicht in dem VLAN11) liegt.
Ich werde daraus nicht schlau. Der Router sieht zwar den Ping, aber er sieht keinen Pong (also die Rückantwort) und macht auch kein SNAT. Das bestätigt auch die TTL=64, die müsste ja, wenn es geroutet worden wäre auf 63 (oder 127) stehen. Wie kommt das? Ist das ein Bug von QNAP? Das über das untagged Interface geantwortet wird und nicht über das eigentliche tagged Interface?
Wenn ich das Gleiche mit einem Win-Server teste, verhält es sich wie erwartet. Keine Antwort von der VLAN22-IP.
Bei QNAP, eine Antwort von einem Interface aus einem anderen VLAN und ohne Gateway?! o_O
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 574083
Url: https://administrator.de/contentid/574083
Ausgedruckt am: 24.11.2024 um 02:11 Uhr
9 Kommentare
Neuester Kommentar
Moin,
Daran, daß das QNAP, selbst "routen" könnte und daher das Antwortpaket gleich auf dem "richtigen" Interface rausschickt hast Du gedacht? Denn so wie Du es schreibst, hängt es ja schon im richtigen Netz. Dann braucht es kein Gateway für die korrekte Antwort.
Edit:
Nach nochmaligem durchlesen Deines Post habe ich festgestellt, daß sich das QNAp durchaus korrekt verhält.
Es bekommt einen icmp-echo-request Durch Interface A aus einem Netz, daß an Interface B sitzt. Die icmp-echo-replay geht an eine IP-Adresse die an Interface B sitzt, also wird sie direkt rausgeschickt statt über Interface A. Daß die eigene Sender-IP dabei aus Netz A ist, ist unerheblich.
Diese Verhalten ist Standard bei den meisten IP-Stacks. Warum das Windows anders macht ist das Geheimnis von MS (oder die Firewall-Einstellungen geben das vor).
lks
PS: Es gibt Diskussionen zwischen den Entwicklern, ob man ein IP-Paket, als legitim ansieht, dessen Absender eigentlich an einem anderen Interface sitzen müßte und daher das Paket am falschen Interface ankommt. Daher soll das Paket verworfen werden. Je nachdem, wer sich jetzt um die Zusammenstellugen einer Distribution kümmert gibt es das verhalten von "MS" oder das verhalten von "QNAP", sofern der Benutzer das nicht anders einstellt.
Daran, daß das QNAP, selbst "routen" könnte und daher das Antwortpaket gleich auf dem "richtigen" Interface rausschickt hast Du gedacht? Denn so wie Du es schreibst, hängt es ja schon im richtigen Netz. Dann braucht es kein Gateway für die korrekte Antwort.
Edit:
Nach nochmaligem durchlesen Deines Post habe ich festgestellt, daß sich das QNAp durchaus korrekt verhält.
Es bekommt einen icmp-echo-request Durch Interface A aus einem Netz, daß an Interface B sitzt. Die icmp-echo-replay geht an eine IP-Adresse die an Interface B sitzt, also wird sie direkt rausgeschickt statt über Interface A. Daß die eigene Sender-IP dabei aus Netz A ist, ist unerheblich.
Diese Verhalten ist Standard bei den meisten IP-Stacks. Warum das Windows anders macht ist das Geheimnis von MS (oder die Firewall-Einstellungen geben das vor).
lks
PS: Es gibt Diskussionen zwischen den Entwicklern, ob man ein IP-Paket, als legitim ansieht, dessen Absender eigentlich an einem anderen Interface sitzen müßte und daher das Paket am falschen Interface ankommt. Daher soll das Paket verworfen werden. Je nachdem, wer sich jetzt um die Zusammenstellugen einer Distribution kümmert gibt es das verhalten von "MS" oder das verhalten von "QNAP", sofern der Benutzer das nicht anders einstellt.
1
Hallo,
das ist ja hoch interessant, das es diesbezüglich zwei Philosophien gibt!
Das war mir bisher weder bekannt noch wäre es mir aufgefallen.
Um es nochmal etwas abgekürzt zu beschreiben:
QNAP (hat keine defnierten Gateways):
Hinweg: PC[VLAN11] -> Router -> QNAP[VLAN22]
Rückweg: QNAP[VLAN11] -> PC[VLAN11]
WinSRV (hat ebenfalls keine defnierten Gateways):
Hinweg: PC[VLAN11] -> Router -> WinSRV[VLAN22]
Rückweg: WinSRV[VLAN22] -> Ende, da kein Gateway definiert ist
Edit: hat dieses Verhalten einen Namen? Ich würde dazu gerne recherchieren?
Kann man MS so einstellen, dass es sich wie QNAP verhält (wobei meiner eignen Philosophie nach der MS-Weg sinniger ist).
das ist ja hoch interessant, das es diesbezüglich zwei Philosophien gibt!
Das war mir bisher weder bekannt noch wäre es mir aufgefallen.
Um es nochmal etwas abgekürzt zu beschreiben:
QNAP (hat keine defnierten Gateways):
Hinweg: PC[VLAN11] -> Router -> QNAP[VLAN22]
Rückweg: QNAP[VLAN11] -> PC[VLAN11]
WinSRV (hat ebenfalls keine defnierten Gateways):
Hinweg: PC[VLAN11] -> Router -> WinSRV[VLAN22]
Rückweg: WinSRV[VLAN22] -> Ende, da kein Gateway definiert ist
Edit: hat dieses Verhalten einen Namen? Ich würde dazu gerne recherchieren?
Kann man MS so einstellen, dass es sich wie QNAP verhält (wobei meiner eignen Philosophie nach der MS-Weg sinniger ist).
Zitat von @ITgustel:
Hinweg: PC[VLAN11] -> Router -> WinSRV[VLAN22]
Rückweg: WinSRV[VLAN22] -> Ende, da kein Gateway definiert ist
Hinweg: PC[VLAN11] -> Router -> WinSRV[VLAN22]
Rückweg: WinSRV[VLAN22] -> Ende, da kein Gateway definiert ist
Oder Ende, weil das Paket am falschen Interface reinkommt und daher erst gar nicht durchgelassen wird.
Welches von beiden Varianten man hier hat, müßte man durch debuggibg erstmal eruieren.
lks
Zitat von @ITgustel:
WinSRV (hat ebenfalls keine defnierten Gateways):
Hinweg: PC[VLAN11] -> Router -> WinSRV[VLAN22]
Rückweg: WinSRV[VLAN22] -> Ende, da kein Gateway definiert ist
WinSRV (hat ebenfalls keine defnierten Gateways):
Hinweg: PC[VLAN11] -> Router -> WinSRV[VLAN22]
Rückweg: WinSRV[VLAN22] -> Ende, da kein Gateway definiert ist
Hallo.
Das könnte aber auch zum einen daran liegen, dass der WinSVR keine zweite NIC in VLAN11 konfiguriert hat.
Zum anderen musst Du bei Windows immer die ICMP Pakete (Echo Anforderung) in der Firewall explizit erlauben.
Edit: hat dieses Verhalten einen Namen? Ich würde dazu gerne recherchieren?
Aktuell würde ich es mit "works as designed"
umschreiben.
Gruß
Radiogugu
Hallo, der Win-Server hat - wie das QNAP - eine vNIC im VLAN11 und eine vNIC in VLAN22. Die Firewall auf dem Server ist abgeschalten.
Oder spuckt da trotz abgeschaltener Firewall noch irgendwas rein?
Die Edge-Firewall lässt Verbindungen aus VLAN11 überall hin zu.
Ergebnis bleibt gleich:
PC[VLAN11] -> Router -> WinSRV[VLAN22] -> keine Antwort
Das ist für mich schlüssig, das Interface wo die Anfrage reinkommt hat kein Gateway, das Ziel der Antwort liegt in einem entfernten Netz. Also müsste ja zwangsläufig über das Gateway gegangen werden.
PC[VLAN11] -> Router -> QNAP[VLAN22] -> Antwort via VLAN11 mit der Absender-IP aus VLAN22
Hier wird quasi geschaut, ob ein anderes Interface in dem Netz der Anfrage liegt und dann darüber geantwortet wird.
Oder spuckt da trotz abgeschaltener Firewall noch irgendwas rein?
Die Edge-Firewall lässt Verbindungen aus VLAN11 überall hin zu.
Ergebnis bleibt gleich:
PC[VLAN11] -> Router -> WinSRV[VLAN22] -> keine Antwort
Das ist für mich schlüssig, das Interface wo die Anfrage reinkommt hat kein Gateway, das Ziel der Antwort liegt in einem entfernten Netz. Also müsste ja zwangsläufig über das Gateway gegangen werden.
PC[VLAN11] -> Router -> QNAP[VLAN22] -> Antwort via VLAN11 mit der Absender-IP aus VLAN22
Hier wird quasi geschaut, ob ein anderes Interface in dem Netz der Anfrage liegt und dann darüber geantwortet wird.
Zitat von @ITgustel:
Ergebnis bleibt gleich:
PC[VLAN11] -> Router -> WinSRV[VLAN22] -> keine Antwort
Das ist für mich schlüssig, das Interface wo die Anfrage reinkommt hat kein Gateway, das Ziel der Antwort liegt in einem entfernten Netz. Also müsste ja zwangsläufig über das Gateway gegangen werden.
Ergebnis bleibt gleich:
PC[VLAN11] -> Router -> WinSRV[VLAN22] -> keine Antwort
Das ist für mich schlüssig, das Interface wo die Anfrage reinkommt hat kein Gateway, das Ziel der Antwort liegt in einem entfernten Netz. Also müsste ja zwangsläufig über das Gateway gegangen werden.
Nein, denn wenn die Widows-Kiste auch im VLAN11 eine NIC hat und auch eine dazu passende IP-Adresse, darf der normalerweise gar nicht über VLAN22 antworten sondern über die VLAN11-NIC direkt, weil das Ziel nämlich direkt an diesem Interface ist. Die Windows-Kiste kennt ja das Ziel. Du kannst mit route print oder netstat -r die Tabelle nachschauen.
Das einzige was da dazwischenspucken kann sind implizite oder explizite Firewall-Regeln. Wenn die Windows-Firewall ausgestellt ist, wird vermutlich der TCP-Stack das Paket schon beim Eingang verworfen haben, weil es "vom falschen Interface" kommt. Wirf doch einfach mal wireshark an.
lks
Wenn ich aus VLAN11 (IP10.10.0.101) mein QNAP NAS anpinge, in VLAN22 (IP10.10.4.101), sollte eigentlich keine Antwort kommen, weil ich auf dem NAS-Interface kein Gateway definiert habe.
Die Aussage ist Unsinn, denn ohne das du eine gültige Subnetzmaske angibst kann das stimmen oder auch nicht.Mit einem mindestens 21 Bit Prefix (255.255.248.0) oder kleiner ist das Interface also immer pingbar.
Die Aussage ist so also ziemlich sinnfrei.
Fazit:
Vermutlich falsche Subnetzmaske, dann klappt der Ping auch ohne Gateway.
Oder...deine VLAN Konfig ist falsch so das das Interface 2 IP Adressen in einer gemeinsamen Layer 2 Domain hat und nicht getrennt in 2 wie bei 2 VLANs.
Auch möglich das du das komplett falsche Bonding Verfahren (LAG) angewendet hast ?!
Der Switch versteht ausschliesslich nur LACP LAGs nach dem 802.13ad Standard.
Hallo zusammen,
ich habe das Ganze mal mit simuliert, mit zwei Mikrotik Routern. Die verhalten sich wie das QNAP, sprich, es antwortet die angesprochene IP, aber direkt auf dem VLAN des Senders mit einer TTL=64.
Jetzt wäre die Frage warum die MS-Server sich nicht so verhalten. Kann das vielleicht mit dem aktivierten NIC-Teaming oder virtuellen Switchen zu tun haben? Ich habe leider keinen Win-Server mit zwei physischen NICs zum testen. Sonst würde ich mal testen ob das ein Standardverhalten von MS ist, bzw. ab wann das auftritt (ab Zeitunkt NIC-Teaming, oder Virtueller Switch). Deshalb lass ich es gut sein :D
ich habe das Ganze mal mit simuliert, mit zwei Mikrotik Routern. Die verhalten sich wie das QNAP, sprich, es antwortet die angesprochene IP, aber direkt auf dem VLAN des Senders mit einer TTL=64.
Jetzt wäre die Frage warum die MS-Server sich nicht so verhalten. Kann das vielleicht mit dem aktivierten NIC-Teaming oder virtuellen Switchen zu tun haben? Ich habe leider keinen Win-Server mit zwei physischen NICs zum testen. Sonst würde ich mal testen ob das ein Standardverhalten von MS ist, bzw. ab wann das auftritt (ab Zeitunkt NIC-Teaming, oder Virtueller Switch). Deshalb lass ich es gut sein :D
Hi Leute,
die Sache hat mir nach wie vor keine Ruhe gelassen, warum sich MS, QNAP und Linux hier unterschiedlich verhalten.
Inzwischen bin ich dazu gekommen weiter nachzuforschen und habe die Lösung gefunden! :D
Es gibt wirklich zwei Philosophien wie der IP-Stack damit umgeht. Das "Weak Host Model" und das "Strong Host Model":
https://en.wikipedia.org/wiki/Host_model
Windows hat mit Vista/Server 2008 vom Weak auf das Strong Model gewechselt:
https://docs.microsoft.com/en-us/previous-versions/technet-magazine/cc13 ...
Linux/CentOS (ab V6) nutzt eine ähnliche Implemntierung. Die "RP Filter" (Reverse Path Filter):
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6 ...
Standard ist seit CentOS6 der Strict Mode (1), ähnlich dem Strong Host Model von Microsoft.
Das erklärt, warum die Windows und CentOS Server nicht auf den Ping antworten.
QNAP nutzt in seinem Linux den "No source validation Mode" (0). Der dem Weak Mode von Microsoft ähnelt.
Und das erklärt warum QNAP auf den Ping antwortet, MS/RHEL/CentOS aber nicht.
Wenn man bei MS mit (administratives CMD):
den Modus umstellt, geht bei Windows auch der Ping.
Bei Linux wären die Befehle analog dazu (Loose Mode):
Auch hier wird dann auf den Ping geantwrotet.
Vielleicht nutz die Info mal jemand, der diesen Thread findet.
Mir war es jedenfalls neu, dass es hier zwei Philosophien gibt.
Grüße
die Sache hat mir nach wie vor keine Ruhe gelassen, warum sich MS, QNAP und Linux hier unterschiedlich verhalten.
Inzwischen bin ich dazu gekommen weiter nachzuforschen und habe die Lösung gefunden! :D
Es gibt wirklich zwei Philosophien wie der IP-Stack damit umgeht. Das "Weak Host Model" und das "Strong Host Model":
https://en.wikipedia.org/wiki/Host_model
Windows hat mit Vista/Server 2008 vom Weak auf das Strong Model gewechselt:
https://docs.microsoft.com/en-us/previous-versions/technet-magazine/cc13 ...
Linux/CentOS (ab V6) nutzt eine ähnliche Implemntierung. Die "RP Filter" (Reverse Path Filter):
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6 ...
Standard ist seit CentOS6 der Strict Mode (1), ähnlich dem Strong Host Model von Microsoft.
Das erklärt, warum die Windows und CentOS Server nicht auf den Ping antworten.
QNAP nutzt in seinem Linux den "No source validation Mode" (0). Der dem Weak Mode von Microsoft ähnelt.
Und das erklärt warum QNAP auf den Ping antwortet, MS/RHEL/CentOS aber nicht.
Wenn man bei MS mit (administratives CMD):
netsh interface ipv4 set interface "NIC-A" weakhostsend=enabled
netsh interface ipv4 set interface "NIC-A" weakhostreceive=enabled Bei Linux wären die Befehle analog dazu (Loose Mode):
sudo sysctl -w "net.ipv4.conf.default.rp_filter=2"
sudo sysctl -w "net.ipv4.conf.all.rp_filter=2" Vielleicht nutz die Info mal jemand, der diesen Thread findet.
Mir war es jedenfalls neu, dass es hier zwei Philosophien gibt.
Grüße
