top
logo


pfSense 2.0 RC1: Squid и Multi-WAN на одной машине PDF Печать E-mail
Автор: adm   
09.09.11 10:06

pfSense 2.0 RC1: Squid и Multi-WAN на одной машине

 

Благодаря Ermal и Heper, в pfSense 2.0 решена проблема сосуществования Squid с Multi-WAN в одной системе. В 1.2.3, напомню, это было известной проблемой. Squid всегда шел в инет через default gateway и свернуть его с этого пути было невозможно.

Оригинальный топик: http://forum.pfsense.org/index.php/topic,33895.0.html

Здесь привожу инструкцию как я ее понял (многое мне показалось лишним)
Все делалось в виртуальных машинах, поэтому настройки сети получились... какие получились:

WAN1: 192.168.0.240/24  GW: 192.168.0.1
WAN2: 10.0.0.3/8  GW: 10.0.0.1
LAN: 192.168.10.1/24

  • Настраиваем Multi-WAN.
  • Нужно сказать, что по сравнению с 1.2.3 в 2.0 все изменилось. Привожу только скриншоты. Надеюсь, все будет понятно. Почитать можно здесь: http://forum.pfsense.org/index.php/topic,10407.0.html




System -> Routing -> Gateways

 

В ситуации если вы не используете Squid, достаточно зайти и поставить галку

System -> Advanced -> Miscellaneous -> Allow default gateway switching


 

  • Настройка Squid:
    Вставляем "tcp_outgoing_address 127.0.0.1" в поле Custom Options



  • Настройка Outbound NAT.
    Ermal сказал, что он сделал специальный патч для автоматической трансляции подсети 127.0.0.0/8. Так что, если вы используете Automatic outbound NAT rule generation, то по идее вам ничего делать не нужно. Однако, если вы используете Manual Outbound NAT rule generation, вам придется кое что добавить:



  • Настройка Firewall
    Добавляем правило во вкладке Floating:



    Подробности:



    Все ключевые пункты отмечены красными цифрами. Все они, кроме 3-го, 6-го и 8-го, должны быть выставлены как на картинке. В 8-ом вы выбираете одну из групп шлюзов в зависимости от того, чего хотите добиться. 3-й и 6-й можно в принципе вообще не трогать и оставить там то, что стояло по умолчанию при создании правла (т.е. интерфейс не выбран, адрес источника - любой). Просто установки изображенные на картинке, кажутся мне более правильными. Ниже напишу почему.

Собственно, все!


SQUID

Это упрошенная схема движения пакетов на выходе из pf (OpenBSD Packet Filter используемый в pfSense). Нормально Squid шлет исходящие наружу пакеты 1) с source IP = default WAN IP и 2) шлет их именно через default WAN и default gateway. То, что мы прописали "tcp_outgoing_address 127.0.0.1" в поле Custom Options, меняет только первое (source IP становится равным 127.0.0.1) но не меняет второго. Даже если основной WAN интерфейс будет лежать, пакет от Squid все равно полетит через него. Вот почему, в отличие от руководства Heper'а, в п.3 правила (см. "Настройка Firewall" в предыдущем посте) я выбираю WAN1. Мимо него пакет не пролетит, зато с такой установкой правило не будет срабатывать на других интерфейсах. Далее в блоке NAT source IP будет опять преобразован из 127.0.0.1 в WAN1 IP. Затем в блоке filter сработает наше правило и если в результате пакету будет назначен другой шлюз  (допустим основной WAN1 лежит, а дополнительный - жив), пакет будет премаршрутизирован и опять начнет свое путешествие по той же цепочке, но уже на другом интерфейсе.
В чем фишка "tcp_outgoing_address 127.0.0.1" если после NAT на WAN1 он все равно преобразуется в WAN1 IP и для блока filter выглядит так же как будто его послал Squid без всяких Custom Options? В том, что оригинальный pf модифицирован Ermal'ом специально для pfSense. Поэтому, глядя на диаграму выше, понять ничего нельзя. Фактически же, после того как наше правило назначает пакету другой шлюз и при перебросе пакета в выходную цепочку OPT-WAN происходит еще и обратная трансляция source IP. Т.о. на OPT-WAN пакет появляется как будто ничего и не было, с адресом источника 127.0.0.1, натится, фильтруется и заводится state связывающий squid и удаленный хост именно через OPT-WAN.

 

