SQUID

[Parol 0]

Помню что гдето читал. Когда читал не нужно было(((((

 

Перыл весь опенет так и не нашол.

 

Есть SQUID как сделать чтобы он перенаправлял запросы со внешнего интерфейса на локальный веб сервер ????

Тобиш набираю я в инет кафе www.vasyapupkin.com и попадаю на 213.227.206.* а там squid перенаправляет запрос на 10,0,0,1 ну и чтоб в обе стороны бегало а не токо запрос !!!

[Max 0]

хм, если мне не изменяет память то это делает не сквид а нат!

[Dr.Techno 0]

это DNAT в iptables

[Dr.Techno 0]

да, кстати пример:

iptables -t nat -A PREROUTING -p tcp -d <IPвнешний> --dport <порт внешний> -j DNAT --to--destination <ip внутрений>:<порт внутрений>

 

<> - скобки убрать.

[Parol 0]

тотоже что сквид это тоже делает вот только как не могу вспомнить

[Den_LocalNet 1 472]

тотоже что сквид это тоже делает вот только как не могу вспомнить

и не пытайся вспомнить - он этого не делает!

 

юзай DNAT предложеный выше или ipfw fwd во FreeBSD

[Slava 1]

Вот здесь http://www.opennet.ru/docs/RUS/iptables/ Хорошо расписано про 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-серверу, уже не должно возникать.

[Satana 0]

Спасибо большое всё ГУД !!!