Ich kann nicht über LAN auf meinen Computer zugreifen

467
Feyyaz

Ich kann meinen Computer auch nicht von einem anderen Gerät aus innerhalb eines LANs per Ping erreichen. Ich habe folgendes versucht:

  1. Aktiviert Netzwerkerkennung, Datei- und Druckerfreigabe, Ordnerfreigabe im Netzwerk und Freigabecenter
  2. In Symantec ntp wurde eine Regel allow_all für beide Richtungen erstellt
  3. Deaktiviert alle Komponenten von Symantec Endpoint Security (NTP, PTP oder sogar Virenschutz)
  4. Eingehende Regel für das ICMPv4-Protokoll in der Windows-Firewall erstellt
  5. Windows-Firewall deaktiviert

Nach Schritt 2 befanden sich in Symantec Packet Logs noch einige Protokolle über blockierte eingehende und ausgehende Anforderungen von IP 0.0.0.0:0 bis 0.0.0.0:0. Die angewendeten Regeln waren "Block_all" und "Build-In Allow IP-Datenverkehr zulassen" (die in der Liste der Firewall-Regeln nicht vorhanden waren). Das Detail lautet:

Ethernet II (Packet Length: 42) Destination: c4-9a-02-12-6a-dd Source: 34-02-86-98-40-fe Type: ARP (0x0806) Address Resolution Protocol (ARP) Hardware type: Ethernet (0x0001) Protocol type: IP (0x0800) Hardware size: 6 Protocol size: 4 Opcode: Response Sender hardware address: 34-02-86-98-40-fe Sender IP address: 192.168.1.101 Target hardware address: c4-9a-02-12-6a-dd Target IP address: 192.168.1.104 

Hinweis: 192.168.1.104 ist das Gerät, das eine Ping-Anforderung sendet.

