Security Lab



Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти  
Форум » Администрирование » Сети
Страницы: 1 2 След.
RSS
Проброс портов Linux
 
#1
Это нравится:0Да/0Нет
03.06.2011 07:19:24
Добрый день. Вот значит какая незадача. Имеется машина с линуксом и внешним IP на борту (10,10,10,1), она раздает инет нескольким машинам в офисе (10.10.10.1/24) посредством arno-iptables-firewall+dhcpd+bind etc. Проблема не в этом. Имеется машина с установленным веб-сервером (10.10.10.2), к ней от роутера (1) проброшен 80 порт правилом в конфиге arno.

Код
NAT_FORWARD_TCP="80>10.10.10.2"


Так все нормально работает с любого другого внешнего хоста, странички открываются все бегает, НО при попытке обратиться на внешний адрес роутера с любого компа ВНУТРЕННЕЙ сети браузер выдает "Не удалось подключиться к удалённому серверу". Арно почему-то при обращениях на внешний адрес от внутренних хостов не прокидывает порт на машину 10.10.10.2.
Более того даже с самого сервера
telnet внешний_ip 80
выдает Unable to connect to remote host: Connection refused. А с внешки все ок.

В скобках приведены внутренние адреса машин. Грубо говоря.

Как быть? Что-то в правилах файрвола недопилено?
Изменено: Doctor Psyho - 03.06.2011 07:23:46
 
 
 
#2
Это нравится:0Да/0Нет
03.06.2011 08:50:32
Цитата
Doctor Psyho пишет:
В скобках приведены внутренние адреса машин. Грубо говоря.

Если адреса верны хоть в какой-то степени (внутренний сервер расположен в той же сети 10.10.10.0/24) - то файрволл на роутере (10.10.10.1) не причем. Для всех машин ВНУТРЕННИЙ сети этот сервер является ЛОКАЛЬНЫМ. И обращение к нему должно идти НАПРЯМУЮ - то есть с использованием таблицы маршрутизации каждого локального компьютера. Тут засада (как мне кажется) в другом. В DNS (BIND в Вашем случае). Там наверняка прописан ВНЕШНИЙ (Интернет) адрес (с БЕЛЫМ ИП). Правильно? Вот локальные машины и обращаются не на 10.10.10.2, а на IP, назначенный ВНЕШЕМУ интерфейсу Линуксового сервера. И Ваше правило не действует. Самый простой способ разрулить это - использовать VIEW из набора фич BIND. Суть этого прибамбаса - выдавать разные IP при обращении из разных сетей. Скажем, для ВНУТРЕННИХ сетей - это будет 10.10.10.2, для внешних - внешний ИП роутера. И тогда при обращении снаружи будет действовать Ваше правило из таблицы nat iptables, а при обращении изнутри (с локальной сети) - будет идти обращение напрямую внутри локалки. Хотя и iptables тоже разрулить можно. Плюнув на попсовый Арно (я так понимаю - что фронтэнд для не осиливших документацию по iptables), и создав правило напрямую в iptables.
 
 
 
#3
Это нравится:0Да/0Нет
04.06.2011 13:02:35
В том то и дело что мне необходимо чтобы запросы шли не напрямую на 10.10.10.2 а приходили сначала на внешний интерфейс роутера, который форвардил бы запрос на веб-машину. Это продиктовано настройками веб-сервера, мне нужно чтобы машины обращались к реальным доменам на реальный адрес роутера. А оно почему-то режет подобные запросы. Bind тут не при чем вообще, на машинах гугловский днс настроен.

Хотя появилась идея - заставлять bind ресолвить запросы на внутренний интерфейс, попробую создать такую зону. Но это тоже не выход - создавать локальные записи для каждого нового субдомена на вебсервере.


upd. А вот пинги на реальный адрес проходят, соответственно просто не работает правило форвардинга для локальных хостов.
Изменено: Doctor Psyho - 04.06.2011 13:04:57
 
 
 
#4
Это нравится:0Да/0Нет
05.06.2011 10:37:26
Цитата
Doctor Psyho пишет:
просто не работает правило форвардинга для локальных хостов.

