Что такое исходный сервер и чем он отличается от CDN

Исходный сервер (origin) — это система, которая передаёт оригинальный контент сайта или ответы приложения посреднику: CDN, обратному прокси или балансировщику нагрузки. Посетитель может подключаться к посреднику, а не напрямую к исходному серверу. Посредник способен кешировать контент, терминировать TLS, фильтровать трафик, распределять запросы или защищать исходный сервер от прямого доступа. Эта архитектура объясняет, почему проверка «домен в IP» часто возвращает адрес, принадлежащий CDN или прокси, а не машине, на которой хранятся данные приложения. Публичный DNS-ответ указывает опубликованную точку входа, но не обязательно каждый внутренний компонент за ней.

Путь запроса через посредника

Типичный путь запроса начинается с того, что DNS разрешает публичное имя хоста в адрес пограничной точки. Браузер пользователя подключается к CDN или прокси, а тот решает, может ли он отдать закешированный ответ или нужно переслать запрос на исходный сервер. Исходным сервером может быть виртуальная машина, платформа контейнеров, облачный балансировщик нагрузки или управляемый хостинг. Между публичной пограничной точкой и приложением может быть несколько уровней. У каждого уровня свои настройки работоспособности, маршрутизации и безопасности, поэтому успешный DNS-запрос подтверждает лишь опубликованный адрес точки входа; он не подтверждает, что прокси может связаться с исходным сервером.

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

Почему по IP-запросу нельзя определить исходный сервер

DNS-запрос возвращает записи, которые резолверам разрешено видеть. Если домен указывает на CDN, эти ответы — публичные конечные точки CDN. DNS может вообще не раскрывать исходный сервер, и инструмент проверки не должен утверждать, что IP пограничной точки — это исходный сервер. Сведения о владельце адреса помогают определить поставщика инфраструктуры, но всё равно не раскрывают полную топологию бэкенда. В работе по безопасности или инцидентам относитесь к таким данным осторожно: общие адреса пограничных точек могут обслуживать множество доменов, и выводы по одному адресу способны привести к неверной атрибуции сервиса.

• Используйте DNS, чтобы определить публичную точку входа, а не чтобы гадать об архитектуре бэкенда.
• Проверяйте панели CDN и обратного прокси на предмет связности и работоспособности исходного сервера.
• Защищайте доступ к исходному серверу документированными сетевыми мерами и аутентификацией.
• Не раскрывайте непреднамеренно приватные или административные исходные серверы в публичном DNS.
• Описывайте наблюдаемые IP точно: как публичные DNS-ответы на конкретный момент времени.

Диагностика снаружи внутрь

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

О смежной архитектуре читайте в статьях как CDN маршрутизируют трафик через DNS и почему CDN скрывают IP исходного сервера. Публичный инструмент проверки домена полезен, чтобы увидеть адрес, который DNS объявляет сейчас. Чтобы диагностировать исходный сервер, используйте телеметрию собственного хостинга и прокси, а не считайте публичное разрешение имён полной картой внутреннего устройства сервиса.

Исходный сервер — это роль приложения, а не конкретный адрес

Команды иногда описывают исходный сервер как единый серверный IP, но в современных развёртываниях за одним CDN могут стоять несколько пулов исходных серверов, приватные балансировщики нагрузки, бессерверные приложения или хранилища. Роль исходного сервера определяется тем, что поставляет контент посреднику, а не одной постоянной машиной. Исходный сервер может переехать или масштабироваться, а публичный DNS при этом продолжит объявлять ту же пограничную точку. При документировании архитектуры помечайте каждую границу: публичное имя хоста, пограничная точка CDN, конечная точка исходного сервера и бэкенд приложения. Это помогает тем, кто занимается инцидентами, запрашивать нужные журналы у нужного владельца. Если ответ ломается на пограничной точке, сопоставляйте диагностику пограничной точки с работоспособностью исходного сервера и идентификаторами запросов, а не считайте, что публичный DNS-адрес указывает на сбойный компонент.