3
Windows - Übertragungsoptimierung in getrennten Netzen
Hallo zusammen,
wir haben bei uns mehrere VLANs konfiguriert, dessen Kommunikation untereinander an einem Cisco SG-300 per ACLs getrennt werden. Für die Deny-ACLs habe ich Logging aktivieret.
Jetzt habe ich die angehängten Informationen in der Logfile gefundenden. Hier versuchen normale, nicht Domain gejointe Computer im VLAN 50 auf andere Windows 10 Computer im VLAN 100 auf Port 7680 zuzugreifen. Dies wird durch die ACLs natürlich verhindert. Habe dies auch kontrolliert, indem ich auf beiden Seiten ein Linux Rechner angeschlossen haben mit deaktivierter Firewall und Wireshark geöffnet hat. Wenn ich versuche die Rechner gegenseitig zu erreichen kommen keine Pakete auf der anderen Seite an. Auch keine Discovery Protokoll Pakete. Dies sollte dicht sein.
Nach Recherche habe ich rausgefunden, dass Windows Port 7680 für die "Übertragungsoptimierung" von Updates nutzt, indem es die Updates von Computern im Heimnetz lädt.
Jetzt die spannende Frage: Woher weiß Windows, dass sich unter der IP 192.168.10.40 ein weiterer nicht Domain gejointer PC befindet, von dem er sich theoretisch die Updates ziehen kann, obwohl keine Pakete in das andere VLAN gelangen?
Ist Windows mittlerweile so frech, dass der sich die Externe IP anschaut und diese zusammen mit der Internen an Microsoft schickt und wenn die Externe IP identisch ist, geht Microsoft davon aus, dass die anderen erreichbar sein müssen? Die hängen nämlich hinter dem gleichem NAT.
Ich werde das ganze deaktivieren, dennoch finde ich es spannend, wie Windows das macht. Hat da jemand nähere Informationen?
wir haben bei uns mehrere VLANs konfiguriert, dessen Kommunikation untereinander an einem Cisco SG-300 per ACLs getrennt werden. Für die Deny-ACLs habe ich Logging aktivieret.
Jetzt habe ich die angehängten Informationen in der Logfile gefundenden. Hier versuchen normale, nicht Domain gejointe Computer im VLAN 50 auf andere Windows 10 Computer im VLAN 100 auf Port 7680 zuzugreifen. Dies wird durch die ACLs natürlich verhindert. Habe dies auch kontrolliert, indem ich auf beiden Seiten ein Linux Rechner angeschlossen haben mit deaktivierter Firewall und Wireshark geöffnet hat. Wenn ich versuche die Rechner gegenseitig zu erreichen kommen keine Pakete auf der anderen Seite an. Auch keine Discovery Protokoll Pakete. Dies sollte dicht sein.
Nach Recherche habe ich rausgefunden, dass Windows Port 7680 für die "Übertragungsoptimierung" von Updates nutzt, indem es die Updates von Computern im Heimnetz lädt.
Jetzt die spannende Frage: Woher weiß Windows, dass sich unter der IP 192.168.10.40 ein weiterer nicht Domain gejointer PC befindet, von dem er sich theoretisch die Updates ziehen kann, obwohl keine Pakete in das andere VLAN gelangen?
Ist Windows mittlerweile so frech, dass der sich die Externe IP anschaut und diese zusammen mit der Internen an Microsoft schickt und wenn die Externe IP identisch ist, geht Microsoft davon aus, dass die anderen erreichbar sein müssen? Die hängen nämlich hinter dem gleichem NAT.
Ich werde das ganze deaktivieren, dennoch finde ich es spannend, wie Windows das macht. Hat da jemand nähere Informationen?
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: 383321
Url: https://administrator.de/contentid/383321
Ausgedruckt am: 17.11.2024 um 01:11 Uhr
3 Kommentare
Neuester Kommentar
Woher weiß Windows, dass sich unter der IP 192.168.10.40 ein weiterer nicht Domain gejointer PC befindet, von dem er sich theoretisch die Updates ziehen kann, obwohl keine Pakete in das andere VLAN gelangen?
Hast du den IP Helper auf den VLANs aktiviert, damit DHCP in die VLANs injiziert wird? Damit lässt du Broadcast Traffic in die einzelnen VLANs und VLAN-übergreifend zu.
Über die externe IP geht das nicht, das siehst du ja anhand von deinem Log.
Wenn ich das richtig weiß, wird ein Broadcast-Paket nicht geroutet. Folglich verlässt ein Broadcast ein VLAN nicht 
Wäre ja auch Blödsinnig, da man VLANs ja gerade nutzt um den Broadcast-Strom klein zu halten. Ich habe zumindest noch keine Broadcast-ARP Pakete im VLAN entdeckt die da nicht hingehören .
Und ein DHCP-Relay sollte eigentlich nur das DHCP-Offer-Broadcast-Paket "auffangen" und dann als Unicast an den entsprechenden DHCP Server weiterleitet.
Ich habe DHCP-Relay aktiviert. IP-Helper nicht explizit. Selbst wenn, ist der nicht dafür da um Broadcast in Unicast umzusetzen und an eine definierte IP weiterzuleiten? So wie es eben bei DHCP erforderlich ist?
Ich meine auch nicht die externe IP:
Folgende Theorie:
Windows schickt folgende Infos eines PCs nach Hause: Interne IP (192.168.10.40 und externe IP). Microsoft schaut in seiner Datenbank, welche Clients er zur gleichen Externen IP findet und teilt dies seinen Clients mit, dass sich im selben Netzwerk scheinbar ein Client befindet, von dem es seine Daten laden kann
Wäre ja auch Blödsinnig, da man VLANs ja gerade nutzt um den Broadcast-Strom klein zu halten. Ich habe zumindest noch keine Broadcast-ARP Pakete im VLAN entdeckt die da nicht hingehören .Und ein DHCP-Relay sollte eigentlich nur das DHCP-Offer-Broadcast-Paket "auffangen" und dann als Unicast an den entsprechenden DHCP Server weiterleitet.
Ich habe DHCP-Relay aktiviert. IP-Helper nicht explizit. Selbst wenn, ist der nicht dafür da um Broadcast in Unicast umzusetzen und an eine definierte IP weiterzuleiten? So wie es eben bei DHCP erforderlich ist?
Ich meine auch nicht die externe IP:
Folgende Theorie:
Windows schickt folgende Infos eines PCs nach Hause: Interne IP (192.168.10.40 und externe IP). Microsoft schaut in seiner Datenbank, welche Clients er zur gleichen Externen IP findet und teilt dies seinen Clients mit, dass sich im selben Netzwerk scheinbar ein Client befindet, von dem es seine Daten laden kann
Zitat von @Waishon:
Wenn ich das richtig weiß, wird ein Broadcast-Paket nicht geroutet. Folglich verlässt ein Broadcast ein VLAN nicht Wäre ja auch Blödsinnig, > da man VLANs ja gerade nutzt um den Broadcast-Strom klein zu halten. Ich habe zumindest noch keine Broadcast-ARP Pakete im VLAN > entdeckt die da nicht hingehören .
Wenn ich das richtig weiß, wird ein Broadcast-Paket nicht geroutet. Folglich verlässt ein Broadcast ein VLAN nicht
Wäre ja auch Blödsinnig, > da man VLANs ja gerade nutzt um den Broadcast-Strom klein zu halten. Ich habe zumindest noch keine Broadcast-ARP Pakete im VLAN > entdeckt die da nicht hingehören .Das ist korrekt, bis zu dem Zeitpunkt, wo du den IP Helper konfigurierst.
Ich hatte mal ne Klimaanlage mit ner fehlerhaften DHCP-Funktion, die alle VLANs geflutet mit DHCP-Anfragen geflutet hat, in denen der IP-Helper aktiv war. Aufgefallen ist das nur in einem VLAN, weil der Broadcast-Storm alle 10MBit/s-Haldduplex-Cisco-ATA-Boxen abgeschossen hat. Deshalb verlass dich da am besten nicht drauf.
Was sagt denn Wireshark, wenn du nach TCP 7680 filterst?
