Насчёт балансировки трафика между двумя каналами есть статья в журнале "Системный администратор" №2(51)'2007, но там в основном про IPFW. Однако автор всё же обмолвился и про PF.
Алгоритм балансировки трафика
round-robin между двумя каналами на PF:
Код: Выделить всё
pass in on ed0 route-to { (rl0 10.0.1.1), (rl1 10.1.1.1) } round-robin from 192.168.0.0/24 to any keep state
здесь: ed0 — внутренний интерфейс, смотрящий на клиентов; rl0 и rl1 — внешние интерфейсы, смотрящие на провайдеров; 10.0.1.1 — адрес шлюза провайдера А; 10.1.1.1 — адрес шлюза провайдера Б; 192.168.0.0/24 — локальная сеть.
Этим правилом входящий трафик на внутреннем интерфейсе (т.е. исходящий для пользователей) будет распределяться между интерфейсами rl0 и rl1 с соответствующими шлюзами по алгоритму round-robin (то есть внешний интерфейс будет меняться циклически — первое соединение будет использовать rl0, второе — rl1, третье — снова rl0 и так далее). Опция keep state сохраняет состояние, благодаря чему все пакеты в рамках одного соединения будут использовать один и тот же шлюз. В итоге нагрузка будет распределяться между двумя каналами — нельзя сказать, что трафик поделится абсолютно поровну, но при рассмотрении за большой период времени можно считать, что балансировка будет приближаться к этому.
Для решения проблемы привязки соединений клиента к определённому IP-адресу, которое требуется для некоторых серверов (а в данном случае каждое новое соединение от одного и того же клиента к определённому серверу будет проходить с большой вероятностью через разные маршруты/интерфейсы), нужно использовать опцию
sticky-address в правиле nat или route-to. Чтобы распределять трафик между интерфейсами в определённой пропорции в правиле PF нужно использовать опцию
probability.
GNU/Linux — это не Unix и даже никогда им не был, и, что самое смешное, никогда им не станет — GNU's Not Unix