Итак, с чего бы начать повествование…
Пожалуй, начну с того, как все было раньше и как развивалось. Я пришел в
компанию-интегратор около двух лет назад. До этого в течении пяти лет я
трудился у операторов ШПД и мобилников. Там я занимался магистральной сетью.
Здесь же пришлось перейти на другой уровень - сетей предприятия. Если
операторские сети характеризуются большим трафиком и кучей маршрутов, то сети
предприятий - это интеллектуальные услуги с небольшим трафиком. Везде своя
специфики, разные устройства.
Любой интегратор - контора проектная, где
прибыль приносят исключительно проекты. Когда специалист занимается настройкой
или проектированием по какому-либо проекту, оплата его труда идет из бюджета
этого проекта. В компании есть внешние проекты - проекты, которые приносят
деньги, и есть внутренние - такие как “Поддержка внутренней сетевой
инфраструктуры” и т.д. Внутренние тоже требуют затрат труда, но руководители
проектов не любят тратить бюджет вутренний, да и специалисты не любят
внутренние проекты из-за того, что по ним час труда стоит меньше (эдакая
мотивация заниматься внешними коммерческими проектами). Из вышесказанного можно
сделать вывод, что внутренняя структура ИТ находится на уровне “чтобы
работало”, но с минимальными затратами.
Когда я пришел в фирму, внутренняя сеть
представляла собой классический пример SOHO (даже не SMB). Единственное, что
отличало её от домашней сети - наличие нескольких VLAN (DMZ, WLAN, LAN).
На периметре стояла одинокая ASA 5505 с единственным каналом в интернет. На
этой железке был поднят сервис Remote Access VPN на Cisco Anyconnect с
авторизацией через LDAP. Нужно заметить, что был реализован и доступ через
Clientless SSL VPN со всеми его фичами такими как split-tunnel, java-приложения
(rdp, vnc, telnet/ssh).
Временами у провайдера
случались аварии. И все бы ничего, если бы в один прекрасный день, это не
произошло во время электронных торгов, а именно какой-то борьбы за тендер. Так
встал вопрос о подключении второго провайдера и резервировании доступа в
интернет. Подключили ещё один канал от другого оператора. Новый канал падал
чаще, но, тем не менее, они все время падали в разное время.
На ASA я реализовал
автоматическое переключение с использованием IP SLA и Track. Пингуем гугловский
публичный днс через основной канал. Если пинги не проходят, убираем статический
маршрут “по-умолчанию” с наибольшей метрикой (по срабатывани. track). Остается
маршрут постоянный с большей метрикой. Резервирование интернета есть.
Прошло некоторое время, и
у фирмы появился офис в другом городе. Вся инфраструктуара находится,
соответственно, в основном офисе. Появилась новая задача - подключить офис к
существующим ресурсам с минимальными затратами. Так появилась ещё одно ASA и
IPSec site-to-site туннель. И всё шло хорошо до первого падения основного
канала. Туннель не резервируется. На ASA основного офиса нет возможности
построить два туннеля через разные интерфейсы на один IP адрес т.к. маршрут
наружу для удаленного хоста идет только через один интерфейс. В момент падения
туннели приходилось переделывать руками.
Так получилось, что у меня
оказалась одна свободная ASA 5505. Я решил задействовать её, переместив на нее
резервный канал в интернет. В виду минимальных расходов на собственную
инфраструктуру в ядре нашей сети нет коммутатора L3, поэтому пока не
реализовано резервирования “шлюза по-умолчанию”, в связи с чем я решил включить
вторую ASA в первую (ASA не поддерживает ни один из FHRP). При начилчии
коммутатора L3 в ядре резервирование “шлюза по-умолчанию” делается на
динамическом протоколе маршрутизации.
Начальная схема:
