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

30.10.2019 Флешки и HDD

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

Батранков Денис, denisNOSPAMixi.ru

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

Надеюсь, эта статья будет полезна как администраторам, так и тем, кто занимается безопасностью сетей. К сожалению, обычно это разные люди.

Введение. О фильтрации вообще.

Вы только посмотрите на формат заголовка IP пакета (эта структура взята из исходников WinPCap) typedef struct ip_header{ u_char ver_ihl; // Version (4 bits) + Internet header length (4 bits) u_char tos; // Type of service u_short tlen; // Total length u_short identification; // Identification u_short flags_fo; // Flags (3 bits) + Fragment offset (13 bits) u_char ttl; // Time to live u_char proto; // Protocol u_short crc; // Header checksum ip_address saddr; // Source address ip_address daddr; // Destination address u_int op_pad; // Option + Padding }ip_header;

сколько полей требуют проверки на правильность уже на входе в сеть. Очевидно, у каждого поля существует множество значений которое определено в cтандарте RFC как имеющие какой-то смысл. И очевидно, что существует множество значений, которые не определены нигде, являются бессмысленными, и мы даже не можем предположить как эти значения будут восприняты хостом-получателем. Если у пакета хоть одно поле неправильное, то и весь он неправильный и он не должен засорять нашу сеть. Однако в настоящее время во многих сетях это не так. С такими пакетами разбирается на каждом хосте своя система защиты от атак (IPS). Я предлагаю не ждать, когда такие пакеты прибудут на хост получателя, а убивать их уже на входе в сети. Причем фильтровать и блокировать трафик мы можем последовательно начиная от канального и заканчивая уровнем приложений (в рамках модели ISO OSI). Это позволит разгрузить сеть и защитить от атак, которые пользуются тем, что мы "закрываем глаза" на неправильные пакеты.

Эта идея не нова. Намек на то, какие пакеты в вашей сети могут быть неправильными, содержится в правилах систем обнаружения атак. Системы обнаружения атак уже давно проверяют все поля пакетов и собирают статистику для анализа найденных неправильных пакетов, которую можно просмотреть и принять меры к наиболее назойливым. Мне больше всего нравится Snort, поскольку в нем все открыто для расширения возможностей. Это позволяет изменять стандартные правила или писать свои, анализировать статистику при помощи и даже можно добавлять правила на блокирование IP адресов при помощи SnortSam в почти любой из известных на данное время FW: Cisco PIX, MS ISA, Checkpoint FW-1, Watchguard Firebox и встроенные в Linux и FreeBSD FW.

Однако, не ограничивая общности можно сказать, что у тех людей, которые пользуются какими бы то ни было системами обнаружения атак, например Сisco NetRanger, RealSecure(Proventia) или Snort, есть мечта: когда же наконец они прекратят генерировать ложные алерты. У меня, по крайней мере, есть такая мечта, поскольку у меня в четырех внешних сетках класса C постоянно происходит что-то новое, хотя типы информационных потоков уже давно устаканились. Я уже не получаю многие алерты типа BAD-TRAFFIC Unassigned/Reserved IP protocol , BAD TRAFFIC Non-Standard IP protocol , BAD-TRAFFIC loopback traffic , BAD-TRAFFIC same SRC/DST , BAD-TRAFFIC tcp port 0 traffic , не потому что я отключил эти правила, а потому что я заблокировал этот "плохой трафик" сразу же на входе. К сожалению, на сегодняшний день приходится игнорировать различные события, зная, что это обычная ложная тревога и заблокировать я это не могу, поскольку любой провайдер не должен блокировать трафик клиенту каким бы он ни был: опасным или просто бесполезным. Но уж "неправильный" трафик я себе блокировать позволяю: неправильные адреса, неправильные флаги, неправильные или опасные порты.

Понятно почему есть системы IDS, которые показывают администратору какой трафик является плохим, но нет программ, которые бы автоматически фильтровали трафик на входе и выходе ваших сетей так, чтобы Snortу было не на что было ругаться. Проблема в ложных алертах. Есть много правил у того же Snort, которые должны не просто детектировать нестандартное поведение, а сразу же его блокировать. Например логично заблокировать трафик который удовлетворяет условию BAD-TRAFFIC ip reserved bit set , то есть те пакеты у которых неправильно выставлен резервный бит. (Кстати, вспомните ли вы сходу какой firewall сможет проверить такое условие и заблокировать такой пакет? ;-)) С другой стороны есть и алерты о полезности которых можно поспорить. Например, недавно стоящие у меня в сети eMule стали виновниками алертов BACKDOOR typot trojan traffic .

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

Фильтр грубой очистки. Защита от спуфинга IP адресов.

Поскольку я пишу не книгу, а статью, то я сегодня докопаюсь лишь до одного поля IP пакета: source address. Известно, что там находится IP адрес источника пакета. И, насколько мне известно, в технологии Cisco SAFE советуют фильтровать это поле согласно RFC и для защиты от IP спуфинга. Давайте разберемся какие точно адреса мы должны блокировать. (Поле адреса получателя (destination address) должно быть в пределах выделенного вам адресного пула, поэтому тут рассуждать не о чем.)

Итак мы знаем, что начиная с 1 января 1983 года было введено понятие IP адреса 4 версии, который представляет из себя 32 битное число, которое мы обычно записываем в виде 4-х десятичных чисел, разделенных точкой. Существует организация Internet Assigned Numbers Authority (IANA), которая распределяет адреса во всем Интернет. Существуют четыре Regional Internet Registries (RIR) распределенных по миру: APNIC (Asia Pacific Network Information Centre) , ARIN (American Registry for Internet Numbers) , LACNIC (Latin American and Caribbean IP address Regional Registry) , RIPE NCC , которые распределяют адреса между Internet Service Providers (ISP). И наконец существует табличка на сайте IANA , в которой записано какой блок адресов кому отдан.

Если попытаться классифицировать адреса, то кроме (изучаемых уже сейчас в школе) классов А,B,C,D,E мы обнаруживаем что существуют специальные адреса, определяемые не только RFC 1918 , но и RFC 3330 , и которые не должны быть использованы в Интернет.

1. Приватные адреса - зарезервированы под использование в локальных сетях согласно RFC 1918.

  • 10.0.0.0 - 10.255.255.255
  • 172.16.0.0 - 172.31.255.255
  • 192.168.0.0 - 192.168.255.255
2. Адреса получаемые при автоматическом назначении IP адреса самому себе при отсутствии DHCP сервера и согласно RFC 3330 тоже не должны выходить за пределы локальной сети.
  • 169.254.0.0 - 169.254.255.255
3. Loopback адреса используемые для проверки работы TCP стека. Используются каждым хостом только для самого себя.
  • 127.0.0.0 - 127.255.255.255

4. Тестовый диапазон - должен использоваться в документациях и примерах кода.

  • 192.0.2.0–192.0.2.255
5. Multicast адреса не могут стоять в поле источника. Только в поле получателя пакета, поскольку используются для обращения к группе хостов.
  • 224.0.0.0 - 239.255.255.255
6. Зарезервированные и невыделенные никому адреса. Эти адреса перечислены все на той же табличке на сайте IANA . На 12 декабря 2004 года в резерве следующие блоки
  • 0.0.0.0 - 2.255.255.255
  • 5.0.0.0 - 5.255.255.255
  • 7.0.0.0 - 7.255.255.255
  • 23.0.0.0 - 23.255.255.255
  • 27.0.0.0 - 27.255.255.255
  • 31.0.0.0 - 31.255.255.255
  • 36.0.0.0 - 37.255.255.255
  • 39.0.0.0 - 39.255.255.255
  • 41.0.0.0 - 42.255.255.255
  • 49.0.0.0 - 50.255.255.255
  • 73.0.0.0 - 79.255.255.255
  • 89.0.0.0 - 126.255.255.255
  • 173.0.0.0 - 187.255.255.255
  • 189.0.0.0 - 190.255.255.255
  • 197.0.0.0 - 197.255.255.255
  • 223.0.0.0 - 223.255.255.255
  • 240.0.0.0 - 255.255.255.255

Последний список впечатляет. И мы еще жалуемся, что нам не хватает адресов. И это я еще объединил несколько блоков адресов, если они находились рядом в списке.

7. Есть еще один класс адресов, который не может быть в поле sources. Это ваши собственные адреса. Те адреса Интернет, которые выделены вам и только вам провайдером. Очевидно, что никто кроме вас не имеет права пользоваться ими и вы должны блокировать любые попытки прислать пакет с адресом источника из вашего пула адресов. Тем более, что подстановка вашего адреса в поле sources может использоваться для реализации различных атак. Например, в атаке Land, посылается SYN-пакет с адресом отправителя, совпадающим с адресом получателя.

Итак, оказалось что существует достаточно большое множество адресов, которых не может быть в поле sources наших IP пакетов. Как правило, если в sources прописан один из перечисленных выше адресов, то это либо неправильно работающая у вышестоящего провайдера маршрутизация (выпускающая наружу неправильные адреса), либо возможная DOS атака. Именно поэтому я предлагаю заблокировать все перечисленные выше адреса на входе вашего маршрутизатора.

Суммируя вышесказанное, мы получаем достаточно приличный список адресов отправителя, который мы должны блокировать. Например, если вы используете маршрутизатор Cisco то access-list будет выглядеть следующим образом:

ip access-list extended complete_bogon

Используем именованный расширенный список доступа

deny ip 0.0.0.0 1.255.255.255 any

IANA Reserved

deny ip 2.0.0.0 0.255.255.255 any

IANA Reserved

deny ip 5.0.0.0 0.255.255.255 any

IANA Reserved

deny ip 7.0.0.0 0.255.255.255 any

IANA Reserved

deny ip 10.0.0.0 0.255.255.255 any

RFC 1918

deny ip 23.0.0.0 0.255.255.255 any

IANA Reserved

deny ip 27.0.0.0 0.255.255.255 any

IANA Reserved

deny ip 31.0.0.0 0.255.255.255 any

IANA Reserved

deny ip 36.0.0.0 1.255.255.255 any

IANA Reserved

deny ip 39.0.0.0 0.255.255.255 any

IANA Reserved

deny ip 41.0.0.0 0.255.255.255 any

IANA Reserved

deny ip 42.0.0.0 0.255.255.255 any

IANA Reserved

deny ip 49.0.0.0 0.255.255.255 any

IANA Reserved

deny ip 50.0.0.0 0.255.255.255 any

IANA Reserved

deny ip 73.0.0.0 0.255.255.255 any

IANA Reserved

deny ip 74.0.0.0 1.255.255.255 any

IANA Reserved

deny ip 76.0.0.0 3.255.255.255 any

IANA Reserved

deny ip 82.0.0.0 1.255.255.255 any

IANA Reserved

permit 88.0.0.0 0.255.255.255 our_net

разрешим доступ с адресом 88/8 в нашу сеть (чтобы не заблокировать ниже)

deny ip 88.0.0.0 7.255.255.255 any

IANA Reserved

deny ip 96.0.0.0 31.255.255.255 any

IANA Reserved и Loopback

deny ip 169.254.0.0 0.0.255.255 any

автоназначенные адреса

deny ip 172.16.0.0 0.15.255.255 any

RFC 1918

deny ip 173.0.0.0 0.255.255.255 any

IANA Reserved

deny ip 174.0.0.0 1.255.255.255 any

IANA Reserved

deny ip 176.0.0.0 7.255.255.255 any

IANA Reserved

deny ip 184.0.0.0 3.255.255.255 any

IANA Reserved

