Архив за месяц: Декабрь 2013

Ограничение скорости интернета для пользователей на Cisco ASA 5510 или как мы переходили на Cisco ASA — часть 2

Cisco, , ,

Итак, с PBR на Cisco ASA кое-как разобрались. Пришло время взяться за ограничение скорости для пользователей. На дебиане оно было реализовано просто и эффективно: при помощи iptables + htb у всех были выставлены минимальная (гарантированная) и максимальная скорость. Все были довольны, всем всего хватало. По необходимости, скорость конкретным пользователям весьма просто увеличивалась или уменьшалась.

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

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

Второй способ — traffic policing. Основное его отличие от шейпинга состоит в отсутствии буфера, т.е. «лишние» пакеты просто отбрасываются. Еще одним отличием от шейпинга является то, что он может применяться как к входящим пакетам, так и к исходящим. Несмотря на отсутствие буфера, приоритезация трафика возможна и в этом случае. Осуществляется она благодаря использованию очереди LLQ (Low-latency queuing). Отличие от шейпинга в данном случае состоит в том, что задержки для любого типа трафика будут ниже, но при этом возможность потери пакетов гораздо выше.

С точки зрения качества обслуживания, было бы неплохо использовать шейпинг трафика. Но тут кроется основная проблема: ASA умеет шейпить трафик только для class-default, т.е. весь трафик, да и то только исходящий. По сути, эта «фишка» реализована тут только для приближения скорости передаваемых данных к ширине канала — передать максимум, пусть и с задержками, потерять минимум.

Таким образом, ограничить входящую скорость всем и каждому мы можем только при помощи полисинга. При этом, если мы желаем ограничить скорость именно для каждого айпишника, нам придется создать по одному acl (access-list) на каждый адрес. Далее, для каждого acl необходимо создать class-map. Вот тут-то и кроется загвоздка. Общее количество class-map’ов в ASA ограничено числом 255. Если общее количество работников/серверов превышает это значение, то вы не сможете ограничить всех и каждого. Так или иначе придется разбивать всех по определенным группам и выставлять скорость уже для группы. При этом, естественно, любители скачивать торренты будут «отбирать» у группы больше скорости, чем было в случае iptables + htb — соответственно качество обслуживания остальных будет ниже.

Рассмотрим конкретный пример ограничения входящей скорости до 10 Мбит/с.

Создать access-list для интересующих нас адресов (сеть 192.168.1.0/24):

access-list LIMITED extended permit tcp any 192.168.1.0 255.255.255.0

Создать соответствующий class-map:

class-map LIMITED
match access-list LIMITED

Создать policy-map:

policy-map LIMITED
class LIMITED
police output 10000000

И применить его к интерфейсу локальной сети:

service-policy LIMITED interface LOCAL

Несколько пояснений по вышеуказанной конфигурации:

  • направление трафика output соответствует трафику, исходящему с интерфейса внутрь сети, т.е. в нашем случае это будет входящий трафик из интернета;
  • скорость для полисинга указывается в битах в секунду;
  • policy-map применяется для локального интерфейса, т.к. на внешнем интерфейсе у нас будут видны только адреса, которые прошли через NAT;

Такой вариант ограничения скорости может быть хорошим в том случае, если список адресов, у которых скорость ограничена всегда укладывается в одну подсеть или редко меняется. На практике такое встречается не часто и поэтому гораздо удобнее пользоваться группами объектов. В группы можно добавлять адреса по одному или целыми подсетями. При этом, два одинаковых адреса добавить не получится (чего не скажешь о двух одинаковых правилах access-list). Создадим группу и добавим в нее несколько хостов:

object-group network LIMITED
network-object host 192.168.1.5
network-object host 192.168.1.7
network-object host 192.168.1.8

Создадим access-list для этой группы:

access-list LIMITED extended permit tcp any object-group LIMITED

Если же нам необходимо исключить из полисинга какой-то трафик (к примеру, трафик DMZ-сети), то мы должны добавить соответствующий access-list с действием deny до этого правила. Выглядеть это будет примерно так (допустим, DMZ-сеть имеет адреса 192.168.15.0/24):

access-list LIMITED extended deny tcp 192.168.15.0 255.255.255.0 object group LIMITED
access-list LIMITED extended permit tcp any object-group LIMITED

После этого применим такие же class-map и policy-map, которые были рассмотрены выше и сохраним конфигурацию краткой командой wr. При необходимости, можно посмотреть статистику полисинга:

show service-policy police

Эта команда выведет данные по ограничению скорости для каждого class-map, перечисленного в policy-map.

На этом простая настройка ограничения скорости завершена.

NEC VMWar VMware IDE CDR10 ATA Device или нерабочий CD-ROM в виртуальной машине

registry, vmware, ,

Возникла у меня как-то необходимость сконвертировать виртуальную машину с Windows 7 из формата VMWare Workstation в VMWare Infrastructure. После конвертации, естественно, очень желательно проапдейтить VMWare Tools. Вот с этим-то, внезапно, и возниклки проблемы. Дело в том, что виртуальный CD-ROM (NEC VMWar VMware IDE CDR10 ATA Device), на который монтируется образ с VMWare Tools по команде Install/Upgrade VMWare Tools, отказался работать и стартовать в системе. Удаление/добавление текущего привода, простое добавление еще одного CD-ROM никакого эффекта не возымели. На всех приводах в диспетчере устройств горел желтый восклицательный знак, а в свойствах светилась ошибка:

Windows cannot start this hardware device because its configuration information (in the registry) is incomplete or damaged. (Code 19)

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

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E965-E325-11CE-BFC1-08002BE10318}

и удалить оттуда ключ с именем UpperFilters или LowerFilters (в зависимости от того, что там есть). После этого простое «обновление драйвера» для устройства моментально решает проблему и CD-ROM снова работает!

Конечно, можно было бы просто закинуть VMWare Tools в гостевую систему и обновить их без привода. Но это не спортивно — проблему необходимо решать, а не обходить ;)

Policy-based routing на Cisco ASA 5510, или как мы переходили на Cisco ASA — часть 1.

Cisco, ,

Жила-была одна небольшая аутсорсинговая компания. И был у нее шлюз на debian. И было хорошо. На одном из собраний с руководством для повышения стабильности и доступности интернета и серверов компании снаружи, было решено перейти на cisco. Причем не просто на cisco, а сразу на 2 cisco ASA 5510 в режиме Active/Passive. Сказано — сделано: две циски были куплены. Осталось дело за малым — изучить, настроить и внедрить. Так уж получилось, что задача эта была возложена на меня.

Для начала, была составлена примерная схема того, что мы должны получить на выходе:

1. Разделение трафика по каналам;

2. Ограничение скорости интернета каждому пользователю;

3. Приоритезация трафика ip-телефонов, а также трафика skype из переговорных комнат;

4. DMZ-подсеть;

5. Немаленькая кучка NAT-ов (если быть точнее, то PAT-ов) внутрь сети;

6. Failover cluster;

7. Site-to-site IPSEC VPN с одним из заказчиков;

Было решено не тратить драгоценное время на полное изучение всех возможностей Cisco ASA, а сразу приступать к выполнению конкретных подзадач, изучая все по ходу действий — знания, полученные на практике, всегда лучше усваиваются и запоминаются дольше.

В дальнейшем тексте предполагается, что у нас есть интерфейсы LOCAL (локальная сеть), ISP1 (интернет-провайдер 1), ISP2 (интернет-провайдер 2) и DMZ.

У тех, кто хорошо знаком с официальными возможностями Cisco ASA, первый пункт списка вызовет некоторое недоумение: в Cisco ASA в один момент времени может быть активен только один маршрут в одном направлении. То есть маршрутов по умолчанию вида

route ISP1 0.0.0.0 0.0.0.0 xxx.xxx.xxx.xxx Y

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

Однако, несмотря на все ограничения, есть способ частично разделить трафик. Конечно, это будет не полноценный PBR, но на безрыбье и рак рыба. «Фишка» в том, что asa имеет свой алгоритм выбора канала для любого пакета. В мануале он описан так:

Egress Interface Selection Process 

 1. If destination IP translating XLATE already exists, the egress interface for the packet is determined from the XLATE table, but not from the routing table. 

 2. If destination IP translating XLATE does not exist, but a matching static translation exists, then the egress interface is determined from the static route and an XLATE is created, and the routing table is not used. 

 3. If destination IP translating XLATE does not exist and no matching static translation exists, the packet is not destination IP translated. The ASA processes this packet by looking up the route to select egress interface, then source IP translation is performed (if necessary).

То есть, если этот пакет первый в данном направлении (нет созданного XLATE), то в первую очередь будут проверяться правила static nat/pat. И если при создании этого правила в качестве inside-интерфейса указать интерфейс ISP2, а outside — интерфейс LOCAL, то трафик, соответствующий этим правилам будет отправлен через интерфейс, указанный в правиле. Например:

static (ISP2,LOCAL) tcp 0.0.0.0 80 0.0.0.0 80 netmask 0.0.0.0

Это правило отправит весь http-трафик через интерфейс ISP2 даже если активен маршрут через интерфейс ISP1. Таким образом, можно получить корявенький, костыльный, но хоть как-то работающий PBR на cisco ASA.

При этом, хотелось бы отметить несколько неприятных нюансов:

1. Правила такого вида будут применяться вне зависимости от адреса назначения пакета. То есть при наличии сети DMZ, пакеты на 80 порт, адресованные в эту сеть, без дополнительных правил (о которых я расскажу в части про DMZ), будут уходить через интерфейс ISP2, т.е. фактически теряться.

2. При таком выборе канала для http-трафика, становится невозможным использование wccp — asa выбирает канал для отправки пакета до того, как узнает, что его надо переадресовать на прокси. При этом, она попытается отправить его на прокси (т.к. видит его активный статус), но через внешний канал. Таким образом, http-трафик просто потеряется.

Работа WordPress на nginx + apache (постоянный 301 редирект)

apache, nginx, Wordpress, , , ,

В последнее время связка nginx + apache стала очень популярной среди администраторов веб-серверов. Эта связка довольно эффективна: nginx обеспечивает высокую скорость отдачи статического контента, кэширование, балансировку нагрузки, а apache, в свою очередь, давно признан стандартом де-факто среди веб-серверов за свою многофункциональность.

Ожидаемым было и появление хостинг-провайдеров, работающих с данной связкой. Чаще всего настройка nginx в данной связке ограничивается примерно такой конструкцией:

location / {
     index index.php index.html index.htm;
     try_files $uri $uri/ @proxy;
}
location ~ \.php$ {
     proxy_set_header X-Real-IP $remote_addr;
     proxy_set_header Host $host;
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
     proxy_pass http://127.0.0.1;
}
location @proxy {
     proxy_set_header X-Real-IP $remote_addr;
     proxy_set_header Host $host;
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
     proxy_pass http://127.0.0.1;
}

В таком случае установка WordPress вызовет бесконечную переадресацию с кодом 301. Дело в том, что nginx при получении запроса GET / будет подставлять индексный файл index.php и отправлять этот запрос на прокси, в качестве которого выступает apache. Apache, в свою очередь, запустит этот файл и за обработку запроса и формирование страницы примется WordPress. Для пущей красоты WordPress удалит из адресной строки index.php, который туда «дописал» nginx и вернет новый «красивый» урл с редиректом 301 клиенту. Клиент перейдет по нему, nginx допишет index.php и мы будем иметь то, что имели в самом начале.

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

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

location ~[^?]*/$ {
     proxy_set_header X-Real-IP $remote_addr;
     proxy_set_header Host $host;
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
     proxy_pass http://127.0.0.1;
}

В таком случае запрос вида GET / будет передан на apache без изменений, wordpress его корректно обработает и вернет главную страницу сайта. При этом, естественно, индексный файл index.php должен быть определен и в конфигурации apache.

Skype грузит процессор

Skype

С недавним апдейтом скайпа ко многим пришли и проблемы: он начал грузить   процессор на 60-80%. Простая переустановка ничего не решала.

Причины произошедшего остались за кадром, а решение оказалось вполне простым: всего лишь скачать и установить версию Skype для старых компьютеров (Skype SSE). Также, эта версия помогает скайпу «увидеть» камеру, если она есть в системе, но skype наотрез отказывается с ней работать.

UPD: С этой версией не работает конференц-связь. Поиски решения продолжаются. В качестве временной меры можно попробовать установить более старую версию и отключить автоматические обновления. Версия 6.9 подходит. Скачать ее можно здесь: http://download.skype.com/msi/SkypeSetup_6.9.0.106.msi

UPD2: По последним наблюдениям, самая свежая версия (6.14.0.104) не грузит процессор.