TCP/IP ретранслятор - что-то в этом духе

[Wiz]

я вот тоже думаю, что программа должна быть все-таки немного сложнее чем просто прокси. там, по видимому, нужно работать непосредственно с IP-пакетами подменять там IP адреса или еще что-то чтобы было прозрачно то есть что-то типа NAT

[Foil]

maxs пишет:
> Ну ну, расскажи мне как в прокси встраивают NAT
а при чем тут NAT?

я говорил про >Прокси сервер - это не веб сервер.
на что он ответил что типа это одно и тоже

Foil пишет:
>Прокси сервер - это не веб сервер.

Правда ?

Ты видимо из тех, кто свято верит, что задача прокси сервера инет раздавать юзверям и хостам внутри сети.

Так вот открою тебе секрет - это не так. В первую очередь прокси и создавались, как решение для публикации приложений расположенных внутри сети в интернет, причем пофиг каких приложений, в том числе и вебсерверов.
И любая нормальная прокся - это умеет. И балансировку нагрузки зачастую умеет.
А называть проксисервером шнягу, которая только инет раздает юзверям - смешно.

вот это он не верно написал.

[Foil]

Wiz пишет:
> я вот тоже думаю, что программа должна быть все-таки немного сложнее чем просто прокси. там, по видимому, нужно
> работать непосредственно с IP-пакетами подменять там IP адреса или еще что-то чтобы было прозрачно то есть что-то
> типа NAT

NAT тебе не поможет.

[Wiz]

нет я о другом, имею ввиду работа с TCP/IP на более низком уровне в этой программе чтобы трафик переназначать прозрачно на другие машины

[Foil]

Жень nginx есть и под винду - запускает как приложение
Настраивай и пробуй!!!
http://sysoev.ru/nginx/docs/windows.html

[maxs]

Foil пишет:
> Wiz пишет:
>> я вот тоже думаю, что программа должна быть все-таки немного сложнее чем просто прокси. там, по видимому, нужно
>> работать непосредственно с IP-пакетами подменять там IP адреса или еще что-то чтобы было прозрачно то есть что-то
>> типа NAT
>
> NAT тебе не поможет.

Ещё как поможет, курите доку по iptables, действие - DNAT:

http://www.faqs.org/docs/iptables/targe ... DNATTARGET

[Foil]

Макс да не подойдет ему этот вариант с DNAT
ему надо на три компа разбросать с одного входящего IP и одного порта 80.

6.5.2. Действие DNAT

DNAT (Destination Network Address Translation) используется для преобразования адреса места назначения в IP заголовке пакета. Если пакет подпадает под критерий правила, выполняющего DNAT, то этот пакет, и все последующие пакеты из этого же потока, будут подвергнуты преобразованию адреса назначения и переданы на требуемое устройство, хост или сеть. Данное действие может, к примеру, успешно использоваться для предоставления доступа к вашему web-серверу, находящемуся в локальной сети, и не имеющему реального IP адреса. Для этого вы строите правило, которое перехватывает пакеты, идущие на HTTP порт брандмауэра и выполняя DNAT передаете их на локальный адрес web-сервера. Для этого действия так же можно указать диапазон адресов, тогда выбор адреса назначения для каждого нового потока будет производиться случайнам образом.

Действие DNAT может выполняться только в цепочках PREROUTING и OUTPUT таблицы nat, и во вложенных под-цепочках. Важно запомнить, что вложенные подцепочки, реализующие DNAT не должны вызываться из других цепочек, кроме PREROUTING и OUTPUT.

