URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 59638
[ Назад ]

Исходное сообщение
"проброс порта"
Отправлено pheonix , 31-Авг-05 11:12

внешний
1.2.3.4:80
внутренний 192.168.0.1:80
как?

Содержание

проброс порта,Dorlas, 11:20 , 31-Авг-05
проброс порта,serphio, 11:22 , 31-Авг-05
- проброс порта,pheonix, 11:23 , 31-Авг-05
  - проброс порта,Dorlas, 11:41 , 31-Авг-05
    - проброс порта,pheonix, 11:55 , 31-Авг-05
      - проброс порта,Dorlas, 12:14 , 31-Авг-05
        
        проброс порта,pheonix, 08:54 , 01-Сен-05
проброс порта,toster, 16:04 , 31-Авг-05
- проброс порта,АрхангелГавриил, 18:47 , 31-Авг-05
  - проброс порта,pheonix, 08:01 , 01-Сен-05
- проброс порта,pheonix, 08:53 , 01-Сен-05
  - проброс порта,pheonix, 09:06 , 01-Сен-05
    - проброс порта,open, 09:56 , 01-Сен-05
      - проброс порта,pheonix, 10:35 , 01-Сен-05
    - проброс порта,Аноним, 10:45 , 02-Сен-05
      - проброс порта,pheonix, 15:11 , 02-Сен-05
  - проброс порта,open, 09:26 , 01-Сен-05
    - проброс порта,pheonix, 09:44 , 01-Сен-05
проброс порта,anonymous, 13:08 , 01-Сен-05
- проброс порта,iasb, 18:28 , 01-Сен-05
  - проброс порта,pheonix, 07:43 , 02-Сен-05
проброс порта,xeon, 08:41 , 02-Сен-05
- проброс порта,pheonix, 09:51 , 02-Сен-05
  - вот мой конфиг,pheonix, 10:03 , 02-Сен-05
проброс порта,toster, 14:05 , 02-Сен-05

Сообщения в этом обсуждении

"проброс порта"
Отправлено Dorlas , 31-Авг-05 11:20

>внешний
>1.2.3.4:80
>внутренний 192.168.0.1:80
>как?
man natd - там усе есть.

"проброс порта"
Отправлено serphio , 31-Авг-05 11:22

>внешний
>1.2.3.4:80
>внутренний 192.168.0.1:80
>как?
создаешь файл /etc/nat1.cfg
там пишешь:
redirect_port tcp 192.168.0.1:80 1.2.3.4:80
и дальше при запуске natd указываешь этот файл конфигурации (у меня natd запускается через rc.local):
natd -f /etc/nat1.cfg

"проброс порта"
Отправлено pheonix , 31-Авг-05 11:23

asplinux операционка забыл написать

"проброс порта"
Отправлено Dorlas , 31-Авг-05 11:41

>asplinux операционка забыл написать

Ну тогда делается средствами iptables (соответственно man iptables).

"проброс порта"
Отправлено pheonix , 31-Авг-05 11:55

>>asplinux операционка забыл написать
>
>
>Ну тогда делается средствами iptables (соответственно man iptables).

