Маршрут на алиас? Проблема.

[Uncertainty]

Доброго времени суток, господа.

Столкнулся с одной немного странной проблемой. Видимо всё перед глазами, но в упор не вижу.

Условие: в локальной сети имеются машины с адресами в сети 192.168.10.0/24 (шлюз по умолчанию 192.168.10.1) и устройства с адресами в сети 192.168.20.0/24
Имеется сервер Ubuntu 10 с двумя сетевыми картами, на которых подняты:
eth0: 8.8.8.8 - выход в инет
eth1: 192.168.10.1 - выход в сеть 192.168.10.0/24
алиас eth1:0 192.168.20.1 - выход в сеть 192.168.20.0/24

Задача: прописать маршрут, что бы машины из 192.168.10.0/24 через сервер имели доступ к сети 192.168.20.0/24

ip_forward включен.

Как я понимаю, необходимо прописать маршрут на сервере.
Возможно и в iptables тоже.

Прошу помощи. Спасибо всем заранее.

[fisher74]

На сервере нужные роуты уже есть.
У клиентов основные шлюзы какие стоят? IP-ы eth1 и eth1:0?
показывай "sudo iptables-save"

[Uncertainty]

# Generated by iptables-save v1.4.4 on Thu Oct 14 16:20:20 2010
*filter
:INPUT ACCEPT [161080:9665185]
:FORWARD ACCEPT [184594:173533911]
:OUTPUT ACCEPT [25009086:40263320083]
:KNOCK - [0:0]
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p gre -j ACCEPT
-A INPUT -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p udp -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -i eth0 -p tcp -m conntrack --ctstate NEW -m tcp --dport 22 -j KNOCK
-A INPUT -i eth0 -p tcp -m conntrack --ctstate NEW -m tcp --dport 23000 -m recent --set --name SSH --rsource
-A INPUT -i eth0 -p tcp -m conntrack --ctstate NEW -m multiport --dports 22999,23001 -m recent --remove --name SSH --rsource
-A INPUT -i eth0 -p tcp -m conntrack --ctstate NEW -m tcp --dport 1723 -j KNOCK
-A INPUT -i eth0 -p tcp -m conntrack --ctstate NEW -m tcp --dport 23000 -m recent --set --name VPN --rsource
-A INPUT -i eth0 -p tcp -m conntrack --ctstate NEW -m multiport --dports 22999,23001 -m recent --remove --name VPN --rsource
-A INPUT -i eth0 -j DROP
-A OUTPUT -p icmp -j ACCEPT
-A KNOCK -m recent --rcheck --seconds 30 --name SSH --rsource -j ACCEPT
-A KNOCK -m recent --rcheck --seconds 30 --name VPN --rsource -j ACCEPT
COMMIT
# Completed on Thu Oct 14 16:20:20 2010
# Generated by iptables-save v1.4.4 on Thu Oct 14 16:20:20 2010
*nat
:PREROUTING ACCEPT [704174:37489225]
:POSTROUTING ACCEPT [195155:12078719]
:OUTPUT ACCEPT [195139:12077951]
-A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE
COMMIT
# Completed on Thu Oct 14 16:20:20 2010

Основной шлюз на машина 192.168.10.1 (то есть eth1 сервера).

[fisher74]

А у этих 192.168.20.0/24 какой?

[Uncertainty]

А у этих 192.168.20.0/24 какой?

Хороший вопрос. Сразу не могу на него ответить. Там обычные iLo модули от серверов.
В принципе им выход в инет или в иные сети и даром не нужен.
Главное иметь к ним доступ из-под сети 192.168.10.0/24

[fisher74]

А что? на iLo никак не зайти посмотреть? Не обязательно же перегружать
У вас, кстати, в таблесах грабли в виде
-A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE
У вас, судя по вашему описанию, нет сети 192.168.1.0/24

[Unreg]

FORWARD ACCEPT, ip_forward 1, так что если указать в 192.168.20.0/24 DG 192.168.20.1 должно работать

[fisher74]

Ну, собственно, я на это и намекал, что если у клиентов в качестве дефолт-шлюзов стоят IP-ы соответствующих интерфейсов сервера, то всё будет работать как часы.

[Uncertainty]

А что? на iLo никак не зайти посмотреть? Не обязательно же перегружать
У вас, кстати, в таблесах грабли в виде
-A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE
У вас, судя по вашему описанию, нет сети 192.168.1.0/24

Это я неудачно прикрыл свою реальную сеть
Пользователь решил продолжить мысль 14 Октября 2010, 17:19:13:Возможно я не полностью описал задачу. Попробую ещё раз. Более детально.

Есть frontend сервер, который одним глазом смотрит в инет, а вторым в локалку.
В локалке в 192.168.10.0/24 висят backend сервера со всякими базами, файловые, апачи и т.д.
В сервера поставили iLo модули, которым присвоили адреса в сети 192.168.20.0/24

Так как в 192.168.10.0/24 находятся не только сервера, но и клиенты (внутренние, администраторы и
т.д., кому доступ нужен к backend серверам напрямую), то соответсвтенно именно
им необходим доступ к iLo. Без дополнительных "клиентских" маршрутов. А значит разруливать
должен сервер, шлюз по-умолчанию, т.е. указанный выше frontend.

На frontend у меня поднят алиас ко внутреннему интерфейсу. Так что с него я могу пинговать как
10.0/24, так и 20.0/24. Задача состоит в том, что бы это могли делать и клиенты.
Пользователь решил продолжить мысль 14 Октября 2010, 17:31:44:

FORWARD ACCEPT, ip_forward 1, так что если указать в 192.168.20.0/24 DG 192.168.20.1 должно работать

Простите, кажется Ваша мысль самая верная.
Можно подробнее, пожалуйста.

Как я ранее указал, ip_forward у меня включен.

FORWARD ACCEPT - я так понимаю это к iptables? Можно более детально, пожалуйста?

Маршрут route add -net 192.168.20.0/24 gw 192.168.20.1 я прописывал, но в ответ (на клиенте) получил:

ping 192.168.20.112
PING 192.168.20.112 (192.168.20.112) 56(84) bytes of data.
From 192.168.10.1: icmp_seq=3 Redirect Host(New nexthop: 192.168.20.112)
From 192.168.10.1: icmp_seq=6 Redirect Host(New nexthop: 192.168.20.112)

[Unreg]

можно увидеть ipconfig/ifconfig и netstat -rn с клиента из 192.168.20.0/24 ?

[fisher74]

Перевожу:

Господин Unreg Вам сказал, что у Вас

FORWARD ACCEPT

Т.е. в таблесах в цепочке FORWARD указано действие по умолчанию ACCEPT

ip_forward 1

Форвардинг у Вас тоже разрешён

так что если указать в 192.168.20.0/24 DG 192.168.20.1 должно работать

И если у клиентов в сети 192.168.20.0/24 DefaultGateway, что есть шлюз по умолчанию, выставить в 192.168.20.1, то всё будет работать.

Я Вам твержу тоже самое, Вы же зачем-то серверу указываете где находится сеть 192.168.20.0/24. Поверьте, как только он поднял интерфейс eth1:0 с указанными Вами настройками, у него маршрут в эту сеть уже появился. Вам нужно смотреть настройки КЛИЕНТОВ СЕТИ 192.168.20.0/24