Windows Server benutzt falsche NIC

[ntloader]

Hi,

ich habe hier zwei multihomed Windows Server 2019. Jeder der beiden Server hat 2 NICs, eine im 10.1.1.x und eine im 192.1.1.x Netz. Die Karte mit der 10er IP ist der direkte link zwischen den beiden Servern. Ich will, dass der Server darüber Dateien überträgt zu seinem Kollegen. Wenn ich also ganz nomal eine Explorer öffne und mich auf die 10.1.1.x Adresse des andere verbinde kann ich da auch Dateien hinkopieren. Schaue ich dann im Resource Monitor, sehe ich allerdings, dass die Daten über die NIC mit der 192er Adresse laufen und nicht über die mit der 10er.
Wie kann ich das umstellen, dass er wirklich die 10er Karte verwendet?

Danke, ntloader

 

[derlorenz]

Spontan würd' ich per script kopieren und da dann die jeweilige IP nutzen. Ob man das für den normalen Copy/Paste Vorgang über die GUI handeln kann, wüsste ich jetzt nicht.

 

[ntloader]

Hä? Wieso sollte man das nicht können. Ich verbinde doch einfach zu der IP und mache ein Copy&Paste.

 

[tollertyp]

Also du hast \\10.1.1.x im Explorer aufgerufen bist nicht über die Freigabe?

Was passiert, wenn du den Rechner anpingst? Mit IP und einmal mit Name? Und was passiert bei einem tracert?

Evtl sonst mal über die hosts den Namen des Servers fest mit der "richtigen" IP verdrahten...

 

[BLJ]

Das ist eine routing Frage. Beeinflussen kannst du das über die "route metric" (tiefere Zahl = bevorzugt).
Wenn du Englisch kannst, ist es hier gut erklärt:
https://www.raymond.cc/blog/choosing-which-connection-to-use-with-windows-routing-table-editor-gui/

Aber auch sonst sollten die Grafiken und das Wissen von "tiefere route metric = bevorzugt" genügen um es zu verstehen.

 

[ntloader]

Also du hast \\10.1.1.x im Explorer aufgerufen bist nicht über die Freigabe?
Was passiert, wenn du den Rechner anpingst? Mit IP und einmal mit Name? Und was passiert bei einem tracert?
Evtl sonst mal über die hosts den Namen des Servers fest mit der "richtigen" IP verdrahten...

Korrekt. Auch über die CMD ist es das selbe.
Bei Ping antwortet er mit der richtigen Adresse. Ich benutze keinen Hostnamen sondern ausschließlich die IP-Adresse. Die zweite NIC hat auch keinen Hostnamen.

Das ist eine routing Frage. Beeinflussen kannst du das über die "route metric" (tiefere Zahl = bevorzugt).
Wenn du Englisch kannst, ist es hier gut erklärt:
https://www.raymond.cc/blog/choosing-which-connection-to-use-with-windows-routing-table-editor-gui/
Aber auch sonst sollten die Grafiken und das Wissen von "tiefere route metric = bevorzugt" genügen um es zu verstehen.

Ich habe mir die Routen angesehen und denke sie passen. Die 10er ist die mit der niedrigsten Metrik. Dein Szenario das da in dem Artikel beschrieben wird passt auch nicht zu machen. Dort geht es um drum über zwei Wege auf die gleiche IP-Adresse zuzugreifen. Bei mir ist die IP Adresse aber einmal im 192er und einmal im 10er Netz.

 

[xexex]

Das ist eine routing Frage.

Im gleichen Netz wird nicht geroutet.

Hast du dir das mal angeschaut? Wird denn nur auf der zweiten NIC übertragen oder auf beiden?
https://docs.microsoft.com/en-us/pr...ows-server-2012-r2-and-2012/dn610980(v=ws.11)

 

[ntloader]

Nein, es wird wirklich nur auf einer Nic übertragen, nicht auf der falschen. Ich habs eben mal noch in die andere Richtung probiert. Also vom eigentlichen Ziel zur Quelle. Gleiches Problem.

 

[xexex]

