Kein Zugriff auf PC im internen Netz möglich nach Windows-Update

[erich56]

Im Zuge eines Grid-Computing Projekts, an welchem ich seit Jahren teilnehme, ist es erforderlich, daß meine über den gleichen Router angeschlossenen Computer gegenseitig aufeinander zugreifen, um gewisse Dateien gegenseitig abzurufen.
Bis gestern hat das bestens funktioniert; allerdings habe ich nach dem gestern durchgeführten Windows-Update das Problem, daß auf einen der Computer von den anderen nicht mehr zugegriffen werden kann. Von diesem Computer aus kann ich zwar alle anderen Computer erfolgreich anpingen, umgekehrt aber kann er von keinem der anderen Computer angepingt werden ("Zeitüberschreitung").
Und dies sowohl bei Kabelverbindung als auch via WLAN.

Möglicherweise hat das Windows Update da irgendwas in den Windows-Defender-Firewalleinstellungen verändert - dazu habe ich jetzt in der Firewall mal in der Abteilung "Eingehende Regeln" nachgesehen, und dort eine Riesenmenge an Einträgen bemerkt, von denen manche mit grünem Häckchen am linken Rand versehen sind, andere nicht. Offen gesagt, ich habe nicht die geringste Ahnung, an welchem der Einträge ich da jetzt was verändern kann/muß, damit von meinen anderen Computern wieder auf diesen einen zugegriffen werden kann. Natürlich will ich nicht einfach wild drauf los werken und alles mögliche verändern, ohne zu wissen, was ich da tue bzw. was dabei rauskommt.
Zur Info: der Internet-Zugriff funktioniert bei diesem Computer. Weiters: ich spreche von Windows 10 Home.
Kann mir jemand zielführende Tipps geben?

 

[Aduasen]

Alle die gleiche Windows Version?
Alle Windows 11?

 

[erich56]

@Aduasen Alle Windows 10 Home

 

[st0rmmaker]

Hast du bei bei den eingehenden Regeln bereits unter Datei- und Druckerfreigabe (Echoanforderung - ICMPv4 eingehend) einen grünen Haken?

Falls ja: Das steht bei dem Eintrag unter der Spalte "Profil"?

Ich vermute einfach, dass der Rechner ggf. durch das Update in ein öffentliches Netzwerk gesteckt wurde.
Hab mal irgendein kurzes Video gefunden:

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

 

[nutrix]

Kennwort für die Netzwerkfreigabe ist gesetzt?

 

[erich56]

Hast du bei bei den eingehenden Regeln bereits unter Datei- und Druckerfreigabe (Echoanforderung - ICMPv4 eingehend) einen grünen Haken?

Falls ja: Das steht bei dem Eintrag unter der Spalte "Profil"?

Anhang anzeigen 1625699

Ich vermute einfach, dass der Rechner ggf. durch das Update in ein öffentliches Netzwerk gesteckt wurde.
Hab mal irgendein kurzes Video gefunden:

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

danke für die Hinweise - da sind beim Windows Update tatsächlich einige Berechtigungen rausgefallen (was natürlich nicht passieren sollte) - hab sie wieder scharf gestellt, und jetzt funktioniert das Ping wieder

 

[st0rmmaker]

Ping ist aber noch nicht die Dateifreigabe, das wäre noch:

Datei- und Druckerfreigabe (NB-Sitzung eingehend)

Datei- und Druckerfreigabe (SMB eingehend)

Hast du aber das Youtube-Video angeschaut und die Einstellung geprüft? Ich hatte nämlich damals mit Windows 10 1-2x den Fall, dass ich nach Updates im öffentlichen Netz (strengere Firewall Richtlinien) gelandet bin.

 

[erich56]

@st0rmmaker ja, alles berücksichtigt (und auch das Video angesehen).
Ich kann nun von anderen Rechnern auf freigegebene Dateien zugreifen (und umgekehrt). Allerdings funktioniert die eine Sache in meinem Grid-Computing, wo von einem anderen Rechner, der als HTTP-Proxy (Squid) fungiert, Dateien abgerufen werden sollen, noch immer nicht.
Mittlerweile bin ich nicht mehr sicher, ob das Problem tatsächlich an der Firewall liegt, oder anderswo.
Daher würde ich gerne - probeweise - die Firewall mal kurz abschalten, bin aber noch nicht dahinter gekommen, wie das geht. Tipps dazu?

 

