Доброго всем времени суток!
Сразу прошу, не посылайте в хендбук, его уже пролистал, так же, не предлагайте сменить работы или нанять админа... Если я обратился сюда, то я этого не знаю но хочу узнать, а не нанимать кого бы то нибыло...
Вообщем суть проблемы.
имеем:
Сервер 1 - Gate
Сервер 2 - Host
Локальная сеть - Lan
Провайдер 1 - ISP1
Провайдер 2 - ISP2
Gate выполняет функцию шлюза, у него 2 сетевые карты, одна на провайдера, вторая в локалку. Имеет "белый" IP.
Host выполняет функцию веб-сервера и почтового сетвера. У него так же 2 сетевые, одна в эту же локалку а одна на второго провайдера и тоже с "белым" IP.
Gate и Host соединены между собой локальной сетью.
На Host стоит в качестве Defaultrouter, шлюз провайдера.
Host отвечает на все запросы на "белый" IP, всё как бы нормально, но канал узковат, посему мне нужно, чтобы он отвечал на запросы, которые приходят на 80-й порт Gate.
Я по средствам PF пробросил порт 80 на Gate. tcpdump-ом смотрю, запросы приходят на Host всё норм, но обратно не уходят.
tcpdump показывает только:12:28:27.877338 IP 212.220.42.55.11314 > 192.168.0.3.http: Flags [S], seq 3094014790, win 5840, options [mss 1356,sackOK,TS val 2866690 ecr 0,nop,wscale 6], length 0
Я так понимаю, что Host пытается отправить пакет не через тот канал, с которого пришло, а через свой. Но это не есть гуд.
На Host подгружены в качестве модуля pf и ipfw
В инете натыкаюсь на реализацию, но для маршрутизации двух подсетей в разные каналы через один щлюз, а подобной моей реализации нигде не встречал:(
Прошу Вас друзья помочь с реализацией. 3 дня уже мучаюсь, испробовал всё что можно, но так и не могу заставить работать...
P.S. да, забыл совсем:
Gate:
# uname -a
FreeBSD gate.mydomen.com 8.2-RC3 FreeBSD 8.2-RC3 #0: Tue Feb 8 10:06:25 YEKT 2011 nops@gate.mydomen.com:/usr/src/sys/i386/compile/kernel i386
Host:
# uname -a
FreeBSD mail.novour.com 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Tue Dec 8 02:04:59 UTC 2009 root@freebsd8-i386.ispsystem.net:/usr/obj/usr/src/sys/kernel.isp i386
2 пути1. FIB (если ядро собрано с этой фичей)
http://www.freebsd.org/cgi/man.cgi?query=setfib&sektion=1&ap...в fib 2 делаете шлюз по умолчанию на Gate
и добавляете на Host правило ipfw
ipfw add X setfib 2 tcp from 192.168.0.3 80 to any
2. Либо на Host используете FWDipfw add X pass tcp from 192.168.0.3 to any out via LocalIf
ipfw add X+1 fwd Gate tcp from 192.168.0.3 80 to anyну и чтобы Gate с этим пакетом правильно поступил, т.е. завернуть его в нат, чтобы он его отправил наружу
> 2 пути
> 1. FIB (если ядро собрано с этой фичей)
> http://www.freebsd.org/cgi/man.cgi?query=setfib&sektion=1&ap...
> в fib 2 делаете шлюз по умолчанию на Gate
> и добавляете на Host правило ipfw
> ipfw add X setfib 2 tcp from 192.168.0.3 80 to anyК сожалению сейчас ядро пересобирать нет возможности... к тому же я не знаю что такое FIB:(
> 2. Либо на Host используете FWD
> ipfw add X pass tcp from 192.168.0.3 to any out via LocalIf
> ipfw add X+1 fwd Gate tcp from 192.168.0.3 80 to any
> ну и чтобы Gate с этим пакетом правильно поступил, т.е. завернуть его
> в нат, чтобы он его отправил наружуПеревожу на русский и простой, поправьте, если я не прав:
ipfw add Х_номер_правила pass tcp from 192.168.0.3 ti any out via интерфей_локальной_сети
ipfw add Х_номер_правила+1 fwd Gate tcp from any to any
в первом мне только не понятно LocalIf, это сетевая, которая смотрит в сторону шлюза?
ну а в остальном мне всё понятно.
Сейчас попробуй))) Хуэе всё равно не будет уже:)
>> 2. Либо на Host используете FWD
>> ipfw add X pass tcp from 192.168.0.3 to any out via LocalIf
>> ipfw add X+1 fwd Gate tcp from 192.168.0.3 80 to any
>> ну и чтобы Gate с этим пакетом правильно поступил, т.е. завернуть его
>> в нат, чтобы он его отправил наружувообщем я добавил в /etc/rc.firewall
[root@mail /etc]# cat /etc/rc.firewall
#!/bin/sh -
f='/sbin/ipfw'
${f} -f flush
${f} add 10 pass tcp from 192.168.0.3 to any out via em0
${f} add 11 fwd 192.168.0.1 tcp from 192.168.0.3 80 to any
Здесь:
192.168.0.1 - IP шлюза Gate
192.168.0.3 - IP этого сервера Host, который смотрит на шлюз.
em0 - сетевая, которая смотрит на шлюз(внутренняя сетевая)Проблема не решилась, всё равно, при обращении на IP шлюза, вообще ничего не открывается:(
Мужик! Поиск для кого на форуме существует? Жмакаешь на поиск и вкалачиваешь - два канала в интернет freebsd, получаешь кучу ссылок с этой темой на форуме, идешь на те, где стоит 5-6 звездочек, то есть там проблема или решена или в них есть ссылки на хорошие статьи. Например одна из них
http://www.opennet.me/openforum/vsluhforumID1/77062.html
Там я давал ссылки на статьи по твоей теме из журнала "Системный администратор" от Сергея Супрунова. И еще ссылочка там есть. Если ссылки на журнал протухли, то зайди на сайт самого журнала - http://www.samag.ru и там поищи в теме Архивы статей, на старые номера и статьи там запрета нет, только на свежие номера за последние полгода. Тебее нужен «Системный администратор» (Февраль, 2007). Впрочем вот тебе прямая ссылка
http://www.samag.ru/cgi-bin/go.pl?q=articles;n=02.2007;a=09
>[оверквотинг удален]
> хорошие статьи. Например одна из них
> http://www.opennet.me/openforum/vsluhforumID1/77062.html
> Там я давал ссылки на статьи по твоей теме из журнала "Системный
> администратор" от Сергея Супрунова. И еще ссылочка там есть. Если ссылки
> на журнал протухли, то зайди на сайт самого журнала - http://www.samag.ru
> и там поищи в теме Архивы статей, на старые номера
> и статьи там запрета нет, только на свежие номера за последние
> полгода. Тебее нужен «Системный администратор» (Февраль, 2007). Впрочем вот
> тебе прямая ссылка
> http://www.samag.ru/cgi-bin/go.pl?q=articles;n=02.2007;a=09Уважаемый, там не тот случай, и примеры из журналов тоже не подходят. Читал уже.
Если Вы не поняли, то мне не надо маршрутизировать 2 подсети через разных провайдеров.
Мне нужно, чтобы одна машина, имея два канала в интернет, отвечал на запросы, пришебдие от обоих провайдеров.
т.е. чтобы ответ на запрос, пришедший от ISP1, улетал через ISP1, а пришедший от ISP2, уходил к ISP2.
нюанс ещё в том, что у одного провайдера белый IP, а у другого серый
для особо страждующих кратко отвечаю: в поставленных условиях задача не разрешима.Теперь объяснение:
Разберем на примере службы - например http-сервер(порт 80).
Итак у нас есть сервер с 2 каналами в Интернет и висящим веб-сервером на обоих интерфейсах.
Например это будет:
ISP1: интерфейс eth1, ip=1.1.1.1
ISP2: интерфейс eth2, ip=2.2.2.2пусть приходит к нам на первый адрес пакет:
выглядеть будет так
SRC_IP:>1024 -> 1.1.1.1:80окей - он обработается веб-сервером и вернется ответ в виде:
1.1.1.1:80 -> SRC_IP:>1024заметим что нигде вообще не фигурирует интерфейс никоим образом. Далее наш сервер подумает а куда же мне направить пакет у которого DST_IP = SRC_IP - обратившись к таблице маршрутизации выберет нужный интерфейс и канал.
К большому сожалению в IP_header отстутсвует информация об интерфейсе - и следовательно узнать а куда же нам рулить пакет когда он уже вернется к нам после обработки службой выше IP не представляется взможным.
Спасибо за внимание.
классическое решение данной проблемы это динамическая правка таблицы маршрутизации - чем собственно говоря и занимается протокол BGP
> классическое решение данной проблемы это динамическая правка таблицы маршрутизации - чем
> собственно говоря и занимается протокол BGPиди книжки почитай, прежде чем советы/ответы писать.
спасибо за совет:) стараюсь им не пренебрегать:)
по поводу BGP. Я в своё время прочитал книжку по BGP. Рекомендую и тебе - называется "Маршрутизация в Интернет".Пойди и ознакомься что же такое протокол BGP, зачем он нужен и как применяется.
> по поводу BGP. Я в своё время прочитал книжку по BGP. Рекомендую
> и тебе - называется "Маршрутизация в Интернет".
> Пойди и ознакомься что же такое протокол BGP, зачем он нужен и
> как применяется.BGP к данному вопросу вообще не применим. Я даже дискутировать на эту тему не собираюсь, ибо слово BGP и DNAT в данном случае совершенно несовместимы.
> классическое решение данной проблемы это динамическая правка таблицы маршрутизации - чем
> собственно говоря и занимается протокол BGPВообщем, исходя из ваших слов, то такое без BGP не возможно...
Тогда скажите, неужели нельзя пометить пакет и завернуть согласно метке? Пускай это будет не IPFW, пускай это будет PF NAT.
Так или иначе, мне нужно, чтобы пакет пришебный на серый адрес с белого ИПа, отправлялся так же через этот же серый адрес...
я скажу даже больше - такое поведение даже с BGP невозможно.А та задача которую вы ставите не решается в принципе.
Для реализации высокой доступности сервисов - делается так:
1) покупается сеть ipv4
2) покупается AS(автономная система)
3) поключаетесь к более чем 1 ISP(например к 2м)
4) настраиваете BGPBGP анонсирует ваш блок адресов в мир - и внешние роутеры вас видят по вашей анонсированной сети. Далее bGP продолжает анонсы через оба апстрима в мир если всё нормально. Если один линк рвётся - то линк BGP тоже рвётся и соответсвенно префикс что вы анонсируете перестаёт быть для мира доступным через сломанный линк. Роутеры всего ИНтернета в этот момент начинают перестраивать свои таблицы маршрутизации чтобы пропустить трафик на ваш префикс через оставшийся канал.
Но даже при поломке одного из каналов достпуность вашей сети будет продолжена через оставшийся линк - при этом всё это произойдёт автоматически. Даже пинги не теряются:) ну и естесственно своему любимому серверу вы присвоете адрес из этой сети и он будет всегда доступен по этому адресу пока хотя бы 1 канал работает.
> Для реализации высокой доступности сервисов - делается так:
> 1) покупается сеть ipv4
> 2) покупается AS(автономная система)
> 3) поключаетесь к более чем 1 ISP(например к 2м)
> 4) настраиваете BGP... А теперь просьба - можно привести цифры - только все суммы - как однократные так и постоянные (пусть и ориентировочные) - если для моего предприятия достаточно "выпустить в свет" серверный пул из 10 ip-адресов ... ? Нет, может быть Вы и правы, и сможете с цифрами в руках переубедить нас, что большинство организаций, испытывающих необходимость в "сервисах высокой доступности" - не готовы к таким затратам ...
to YuST:Почему я упомянул про именно покупку - потому что официально получить бесплатно адреса возможно но сложно через RIPE - т.к. они кончаются. Проще купить.
Минимальный блок адресов для анонса = /24 (т.е. 256 адресов) - т.е. вам нужен именно минимальный блок.
Также будет нужен роутер с поддержкой BGP. Слышал про opensource-программные решения Quagga/Zebra - но сам с ними не работал - за качество работы не скажу. Т.к. специализируюсь на Cisco. Но quagga/zebra в итоге вообще бесплатны.
мы для своей конторы закупали адреса у http://www.ipaddr.ru/(не сочтите за рекламу). По ценам указанным на их сайте. Как в данный момент дела обстоят с ценами в связи с окончанием адресного пространства не в курсе - не мониторю ситуацию.
> я скажу даже больше - такое поведение даже с BGP невозможно.Ну вот, уже согласен что BGP неприменим, а меня книжки по BGP читать отправил.. Нехорошо получилось )
to sm00th1980 :
- теория TCP/IP сетей - 5 баллов
- практика FreeBSD - м... - Вы не обижайтесь, но "кол"Как уже говорили ранее - поставленная задача имеет - ИМХО - два варианта решения:
- первый вариант - сборка ядра с "options ROUTETABLES=ХХ" и последующие использование (например) и ipfw конструкций типа:
setfib 1 ip from 192.168.0.0/24 to any in recv em0
setfib 1 ip from any to 192.168.0.0/24 out xmit em0
setfib 0 ip from table(1) to any
setfib 0 ip from any to table(1)
в setfib 0 - default gw - провайдер № 1, в setfib 1 - default gw - провайдер №2... Все хосты, описанные в таблице (ipfw) 1 идут через провайдера №1, остальные - через провайдера № 2... В ЛЮБУЮ сторону - как исходящий, так и входящий трафик ...- второй вариант - может состоять в вдумчивом раскуривании связки ipfw-fwd, keep-state - check-state - established - смысл в том, что-бы при первом обращении к внутреннему хосту - создать правильное динамическое, двухсторонее правило, по которому и пройдут дальнейшие пакеты ...
да про multiple routing tables я и забыл. Щас попробую собрать стенд для проверки.
Самому интересно:)
> Доброго всем времени суток!
> Сразу прошу, не посылайте в хендбук, его уже пролистал, так же, не
> предлагайте сменить работы или нанять админа... Если я обратился сюда, то
> я этого не знаю но хочу узнать, а не нанимать кого
> бы то нибыло...Если бы ты хотел узнать, ты бы пошел в гугл и занялся поиском, потом начал бы думать, экспериментировать, анализировать, и т д ..
.
>> Доброго всем времени суток!
>> Сразу прошу, не посылайте в хендбук, его уже пролистал, так же, не
>> предлагайте сменить работы или нанять админа... Если я обратился сюда, то
>> я этого не знаю но хочу узнать, а не нанимать кого
>> бы то нибыло...
> Если бы ты хотел узнать, ты бы пошел в гугл и занялся
> поиском, потом начал бы думать, экспериментировать, анализировать, и т д ..
> .Уважаемый, а вы думаете что я к вам пришёл от того, что мне лень искать по гуглу?
Спрашивал у гугла, но я не знаю как именно сделать и завернуть..... в силу отсутствия опыта. Вы ведь тоже не знали этого когда-то, так помогите узнать нуждающемуся...
Если я понял что это PBR, то наверное я не из головы придумал, верно?!
Гугл не помог, в соновном ссылки на одну и туже статью, расплодившуюся по инету тупым копипастом, надоело уже читать одно и тоже:(
Подобной реализации нигде не встретил.
Help Me Please!!!
>> Доброго всем времени суток!
>> Сразу прошу, не посылайте в хендбук, его уже пролистал, так же, не
>> предлагайте сменить работы или нанять админа... Если я обратился сюда, то
>> я этого не знаю но хочу узнать, а не нанимать кого
>> бы то нибыло...
> Если бы ты хотел узнать, ты бы пошел в гугл и занялся
> поиском, потом начал бы думать, экспериментировать, анализировать, и т д ..
> .Если очень сильно хочется сделать решение поставленной задачи, то придется заменить фряху на линух. У линуха есть возможность маркировки _соединений_.
дело не в линуксе и не во freebsd - дело в самом протоколе IP и процессе маршрутизации. Информация о втором уровне L2 на L3(IP) не присутствует совсем. И никакая маркировка не поможет в этом. Т.к. она осуществляется на IP уровне а с верхних уровней пакет ответа приходит на 3-ий девственно чистым без меток на основании которого мы могли бы его отправить в тот или иной канал.
Коллеги, если всё-таки охота подискутировать на данную тему то не вопрос.
Предлагаю через skype: sm00th1980
Да коллеги, подтверждаю был не прав.Есть как минимум 1 рабочее решение.
Два входящий интерфейса:
em0: ip=192.168.0.2
em1: ip=192.168.1.2Описываю ход решения:
1)Нужно сделать 2 таблицы маршрутизации. Собрать ядро с options ROUTETABLES=2
2) после перезагрузки у нас будет 2 независимые таблицы роутинга
3)выставляем в них 2 default-route
команда:
setfib 0 route add default 192.168.0.1 #default в первой таблице
setfib 1 route add default 192.168.1.1 #default во второй таблице4) правим ipfw
ipfw add 100 setfib 1 all from any to 192.168.1.2 in recv em1 #устанавливаем для пакетов пришедших с интерфейса em1 таблицу роутинга = 1. В итоге ответный пакет будет уходить по default=192.168.1.1 - что нам и нужно.
ipfw add 200 pass all from any to any #разрешаем всёвроде всё.
> Да коллеги, подтверждаю был не прав.
> Есть как минимум 1 рабочее решение.... Ну а я сегодня-завтра буду решать чутка более сложный вариант:
- два два канала от двух провайдеров с реальными белыми ip ;
- серверный пул и офисная подсеть за nat-ом (вернее "двумя параллельными" - на каждого провайдера свой) ;
- AS, BGP - отсутствуют как класс ;
== обеспечить доступ к серверному пулу ОДНОВРЕМЕННО по ДВУМ внешним каналам == :)... Если получится - отпишусь сюда результатом ...
И (условно) третий вариант решения, подсказанный сегодня одним умным товарищем. Как уже проверил уважаемый sm00th1980 - multiple routing tables у нас (FreeBSD) - работает ;) ;) ;)
Так вот - обеспечить ОДНОВРЕМЕННУЮ работу в любом из вариантов - что в моей задаче. что в задаче ТС - вполне реально, скрестив multiple routing tables и дополнительные сетевые алиасы на серверах.Приведу пример решения для своей задачи, ТС я думаю вполне сможет адаптировать его "под себя". Что имеем, и как стоит задача - я уже писал в предыдущем посте ... Решение - на шлюзе поднимаем две таблицы маршрутизации одна обрабатывает нашу основную (реальную) подсеть серверов и шлюзом по умолчанию для нее выступает провайдер-1, вторая - обрабатывает подсеть из наших "дополнительных" алиасов, и шлюзом по умолчнию для нее выступает провайдер-2. Соответственно на шлюзе настраиваем и два nat-а. В таком варианте - откуда бы не пришел пакет на внутренний сервер - отправлен он будет именно в тот аплинк, из которого был получен запрос...
>[оверквотинг удален]
> команда:
> setfib 0 route add default 192.168.0.1 #default в первой таблице
> setfib 1 route add default 192.168.1.1 #default во второй таблице
> 4) правим ipfw
> ipfw add 100 setfib 1 all from any to 192.168.1.2 in recv
> em1 #устанавливаем для пакетов пришедших с интерфейса em1 таблицу роутинга =
> 1. В итоге ответный пакет будет уходить по default=192.168.1.1 - что
> нам и нужно.
> ipfw add 200 pass all from any to any #разрешаем всё
> вроде всё.да-да-да. правильный ход мысли. Таким путем точно можно достичь искомого.
> да-да-да. правильный ход мысли. Таким путем точно можно достичь искомого.Слишком сложно.
При двух белых IP от разных провов можно обойтись обычными ipfw fwd.
У setfib есть побочные моменты - нет поддержки ipv6 и странные путаницы default gateway.
Пока юзаю 2хBGP-канала + обычный линк с NAT для офисных хомячков.
>> да-да-да. правильный ход мысли. Таким путем точно можно достичь искомого.
> Слишком сложно.
> При двух белых IP от разных провов можно обойтись обычными ipfw fwd.
> У setfib есть побочные моменты - нет поддержки ipv6 и странные
> путаницы default gateway.
> Пока юзаю 2хBGP-канала + обычный линк с NAT для офисных хомячков.Для локального трафика ipfw setfib всеравно не работает :-(
//А в линуксе iproute + connmark есть .... эххх )
> //А в линуксе iproute + connmark есть .... эххх )Хватит тут агитаторов Линукс.
Идите на форумы виндузятников и там проводите агитацию :)
>> //А в линуксе iproute + connmark есть .... эххх )
> Хватит тут агитаторов Линукс.
> Идите на форумы виндузятников и там проводите агитацию :)интересно, а в винде возникают вопросы - "виндовс и два провайдера, общий доступ к сети" ?
Или там как обычно - два провайдера - два сервера?
>>> да-да-да. правильный ход мысли. Таким путем точно можно достичь искомого.
>> Слишком сложно.
>> При двух белых IP от разных провов можно обойтись обычными ipfw fwd.
>> У setfib есть побочные моменты - нет поддержки ipv6 и странные
>> путаницы default gateway.
>> Пока юзаю 2хBGP-канала + обычный линк с NAT для офисных хомячков.
> Для локального трафика ipfw setfib всеравно не работает :-(
> //А в линуксе iproute + connmark есть .... эххх )Почему Вы уверены, что не работает? может пакет просто не попадает в Ваше правило?
>>>> да-да-да. правильный ход мысли. Таким путем точно можно достичь искомого.
>>> Слишком сложно.
>>> При двух белых IP от разных провов можно обойтись обычными ipfw fwd.
>>> У setfib есть побочные моменты - нет поддержки ipv6 и странные
>>> путаницы default gateway.
>>> Пока юзаю 2хBGP-канала + обычный линк с NAT для офисных хомячков.
>> Для локального трафика ipfw setfib всеравно не работает :-(
>> //А в линуксе iproute + connmark есть .... эххх )
> Почему Вы уверены, что не работает? может пакет просто не попадает в
> Ваше правило?=) Потому что в файрволл локальный пакет попадает уже после принятия решения о маршрутизации. Если пакет транзитный, то маркировка делается на входе, потом применяется выбранная FIB, а уже потом пакет идет на выход. Повторюсь, локальный пакет маркируется после выбора FIB. Если почитаете интернет на эту тему, то там были идеи типа введения правила ipfw reroute :-)
Вот потому и считаю, что не работает :-) Хотя пакет попадает под правило. :-)
Это я про как минимум 8ку говорю... За процессом разработки / изменений в FreeBSD слежу изредка, если мои данные устарели - я буду рад это узнать.
>[оверквотинг удален]
> =) Потому что в файрволл локальный пакет попадает уже после принятия решения
> о маршрутизации. Если пакет транзитный, то маркировка делается на входе, потом
> применяется выбранная FIB, а уже потом пакет идет на выход. Повторюсь,
> локальный пакет маркируется после выбора FIB. Если почитаете интернет на эту
> тему, то там были идеи типа введения правила ipfw reroute :-)
> Вот потому и считаю, что не работает :-) Хотя пакет попадает под
> правило. :-)
> Это я про как минимум 8ку говорю... За процессом разработки / изменений
> в FreeBSD слежу изредка, если мои данные устарели - я буду
> рад это узнать.ну тогда 'ipfw fwd' Вам в помощь, после этого правила система плюет на таблицу маршрутизации и отправляет пакет туда, куда ей сказали, ну если конечно шлюз указанный в правиле доступен на одном из интерфейсов.
хотя я конечно огорчен, что FIB в ipfw не работает на 100%, сам еще не пользовался, но в будущем планировал.