Настройка multivan на роутере

Обновлено: 25.01.2025

Конфигурационный файл /etc/config/multiwan является частью пакета multiwan. Этот пакет представляет собой скрипт, который позволяет сделать конфигурацию с несколькими провайдерами простой и легко управляемой. Пакет multiwan содержит легко настраиваемый набор правил распределения нагрузки и отказоустойчивости.

Установка

Посредством графического интерфейса LuCI

В LuCI выполните шаги:

System → Software → Available packages → Найдите пакет luci-app-multiwan → Нажмите Install

В результате будет установлен пакет multiwan и пакет управления им через LuCI luci-app-multiwan. После установки при очередном обновлении веб-страницы, Вы сможете настраивать пакет multiwan на странице Network → Multi-WAN

Посредством командной строки (CLI)

Настройка

Основные настройки

В файле /etc/config/multiwan (по умолчанию маршрутизировать трафик через оба интерфейса WAN )

В командной строке (выставляем последовательный мониторинг живости линка):

* Распределение нагрузки посредством netfilter называется Fast Balancer (лучшее распределение)

* Распределение нагрузки посредством iproute2 называется Load Balancer (лучшая совместимость)

* Правило wanrule для Fast Balancer - “fastbalancer”

* Правило wanrule для Load Balancer - “balancer”

Казалось бы, что fastbalancer должен давать лучший результат, но в действительности Вам нужно попробовать оба варианта, чтобы понять, какой из них лучше всего подходит для вашей ситуации.

Интерфейс WAN

Имя параметра	Значение по умолчанию	Варианты значения	Описание
weight	10	disable/1-10	Load Balancer Distribution
health_interval	10	disable/5/10/20/30/60/120	Health Monitor Interval in seconds
icmp_hosts	?	disable/dns/gateway/<host>	Health Monitor ICMP Host(s)
timeout	?	disable/1-5/10	Health Monitor ICMP Timeout
health_fail_retries	?	1/3/5/10/15/20	Attempts Before WAN Failover
health_recovery_retries	?	1/3/5/10/15/20	Attempts Before WAN Recovery
failover_to	?	disable/balancer/fastbalancer/<interface>	Failover Traffic Destination
dns	auto	auto/<dns>	DNS Server(s)

При использовании двух или нескольких модемов 3G вам нужно добавить для каждого интерфейса WAN следующие правила в /etc/config/network:

Правила для исходящего трафика

Если несколько правил перекрываются, действует правило, расположенное последним в файле конфигурации. ( not clear enough.)

Имя параметра	Значение по умолчанию	Варианты значения	Описание
src	all	all/<IP >/<hostname>	Адрес источника: all (любой), адрес IP либо имя хоста
dst	all	all/<IP >/<hostname>	Адрес получателя: all (любой), адрес IP либо имя хоста
port_type	dports	dports/source-ports	Тип порта: порт источника или порт получателя
ports	all	all/<port,port:range>	Номера портов: все, один либо диапазон
proto	all	all/tcp/udp/icmp/<custom>	Протокол: все, мнемоническое имя из /etc/protocols либо номер
wanrule	balancer/fastbalancer/<interface>	Правило распределения WAN : балансировка iproute2 или iptables, либо имя интерфейса
failover_to	balancer/fastbalancer/<interface>	Резервный линк при отказе этого линка

Quick Multiwan setup guide by AndyBallon

1. Установка Backfire 10.03

for upgrades from Kamikaze use the .trx and install via the web interface for bricked <smirk> routers see tftp install of .bin file

2. Create extra Vlan for Wan2

I do this via /etc/config/newtork.

Note: I removed port “0” from eth0_0 and gave it to eth0_2.

3. Install prerequisite software

ip, iptables, iptables-utils, iptables-mod-conntrack, iptables-mod-conntrack-extra, iptables-mod-ipopt and kmod-ipt-ipopt this is how I do it:

b. right click a link to a package and “Copy Link Location”

Reboot to refresh the web ui. I always need to do this otherwise the link does not show up in networking.

5. Configure Wans && configure multiwan

a. I only have two internet connections so I always remove the last two wan interfaces. I also comment out MWAN3 and MWAN4 in /etc/iproute2/rt_tables (although it may not be necessary). b. Load Balancer Distribution = 1 for even connection distribution

6. Test.

Status > Interfaces should show traffic going through both interfaces. try a torrent with lots of seeders. If you have a internet line that can do 90kbps max download, and another that can do 180kbps max if multiwan is working properly you should get a download rate greater than the higher rated link. pulling the plug from a wan port should still give you internet connection

7. Troubleshooting

when you refresh the Interface status page and the Transfer rate of one interface does not change when you you go the the Interface Status page you only see one wan interface when you do “route” you only get one default gateway

8. Extras

If you have two or more connections to the same ISP you should try:

Channel bonding ←- this gives you per packet load distribution (effectively doubles your transfer rates)

Last modified: 2015/12/11 15:47
by tmomas

Self-registration in the wiki has been disabled.
If you want to contribute to the OpenWrt wiki, please post HERE in the forum or ask on IRC for access.

Except where otherwise noted, content on this wiki is licensed under the following license:
CC Attribution-Share Alike 4.0 International

Я настоятельно рекомендую сначала прочитать, далее вникнуть, потом понять и только после того, как у вас вся картина будет нарисована в голове, приступить к настройке.

Настройка нескольких провайдеров в RouterOS.

Если оператор нам выдал ip адрес 1.1.1.2, то мы должны обеспечить выход через этого провайдера именно с таким ip адресом, а не с каким либо другим.

Не будем ходить вокруг да около, а сразу приступим к настройке.

Для начала определим вводные данные.

Интерфейс ether1
IP:88.88.88.2/29 Gateway: 88.88.88.1, а также данный провайдер отдаёт ещё один префикс на том же интерфейсе IP:99.99.99.2/24 Gateway: 99.99.99.1
DSN сервера 2.2.2.2 и 3.3.3.2

Интерфейс ether2
IP:44.44.44.2/29 Gateway: 44.44.44.1
DSN сервера 7.7.7.2 и 6.6.6.2

Ether3 - IP:172.20.17.1/24 - локальная сеть компьютеров
Ether4 - IP:172.20.18.1/24 - локальная сеть для серверов

Настройка IP адресации

Настроим IP адреса, согласно выданным настройкам от провайдеров.

Я думаю бессмысленно как-то дополнять данные настройки.

Маркировка соединений от провайдера

Вы наверное помните, а если и нет, то стоит напомнить, что любой пакет, который приходит на маршрутизатор попадает в цепочку prerouting и не важно куда он дальше попадёт forward или Input.

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

Сначала настроим, а далее разберём что сделали.

Разберём только первое правило, все остальные по аналогии.

Если пакет приходит с интерфейса ether1 и адрес назначения лежит в сети 88.88.88.0/29, и такой пакет создал соединение, то маркируем соединение маркой Next-Hop/88.88.88.1.

88.88.88.0/29 - почему сеть, а не IP? Если вы будете делать правила для каждого IP адреса, количество правил будет расти, а смысл будет тот же самый.

connection-state=new - нет смысла пытаться маркировать соединения, которые уже установлены, как вы помните new - это пакет, который создал соединение, т.е он только один, а в случае со всеми пакетами routeros будет каждый раз пытаться маркировать соединение, которое уже и так может иметь маркировку.

И так это наша заготовка, далее мы начнём работать непосредственно с логикой.

С этого момента весть трафик, который придёт со стороны провайдера, будет промаркирован, а далее бы будем оперировать данной маркировкой.

Доступ к маршрутизатору

Первая задача, которую нам необходимо решить, это организовать возможность управления маршрутизатором через разных провайдеров. Мы должны иметь возможность подключится по любому IP адресу по ssh, winbox, а также если вы будете использовать RouterOS в случае VPN сервера. В общем организовать правильный выход пакетов, которые будет отправлены с маршрутизатора в ответ на входящие соединения.

Для начала нам надо организовать правильные таблицы маршрутизации. В одной таблице маршрутизации не могут быть одновременно два одинаковых активных маршрута, если маршруты одинаковы, то приоритет выбирается из значения distance. Для того чтобы можно было использовать несколько одинаковых маршрутов в RouterOS есть возможность создавать альтернативные (именованные) таблицы маршрутизации.

Создадим данные таблицы.

dst-address=0.0.0.0/0 - обычный маршрут по умолчанию, не более чем.

gateway=88.88.88.1 - шлюз, обратите внимание на то, что нам первый провайдер даёт два префикса с разными шлюзами, и поэтому мы создаём три маршрута, для нас по факту не два провайдера, а три.

routing-mark=Next-Hop/88.88.88.1 - это и есть именованная таблица маршрутизации. Она может иметь любое имя, какое вам удобнее, лично моё мнение, такое именование удобно записывать в названии таблицы шлюз, через который будет отправлен пакет в случае если он будет использовать данный маршрут. Имена маркировок соединений и маршрутов просто совпали и могут быть совершенно разные.

Вы обратили внимание, что я писал про таблицы и маркировки, дело в том, что маркировка маршрута это не таблица, хотя в большинстве случаев это так. Попробуйте ответить на вопрос, для чего и какая разница в правилах между двумя фильтрами в фаерволе.

Дело в том, что routing-mark это маркировка, когда вы своими руками с помощью mangle назначили на пакет маркировку, а routing-table это то, через какую таблицу маршрутизации вышел пакет.

Если маршрутизатор не найдёт подходящего маршрута в именованной таблице маршрутизации, маршрутизатор продолжит поиск подходящего маршрута в таблице по умолчанию main и такой пакет можно будет отфильтровать например так routing-mark=custommark routing-table=main . Нам же такое поведение не нужно, если по какой-то причине маршрут не будет найден, пакет должен умереть на маршрутизаторе, а отправлять через другого провайдера нет никакого смысла.

Нам необходимо переопределить данное поведение.

Т.е марка и таблица по факту это одно и тоже, пакет который имеет определённую routing-mark пытается найти маршрут в таблице с таким же именем.

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

Все интерфейсы имеют способность падать, есть один интерфейс, который всегда находится в состоянии UP, но в RouterOS использовать его в конфигурации не представляется возможным - это Loopback.

В RouterOS данный интерфейс можно заменить пустым bridge.

Я часто расказываю на курсах, почему именно такое название, а не просто Loopback, возможно в ближайшем будущем в RouterOS будет добавлено поддержка Loopback интерфейса и если разрабочики заложат такое-же название, то при обновлении версии RouterOS могут возникнуть проблемы.

А теперь создадим маршрут в таблице main, который необходим для преодоления выбора маршрута и попадания пакета в цепочку output.

Максимальная дистанция для того, чтобы в случае если мы создадим нормальный маршрут по умолчанию, а не фиктивный, нам данный маршрут не мешал.

Напоминаю, что дистанция 255 это административная дистанция, которая явно указывает на то, что данный маршрут мёртв и не участвует в маршрутизации.

Всё, на данном этапе вы должны иметь возможность подключаться к маршрутизатору по любому IP адресу через любого провайдера одновременно, можете пинговать и делать всякие другие непотребства с внешними IP адресами.

Выход с маршрутизатора

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

Когда вы пингуете с маршрутизатора, строите PPP* или IP туннели с самого маршрутизатора или dns запросы отправляете с самого маршрутизатора. Разница с прошлым кейсом в том, что мы отправляли пакет по уже установленному соединению, а здесь пакет улетает с маршрутизатора и соединение не имеет маркировки.

Здесь будет значительно проще.

Весь трафик, который уходит с маршрутизатора, и имеет IP адрес, который попадает под префикс, будет отправлен в именованную таблицу маршрутизации.

