Два интернет-соединения(не бейте, в топика &#
-
В общем так.
Мою схему я где-то тут расписывал. В балансирующий шлюз я вставил 4 карты.
LAN 192.168.1.1 сеть 192.168.1.0/24 - общая сетка, через этот интерфейс ходят избраные приложения с некоторых компьютеров, в нее перенаправлены порты внешних www и почтовика (правильнее, конечно их во вторую подсеть засунуть, но руки пока не доходят)
LAN2 192.168.2.1 сеть 192.168.2.0/24 - Сеть куда смотрит WAN интерфейс машины где squid, и где со временем будут почтарь и www
WAN и WAN2 - собственно, настроены по требованиям провайдеров, между ними балансировка.
Вторая машинка:
LAN 192.168.1.2 сеть 192.168.1.0/24 общая сетка.
WAN 192.168.2.2 сеть 192.168.2.0/24 - выводит на балансировку.
Сквид настроен как transparent. DHCP всем выдает 192.168.2.2 в качестве шлюза по умолчанию, кроме некоторых машин с которых можно бегать в обход напрямую на балансирующий сервер (четко прописано кому, куда и на какой порт, иначе - добро пожаловать через прокси). Дополнительно адрес прокси указан в политике домена.Подружить сквид с мультиваном при балансировке сложно. Там надо лезть в настройку еще и постоянных маршрутов. Причем рыба конфига прописана жестко. То есть если отредактироать правила ручками, прописать маршруты то оно проработает. А в полночь применится конфиг (config.xml) который потрет все файлы с настройками и превратит тачку в тыкву :-
Заморачиваться с переписыванием .php и .xml я не стал, благо списанного барахла было немеряно.Можно, наверно, и без дополнительной подсетки обойтись - правило 1:
"у всего, что идет с IP-squid'ового сервера gateway=loadbalance/failover"
правило 2:
"у всего, что не IP-squid'ового сервера gateway=IP-squid'ового сервера"
Тогда все будут слать на шлюз по умолчанию, тот на сквид (он типа transparent, перехватывает запрос и обрабатывает его) и отсылает опять же на шлюз по умолчанию, но уже от своего имени.
Дальше можно еще сильнее заморочится с портами-айпишниками, но это уже по желанию. -
Понял , но как то не совсем красиво . :)
А можно как то перенаправлять запросы из LAN на прокси находящийся в LAN сегменте ?Как такое правило написать ? И останется ли доступ к веб морде шлюза ?
-
Виноват, конечно, всем выдается шлюз 192.168.1.2 …
И, конечно, через вебмордочку не получится настроить шлюзом адрес из подсети LAN.
Такое нужно прописывать отдельным правилом pf... причем, опять же до полуночи :-
А вот функционированию вебмордочки это не помешает.
И на счет не красиво... практика показала что даже как-то удобно. То есть всяким хитровыдуманым клиентам банков и прочей нечисти прописывается 'route -p add ...' маршруты до серверов этих банков. А все, что идет с прокси дополнительно обрезается на шлюзе, по скорости и прочему. Транспарент сквид обрезает все попытки юзать торренты, качать мыло с внешних ящиков, серфить где ни попадя...
Пока вяло обдумывается идея высадить все это на один сервер в разные VM. Вроде из плюсов - только сокращение проводов, хотя, чем ни занятие, если вдруг случится ситуация "ну совершенно, то есть - абсолютно делать нечего"... -
Понял , но как то не совсем красиво . :)
А можно как то перенаправлять запросы из LAN на прокси находящийся в LAN сегменте ?Как такое правило написать ? И останется ли доступ к веб морде шлюза ?
Попробовать задать на Lan Virtual IP 'other' c адресом вашего прокси
и затем правило outbond NAT src=any dest=!lansubnet port 80 > ВашVirtualIP port proxy
НО перед ним нужно сделать NoNat правило с вашей прокси-машинки в любую сторону на 80 порт.Ну и правила файервола соотв выставить.
Сразу скажу, что я этот вариант не пробовал (у меня бридж), но на тестовой системе формирует правильные нат правила. Единственно что еще может дать косяк - VirtualIP. Вроде-бы other не должен апдейтится в систему в отличии а ARP и Carp. -
Много понял , но вот это не совсем
НО перед ним нужно сделать NoNat правило с вашей прокси-машинки в любую сторону на 80 порт.
Можно разжевать подробнее ? -
Много понял , но вот это не совсем
НО перед ним нужно сделать NoNat правило с вашей прокси-машинки в любую сторону на 80 порт.
Можно разжевать подробнее ?Ну вот смотри - ты делаешь правило натить все обращения наружу на 80 порт из лана к проксевой машинке. Авот ее нужно исключить из списка, чтобы ее не натить. Для этоо перед правилом ната там-же делаем правило для проксевой машины с опцией нонат (src=проксевая тачка dst=any port 80 NONAT)
-
Понял , но в Source можно указать только Network или Any ?
-
network с маской в 32 бита - это собственно хост :)
И еще, нужно не только 80 порт перебросить, но и 443. Лучше завести алиас, куда накидать все порты (для начала 80,443,8080,3128 - соответвтвенно http, https и классические прокси, например, whois-сервис на ripn.net висит на 8080, где-то еще такое встречалось) и потом добавлять-удалять записи в алиас. -
Вводная . Шлюз 192.168.0.110
Прокси 192.168.0.100При указании прокси в настройках браузера всё работает .
А вот при таких правилах ничего не происходит.
Где ошибся ?
-
А прокси прозрачный?
-
Да … прозрачный .
-
А если шлюзом по умолчанию поставить 192.168.0.100 на одной машине и проверить - будет ли интернет?
Если будет - то дело в NAT, если не будет - крутить прокси. -
Ну выставить шлюзом 192.168.0.100 проблем конечно никаких. И всё работать будет .
Но это просто некрасиво. :-\Я прекрасно понимаю что это самое простое решение проблемы . Я понимаю что пользователи этого и не заметят , разве что TTL на 1 изменится .
Но некрасиво .Гуру , помогайте :) С меня коньяк. Найду способ переправить ( я на Урале )
-
rencom
картиночку NAT можно посмотреть? -
rencom
картиночку NAT можно посмотреть?Вложение чуть выше . Или не то ?
Тут ещё интересный факт нарисовался . На машине которая прокси 2 сетевые карты . Lan 192.168.0.100 и WAN 192.168.0.105
Так вот весь трафик который идёт через прокси крутится на LAN интерфейсе . Через WAN ничего не идёт . При этом прокси нормально работает . Как так ?
-
А если добавить в NoNAT оба интерфейса прокси?
То, что используется LAN интерфейс - это нормально. Тоже задавался такими вопросами, потом внимательно просмотрел вывод pfctl -sa и чего-то еще, понял последовательность перенаправлений и думать про такое забыл. Кстати, может WAN интерфейс откнуть в пустой свитч? Просто чтоб состояние было "up", а пакеты кругами не ходили. Работать будет - проверено.
Кстати, а почему Вы сделали NoNAT с LAN адреса прокси, если ожидали, что траффик пойдет через WAN интерфейс?