Сервер недоступен из некоторых сетей: DPI и блокировки

Введение

Иногда пользователи сталкиваются с ситуацией, когда сайт, сервер или отдельный сетевой сервис перестаёт открываться из определённой сети, но при этом продолжает работать из других.

Например:

сайт открывается через мобильный интернет, но не через домашнего провайдера;
SSH не подключается из одной сети, но работает с другого сервера;
RDP перестал подключаться, хотя сам сервер работает;
ping не проходит, но сайт открывается;
после изменения IP-адреса доступ временно восстанавливается;
сервер доступен через консоль в панели управления, но подключиться к нему по SSH невозможно.

В таких случаях причина может находиться не на самом сервере. На доступность ресурса влияют не только его настройки, но и маршрутизация, сетевое оборудование и применяемые в сети правила обработки трафика.

Отдельно необходимо учитывать системы сетевой фильтрации, которые могут анализировать параметры соединений и ограничивать доступ к определённым ресурсам.

Какие причины встречаются чаще всего

Причину проблемы удобно разделить на несколько групп.

Проблема на сервере

Например:

остановилась служба;
закрыт TCP-порт;
изменились правила firewall;
закончились ресурсы;
неправильно настроен веб-сервер;
произошла ошибка в конфигурации IPv6.

Проблема с маршрутизацией

Пакеты могут теряться на одном из участков маршрута между клиентом и сервером.

Ограничения со стороны сети

Оператор или другое сетевое оборудование может применять правила обработки определённых типов соединений.

Ограничения на уровне регулятора

В некоторых странах операторы связи обязаны использовать системы фильтрации трафика и выполнять установленные регулятором правила ограничения доступа к сетевым ресурсам.

Такие системы могут работать не только по принципу простого списка IP-адресов.

Изменение характеристик IP-адреса

IP-адрес мог ранее использоваться для других сервисов, в том числе VPN, прокси или других сетевых приложений. В результате текущая проблема может быть связана не с тем сервисом, который работает на сервере сейчас, а с предыдущей историей использования адреса или его текущей классификацией в сторонних системах.

Как работают сетевые ограничения

Современные системы фильтрации могут использовать несколько признаков одновременно. В зависимости от конкретной инфраструктуры могут анализироваться:

IP-адрес назначения;
порт;
протокол;
доменное имя;
параметры TLS-соединения;
характеристики сетевого трафика;
принадлежность IP-адреса к определённому диапазону;
ранее выявленные характеристики ресурса.

Поэтому ограничение не обязательно означает, что IP-адрес сервера напрямую внесён в список запрещённых ресурсов. Фильтрация может применяться непосредственно к сетевому соединению и выполняться в момент его установления.

Например, клиент отправляет серверу запрос на установление TCP-соединения, но сетевое оборудование по пути определяет, что такое соединение необходимо ограничить, и не пропускает его дальше. Сервер в этом случае вообще не получает запрос от клиента.

Для пользователя результат выглядит как обычная сетевая ошибка: соединение не устанавливается, а через некоторое время клиент сообщает Connection timed out. При этом сам сервер может продолжать работать штатно и оставаться доступным из других сетей.

Почему наличие VPN на сервере может иметь значение

Отдельного внимания заслуживает сервер, на котором работает или ранее работал VPN.

Например, на IP-адресе может находиться сервер с:

OpenVPN;
WireGuard;
IPsec;
другим VPN-сервисом;
прокси;
шлюзом удалённого доступа.

Само по себе наличие VPN не означает, что IP-адрес будет заблокирован.

Однако VPN-трафик имеет определённые характеристики, а используемый IP-адрес может быть известен различным системам анализа сетевого трафика.

Кроме того, если IP-адрес ранее использовался для VPN или другого сетевого сервиса, его текущая классификация в сторонних системах может не измениться сразу после удаления этого сервиса.

Это не означает, что причиной обязательно является VPN. Такой фактор необходимо рассматривать наряду с другими возможными причинами.

Почему изменение IP-адреса иногда помогает

Если после смены IP сайт начинает открываться, это важный диагностический признак.

В этом случае могли измениться:

маршрут до сервера;
правила обработки трафика;
классификация адреса;
сетевые фильтры;
характеристики конкретного IP-диапазона.

Однако смена IP не всегда является окончательным решением. Если причина находится в конфигурации сервера или в маршрутизации, проблема может повториться и на новом адресе.

Как определить, что проблема не на сервере

Первое, что следует сделать - это проверить ресурс из другой сети.

Например:

домашний интернет;
мобильный интернет;
другой интернет-провайдер;
другой сервер;
VPN.

Если результат выглядит следующим образом:

Источник подключения	Результат
Домашний интернет	Не работает
Мобильный интернет	Работает
Другой сервер	Работает
Консоль сервера	Работает

вероятность проблемы непосредственно в веб-сервере значительно снижается.

В этом случае необходимо проверить сетевой маршрут и обработку соединения.

Проверка DNS

Сначала необходимо убедиться, что доменное имя разрешается в правильный IP-адрес.

Linux:

dig planetahost.ru

или:

nslookup planetahost.ru

Проверьте записи:

A
AAAA

Если используется IPv6, убедитесь, что AAAA указывает на корректный адрес и сервер действительно доступен по IPv6.

Проверка IPv4 и IPv6

IPv4:

curl -4 -vk https://vk.ru/

IPv6 (если поддерживает клиент и сайт):

curl -6 -vk https://vk.ru/

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

Проверка TCP-порта

Для HTTPS используется TCP/443.

Проверить его можно командой:

nc -vz planetahost.ru 443

Для SSH:

nc -vz planetahost.ru 22

Для RDP:

nc -vz planetahost.ru 3389

Возможны два основных результата:

Порт доступен означает, что TCP-соединение успешно устанавливается. Клиент получает ответ от удалённого узла и может начать обмен данными.

Тайм-аут означает, что клиент не получил ожидаемого ответа в течение отведённого времени. Причиной может быть блокировка на серверном firewall, проблема с маршрутизацией или фильтрация соединения по пути между клиентом и сервером.

Проверка SSH на сервере

Если проблема именно с SSH, проверьте состояние службы:

systemctl status ssh

На некоторых системах используется:

systemctl status sshd

Проверьте, прослушивается ли TCP/22:

ss -lntp | grep ':22'

Также необходимо проверить правила firewall.

Для nftables:

nft list ruleset

Для iptables:

iptables -L -n -v

Если SSH работает из другой сети, а служба на сервере исправна, следует дополнительно проверить сетевой маршрут.

Проверка HTTPS

Для проверки HTTPS удобно использовать:

curl -vk https://planetahost.ru/

В выводе можно увидеть:

IP-адрес, к которому выполняется подключение;
успешность TCP-соединения;
процесс TLS handshake;
версию TLS;
сертификат;
HTTP-версию;
HTTP-код ответа.

Например:

В таком случае базовое соединение с веб-сервисом устанавливается корректно.

Проверка TLS

Если TCP/443 доступен, но HTTPS не работает, отдельно проверьте TLS:

openssl s_client \
  -connect planetahost.ru:443 \
  -servername planetahost.ru

Параметр -servername позволяет проверить подключение с использованием SNI.

Если TCP-соединение устанавливается, но TLS handshake не завершается, необходимо проверять конфигурацию TLS и особенности соединения.

В отдельных случаях на результат могут влиять системы сетевого анализа трафика.

HTTP/2 и HTTP/3

Современные сайты могут использовать два разных протокола. HTTP/2 работает через TCP, а HTTP/3 использует QUIC и UDP.

Из-за этого HTTP/3 может работать нестабильно в сетях, где UDP-трафик фильтруется. В том числе некоторые системы DPI могут анализировать или блокировать QUIC-трафик. В таком случае TCP/443 продолжает работать, а HTTP/3 может завершаться тайм-аутом.

Для проверки можно временно отключить HTTP/3 на клиенте. Тогда браузер перестанет использовать QUIC и перейдёт на HTTP/2 через TCP.

В Chrome это можно сделать через chrome://flags/#enable-quic, установив Experimental QUIC protocol → Disabled. В Firefox используется параметр network.http.http3.enabled в about:config.

Если после отключения HTTP/3 сайт начинает нормально работать, это дополнительный признак того, что проблема связана с QUIC, UDP-трафиком или его фильтрацией по пути следования.

Проверка маршрута

Для просмотра маршрута в Linux:

traceroute planetahost.ru

В Windows:

tracert planetahost.ru

Для HTTPS в Linux можно дополнительно использовать TCP-трассировку:

traceroute -T -p 443 planetahost.ru

Результаты лучше сравнивать из разных сетей. Например, если через одного провайдера маршрут до сервера проходит нормально, а через другого обрывается на определённом участке, это помогает понять, в каком направлении искать проблему.

При этом отсутствие ответа от отдельного узла в traceroute не обязательно означает неисправность этого узла. Сетевое оборудование может просто не отвечать на диагностические запросы, хотя при этом продолжать нормально передавать трафик. Как читать результаты данной команды можете изучить подробно в нашей статье.

Если не работает ping

Отсутствие ответа на:

ping 62.173.138.27

не означает, что сервер полностью недоступен.

ICMP может быть запрещён на сервере или промежуточном оборудовании.

Поэтому одновременно необходимо проверять нужный TCP-порт:

nc -vz 62.173.138.27 443

Если ping не работает, а TCP/443 доступен, веб-сервис может функционировать нормально.

Что делать, если проблема появилась внезапно

Если сервер длительное время работал нормально, а затем перестал открываться из определённой сети, рекомендуется:

Проверить ресурс из другой сети.
Проверить DNS.
Проверить IPv4 и IPv6.
Проверить TCP-порт.
Проверить маршрут.
Проверить состояние службы на сервере.
Проверить firewall.
Проверить HTTPS и TLS.
При использовании HTTP/3 проверить доступность QUIC.
Сравнить результаты из разных сетей.

Если сервис доступен из других сетей и сервер работает штатно, необходимо рассматривать проблему на уровне сетевого маршрута или применяемых ограничений.

Что предоставить технической поддержке

Для ускорения диагностики желательно сразу указать:

доменное имя;
IP-адрес;
используемый порт;
протокол;
время возникновения проблемы;
интернет-провайдера;
результаты проверки из другой сети;
название сервиса (если проблема только с ним).

Например:

Домен: planetahost.ru
IP: 62.173.138.27
Порт: 443
Провайдер: XXX
Время возникновения: 14:30

TCP/443: timeout
Через мобильный интернет: работает
Через другой сервер: работает

Дополнительно можно приложить результаты:

dig example.com
traceroute example.com
nc -vz example.com 443
curl -vk https://example.com/

Что важно учитывать

Если ресурс перестал открываться только из определённых сетей, не следует сразу изменять конфигурацию сервера или переносить сервис на другой IP.

Сначала необходимо установить, где возникает проблема.

В некоторых случаях причина действительно находится на сервере: например, остановилась служба, изменились правила firewall или нарушилась IPv6-конфигурация.

В других случаях сервер работает нормально, а проблема возникает за его пределами.

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

Такие системы могут принимать решения на основании IP-адресов, доменных имён, портов, протоколов и других характеристик соединения. Поэтому наличие или прежнее использование на IP-адресе VPN-сервисов, прокси и других сетевых приложений в отдельных случаях также может иметь значение.

При этом если блокировка происходит на стороне сети или оборудования вышестоящего оператора, хостинг-провайдер не может напрямую повлиять на такую блокировку. В таких случаях хостинг-провайдер также не всегда может определить точную причину ограничения, поскольку решение о фильтрации принимается за пределами его сети.

При этом по одному признаку определить причину невозможно. Необходимо сопоставить результаты проверок из разных сетей.

Заключение

Если сервер доступен из одной сети, но недоступен из другой, важно определить, где именно возникает проблема: на сервере, на маршруте до него или в самой сети доступа.

Для этого можно сравнить доступность сервера из нескольких разных сетей.

Важно учитывать, что подобные ограничения могут применяться и к другим внешним сайтам, а не только к вашему серверу. Поэтому проблема, которая проявляется только через определённого провайдера, не обязательно связана с сервером. Подробнее о проверке доступности сайта можно прочитать в нашей другой статье.

Такое сравнение помогает понять, находится ли проблема на стороне сервера или возникает где-то в сети между пользователем и сервером.