[st0rmmaker]

@erich56

Ich würde sie ausschalten mit Rechtsklick auf Windows-Firewall mit erweiterter Sicherheit klicken,
auf Eigenschaften klicken und alle 3 Profile (Domänen-, Privates- und Öffentliches-Profil) kurz deaktivieren und testen.

Würde aber direkt im Anschluss die Firewall wieder anschalten. So siehst zumindest erstmal, ob es an der Firewall liegt oder nicht.

 

[erich56]

@erich56

Ich würde sie ausschalten mit Rechtsklick auf Windows-Firewall mit erweiterter Sicherheit klicken,
auf Eigenschaften klicken und alle 3 Profile (Domänen-, Privates- und Öffentliches-Profil) kurz deaktivieren und testen.

Würde aber direkt im Anschluss die Firewall wieder anschalten. So siehst zumindest erstmal, ob es an der Firewall liegt oder nicht.

Anhang anzeigen 1625934

danke für die Hinweise.
Bin jetzt mal so vorgegangen - es hat trotzdem nicht den gewünschten Erfolg gebracht :-(
Zumindest weiß ich nun, daß es NICHT an der Firewall liegt. Möglicherweise ist da beim Windows Update etwas in Unordnung gekommen.

 

[st0rmmaker]

@erich56

Schade, ich kenne das Tool oder die Logik des Datenaustauschs zwar nicht, aber läuft der Service auch und noch auf dem richtigen Port?

Aus dem ersten Post nehme ich an, dass die anderen PCs effektiv die Dateien pullen.

Du könntest in der CMD (als Admin starten) mit "netstat -ab" prüfen, ob dein Programm auf dem richtigen Port lauscht.

Zu sehen unter Local Address:
z.B. 0.0.0.0:3389 ist RDP mit TermService

Das müsste bei allen Computer für dein Programm dann gleich sein.
Ansonsten würde ich einfach eine Neuinstallation empfehlen

 

[erich56]

beiliegend das Ergebnis von "netstat -ab"

Ergänzung (8. Juni 2025)

und hier - im Vergleich dazu - das "netstat -ab" Ergebnis von einem PC, bei welchem die besagte Verbindung einwandfrei funktioniert (ASUS)

 

[st0rmmaker]

Kannst du mir noch verraten, wie du die Dateien erhälst? Läuft da ein Programm im Hintergrund? Falls ja, bräuchte ich den kompletten Namen davon

 

[erich56]

tja, bis ins letzte technische Detail kann ich es Dir leider nicht erklären, aber im wesentlichen passiert folgendes:
Das Grid Computing Projekt heißt in diesem Fall LHC@Home (ein Projekt von CERN). Von dort werden die sog. "tasks" runtergeladen, verarbeitet, und danach wieder dorthin hochgeladen.
Diese tasks ziehen jeweils zu Beginn der Verarbeitung auch einige 1000 Kleinstdateien mit runter vom CERN-Server, und das sind immer die gleichen, sie werden zur Verarbeitung der Tasks benötigt, und nach erfolgreicher Beendigung der Task wieder gelöscht.
Wenn nun, wie in meinem Fall, insgesamt 12 oder 13 PCs und Notebooks solche tasks verarbeiten, dann kommt das Internet-Modem mit der hohen Zahl von Kleinstdateien schnell an seine Grenzen; deshalb war mir ein Fachmann bei der Installation des Squid-Proxy auf einem meiner Geräte behilflich, mit dem Zweck, daß diese jeweils immer gleichen, tausenden Kleinstdateien bei Beginn einer Task nicht jedesmal über's Internet runtergezogen werden, sondern von diesem Proxy. An den beteiligten Rechnern mußte ich dazu nichts weiteres tun als einmalig in den BOINC-Einstellungen den Proxy mit der IP-Adresse 192.168.0.39 (auf diesem Notebook ist der Proxy installiert) anzugeben. Das hat nun seit ca. 2 Jahren immer bestens funktioniert, abhängig von der Art der Tasks (die sind vom Umfang her nicht immer gleich) versendet der Proxy eine knappe Million Kleinst-Dateien innerhalb 24 Stunden (fallweise auch darüber hinaus).

Und seit gestern eben kann der eine Rechner nicht mehr auf den Proxy zugreifen. Es kommt bei jedem Versuch, neue Tasks runterzuladen, in der BOINC Ereignisanzeige die Fehlermeldung "Scheduler request to https://lhcathome.cern.ch//lhcathome_cgi/cgi failed; Failure when receiving data from the peer".

Wenn ich den BOINC Einstellungen dieses Rechners den Proxy wegschalte, funktioniert alles bestens; d.h. der Rechner zieht die Dateien direkt über's Internet, nicht über den lokalen Proxy.
Ein künftiger Betrieb dieses einen Rechners ohne Proxy wäre jetzt nicht unbedingt ein Beinbruch. Allerdings würde mich brennend interessieren, was zu diesem Problem geführt hat.

Ich habe zwischenzeitlich auch sfc /scannow und danach dism laufen lassen. Ersteres hab berichtet, beschädigte Dateien gefunden und erfolgreich repariert zu haben (hatte in all den Jahren noch keinen Fall erlebt, wo eine solche Meldung nicht kam), bei zweiterem gab's keinerlei Beanstandungen.

 

[st0rmmaker]

Okay, ich hab mir mal den Spaß nur mal schnell angeschaut, also kenne ich mich nicht 100% mit der Materie aus.

Aber wenn diser Artikel stimmt https://www.rechenkraft.net/wiki/LHC@home , benötigt man für LHC@Home das Programm "BOINC". Nach der Installation sehe ich zumindest es als Programm laufen:

Und unter meinem Netstat, sehe ich auch, dass das Programm läuft und Ports öffnet:
TCP 127.0.0.1:31416 -PC:0 LISTENING
[boinc.exe]
TCP 127.0.0.1:31416 -PC:0 ESTABLISHED
[boinc.exe]

Das sehe ich auch in deinem Asus-Log:

TCP 127.0.0.1:31416 ASUS-Z170:0 ABHÖREN
[boinc.exe]
TCP 127.0.0.1:31416 ASUS-Z170:61586 HERGESTELLT
[boinc.exe]

ABER nicht bei dem Computer, bei dem es nicht funktioniert.

Daher einfach die Frage, sind die Einstellungen von dem Tool zumindest auf den Clients identisch, bzw. startet es auch automatisch?

Hier die Standard-Einstellungen:

Ansonsten empfehle ich tatsächlich, einfach das Programm neu aufzusetzen.

 

[erich56]

danke für Deine Analyse, und für die Zeit, die Du dafür aufgewendet hast :-)