Большое спасибо за описание.
Единственный нюанс: потребовалось поставить галку на System -> Advanced -> Miscellaneous -> Allow default gateway switching. Остальной трафик и без неё уходил на резервный канал, а вот Squid никак не хотел и ругался "no such route".

 

Добавлено!

Еще хочу рассказать как я криво-косо распределил юзеров по каналам. Балансировка каналов, когда вместо WAN1FailsToWAN2 вы ставите LoadBalance, не есть хорошая идея, т.к. некоторые сайты (яду им!) такого не переносят. В частности mail.ru не дает скачать вложения из письма. Ну понятно, вы зашли с одного IP, а вложение тянете с другого. Тут-то у mail.ru и происходит короткое замыкание и паралич головного мозга.
Так вот, решил я тогда рассадить юзеров по каналам, чтобы оба канала работали в полную силу. Половину юзеров пустить через WAN1FailsToWAN2, а другую - через WAN2FailsToWAN1. Проблема тут в том, что после squid'а никаких юзеров уже нету, а запрос в инет летит от имени localhost (tcp_outgoing_address 127.0.0.1). Кто из юзеров попросил squid залезть на этот сайт не ясно от слова "совсем".
Решение придумал такое:
Сделал в /var/squid/acl два файла: w1w2.acl и w2w1.acl. В первый запихал все нечетные адреса локалки, во второй - все четные.
В Services -> Proxy server -> General -> Custom Options в самое начало вместо tcp_outgoing_address 127.0.0.1 вставил такое:

acl w1w2 src "/var/squid/acl/w1w2.acl";
acl w2w1 src "/var/squid/acl/w2w1.acl";
tcp_outgoing_address 127.0.0.1 w1w2;
tcp_outgoing_address 127.0.0.2 w2w1;

(переносы строк только не нужны)
т.е. половина локалки из squid'а вылетает с адресом источника 127.0.0.1, вторая - с 127.0.0.2
ах да, 127.0.0.2 нету, надо сначала завести:

ifconfig lo1 create 127.0.0.2

И вот (смотрим рисунок во втором посте топика) что-то делать с летящими из squid'а пакетами мы можем только в блоке nat и блоке filter. Причем, - опять беда - в nat никак не воткнешь policy routing, а filter, который policy routing умеет, после ната уже не видит ни 127.0.0.1 ни 127.0.0.2, а видит только WAN1 IP в адресе источника пакета. Т.е. надо добиться, чтобы после блока nat пакеты от 127.0.0.1 и 127.0.0.2 были еще хоть как-то различимы. Ну я не нашел ничего лучшего чем различать их по диапазону портов источника.
В Firewall -> NAT -> Outgoing у нас было:

WAN1      127.0.0.0/8    *    *    *    *    1024:65535    
WAN2      127.0.0.0/8    *    *    *    *    1024:65535

а стало:   

WAN1      127.0.0.1/32    *    *    *    *    1024:33279
WAN1      127.0.0.2/32    *    *    *    *    33280:65535

WAN2      127.0.0.0/8    *    *    *    *    1024:65535   

Половине локалки натом порт источника выбирается из диапазона 1024:33279, второй - из диапазона 33280:65535. Это по честному, по пионерски.
Теперь в блоке filter мы можем их различить и отправить по разным каналам. Идем в Firewall -> Rules -> Floating, где у нас уже есть правило:

TCP    WAN1 address    *    *    80 (HTTP)    WAN1FailsToWAN2    none

открываем его для редактирования и в Source port range делаем from:1024, to:33279, сохраняем и принимаем изменения
кнопочкой "+" дублируем правило и ставим в Source port range from:33280, to:65535, а в Advanced features -> Gateway выбираем WAN2FailsToWAN1, сохраняем и снова принимаем .5 Grolsch Premium Lager



оригинал: http://forum.pfsense.org/index.php/topic,34810.0.html

ссылка на статью: http://thin.kiev.ua/index.php?option=com_content&view=article&id=411:squidmulti-wan-&catid=50:pfsense&Itemid=81

{jcomments on}

Последнее обновление 05.09.12 15:20
 
Интересная статья? Поделись ей с другими:

bottom

 

Unreal Commander PfSense по русски Яндекс.Метрика