Два канала – роскошь?

Резервирование и балансировка трафика во FreeBSD

Сергей Супрунов

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

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

Конечно, «академически» правильным решением была бы настройка полноценного маршрутизатора (возможно, даже программно-аппаратного комплекса типа Cisco), обеспечивающего динамическое регулирование трафика на основании такой информации, как доступность того или иного узла, «стоимость» маршрута, требования к качеству обслуживания (сетевики этот QoS уже в ночных кошмарах видят). Однако это зачастую связано с необходимостью регистрировать собственную автономную систему (AS), настраивать один из протоколов маршрутизации (например, BGP) и т. д. Для небольших компаний такие решения обычно оказываются неоправданно дорогими и сложными, да и не каждый провайдер захочет с этим возиться, если вы для него – лишь один из тысяч клиентов, подключённых по обычному ADSL. Поэтому мы рассмотрим, что можно сделать без взаимодействия с провайдером, имея в своём распоряжении лишь машину с установленной FreeBSD, выполняющей роль шлюза для локальной сети.

Анализ проблемы

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

Чтобы не потерять за деревьями леса, будем считать, что оба канала «приходят» к нашему серверу в виде Ethernet, т.е. подключаются на обычные сетевые карты и настраиваются путём указания IP-адреса самого интерфейса, адреса шлюза по умолчанию и маски подсети (т.е. как статические маршруты). Через третью сетевую карту подключается локальная сеть. Для определённости в дальнейших примерах будем считать, что внешними интерфейсами являются rl0 и rl1, а ed0 – внутренний. В зависимости от условий договоров с провайдерами могут возникнуть следующие подзадачи:

n  переключение на более дорогой канал только на время проблем с дешёвым;

n  направление трафика, чувствительного к задержкам, в более «быстрый» канал, в то время как весь не критичный к скорости доставки пакетов трафик (например, FTP-закачки) заворачивать в «медленный», но более дешёвый канал;

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

Думаю, и без длительных объяснений понятно, что как-то влиять мы сможем лишь на тот трафик, который инициируется хостами локальной сети, получающими доступ в Интернет через данный сервер, либо самим сервером. То есть мы сможем управлять тем, через какой из каналов будет загружаться запрошенная пользователем страница или «заливаться» на удалённый FTP-сервер какой-то файл. А вот трафик, инициированный «снаружи» (например, почтовый или запросы на веб-сервер компании), придётся обслуживать на том канале, куда он придёт.