да я уже замаляся его читать, не могу сделать не получаеться что на всём форуме никто с этим не сталкивался что ли:(

"проброс порта"
Отправлено Dorlas , 31-Авг-05 12:14

>>>asplinux операционка забыл написать
>>
>>
>>Ну тогда делается средствами iptables (соответственно man iptables).
>
>
>да я уже замаляся его читать, не могу сделать не получаеться что
>на всём форуме никто с этим не сталкивался что ли:(
Вроде бы так:
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.0/24 -d 0/0 -j SNAT -to-source 1.2.3.4 -j ACCEPT
iptables -t nat -A PREROURING -p tcp -s 0/0 -d 1.2.3.4 -dport http -j DNAT -to-dest 192.168.0.1 -j ACCEPT

"проброс порта"
Отправлено pheonix , 01-Сен-05 08:54

>>>>asplinux операционка забыл написать
>>>
>>>
>>>Ну тогда делается средствами iptables (соответственно man iptables).
>>
>>
>>да я уже замаляся его читать, не могу сделать не получаеться что
>>на всём форуме никто с этим не сталкивался что ли:(
>
>Вроде бы так:
>
>iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.0/24 -d 0/0 -j
>SNAT -to-source 1.2.3.4 -j ACCEPT
>
>iptables -t nat -A PREROURING -p tcp -s 0/0 -d 1.2.3.4 -dport
>http -j DNAT -to-dest 192.168.0.1 -j ACCEPT
ошибку выдаёт, у меня есть уже конфиг файл может в нём что не так, кинуть вам его?

"проброс порта"
Отправлено toster , 31-Авг-05 16:04

>внешний
>1.2.3.4:80
>внутренний 192.168.0.1:80
>как?
А мануалы читать не пробовал для начала?
из Iptables Tutorial Iptables Tutorial
[цитата]
Действие 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.
[/цитата]

"проброс порта"
Отправлено АрхангелГавриил , 31-Авг-05 18:47

>>внешний
>>1.2.3.4:80
>>внутренний 192.168.0.1:80
>>как?
а может проще через redirect в xinetd?

"проброс порта"
Отправлено pheonix , 01-Сен-05 08:01

>>>внешний
>>>1.2.3.4:80
>>>внутренний 192.168.0.1:80
>>>как?
>а может проще через redirect в xinetd?

а это как?

"проброс порта"
Отправлено pheonix , 01-Сен-05 08:53

>>внешний
>>1.2.3.4:80
>>внутренний 192.168.0.1:80
>>как?
>
>А мануалы читать не пробовал для начала?
>из Iptables Tutorial Iptables Tutorial
>
>[цитата]
>Действие 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.
>[/цитата]
не пошло, уже это говорю же пробывал

"проброс порта"
Отправлено pheonix , 01-Сен-05 09:06

пробывла так
port_redir
{
        type            = UNLISTED
        port            = 211
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = root
        disable         = no
        redirect        = 192.168.0.2 80
}
ошибок не выдало, но результат нулевой

"проброс порта"
Отправлено open , 01-Сен-05 09:56

а может так ?
service bla-bla
{
....
>пробывла так
>
>port_redir
>{
>        type
>        = UNLISTED
>        port
>        = 211
>        socket_type
> = stream
>        protocol
>    = tcp
>        wait
>        = no
>        user
>        = root
>        disable
>     = no
>        redirect
>    = 192.168.0.2 80
>}
>
>ошибок не выдало, но результат нулевой

"проброс порта"
Отправлено pheonix , 01-Сен-05 10:35

>а может так ?
>service bla-bla
>{
>....
так тоже никак(

"проброс порта"
Отправлено Аноним , 02-Сен-05 10:45

>пробывла так
>
>port_redir
>{
>        type
>        = UNLISTED
>        port
>        = 211
>        socket_type
> = stream
>        protocol
>    = tcp
>        wait
>        = no
>        user
>        = root
>        disable
>     = no
>        redirect
>    = 192.168.0.2 80
>}
>
>ошибок не выдало, но результат нулевой

надеюсь разберешся:
# cat /etc/xinetd.d/vnc1
service vnc1
   {
        disable = no
        type            = UNLISTED
        socket_type     = stream
        protocol        = tcp
        user            = nobody
        wait            = no
        redirect        = 10.1.1.53 5901
        port            = 5901
   }
# grep vnc1 /etc/services
vnc1            5901/tcp                        # vnc
vnc1            5901/udp                        # vnc

"проброс порта"
Отправлено pheonix , 02-Сен-05 15:11

>>пробывла так
>>
>>port_redir
>>{
>>        type
>>        = UNLISTED
>>        port
>>        = 211
>>        socket_type
>> = stream
>>        protocol
>>    = tcp
>>        wait
>>        = no
>>        user
>>        = root
>>        disable
>>     = no
>>        redirect
>>    = 192.168.0.2 80
>>}
>>
>>ошибок не выдало, но результат нулевой
>
>
>надеюсь разберешся:
>
># cat /etc/xinetd.d/vnc1
>service vnc1
>   {
>        disable = no
>        type
>        = UNLISTED
>        socket_type
> = stream
>        protocol
>    = tcp
>        user
>        = nobody
>        wait
>        = no
>        redirect
>    = 10.1.1.53 5901
>        port
>        = 5901
>   }
>
># grep vnc1 /etc/services
>vnc1
>5901/tcp
>
>  # vnc
>vnc1
>5901/udp
>
>  # vnc
я вшоке из-за юзера ниче не робило:) всё робит сэнкс:))

"проброс порта"
Отправлено open , 01-Сен-05 09:26

попробуй через xinetd, man xinetd.conf на тему redirect
>>>внешний
>>>1.2.3.4:80
>>>внутренний 192.168.0.1:80
>>>как?
>>
>>А мануалы читать не пробовал для начала?
>>из Iptables Tutorial Iptables Tutorial
>>
>>[цитата]
>>Действие 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.
>>[/цитата]
>не пошло, уже это говорю же пробывал

"проброс порта"
Отправлено pheonix , 01-Сен-05 09:44

>попробуй через xinetd, man xinetd.conf на тему redirect
>
выше же написан скрипт через хинетд

"проброс порта"
Отправлено anonymous , 01-Сен-05 13:08

>внешний
>1.2.3.4:80
>внутренний 192.168.0.1:80
>как?
poprobyi rinetd

"проброс порта"
Отправлено iasb , 01-Сен-05 18:28

>>внешний
>>1.2.3.4:80
>>внутренний 192.168.0.1:80
>>как?
>
>poprobyi rinetd

зайди на http://iasb.narod.ru - там есть ясная статейка по FreeBSD

"проброс порта"
Отправлено pheonix , 02-Сен-05 07:43

>зайди на http://iasb.narod.ru - там есть ясная статейка по FreeBSD
Linux ASP 9.2

"проброс порта"
Отправлено xeon , 02-Сен-05 08:41

>внешний
>1.2.3.4:80
>внутренний 192.168.0.1:80
>как?
Ставишь rinetd(качнуть например отсюда http://www.boutell.com/rinetd/)
в /etc/rinetd.conf пишеш:
1.2.3.4 80 192.168.0.1 80
делаешь #service rinetd start
всё.

"проброс порта"
Отправлено pheonix , 02-Сен-05 09:51

за прогу спасибо, это на крайняк попробую, хачу с помощью апитаблез, вобщем делаю так
iptables -t nat -A PREROUTING -p tcp -d 192.168.0.1 --dport 211 -j DNAT --to-destination 192.168.0.3:80
192.168.0.1 - адресс шлюза
никуда пакеты не перекидаваються хотя должны с адресса http://192.168.0.1:211 на http://192.168.0.3:80 сам я навигачу с ip 192.168.0.3 что может быть не так?
с других лановских ip прекрасно заходит на сервак http://192.168.0.3 так что всё робит, но почему не перекидываеться порт?
может какая функция или модуль не подключё?
версия iptables v1.2.9

"вот мой конфиг"
Отправлено pheonix , 02-Сен-05 10:03

#!/bin/sh
I=/sbin/iptables
ip_i=192.168.0.1
ip_o=1.2.3.4
ip_lan=192.168.0/24
in_i=eth1
in_o=eth0
$I -F
$I -X
$I -t nat -F
$I -t nat -X
$I -t mangle -F
$I -t mangle -X
$I -P INPUT DROP
$I -P OUTPUT DROP
$I -P FORWARD DROP
$I -A INPUT   -m state --state ESTABLISHED,RELATED -j ACCEPT
$I -A OUTPUT  -m state --state ESTABLISHED,RELATED -j ACCEPT
$I -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
$I -A INPUT  -i lo -j ACCEPT
$I -A OUTPUT -o lo -j ACCEPT
$I -A INPUT  -s $ip_i -j ACCEPT
$I -A OUTPUT -d $ip_i -j ACCEPT
$I -A INPUT  -s $ip_o -j ACCEPT
$I -A OUTPUT -d $ip_o -j ACCEPT
$I -A INPUT -p tcp --syn --dport 25 -j ACCEPT
$I -A INPUT -p tcp --syn --dport 80 -j ACCEPT
$I -A INPUT -p tcp --syn --dport 110 -j ACCEPT
#$I -A INPUT -p tcp --syn --dport 211 -j ACCEPT
$I -A INPUT -i $in_i -j ACCEPT
$I -A OUTPUT -p tcp --syn -j ACCEPT
$I -A OUTPUT -p udp -j ACCEPT
$I -A OUTPUT -p icmp -j ACCEPT
########################################
# NAT and related
$I -t nat -A POSTROUTING -s $ip_lan -o $in_o -j SNAT --to-source $ip_o
$I -A FORWARD -p tcp -i $in_i -o $in_o --syn -j ACCEPT
$I -A FORWARD -p udp -i $in_i -o $in_o -j ACCEPT
$I -A FORWARD -p icmp -i $in_i -o $in_o -j ACCEPT
echo "1" >/proc/sys/net/ipv4/ip_forward
после него вношу то что сверху написано и ничё не робит, что за вата?
маска внешного апи 255.255.255.224 лановского 255.255.255.0

"проброс порта"
Отправлено toster , 02-Сен-05 14:05

>внешний
>1.2.3.4:80
>внутренний 192.168.0.1:80
>как?
еще есть софтинка zebedee. Она умеет строить туннели между удаленными портами и + еще жать и криптовать траффик. У меня ей smtp пробрасывается между почтарями