14.07.2008

Борьба за корневые DNS сервера.  Хорошие парни побеждают?

image

Однозначно никто не может сказать, способна ли данная схема с существующим числом корневых DNS серверов противостоять распределенным DoS атакам в случае использования бот сетей с миллионами хостов.

Введение

            ICCAN объявил, что с 2009 года можно будет зарегистрировать  домены верхнего уровня, а это означает, что нагрузка на корневые DNS сервера дополнительно возрастет. Корневые DNS сервера Интернет периодически атакуют, используя бот сети. Бот сети разрастаются до огромных размеров. Практически ни одна из коммерческих организаций не способа противостоять DoS атакам с использованием бот-сетей.

Давайте разберемся, что «хорошие парни», ответственные за работоспособность корневых  DNS серверов противопоставляют  «плохим  парням», которые, возможно, будут атаковать эти сервера.

Основы работы DNS.

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

            Чтобы разобраться, почему атакуются именно корневые сервера DNS необходимо понимать, как работает эта система. Графически, структуру DNS корректней всего представить в виде дерева.

            В корне дерева расположены так называемые корневые сервера. Их всего 13 штук. Корневые сервера знают о месте положения (IP адреса) так называемых TLD (Top Level Domain) серверов. TLD сервера обслуживают большие зоны первого уровня, такие как com, net, ru, kz, ua, gov….  Группа TLD серверов знает о месте положения серверов обслуживающих домены второго уровня в пределах их зоны ответственности. Например, ответственные за домен  com знают IP адреса серверов второго уровня для зоны первого уровня com, ответственные за зону ru  знают о серверах зоны ru, ну и так далее. Сервера ответственные за зоны второго уровня уже, как правило,   знают конкретные адреса серверов, предоставляющих сервисы интернета, таких как www, mail и т.д. Также сервера второго уровня  могут быть ответственными за домены третьего уровня, ну и так далее.

            Для того, чтобы понять как вся  структура функционирует, рассмотрим как это работает на примере определения  IP адреса сервера www.securityab.ru. Для упрощения,  рассмотрим пример работы рекурсивного DNS без учета механизмов кэширования.

            Все, что первоначально  известно серверу, который предоставляет услуги DNS это 13 IP адресов корневых серверов. В моей любимой ОС FreeBSD они жестко прописаны в файле named.root, в вашей любимой ОС, они, возможно, хранятся в других местах, но, эти   IP адреса однозначно одна из самых постоянных вещей Интернета. 

Допустим, клиент запрашивает IP адрес сервера www.securitylab.ru сервер DNS, который его обслуживает. Тот, в свою очередь, спрашивает об этом корневые сервера, при этом IP адрес корневого сервера выбирается произвольно. Один из корневых серверов ему отвечает, что ничего не знает о www.securitylab.ru, но, спросить об этом можно у  одного из 6-ти (на данный момент) TLD серверов, ответственных за зону ru. Сервер DNS запрашивает один из серверов TLD, который отвечает, что надо бы запросить об этом один из трех серверов ответственных за зону второго уровня securitylab.ru. Сервер DNS дает третий запрос к одному из серверов второго уровня, и, наконец, узнает что www.securitylab.ru живет на IP адресе 217.16.31.134.

            Все это справедливо, если вы не используете при работе с DNS кэширование (запоминаете результаты предыдущих запросов). Кэширование подразумевает, что после первого запроса сервер  уже знает адреса серверов, которые хранят информацию о зоне ru и securitylab.ru и, собственно, где расположен www.securitylab.ru.

            Кэширование выгодно всем. Меньше запросов к корневым и TLD серверам, меньше трафика тратит сервер DNS провайдера, меньше времени клиент ждет ответа от DNS сервера провайдера.

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

            Технически, проще завалить TLD сервера. Однако, не смотря на это, атакуют чаще всего, именно корневые сервера, так как, срубив ветвь, даже очень большую, такую как com, net или org,, вы  всего лишь, срубите часть дерева, но не весь DNS. Убив же корень, вы добьетесь максимального эффекта.

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

            Вообще, проблема при распределенных DoS атаках на корневые DNS сервера вовсе не в том, что они  не успевают обрабатывать запросы. Основная проблема в том, что они становятся недоступными по сети. Фактически, чтобы вызвать отказ в обслуживании всей системы DNS, атакующим достаточно одновременно вывести из строя 13 географически распределенных точек  сети. Конечно, можно прописать еще несколько десятков серверов в качестве корневых. Однако это сложно с точки зрения того, что необходимо будет менять настройки программного обеспечения на всех клиентах.  Кроме того, такая система не гарантирует рационального распределения трафика между корневыми серверами.

            В качестве другого решения противостояния распределенным DoS атакам на текущий момент внедрена крайне масштабируемая система с использованием anycast. Рассмотрим, что это такое.

