Допускает ли anycast использование альтернативных маршрутов?
Немного натренированный заголовок, но я недостаточно разбираюсь в предмете, чтобы придумать более подходящий 1.
Я снова и снова читал, что anycast - отличное решение для балансировки нагрузки и предпочтительное решение для балансировки нагрузки DNS. Однако мне интересно, Anycast имеет только преимущество балансировки нагрузки и не обеспечивает избыточности. В то время как простое решение DNS без балансировки нагрузки (т.е. только несколько записей A) не предлагает никакой балансировки нагрузки, но, похоже, предлагает лучшую избыточность.
Я внимательно изучил службы DNS и заметил, что в 2016 году Dyn произошел сбой: https://en.wikipedia.org/wiki/2016_Dyn_cyberattack . Но две вещи:
1) Если что-то пойдет не так с сервером за определенным объявлением anycast, будут ли автоматически проверяться другие маршруты? Если да, то почему Dyn пострадал от такого сбоя - или это из-за того, что DNS работает на UDP?
Например, если мы пытаемся подключиться к синему узлу, следуем маршруту 1-2-6 и находим маршрут 6 не работает (невозможно подключиться к серверу или какая-то ошибка), будут ли автоматически проверяться маршруты 1-2-5 или 1-3-4?
2) Есть ли что-нибудь, что клиент может сделать, чтобы смягчить эту проблему?
3) Мне кажется, что anycast с большей вероятностью пожертвовать определенным регионом, чтобы другие регионы оставались в сети, в отличие от большего количества циклического перебора DNS, который не обеспечил бы такую же производительность, но обеспечил бы лучшую амортизацию такой атаки. Итак, почему (при условии, что мои мысли верны), похоже, будет большой толчок для anycast и меньше - для большего количества служб DNS с циклическим перебором, которые возвращали бы порядок серверов, релевантный для пользователя.
I ' Я знаю об этом вопросе Несколько центров обработки данных и HTTP-трафик: DNS Round Robin - ЕДИНСТВЕННЫЙ способ обеспечить мгновенное переключение при отказе? хотя я не считаю это дубликатом, поскольку я ' m интересуется причинами, по которым anycast может терпеть неудачу, как это происходит.
Итак, сначала давайте кратко рассмотрим, что подразумевается под использованием anycast для DNS:
Данный IP-адрес a - это преобразователь, который мы хотим сделать более доступным. Хост a является членом подсети A / 24. Anycast может выполняться с использованием определенных маршрутов хоста (например, a / 32), но обычно это наблюдается только в частных сетях, а не в общем Интернете.
Существует некий механизм, при котором подсеть A динамически объявляется только тогда, когда соответствующая служба DNS работает. Обратите внимание (и это действительно ] важно), что само объявление может исходить с одного хоста на сайте, на котором запущен преобразователь, со всего физического сайта, содержащего несколько экземпляров указанного преобразователя (т.е. многие хосты, работающие преобразователи, сайт в целом разделяет один маршрут).
Один и тот же маршрут ( A ) будет объявляться из нескольких точек в общедоступном Интернете. Это может быть большой провайдер (читай: точки присутствия, рассредоточенные по всему миру), представляющий один и тот же маршрут в каждой точке соединения с зарубежными сетями или один и тот же маршрут, исходящий из точек, размещенных у нескольких операторов.
Итак - когда произвольный клиент отправляет пакет по IP-адресу с произвольной рассылкой, указанный пакет будет стремиться найти себя к «ближайшей» точке объявления. Я поместил пугающие кавычки вокруг самых близких, потому что они близки только в том смысле, как была выложена топология маршрутизации и какие политики используются для маршрутизаторов на этом пути. Вполне возможно, что ближайший экземпляр адреса anycast может оказаться самым дальним физически.
Если, в свою очередь, точка, в которой объявляется этот маршрут, терпит неудачу (... что может быть результатом сбоя службы на хосте и отмены маршрута или более традиционной проблемы с доступностью сети), то пакеты, привязанные к anycast адрес будет перенаправлен на следующий ближайший (опять же - в терминах протокола маршрутизации) экземпляр маршрута. Во время повторной конвергенции сети разрешение клиента может завершиться ошибкой и попытаться повторить попытку, при этом повторная попытка теперь идет по более длинному пути для достижения, по-видимому, того же адреса. Все это прозрачно как для клиентского процесса, так и для пользователя, и в терминах сети лучше всего рассматривать это как следование альтернативному пути к данной сети.
Иногда полезно думать о произвольной сети как о логической конструкции.Это виртуальная подсеть, которая содержит интересующую вас службу. Эта виртуальная подсеть доступна по многим путям в сети.
Тем не менее, вот основные предостережения при проектировании Anycast:
Поскольку нет гарантии, что данный пакет для Anycast IP достигнет того же физического хоста, этот подход действительно отображается только на протоколы без установления соединения.
Надежность решения настолько хороша, насколько хороша логика, связывающая правильную работу сервиса с объявлением маршрута. Если служба выйдет из строя и маршрут будет продолжать рекламироваться, то может возникнуть потенциально значительная черная дыра.
Получение хороших и правильных ] объявлений маршрутов, распространяемых по общедоступному Интернету, не является тривиальной задачей. Создавать горячие точки очень просто: конкретный экземпляр произвольного маршрута, который предпочтительнее для большинства клиентов. Это все еще потенциально достойное решение высокой доступности (для более простых типов сбоев), но оно не относится к балансировке нагрузки.
Теперь - наконец - когда все это изложено, на ваш вопрос легче ответить:
Нет ничего , присущего любому типу рассылки, что делало бы его более устойчивым к DDoS. Каждый из потенциально миллионов потоков DDoS-трафика найдет свой путь к ближайшему экземпляру, что, вероятно, сделает его недоступным для других легитимных клиентов, которые в противном случае были бы направлены к этим точкам.
Теперь, если подавляющее большинство хостов в используемых ботнетах находилось, скажем, в Восточной Европе, и один из маршрутов anycast происходил из ближайшего PoP (опять же - «поблизости» с точки зрения маршрутизации топология), тогда этот трафик будет опускаться до одной точки, в то время как большая часть остального мира продолжит разрешаться по тому же маршруту, который также был размещен в удобных точках на других континентах. В этом конкретном случае anycast, возможно, будет одним из лучших механизмов для минимизации ущерба от DDoS-атаки. Это в значительной степени зависит от того, как были распределены маршруты anycast и как была настроена политика (см. № 3 выше - нетривиальная проблема).
Очевидно, что этот вариант использования не так убедителен в случае DDoS-атаки это действительно распределенное . Однако при правильном проектировании локализация маршрутов anycast означает, что атакующая нагрузка теперь может быть распределена по произвольному количеству географически распределенных физических хостов. Это будет иметь тенденцию ослаблять эффект атаки на цель, а также потенциально распространять воздействие на большую часть сети. Опять же - огромная сумма зависит от того, как все было спроектировано и настроено.
Почему это считается победой по круговой системе? Просто потому, что можно развернуть произвольное количество хостов без необходимости в отдельных балансировщиках нагрузки на отдельных IP-адресах, а также нет зависимости от значения тайм-аута для конкретных клиентов, решающих перейти на другой преобразователь. Можно буквально развернуть тысячу хостов в одном центре обработки данных с одним и тем же IP-адресом и соответствующим образом сбалансировать трафик (nb - очевидно, огромные практические ограничения, основанные на размере таблиц ECMP и т. Д.) Или развернуть тысячу географически разнесенных сайтов каждый с тысячей хостов. Все это может быть выполнено без изменения конфигурации клиента, без (по общему признанию, обычно кластеризованной) точки отказа балансировщика нагрузки и т. Д. Короче говоря, при правильной настройке он масштабируется так же, как и Интернет в целом.