Не могу подключиться по ssh к серверу Linux после смены провайдера

Question

Организация, частью сети которой является этот сервер, меняет своего провайдера. Когда я переключаю этот сервер на новые значения IP, шлюза и т. д., я больше не могу подключиться к нему по ssh. Я зашел в один из инструментов проверки портов, и когда я проверил порт 22, он вернул "Я не смог увидеть вашу службу на _new_IP_value_ на порту 22".

Новый IP статический. На сервере нет маршрутизатора, нет переадресации портов — сетевой кабель идет прямо в сервер.

Естественно, я подумал, что сеть организации или новый интернет-провайдер блокируют порт 22, поэтому я позвонил администратору сети и попросил открыть его или сказать интернет-провайдеру открыть его. Он сказал, что сделает это. Но ничего не изменилось. Я позвонил ему через день с тем же вопросом, но было видно, что он занят — сказал, что сделал то, о чем я просил, и фактически повесил трубку.

Итак, теперь я думаю, что, возможно, что-то не так с настройками сервера. Но все инструменты Linux, такие как lsof, netstat, nmap и т. д. говорят, что sshd запущен и работает и прослушивает порт 22, порт 22 открыт и т. д., и я все еще могу подключиться к серверу по ssh, когда я переключаю его обратно в сеть нашего старого провайдера — все, что я переключаю, это IP, шлюз, DNS, ничего больше.

Может ли быть что-то на этом сервере, что блокирует ssh-соединения, когда сервер находится в сети нового провайдера, но не старого? ОС — Linux Mint.

Answer 1

Запустите захват пакетов на клиенте и запустите захват пакетов на сервере. Наиболее распространенными инструментами являются Wireshark и tcpdump:

tcpdump -n -i eth0 "(tcp port 22 or 3389) or icmp or icmp6"

• Если вы видите, что пакеты TCP SYN покидают клиент, но не поступают на сервер, проблема обычно связана с сетью — скорее всего, с интернет-провайдером сервера, поскольку онлайн-инструменты проверки портов исключили возможность того, что интернет-провайдер на стороне клиента является странным.

  (Возможно, администратор вообще не открыл порты или открыл их не для нужного адреса. Нередко порт 3389 также бывает закрыт на уровне интернет-провайдера.)

  Я думаю, tcptracerouteчто это может помочь выяснить, какое расстояние проходят пакеты, прежде чем исчезнуть.

• Если вы видите, что пакеты TCP SYN поступают на сервер, но на них не отвечаютсовсем, проблема с сервером. Это может быть внутренний брандмауэр сервера (tcpdump получает пакетыдоони попадают в брандмауэр), поэтому проверьте, есть ли у вас какие-либо правила iptablesилюбые правила nft.

  Также убедитесь, что на сервере естьмаршрут обратноклиенту и что он действительно попадает на правильный шлюз через правильный интерфейс:

  ip -4 route get <client_ip>
  ip -4 route show match <client_ip>
  

  Также запустите systemctl cat sshd, чтобы проверить, есть ли какие-либо белые списки IP-адресов уровня cgroup. Также запустите, ip xfrm policyчтобы проверить, есть ли какие-либо политики IPsec.

• Если вы видите, что приходят пакеты TCP SYN, но они генерируют ответы TCP RST, проблема все равно может быть в брандмауэре или демон SSH может быть настроен наслушатьпо неправильному адресу. (Вы не упомянули, чтолокальный адресотображается lsof/netstat рядом с "port 22". Если он показывает 0.0.0.0:22 или [::]:22, это хорошо, но если он показывает старый адрес, его нужно изменить в sshd_config.)

• Если вы видите, что приходят пакеты TCP SYN, а от сервера исходят ответы SYN/ACK, но клиент их не получает, это также проблема сети, и, скорее всего, на стороне интернет-провайдера сервера.