Всё, теперь вы можете строить туннели и у вас всё будет работать, но только в том случае если явно указан IP адрес, например в Ipsec или gre, ip туннели и прочее, там где явно можно указать Source адрес. А что делать с сервисами, где нельзя указать явно IP адрес источника? Ответ на этот вопрос кроется в таблице маршрутизации. Параметр pref-src отвечает за то, какой IP адрес будет выбран если он явно не задан.

Если вам необходимо установить соединение из локальной сети с адресом который назначен на интерфейсе провайдера, допустим при использовании Hairpin-NAT, в правилах вы должны исключить BOGON сети из адресов назначения.

В нашем примере если только для одного IP адреса.

Ещё раз для понимания, у нас есть два варианта развитая сюжета, если IP адрес источника явно указан и тогда нам нечего не грозит и всё замечательно работает. Второй вариант, когда IP адрес явно не задан, например вы подминаете l2tp-client у нас нет возможности указать source адрес, но ведь адрес назначения есть в любом случае. Тогда маршрутизатор поступает следующим образом, он находит маршрут в таблице маршрутизации main, смотрит какой указан pref-src и использует данный ip адрес, как адрес источника.

Вы помните что мы создавали фиктивный маршрут.

Давайте его немного изменим так, чтобы мы определили IP адрес, с которого будет формироваться трафик.

Выбор IP адреса зависит только от вас, выбирайте тот адрес, который считаете менее загруженным.

На этом этапе всё, теперь вы можете строить различные туннели и устанавливать соединения не только указывая явно source адрес.

Доступ за НАТ

172.20.18.2 - это exchange сервер, мы должны обеспечить доступность 25,80,443 портов через каждого провайдера.

НАТ делаем как обычно, без всяких излишеств.

А теперь давайте вспомним то, что мы делали самым первым правилом в mangle мы промаркировали все соединения, которые приходят через всех провайдеров! Данная маркировка нам опять поможет.

Попробуем логически по шагам описать то, как это будет работать. Опишем для одного провайдера, для остальных по тоже схеме.

Когда пакет придёт на IP адрес 88.88.88.2 мы промаркировали соединение которому принадлежит пакет.
Далее в NAT мы изменили адрес назначения и маршрутизатор отправит его до сервера.
Естественно сервер в ответ отправит пакет, как минимум syn,ack, так как данный пакет принадлежит уже существующему соединению, мы по имени соединению отправим данный пакет в именованную таблицу маршрутизации.

НАТ уже сделали, дело осталось за малым- найти трафик, который приходит от сервера.

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

Наверное многие спросят, а почему указывается не интерфейс ether1, а не взять и указать явно локальный интерфейс, например ether4.

Мы с вами делаем универсальную конфигурацию, если явно указать какой-либо другой интерфейс, значит в случае если у нас будет ещё один NAT, который пойдёт в другой порт, нам необходимо будет добавлять ещё одно аналогичное правило, но уже с другим интерфейсом. А ведь мы можем даже завернуть трафик с помощью NAT вообще на внешние сервера например 1.1.1.1, и что тогда? Единственный интерфейс откуда в цепочке prerouting мы не должны ожидать данный трафик, это трафик с самого провайдера и причём именно с того, с которого он пришёл.

Всё работает, теперь вы можете подключаться в своему серверу по любому IP адресу. Создайте DNS A запись RR и укажите все три внешних IP адреса и всегда ссылайтесь на данную запись.

Ещё каких-то лет 7 назад, DNS RR работал не очень хорошо, в плане того, что приложения зачастую использовали только первый IP адрес, сейчас все изменилось и многие приложения в случае, если не смогут подключиться по одному адресу, будут пытаться подключаться по другому и так далее.

А также source NAT?

Промелькнула такая мысль в голове? Ведь когда пакет от сервера будет уходить через маршрутизатор, нам надо будет подменить его src адрес, на адрес на который он шёл в самом начале. Но мы ничего не сделали для этого.

Нам делать ничего не нужно, если вспомнить что в правило NAT попадает только самый первый пакет, тот на основании которого было создано соединение new, именно поэтому обычно вы видите небольшие значения в счётчиках правила NAT.

Обратное преобразования NAT произойдёт автоматически, давайте взглянем на запись в conntrack.

Давайте уберём из вывода лишнее, чтобы оно нам не мешало.

И так когда пакет попал на маршрутизатор и соединение было "только только" создано, соединение имело такой вид

После того, как произошла процедура dst NAT, маршрутизатор добавил флаги и самое главное на какой адрес изменяется IP адрес во всех пакетах в данном соединении.

Когда пакет уходил с маршрутизатора в цепочки postrouting работает процедура src NAT, но у нас нет правил src NAT, оставили значение исходное.

Обратите внимание, что все данные этапы были сделаны на момент прохождения только первого пакета.

Теперь, если пакет приходит на маршрутизатор и у него в заголовках src-address=5.19.245.3:57839 dst-address=88.88.88.2:80 dst-address изменится на 172.20.18.2:80.

Если пакет приходит на маршрутизатор с адресами в заголовках src-address=172.20.18.2:80 dst-address=5.19.245.3:57839 src адрес изменится на 88.88.88.2:80.

Тем самым src NAT на данном этапе работает автоматически на основании правил dst-NAT.

Выпустить с правильного адреса

Часто бывают ситуации, что вам необходимо жёстко определить, чтобы какой-то внутренний хост выходил только с определённого IP адреса.

Например, VoIP телефония, ваш провайдер телефонии требует, чтобы вы регистрировались только с определённого IP адреса, или банк клиент на компьютере главного бухгалтера должен подключаться с определённого адреса.

Адрес 0.0.0.1 для того чтобы создать лист, но не привязывать к реальному адресу.

Название листа явно говорит о том, на какой IP адрес необходимо изменить адрес источника.

Для реализации данного кейса нам необходимо учитывать особенность работы RouterOS.

Дело в том, что для трафика который проходит через маршрутизатор мы можем изменить таблицу маршрутизации только в цепочке prerouting, и естественно исходящий интерфейс нам ещё не известен, он будет известен только в цепочке forward.

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

Для решении данной задачи нам помогут BOGON сети, это список сетей, которые никогда не должны использоваться для публикации между public AS в протоколе BGP, другими словами это все те сети, которые используются исключительно в локальных целях.

Создадим адрес лист с BOGON сетями.

А далее создадим правила для того, чтобы выпустить хосты с определённого IP адреса.

И последний нюанс- это настроить NAT.

Обратите внимание, что не весь трафик, а только тот, который находится в определённом маркированном маршруте, это необходимо для того, чтобы трафик между локальными сетями не попадал под NAT правило.

Выпускаем всех остальных и балансируем нагрузку.

Осталось дело за малым, выпустить всех остальных в интернет и постараться распределить нагрузку. Оговорю сразу мы не можем распределить нагрузку по пакетно, нам мешает то, что провайдеры не пропустят трафик с другими IP адресами через свою сеть. Поэтому будем балансировать соединениями. Да, мы не получим суммарную пропускную способность на одно соединение всех провайдеров, но это лучшее, что мы можем сделать в данном случае.

Мы будем использовать ECMP для того, чтобы распределить нагрузку по провайдерам.

Наверное вы уже догадались, что весь оставшийся трафик от ваших локальных хостов будет попадать в таблицу main.

Давайте сделаем маршрут ECMP с тем учётом, что шлюз 88.88.88.1 это 10Mbps, а 44.44.44.1 5Mbps.

Пакеты будут отправляться поочередно для каждого шлюза, на каждые 3 пакета, 2 пакету будут отправлены в 88.88.88.1 и оставшийся один пакет на шлюз 44.44.44.1.

Хотя это немного и не правильно, дело в том, что у процесса ECMP есть отдельная таблица кеша, и чтобы каждый раз не выбирать маршрут, маршрутизатор для связки src-address:port dst-address:port создаёт хеш и выберет для данного хеша уже шлюз по схеме Round Robin, тем самым для одного соединения будет выбираться один и тот же шлюз.

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

Проблема в том, что ограничение в 10 минут, это ограничение жёсткое и нам его не убрать и не изменить.

Будем решать штатными средствами RouterOS.

Давайте подумаем вместе, что нам известно о пакете, который попал под ECMP маршрут? Конечно, данный пакет находится в таблице main.

Идея данного способа заключается в следующем. Дать маршрутизатору выбрать маршрут с помощью ECMP, промаркировать такие соединения и все последующие пакеты в этом соединение пускать мимо ECMP, тем самым мы убираем проблему 10 минут.

chain=postrouting - Работаем в цепочке по факту того, что уже выбрал ECMP, можно использовать и цепочку forward, но тогда не попадёт трафик который был сгенерирован самим маршрутизатором.

routing-table=main - Маршрут ECMP находиться в main таблице.

out-interface=ether1 - ECMP выбрал шлюз, который лежит через первый интерфейс

connection-state=new - Мы маркируем соединение, нет смысла работать со всеми пакетами.

action=mark-connection new-connection-mark=ECMP/ether1 - маркируем соединение.

Ещё раз, мы дали возможность ECMP выбрать направление и мы уже по факту промаркировали соединения, основываясь на выборе интерфейса.

А теперь все последующие пакеты в соединениях с такой маркировкой должны быть отправлены в тот же интерфейс, но не в таблицу main, так как там работает ECMP, нам это уже не к чему.

Не забудьте, что трафик смотрится со всех сторон, а нам необходимо только трафик из локальной сети, а так как интерфейсов может быть много, лучше всего отфильтровывать по принципу весь трафик КРОМЕ того который пришёл с интерфейса провайдера.

Осталось настроить NAT

За сим всё, спасибо за внимание.

Удалённая настройка маршрутизатора, к дальней дороге.

Технология MultiWAN позволяет организовать отказоустойчивое соединение с резервированием линков от нескольких провайдеров, а также решает проблему балансировки трафика между резервными линками.

Задача: Настроить маршрут к серверу (108.16.0.1/28) с возможностью балансировки нагрузки.

Рисунок 1 – Схема сети

Решение:

Первым делом создадим лист проверки целостности соединения:

Далее создадим цель проверки:

Указываем адрес для проверки:

Настроем дополнительные параметры проверки (необязательно).

Указываем количество ICMP-запросов, отправляемых за одну проверку:

Указываем максимальное значение отклонения между средней и максимальной задержкой пакета:

Указываем максимальное количество потерянных пакетов:

Указываем период между проверками состояния канала:

Указываем значение средней задержки передачи пакетов:

Указываем ожидания ответа перед объявлением теста ping неудачным:

Включаем проверку и выходим:

Заходим в режим конфигурирования интерфейса te1/0/1, указываем security-zone и IP-адрес:

Указываем список целей для проверки соединения:

Включаем WAN-режим и выходим:

Создадим vlan 150:

Создадим bridge 4, добавим в него vlan 150:

Аналогично как и с интерфейсом te1/0/1 настроим bridge 4:

Добавим vlan 150 на порт te1/0/2:

Создадим правило WAN:

Укажем участвующие интерфейсы, распределим нагрузку по ним (%):

Включим созданное правило балансировки и выйдем из режима конфигурирования правила:

Выйдем из режима конфигурирования и применим изменения:

Для переключения в режим резервирования настроим следующее:

Заходим в режим настройки правила WAN:

Функция MultiWAN также может работать в режиме резервирования, в котором трафик будет направляться в активный интерфейс c наибольшим весом. Включить данный режим можно следующей командой:

Изменения конфигурации вступят в действие после применения:

Технология MultiWAN (подключение к нескольким провайдерам) существует в двух вариантах: распределение нагрузки (Load Balancing), режим основного и резервного канала (Failover).

