Роутинг между сетями на алиасе

А маска подсети какая?

А по IP принтеры и шары прицепить, получается?

Есть две подсети 192.168.10.0 и 192.168.11.0, физически на одном свитче.

То есть на любом компьютере можно поставить ip-адрес из другой сети. В чем смысл твоего роутера ?

маска 255.255.255.0

по ip не получается прицепиться, более того telnet на 139 порт компов с шарами не подцепается из другой сети, а вот с маршрутизатора - подцепается

смысл роутера в организации доступа в интернет компам этих двух подсетей.

Сделай 255.255.0.0 и будет тебе счастье, только на всех компа/роутерах/принтерах.

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

>telnet на 139 порт компов с шарами не подцепается из другой сети

Т.е. машину мы пингуем из другой сети, а телнетом к ней не можем?

Может банально брандмауер, Касперский и что еще там..., по умолчанию оно все блокирует все внешние подключения.

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

Еще, 139 не показатель, нетбиос изначально только в локальной сети, а например к порту 445 сможем подключиться?

Если у тебя включен ip_forward на Linux и для обоих сетей этот Linux хост является шлюзом, то у тебе уже всё должно работать, в противном случае ты сам что-то накрутил в правилах iptables.

ip_forward включен, маршрутизация нормально работает, из обеих сетей интернет доступен. более того! я сейчас поставил радмин на комп в 11-й подсети, и из 10-й он подключается нормально! а вот на виндовые шары заходить не хочет, хоть тресни... получается, дело не в роутинге?

к 445 порту тоже не коннектится. но вот поставил радмин - к 4899 без проблем! не пойму, в чем дело... значит, дело не в линуксе

445 важный порт, мож действительно iptables прибиты виндовые порты.

все, разобрался. не было POSTROUTING правил для 139, 445 портов. поэтому в локалке все работало, а между сетями - уже нет. спасибо всем за наводки!

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

Лучше без маскарадинга, да. Фаерволл на винде настрой, чтобы пропускал подключения.

в том-то и дело, что в винде файрволлы отключены. но доступ работает, только когда на роутере прописываю маскарадинг на внутренний интерфейс. по идее же должно хватить форварда между сетями 10.0 и 11.0. но не работает.

Значит, не отключены. Кроме виндового фаерволла у тебя может быть, например, касперский или любое другое антивирусное решение.

файрволла нет. при включении на роутере маскарадинга все работает.

Я более чем уверен, что фаерволл таки есть, но никакого желания помогать тебе разбираться с виндой у меня нет, так что дальше давай сам.

Алиасы, вроде как, являются устаревшим костылём.
Несколько IP лучше назначать средствами iproute.
Маскарадинг между подсетями — однозначное недоразумение.
Фаерволы на венде всё-таки проверьте:

netsh fi sh co v=e

да что их проверять, я точно знаю, что на винде нет файрволла по той простой причине, что его сервис даже не запущен. сдается мне, дело в iptables, но там все просто, тупо добавлял форвард для всех

iptables -A FORWARD -i eth0 -j ACCEPT

iptables -A FORWARD -o eth0 -j ACCEPT

или так

-A FORWARD -s 192.168.10.0/24 -d 192.168.11.0/24 -j ACCEPT.

не работает. А если замаскарадить

-A POSTROUTING -s 192.168.10.0/24 -o eth0 -j MASQUERADE

все прекрасно работает. но как-то неправильно это.

Насчет алиаса - знаю, что устаревшая штука, но до сих пор прекрасно работала.

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

Блин, даже не знаю. Сейчас еще раз проверю. Но как может файрволл влиять, если его сервис даже не запущен. Антивирь стоит др веб, без брандмауэра, только спайдер запущен. Его пробовал стопить - не влияет. А маскарад я в дополнение к форварду делаю.

Чудес не бывает.
Это либо проблема с фаерволом на венде/линуксе, либо с маршрутизацией.
Например, в первой сети этот роутер является дефолтным шлюзом, а во второй — нет, поэтому пинг идёт только при маскарадинге.

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