Что такое anycast.

Не смотря на то, что технология anycast была описана еще в ноябре 1993 года в RFC 1546, очень мало сетевых профессионалов  знают, что это такое. Дело тут не в сложности технологии, а скорее в том, что ее использование ограничено узкой областью применения.

Слово anycast образуется от двух английских слов any – любой, cast – бросать, или, в терминах сети, вещать. Вообще в сети различают 4 метода вещания - broadcast, multicast, unicast и anycast.

Если вы откроете Википедию по cast-ам  то увидите там 4 красивых рисунка иллюстрирующих их. Позволю себе их использовать.

broadcast-ы передаются от вещающего одновременно всем. По аналогии с реальным миром у вещающего есть мегафон, с помощью которого он разговаривает с толпой людей. Его слышат все, но радиус действия мегафона ограничен.  Примером использования broadcast-а является процесс выдачи IP адреса хосту по протоколу DHCP. В сетях broadcast-ы обычно не распространяются дальше локальной сети.

multicast больше похож на радио. Радиус действия у него может быть большой, однако вы его не услышите, пока не включите радио, в терминах сети не подпишется на услугу. Пример использования multicast-а – IPTV, когда вы переключаете каналы на своей IPTV приставке, вы подписываетесь на определенный канал multicast  вещания, и только после этого вам доставляется картинка со звуком. При этом на один и тот же канал могут подписаться одновременно многие пользователи.

unicast можно сравнить с телефоном. Набрав определенный номер, вы разговариваете с определенным человеком. В сети, указав IP адрес, протокол и порт, вы общаетесь с определенным сервером. Большинство общений между хостами в Интернет происходит по технологии unicast. Примеров использования unicast-ов множество - от закачки файлов по ftp до передачи электронной почты.

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

            Чтобы понять, как работает anycast необходимо иметь представления о том, как работает  маршрутизация в сетях использующих протокол IP.

Основы маршрутизации.

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

Часто, два удаленных хоста в Интернете связаны между собой избыточными связями. Порой,  пакет данных отосланный от хоста A теоретически может достичь хоста Б десятками различных путей. Совсем не факт, что если пакет от хоста А прошел через 3 определенных маршрутизатора, то обратный пакет от хоста Б придет через те же 3 маршрутизатора.   Наличие избыточных связей  дает 2 основных преимущества, первое – выход из строя одного из каналов связи не будет означать недоступности для группы хостов, второе – нагрузка при передаче данных может распределяться между различными каналами, в результате общая пропускная способность сети возрастает.

В процессе принятия решения, через какой из возможных путей переслать пакет маршрутизатор руководствуется, прежде всего, адресом назначения пакета и логикой маршрутизации. Обычно, маршрутизатор не руководствуется информацией об источнике (кто послал пакет), протоколе, портах и прочей информацией заголовков пакета данных. Но, например, у маршрутизаторов cisco есть особая фича, так называемый PBR (Policy-Based Routing) http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfclass.html#wpxref35843

, однако, это скорее исключение, чем правило.

            Забавно, но даже сетевики со стажем не всегда четко представляют, что служит критерием принятия решения о направлении пакетов по тому либо иному маршруту. Простейшая задача, на картинке ниже вводит их в ступор.

Вопрос: пакет на хост 192.168.0.2 уйдет с верхнего или нижнего интерфейса?

Правильный ответ – с  верхнего. Почему? Потому, что при выборе лучшего маршрута последовательно срабатывают следующие 3 правила.

1)      Если длины префиксов подсетей, в которые попадает IP адрес хоста назначения разные, то выбирается маршрут с самым длинным префиксом.

2)      Если префиксы равны, то выбирается маршрут с более приоритетным протоколом маршрутизации.

3)      Если и префиксы равны и протоколы одинаковые, то срабатывает внутренняя метрика протокола маршрутизации.

В данном примере сработало первое правило.

