Сервис выходит в сеть с неожиданного адреса: читаем ip route get

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

Разбор стоит начать с конкретного назначения: IP партнёра и порта приложения. Выяснять «какой у сервера IP» слишком расплывчато. У одного узла одновременно существуют адрес управления, адрес внутренней сети и адрес, который видит внешний сервис после трансляции.

Спросите ядро о выбранном пути

ip -br address
ip route get 192.0.2.80

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

Допустим, нужный адрес — 198.51.100.20, а выбран src 10.20.0.10. Теперь есть проверяемая гипотеза: обычное соединение получает другой локальный адрес. Запишите весь ответ, включая маршрут. Исправление только адреса может оставить соединение на интерфейсе, через который партнёр вообще недоступен.

Проверьте соединение с заданным источником

ip route get 192.0.2.80 from 198.51.100.20
curl --interface 198.51.100.20 --connect-timeout 5 --max-time 15 https://api.partner.example/health

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

Успех запроса с явным источником сужает задачу до выбора адреса и сетевой политики. Но партнёр после NAT может видеть совсем другой IP. Попросите его сопоставить время запроса с журналом входящих соединений либо используйте согласованную точку наблюдения на внешней границе. Локальное поле src не раскрывает результат будущей трансляции.

Как закрепить вывод в рабочем решении

Для одного клиента можно оставить явную привязку, если приложение поддерживает такую настройку. Когда правило требуется нескольким службам, разберите маршруты и правила выбора таблиц с сетевым администратором. Не меняйте default route в надежде исправить один API: это затронет управление сервером и другие назначения.

Если заданный источник даёт успешное TCP-соединение, но HTTP отвечает 403, сохраните ответ отдельно. Приложение партнёра может проверять дополнительную авторизацию. Успешный сетевой путь и разрешённая бизнес-операция — два последовательных условия. Именно журнал партнёра покажет, какое из них ещё не выполнено.

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

Следующий шаг — связать адреса, маршруты и доступность приложения в одну диагностику. В курсе «Linux и Bash для DevOps-инженеров» есть работа с сетью, портами, DNS и HTTP на учебном сервере. Откройте программу, чтобы перейти от отдельных команд к последовательной проверке сетевого сбоя.

Ещё по теме

• IPv4 работает, IPv6 зависает: проверяем AAAA и отдельный путь до сервиса
• CLOSE_WAIT растёт: почему перезапуск сети не закрывает сокеты приложения