то есть это не виндовый файрволл 200%.

это что-то с iptables, но вот что - не пойму.

не работают правила FORWARD почему-то между 10.0 и 11.0

может, что-то связанное с алиасом?

да, шлюз везде корректно прописан. в 10-й сети 10-й, в 11 - 11-й.

...либо с маршрутизацией.
Например, в первой сети этот роутер является дефолтным шлюзом, а во второй — нет, поэтому пинг идёт только при маскарадинге.

У него пинг без маскарада работает.

Хотя пинги ходят между хостами обеих подсетей нормально. подскажите, куда копать.

Сделай проще, на выбор:
1. загрузить не вин машину
2. загрузиться с live не винды
я практически уверен что будет все работать

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

Разумеется, NAT не нужен тут. Что-то где-то не так. И да, tcpdump должен, как обычно, помочь понять, что происходит. На win можно wireshark.

сдается мне, дело в iptables

Отключи совсем на время разбора. iptables тут не требуется ни в каком виде.

пинг работает тоже через маскарад, как оказалось. сделано было, чтоб сайты пинговать. если маскарад убрать - пинг не работает между 10.0 и 11.0

отладка осложняется тем, что сервер боевой, много народу работает в онлайне. пробую правила по одному убирать, уже приходилось к серверу ездить через консоль восстанивливать)

Короче, оставил только внутренние правила для отладки

-A FORWARD -s 192.168.10.0/255.255.255.0 -d 192.168.11.0/255.255.255.0 -i eth0 -o eth0 -j ACCEPT. -A FORWARD -s 192.168.11.0/255.255.255.0 -d 192.168.10.0/255.255.255.0 -i eth0 -o eth0 -j ACCEPT -A FORWARD -j DROP

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

много народу работает в онлайне.

А ночью ?

уже приходилось к серверу ездить через консоль восстанивливать)

В соседнем screen-е надо написать что-то вроде
sleep 3600 && reboot

Ну и ничего не записывать, разумеется.

Нарисовал бы ты схему, что бы всем понятнее стало.
Пока просто спрошу:
Какой ip у сервера в сети 192.168.10.0/24 ?
Какой ip шлюза у клиентов в сети 192.168.10.0/24 ?
Какой ip у сервера в сети 192.168.11.0/24 ?
Какой ip шлюза у клиентов в сети 192.168.11.0/24 ?
Что говорит tcpdump на сервере при пинге из одной сети в другую и наоборот (при отключенном маскараде)?

В соседнем screen-е надо написать что-то вроде
sleep 3600 && reboot
Ну и ничего не записывать, разумеется.

Плюсую. Только я в крон прописываю (и обычно критические вещи, там где накосячить можно, занимают меньше часа так что ограничиваюсь 15-30 минутами), скрин после очередного ребута можно забыть заново запустить.
А что бы уже совсем с эпоскидкой и тремя презервативами, можно конфиги из резервной копии назад копировать.

может, алиас не поддерживает роутинг между основным адаптером и алиасом?

Работает, инфа 100%.

Гаданием на кофейной гуще заниматься непродуктивно.
Надо смотреть диагностику с сервера (роутера) и клиентов:

ip a; ip r; sudo iptables-save
ipconfig /all & route print

Какой ip у сервера в сети 192.168.10.0/24 ?
Какой ip шлюза у клиентов в сети 192.168.10.0/24 ?
Какой ip у сервера в сети 192.168.11.0/24 ?
Какой ip шлюза у клиентов в сети 192.168.11.0/24 ?
Что говорит tcpdump на сервере при пинге из одной сети в другую и наоборот (при отключенном маскараде)?

ip сервера 192.168.10.254 и 192.168.11.254 шлюзом он прописан, естественно, у всех клиентов в соответствующих подсетях, в 10-й подсети прописан 10.254, в 11-й прописан 11.254 tcpdump при пинге показывает все нормально, ну это и неудивительно, т.к. с сервером соединения есть из обеих подсетей, нет связи между сетями.