Testweise die Firewall auf beiden Rechnern deaktiviert? Wenn die Direktverbindung auf öffentlich steht wird daran vermutlich auch kein SMB Protokoll offen sein.

 

[Evil E-Lex]

Vielleicht ist die Reihenfogle der Adapter (nicht die Route-Metric) verkehrt. Schau mal mittels:
$interfaces = Get-WmiObject Win32_NetworkAdapterConfiguration $interfaces | Format-Table InterfaceIndex, Index, ServiceName, IPAddress, Description
Ob in der Reihenfolge vielleicht der Adapter mit der 192er IP vor dem anderen auftaucht.

 

[ntloader]

Kann nix falsches daran erkennen:

InterfaceIndex Index ServiceName IPAddress                                  Description
-------------- ----- ----------- ---------                                  -----------
             8     0 kdnic                                                  Microsoft Kernel Debug Network Adapter
             3     1 rt640x64    {10.1.99.101, fe80::198d:28d7:b94a:b44f}   Realtek PCIe GBE Family Controller
             5     2 rtux64w10                                              Realtek GbE Family Controller
            10     3 Netft       {169.254.2.4, fe80::70f8:12e2:a397:2307}   Microsoft Failover Cluster Virtual Adapter
             9     4 VMSMP                                                  Hyper-V Virtual Switch Extension Adapter
             6     5 VMSNPXYMP   {192.168.1.101, fe80::1490:20ea:25f5:f5c8} Hyper-V Virtual Ethernet Adapter

Ich habe jetzt mal noch auf einem System die 192er NIC deaktiviert. Dann funktioniert der Kopiervorgang über die 10er NIC wie es sein soll. Sobald ich die 192er NIC wieder einschalte, nimmt er aber dieser dann wieder her. 😭

 

[Evil E-Lex]

Sieht gut aus meine ich. Ich hab auf die schnelle das hier gefunden:
Force network traffic through a specific NIC with SMB multichannel
Beschreibt deine Symptome recht genau, ist aber schon was älter. Vielleicht hilft es ja.

 

[BLJ]

Im gleichen Netz wird nicht geroutet.

Was du meinst ist sicher richtig. Was du schreibst ist ne andere Sache (definiere Netzwerk, definiere routing).

Wenn beim "TE" Files kopiert werden können - diese aber über die "falsche" NIC gehen, dann muss es wohl zwei Routen zum Ziel geben, oder? Eine relevante Frage ist dann wieder wie das Ziel definiert ist; eine IP oder ein Hostname? Findet evtl. ein reverse DNS lookup statt? In dem Fall, dass es jeweils nur eine Route auf eine bestimmte IP gibt, würde ich dir zustimmen, dass es nicht mit IP-level routing zu tun hat.

Ich habe mir die Routen angesehen und denke sie passen. Die 10er ist die mit der niedrigsten Metrik. Dein Szenario das da in dem Artikel beschrieben wird passt auch nicht zu machen. Dort geht es um drum über zwei Wege auf die gleiche IP-Adresse zuzugreifen. Bei mir ist die IP Adresse aber einmal im 192er und einmal im 10er Netz.

Was gibt denn tracert 10.... (10 er Ziel Adresse) zurück?
Wenn er die falsche NIC nimmt, nimmt er auch die "falsche" IP - ausser du hast routes über beide NIC zum selben Ziel (was aber von deiner Aussage zur Route-Metric widerlegt wird).
Liefert tracert nichts unerwartetes zurück, dann wird es wohl nichts mit dem IP-Level routing zu tun haben, und das Problem wird auf einer höheren Protokoll Ebene liegen (SMB?!).

 

[orioon]

Kannst du bitte ein Bild von den Routen posten / sie kopieren?
Geht mit "route print"

 

[ntloader]