ja, LHC läuft, wie auch viele andere GridComputing Projekte, unter BOINC.
Das automatische Starten von BOINC beim Booten des Rechners habe ich bei allen Geräten abgeschaltet, ich starte BOINC manuell.

Interessant ist, daß das, was Du im ASUS Log siehst, bei dem nicht funktionierenden Computer im Log nicht vorhanden ist. Wohl ein deutlicher Hinweis auf ein Problem.
Tja, vielleicht keine schlechte Idee, BOINC neu zu installieren (oder eine Reparatur laufen lassen, beides keine große Sache.

 

[erich56]

habe nun zuerst eine BOINC Reparatur-Installation durchgeführt - ergebnislos. Dann BOINC de-installiert und neu installiert - auch ergebnislos.
Werde wohl damit leben müssen, daß bei diesem System der Squid Proxy nicht einsetzbar ist.

 

[qiller]

Dann musst du in die Squid-Proxy Logdateien reinschauen was da schief läuft.

 

[erich56]

Guter Tipp, werde ich mir auch noch ansehen. Bin allerdings gespannt, ob ich dort überhaupt was sehe, da ja offensichtlich die Verbindung zum Proxy gar nicht zustande kommt.

 

[qiller]

Bin allerdings gespannt, ob ich dort überhaupt was sehe, da ja offensichtlich die Verbindung zum Proxy gar nicht zustande kommt.

Wenn in den Log-Files des Squid-Proxies keinerlei Einträge vom Problemclient auftauchen, ist das auch eine Erkenntnis: Dann stimmt etwas mit der Verbindung zum Proxy selber schon nicht. Da ja alle anderen Boinc-Clients den Proxy erreichen, würde ich dann beim Problemclient suchen.