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