А теперь немного подробней. Что такое префикс? Префикс это метод описания подсети. Префикс состоит из двух частей, левая – идентификатор подсети, правая – длина этого идентификатора.

Самый длинный префикс имеет длину 32 при этом левая часть такого префикса, по сути, является IP адресом. Самый короткий префикс имеет длину 0, при этом левая часть префикса также равна 0, такой префикс записывается как 0/0 или 0.0.0.0/0, и в него попадают все возможные IP адреса.

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

Маршруты могут вноситься ручками в конфигурацию маршрутизатора, это называется статическая маршрутизация, а могут появляться там автоматически, с помощью протоколов динамической маршрутизации.

Основной принцип динамической маршрутизации прост. Каждый маршрутизатор знает о нескольких сетях доступных через него. После включения динамической маршрутизации соседние маршрутизаторы начинают обмениваться информацией о доступных через них сетях. В конце концов, после полного обмена маршрутной информацией у каждого маршрутизатора появляется полное представление обо всех подсетях в пределах автономной системы маршрутизации (например, какие есть подсети, через какие интерфейсы они доступны, как далеко они расположены).  В случае, если происходят некоторые события, например пропадает линк между маршрутизаторами, или вносятся/удаляются определенные подсети, таблицы маршрутизации автоматически пересчитываются.

Несколько слов о приоритетах протоколов маршрутизации. Статическая маршрутизация имеет наивысший приоритет, различные  протоколы динамической маршрутизации имеют каждый свой приоритет. В примере, приведенном выше, если бы префиксы подсетей совпадали, то пакет, согласно второму правилу, был бы передан через нижний интерфейс. Область действия приоритетов протоколов маршрутизации локальна для каждого маршрутизатора. Если маршрутизатор A получил маршрут для сети 192.168.0.0/28 через статический маршрут, а маршрутизатор B получил маршрут 192.168.0.0/28 от маршрутизаторов A и C по OSPF, то маршрутизатор B в выборе приоритетов руководствуется метриками OSPF. То есть маршрутизатору не важно, как соседи узнали о том либо ином маршруте, важно только то, как и что он о нем узнал.

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

Различные протоколы динамической маршрутизации вычисляют метрики различными способами. Для примера поверхностно рассмотрим критерии выбора маршрута протоколом динамической маршрутизации OSPF.

OSPF - Open Shortest Path first, вольно это можно перевести как лучший (маршрут) - с наименьшим доступным путем. Это значит, что в случае равнозначных (по скорости) связей между узлами сети выбирается маршрут с наименьшим количеством маршрутизаторов через которые он будет следовать. На длину пути автоматически влияет скорость, с которой работает интерфейс. Например, если интерфейс работает на скорости 100Мбит/c, то путь до соседа будет равен 1, если 10Мбит/c, то он будет  равен 10 и т.д. Повлиять на дистанцию можно и ручками. Для этого надо просто прописать на нужном интерфейсе параметр bandwith (емкость), который не влияет на физическую скорость интерфейса, но влияет на процесс принятия решения маршрутизации.

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

Правило номер 1.

Задумайтесь, как описать, где расположены выходы из вашей сети, в которой крутится, допустим, тот же OSPF. Естественно, на маршрутизаторах, где они (выходы) расположены надо прописать маршрут по умолчанию (default gateway). В маршрут по умолчанию должны включаться все возможные IP адреса. Как описывается default gateway в префиксах? Вот так - 0/0. Любой IP адрес попадает в префикс 0/0, однако пакеты на default gateway должны кидаться только в том случае, если другие маршруты не срабатывают (адрес назначения не попадает ни в один другой существующий префикс маршрутизации). Default gateway – тот же маршрут, он так же передается между маршрутизаторами протоколом OSPF, следовательно, маршруты с более длинным префиксом всегда делаются более приоритетными, для того, чтобы схема с маршрутом по умолчанию работала.

Правило номер 2.

Метрики различных протоколов маршрутизации не соизмеримы. Гораздо проще дать приоритет одному протоколу маршрутизации над другим, чем, не понятно как, сопоставлять приоритеты метрик различных протоколов маршрутизации.

Правило номер 3.

Оно третье только потому, что первые 2 места уже заняты J

Для того, чтобы понять как организовывается anycast в IP сетях, понимания описанных выше принципов работы маршрутизации достаточно.