тцпдамп на интерфейсах серверов позволит ответить на этот вопрос. :) А также просмотр действующих правил файрволла (iptables -nL, iptables -t nat -nL).
 
 
 
#5
Это нравится:0Да/0Нет
05.06.2011 15:02:16
Убил арну, очистил все правила. Добавил начистую:

Код
iptables -t nat -A PREROUTING -p tcp -d внешний_ip --dport 80 -j DNAT --to-destination 10.10.10.2:80


все равно проброс работает только при выполнении условия - клиент должен быть из внешних сетей. Из внутрянки

telnet внешний_ip 80
выдает Unable to connect to remote host: Connection refused.

Печаль.
 
 
 
#6
Это нравится:0Да/0Нет
05.06.2011 15:13:11
Значит криво настроено правило файрволла. Я еще раз повторяю - выбросьте Вы этот Арно, прочитайте на опеннете документацию по iptables (даже на русском языке для выпускников школ времен расцвета демократии) и настройте нужное Вам правило.
 
 
 
#7
Это нравится:0Да/0Нет
05.06.2011 15:22:39
А ведь как все просто и элементарно решается средствами BIND. :)
Цитата

view "internal" {
     match-clients {10.10.10.0/24;};
     recursion yes;
     zone "имя" in {
         type master;
         file "internal_file_zone";
         notify yes;
      };
};

view "external" {
     match-clients {any;};
     recursion yes;
     zone "имя" in {
         type master;
         file "external_file_zone";
         notify yes;
      };
};

И все! И никакой возни с файрволлом, никакой лишней нагрузки на роутер. Все просто и красиво. Зачем плодить лишние сущности на пустом месте???  :o А остальные зоны, если уж так хочется, тупо форвардить на Гугло-нейм сервера.
 
 
 
#8
Это нравится:0Да/0Нет
05.06.2011 15:53:47
Да, к варианту с биндом я уже и так пришел, видимо это самый элегантный вариант без секса с перенаправлением трафика между интерфейсами. Спасибо за внимание.
 
 
 
#9
Это нравится:0Да/0Нет
05.06.2011 18:15:40
Да нет - можно и средствами iptables это все сделать. Но, поняв для начала, что и куда должно ходить, какие цепочки работают и в каких случаях (в частности - таблица nat и PREROUTING, POSTROUTING). Можно все это настроить. Но не средсвами "попсовых" фронтэндов.  ;)
 
 
 
#10
Это нравится:0Да/0Нет
08.06.2011 07:04:11
Глупый вопрос: а forward пакетов разрешён ?
Что выводит команда:
cat /proc/sys/net/ipv4/ip_forward

Если 0 - тогда логично, что ничего не работает.
Лечить это:

echo 1 > /proc/sys/net/ipv4/ip_forward
или
sysctl -w net.ipv4.ip_forward=1

Ещё вариант как пробросить порт во внутреннюю сетку c использованием xinetd:  http://go.hopx.net/2009/11/xinetd-port-forwarding.html
Здесь ещё примеры на эту же тему http://www.heronforge.net/redhat/node11.html
Понятно, что при большом трафике xinetd начнёт заметно потреблять процессорное время, но как вариант...
 
 
 
#11
Это нравится:0Да/0Нет
08.06.2011 12:12:21
Вопрос действительно глупый.
 
 
 
#12
Это нравится:0Да/0Нет
16.06.2011 02:46:38
Дабы не создавать отдельный топик. Имеется машина, на которой поднят нат. у машины 2 интерфейса с внешними ип, XX.XX.XX.XX и YY.YY.YY.YY, и один с локальным 192.168.0.1. Машины за натом ходят наружу через интерфейс XX.XX.XX.XX, шлюзом для них является соответственно локальный ип. Необходимо пробросить канал от интерфейса с YY.YY.YY.YY на одну из внутренних машин 192,168,0,50, чтобы обратившись из внешки по адресу YY.YY.YY.YY весь трафик прозрачно перенаправлялся на 192,168,0,50. Это вообще осуществимо?
Изменено: Doctor Psyho - 16.06.2011 04:28:44
 
 
 
