Жила-была одна небольшая аутсорсинговая компания. И был у нее шлюз на 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, а сразу приступать к выполнению конкретных подзадач, изучая все по ходу действий — знания, полученные на практике, всегда лучше усваиваются и запоминаются дольше.

У тех, кто хорошо знаком с официальными возможностями 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-трафик просто потеряется.