Hier bitte, reicht ja der IPv4 Teil oder?
Der Server von dem die Liste stammt hat zwei IPs: 10.1.99.102 und 192.168.1.102, Gateway und DNS hat nur die 192er.

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.1.1    192.168.1.102    291
        10.1.99.0    255.255.255.0         On-link       10.1.99.102    281
      10.1.99.102  255.255.255.255         On-link       10.1.99.102    281
      10.1.99.255  255.255.255.255         On-link       10.1.99.102    281
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
      169.254.0.0      255.255.0.0         On-link     169.254.1.202    271
    169.254.1.202  255.255.255.255         On-link     169.254.1.202    271
  169.254.255.255  255.255.255.255         On-link     169.254.1.202    271
      192.168.1.0    255.255.255.0         On-link     192.168.1.102    291
    192.168.1.102  255.255.255.255         On-link     192.168.1.102    291
    192.168.1.103  255.255.255.255         On-link     192.168.1.102    291
    192.168.1.255  255.255.255.255         On-link     192.168.1.102    291
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link       10.1.99.102    281
        224.0.0.0        240.0.0.0         On-link     192.168.1.102    291
        224.0.0.0        240.0.0.0         On-link     169.254.1.202    271
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link       10.1.99.102    281
  255.255.255.255  255.255.255.255         On-link     192.168.1.102    291
  255.255.255.255  255.255.255.255         On-link     169.254.1.202    271
===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
          0.0.0.0          0.0.0.0      192.168.1.1  Default
          0.0.0.0          0.0.0.0      192.168.1.1     256
===========================================================================

 

[orioon]

Hast du die persistent routes bewusst erstellt? Die 256 Metrik dort könnte das Problem sein.

 

[ntloader]

Ne, ist nicht von mir hinzugefügt worden. Standardinstallation, hat keiner dran rumgepfuscht.

 

[BLJ]

Ne, ist nicht von mir hinzugefügt worden. Standardinstallation, hat keiner dran rumgepfuscht.

Ich zweifle daran, dass Windows von Haus aus static routes mit sich bringt (was für einen Sinn würde das machen?!). Ich habe aber auf die Schnelle keine eindeutigen Informationen dazu gefunden.

 

[Evil E-Lex]

Meine Windows 10 VM erzeugt diese statische Route von selbst:

===========================================================================
Ständige Routen:
  Netzwerkadresse          Netzmaske  Gatewayadresse  Metrik
          0.0.0.0          0.0.0.0    192.168.10.10  Standard
===========================================================================

Bei @ntloader sieht die zweite Route mit fester Metrik aber in der Tat merkwürdig aus. Die würde ich testweise entfernen.

 

[Raijin]

Da muss ich @BLJ beipflichten. Das macht Windows nur, wenn man manuell eine Route mit -p hinzufügt. Bei einer VM kann das ggf durch die VM-Umgebung geschehen sein.


Wie dem auch sei, die Metrik sollte hier aber nicht das Problem sein. Bei der Evaluierung welche Route genommen wird, kommt die Metrik als letztes Kriterium zum Einsatz. Das erste und wichtigste Kriterium ist das Matching der Route. Wenn mehrere Route matchen, zB eine Subnetz-Route und die Standard-Route, wird die spezifischere von beiden genommen (also die mit der bitweise längeren Subnetzmaske), egal welche Metrik sie hat. Je genauer die Route passt, umso eher wird sie genommen. Nur wenn zwei Routen gleich gut passen, entscheidet die Metrik - zum Beispiel wenn man zwei Standardrouten von zwei Netzwerkadaptern hat.

Da Windows automatisch für jeden Netzwerkadapter eine Route erzeugt, die genau auf das Subnetz passt, ist die Standardroute in diesem Moment vollkommen irrelevant. Das ist die Route in Zeile 6 aus #15


Leider habe ich so aus dem Stegreif keine bessere Idee, weil ich mir das Verhalten auch nicht wirklich erklären kann. Es würde mich jedoch sehr wundern, wenn es an der Metrik läge.



Mal ne Frage zur Verkabelung: Sind die beiden Server direkt miteinander verbunden, also Server <-Kabel-> Server oder hängt da noch ein Switch dazwischen, womöglich sogar derselbe Switch, an dem beide Server auch mit dem zweiten NIC hängen? Sprich: Sind die beiden Subnetze 10.1.99.0/24 und 192.168.1.0/24 physisch oder mit VLANs getrennt oder laufen sie gar parallel auf derselben Infrastruktur ohne Trennung?