deny ip 189.0.0.0 0.255.255.255 any

IANA Reserved

deny ip 190.0.0.0 0.255.255.255 any

IANA Reserved

deny ip 192.0.2.0 0.0.0.255 any

Адреса для тестов.

deny ip 192.168.0.0 0.0.255.255 any

RFC 1918

deny ip 197.0.0.0 0.255.255.255 any

IANA Reserved

deny ip 198.18.0.0 0.1.255.255 any

IANA Reserved

deny ip 201.0.0.0 0.255.255.255 any

IANA Reserved

deny ip 222.0.0.0 1.255.255.255 any

IANA Reserved

deny ip 223.0.0.0 0.255.255.255 any

IANA Reserved

deny ip 224.0.0.0 31.255.255.255 any

Multicast и затем IANA Reserved

deny ip our_net any

блокируем наши адреса на входе

permit ip any our_net

разрешаем все остальное

our_net я обозначил ваш блок адресов. Например, он может выглядеть как 194.194.194.0 0.0.0.255 согласно правил написания access-listов.

Неважно где будет реализован этот метод фильтрации на вашем пограничном маршрутизаторе, межсетевом экране или даже на сервере, но самое главное что атакующий лишается возможности использовать адреса из несуществующих сетей. Хочу заметить, что если вы пользуетесь Cisco IOS последних версий (12.2 и выше), то вам не нужно этот access-list делать самому. Такой же access-list формируется простой (казалось бы) командой auto secure .

Команда auto secure делает ВСЁ за специалиста по компьютерной безопасности! Все что наработано на сегодняшний день по защите маршрутизаторов Cisco делается этой одной командой. Вы, конечно, должны представлять что она делает, когда вводите ее, но эта команда сделает все, даже если у вас нет никаких сертификатов и образования в этой области. :(Я вообще когда узнал про возможности auto secure решил, что вот и пришла пора бросать заниматься безопасностью и пойти утюги продавать - там и зарплата, говорят, больше и высшее образование не нужно. ;-) Зачем теперь специалисты, если все делается одной командой.

Однако у этого метода есть минус: вам нужно постоянно отслеживать изменения в таблице на сайте IANA http://www.iana.org/assignments/ipv4-address-space , чтобы после изменения этого списка вы изменили свой access-list. Например, последнее изменение было в августе этого года: выделены сети 71/8, 72/8 для ARIN. Я не знаю есть ли готовый скрипт для выполнения этой работы, но если вы найдете такой или напишете сами, то общество будет Вам благодарно. Есть одна страничка, где всегда хранится актуальный access-list http://www.cymru.com/Documents/secure-ios-template.html , но там список доступа слегка длинноват. Его можно сократить. Принцип сокращения такой

deny ip 0.0.0.0 0.255.255.255 any
deny ip 1.0.0.0 0.255.255.255 any

меняем на

deny ip 0.0.0.0 1.255.255.255 any

В случае если на входе в сеть нет такого фильтра, то возможно вам хочется настроить фильтр на своем собственном сервере или рабочей станции. Кстати авторы персональных FW могли бы взять это на вооружение. Это поможет защитить хост от DOS атак. Вот, например, пример атиспуфингового фильтра для BIND .

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

Фильтр тонкой очистки или Isolated VLAN.

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

Давайте рассмотрим на примере Демилитаризованной зоны (DMZ). Считается правильным выделять сервера компании в отдельную сеть, защищенную как от пользователей из Интернет, так и от внутренних пользователей. Как говорят, доверяй, но проверяй. На картинке показаны два возможных варианта реализации: DMZ располагается между двумя Firewall и DMZ висит на одном из портов Firewall.

Итак, межсетевые экраны фильтруют трафик, приходящий из Интернет и из локальной сети. И, как правило, дизайнеры сети успокаиваются на этой схеме. Все сервера подключаются через один свитч и оказываются в одном широковещательном домене. Однако нужно ли взаимодействие между серверами в DMZ друг с другом? Нужно смотреть в каждом конкретном случае. Можно предположить, что если будет взломан один из серверов DMZ, то с этого сервера возможна атака на соседний сервер, тем более что мы на этапе проектирования никак не защитили один сервер от другого. Таким образом, в тех случаях, когда серверы не должны функционировать друг с другом рекомендуется делать несколько отдельных DMZ. Однако лучшим вариантом является использование PVLAN. Если порты, к которым подключены серверы не будут пересылать пакеты друг другу на канальном уровне, то не будет никакого трафика между серверами и единственный способ для них связаться друг с другом - пройти через Firewall, на котором это соединение должно быть разрешено и передано на нужный порт. Такие порты которые не передают трафик друг другу на канальном уровне называются изолированными.

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

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

У Сisco PVLAN реализован так, что трафик, который приходит на promiscuous порт может быть распределен по любым другим портам типа isolated и community. Трафик, который приходит на isolated порт может быть направлен только на promiscuous порт. Трафик, который приходит на community порт может быть направлен на promiscuous порт и на порты принадлежащие этой же community.

Таким образом, даже находясь в одном VLAN хосты у которых в схеме информационных потоков не должно быть взаимного трафика не будут получать ни единого пакета друг от друга. Единственная возможность обменяться информацией – прописать явно правило на межсетевом экране или маршрутизаторе разрешающее передавать пакеты между ними. Но это правило уже работает на третьем уровне модели OSI и в этом случае можно применять access-list и правила межсетевого экрана для явного указания разрешенных портов и протоколов.

Если копнуть более глубоко, то когда хост 1 посылает ARP запрос (в поиске MAC адреса хоста 2 с нужным ему IP из той же подсети) хост 2 не получает это запрос и не отвечает хосту 1, поскольку оба сидят на изолированных друг от друга портах. Мы добились того, что хост 1 считает, что хост 2 недоступен и наоборот. Таким образом решается задача контроля трафика внутри сети и, самое главное, не нужно разбивать сеть на подсети. Мы можем безболезненно наложить технологию PVLAN на уже имеющиеся сети.

Когда же нам становится нужно, чтобы сервера общались друг с другом, то маршрутизатор (или firewall) может ответить, что этот хост доступен через него. Эта техника называется Proxy ARP . Хост 1 думает, что хост 2 находится в другом сегменте и посылает IP пакет через маршрутизатор (или firewall). То есть получается, что в пакете стоит MAC адрес маршрутизатора, и IP адрес хоста 2. А вот маршрутизатор (или firewall) уже решает передавать пакет хосту 2 или нет.

Надо заметить, что есть и уязвимость этого метода: если у вас используется маршрутизатор который не имеет никаких правил доступа и, не задумываясь, маршрутизирует все пакеты, что к нему приходят, то злоумышленник с хоста 1 может специально послать пакет с МАС адресом маршрутизатора, но с IP адресом хоста 2. Такой пакет пройдет через isolated port к маршрутизатору и затем будет послан маршрутизатором на хост 2. Поэтому, надо либо добавить правила доступа на маршрутизаторе (или firewall) запрещающие или разрешающие такие пакеты явно, либо пользоваться дополнительно VLAN Access Control List (VACL) на свитче.

Раньше в рамках одного свитча была похожая возможность которая называлась protected port, но она работала только в пределах одного свитча и информация о protected портах не передавалась по транкам. Сейчас это понятие расширено и дополнено community портами.

Технология PVLAN может быть практически реализована на достаточно большом количестве выпускаемых в настоящее время управляемых коммутаторов имеющих порты Ethernet со скоростью работы 10/100/1000 мегабит в секунду.

Конкретная реализация этих схем на свитчах Cisco описана .

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

Системы веб-фильтрации могут быть выполнены в различных вариациях:

  • утилиты;
  • приложения;
  • дополнения для браузера;
  • дополнение для интернет-шлюзов;
  • облачные сервисы.

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

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

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

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

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

При выборе средства веб-фильтрации стоит обратить внимание на полноту классификатора, скорость классификации новых сайтов, а также процент ложных срабатываний.

К 2020 году в России появится Национальная система фильтрации интернет-трафика (НаСФИТ). Она должна будет защитить детей от негативного и опасного контента. Как рассказал «Известиям» глава Лиги безопасного интернета (ЛБИ) Денис Давыдов, несовершеннолетние пользователи сети смогут посещать только доверенные сайты из «белого списка».

Создание Национальной системы фильтрации интернет-трафика при использовании информационных ресурсов детьми предусмотрено госпрограммой «Цифровая экономика», которую 31 июля утвердил премьер-министр России Дмитрий Медведев. Согласно тексту документа, до конца I квартала 2019 года должна быть разработана архитектура и прототип НаСФИТ, определены необходимые ресурсы. До конца I квартала 2020 года система должна быть введена в эксплуатацию.

Основными лоббистами такой системы на протяжении пяти лет выступают Лига безопасного интернета и сенатор Елена Мизулина. Они участвовали в разработке закона «О защите детей от информации, причиняющей вред их здоровью и развитию» (известен как закон «О черных списках»). В 2012 году в Рунете появился единый реестр запрещенной информации, его ведением занимается Роскомнадзор.

Как рассказал «Известиям» Денис Давыдов, сейчас обсуждаются два варианта реализации национальной системы фильтрации. Первый - фильтрация трафика только в образовательных учреждениях. Второй - фильтрация по умолчанию для всех пользователей Рунета. Граждане смогут посещать сайты из «белого списка», а чтобы получить доступ к нефильтрованному контенту, нужно будет написать заявление интернет-провайдеру или снять соответствующую «галочку» в личном кабинете.

У Лиги безопасного интернета есть собственный «белый список» сайтов, в котором более 1 млн ресурсов. Есть у ЛБИ и две системы фильтрации. Первая - надстройка для браузера, показывающая только доверенные сайты из «белого списка». Вторая - программно-аппаратный комплекс, который устанавливается у оператора связи. ЛБИ уже протестировала эту систему в нескольких регионах России, в частности в Костроме.

По словам Дениса Давыдова, «белые списки» не будут эффективны, если организаторы распространения информации не будут самостоятельно выявлять и блокировать запрещенный в России контент. Поэтому лига ждет повторного внесения законопроекта депутатов Сергея Боярского и Андрея Альшевских. Внесенный ими ранее в Госдуму проект был затем отозван. Он устанавливал ответственность администрации соцсетей за отказ удалить противоправный и недостоверный контент. Как пояснил Денис Давыдов, без такой ответственности взрослые пользователи Рунета смогут выключить фильтрацию и дети не будут ограждены от опасного контента

Глава компании «Ашманов и партнеры» Игорь Ашманов рассказал, что принимал участие в работе подгруппы, разрабатывавшей в программе «Цифровая экономика» раздел по информационной безопасности. По его словам, в документе, ушедшем в правительство из Минкомсвязи, не было речи о НаСФИТ.

По всей видимости, этот пункт был добавлен после, - сказал Игорь Ашманов. - Что касается идеи «белых списков», то она нежизнеспособна.

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

Генеральный директор «ТМТ Консалтинг» Константин Анкилов тоже считает, что инициатива внедрения «белых списков» для всех пользователей неправильна.

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

Официальный представитель «МегаФона» Юлия Дорохина считает правильным ограничение доступа детей к нежелательному контенту.

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

Направлена на несовершеннолетних интернет-пользователей, которые, в случае ее внедрения, смогут посещать только доверенные сайты из «белого списка». Таким образом они будут лишены доступа к «опасному» контенту.

Пока не решено, будет ли трафик фильтроваться только в образовательных учреждениях страны или же для всех пользователей Рунета. Во втором случае, чтобы получить доступ в «свободный интернет», нужно будет написать заявление интернет-провайдеру. Лига безопасного интернета уже тестирует систему «белого списка» в ряде регионов России, в частности, в Костроме.

Чьих рук дело?

Создание этой системы предусматривается , которую 31 июля утвердил премьер-министр России Дмитрий Медведев. НаСФИТ должна быть введена в эксплуатацию до конца 2020 года. Почву для появления системы подготовила, в том числе, сенатор , благодаря которой с 2012 года в Рунете ведется единый реестр запрещенной информации Роскомнадзора.

Почему НаСФИТ может нанести вред?

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

Помимо пользователей НаСФИТ может нанести урон всей телеком- и ИТ-отрасли. Провайдерам и операторам придется тратить огромные ресурсы «на реализацию малоэффективных решений по фильтрации трафика вместо того, чтобы инвестировать в цифровую экономику и строительство cетей 5G», cетует пресс-секретарь МТС.

Идея может не сработать

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

Представитель интернет-провайдера АКАДО Телеком сообщил, что компания поддерживает инициативу, но также сомневается в механизме ее воплощения в жизнь.

«Неясно, по какому принципу сайты будут попадать в "белый список", кто это должен определять. Если речь идет о фильтрации контента только в образовательных учреждениях, то такая мера вряд ли будет действенна, так как при желании дети смогут зайти на сайты из дома. Поэтому проект нуждается в серьезной доработке». Ирина Романникова, пресс-служба АКАДО Телеком.

Как можно фильтровать?

По мнению гендиректора информационно-аналитического агентства TelecomDaily Дениса Кускова, есть два разумных способа фильтрации «вредных» сайтов: собственные инструменты оператора и покупка SIM-карты с оговоркой, что она будет использоваться ребенком. В этом случае оператор сможет включить фильтрацию сразу.

У некоторых операторов уже есть собственные системы для фильтрации трафика. Так, «Ростелеком» предлагает продукт «Контент-фильтрация трафика» для образовательных учреждений, а «ВымпелКом» - рекомендательный сервис интернет-ресурсов «Вебландия», сайты для которого отбирают детские библиотекари.

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

распределения сеансов по портам. Случайный набор МAC-адресов в сети может привести к тому, что через один порт будут проходить несколько десятков сеансов, а через другой - только два-три. Выравнивания нагрузки портов в данном алгоритме можно достигнуть только при большом количестве компьютеров и сеансов связи между ними.

Можно предложить и другие способы распределения сеансов по портам. Например, в со­ ответствии с ІР-адресами пакетов, которые инкапсулированы в кадры канального уровня, типами прикладных протоколов (почта по одному порту, веб-трафик по другому и т. д.). Полезным оказывается назначение порту сеансов с МAC-адресами, которые были изучены как идущие именно через этот порт -тогда трафик сеанса пойдет через один и тот же порт в обоих направлениях.

Стандартный способ создания агрегированных каналов, описанный в спецификации 802.3ad, предполагает возможность создания логического порта путем объединения не­ скольких физических портов, принадлежащих разным коммутаторам. Для того чтобы коммутаторы могли автоматически обеспечиваться информацией о принадлежности какого-либо физического порта определенному логическому порту, в спецификации предложен служебный протокол управления агрегированием линий связи (Link Control Aggregation Protocol, LCAP). Поэтому возможны такие конфигурации агрегированных ка­ налов, которые увеличивают отказоустойчивость сети не только на участках между двумя коммутаторами, но и в более сложных топологиях (рис. 14.8).

Агрегированный канал

Рис. 14.8. Распределенное агрегирование каналов

При отказе какого-либо канала транка все пакеты сеансов, назначенные для соответствую­ щего порта, будут направляться на один из оставшихся портов. Обычно восстановление связности при таком отказе занимает от единиц до десятков миллисекунд. Это объясняется тем, что во многих реализациях транка после отказа физического канала все МАС-адреса, которые были с ним связаны, принудительно помечаются как неизученные. Затем ком­ мутатор повторяет процедуру изучения этих адресов. После этого процедура назначения сеанса портам выполняется заново, естественно, учитываются только работающие порты. Так как тайм-ауты в сеансах протоколов локальных сетей обычно небольшие, коротким оказывается и время восстановления соединения.

Фильтрация трафика

Локальная сеть обеспечивает взаимодействие каждого узла с каждым -это очень полезное свойство, так как не требуется производить никаких специальных действий, чтобы обе­

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

Многиемодели коммутаторов позволяют администраторам задавать дополнительные усло­ вияфильтрации кадров наряду со стандартными условиями их фильтрации в соответствии с информацией адресной таблицы. Такие фильтры называют пользовательскими.

Пользовательский фильтр, который также часто вазываютслискомдоступа {access list), предназначендлясозданиядополнительныхбарьеровнаггут кадров, чтопозволяетограничи­ вать доступ определенных групп полЁзовапгелейк Пользовательский

фильтр - это набор условий, которые ограничмваотобычную/югиет передачи кадров комму­ таторами.

Наиболее простыми являются пользовательские фильтры на основе МAC-адресов станций. Так как МАС-адреса -это та информация, с которой работает коммутатор, он позволяет создавать подобные фильтры удобным для администратора способом, возможно, про­ ставляя некоторые условия в дополнительном поле адресной таблицы, например условие отбрасывать кадры с определенным адресом (см. рис. 13.6 в главе 13). Таким способом пользователю, работающему на компьютере с данным МАС-адресом, полностью запре­ щается доступ к ресурсам другого сегмента сети.

Рассмотрим применение пользовательского фильтра на примере сети, показанной на рис. 14.9.

Рис. 14.9. Контрольдоступа к серверу с помощью пользовательского фильтра

Пусть мы хотим разрешить доступ к серверу 51 только с компьютеров С 1 иС 3, кадры от всех остальных компьютеров до этого сервера доходить не должны. Список доступа, ко­ торый решает эту задачу, может выглядеть так:

М А С - С 1 M A C - S 1

М А С - С З MAC - S I

d e n y a n y a n y

Числа 10,20 и ЗО -это номера строк данного списка. Строки нумеруются с интервалом 10 для того, чтобы в дальнейшем была возможность добавить в этот список другие записи, сохраняя исходную последовательность строк. Первое условие разрешает (permit) пере­ дачу кадра, если его адрес источника равен МАС-С1, а адрес назначения -МАС-SI; второе условие делает то же, но для кадра с адресом источника МАС-СЗ, третье условие запрещает (deny) передачу кадров с любыми (any) адресами.

Для того чтобы список доступа начал работать, его нужно применить к трафику опреде­ ленного направления на какому-либо порту коммутатора: либо к входящему, либо к ис­ ходящему. В нашем примере нужно применить список доступа к исходящему трафику порта 1 коммутатора SW3, к которому подключен сервер 51. Коммутатор SW3, перед тем как предать кадр на порт 1, будет просматривать условия списка доступа по очереди. Если какое-то условие из списка соблюдается, то коммутатор выполняет действие этого условия для обрабатываемого кадра, и на этом применение списка доступа для данного кадра заканчивается.

Поэтому когда от компьютера С 1 приходит кадр, адресованный серверу 51, то соблюдается первое условие списка, которое разрешает передачу кадра, так что коммутатор выполняет стандартное действие по продвижению кадра, и тот доходит до сервера 52. С кадром от компьютера СЗ совпадение происходит при проверке второго условия, и он также переда­ ется. Однако когда приходят кадры от других компьютеров, например компьютера С2, то ни первое, ни второе условия не соблюдаются, зато соблюдается третье условие, поэтому кадр не передается, а отбрасывается.

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

Иногда администратору требуется задать более тонкие условия фильтрации, например запретить некоторому пользователю печатать свои документы на сервере печати Windows, находящемуся в чужом сегменте, а остальные ресурсы этого сегмента сделать доступными. Для реализации подобного фильтра нужно запретить передачу кадров, которые удовлет­ воряют следующим условиям: во-первых, имеют определенный МАС-адрес, во-вторых, содержат в поле данных пакеты SMB, в-третьих, в соответствующем поле этих пакетов в качестве типа сервиса указана печать. Коммутаторы не анализируют протоколы верх­ них уровней, такие как SMB, поэтому администратору приходится для задания условий фильтрации «вручную» определять поле, по значению которого нужно осуществлять фильтрацию. В качестве признака фильтрации администратор указывает пару «смещениеразмер» относительно начала поля данных кадра канального уровня, а затем еще приводит шестнадцатеричное значение этого поля.

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

Виртуальные локальные сети

Важным свойством коммутатора локальной сети является способность контролировать передачу кадров между сегментами сети. По различным причинам (соблюдение прав до­ ступа, политика безопасности и т. д.) некоторые кадры не следует передавать по адресу назначения.

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

Виртуально^ сетью группаузлов сети,

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

Виртуальные локальные сети могут перекрыватьсяу если один или несколько компьютеров входят в состав более чем одной виртуальной сети. На рис. 14.10 сервер электронной почты входит в состав виртуальных сетей 3 и 4. Это означает, что его кадры передаются комму­ таторами всем компьютерам, входящим в эти сети. Если же какой-то компьютер входит в состав только виртуальной сети 3, то его кадры до сети 4 доходить не будут, но он может взаимодействовать с компьютерами сети 4 через общий почтовый сервер. Такая схема защищает виртуальные сети друг от друга не полностью, например, широковещательный шторм, возникший на сервере электронной почты, затопит и сеть 3, и сеть 4.

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

Назначение виртуальных сетей

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

Приходится задавать отдельные условия для каждого узла сети , используя при этом громоздкие МАС-адреса. Гораздо проще было бы группировать узлы и описывать усло­ вия взаимодействия сразу для групп.

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

Техника виртуальных локальных сетей решает задачу ограничения взаимодействия узлов сети другим способом.

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

ІО^оіоиногаомзр^снолсншвирту&1ьнЫ*сэт^ запнетсято,чтоонапозволяетсоаддватьпсшностыо изолированныеоегментысетияутемлогическогоконфигурированиякоммутаторов,реприбегая

кизмененик>физиче<жойо^у<1>1>ы.

До появления технологии VLAN для создания отдельной сети использовались либо фи­ зически изолированные сегменты коаксиального кабеля, либо не связанные между собой сегменты, построенные на повторителях и мостах. Затем эти сети связывались маршрути­ заторами в единую составную сеть (рис. 14.11).

Изменение состава сегментов (переход пользователя в другую сеть, дробление крупных сегментов) при таком подходе подразумевает физическую перекоммутацию разъемов на

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

ц иг О

5 E J L JЗ

Сегменты на повторителях

Рис. 14.11. Составная сеть, состоящая из сетей, построенных на основе повторителей

Длясвязывания виртуальных сетей в общую сеть требуется привлечение средств сетевого уровня. Он может быть реализован в отдельном маршрутизаторе или в составе программ­ ного обеспечения коммутатора, который тогда становится комбинированным устрой­ ством - так называемым коммутатором 3-го уровня (см. главу 18).

Технология виртуальных сетей долгое время не стандартизировалась, хотя и была реали­ зованав очень широком спектре моделей коммутаторов разных производителей. Положе­ ниеизменилось после принятия в 1998 году стандарта IEEE 802.1Q, который определяет базовые правила построения виртуальных локальных сетей, не зависящие от протокола канального уровня, поддерживаемого коммутатором.

Создание виртуальных сетей на базе одного коммутатора

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

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

Второй способ образования виртуальных сетей основан на группировании МАС-адресов. Каждый МАС-адрес, который изучен коммутатором, приписывается той или иной вир­ туальной сети. При существовании в сети множества узлов этот способ требует от адми­ нистратора большого объема ручной работы. Однако при построении виртуальных сетей

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

Рис. 14.12. Виртуальные сети, построенные на одном коммутаторе

Создание виртуальных сетей на базе нескольких коммутаторов

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

s ,:w.

Рис. 14.13. Построение виртуальных сетей на нескольких коммутаторах с группированием портов

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

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

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

Описанные два подхода основаны только на добавлении дополнительной информации к адресным таблицам коммутатора и в них отсутствует возможность встраивания в пере­ даваемый кадр информации о принадлежности кадра виртуальной сети. В остальных подходах используются имеющиеся или дополнительные поля кадра для сохранения информации о принадлежности кадра той или иной виртуальной локальной сети при его перемещениях между коммутаторами сети. При этом"нет необходимости помнить в каждом коммутаторе о принадлежности всех МАС-адресов составной сети виртуальным сетям.

Дополнительное поле с пометкой о номере виртуальной сети используется только тогда, когдакадр передается от коммутатора к коммутатору, а при передаче кадра конечному узлу оно обычно удаляется. При этом модифицируется протокол взаимодействия «коммутаторкоммутатор», а программное и аппаратное обеспечение конечных узлов остается неизмен­ ным. До принятия стандарта IEEE 802.1Q существовало много фирменных протоколов этоготипа, но все они имели один недостаток -оборудование различных производителей при образовании VLAN оказывалось несовместимым.

Этот стандарт вводит в кадре Ethernet дополнительный заголовок, который называется тегом виртуальной локальной сети.

^rrnatlon}- упрадляюадя шшщ** котороеявляется

6 байт 2 байта 2 байта

2 байта

42-1496 байт

">Тур9;.-а ‘іЗ Ь к:

Ъ.’<-V"

Приоритет;

*Фйс. 14.14. Структура помеченного кадра Ethernet

TerVLANне является обязательным для кадров Ethernet. Кадр, у которого имеется такой заголовок, называют помеченным (tagged frame). Коммутаторы могут одновременно ра­ ботатькак с помеченными, так и с непомеченными кадрами. Из-за добавления тега VLAN максимальная длина поля данных уменьшилась на 4 байта.

Для того чтобы оборудование локальных сетей могло отличать и понимать помеченные кадры, для них введено специальное значение поля EtherType, равное 0x8100. Это значе­ ние говорит о том, что за ним следует поле TCI; а не стандартное поле данных. Обратите внимание, что в помеченном кадре за полями тега VLAN следует другое поле EtherType, указывающее тип протокола, данные которого переносятся полем данных кадра.

В поле TCI находится 12-битное поле номера (идентификатора) VLAN, называемогоVID. Разрядность поля VID позволяет коммутаторам создавать до 4096 виртуальных сетей. Помимо этого в поле TCI помещено 3-битное полеприоритета кадра. Однобитное полеCFI было введено с целью поддержания специального формата кадра Token Ring, для сетей Ethernet оно должно содержать значение 0.

Пользуясь значением VID в помеченных кадрах, коммутаторы сети выполняют групповую фильтрацию трафика, разбивая сеть на виртуальные сегменты, то есть на VLAN. Для под­ держки этого режима каждый порт коммутатора приписывается к одной или нескольким виртуальным локальным сетям, то есть выполняется группировка портов.

Для упрощения конфигурирования сети в стандарте 802.1Q вводятся понятия линии до­ ступа и транка.

^бммутатора (называемый в этом случае портом доступа) Йекйторойвиртуальной локальной сети.

щ соединяет ме*дусобой портыдаух коммутаторов; в общем!

#$фик несколькихвиртуальныхсетей. V ,j

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

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

Порты доступа получают от конечных узлов сети непомеченные кадры и помечают их тегом VLAN, содержащим то значение VID, которое назначено этому порту. При передаче же помеченных кадров конечному узлу порт доступа удаляет тег виртуальной локальной сети.

Для более наглядное описания вернемся к рассмотренному ранее примеру сети. На рис. 14.15 показано, как решается задана избирательного доступа к серверам на основе техники VLAN.

VLAN-2

VLAN-3

Рис. 14.15. Разбиение сети на две виртуальные локальные сети

Чтобы решить эту задачу, можно организовать в сети две виртуальные локальные сети, VLAN2 и VLAN3 (напомним, что сеть VLAN1 уже существует по умолчанию -это наша исходная сеть), приписав один набор компьютеров и серверов к VLAN2, а другой - KVLAN3.

Для приписывания конечных узлов к определенной виртуальной локальной сети соот­ ветствующие порты объявляются портами доступа этой сети путем назначения им соот­ ветствующего идентификатора VID. Например, порт 1 коммутатора SW1 должен быть объявлен портом доступа VLAN2 путем назначения ему идентификатора VID2, то же самоедолжно быть проделано с портом 5 коммутатора SW1, портом 1 коммутатора SW2 и портом 1 коммутатора SW3. Порты доступа сети VLAN3 должны получить идентифи­ каторVID3.

В нашей сети нужно также организовать транки -те линии связи, которые соединяют между собой порты, коммутаторов. Порты, подключенные к транкам, не добавляют и не удаляют теги, они просто передают кадры в неизменном виде. В нашем примере такими портамидолжны быть порты 6 коммутаторов SW1 и SW2, а также порты 3 и 4 коммутатора SW3. Порты в нашем примере должны поддерживать сети VLAN2 и VLAN3 (и VLAN1, если всети есть узлы, явно не приписанные ни к одной виртуальной локальной сети).

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

Как мы видим из примера, техника VLAN оказывается весьма эффективной для разгра­ ничения доступа к серверам. Конфигурирование виртуальной локальной сети не требует знания МАС-адресов узлов, кроме того, любое изменение в сети, например Подключение компьютера к другому коммутатору, требует конфигурирования лишь порта данного ком­ мутатора, а все остальные коммутаторы сети продолжают работать без внесения изменений в их конфигурации.

Альтернативные маршруты в виртуальных локальных сетях

По умолчанию протокол STP/RSTP образует в сети одно покрывающее дерево для всех виртуальных локальных сетей. Чтобы в сети можно было использовать разные покрываю­ щие деревья для разных виртуальных локальных сетей, существует специальная версия протокола, называемая множественным протоколом покрывающего дерева (Multiple Spanning Tree Protocol, MSTP).

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

тивном случае, как мы видели в примере на рис. 14.2 и 14.3, единственное покрывающее дерево может полностью оставить без работы некоторые коммутаторы сети, то есть недо­ использует имеющие сетевые ресурсы.

Если вернуться к нашему примеру (см. рис. 14.2), то при создании двух покрывающих деревьев можно сконфигурировать приоритеты коммутаторов так, чтобы для одного дерева корневым коммутатором стал коммутатор 111, а для второго -коммутатор 222 (рис. 14.16).

В этом варианте мы подразумеваем, что порты 4 коммутаторов с 555 по 888 сконфигу­ рированы как порты доступа одной виртуальной локальной сети, например VLAN100,

а порты 3 тех же коммутаторов -как порты доступ»другой виртуальной локальной сети, например VLAN200. Сеть VLAN100 приписана к покрывающему дереву с корневым коммутатором 111, a VLAN200 -к покрывающему дереву с корневым коммутатором 222.

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

Протокол MSTP основан на протоколе RSTP, поэтому обеспечивает быструю реакцию сетина отказы.

Качество обслуживания в виртуальных сетях

Коммутаторы локальных сетей поддерживают практически все механизмы QoS, которые мы обсуждали в главе 7. Это утверждение относится к коммутаторам локальных сетей как к классу коммуникационных устройств, каждая же конкретная модель коммутатора можетбыть наделена только определенным набором механизмов поддержания параметров QoS или же не иметь их вовсе. Как правило, коммутаторы рабочих групп средств QoS не поддерживают, в то время как дл^ магистральных коммутаторов эта поддержка является обязательной.

Классификация трафика

Коммутаторы локальных сетей являются устройствами второго уровня, которые анализи­ руютзаголовки только протоколов канального уровня. Поэтому коммутаторы обычно ис­ пользуютдля классификации трафика только МАС-адреса источника и приемника, а также номер порта, через который поступил кадр. Возможен также учет при классификации значения произвольного подполя внутри поля данных, заданного путем указания смеще­ ния в байтах. Эти способы не очень удобны для администратора, которому необходимо, например, отделить голосовой трафик от трафика передачи файлов. Поэтому некоторые коммутаторы, не поддерживая протоколы верхних уровней в полном объеме (например, не применяя протокол IP для продвижения пакетов), выполняют классификацию на основе признаков, содержащихся в заголовках пакетов этих протоколов -ІР-адресах и портах TCP/UDP

Маркирование трафика

Маркирование трафика обычно выполняется на границе сети, а затем его результаты ис­ пользуются во всех промежуточных устройствах сети. В кадре Ethernet 802.3 отсутствует поле, в которое можно было бы поместить результат маркировки трафика. Однако этот недостаток исправляет спецификация 802.1р, в которой имеются три бита дополнительного заголовка 802.1Q/p для хранения приоритета кадра.

Фактически, эти три бита служат для хранения признака одного из восьми классов тра­ фика. Именно так трактует это поле стандарт 802.1 D-2004, куда вошла спецификация 802.1р. В приложении G стандарта 802.1D-2004 даются рекомендации по разделению всего трафика локальных сетей на семь классов:

□ NC (управление сетью). Управлению сетью дается высший приоритет при обслужива­ нии, так как от своевременного принятия решения и доставки управляющей информа­ ции сетевым устройствам зависят любые характеристики сети.

□ VI (видео). Видеотрафику требуется обеспечить задержу менее 100 мс.

□ CL (контролируемая нагрузка). При применении важных бизнес-приложений требуется некоторая форма контроля допуска (admission control) и резервирование пропускной способности для потока.

□ ЕЕ (улучшенное обслуживание). Это улучшенный вариант обслуживания по возмож­ ности, не дающий никаких гарантий пропускной способности.

□ BE (обслуживание по возможности, или с максимальными усилиями). Стандартное обслуживание в локальных сетях.

□ ВК (фоновый трафик). Наименее чувствительный к задержкам трафик, например тра­ фик резервного копирования, источник которого может передавать большие объемы данных, поэтому его целесообразно выделить в особый класс, чтобы он не замедлял обработку других типов трафика.

Управление очередями

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

Коммутатор обычно поддерживает некоторое максимальное количество очередей, которое может оказаться меньше, чем требуемое число классов трафика. В этой ситуации несколько классов будут обслуживаться одной очередью, то есть фактически сольются в один класс. Стандарт 802.1D-2004 дает рекомендации в отношении того, какие классы трафика нуж­ но реализовывать в сети в условиях ограниченного количества очередей в коммутаторах (табл. 16.1).

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

Две очереди дают возможность дифференцированно обслуживать группы классов трафи­ ка -менее требовательные классы ВК, BE и ЕЕ в одной очереди, а более требовательные классы VO, CL, VI, NC -в другой.

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

Виртуальные локальные сети

Таблица 16.1. Классытрафика и количество очередей

Количество очередей

Классы трафика

{BE, ЕЕ, ВК, VO, CL, VI, NC}

{BE, ЕЕ, ВК}

{VO, CL, VI, NC}

{BE, ЕЕ, ВК}

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

Резервирование и профилирование

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

Для коммутаторов локальных сетей не существует стандартного протокола резервирования ресурсов. Поэтому для выполнения резервирования администратор сети должен сконфи­ гурировать каждый коммутатор сети отдельно.