Я столкнулся с аналогичной проблемой, как в этот вопрос о неправильном IP в LAN. Однако стандартный трюк с псевдонимом addr на сетевой карте не помог. У меня нет прямого доступа к серверной консоли, я могу получить физический доступ через неделю или больше, если мне повезет, но я надеюсь, что смогу найти более быстрый способ.
Я могу подключить (Linux) сервер по адресу 10.0.0.1
с сервера (Linux, с IP $MY_IP
) на (предположительно) том же сегменте L2, и он отвечает $TARGET_MAC
который является правильным и ожидаемым MAC для этого сервера
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)
Я скрыл свои IP и MAC, так как эти машины общедоступны.
Если я добавлю псевдоним адреса для этого интерфейса, я все еще могу настроить цель, но не могу проверить связь с ней. Ни один другой интерфейс не имеет диапазона 10.0.0.0/24, он не работает даже с 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
Целевой сервер прослушивает SSH-соединения, но ssh не проходит
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
Я попытался заставить цель обновить свою таблицу ARP, отправив ей пакеты ARP REPLY, но это, похоже, не помогло.
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
Есть небольшая вероятность, что есть какой-то компонент L3, потому что сервер отправил мне обновления по электронной почте (apt-listchanges
output), но заголовки электронной почты содержат IP-адрес, назначенный некоторому переключателю, но имя хоста в заголовках было правильным (имя хоста цели). Другие администраторы сказали мне, что он должен быть в том же сегменте L2, и arping, похоже, предполагает это. Есть ли другие способы исключить компоненты L3?
Цель состоит в том, чтобы установить SSH-соединение с целевым сервером, чтобы я мог решить проблему.
Очевидно, вы находитесь в том же сегменте Ethernet L2, используя IP-адреса 1 и 2 в одном диапазоне. Я могу придумать две причины, по которым это не сработает:
10.0.0.1
имеет активную фильтрацию уровня 3 (скорее всего, IPTable) и отбрасывает отправляемые вами ICMP-пакеты, несмотря на то, что все настроено правильно, чтобы заставить его работать с сетевой точки зрения. Попробуйте другие зонды (ssh
, telnet
, http
или любой другой сетевой сервис, который, как известно, прослушивает сервер).ping
зонды не уходят через $ IFACE (например, если тот же диапазон IP-адресов также настроен на другом интерфейсе). Попробуйте использовать ping -i $IFACE