Интересно. Вот мы не можем больше одного канала пустить, казначейство не дает добро.
LinuxForum.Fans
openSUSE шлюз и маршрутизатор для 3 каналов интернет
Автор: Elrik12
37 сообщений
21276 просмотров
Попробуйте проверить раздельно.
1. Остановите сквид и припишите внутренние сети к таблицам, как в примере. Проверте с помощью traceroute по каким маршрутам из внутренних сетей ходят пакеты. Если результат - "то, что надо" - значит в скрипте вы не накосячили и дополнительные таблицы работают.
2. Очистите результаты работы скрипта (ip rule del from .... и ip route flush table...). Запустите сквид и попробуйте проверить работу "tcp_outgoing_address" так сказать в чистом виде....
Все дело в том, что по идее сам шлюз при обращении к сети (а при работе через сквид в сеть ходит он сам) пользуется только одной таблицей (main) - там все правила уже есть (но шлюз по умолчанию - только один), при этом пакеты по интерфейсам по идее должен сам сквид разруливать, который о доп. таблицах ничего не знает... и возможно они тогда вообще не нужны... Вы же из внутренних сетей не в инет ломитесь, а на порт прокси (он-же у вас "не прозрачный" - судя по правилам фаервола) . То-есть они нужны только для того трафика, который идет мимо сквида...
to UTiM
Т.е. может быть все дело в "не прозрачности" сквида?
Я думал сквид при использовании "tcp_outgoing_address" шлет пакеты от соответствующего адреса ip, а далее все равно маршрутизация должна работать. Иначе, как пакеты узнают как попасть в конкретную сеть?
Привожу еще выводы "route -n", "ip ro" и "ip ru":
route -n:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
80.242.156.56 0.0.0.0 255.255.255.252 U 0 0 0 eth2
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.8.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
ip ro:
80.242.156.56/30 dev eth2 proto kernel scope link src 80.242.156.56
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.10
10.8.0.0/16 dev eth1 proto kernel scope link src 10.8.5.14
169.254.0.0/16 dev eth0 scope link
127.0.0.0/8 dev lo scope link
ip ru:
0: from all lookup local
32764: from 80.242.156.56 lookup provider_2
32765: from 10.8.5.14 lookup provider_1
32766: from all lookup main
32767: from all lookup default
Вывод tracert c клиента (идем к google.ru):
Трассировка маршрута к 74.125.87.104 с максимальным числом прыжков 30
1 192.168.0.10 сообщает: Заданная сеть недоступна.
Трассировка завершена.
traceroute с шлюза выдает тоже самое.
... при этом пакеты по интерфейсам по идее должен сам сквид разруливать, который о доп. таблицах ничего не знает... и возможно они тогда вообще не нужны... Вы же из внутренних сетей не в инет ломитесь, а на порт прокси (он-же у вас "не прозрачный" - судя по правилам фаервола) . То-есть они нужны только для того трафика, который идет мимо сквида...
...Еще подумал...
Я так понимаю, сквид вобще не имеет понятия об "интерфейсах" как таковых. Он просто слушает входящие сообщения на указанном адресе+порту и отправляет исходящие на указанный адрес+порт. А уже то каким образом пойдут пакеты (и на какой интерфейс) занимается iptables/firewall, т.е. маршрутизация. Или я что-то не так понимаю? Сразу оговорюсь, что я в маршрутизации не силен, да и линукс изучаю сравнительно не долго. Так что, особо круто не заворачивайте ;)
Кстати, да, прокси у меня действительно не прозрачный - планирую использовать для фильтрации контента и разграничения по пользователям.
to UTiM
Я думал сквид при использовании "tcp_outgoing_address" шлет пакеты от соответствующего адреса ip, а далее все равно маршрутизация должна работать. Иначе, как пакеты узнают как попасть в конкретную сеть?
Узнает ядро по адресу источника (или метке ip-таблеса) и разруливает в соответствии с привязками к таблицам маршрутизации ( привязка - ip rule add from $NET_LOCAL table $TS) У вас-же источником служит сам шлюз, точнее его прокси - соответственно он или привязывается к дефолтной таблице main... или занимается маршрутизацией сам (а не ядро) в соответствии с "tcp_outgoing_address"
Вообще, если вы только "планируете" использовать прокси - то сделайте хотя-бы пока простую маршрутизацию, как в примере - убедитесь, что работает - а потом уже будете развлекаться со сквидом....
Кстати, по вашим правилам фаервола из внутренней сети ходить в инет можно всем напрямую, без всяких прокси. По идее, чтобы заставить юзеров ходить через него надо или "прямые" сервисы прикрывать или делать прокси "прозрачным".
У вас-же источником служит сам шлюз, точнее его прокси - соответственно он или привязывается к дефолтной таблице main... или занимается маршрутизацией сам (а не ядро) в соответствии с "tcp_outgoing_address"
Здесь можно подробнее?
Кстати, по вашим правилам фаервола из внутренней сети ходить в инет можно всем напрямую, без всяких прокси. По идее, чтобы заставить юзеров ходить через него надо или "прямые" сервисы прикрывать или делать прокси "прозрачным".
Может просто маскарадинг выключить или это для прокси требуется...?
Да, насчет "прозрачности" - надо будет сделать, правда нужно настройки всех клиентов менять.
Здесь можно подробнее?
Т.е точнее не "привязывается" , а использует дефолтную таблицу...
Ну а поподробнее - это к "первоисточникам".... я в меру своего понимания, так сказать... могу и "честно заблуждаться"
Может просто маскарадинг выключить или это для прокси требуется...?
Для прокси - не требуется. Требуется только для служб, которые не могут работать через прокси и чтобы не светить "локальные" ip в других сетях. Хотя при включенном фаерволе - по умолчанию и так - никто никуда не ходит (что не разрешено - то запрещено).
Да, насчет "прозрачности" - надо будет сделать, правда нужно настройки всех клиентов менять.
А вот тут на ваше усмотрение. При прозрачном прокси у юзеров нет необходимости что-либо настраивать - фаервол сам перенаправляет нужный трафик на прокси, но авторизация и учет трафика (как минимум - придется всем раздать статические IP) будут затруднены. Но если от прокси требуется только кэширование и фильтрация трафика - это наш метод. При "непрозрачном" доступны все методы авторизации (фиксация IP-шников не требуется), но придется во всех юзерских прогах прописывать прокси...
Все равно ничего не получается... Хрень какая-то! Уже пробовал "rp_filter". Настраивал со сквидом и без сквида. Прописывал какую-то левую маршрутизацию..... Что за..??
Прописывал какую-то левую маршрутизацию..... Что за..??
Не горячитесь. Не пытайтесь сразу все свалить в кучу. Попытайтесь понять, что вы делаете. Действуйте последовательно.
Для начала верните все в исходное состояние. Отключите сквид очистите таблицы и правила, для надежности - лучше перезагрузится. Далее действуйте ПОШАГОВО, на каждом шагу проверяя полученный результат - если не получается НЕ ДВИГАЙТЕСЬ ДАЛЬШЕ - пока не поймете причину.
1. Укажите на шлюзе (в графической настройке сети) шлюз "по умолчанию" - любой из двух имеющихся и ДНС-ы для него.
2. В SuseFirewall укажите интерфейсы по зонам, включите маршрутизацию и NAT на внешнй зоне, разрешите внутренней сети ходить через NAT. Пока все будут ходить через "шлюз по умолчанию" обязательно проверьте, что это работает. (с клиентских машин!)
3. Возьмите скрипт http://linuxforum.ru/viewtopic.php?pid=4784#p4784 и настройте его НА ОДИН ИНТЕРФЕЙС, ОТЛИЧНЫЙ ОТ УКАЗАННОГО ДЛЯ ШЛЮЗА ПО УМОЛЧАНИЮ. (просто пока закомментируйте лишнее) Запустите. Не забудьте привязать к нему свою внутреннюю сеть и прописать таблицу в файле /etc/iproute2/rt_tables Проверьте ( traceroute в помощь) что внутренние машины ходят теперь через другой интерфейс (не "по умолчанию").
4. Добавьте в скрипт вторую таблицу и настройки для интерфейса. Привяжите к ней часть машин (последняя привязка - имеет больший приоритет - см скрипт) Запустите скрипт, проверьте результат.
5. Далее эксперементируйте со сквидом, сначала попробуйте прозрачно перенаправить на него трафик по одному порту (FW_REDIRECT=....) Убедитесь, что работаете теперь именно через сквид (wireshark на шлюзе вам в помощь)
6. Пробуйте, теперь направить (tcp_outgoing_address с компанией) разных клиентов по разным интерфейсам (wireshark) - я лично так никогда со сквидом не делал и не могу гарантировать что оно на данной версии сквида работает - но по крайней мере это будет понятно.
7. Если "прозрачный" сквид работает как надо, то если хотите - можете делать его "не прозрачным", поднимать авторизацию и закрывать части сервисов "прямой" выход в инет.
А вот такой вопрос: может ли сервер/шлюз определять dns через одного провайдера (дефолтный шлюз в таблице main), а tcp-запросы пересылать через другого (шлюз из доп. таблицы; по "tcp_outgoing_address" скида)?
А вот такой вопрос: может ли сервер/шлюз определять dns через одного провайдера (дефолтный шлюз в таблице main), а tcp-запросы пересылать через другого (шлюз из доп. таблицы; по "tcp_outgoing_address" скида)?
Вам мало DNS-ов? wink
Нет смысла извращатся (заставлять шлюз ходить чарез собственный прокси - для этого сама клиентская программа должна минимум уметь работать через прокси)
Смотрите пример (с соотв. комментарием) - маршруты до днс-ов можно прописать жестко в main, поскольку мы заранее знаем и их адреса и на каких именно интерфейсах они сидят. В противном случае - для "непрописанного" используется шлюз "по умолчанию" - то есть до днс-сов "второго" провайдера вы будете ходить, но через "первого".
А что бы не прописывать эти днсы юзерам и в доп таблицы - рекомендуется поднять собственный DNS на шлюзе, и указать его пользователям, а уже с него "дергать" провайдерские...
Я бы предложил поднять 3 виртуальных машины с проксёй и каждую посадить на свой канал.
А не проще бы поднять vlan? Маршрутизатор хоть dir 100 и с него разруливать на vlan (способ проверен)
Остальное читать не выносимо вынос мозга).
Как я вижу себе задачу сервер 4 сетевые.
3 сетевые это инет. 4 подключён к dlink dir 100 к wan порту остальные порты 3 (по отделам то есть подсети).
На длинк поднять vlan каждому отделу по 1 vlan. На linux тоже поднимаем виртуальные интерфейсы.
После создаём трубы (iproute2) и уже с iptables посылаем траффик в нужное нам коромысло.
На счёт dns можно поставить свой кеширующий.
[quote=Loky]Я бы предложил поднять 3 виртуальных машины с проксёй и каждую посадить на свой канал.
А не проще бы поднять vlan? Маршрутизатор хоть dir 100 и с него разруливать на vlan (способ проверен)
Остальное читать не выносимо вынос мозга).[/quote]
Нет, мы не ищем легких путей.... Даешь пять виртуальных машин со сквидами, восемь vlan-нов и еще цисковским маршрутизатором сверху лакернуть (а что, делинк - какой то - фу - не солидно :D ) А что, работать то в принципе будет.... wink
На фиг киску) на такою мелочь)))) Если работать с циской на фига тогда linux smile
Как вам нравиться всякие прокси в жизни не буду за ними сидеть гадость).
Кажется дело тронулось! В сквиде ставлю "udp_outgoing_address 80.242.156.56" и все работает! Т.о. сквид берет dns'ы из сети второго провайдера. Выходит первый провайдер как-то хитро блокирует dns-запросы (до этого шло через дефолтный шлюз первого провайдера).
Кажется дело тронулось! В сквиде ставлю "udp_outgoing_address 80.242.156.56" и все работает! Т.о. сквид берет dns'ы из сети второго провайдера. Выходит первый провайдер как-то хитро блокирует dns-запросы (до этого шло через дефолтный шлюз первого провайдера).
Ну так зачем все таки заставлять юзеров запрашивать разные DNS-ы через сквид (причем, у разных провайдеров)? Чем вам не нравится кэсширующий DNS на шлюзе - и пользователям однообразно, и ускорение, и маршруты к провайдерским просто в main прописываются и указываются (все четыре) как источники для вашего. Поймите - если шлюз "упал" вам наличие альтернативных DNS-сов ну совершенно не поможет...
Войдите или зарегистрируйтесь, чтобы ответить.
