Тогда проверяем:
- отвечает ли сервер
SYN-ACK; - не блокирует ли ответ локальный firewall;
- корректен ли обратный маршрут;
- нет ли асимметричной маршрутизации.
Это важный момент. Для успешного TCP-соединения нужен путь не только:
client → server
но и:
server → client
Поэтому:
пакет дошёл до сервера
≠
TCP-соединение установлено
10. TCP работает, но HTTPS — нет
Допустим:
nc → success
но:
curl -vk https://service.example.ru/
завершается ошибкой. Теперь сетевой слой уже менее подозрителен. Проверяем:
- TLS handshake;
- сертификат;
- SNI;
- hostname;
- конфигурацию nginx;
- виртуальные хосты;
- обратный прокси.
Например, запрос по IP может попадать в один virtual host, а по имени:
service.example.ru
— в другой.
Тогда:
https://192.0.2.50 → работает
и:
https://service.example.ru → не работает
не являются противоречием. Это две разные проверки.
11. Обратный прокси тоже может быть границей
Допустим, пользователь приходит не прямо на nginx приложения:
client ↓ reverse proxy ↓ application server
Тогда локальный тест:
curl https://localhost/
на application server вообще не проверяет путь пользователя. Нужно отдельно проверить:
client → reverse proxy
и:
reverse proxy → backend
Если reverse proxy отвечает:
502 Bad Gateway
это означает не то, что «HTTPS не работает». Наоборот: клиент уже дошёл до reverse proxy и получил от него HTTP-ответ. Теперь область поиска смещается к backend.
12. Проверяем журнал в момент ошибки
Например:
journalctl -u nginx
или application log. Но полезнее смотреть события в момент конкретной попытки подключения. Если пользователь выполняет запрос в 14:35, а мы изучаем случайные ошибки недельной давности, связь между ними ещё не доказана. Хорошая диагностика связывает:
конкретная попытка пользователя
↓
конкретное сетевое событие
↓
конкретная запись журнала
13. Допустим, находим причину
Например, выясняется:
nginx → работает локальный firewall → разрешает 443 пакеты с клиента → до сервера не доходят
После проверки промежуточного firewall обнаруживаем:
source network: 10.20.30.0/24 разрешённый source: 10.20.20.0/24
То есть правило существует, но разрешает не ту сеть. Формулируем подтверждённый вывод:
HTTPS-сервис исправен локально, но входящие соединения из пользовательского сегмента блокируются промежуточным межсетевым экраном из-за неверно заданной исходной сети в ACL.
Теперь рекомендация уже конкретна: скорректировать ACL для требуемого пользовательского сегмента.
14. После изменения нужна проверка результата
Исправили правило. На этом работа ещё не закончена. Повторяем проверку из исходной пользовательской точки:
DNS → OK TCP 443 → OK TLS → OK HTTP → OK application response → OK
Именно так подтверждаем: пользовательский сценарий восстановлен. Не достаточно:
firewall rule changed
Нужно:
пользователь снова может воспользоваться сервисом
Главное
Локальные проверки отвечают только на локальные вопросы:
systemd active
↓
процесс запущен
LISTEN
↓
сокет существует
curl localhost → 200
↓
локальный HTTP-запрос успешен
Но пользователь работает через всю цепочку:
DNS ↓ network ↓ firewalls / ACL ↓ proxy / NAT ↓ server ↓ application
Поэтому:
работает локально
≠
доступно пользователю
При таких проблемах эффективнее не менять настройки наугад, а последовательно определять: на каком участке запроса заканчивается подтверждённая работоспособность.
#Кейс #Linux #Network #Troubleshooting #ПоФактам