Таблица 6-16. Действие DNATКлюч --to-destination
Пример iptables -t nat -A PREROUTING -p tcp -d 15.45.23.67 --dport 80 -j DNAT --to-destination 192.168.1.1-192.168.1.10
Описание Ключ --to-destination указывает, какой IP адрес должен быть подставлен в качестве адреса места назначения. В выше приведенном примере во всех пакетах, пришедших на адрес 15.45.23.67, адрес назначения будет изменен на один из диапазона от 192.168.1.1 до 192.168.1.10. Как уже указывалось выше, все пакеты из одного потока будут направляться на один и тот же адрес, а для каждого нового потока будет выбираться один из адресов в указанном диапазоне случайным образом. Можно также определить единственный IP адрес. Можно дополнительно указать порт или диапазон портов, на который (которые) будет перенаправлен траффик. Для этого после ip адреса через двоеточие укажите порт, например --to-destination 192.168.1.1:80, а указание диапазона портов выглядит так: --to-destination 192.168.1.1:80-100. Как вы можете видеть, синтаксис действий DNAT и SNAT во многом схож. Не забывайте, что указание портов допускается только при работе с протоколом TCP или UDP, при наличии опции --protocol в критерии.


Действие DNAT достаточно сложно в использовании и требует дополнительного пояснения. Рассмотрим простой пример. У нас есть WEB сервер и мы хотим разрешить доступ к нему из Интернет. Мы имеем только один реальный IP адрес, а WEB-сервер расположен в локальной сети. Реальный IP адрес $INET_IP назначен брандмауэру, HTTP сервер имеет локальный адрес $HTTP_IP и, наконец брандмауэр имеет локальный алрес $LAN_IP. Для начала добавим простое правило в цепочку PREROUTING таблицы nat:
iptables -t nat -A PREROUTING --dst $INET_IP -p tcp --dport 80 -j DNAT \
--to-destination $HTTP_IP


В соответствии с этим правилом, все пакеты, поступающие на 80-й порт адреса $INET_IP перенаправляются на наш внутренний WEB-сервер. Если теперь обратиться к WEB-серверу из Интернет, то все будет работать прекрасно. Но что же произойдет, если попробовать соединиться с ним из локальной сети? Соединение просто не установится. Давайте посмотрим как маршрутизируются пакеты, идущие из Интернет на наш WEB-сервер. Для простоты изложения примем адрес клиента в Интернет равным $EXT_BOX.

Пакет покидает клиентский узел с адресом $EXT_BOX и направляется на $INET_IP

Пакет приходит на наш брандмауэр.

Брандмауэр, в соответствии с вышеприведенным правилом, подменяет адрес назначения и передает его дальше, в другие цепочки.

Пакет передается на $HTTP_IP.

Пакет поступает на HTTP сервер и сервер передает ответ через брандмауэр, если в таблице маршрутизации он обозначен как шлюз для $EXT_BOX. Как правило, он назначается шлюзом по-умолчанию для HTTP сервера.

Брандмауэр производит обратную подстановку адреса в пакете, теперь все выглядит так, как будто бы пакет был сформирован на брандмауэре.

Пакет передается клиенту $EXT_BOX.

А теперь посмотрим, что произойдет, если запрос посылается с узла, расположенного в той же локальной сети. Для простоты изложения примем адрес клиента в локальной сети равным $LAN_BOX.

Пакет покидает $LAN_BOX.

Поступает на брандмауэр.

Производится подстановка адреса назначения, однако адрес отправителя не подменяется, т.е. исходный адрес остается в пакете без изменения.

Пакет покидает брандмауэр и отправляется на HTTP сервер.

HTTP сервер, готовясь к отправке ответа, обнаруживает, что клиент находится в локальной сети (поскольку пакет запроса содержал оригинальный IP адрес, который теперь превратился в адрес назначения) и поэтому отправляет пакет непосредственно на $LAN_BOX.

Пакет поступает на $LAN_BOX. Клиент "путается", поскольку ответ пришел не с того узла, на который отправлялся запрос. Поэтому клиент "сбрасывает" пакет ответа и продолжает ждать "настоящий" ответ.

Проблема решается довольно просто с помощью SNAT. Ниже приводится правило, которое выполняет эту функцию. Это правило вынуждает HTTP сервер передавать ответы на наш брандмауэр, которые затем будут переданы клиенту.
iptables -t nat -A POSTROUTING -p tcp --dst $HTTP_IP --dport 80 -j SNAT \
--to-source $LAN_IP


Запомните, цепочка POSTROUTING обрабатывается самой последней и к этому моменту пакет уже прошел процедуру преобразования DNAT, поэтому критерий строится на базе адреса назначения $HTTP_IP.

Если вы думаете, что на этом можно остановиться, то вы ошибаетесь! Представим себе ситуацию, когда в качестве клиента выступает сам брандмауэр. Тогда, к сожалению, пакеты будут передаваться на локальный порт с номером 80 самого брандмауэра, а не на $HTTP_IP. Чтобы разрешить и эту проблему, добавим правило:
iptables -t nat -A OUTPUT --dst $INET_IP -p tcp --dport 80 -j DNAT \
--to-destination $HTTP_IP


Теперь никаких проблем, с доступом к нашему WEB-серверу, уже не должно возникать.
Каждый должен понять, что эти правила предназначены только лишь для корректной обработки адресации пакетов. В дополнение к этим правилам вам может потребоваться написать дополнительные правила для цепочки FORWARD таблицы filter. Не забудьте при этом, что пакеты уже прошли цепочку PREROUTING и поэтому их адреса назначения уже изменены действием DNAT.

[Hando]

блееееееа!

[souphead]

AlexA пишет:
>

Так вот открою тебе секрет - это не так. В первую очередь прокси и создавались, как решение для публикации
> приложений расположенных внутри сети в интернет, причем пофиг каких приложений, в том числе и вебсерверов.

>
> Откуда столько умников? В ИТ есть такое понятие - PROXY, по русски это что-то типа: посредник.
> Так вот изначально прокси-сервер - это был посредник между пользователями и веб-серверами с функциями кэширования,
>
> обеспечения анонимности и т.п. Потом прокси-сервера в локальных сетках стали дополнительно нагружать функциями
> firewall, NAT, DHCP, DNS, routera и т.д.

Ты сам то понял какую ты ржаку написал ?
Это в чьем ИТ есть такое понятие ? В вашем ИТ - ИТ осфисов с сотней-другой компов и несколькими серверами ?
Может у ВАС - оно и так.
В реальном мире все по-другому.
То, что на сервере, где стоит прокси, запущены firewall, NAT, DHCP, DNS, routera, при чем здесь они вообще?
Прокси серверу вообще параллельно, какие протоколы пускать, наружу или внутрь, важно то, что он аутентифицируя обращающегося клиента, по определенным правилам перенаправляет пакеты на приложение крутящееся на определенном порту хоста-цели.
Использование прокси для обеспечения доступа ювзверей в интернет - это маленький частный случай.
Но видимо тебе просто не приходилось никогда сталкиваться ни с чем, кроме как задачка - выпустить юзерей в инет.
Не стоит думать, что ты крутой ИТ-спец, упираясь в свой опыт админинья конторки максимум с несколькими сотнями компов и 10ком другим серверов.
И с видом эксперта нести фигню.


31: Foil:

Ты и вправду читать не умеешь, я и не писал, что прокси - это http сервер.

Я писал, что для задач Виза - нужен именно прокси.

Так вот открою тебе секрет - это не так. В первую очередь прокси и создавались, как решение для публикации приложений расположенных внутри сети в интернет, причем пофиг каких приложений, в том числе и вебсерверов.
И любая нормальная прокся - это умеет. И балансировку нагрузки зачастую умеет.
А называть проксисервером шнягу, которая только инет раздает юзверям - смешно.

> вот это он не верно написал.

А тепер вот доходчиво по русски, что такое прокси.

Прокси-сервер (от англ. proxy — «представитель, уполномоченный») — служба в компьютерных сетях, позволяющая клиентам выполнять косвенные запросы к другим сетевым службам. Сначала клиент подключается к прокси-серверу и запрашивает какой-либо ресурс (например, e-mail, ftp, другое приложение прикладного уровня), расположенный на другом сервере. Затем прокси-сервер либо подключается к указанному серверу и получает ресурс у него, либо возвращает ресурс из собственного кэша (в случаях, если прокси имеет свой кэш). В некоторых случаях запрос клиента или ответ сервера может быть изменён прокси-сервером в определённых целях. Также прокси-сервер позволяет защищать клиентский компьютер от некоторых сетевых атак.

[souphead]

Wiz пишет:
> я вот тоже думаю, что программа должна быть все-таки немного сложнее чем просто прокси. там, по видимому, нужно
> работать непосредственно с IP-пакетами подменять там IP адреса или еще что-то чтобы было прозрачно то есть что-то
> типа NAT

NGINX - это все умеет, ибо под это и заточен.

Я ж тебе готовый конфиг дал даже, для указанных тобой IP.

[AlexA]

Ты сам то понял какую ты ржаку написал ?
Это в чьем ИТ есть такое понятие ? В вашем ИТ - ИТ осфисов с сотней-другой компов и несколькими серверами ?
Может у ВАС - оно и так.
В реальном мире все по-другому.
То, что на сервере, где стоит прокси, запущены firewall, NAT, DHCP, DNS, routera, при чем здесь они вообще?
Прокси серверу вообще параллельно, какие протоколы пускать, наружу или внутрь, важно то, что он аутентифицируя обращающегося клиента, по определенным правилам перенаправляет пакеты на приложение крутящееся на определенном порту хоста-цели.
Использование прокси для обеспечения доступа ювзверей в интернет - это маленький частный случай.
Но видимо тебе просто не приходилось никогда сталкиваться ни с чем, кроме как задачка - выпустить юзерей в инет.
Не стоит думать, что ты крутой ИТ-спец, упираясь в свой опыт админинья конторки максимум с несколькими сотнями компов и 10ком другим серверов.
И с видом эксперта нести фигню.

Плин, дайте йаду, не хочу больше жить. Суп, прости, я не прав, ты гений. Меня нет, ушел ридить доки эбаут прокси-серверов
http://www.freeproxy.ru/ru/free_proxy/faq/index.htm

[AlexA]

А тепер вот доходчиво по русски, что такое прокси.

Прокси-сервер (от англ. proxy — «представитель, уполномоченный») — служба в компьютерных сетях, позволяющая клиентам выполнять косвенные запросы к другим сетевым службам. Сначала клиент подключается к прокси-серверу и запрашивает какой-либо ресурс (например, e-mail, ftp, другое приложение прикладного уровня), расположенный на другом сервере. Затем прокси-сервер либо подключается к указанному серверу и получает ресурс у него, либо возвращает ресурс из собственного кэша (в случаях, если прокси имеет свой кэш). В некоторых случаях запрос клиента или ответ сервера может быть изменён прокси-сервером в определённых целях. Также прокси-сервер позволяет защищать клиентский компьютер от некоторых сетевых атак.

Так бы сразу и сказал, а то пасть порву, пасть порву
http://ru.wikipedia.org/wiki/Proxy_server

[AlexA]

Вот здесь кратко и ясно о прокси-серверах:
http://www.helloworld.ru/texts/comp/ine ... xy/016.htm

И вообще, суп, я вижу ты не глупый человек, но внимательно читать не умеешь. Когда речь идет о "ПРОКСИ СЕРВЕРЕ",
не надо мешать с другими прокси. Давай сюда еще замешаем прокси из ООП и т.д. То что ты имеешь в виду "ОБРАТНЫЙ прокси сервер",
он так и называется - О Б Р А Т Н Ы Й !!!

Спасибо за внимание

[souphead]

42: AlexA:

Обратный прокси - это бредовый термин, русских горе ойтишнегов.

Какая разница, если определение взято из вики - если оно стопудово верно.
Давать ссылки на левоту типа http://www.helloworld.ru/ и http://www.freeproxy.ru - это конечно кошернее.

Назови мне хоть один действительно распространенный прокси, используемый в среднем и крупном бизнесе, который не умеет публиковать приложения и не умел изначально?

[AlexA]

Суп я виноват, что начал эту байду, черт попутал. Извини.