Методика тестирования маршрутизаторов, версия 2.6


Тестирование устройства делится на три этапа:

В качестве тестовых стендов используются два компьютера со следующими параметрами:

  • Платформа — Asus Terminator
  • Процессор — VIA C3 866MHz
  • Сетевые адаптеры — Intel Pro/100+ Management Adapter и SIS 900
  • Память — 128MB SDRAM
  • Жесткий диск — Maxtor 20GB
  • ОС — Gentoo Linux 1.4 с ядром из ветки 2.6.x

Тестирование производительности

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

Для тестирования используется программный пакет NetIQ Chariot. Пакет представляет собой консоль управления (которая может находиться на любом компьютере) и набор сенсоров. Последние являются программами, которые устанавливаются на хостах-генераторах и осуществляют генерацию и мониторинг трафика (по определенным шаблонам). Сенсоры существуют под множество ОС, из которых нас интересуют Linux и Windows 2000.

Один компьютер находится в локальной сети (подключался к локальному порту маршрутизатора), второй — внешней (подключался к порту WAN). Между ними находится тестируемое устройство. На каждом хосте установлены Chariot-сенсоры. Далее, запускается консоль управления:

Задаются пары приемника и передатчика трафика (указываются IP адреса хостов с сенсорами) и каждой паре назначается нужный скрипт, в соответствии с которым трафик и будет генерироваться.

Для тестов используются три скрипта, генерирующие различные типы трафика:

  • Пакеты максимального размера;
  • Пакеты размера 512 байт;
  • Пакеты размера 64 байта;
Наличие тестов на пакетах небольшого и среднего размеров способно выявить ошибки реализации некоторых алгоритмов работы тестируемого устройства. Не следует ожидать максимальных скоростей на подобных тестах — производитель обычно заявляет скорость маршрутизации для пакетов максимальной длины, а вот на минимальных она оказыается существенно меньше (что, впрочем, является нормой для любых маршрутизаторов и даже коммутаторов).

Throughput.scr: TCP трафик без ограничений (циклическая пересылка файлов размером 100000 байт со случайно-сгенерированным содержанием). В этом случае большая часть пакетов, проходящих через маршрутизатор, будет максимально возможного размера (1514 байт).

Throughput_512.scr: TCP трафик с размерами пакетов 512 байт, кроме того, увеличено количество транзакций до 100.

Throughput_64.scr: TCP трафик с размерами пакетов 64 байта, кроме того, увеличено количество транзакций до 300.

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

Кроме этого, немного изменены опции работы, а именно установлено фиксированное время работы теста в 180 секунд:

Вторая используемая утилита — netPIPE версии 3.5. Программа осуществляет генерацию трафика с постепенно возрастающим размером пакета данных (пакет размера N передается несколько раз, количество передач обратно пропорционально его размеру, но не меньше семи). Передачи пакетов туда-сюда осуществляются последовательно (одновременная передача пакетов данных отсутствует). Эта схема позволяет наглядно увидеть процент использования канала в зависимости от размера передаваемых данных.

Параметры запуска netPIPE:
приемник: NTtcp -b 65535 -o logfile
передатчик: NTtcp -b 65535 -o logfile -h $IP

Результаты тестирования производительности

Результаты NetIQ Chariot.
С помощью программы генерировался TCP-трафик (с пакетами преимущественно максимального размера) и моделировались все три возможные ситуации.

  • Передача трафика из внутренней сети во внешнюю (LAN –> WAN);
  • Передача трафика из внешней сети во внутреннюю (WAN –> LAN);
  • Двунаправленная передача трафика в обе стороны одновременно (fdx WAN&WAN);

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



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

Результаты netPIPE.
Программа генерирует трафик методом «Ping Pong». Поэтому скорость передачи данных будет одинакова вне зависимости от того, с какой стороны находится клиент netPIPE, а с какой — сервер.

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

Тестирование VPN

В данном случае понимается скорость шифрования трафика маршрутизатором. Метод абсолютно аналогичен тестированию производительности, но в данном случае перед генерацией трафика создается IPSec туннель между WAN портом маршрутизатора и VPN сервером. Chariot-сенсоры устанавливаются в локальных сетях за LAN портом тестируемого маршрутизатора с одной стороны и за второй сетевой картой VPN сервера — с другой.

В качестве последнего выступает компьютер с установленным Gentoo Linux 1.4 (ядро 2.6.4). В ядре включена поддержка IPSec протокола, а в системе дополнительно установлена последняя версия ipsec-tools.

Тестируется все поддерживаемые алгоритмы шифрования/аутентификации как для ESP (полное шифрование данных), так и для AH (аутентификация заголовков, сами данные не шифруются).

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

  • для ESP: DES, 3DES, AES;
  • для AH: MD5, SHA1

Тестирование безопасности

Для этого теста используется последняя версия свободно распространяемого сканера сетевой безопасности Nessus (на данный момент версии 1.2.7). Внешний порт (WAN) сканируется всеми доступными плагинами из списка.

В качестве результатов приводится сокращенный (без списка конфигурации текущего сканирования) и полный отчет, генерируемый Nessus-ом. Тут же отмечается стабильность работы устройства во время процесса его сканирования — оставались ли доступны внешние хосты в этот момент? Не перегружался/не вис ли роутер?

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

Кроме этого, в этот же раздел попадают все замеченные «баги безопасности», встреченные во время тестирования устройства. К примеру, сюда относятся:

  • пустой пароль по умолчанию, установленный на интерфейсе администрирования;
  • открытые наружу порты

 




Дополнительно

Методика тестирования маршрутизаторов, версия 2.6

Методика тестирования маршрутизаторов, версия 2.6

Тестирование устройства делится на три этапа:

В качестве тестовых стендов используются два компьютера со следующими параметрами:

  • Платформа — Asus Terminator
  • Процессор — VIA C3 866MHz
  • Сетевые адаптеры — Intel Pro/100+ Management Adapter и SIS 900
  • Память — 128MB SDRAM
  • Жесткий диск — Maxtor 20GB
  • ОС — Gentoo Linux 1.4 с ядром из ветки 2.6.x

Тестирование производительности

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

Для тестирования используется программный пакет NetIQ Chariot. Пакет представляет собой консоль управления (которая может находиться на любом компьютере) и набор сенсоров. Последние являются программами, которые устанавливаются на хостах-генераторах и осуществляют генерацию и мониторинг трафика (по определенным шаблонам). Сенсоры существуют под множество ОС, из которых нас интересуют Linux и Windows 2000.

Один компьютер находится в локальной сети (подключался к локальному порту маршрутизатора), второй — внешней (подключался к порту WAN). Между ними находится тестируемое устройство. На каждом хосте установлены Chariot-сенсоры. Далее, запускается консоль управления:

Задаются пары приемника и передатчика трафика (указываются IP адреса хостов с сенсорами) и каждой паре назначается нужный скрипт, в соответствии с которым трафик и будет генерироваться.

Для тестов используются три скрипта, генерирующие различные типы трафика:

  • Пакеты максимального размера;
  • Пакеты размера 512 байт;
  • Пакеты размера 64 байта;
Наличие тестов на пакетах небольшого и среднего размеров способно выявить ошибки реализации некоторых алгоритмов работы тестируемого устройства. Не следует ожидать максимальных скоростей на подобных тестах — производитель обычно заявляет скорость маршрутизации для пакетов максимальной длины, а вот на минимальных она оказыается существенно меньше (что, впрочем, является нормой для любых маршрутизаторов и даже коммутаторов).

Throughput.scr: TCP трафик без ограничений (циклическая пересылка файлов размером 100000 байт со случайно-сгенерированным содержанием). В этом случае большая часть пакетов, проходящих через маршрутизатор, будет максимально возможного размера (1514 байт).

Throughput_512.scr: TCP трафик с размерами пакетов 512 байт, кроме того, увеличено количество транзакций до 100.

Throughput_64.scr: TCP трафик с размерами пакетов 64 байта, кроме того, увеличено количество транзакций до 300.

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

Кроме этого, немного изменены опции работы, а именно установлено фиксированное время работы теста в 180 секунд:

Вторая используемая утилита — netPIPE версии 3.5. Программа осуществляет генерацию трафика с постепенно возрастающим размером пакета данных (пакет размера N передается несколько раз, количество передач обратно пропорционально его размеру, но не меньше семи). Передачи пакетов туда-сюда осуществляются последовательно (одновременная передача пакетов данных отсутствует). Эта схема позволяет наглядно увидеть процент использования канала в зависимости от размера передаваемых данных.

Параметры запуска netPIPE:
приемник: NTtcp -b 65535 -o logfile
передатчик: NTtcp -b 65535 -o logfile -h $IP

Результаты тестирования производительности

Результаты NetIQ Chariot.
С помощью программы генерировался TCP-трафик (с пакетами преимущественно максимального размера) и моделировались все три возможные ситуации.

  • Передача трафика из внутренней сети во внешнюю (LAN –> WAN);
  • Передача трафика из внешней сети во внутреннюю (WAN –> LAN);
  • Двунаправленная передача трафика в обе стороны одновременно (fdx WAN&WAN);

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



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

Результаты netPIPE.
Программа генерирует трафик методом «Ping Pong». Поэтому скорость передачи данных будет одинакова вне зависимости от того, с какой стороны находится клиент netPIPE, а с какой — сервер.

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

Тестирование VPN

В данном случае понимается скорость шифрования трафика маршрутизатором. Метод абсолютно аналогичен тестированию производительности, но в данном случае перед генерацией трафика создается IPSec туннель между WAN портом маршрутизатора и VPN сервером. Chariot-сенсоры устанавливаются в локальных сетях за LAN портом тестируемого маршрутизатора с одной стороны и за второй сетевой картой VPN сервера — с другой.

В качестве последнего выступает компьютер с установленным Gentoo Linux 1.4 (ядро 2.6.4). В ядре включена поддержка IPSec протокола, а в системе дополнительно установлена последняя версия ipsec-tools.

Тестируется все поддерживаемые алгоритмы шифрования/аутентификации как для ESP (полное шифрование данных), так и для AH (аутентификация заголовков, сами данные не шифруются).

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

  • для ESP: DES, 3DES, AES;
  • для AH: MD5, SHA1

Тестирование безопасности

Для этого теста используется последняя версия свободно распространяемого сканера сетевой безопасности Nessus (на данный момент версии 1.2.7). Внешний порт (WAN) сканируется всеми доступными плагинами из списка.

В качестве результатов приводится сокращенный (без списка конфигурации текущего сканирования) и полный отчет, генерируемый Nessus-ом. Тут же отмечается стабильность работы устройства во время процесса его сканирования — оставались ли доступны внешние хосты в этот момент? Не перегружался/не вис ли роутер?

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

Кроме этого, в этот же раздел попадают все замеченные «баги безопасности», встреченные во время тестирования устройства. К примеру, сюда относятся:

  • пустой пароль по умолчанию, установленный на интерфейсе администрирования;
  • открытые наружу порты