The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Перенаправление на другой адрес"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (Firewall, Фильтрация пакетов / FreeBSD)
Изначальное сообщение [ Отслеживать ]

"Перенаправление на другой адрес"  +/
Сообщение от GlooM14 (ok) on 14-Дек-13, 13:40 
Приветствую!

Имеются два сервера в одном широковещательном сегменте (белые внешние адреса).
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

Однако, данный костыль, самопроизвольно падает. Есть какое-нибудь более грамотное решение данной проблемы, нежели чем запихивание выполнения датапайпа в крон каждую минуту? -)

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Перенаправление на другой адрес"  +/
Сообщение от Аноним (??) on 14-Дек-13, 15:33 
> Необходимо перенаправлять ТОЛЬКО запросы на 80-й порт server.name на x.y.z.196.

Как вариант поставить на x.y.z.194. nginx, который будет проксировать http запросы на server.name на хост x.y.z.196., и заодно скеширует и ускорит отдачу.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Перенаправление на другой адрес"  +/
Сообщение от GlooM14 (ok) on 14-Дек-13, 20:20 
>> Необходимо перенаправлять ТОЛЬКО запросы на 80-й порт server.name на x.y.z.196.
> Как вариант поставить на x.y.z.194. nginx, который будет проксировать http запросы на
> server.name на хост x.y.z.196., и заодно скеширует и ускорит отдачу.

Спасибо! Вариант весьма не плох!

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Перенаправление на другой адрес"  +/
Сообщение от михалыч (ok) on 14-Дек-13, 20:13 
> В общем, у меня создалось такое впечатление, что 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
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Перенаправление на другой адрес"  +/
Сообщение от GlooM14 (ok) on 14-Дек-13, 20:22 
>> В общем, у меня создалось такое впечатление, что fwd в принципе умеет заворачивать запросы только на локалхост.
> Не только.
> вот что говорит man ipfw в разделе fwd
> То есть, должны пакеты идти после форвардинга на машину 196.
> Другое дело, что содержимое пакета не меняется.
> tcpdump посмотреть что приходит, что уходит и на 194 и на 196

На данный момент посмотреть не могу. Но помню точно, что после применения правила запрос не просто сбрасывался, а показывал все равно пустой "It works" со 194. То есть связь устанавливалась со 194, где ничего нет.


Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

5. "Перенаправление на другой адрес"  +/
Сообщение от михалыч (ok) on 14-Дек-13, 20:27 
> То есть связь устанавливалась со 194, где ничего нет.

Смотреть, смотреть tcpdump'ом, а то fwd может и не отрабатывает.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "Перенаправление на другой адрес"  +/
Сообщение от kam (ok) on 14-Дек-13, 22:54 
> Другое дело, что содержимое пакета не меняется.

Именно. К тому же клиент посылает запрос на .194, а ответ получит с .196. Ему это не понравится.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру