Здесь 10.0.1.2 – IP-адрес на rl0; напомню, что шлюзом по умолчанию у нас является 10.1.1.1. Для полного счастья этого ещё недостаточно (поскольку трафик к «чужим» IP-адресам по-прежнему будет стремиться уйти через шлюз по умолчанию), поэтому заключительным штрихом будет перенаправление трафика с адреса, к которому мы таким образом привязали Squid, в наш второй канал, скажем, тем же fwd-правилом:

# ipfw add fwd 10.0.1.1 ip from 10.0.1.2 to not 192.168.0.0/24 out

Эта схема будет работать и без последующего NAT-преобразования, но при условии, что IP-адрес, заданный на rl0 (и к которому мы привязываем Squid) будет из диапазона, выданного нам провайдером, предоставляющим подключение на данном канале. Это даст гарантию, что и входящий трафик будет маршрутизирован должным образом.

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

CLIENT_OPTIONS(`Addr=10.0.1.2')dnl

Теперь вся исходящая почта будет уходить с указанного адреса – остаётся только пакеты перенаправить в нужный шлюз. (Думаю, не нужно пояснять, что на маршрут входящей почты мы можем влиять лишь соответствующей MX-записью для нашего домена).

Распределение нагрузки по подсетям

Если равномерно распределить трафик по типу не удаётся (допустим, 99% всей нагрузки приходится на http-соединения), то можно попытаться «раскидать» трафик внутренних подсетей по разным каналам.

Использование для этой цели fwd-правил очевидно (с той же поправкой на дальнейшую NAT-трансляцию):

ipfw add 4900 fwd 10.0.1.1 ip from 192.168.0.0/25 to any

Но в данном случае можно использовать распределение нагрузки и на базе NAT, запущенного на данном компьютере (рис. 2).

Рисунок 2. Схема с «внутренними» NAT-серверами

Например, так это можно осуществить, используя ipfw и два экземпляра natd:

# natd -n rl0 -p 8668

# natd -n rl1 -p 8669

# ipfw add divert 8668 ip from 192.168.0.0/25 to any