Приветствую!Имеются два сервера в одном широковещательном сегменте (белые внешние адреса).
1- x.y.z.194
2 - x.y.z.196На сервере №1 настроен ДНС, который доменное имя "server.name" преобразует в x.y.z.194. На сервере №2 работает веб-сервер и его айпи к домену не привязан. В качестве временной меры он реализует хостинг для сайта, который, пока по определенным причинам не может переехать на сервер №1.
Задача.
Необходимо перенаправлять ТОЛЬКО запросы на 80-й порт server.name на x.y.z.196. То есть, все остальные сервисы, привязанные на доменное имя должны попадать, как и полагается, на первый сервак, а только веб-запросы на второй.
fwd в ipfw работает непонятно. После чтения мануалов выяснилось, что форвардинг возможен на адреса в пределах одной широковещательной зоны (то есть, казалось бы, мой случай), но конструкция вида:
${fwcmd} add fwd x.y.z.196,80 tcp from any to x.y.z.194,80 via bce0
НЕ РАБОТАЕТ
Хотя, сам fwd функционирует - проверено заворотом запросов пользователей локалки на сквид. В общем, у меня создалось такое впечатление, что fwd в принципе умеет заворачивать запросы только на локалхост.
На данный момент проблему решаю так:
datapipe x.y.z.194 80 x.y.z.196 80Однако, данный костыль, самопроизвольно падает. Есть какое-нибудь более грамотное решение данной проблемы, нежели чем запихивание выполнения датапайпа в крон каждую минуту? -)
> Необходимо перенаправлять ТОЛЬКО запросы на 80-й порт server.name на x.y.z.196.Как вариант поставить на x.y.z.194. nginx, который будет проксировать http запросы на server.name на хост x.y.z.196., и заодно скеширует и ускорит отдачу.
>> Необходимо перенаправлять ТОЛЬКО запросы на 80-й порт server.name на x.y.z.196.
> Как вариант поставить на x.y.z.194. nginx, который будет проксировать http запросы на
> server.name на хост x.y.z.196., и заодно скеширует и ускорит отдачу.Спасибо! Вариант весьма не плох!
> В общем, у меня создалось такое впечатление, что fwd в принципе умеет заворачивать запросы только на локалхост.Не только.
вот что говорит man ipfw в разделе fwd
fwd | forward ipaddr | tablearg[,port]
Меняет следующий хоп соответствующих пакетов на ipaddr, который может быть
IP-адресом или именем хоста. Для IPv4 следующий прыжок для пакета может также
определяться по последней просмотренной таблице, используя ключевое слово tablearg
вместо явного адреса. Поиск прекращается, если это правило соответствует.Если ipaddr - это локальный адрес, то соответствующие пакеты будут
перенаправляться в порт (или номер порта в пакете, если иное не будет указано
в правиле) на локальной машине.Если ipaddr не локальный адрес, то номер порта (если указан) игнорируется
и пакет будет направлен на удаленный адрес, с помощью маршрута в локальной
таблице маршрутизации для этого IP-адреса.Правило fwd не будет соответствовать пакетам layer-2 (которые получены на
ether_input, ether_output или bridged).Действие fwd не изменяет содержимое пакета.
В частности, адрес назначения остается неизменным, поэтому пакеты, пересылаемые
в другую систему, обычно отбрасываются этой системой, если нет соответствующего
правила в этой системе, чтобы захватить их.Для локально направленных пакетов, локальному адресу сокета будет присвоен
оригинальный адрес назначения пакета. Это приводит к тому, что запись netstat
выглядит довольно странно, но предназначено для использования с прозрачными
прокси-серверами.Для включения fwd, собственное ядро должно быть скомпилировано с опцией
options IPFIREWALL_FORWARD
То есть, должны пакеты идти после форвардинга на машину 196.
Другое дело, что содержимое пакета не меняется.
tcpdump посмотреть что приходит, что уходит и на 194 и на 196
>> В общем, у меня создалось такое впечатление, что fwd в принципе умеет заворачивать запросы только на локалхост.
> Не только.
> вот что говорит man ipfw в разделе fwd
> То есть, должны пакеты идти после форвардинга на машину 196.
> Другое дело, что содержимое пакета не меняется.
> tcpdump посмотреть что приходит, что уходит и на 194 и на 196На данный момент посмотреть не могу. Но помню точно, что после применения правила запрос не просто сбрасывался, а показывал все равно пустой "It works" со 194. То есть связь устанавливалась со 194, где ничего нет.
> То есть связь устанавливалась со 194, где ничего нет.Смотреть, смотреть tcpdump'ом, а то fwd может и не отрабатывает.
> Другое дело, что содержимое пакета не меняется.Именно. К тому же клиент посылает запрос на .194, а ответ получит с .196. Ему это не понравится.