#13
Это нравится:0Да/0Нет
16.06.2011 12:10:36
что не так с

iptables -t nat -I PREROUTING -d YY.YY.YY.YY -j DNAT --to-destination 192.168.0.50

?
 
 
 
#14
Это нравится:0Да/0Нет
16.06.2011 19:14:57
iptables-save в студию. ну и ip r s, ip a s
 
 
 
#15
Это нравится:0Да/0Нет
17.06.2011 04:58:43
Все осложняется тем, что эти адреса - pppoe соединения, и если же через ppp0 у меня машины ходят в инет, то ppp1 даже не пингуется с внешки, как исправить ума не приложу, ведь не может быть два default route в системе. Хотелось бы проще чем грабли с  multiple default gateways или лоад балансинг. Мне нужно чтобы второй интерфейс тоже был доступен с внешки.

Код
router:~# ip r s
provider_ipaddr dev ppp0  proto kernel  scope link  src XX.XX.XX.XX
provider_ipaddr dev ppp1  proto kernel  scope link  src YY.YY.YY.YY
provider_local_ipaddr/25 dev eth2  proto kernel  scope link  src ipaddr_eth2
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.1


Код
router:~# ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:08:c7:89:8b:75 brd ff:ff:ff:ff:ff:ff
    inet provider_local_ipaddr/25 brd provider_local_gw scope global eth2
    inet6 fe80::208:c7ff:fe89:8b75/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
    link/ether 1c:bd:b9:86:3f:27 brd ff:ff:ff:ff:ff:ff
4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:c0:df:10:37:16 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.1/24 brd 192.168.0.255 scope global eth0
    inet6 fe80::2c0:dfff:fe10:3716/64 scope link
       valid_lft forever preferred_lft forever
147: ppp1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 3
    link/ppp
    inet YY.YY.YY.YY peer pppoe_gw/32 scope global ppp1
149: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 3
    link/ppp
    inet XX.XX.XX.XX peer pppoe_gw/32 scope global ppp0
 
 
 
#16
Это нравится:0Да/0Нет
17.06.2011 05:49:59
Цитата
Doctor Psyho пишет:
Хотелось бы проще чем грабли с multiple default gateways или лоад балансинг.
там нет граблей. всё просто: по 1 табличке для каждого isp. в каждой табличке свой дефолт. ну и далее ip rule ... table isp1 и ip rule .... table isp2
 
 
 
#17
Это нравится:0Да/0Нет
17.06.2011 10:06:18
Достаточно для второго канала сделать табличку
Нечто типа
Код
echo "200 chan2" >> /etc/iproute2/rt_tables

ip route add 192.168.0.50 dev ethN table chan2
ip route add default dev pppN table chan2

ip rule add from YY.YY.YY.YY table chan2
 
 
 
#18
Это нравится:0Да/0Нет
17.06.2011 14:53:32
Не проканало так. В выводе ip r ничего не поменялось. Или надо переподнять интерфейсы?

в /etc/iproute2/rt_tables только это:

Код
# reserved values
#
255     local
254     main
253     default
0       unspec
#
# local
#
#1      inr.ruhep
200 chan2
Изменено: Doctor Psyho - 17.06.2011 14:55:30
 
 
 
#19
Это нравится:0Да/0Нет
19.06.2011 07:54:23
Пробовал сделать по этому мануалу, http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.multiple-links.html но там суть в отправке пакетов через разные шлюзы, а у меня один провайдер, хоть ip на pppoe разные, а шлюз таки - один. Соответственно ip route ругается при добавлении маршрута на вторую табличку.
 
 
 
#20
Это нравится:0Да/0Нет
21.06.2011 13:45:20
Цитата
Doctor Psyho пишет:
Не проканало так. В выводе ip r ничего не поменялось. Или надо переподнять интерфейсы?
Стучите в аську если интересно, покрутим.
 
 
 
Страницы: 1 2 След.
Читают тему