Как работает anycast.

            Для описания работы anycast рассмотрим сеть, в которой работает протокол динамической маршрутизацией с максимально упрощенной логикой выбора маршрута из различных  мест до хоста 192.168.0.2. 

Допустим, работает тот же OSPF, при этом линки между маршрутизаторами имеют одинаковую пропускную способность и параметр bandwith нигде не сконфигурирован. Критерием выбора маршрута в данном случае, является только количество маршрутизаторов, через которые должны пройти пакеты. Стрелками разного цвета указаны пути пакетов для того, чтобы достичь сервера.

            А теперь, для этой же сети включим еще один физический сервер с таким же IP  в маршрутизатор F. Этот маршрутизатор, в свою очередь заставим анонсировать тот же префикс через себя.

Очевидно, что в этом случае, часть трафика пойдет на один сервер, часть на другой.

Таким образом, 2 или более, разных, но равноценных сервера с одинаковым IP  можно включить в различные географически удаленные места. Такая схема не только не противоречит принципам маршрутизации, но я бы сказал даже, что она органично в них вписывается.

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

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

В такой схеме есть только одна засада. Допустим, пользователь, работающий через маршрутизатор B качает по ftp большой файл с сервера, работающего через маршрутизатор А. В это время связь между А и B прерывается.  Если бы не было anycast-а, таблицы маршрутизации перестроились бы таким образом, что пакеты пошли  бы в обход, но все равно, достигли бы сервера работающего через A, и закачка бы не прервалась. В случае с anycast-ом пользователь переключится на сервер, работающий через маршрутизатор F. Так как ftp на транспортном уровне использует tcp, который ориентирован на сессию, то закачка для пользователя прервется. Я не буду детально объяснять, почему это так, так как это выходит за рамки статьи. В целом же, относительно возможности нормального использования ориентированных на сессию протоколов со схемами anycast-а, с глобальной точки зрения на функционирование Интернет, мнения специалистов разделились. Одни считают, что это не целесообразно, так как чревато частыми “обрывами” (причем, мало кто способен будет нормально объяснить, почему раньше НЕ БЫЛО НИ ЕДИННОГО ОБРЫВА, а сейчас они есть J), другие же говорят, что заметных “обрывов” не будет, и доказывают это на практике.

 Если вы будете читать информацию по anycast-ам, то вам часто будет встречаться фраза, что объявляются IP адреса с определенным одинаковым префиксом. Подчеркивают это потому, что если вы объявите маршруты до одного и того же IP  с различными префиксами, то работать anycast не будет, это логично, если вы понимаете логику маршрутизации, которая была описана выше, а именно, первое правило. 

Действительно, допустим, вы хотите построить систему с тремя anycast серверами, живущими на одинаковых IP адресах, при этом объявили в маршрутизации 2 из них с префиксом длиной 28, а третий с префиксом длиной 29. Тогда схема не будет работать, так как все пакеты будут маршрутизироваться на третий маршрут. Если же вы прописали третий маршрут с префиксом длиной 27, то пакеты будут идти только на первые два сервера, третий выпадет из схемы.

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

Теперь вернемся к нашим баранам, то есть корневым DNS серверам.

DNS Root сервера и anycast.

            Принцип работы с anycast в глобальном масштабе такой же, как и в локальных сетях. В глобальной сети Интернет в качестве протокола динамической маршрутизации используется протокол BGP.

В целом описывать, как все устроено, и какие проблемы могут возникнуть при включении anycast-а очень сложно. Сам по себе протокол BGP не прост, а при включении anycast возникают дополнительные не совсем приятные моменты. Существует RFC http://tools.ietf.org/html/rfc4786, которые описывают лучшие практики при организации anycast в глобальных масштабах.

Чтобы определить к какому из корневых anycast серверов идут запросы, адресованные на тот либо иной anycast адрес корневого DNS сервера, можно использовать команду.

dig +norec @X.ROOT-SERVERS.NET HOSTNAME.BIND CHAOS TXT

      Где X – буква от A до M для каждого из 13-ти anycast IP адресов серверов.

Если у вас есть возможность давать такие команды с различных географически удаленных серверов в сети, то, можно легко убедиться, что на запросы из различных автономных систем приходят ответы с физически разных серверов.