В этом обзоре мы покажем как в pfSense настроить оба варианта MultiWAN, но для начала несколько ссылок на предыдущие обзоры по теме:

Добавление WAN2

Итак, для реализации MultiWAN в нашем программном роутере должно быть как минимум 3 сетевых карты. Две для WAN и одна для нашей локальной сети. Если вы настраивали pfSense по нашим предыдущим обзорам, то у вас уже должно быть установлено две карточки. Выключаете pfSense, вставляете третью сетевуху, подключаете кабель, включаете комп.

Идем на WEB-интерфейс роутера. Там нам надо проследовать в Interfaces(assign) и добавить третью сетевую карту. Для этого нужно просто-напросто кликнуть мышью по кнопке Add, как показано на скриншоте.

После этого у вас появится еще одна сетевуха с названием OPT1. Главное, не забываем нажать кнопочку Save внизу!

Теперь идем в меню InterfacesOPT1. Ставим галку Enable Interface, затем переименовываем в более понятное название. Я написал WAN2. Далее выбираем тип подключения к интернету в поле Type. Описание всех остальных параметров приводить не будем, т.к. у вас уже должен быть опыт настройки WAN интерфейса из предыдущих обзоров.

По завершению настройки нажимаем Save внизу и Apply Changes вверху.

Проверка настроек

После настройки второго WAN интерфейса идем в меню StatusDashboard и убеждаемся, что все наши интерфейсы подключены и им присвоены IP-адреса.

В зависимости от типа каждого интернет-подключения, шлюзы там могут быть назначены автоматически (в случае ppp, pptp, pppoe, l2tp, dhcp) и вручную (в случае static). Нам важно проверить, что у каждого интерфейса WAN есть свой шлюз (Gateway). Для этого идем в меню SystemRouting. Смотрим на столбец (выделено желтым на скриншоте).

Помимо Gateway есть еще один интересный параметр — Monitor IP. По умолчанию он принимает тоже самое значение что и Gateway. В поле Monitor IP указан адрес, который pfSense постоянно мониторит на предмет доступности через соответствующий WAN интерфейс. Если этот адрес доступен, то pfSense считает, что это подключение к интернету работоспособно. Если недоступен, значит через этот интерфейс нет подключения к интернету. Если у вас какой-либо gateway не заполнен и/или вы хотите поменять значение Monitor IP, нужно нажать на кнопку редактирования напротив нужного WAN подключения.
Статус работоспособности можно посмотреть в меню StatusGateways

Настройка MultiWAN

Настройка MultiWAN выполняется в меню SystemRouting, в закладке Groups. Нажимаем кнопку добавить и в новом окне вписываем следующие параметры:
Group Name — произвольное имя группы MultiWAN.
Gateway Priority — приоритет между WAN интерфейсами. Если для обоих каналов выбрать одно и тоже значение, то MultiWAN будет работать по принципу Load Balancing. Если выбрать разные, то будет работать схема Failover. Основной канал будет с наименьшей цифрой.
Trigger Level — условие перехода с одного канала на другой. Возможные варианты: Member Down (отключение канала), Packet Loss (потери пакетов), High Latency (большие задержки), последний вариант — комбинация предыдущих двух.
Description — описание (необязательное поле)
Я у себя настроил вот так:

Нажимаем Save и затем Apply Changes.
Чтобы локальный службы pfSense, такие как прокси-сервер, антивирус и пр. корректно работали при разрыве одного из интернет-соединений, необходимо в меню SystemAdvance в закладке Miscellaneous установить галку Allow default gateway switching и сохранить это дело, нажатием кнопки Save внизу старницы.

Последнее что необходимо сделать — изменить правила в Firewall, а именно в правилах в качестве шлюза выставить общий шлюз (в своей конфигурации я его назвал MyMultiWAN). Идем в меню FirewallRules, переходим на закладку LAN, нажимаем кнопку редактирования нашего правила

Здесь выставляем Gateway, нажимаем Save и Apply Changes.

Читайте также: