Я, наверное, полный новичок в вопросах, связанных с сбоями сервера, но наш ИТ-отдел делает смелое заявление, которое я хочу проверить. Я искал в Интернете, но не нашел ничего, связанного с моим вопросом, поэтому прихожу сюда.
У нас есть Threat Management Gateway 2010, и мы просто перенаправляли запрос в IIS, и он содержал IP-адрес, чтобы мы могли видеть, откуда он идет. Но теперь они включили «Запросы приходят на сервер TMG», поэтому IP-адреса больше не пересылаются. У каждого запроса есть IP-адрес сервера TMG.
Идея заключается в том, что из-за многопутевых маршрутов bgp входящий запрос проходит через RouteA, но сообщения подтверждения мог вернуться через RouteB. Утверждается, что, поскольку запрос исходит не из первого известного источника, нашего прокси, а из IIS, некоторые умные маршрутизаторы на посетителе наших веб-сайтов не распознают сообщение подтверждения и не фильтруют его. Другими словами, ответ никогда не приходит.
Опять же, это претензия. Но я не могу найти НИКАКИХ ресурсов в Интернете, подтверждающих это утверждение. Я действительно читал о многопутевости bgp, но больше в том случае, если есть альтернативные маршруты, когда самый быстрый маршрут по какой-то причине не работает.
Итак, это утверждение полностью надумано или в нем есть доля правды? Может ли кто-нибудь объяснить или указать мне ресурсы?
Заранее спасибо!
Такая асимметричная маршрутизация действительно довольно часто встречается в Интернете. У данного маршрутизатора BGP может быть множество правил локальных предпочтений, а также разные точки зрения на путь и одноранговые узлы, которые он предпочитает использовать. Интернет-маршрутизатор не знает и не заботится о том, через какой канал прошел сеанс, и это тоже не имеет значения; пока пакет доходит до места назначения, все работает нормально.
Но это поведение не имеет никакого отношения к обмену данными между вашим веб-сервером и прокси TMG.
Проблема с объяснением здесь:
запрос исходит не из первого известного источника, нашего прокси, а из IIS
Если бы это было правдой, то все подключения к веб-серверу безоговорочно завершились бы ошибкой. Клиент подключается к IP-адресу прокси-сервера и ожидает ответного трафика с того же адреса - сервер IIS, являющийся исходным IP-адресом ответного трафика (пропуская TMG), будет отклонять ответный трафик.
Причина, по которой TMG правильно работает, когда очевидным источником подключения является «настоящий» клиент, заключается в том, что TMG находится в очереди перед вашим веб-сервером (это работает, только если TMG находится в линии, действуя как ваш маршрутизатор) . TMG видит ответный трафик от вашего веб-сервера, связанный с адресом клиента, улавливает его и отправляет клиенту через правильное соединение (то, которое клиент инициировал для TMG).
Итак, в основном, BGP и интернет-маршрутизация не имеют к этому никакого отношения, но подобный вид асимметричной маршрутизации во внутренней сети (где устройство TMG не используется для маршрутизации трафика ответа) разорвет соединения с веб-клиентами и потребует использования IP-адрес TMG в качестве очевидного источника подключения. Может они планируют изменение топологии?