14:19:06.241211 IP pool-192.168.11.41.local > 192.168.11.254: ICMP echo request, id 1, seq 5, length 40 14:19:06.241245 IP 192.168.11.254 > pool-192.168.11.41.local: ICMP echo reply, id 1, seq 5, length 40

Повторю: tcpdump «при пинге из одной сети в другую и наоборот», а не пинг до сервера. Да и запускайте его с -n а то читать имена в постах неудобно.

сорри, невнимательно прочитал. вот tcpdump при пинге из 10 в 11

# tcpdump icmp -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
14:33:06.176623 IP 192.168.10.21 > 192.168.11.41: ICMP echo request, id 512, seq 5376, length 40
14:33:06.176655 IP 192.168.10.254 > 192.168.10.21: ICMP redirect 192.168.11.41 to host 192.168.11.41, length 68
14:33:06.176660 IP 192.168.10.21 > 192.168.11.41: ICMP echo request, id 512, seq 5376, length 40
14:33:11.299297 IP 192.168.10.21 > 192.168.11.41: ICMP echo request, id 512, seq 5632, length 40
14:33:11.299327 IP 192.168.10.254 > 192.168.10.21: ICMP redirect 192.168.11.41 to host 192.168.11.41, length 68
14:33:11.299332 IP 192.168.10.21 > 192.168.11.41: ICMP echo request, id 512, seq 5632, length 40
14:33:16.799298 IP 192.168.10.21 > 192.168.11.41: ICMP echo request, id 512, seq 5888, length 40
14:33:16.799331 IP 192.168.10.254 > 192.168.10.21: ICMP redirect 192.168.11.41 to host 192.168.11.41, length 68
14:33:16.799336 IP 192.168.10.21 > 192.168.11.41: ICMP echo request, id 512, seq 5888, length 40
14:33:22.299333 IP 192.168.10.21 > 192.168.11.41: ICMP echo request, id 512, seq 6144, length 40
14:33:22.299365 IP 192.168.10.254 > 192.168.10.21: ICMP redirect 192.168.11.41 to host 192.168.11.41, length 68
14:33:22.299370 IP 192.168.10.21 > 192.168.11.41: ICMP echo request, id 512, seq 6144, length 40
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel

net.ipv4.conf.*.shared_media - в 0 попробуйте поставить

на вид ничего не поменялось

Хм, а должно было. Тогда можно еще net.ipv4.conf.*.send_redirects так же в 0

То же самое. А что должно быть? Вроде ничего не поменялось. sysctl -w сразу действует, network рестартовать не надо, насколько я понимаю?

вот вывод ip (внешний адрес убрал)

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
    inet 127.0.0.2/8 brd 127.255.255.255 scope host secondary lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    inet 192.168.10.254/24 brd 192.168.10.255 scope global eth0
    inet 192.168.11.254/24 brd 192.168.11.255 scope global eth0:0
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    inet my_external_ip/24 brd my_external_ip scope global eth1
       valid_lft forever preferred_lft forever

# ip r
my_external_ip/24 dev eth1  proto kernel  scope link  src my_external_ip
192.168.11.0/24 dev eth0  proto kernel  scope link  src 192.168.11.254
192.168.10.0/24 dev eth0  proto kernel  scope link  src 192.168.10.254
169.254.0.0/16 dev eth0  scope link
127.0.0.0/8 dev lo  scope link
default via my_external_ip dev eth1

ICMP редирект должен был перестать слать.

sysctl -w сразу действует, network рестартовать не надо, насколько я понимаю?

Да вроде как да. Посмотрите на всякий случай в файликах /proc/sys/net/ipv4/conf/....
Вот явно дело в какой-то ерунде. Но чего-то мне в голову ничего не приходит. У меня почти подобная же фигня работает вполне нормально и далеко не первый год, две маленькие подсетки с реальными ip висят и я не помню что бы специально что-то для этого делал.

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