2
Sie haben Informationen zu einer [ARP] (https://en.wikipedia.org/wiki/Address_Resolution_Protocol) -Anforderung und nicht zu einem [Ping] (https://en.wikipedia.org/wiki/Ping_%28networking_utility) angezeigt % 29) [ICMP] (https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol). ARP ist der Mechanismus, durch den ein System die [MAC-Adresse] (https://en.wikipedia.org/wiki/MAC_address) lernt, z. B. c4-9a-02-12-6a-dd für 192.168.1.104 , einer IP-Adresse zugeordnet. Wenn ARP blockiert ist, können Systeme überhaupt nicht kommunizieren. Verwenden Sie sowohl Symantec-Firewall-Software als auch die Microsoft Windows-Firewall? moonpoint vor 8 Jahren 0
Haben Sie Ping-Tests von dem System aus ausgeführt, auf das Sie nicht zugreifen können? Haben Sie die Tests in die entgegengesetzte Richtung ausgeführt? Wenn B das System ist, auf das Sie nicht zugreifen können, und A kein Ping an B, kann B Ping A? Kann die IP-Adresse des Routers per Ping gesendet werden? Haben Sie versucht, B von mehreren Systemen aus anzupingen? Wenn Sie nicht mehr als ein System zum Ping von B haben, kann nur A erfolgreich A andere IP-Adressen pingen? moonpoint vor 8 Jahren 0
@moonpoint gab es nur ARP-Anfragen. Richtig, das ist die MAC-Adresse für 192.168.1.104. Zuerst war die Firewall von Symantec und Windows aktiv, dann habe ich beide deaktiviert. Feyyaz vor 8 Jahren 0
@moonpoint, B kann A und andere Geräte anpingen, A kann an andere Geräte anpingen. Aber ich habe mehrere Geräte zum Ping B ausprobiert, kein Glück. Und das ist nicht das einzige Problem. Ich kann nicht auf einen HTTP-Dateiserver unter B zugreifen, er kann nicht mit einem Chromecast-Gerät kommunizieren. Die Hauptursache für ARP-Blöcke, ICMP-Blöcke und andere Probleme ist wahrscheinlich die gleiche. Feyyaz vor 8 Jahren 0

3 Antworten auf die Frage

1
Carl B

Haben Sie die Remote-Einstellungen angepasst? Klicken Sie mit der rechten Maustaste auf Arbeitsplatz, klicken Sie auf Remote-Einstellungen, und stellen Sie sicher, dass das Kontrollkästchen aktiviert ist. Aktivieren Sie im erweiterten Kontrollkästchen das Kontrollkästchen Remoteunterstützung zulassen

11111

enter image description here

enter image description here

Ja, sie sind angekreuzt Feyyaz vor 8 Jahren 0
Auf einem Windows-System könnte dies möglicherweise erklären, warum [RDP] (https://en.wikipedia.org/wiki/Remote_Desktop_Protocol) nicht funktioniert, aber nicht erklären, warum ein System keine ICMP-Echoantworten (https) sendet : //en.wikipedia.org/wiki/Ping_%28networking_utility%29#Echo_reply) an ICMP [Echoanfragen] (https://en.wikipedia.org/wiki/Ping_%28networking_utility%29#Echo_request), die vom Ping gesendet werden Dienstprogramm auf einem anderen System. moonpoint vor 8 Jahren 0
1
cloudnyn3

ARP- und ICMP-Pakete (Echo-Requests oder Ping-Pakete) werden oftmals vollständig deaktiviert. Sie müssen alles nach und nach vollständig deaktivieren, bis Sie das Problem behoben haben. Ich würde persönlich Wireshark öffnen und sehen, wohin die Pakete gehen oder fallen gelassen werden. Wireshark kann an der Firewall vorbei lesen. Sie können feststellen, ob es sich nur um Ihren Computer oder Ihren sendenden Computer handelt.

Ich öffnete Wireshark und schickte eine neue Ping-Anfrage. Leider habe ich keine Anfragen von 192.168.1.104 gesehen. Das sendende Gerät kann andere Geräte pingen. Feyyaz vor 8 Jahren 1
Haben Sie "tracert" ausprobiert, verwendet es einen anderen Port und einen anderen Pakettyp, sodass es möglicherweise nicht durch irgendetwas gekennzeichnet wird. cloudnyn3 vor 8 Jahren 0
Ich muss sagen, dass es sich bei 9/10 normalerweise um die Firewall oder um ein Sicherheitssystem handelt. Ich beschäftige mich ALLES bei der Arbeit. Windows hat auch eine Fülle von Einstellungen, um die Leute fernzuhalten. Ich würde JEDE einzelne Sicherheitsfunktion abschalten, die Sie sich vorstellen können, und nachsehen, was genau das Problem verursacht. cloudnyn3 vor 8 Jahren 0
Traceroute schlägt auch fehl. Ich denke schon, aber ich weiß nicht, was ich sonst deaktivieren sollte. Feyyaz vor 8 Jahren 0
Haben Sie auf diese Maschine portforward? Möglicherweise müssen Sie auch die Firewall des Routers deaktivieren, falls vorhanden. Ich vertraue der Firewall meines Computers so, dass ich sie nicht benutze. Ich habe seltsame Probleme wegen Geräte-Firewalls. cloudnyn3 vor 8 Jahren 0
@ cloudnyn3, [traceroute] (https://en.wikipedia.org/wiki/Traceroute) sendet [UDP] (https://en.wikipedia.org/wiki/User_Datagram_Protocol) -Datagramme an Ports mit hoher Nummer, aber Microsofts Tracert verwendet ICMP-Pakete genauso wie Ping - siehe [Tracert] (https://technet.microsoft.com/de-de/library/cc940128.aspx). Wenn er Zugriff auf ein Linux / OS X-System im LAN hatte, führt die Verwendung von Traceroute möglicherweise zu unterschiedlichen Ergebnissen, die Verwendung von Tracert von Microsoft führt jedoch wahrscheinlich zu denselben Ergebnissen. moonpoint vor 8 Jahren 2
@moonpoint Danke, dass du mich korrigiert hast. Ich entschuldige mich = P cloudnyn3 vor 8 Jahren 0
@moonpoint, ich habe einen Mac für Traceroute benutzt, es schlägt immer noch fehl. Feyyaz vor 8 Jahren 0
@Feyyaz, da Wireshark keine ICMP-Echoanfragen sah, können Sie die Netzwerkverbindung für das .101-System an einen anderen Port des Switches, Routers oder der Firewall verschieben, an die es angeschlossen ist. Haben Sie ein anderes Netzwerkkabel, das Sie dafür ausprobieren könnten? Dh können Sie ein Kabel- oder Portproblem ausschließen? Diese scheinen jedoch keine wahrscheinlichen Ursachen zu sein, wenn das .101-System andere Systeme pingen kann. Ich nehme an, dass beide Systeme .101 und .104 die gleiche Subnetzmaske haben. moonpoint vor 8 Jahren 0
@Feyyaz Es scheint, als wäre es entweder etwas, das Sie auf Ihrem Betriebssystem nicht ausgeschaltet haben, oder ein physisches Problem. Es besteht die Möglichkeit, dass ein anderer Dienst unabhängig von den von Ihnen verwendeten Anwendungen ist, die dies verursachen könnten. Ich würde vorübergehend die Startelemente ausschalten und im abgesicherten Modus neu starten, wobei absolut nichts anderes als Notwendigkeiten ausgeführt wird. Sehen Sie, ob das überhaupt hilft, und wie Moonpoint gesagt hat, wenn sie anders vernetzt sind, kann dies leicht zu Verwirrung führen. cloudnyn3 vor 8 Jahren 1
@Feyyaz, versuchen Sie den abgesicherten Modus, wie von cloudyn3 vorgeschlagen, und versuchen Sie es mit einer Linux-CD [live CD] (https://en.wikipedia.org/wiki/Live_CD). Es gibt viele Linux-Distributionen, für die eine Live-CD verfügbar ist, z. B. [Die LiveCD-Liste] (https://livecdlist.com/). Wenn dies funktioniert, würde dies bestätigen, dass das Problem innerhalb des Betriebssystems auf einem Niveau liegt, das den Netzwerkdienst in Windows selbst im abgesicherten Modus beeinträchtigt. moonpoint vor 8 Jahren 0
Es fällt auch im abgesicherten Modus aus. Aber ich glaube jetzt, dass es einen Dienst gibt, der ihn blockiert, weil ich angefangen habe, von meinem Mac aus zu pinggen, da dies immer wieder fehlschlug (Timeout). Dann habe ich den Zielcomputer neu gestartet, auf dem Windows-Logo-Bildschirm (Initialisierung), die Mac-Ping-Ergebnisse in "sendTo: Host is down" geändert, und direkt nach dem Aufrufen des Windows-Desktopbildschirms kehrten die Ping-Ergebnisse wieder zurück. Ich werde Ubuntu auch live ausprobieren, danke. Feyyaz vor 8 Jahren 0
@moonpoint, ich habe Ubuntu Live ausprobiert. Es funktioniert gut. Das Problem muss also Windows sein. Es gibt ein anderes Programm, das ich zuerst vermutet hätte: Checkpoint Endpoint Security. Ich habe die Windows-Dienste deaktiviert, Ping ist erneut fehlgeschlagen, aber das scheint mir immer noch die verdächtigste App zu sein. Arbeiten daran.. Feyyaz vor 8 Jahren 0
0
Feyyaz

Nun, das Problem war weder Windows-Firewall noch Symantec. Wie einige von Ihnen bereits vermutet hatten, war dies eine weitere Anwendung, die ich zunächst nicht wusste: Checkpoint Endpoint Security.

Es ist für uns erforderlich, VPN-Verbindungen zum Unternehmen herzustellen. Es hat eine eigene Firewall, die Windows nicht erkennt. Selbst wenn VPN nicht aktiv ist, funktioniert die Firewall und blockiert alles dumm. Und es kann nicht aufgrund von Unternehmensrichtlinien deaktiviert werden.

Die Lösung bestand darin, Checkpoint Endpoint Security vollständig zu deinstallieren :).

Vielen Dank für all Ihre Bemühungen.