У нас есть сервер, где один из наших инженеров неправильно сконфигурировал подсеть, и теперь мы заблокированы из этого сервера и единственного доступа, о котором я знаю, работал бы, последовательная консоль от IDC (это означает просить, чтобы инженер IDC помог нам с этим).
Что было неправильно сконфигурировано:
address 192.168.1.9 # Original address there was
netmask 255.255.255.254 # Misconfigured, originally should've been .240
Из любопытства - там способ постараться не назвать IDC и так или иначе соединяться с этим хостом по SSH (затем, мы можем исправить конфигурацию)?
Вы должны иметь возможность войти на другой хост в том же сегменте сети. Некоторые из способов получить доступ к неправильно настроенному хосту требуют root на промежуточном хосте, но есть и один простой способ получить доступ без необходимости root на промежуточном хосте.
Легкий способ получить доступ к хосту с помощью IPv6
ssh -o ProxyCommand='ssh -W [fe80::42:ff:fe:42%%eth0]:%p user@intermediate-host' root@target-server
Следующие значения в примере вышеприведенной команды должны быть заменены на правильные значения в вашем случае использования: fe80::42:ff:fe:42
, eth0
, user
, intermediate-host
и target-server
.
Подробное объяснение того, как это работает
ProxyCommand
- это функция ssh, которую можно использовать, когда вы не можете открыть TCP-соединение непосредственно с целевым хостом. Аргумент к ProxyCommand
- это команда, чей stdin/stdout использовать вместо TCP соединения.
-W
используется для открытия переадресации одного порта и подключения его к stdin/stdout. Это хорошо сочетается с ProxyCommand
.
fe80::42:ff:fe:42%%eth0
является линк-локальным адресом целевого хоста. Обратите внимание, что из-за того, что ProxyCommand
использует %
в качестве экранирующего символа, набранная команда ssh должна использовать %
в этом месте. Найти все линково-локальные адреса в сегменте можно, выполнив ssh user@intermediate-host ping6 -nc2 ff02::1%eth0
.
Использование IPv6 линково-локальных адресов для этой цели обычно самый простой способ, так как он включен по умолчанию на всех современных системах, и линково-локальные адреса продолжают работать, даже если сильно неправильно настроены стеки IPv4 и IPv6.
Возврат к IPv4
Если IPv6 полностью отключен на неправильно настроенном узле (абсолютно не рекомендуется), то, возможно, вам придется прибегнуть к использованию IPv4. Поскольку IPv4 не имеет локальных адресов, как IPv6, то доступ к неправильно настроенному узлу с помощью IPv4 становится более сложным и требует наличия корневого доступа на промежуточном узле.
Если бы неправильно настроенный узел все еще мог использовать свой шлюз по умолчанию, вы бы смогли получить доступ к нему извне. Возможно, неправильно настроенная маска сети также нарушила шлюз по умолчанию из-за того, что стек отказался использовать шлюз вне префикса, охватываемого маской сети. Если это действительно так, то неправильно настроенный хост сможет общаться только с 192.168.1.8, потому что это единственный другой IP-адрес в подсети, доступный в настоящее время этому неправильно настроенному хосту.
Если у вас есть логин на 192.168.1.8, вы, возможно, просто сможете использовать ssh оттуда до 192.168.1.9. Если 192.168.1.8 в настоящее время не назначен, вы можете временно назначить его любому хосту в сегменте, к которому у вас есть root доступ.
.Вам нужно загрузить IP адрес в пределах настроенной подсети вашего целевого компьютера, а не только в том диапазоне, который вы на самом деле хотите.
Если вы отправите пакет на 10.0.0.2 с подсетью 255.255.255.248, например, 10.0.0.220, 10.0.0.0.2 посмотрит на маску подсети, чтобы понять, как на него ответить. Поскольку .220 выходит из подсети 255.255.255.248, .2 должен отправить ответ на шлюз по умолчанию.
Так что если вы можете загрузить IP адрес в той же подсети, что и .2, например, 10.0.0.3, то это сработает.
В вашем конкретном случае, для 10.0.0.9, подсеть 255.255.255.254 имеет только 1 дополнительный IP адрес, а именно 10.0.0.8. Таким образом, если вы можете загрузить этот IP-адрес, вы должны быть в состоянии SSH.
.Касперд
дал отличный ответ, достаточно подробный для того, чтобы я смог узнать, как я могу оправиться от ситуации в вопросе. Этот ответ является точным пошаговым, как я это сделал.
arp -a
или ip список соседей
, как root
находит MAC-адрес неправильно настроенного сервера. ssh user@link-local%dev
где: