Пошаговое руководство по диагностике проблем доступа к серверу: ping, SSH, проверка портов, файрвол и сетевая маршрутизация.
Невозможность доступа к серверу может быть вызвана различными причинами: сетевые проблемы, правила файрвола, сбои служб или аппаратные неисправности. В этом руководстве мы подробно расскажем о шагах систематической диагностики проблем доступа к серверу.
Первым делом проверьте, доступен ли ваш сервер в сети:
# Простой ping-тест
ping -c 10 IP_СЕРВЕРА
# Ping с настройкой таймаута
ping -c 10 -W 3 IP_СЕРВЕРА
| Результат | Значение | Возможная причина |
|---|---|---|
| Ответ получен | Сервер доступен в сети | Возможна проблема на уровне сервиса |
| Request timeout | Пакеты не достигают цели | Файрвол, сетевая проблема или сервер выключен |
| Destination unreachable | Проблема маршрутизации | Неверный IP, ошибка сетевой конфигурации |
| 100% потеря пакетов | Полная потеря доступа | Сервер выключен или нет сетевого подключения |
На серверах REXE, когда у IP нет ни одного правила, все порты открыты. Если на вашем IP есть правила, автоматически включается Default Block; в этом случае для ICMP (ping) также может потребоваться правило в Path Panel (переключатель Ping).
Если ping работает, протестируйте SSH-подключение:
# Тест SSH-подключения (подробный режим)
ssh -v root@IP_СЕРВЕРА
# SSH с настройкой таймаута
ssh -o ConnectTimeout=10 root@IP_СЕРВЕРА
# SSH через определённый порт
ssh -p 2222 root@IP_СЕРВЕРА
# Connection refused — служба SSH не запущена или неверный порт
ssh: connect to host IP_СЕРВЕРА port 22: Connection refused
# Connection timed out — файрвол блокирует или сервер недоступен
ssh: connect to host IP_СЕРВЕРА port 22: Connection timed out
# No route to host — проблема сетевой маршрутизации
ssh: connect to host IP_СЕРВЕРА port 22: No route to host
# Permission denied — ошибка аутентификации
Permission denied (publickey,password)
Проверьте, открыты ли определённые порты:
# Проверка порта с помощью telnet
telnet IP_СЕРВЕРА 22
telnet IP_СЕРВЕРА 80
telnet IP_СЕРВЕРА 443
# Проверка порта с помощью nc (netcat)
nc -zv IP_СЕРВЕРА 22
nc -zv IP_СЕРВЕРА 80
nc -zv -w 5 IP_СЕРВЕРА 22
# Сканирование портов с помощью nmap
nmap -p 22,80,443 IP_СЕРВЕРА
# Проверка нескольких портов
nmap -p 1-1000 IP_СЕРВЕРА
| Статус | Значение |
|---|---|
| open | Порт открыт и служба прослушивает |
| closed | Порт доступен, но служба отсутствует |
| filtered | Файрвол блокирует порт |
| timeout | Таймаут подключения |
На серверах REXE, когда у IP нет ни одного правила, все порты открыты. Когда на вашем IP есть хотя бы одно правило, автоматически включается Default Block, и для доступа необходимо открыть соответствующий порт правилом фильтрации:
Правилам Path Panel может потребоваться 2-5 минут для перехода в статус propagated. Вновь созданные правила могут быть не сразу активны.
Даже если в панели правило отображается как ещё не распространённое (не обновлённое), правило, скорее всего, уже развёрнуто в течение 2-5 минут. Статус может обновляться с задержкой из-за интервала проверки статуса панелью или времени, необходимого для применения правила на всех узлах на стороне Path (кроме нашего). Это лишь визуальная задержка в панели; порт на самом деле уже открыт в системе.
Если у вас есть консольный доступ к серверу:
# Проверка правил iptables
sudo iptables -L -n -v
# Статус UFW
sudo ufw status verbose
# Статус firewalld
sudo firewall-cmd --list-all
# Правила nftables
sudo nft list ruleset
# Отключение UFW
sudo ufw disable
# Очистка правил iptables
sudo iptables -F
sudo iptables -P INPUT ACCEPT
sudo iptables -P OUTPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
# Остановка firewalld
sudo systemctl stop firewalld
Отключение файрвола делает ваш сервер уязвимым. Используйте это только для тестирования и немедленно включите файрвол после завершения теста.
Если у вас есть консольный доступ, проверьте статус служб:
# Статус службы SSH
sudo systemctl status sshd
# Статус веб-сервера
sudo systemctl status nginx
sudo systemctl status apache2
# Список всех запущенных служб
sudo systemctl list-units --type=service --state=running
# Список неудачных служб
sudo systemctl list-units --type=service --state=failed
# Проверка прослушиваемых портов
sudo ss -tlnp
sudo netstat -tlnp
# Анализ пути с помощью traceroute
traceroute IP_СЕРВЕРА
# Детальный анализ с помощью mtr
mtr -r -c 50 IP_СЕРВЕРА
# Локальная таблица маршрутизации
ip route show
# ARP-таблица
arp -a
Если сетевой доступ невозможен, попробуйте альтернативные методы доступа:
#!/bin/bash
# Скрипт диагностики доступа к серверу
SERVER_IP="IP_СЕРВЕРА"
echo "=== Проверка доступа к серверу: $SERVER_IP ==="
# 1. Проверка ping
echo -e "\n[1] Проверка Ping:"
ping -c 5 -W 3 $SERVER_IP 2>&1 | tail -2
# 2. Проверка SSH-порта
echo -e "\n[2] Проверка SSH-порта (22):"
nc -zv -w 5 $SERVER_IP 22 2>&1
# 3. Проверка HTTP-порта
echo -e "\n[3] Проверка HTTP-порта (80):"
nc -zv -w 5 $SERVER_IP 80 2>&1
# 4. Проверка HTTPS-порта
echo -e "\n[4] Проверка HTTPS-порта (443):"
nc -zv -w 5 $SERVER_IP 443 2>&1
# 5. Traceroute
echo -e "\n[5] Traceroute:"
traceroute -m 15 $SERVER_IP 2>&1
echo -e "\n=== Проверка завершена ==="
| Сценарий | Возможная причина | Решение |
|---|---|---|
| Ping не работает, ни один порт не открыт | Сервер выключен или нет сетевого подключения | Перезагрузите сервер через панель REXE |
| Ping работает, но SSH не подключается | Служба SSH упала или порт заблокирован | Создайте правило для SSH-порта в Path Panel |
| SSH подключается, но сайт не открывается | Служба веб-сервера упала | Подключитесь по SSH и перезапустите nginx/apache |
| Все порты отображаются как filtered | Файрвол блокирует весь трафик | Проверьте правила Path Panel |
| Периодические обрывы соединения | Потеря сетевых пакетов или DDoS | Создайте отчёт mtr и отправьте в поддержку REXE |
Для решения проблем доступа к серверу важен систематический подход. Начните с проверки ping и последовательно проверяйте доступность портов, правила файрвола и статус служб. На серверах REXE не забудьте проверить правила файрвола Path Panel. Если проблема сохраняется, обратитесь в службу поддержки REXE с отчётом mtr и результатами проведённых проверок.
Сначала проверьте статус вашего сервера в клиентской панели REXE (my.rexe.tr). Если сервер работает, попробуйте подключиться через VNC-консоль. Проверьте правила файрвола в Path Panel. Если проблема сохраняется, откройте тикет в поддержку.
Обычно это означает, что файрвол блокирует SSH-порт. Создайте в Path Panel правило фильтрации TCP Symmetric для SSH-порта (22) и дождитесь перехода правила в статус propagated (2-5 минут).
Возможно, служба SSH упала. Подключитесь к серверу через VNC-консоль и перезапустите службу SSH командой 'sudo systemctl restart sshd'. Также проверьте SSH-порт (22), он мог быть изменён.
Переход правила в статус propagated может занять 2-5 минут. Проверьте статус правила в Path Panel. Также убедитесь, что вы выбрали правильный IP-адрес, порт и протокол.
Проверьте логи атак в Path Panel. Возможно, активирован Null Route. Система защиты от DDoS REXE активируется автоматически. Если атака продолжается, свяжитесь со службой поддержки.
Руководство по решению проблем SSH-подключения: правила файрвола Path.net, Default Block, создание правила фильтрации для SSH-порта и шаги по устранению неполадок.
Руководство по решению проблем RDP-подключения: правила файрвола Path.net, Default Block, создание правила фильтрации для порта RDP и шаги по устранению неполадок.
Руководство по сетевому тестированию с помощью WinMTR и Linux MTR, создание правила фильтрации ICMP и отправка результатов в службу поддержки. Диагностика потери пакетов.