Хотелось бы осветить различные топологии, используемые различными организациями, ответственными за корневые сервера. Прежде, чем описывать какие топологии используется необходимо ввести 2 понятия anycast DNS серверов. Существуют, так называемые, локальные root anycast сервера и глобальные root anycast сервера. Глобальные сервера – это сервера которые доступны в глобальных пределах, то есть теоретически всем в Интернет, хотя, благодаря регуляциям метриками BGP каждый из них доступен только из определенных мест. Локальные сервера доступны только клиентам нескольких ближайших к ним провайдеров. Регулированием того, какой это сервер глобальный или локальный занимается протокол BGP. Согласно тому, какие сервера (локальные или глобальные) и в какой пропорции используются при  организации anycast, различают 3 схемы.

Единообразная (flat) – состоит только из глобальных серверов, используется для J-root серверов.

Иерархическая (hierarchical) состоит из нескольких географически близко расположенных глобальных серверов и множества локальных серверов используется для F-root серверов.

Гибридная (hybrid) состоит из географически распределенных глобальных серверов и также распределенных локальных серверов используется для K-root серверов.

Вот, например, как выглядит картина глобального местоположение для k-root серверов c IP адресом 193.0.14.129, которую администрирует RIPE www.ripe.net (гибридная схема).

И для f-root с IP адресом 192.5.5.241, которую администрирует Internet Systems Consortium, Inc. www.isc.org  (иерархическая схема).

Как видите, среди различных организаций ответственных за корневые сервера различные подходы. Каждая из схем эффективна, какая из них более эффективна вопрос до конца не определенный.

Согласно всем отчетам, результаты тестирования подтверждают эффективность работы anycast для root DNS серверов в глобальном режиме, проблемы при работе DNS с использованием  tcp не существенны.

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

На текущий момент всего в мире 150 root DNS серверов, что более чем на порядок больше, чем первоначальное число - 13. Более подробную информацию о текущем состоянии дел по корневым серверам можно узнать тут http://www.root-servers.org/

Тот факт, что сервера географически распределены, делает DoS атаку на них более сложной. Бот сеть, которая сможет вывести из строя все корневые сервера также должна быть глобально  распределенной. Ведь, если допустим, хосты атакующей бот сети будут сконцентрированы в основном в Европе, жители Южной Америки даже не будут подозревать о том, что на корневые DNS проводится атака.

            В Интернете можно найти большой объем информации о технологии anycast и в частности об использовании ее для DNS. Что касается рамок данной статьи то, на этом я ограничусь.

Заключение.

            Однозначно никто не может сказать, способна ли данная схема с существующим числом корневых DNS серверов противостоять распределенным DoS атакам в случае использования бот сетей с миллионами хостов. Ясно одно, схема хорошо масштабируемая, и даже если, не смотря ни на что, плохим парням удастся завалить глобальную систему DNS, то хорошие парни в ответ смогут ее многократно усилить. Похоже, хорошие парни побеждают.

Григорий Сандул, zelendoplit@yahoo.com
или введите имя

CAPTCHA
Страницы: 1  2  3  4  
14-07-2008 23:27:56
Видно сразу - статья писалась под пиво! PS: Да кстати - прошу Григорий Сандул перечислить литературу с которой он это все наваял, так как его писанину уж очень сложно читать(я лично еле осилил и ничего нового не узнал)!
0 |
15-07-2008 09:32:47
Статья писалась за выходные. Но, не под пиво. А литературу - гугл вам в помощь . Более того, ссылки которые есть в статье, содержат другие ссылки, большинство информации оттуда. И вообще, читайте RFC батенька.
0 |
15-07-2008 10:13:13
И еще одну вещь хотелось бы сказать на замечание о том что Вы ничего нового не узнали. Совсем недавно, еще в этом месяце, я общался с двумя новоиспеченными письменными CCIE (только сдали экзамен). Вы думаете они знают что такое anycast? Я специально спросил, оказыватеся - не знают. Думаете я знал что такое anycast до прошлого года, пока не заинтересовался этим вопросом после последней атаки на root DNS? Это основная причина, по которой я написал статью. Мужики-то не знают . А вещь, с академической точки зрения интересная.
0 |
15-07-2008 15:12:31
письменными CCIE (только сдали экзамен). Я совсем не удивлен! Люди кроме как погулять, да по-тусить больше ничего не хотят нового выучить! Тем более щас народ пошел не тот, что был раньше((
0 |
1
16-07-2008 12:22:05
Дада, поплачь. Давай про совок еще.
0 |
1
17-07-2008 11:41:07
Да уш... Одного не пойму, зачем они тратят бабло на сертификации и зубрежку, если потом не могут применить это на практике или тупо непонимают базисов? К тому же бесит тот аспект что они и нового ничего не хотят узнать!!! Им просто не интересно. Драма ппц
0 |
17-07-2008 13:20:48
А вот тут Вы не правы. Объективно,их уровень знаний выше моего. Мне, например, для подготовки к письменному CCIE, по самым моим оптимистичным прогнозам необходимо будет как минимум 3 месяца очень, очень сильно сушить себе мозги. Есть очень много технологий, с которыми я не работал или работал, но мало, например MPLS, IS-IS, multicast, ATM, Frame Relay..... Они все это знают, мало того, многое используют на практике. Фишка в том, что anycast - это нечто такое, что используется крайне редко, поэтому они и не знали об этом. А тратят они бабло не напрасно, ибо с такими сертификатами они нужны везде, и получают CCIE-шники, по сравнению с другими инженерами, очень много денег. Кроме всего прочего, для того, чтобы стать партнерами Cisco, а следовательно, получать очень хорошие скидки на оборудование, компаниям необходимо иметь в своем штате определенное количество сертифицированных Cisco специалистов. Поэтому такие люди ну просто нарасхват. Во всем мире на текущий день около 20000 CCIE.
0 |
17-07-2008 18:24:07
Вполне согласен, что сертифицированные люди нужны и они на расхват! Насчет уровня знаний тоже согласен, но если их спросить обо многом по прошествии к примеру 3-х месяцев, то они уже многое забудут(будут знать лиш то - с чем сталкиваются часто на фирмах где они работают), так как многие просто заучивают некоторую информацию для сдачи экзаменов(это не относится к тем кто постоянно сидит в учебе и пополняет свои знания новыми знаниями - ибо IT-специалист должен всегда учится!!)
0 |
1
15-07-2008 00:27:41
Статья, на самом деле, очень неплохая... Вот только где-то к середине я забыл, что она об атаках, а не о маршрутизациию))) "Маршрутизация для улиток" Вообще - интересно было почитать
0 |
15-07-2008 09:39:28
Иначе не получалось. Можно конечно выдернуть главу про маршрутизацию и большинство моментов с DNS, но тогда слишком много моментов пришлось бы объяснять по ходу объяснения как работает anycast. Не все IT - шники понимают, как работает маршрутизация и DNS, например программерам это не интересно. Те же кто понимает как работает маршрутизация и знает как работает DNS могли эти главы просто пропустить.
0 |
1
15-07-2008 10:15:38
По мне так бойан [|||:] Ничего нового, статья про маршрутизацию. Но для многих будет полезно, особенно для тех, кто считает, что root-серверов по-прежнему 13
0 |
1
15-07-2008 10:22:56
Безграмотность редкостная! Понятно, что автор никогда не работал в ISP и не сталкивался с конфигурацией BGP, анонсированием сетей, ASок и не конфигурил BIND. Но зачем же такую ересь писать!! да еще и с таким апломбом!! Настойчиво рекомендую разобраться в принципах работу DNS и основах маршрутизации IP (хотя бы сходить на базовые курсы по построению сетей Cisco) и затем перечитать свой опус еще раз (тогда, надеюсь, исчезнут вопросы, как строится таблица маршрутизации и что бывает, когда в сети два хоста с одинаковым IP-адресом). P.S. Администрация СекЛаба - вы так точно до уровня МК докатитесь!!
0 |
1
15-07-2008 10:49:33
Уважаемый serg, я не "работал в ISP", но написанное в статье полностью совпадает с моими теоритическими представлениями о DNS и anycast. Если вы заметили неточности и несоответствия, думаю читателям секлаба будет интересно узнать о них по подробней. Опишите посуществу "что не так"! ЗЫ: Не стоит уподобляться форумным тролям и разводить халивары фразами типа ...хотя бы сходить на базовые курсы по построению сетей Cisco...и Администрация СекЛаба - вы так точно до уровня МК докатитесь!!
0 |
1
23-07-2008 23:34:22
Ага. Тщеславные придурки, которые, вместо того чтобы вносить конструктивную критику, по совершенно непонятным (неспециалистам) причинам, начинают гнать на авторов статей - задолбали! Как отпишется такое чудо - и непонятно, то ли прыщавый недоучившийся тинейджер ПТУ-шник с жиру бесится, то ли антисоциальный типа-специалист, который всё типа-умеет, но пару слов связать не может, а слюной брызжет.
0 |
15-07-2008 10:50:15
Забавно. Автор получил CCNA в 2001 году. С 1999 по 2004 работал у ISP, сетевиком, BGP конфигурировал, читал даже книжки по BGP:). Оказывается я и BIND не конфигурировал? Ну, у меня сейчас 3 срваках он как-то живет, никто не жалуется. Можно ли поконкретней что не верно. Аргументируйте батенька
0 |
15-07-2008 10:25:20
В маршрутизации для описания подсетей используются префиксы, но не идентификаторы подсетей и маски. Запись 192.168.0.0/28 описывает подсеть, в префиксе которой последовательно 28 единиц (длина префикса), что эквивалентно записи 192.168.0.0 маска 255.255.255.240. Вообще, тут несколько тонкий вопрос отличия, но маски используются для того, чтобы вычислить относится ли хост к определенной подсети, префиксы служат для описания значимой для маршрутизации информации о местоположении подсетей. Есть еще некоторые не существенные, в данном контексте отличия.Z nfr b y gjyzkВ маршрутизации для описания подсетей используются префиксы, но не идентификаторы подсетей и маски. Запись 192.168.0.0/28 описывает подсеть, в префиксе которой последовательно 28 единиц (длина префикса), что эквивалентно записи 192.168.0.0 маска 255.255.255.240. Вообще, тут несколько тонкий вопрос отличия, но маски используются для того, чтобы вычислить относится ли хост к определенной подсети, префиксы служат для описания значимой для маршрутизации информации о местоположении подсетей. Есть еще некоторые не существенные, в данном контексте отличия. Я так и не понял. 192.168.0.0/28 и 192.168.0.0 - 255.255.255.240 - отличаются?
0 |
15-07-2008 10:52:27
Нет 192.168.0.0/28 и 192.168.0.0 - 255.255.255.240 не отличаются. Но, формально, подсеть может быть такой 192.168.0.0 маска 255.255.255.88 Префикс таким быть не может.
0 |
1
15-07-2008 10:57:13
Это в каких таких случаях маска может быть 88, т.е. рваная (1011000) в последнем октете?
0 |
15-07-2008 11:05:45
В таких в которых пропишите, если, конечно ОС разрешит. XP - не разрешает, FreeBSD разрешает. Фактически такие подсети можно описать на нескольких различных интерфейсах одного и того же хоста, на сам же хост зарулить префикс 192.168.0.0/25 и все работать будет.
0 |
1
15-07-2008 11:43:28
А можно подробнне - какие IP-адреса будут использоваться в сети 192.168.0.0 маска 255.255.255.88, какой адрес бродкаста, какой адрес сети?
0 |
15-07-2008 11:57:42
# ifconfig fxp0 alias 192.168.25.11 netmask 255.255.255.88 # ifconfig fxp0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 options=8<VLAN_MTU> inet 192.168.25.11 netmask 0xffffff58 broadcast 192.168.25.175 ether 00:15:f2:3e:74:86 media: Ethernet autoselect (100baseTX) status: active На самом деле так уже практически никто не делает. Это использовалось раньше. Допустим у вас есть большая подсеть. Вы ее можете раздробить на несколько подсетей, каждую из подсетей пустить на различные физические интерфейсы (часть интерфейсов допустим работает по Ethernet, часть Talking Ring). При этом, вы можете вашу большую подсеть дробить как вам удобно. В данном примере ваша маршрутизируемая сеть с префиксом 25 - то что за префиксом вы можете субнетить как вам удобно, не обязательно, чтобы единицы в маске подсети были последовательны и не чередовались с нулями. Это пошло в RFC когда была впервые включена бесклассовая маршрутизация.
0 |
15-07-2008 12:21:08
Признаюсь несколько удивлен. А вас не затруднит указать номер RFC где написано что в маске сети можно чередовать единицы с нулями?
0 |
15-07-2008 12:24:06
Не вопрос. http://www.faqs.org/rfcs/rfc950.html там кстати, в примере именно 88 в последнем октете На сколько мне известно, этот RFC никто не отменял.
0 |
15-07-2008 12:23:40
и мне интересно как выглядит таблица маршрутизации при указанной вами схеме.
0 |
15-07-2008 12:26:37
Еще раз повторюсь таблица маршрутизации оперирует префиксами, но не масками. На хост кидается целый префикс допустим 192.168.0.0/25 дальше хост не маршрутизирует, а разбрасывает пакеты через нужные интерфейсы в локалку.
0 |
15-07-2008 12:27:52
# route get 192.168.25.11 route to: localhost destination: localhost mask: 255.255.255.88 interface: fxp0 flags: <UP,DONE,CLONING> recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 1500 -423926
0 |
15-07-2008 12:28:34
route to: localhost destination: localhost mask: 255.255.255.88 interface: fxp0 flags: <UP,DONE,CLONING> recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 1500 -423974
0 |
15-07-2008 12:32:37
Запускаем ping при данной конфигурации syslog# ping 192.168.25.12 PING 192.168.25.12 (192.168.25.12): 56 data bytes ping: sendto: Host is down ping: sendto: Host is down И в догонку tcpdump на том же интерфейсе: # tcpdump -ni fxp0 host 192.168.25.12 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on fxp0, link-type EN10MB (Ethernet), capture size 96 bytes 12:31:02.717435 arp who-has 192.168.25.12 tell 192.168.25.11 12:31:03.718176 arp who-has 192.168.25.12 tell 192.168.25.11 12:31:04.719181 arp who-has 192.168.25.12 tell 192.168.25.11 12:31:05.720180 arp who-has 192.168.25.12 tell 192.168.25.11 12:31:06.721174 arp who-has 192.168.25.12 tell 192.168.25.11 12:31:07.722179 arp who-has 192.168.25.12 tell 192.168.25.11
0 |
15-07-2008 13:05:47
Я сейчас поставил зебру, настроил OSPF вот какой конфиг ospfd# sh run Current configuration: ! hostname ospfd password zebra log stdout ! interface fxp0 ! interface xl0 ! interface plip0 ! interface lo0 ! ! line vty ! end и вот какой маршрут (подхваченный от интерфейса) у меня в таблице ospfd# sh ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, B - BGP, > - selected route, * - FIB route ..... ..... C>* 192.168.25.8/29 is directly connected, fxp0 Забавно.
0 |
15-07-2008 14:02:10
ЗабавноНу это уже более объяснимо. Он просто игнорирует всё до последней единицы, считая что там везеде должны стоять единицы.
0 |
15-07-2008 21:32:06
Ну это я тоже понял, забавно то, что по хорошему, зебра должна бы объявить 2 префикса такой 192.168.25.8/29 и такой 192.168.25.168/29 Впрочем, это не камень в огород зебры. Ввиду явной алогичности тех, кто подсетку разбивает не последовательно, маску 255.255.255.88 могут на сегодняшний день использовать только инопланетяне, или те, у которых, страшно сказать, Ктуху уже начал кушать мозг. Кстати, я знаю о такой возможности, именно потому что на этом сайте нашелся один такой чувак под ником ak_ . http://www.securitylab.ru/forum/forum24/topic38948/messages/#message311904 Почитайте приколитесь Тогда то я и прочел внимательно RFC 950. Написанный кстати в 1985 году
0 |
15-07-2008 23:47:18
хм... имхо - человек просто нашел неоднозначность в RFC. полагаю и зебра и большинство реализаций (драйверов) tcp\ip не будут как-то иначе обрабатывать, потому как это скорее всего не реализовано. это получается, что если например маска 255.255.84.0 описывает 8 абсолютно различных подсеток /22. А на многих роутерах я вообще видел, что подсеть только префиксом и описывается.
0 |
1
18-07-2008 01:54:25
Talking Ring -> Token Ring Т.е. не говорящее, а с маркером (токеном).
0 |
1
16-07-2008 14:07:06
Кроме того, не надо забывать, что маска может использоваться не только для выделения подсети, но и просто как маска , например, в access-листах (которые тоже могут иметь отношение к маршрутизации). Там уже можно их с любыми дырами делать, если надо ужать большой список айпишников хостов (хотя та же cisco хранит и обрабатывает их в таком виде, что надо 10 раз подумать, прежде чем "ужимать").
0 |
Страницы: 1  2  3  4