17
Ping im LAN: Unbekannte IP-Adresse antwortet
Hey Leute.
Ich habe heute ein kleines LAN aufgebaut und dabei ist mir etwas aufgefallen, was ich nicht verstehe :D
Und zwar habe ich einen Rechner mit W10, einen mit Ubuntu und einen mit Kali in besagtes Netzwerk integriert. Ohne Gateway, DHCP, Proxy, DNS etc. IP-Adressen manuell vergeben.
W10 und Ubuntu wurden an einem Switch angeschlossen. Kali am selben Switch, jedoch am Mirrorport (wollte bisschen sniffen zu Testzwecken)
Wenn ich W10 und Ubuntu jeweils anpinge, funktioniert alles wie geplant und erwartet.
Pinge ich allerdings von W10 nach "draußen" (z.B: ping 8.8.8.8 -t) erhalte ich von einer unbekannten/nicht von mir vergebenen IP die Meldung "Zielhost nicht erreichbar". Diese IP war auch nicht im ARP-Cache zu sehen.
Auch beim Sniffen bzw. Wireshark sind keine Pakete vom W10 angekommen, also weder ICMP, noch ARP usw.
Meine Fragen/Vermutungen sind jetzt:
a) Warum erhalte ich eine Antwort von einer völlig unbekannten IP? Ist das vielleicht so ein 'hypotethischer' Gateway, der automatisch gesetzt wird oder sowas? Klingt irgendwie komisch.
b) Warum sehe ich beim Sniffen bei diesem Ping keine Pakete durch den Switch laufen? Ich vermute hierbei, dass die Pakete garnicht verschickt werden, weil an der Routingtabelle deutlich wird, dass sie nicht im eigenen Netz liegen/zum Gateway müssen, aber kein Gateway eingetragen ist.
Könnt ihr mir helfen? :D
Vielen Dank schonmal
Ich habe heute ein kleines LAN aufgebaut und dabei ist mir etwas aufgefallen, was ich nicht verstehe :D
Und zwar habe ich einen Rechner mit W10, einen mit Ubuntu und einen mit Kali in besagtes Netzwerk integriert. Ohne Gateway, DHCP, Proxy, DNS etc. IP-Adressen manuell vergeben.
W10 und Ubuntu wurden an einem Switch angeschlossen. Kali am selben Switch, jedoch am Mirrorport (wollte bisschen sniffen zu Testzwecken)
Wenn ich W10 und Ubuntu jeweils anpinge, funktioniert alles wie geplant und erwartet.
Pinge ich allerdings von W10 nach "draußen" (z.B: ping 8.8.8.8 -t) erhalte ich von einer unbekannten/nicht von mir vergebenen IP die Meldung "Zielhost nicht erreichbar". Diese IP war auch nicht im ARP-Cache zu sehen.
Auch beim Sniffen bzw. Wireshark sind keine Pakete vom W10 angekommen, also weder ICMP, noch ARP usw.
Meine Fragen/Vermutungen sind jetzt:
a) Warum erhalte ich eine Antwort von einer völlig unbekannten IP? Ist das vielleicht so ein 'hypotethischer' Gateway, der automatisch gesetzt wird oder sowas? Klingt irgendwie komisch.
b) Warum sehe ich beim Sniffen bei diesem Ping keine Pakete durch den Switch laufen? Ich vermute hierbei, dass die Pakete garnicht verschickt werden, weil an der Routingtabelle deutlich wird, dass sie nicht im eigenen Netz liegen/zum Gateway müssen, aber kein Gateway eingetragen ist.
Könnt ihr mir helfen? :D
Vielen Dank schonmal
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: 502183
Url: https://administrator.de/forum/ping-im-lan-unbekannte-ip-adresse-antwortet-502183.html
Ausgedruckt am: 23.12.2024 um 05:12 Uhr
17 Kommentare
Neuester Kommentar
Mach ein tracert 8.8.8.8 und schau dir an über wie viele Hops Deine Anfragen gehen. Eine davon wird die besagte IP Adresse sein.
1
Sagt mal - hab ihr euch überhaupt die Frage durchgelesen?
Und wenn ja - warum habt ihr dann überlesen, dass er gar kein GW angegeben hat?!
Und wenn ja - warum habt ihr dann überlesen, dass er gar kein GW angegeben hat?!
Ich habe sowas vermutet, aber weil er von einer ihm unbekannten IP sprach wollte ich doch auf Nummer sicher gehen 
Allerdings müsste bei fehelndem Gateway unter Linux eigentlich direkt die Meldung "Network is unreachable" geworfen werden, keine "Zielhost nicht erreichbar" - weil das alles irgendwie etwas diffus ist, habe ich auf meinen Artikel verwiesen
Allerdings müsste bei fehelndem Gateway unter Linux eigentlich direkt die Meldung "Network is unreachable" geworfen werden, keine "Zielhost nicht erreichbar" - weil das alles irgendwie etwas diffus ist, habe ich auf meinen Artikel verwiesen
Servus.
Ist das ein Layer3 Switch der ne Routingtabelle hat ?
Aber dann solltest Du dennoch was am Mirrorport sehen.
Welche IPs hast Du vergeben, welche IP antwortet ?
Henere
Ist das ein Layer3 Switch der ne Routingtabelle hat ?
Aber dann solltest Du dennoch was am Mirrorport sehen.
Welche IPs hast Du vergeben, welche IP antwortet ?
Henere
Wenn er auf Ping eine (negative) Antwort von irgendwo bekommen hat, wird ihm auch tracert etwas aus ausspucken. Dann wird er schon sehen was es mit seiner Gateway auf sich hat.
Hallo zusammen.
Vielen Dank für eure Antworten und vor allem den Link von Gurke
Auf die Idee mit tracert hätte ich eigentlich selbst kommen müssen. Das werde ich heute Abend mal ausprobieren. Vielleicht steht ja auch was Interessantes in der Routingtabelle drin. Mal schauen.
Es ist ein Cisco 2960G 8 Port Switch. Sollte also nur auf L2 laufen.
Die vergebenen IPs waren:
W10: 192.168.0.21/24
Ubuntu: 192.168.0.20/24
Das oben geschilderte Problem trat bei W10 auf.
Vielen Dank für eure Antworten und vor allem den Link von Gurke
Auf die Idee mit tracert hätte ich eigentlich selbst kommen müssen. Das werde ich heute Abend mal ausprobieren. Vielleicht steht ja auch was Interessantes in der Routingtabelle drin. Mal schauen.
Es ist ein Cisco 2960G 8 Port Switch. Sollte also nur auf L2 laufen.
Die vergebenen IPs waren:
W10: 192.168.0.21/24
Ubuntu: 192.168.0.20/24
Das oben geschilderte Problem trat bei W10 auf.
Moin. Und was hat geantwortet?
Sollte also nur auf L2 laufen.
Sollte..???Konjunktive sind in der IT und besonders der Netzwerk IT immer eine sehr schlechte Basis... Posting der Konfig wäre sicherer...aber egal.
Man fragt sich auch warum du denn den Wireshark installiert hast ?
Setze doch den Mirrorport auf den W10 Rechner und sniffer da mit WAS der denn nach dem Ping oder Traceroute auf 8.8.8.8 alles ins Netz sendet ! Das sollte doch Aufschluss geben.
Da wird sich sicher etwas finden sofern er aktiv mit anderen IPs "redet".
Man sollte auch nicht vergessen das Windows erlaubt sekundäre Alternativ IPs (Secondary IP) auf der NIC zu konfigurieren.
Möglich also das irgendwas am Winblows "verschlimmbessert" wurde oder der Cisco zusätzlich noch etwas konfiguriert hat was wir hier nicht kennen können weil du es nicht angibst. Um soetwas zu erkennen müsste die Forums Community hellsehen können.
Fazit: Es bleiben also zig Optionen für so ein Verhalten...
Hallo zusammen.
Ich hab mich nochmal an das Problem drangesetzt. Wurde von W10 gemacht mit der IP 192.168.0.21/24
Merkwürdigerweise kann ich vom Linux-Rechner die IP nicht anpingen (IP des Rechners: Destination Host unreachable)
Wireshark sagt mir hier, dass auf die ARP-Requests keine Antwort kommt und der Cisco-Switch nur STP-, DTP- und Loop-Pakete herumschickt.
Ich vermute, wie aqui mich freundlich darauf hinwies, dass tatsächlich die 192.168.0.38 zum Switch gehört.
Warum die Vermutung? => Ich hab diesen ausgelagerten Switch zu Test- und Lernzwecken von unserem Admin bekommen. Die running-config habe ich mir dabei dummerweise vorher nicht angeschaut bzw. die Einstellungen nicht resettet. Vermutlich ist die konfigurierte IP noch ein Überbleibsel aus alten Zeiten.
Nachprüfen kann ich das gerade nicht, weil ich per SSH nicht drauf komme
Vermutlich wurde auch ein anderer Port eingestellt. Und das alles per Console zu machen würde ich morgen....
Ich hab mich nochmal an das Problem drangesetzt. Wurde von W10 gemacht mit der IP 192.168.0.21/24
ping 8.8.8.8
Ping wird ausgeführt für 8.8.8.8 mit 32 Bytes Daten:
Antwort von 192.168.0.38: Zielhost nicht erreichbar.
Antwort von 192.168.0.38: Zielhost nicht erreichbar.
Antwort von 192.168.0.38: Zielhost nicht erreichbar.
Antwort von 192.168.0.38: Zielhost nicht erreichbar.
Ping-Statistik für 8.8.8.8:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust)tracert 8.8.8.8
Routenverfolgung zu 8.8.8.8 über maximal 30 Hops
1 192.168.0.38 meldet: Zielhost nicht erreichbar.
Ablaufverfolgung beendet.ping 192.168.0.38
Ping wird ausgeführt für 192.168.0.38 mit 32 Bytes Daten:
Antwort von 192.168.0.38: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.0.38: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.0.38: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.0.38: Bytes=32 Zeit<1ms TTL=128
Ping-Statistik für 192.168.0.38:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 0ms, Maximum = 0ms, Mittelwert = 0msMerkwürdigerweise kann ich vom Linux-Rechner die IP nicht anpingen (IP des Rechners: Destination Host unreachable)
Wireshark sagt mir hier, dass auf die ARP-Requests keine Antwort kommt und der Cisco-Switch nur STP-, DTP- und Loop-Pakete herumschickt.
Ich vermute, wie aqui mich freundlich darauf hinwies, dass tatsächlich die 192.168.0.38 zum Switch gehört.
Warum die Vermutung? => Ich hab diesen ausgelagerten Switch zu Test- und Lernzwecken von unserem Admin bekommen. Die running-config habe ich mir dabei dummerweise vorher nicht angeschaut bzw. die Einstellungen nicht resettet. Vermutlich ist die konfigurierte IP noch ein Überbleibsel aus alten Zeiten.
Nachprüfen kann ich das gerade nicht, weil ich per SSH nicht drauf komme
ssh 192.168.0.38
ssh: connect to host 192.168.0.38 port 22: Connection refused
Mach doch einen Reset auf Defaultwerte. Danach erst fängst das basteln an.
1
Ich würde da jetzt mal mit folgendem Befehl auf der Windows-Büchse weiter machen:
arp -a | find "192.168.0.38"
Da wird dir dann die MAC Adresse dieses Geräts angezeigt.
Dann kannst du auf Seiten wie dieser nachsehen, von welchem Hersteller das Gerät stammt, was da die Antwort geschickt hat:
https://macvendors.com/
arp -a | find "192.168.0.38"
Da wird dir dann die MAC Adresse dieses Geräts angezeigt.
Dann kannst du auf Seiten wie dieser nachsehen, von welchem Hersteller das Gerät stammt, was da die Antwort geschickt hat:
https://macvendors.com/
Hey Leute.
Sorry für die verspätete Antwort.
Hab die Tage mal ein bisschen rumprobiert und bin komplett verwirrt.
Im ARP-Cache ist kein Eintrag zur 192.168.0.38 zu finden. Das Pingen funktioniert aber ganz normal. Auch beim Monitoring am Switch erkennt man bzgl. der IP garnichts. Weder ARP- noch ICMP-Pakete.
Ich habe mir den Switch in den letzten Tagen etwas genauer angeschaut. VLAN 1 (Ist bei Cisco ja das Standard-Management-VLAN) war nicht konfiguriert. Habe dem VLAN 1 dann selbstständig eine IP gegeben und die konnte ich vom W10-Rechner anpingen. Der entsprechende Eintrag war auch im ARP-Cache zu finden und beim Monitoring wurde auch alles erkannt (ICMP- und ARP-Pakete).
Jetzt wirds noch lustiger: Ich hab ja eine LAN- und eine WLAN-Schnittstelle. Als ich rumprobiert habe, habe ich WLAN immer deaktiviert und nur die LAN-Verbindung aktiviert gelassen und da manuell die IP vergeben. Jetzt habe ich WLAN wieder aktiviert und WLAN erhält vom DHCP die 192.168.0.38.... Kann das irgendwie damit zusammenhängen? Dass die beiden NICs irgendwie in einem Netzwerk sind, obwohl die eine deaktiviert ist?
Sorry für die verspätete Antwort.
Hab die Tage mal ein bisschen rumprobiert und bin komplett verwirrt.
Im ARP-Cache ist kein Eintrag zur 192.168.0.38 zu finden. Das Pingen funktioniert aber ganz normal. Auch beim Monitoring am Switch erkennt man bzgl. der IP garnichts. Weder ARP- noch ICMP-Pakete.
Ich habe mir den Switch in den letzten Tagen etwas genauer angeschaut. VLAN 1 (Ist bei Cisco ja das Standard-Management-VLAN) war nicht konfiguriert. Habe dem VLAN 1 dann selbstständig eine IP gegeben und die konnte ich vom W10-Rechner anpingen. Der entsprechende Eintrag war auch im ARP-Cache zu finden und beim Monitoring wurde auch alles erkannt (ICMP- und ARP-Pakete).
Jetzt wirds noch lustiger: Ich hab ja eine LAN- und eine WLAN-Schnittstelle. Als ich rumprobiert habe, habe ich WLAN immer deaktiviert und nur die LAN-Verbindung aktiviert gelassen und da manuell die IP vergeben. Jetzt habe ich WLAN wieder aktiviert und WLAN erhält vom DHCP die 192.168.0.38.... Kann das irgendwie damit zusammenhängen? Dass die beiden NICs irgendwie in einem Netzwerk sind, obwohl die eine deaktiviert ist?
Im ARP-Cache ist kein Eintrag zur 192.168.0.38 zu finden
Das lässt darauf schliessen das diese IP eine Alternative, sprich Secondary IP irgendwo ist. Der ARP Cache ist dann mit einer anderen IP schon im Cache.Nimm dir am besten einen Wireshark Sniffer und sieh dir die Pings an. ICMP Echo request und das Echo Reply zeigen dir im Wireshark die zu dieser IP korrespondierende Mac Adresse an.
Am Switch kannst du dann über die Mac Forwarding Tabelle sehen an welchem Switchport das zu dieser Mac Adresse gehörendes Endgerät hängt.
Damit hast du dann den Buhmann entlarvt der dir diese IP vorgaukelt und aktiv damit antwortet !
und WLAN erhält vom DHCP die 192.168.0.38.... Kann das irgendwie damit zusammenhängen?
Ja logisch !Es sind ja dann beide Adapter aktiv. Wenn das WLAN also auch mit dem LAN verbunden ist sind beide Adapter parallel im gleichen IP Netz.
Winblows kann damit nicht umgehen und dann entscheidet die NIC Bindungsreihenfolge welcher Adapter der aktive ist und den nutzt Winblows dann. Der andere wird ignoriert.
Vermutlich hat also dein WLAN Adapter die höhere Bindungsreihenfolge und wird dann der aktive Adapter.
Ob die Mac Adresse übereinstimmt zeigt dir dann ein ipconfig -all !
Ist der Adapter aber deaktiviert ist auch die Schnittstelle physisch deaktiviert, sprich also abgeschaltet und inaktiv. Dann kann logischerweise weder die IP noch die Mac Adresse erreichbar sein.
Es sei denn dein Rechner hat einen Bug und schaltet das Interface nicht inaktiv ?!
Zitat von @aqui:
Es sind ja dann beide Adapter aktiv. Wenn das WLAN also auch mit dem LAN verbunden ist sind beide Adapter parallel im gleichen IP Netz.
Winblows kann damit nicht umgehen und dann entscheidet die NIC Bindungsreihenfolge welcher Adapter der aktive ist und den nutzt Winblows dann. Der andere wird ignoriert.
Vermutlich hat also dein WLAN Adapter die höhere Bindungsreihenfolge und wird dann der aktive Adapter.
Ob die Mac Adresse übereinstimmt zeigt dir dann ein ipconfig -all !
Ist der Adapter aber deaktiviert ist auch die Schnittstelle physisch deaktiviert, sprich also abgeschaltet und inaktiv. Dann kann logischerweise weder die IP noch die Mac Adresse erreichbar sein.
Es sei denn dein Rechner hat einen Bug und schaltet das Interface nicht inaktiv ?!
und WLAN erhält vom DHCP die 192.168.0.38.... Kann das irgendwie damit zusammenhängen?
Ja logisch !Es sind ja dann beide Adapter aktiv. Wenn das WLAN also auch mit dem LAN verbunden ist sind beide Adapter parallel im gleichen IP Netz.
Winblows kann damit nicht umgehen und dann entscheidet die NIC Bindungsreihenfolge welcher Adapter der aktive ist und den nutzt Winblows dann. Der andere wird ignoriert.
Vermutlich hat also dein WLAN Adapter die höhere Bindungsreihenfolge und wird dann der aktive Adapter.
Ob die Mac Adresse übereinstimmt zeigt dir dann ein ipconfig -all !
Ist der Adapter aber deaktiviert ist auch die Schnittstelle physisch deaktiviert, sprich also abgeschaltet und inaktiv. Dann kann logischerweise weder die IP noch die Mac Adresse erreichbar sein.
Es sei denn dein Rechner hat einen Bug und schaltet das Interface nicht inaktiv ?!
Hi
Danke für die Antwort. Ich habe alles nochmal ausprobiert:
1) Habe den WLAN-Adapter deaktiviert (zuvor mit ipconf -all geprüft => dort stand drin "Medium getrennt". Es waren auch keine Einstellungen vergeben wie IP, Gateway, DNS etc.)
2) Habe die 192.168.0.38 (zuvor IP vom aktiven WLAN-Adapter) angepingt. Auf die Pings bekomme ich Antworten, Wireshark zeigt mir dazu aber nichts an. Also weder ARP noch ICMP.
3) Habe 8.8.8.8 angepingt. Bekomme von 192.168.0.38 die Antwort, dass der Zielhost nicht erreichbar ist. Auch hier zeigt mir Wireshark nichts an
4) Habe 192.168.0.222 (beliebige IP des selben Netzes) angepingt. Bekomme von der IP des LAN-Adapters die Antwort, dass der Zielhost nicht erreichbar ist. Hier zeigt mir Wireshark allerdings ARP-Requests an
Auf die Pings bekomme ich Antworten, Wireshark zeigt mir dazu aber nichts an. Also weder ARP noch ICMP.
Wenn das wirklich stimmt, dann ist die IP intern in deinem Rechner drin !! Sprich da geht gar nichts erst was ins Netz sondern es ist intern. Logisch wenn der Kabelhai nix anzeigt !Sniffer dann mal auf dem Loopback Adapter ! Da sollte dann was kommen...!
Wie auch immer.. Da hast du dann intern irgendwas Virtuelles am Laufen was diese IP nutzt oder eine Secondary IP definiert oder eine doppelte IP (statisch) vergeben oder oder oder...
Da solltest du also mal verstärkt auf dem Rechner selber suchen !!
