Допускает ли anycast использование альтернативных маршрутов?

Итак, сначала давайте кратко рассмотрим, что подразумевается под использованием anycast для DNS:

1. Данный IP-адрес а - это преобразователь, который мы хотим сделать более доступным. В а хозяин является членом А / 24 подсеть. Anycast может выполняться с определенными маршрутами хоста (т.е. а/ 32), но обычно это наблюдается только в частных сетях, а не в общем Интернете.

2. Существует некий механизм, позволяющий А подсеть динамически объявляется только тогда, когда соответствующая служба DNS работает. Обратите внимание (а это действительно важно), что сама реклама может исходить с одного хоста внутри сайта, на котором работает преобразователь, со всего физического сайта, содержащего несколько экземпляров указанного преобразователя (т.е. многие хосты, на которых запущены преобразователи, сайт в целом использует один маршрут).

3. Тот же маршрут (А) будет рекламироваться из нескольких точек в общедоступном Интернете. Это может быть большой провайдер (читай: точки присутствия, рассредоточенные по всему миру), представляющий один и тот же маршрут в каждой точке соединения с зарубежными сетями или один и тот же маршрут, исходящий из точек, размещенных у нескольких операторов.

Итак - когда произвольный клиент отправляет пакет по любому IP-адресу, указанный пакет будет стремиться найти себя в «ближайшей» точке рекламы. Я поместил пугающие кавычки вокруг самых близких, потому что они близки только в том смысле, как была выложена топология маршрутизации и какие политики используются для маршрутизаторов на этом пути. Вполне возможно, что ближайший экземпляр адреса anycast может оказаться самым дальним физически.

Если, в свою очередь, точка, в которой объявляется этот маршрут, терпит неудачу (... что может быть результатом сбоя службы на хосте и отмены маршрута или более традиционной проблемы с доступностью сети), то пакеты, привязанные к адресу anycast, будут направляется к следующему ближайшему (опять же - в терминах протокола маршрутизации) экземпляру маршрута. Во время повторной конвергенции сети разрешение клиента может завершиться ошибкой и попытаться повторить попытку, при этом повторная попытка теперь идет по более длинному пути для достижения, по-видимому, того же адреса. Все это прозрачно как для клиентского процесса, так и для пользователя, и с точки зрения сети лучше всего рассматривать это как следование альтернативному пути к данной сети.

Иногда полезно думать о произвольной сети как о логической конструкции. Это виртуальная подсеть, которая содержит интересующую вас службу. Эта виртуальная подсеть доступна по многим путям в сети.

Тем не менее, вот основные предостережения в отношении любого дизайна:

1. Поскольку нет гарантии, что данный пакет для IP-адреса anycast достигнет одного и того же физического хоста, этот подход действительно соответствует только протоколам без установления соединения.

2. Надежность решения зависит от логики, связывающей правильную работу сервиса с объявлением маршрута. Если служба прекратит работу, а маршрут будет продолжать рекламироваться, возникнет потенциально значительная черная дыра.

3. Получение рекламы о любом маршруте хорошо и должным образом- распространять по общедоступному Интернету нетривиально. Создавать горячие точки очень просто: конкретный экземпляр произвольного маршрута, который предпочтительнее для большинства клиентов. Это все еще потенциально достойное решение высокой доступности (для более простых типов сбоев), но оно не относится к балансировке нагрузки.

Теперь - наконец - когда все это изложено, на ваш вопрос легче ответить:

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

Теперь, если подавляющее большинство хостов в используемых ботнетах находилось, скажем, в Восточной Европе, и один из маршрутов anycast был создан в соседнем PoP (опять же - «поблизости» с точки зрения топологии маршрутизации), тогда этот трафик упадет до одной точки, в то время как большая часть остального мира продолжит использовать тот же маршрут, который также проходил в удобных точках на других континентах. В этом конкретном случае anycast, возможно, был бы одним из Лучший механизмы минимизации ущерба от DDoS-атаки. Это сильно зависит от того, как были распределены маршруты anycast и как была настроена политика (см. № 3 выше - нетривиальная проблема).

Очевидно, что этот вариант использования не столь убедителен в случае DDoS-атаки, которая действительно распределен. Однако при правильном проектировании локализация маршрутов anycast означает, что атакующая нагрузка теперь может быть распределена по произвольному количеству географически распределенных физических хостов. Это будет иметь тенденцию ослаблять эффект атаки на цель, а также потенциально распространять воздействие на большую часть сети. Опять же - огромный сумма зависит от того, как все было спроектировано и настроено.

Почему это считается победой по круговой системе? Просто потому, что можно развернуть произвольное количество хостов без необходимости в отдельных балансировщиках нагрузки на отдельных IP-адресах, а также нет зависимости от значения тайм-аута для конкретных клиентов, решающих перейти на другой преобразователь. Можно было буквально развернуть тысячу хостов в пределах единый центр обработки данных с одним и тем же IP-адресом и соответствующим образом распределять трафик (например, огромные практические ограничения, основанные на размере таблиц ECMP и т. д.) или развернуть тысячу географически разнесенных сайтов каждый с тысячей хозяев. Все это может быть выполнено без изменения конфигурации клиента, без (по общему признанию, обычно кластеризованной) точки отказа балансировщика нагрузки и т. Д. Короче говоря, при правильной настройке он масштабируется так же, как и Интернет в целом.