Ich bin auf ein ähnliches Problem gestoßen wie indiese Frage zu einer falschen IP im LAN. Der Standard-Adressaliastrick auf der Netzwerkkarte hat jedoch nicht geholfen. Ich habe keinen direkten Zugriff auf die Serverkonsole. Wenn ich Glück habe, bekomme ich vielleicht in einer Woche oder später physischen Zugriff, aber ich hoffe, dass ich einen schnelleren Weg finden kann.
Ich kann den (Linux-)Server auf die Adresse 10.0.0.1von einem Server (Linux, mit IP $MY_IP) auf (angeblich) demselben L2-Segment per ARP ansprechen und er antwortet mit der $TARGET_MACkorrekten und erwarteten MAC für diesen Server
root@host:~# arping -c 3 -I $IFACE 10.0.0.1
ARPING 10.0.0.1 from $MY_IP $IFACE
Unicast reply from 10.0.0.1 [$TARGET_MAC] 0.746ms
Unicast reply from 10.0.0.1 [$TARGET_MAC] 0.796ms
Unicast reply from 10.0.0.1 [$TARGET_MAC] 0.807ms
Sent 3 probes (1 broadcast(s))
Received 3 response(s)
Ich habe meine IPs und MACs versteckt, da diese Maschinen öffentlich zugänglich sind.
Wenn ich einen Adressalias für diese Schnittstelle hinzufüge, kann ich das Ziel zwar immer noch per AR-Anruf erreichen, aber nicht anpingen. Keine andere Schnittstelle hat den Bereich 10.0.0.0/24, es schlägt sogar mit fehl ping -I $IFACE.
root@host:~# ip addr add 10.0.0.2/24 dev $IFACE
root@host:~# arping -c 3 -I $IFACE 10.0.0.1
ARPING 10.0.0.1 from 10.0.0.2 $IFACE
Unicast reply from 10.0.0.1 [$TARGET_MAC] 0.788ms
Unicast reply from 10.0.0.1 [$TARGET_MAC] 0.766ms
Unicast reply from 10.0.0.1 [$TARGET_MAC] 0.794ms
Sent 3 probes (1 broadcast(s))
Received 3 response(s)
root@host:~# ping -c 3 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
--- 10.0.0.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2015ms
Der Zielserver wartet auf SSH-Verbindungen, aber SSH kommt nicht durch
root@host:~# ssh -vvv 10.0.0.1
OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 Jan 2015
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 10.0.0.1 [10.0.0.1] port 22.
debug1: connect to address 10.0.0.1 port 22: Connection timed out
ssh: connect to host 10.0.0.1 port 22: Connection timed out
Ich habe versucht, das Ziel durch Senden von ARP-Antwortpaketen zur Aktualisierung seiner ARP-Tabelle zu zwingen, aber das hat anscheinend nicht geholfen.
root@host:~# arping -A -c 3 -s 10.0.0.2 -I $IFACE 10.0.0.1
ARPING 10.0.0.1 from 10.0.0.2 $IFACE
Sent 3 probes (3 broadcast(s))
Received 0 response(s)
root@host:~# ping -c 3 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
--- 10.0.0.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms
Es besteht eine geringe Chance, dass eine L3-Komponente vorhanden ist, da mir der Server E-Mail-Updates ( apt-listchangesAusgabe) gesendet hat, die E-Mail-Header jedoch eine IP enthalten, die einem Switch zugewiesen ist, obwohl der Hostname in den Headern korrekt war (der Hostname des Ziels). Andere Administratoren haben mir gesagt, dass es sich im selben L2-Segment befinden sollte, und Arping scheint dies zu belegen. Gibt es andere Möglichkeiten, L3-Komponenten auszuschließen?
Das Ziel ist, eine SSH-Verbindung zum Zielserver herzustellen, damit ich das Problem beheben kann.
Antwort1
Anscheinend sind Sie im selben L2-Ethernet-Segment und verwenden die IPs 1 und 2 im selben Bereich. Mir fallen zwei Gründe ein, warum das nicht funktionieren sollte:
- Auf dem Server mit IP
10.0.0.1ist eine Art Layer-3-Filterung aktiv (höchstwahrscheinlich IPTable) und er verwirft die ICMP-Pakete, die Sie senden, obwohl alles richtig eingerichtet ist, damit es aus Netzwerksicht funktioniert. Versuchen Sie es mit anderen Tests (ssh,telnet,http, oder einem beliebigen Netzwerkdienst, von dem Sie wissen, dass er auf dem Server lauscht). - Aus irgendeinem Grund
pingverlassen Ihre Sonden den Server nicht über $IFACE (beispielsweise, wenn der gleiche IP-Bereich auch auf einer anderen Schnittstelle konfiguriert ist). Versuchen Sie es mitping -i $IFACE