Вопрос про роутинг

[andrey465]

Здравствуйте!

Объясните пожалуйста следующую ситуацию:

Имеем стандартную конфигурацию сети - локальная сеть (192.168.1.0/24), интернет любым вариантом подключения, как минимум два компьютера - собственно роутер(192.168.1.1) и клиент (192.168.1.2) (оба на линуксе). Все работает, натится, пингуется, порты при необходимости пробрасываются и т.д.

Ситуация чуть меняется - на роутере подключается дополнительная сеть(10.128.0.10/8) (например какой нибудь туннель куда нибудь).
Настраивается нат, разрешения, маршруты на роутере. Опять же - с роутера все пингуется, натится и т.д. Но вот не задача - клиент знать не знает ни про какой туннель (все маршурты на роутере и все разрешения имеются). Все это долго тестится/отлаживается с целью выяснить что и где забыли. В конце концов выясняется что при добавлении на клиент маршрута в туннель через роутер (10.128.0.0/8 via 192.168.1.1) все начинает работать как по маслу.

Собственно вопрос - как же так?

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

Код: [Выделить]

192.168.1.0/24 dev eth0 src 192.168.1.2
default via 192.168.1.1
тоесть, если адрес не найден в локальной сети то маршрут спрашивается у роутера.
А тут получается что без добавления нового маршрута

Код: [Выделить]

192.168.1.0/24 dev eth0 src 192.168.1.2
10.128.0.0/8 via 192.168.1.1
default via 192.168.1.1
клиент сам не видет сеть и не собирается спрашивать у роутера.

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

[_set_]

http://www.opennet.ru/base/net/ubuntu_route.txt.html

[andrey465]

Я так понял правило "если адрес не найден в локальной сети то маршрут спрашивается у роутера" действует только в одной подсети (локальная сеть или интернет), если же добавляется подсеть с другим адресным пространством то для ее работы нужны маршруты на каждом клиенте?

[fisher74]

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

[andrey465]

Роутер Ubuntu 11.04
на нем:
   Интернет
   Локальная сеть 192.168.1.0/24 адрес 192.168.1.1
   VPN pptp 10.128.0.0/24 адрес 10.128.0.1 (является vpn сервером)

Клиент в локальной сети Suse Linux
   адрес 192.168.1.2

Клиент в VPN сети Windows 7

Предположим что правила iptables чисты (политики везде ACCEPT), за исключением маскардинга и включенного форвардинга.
Подключается VPN клиент, получает адрес (например 10.128.0.10), адрес шлюза соответственно 10.128.0.1.
Проверяем, VPN клиент успешно пингует локальную сеть, роутер соответственно успешно пингует VPN клиента,
клиент в локальной сети не может пропинговать VPN клиента (пишет Destination Host Unreachable), conntrack на роутере не фиксирует запросов от клиента (я так понимаю что запросы даже не попадают на роутер).
Добавляем "маршрут с шлюзом на дефолтный шлюз" - работает.

Далее, первый ответ навел на мысль переделать конфигурацию VPN - настроить так, чтобы она маршрутизировалась как часть локальной сети - меняем адрес сервера в VPN на 192.168.1.1 и собственно выделяем для VPN клиентов адреса 192.168.1.100-150.
Попытка номер два ("спец маршрут" на локальном клиенте заранее удален) - VPN клиент подключается, получает адрес 192.168.1.100 и шлюз 192.168.1.1  - все пингуется, все друг друга видят.

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

[drako]

Предположим что правила iptables чисты (политики везде ACCEPT), за исключением маскардинга и включенного форвардинга.

Давайте теоретизирование оставим преподавателям в высших учебных заведениях - это их хлеб, а сами углубимся в конкретику настройки конкретного железа...
Кажите iptables-save, route -n, ifconfig -a для начала.

[fisher74]

Ни разу с такой проблемой не сталкивался, хотя роутеров настроил достаточно...
Всё-таки было бы интересно посмотреть tracepath до клиента VPN

Боюсь, что ТС проблему решил обошедши её изменением структуры сети, и вопрос перешёл в статус [Решено]

[andrey465]

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

ifconfig -a
eth0      Link encap:Ethernet  HWaddr f4:6d:04:31:bd:9d
          inet addr:10.0.5.2  Bcast:10.255.255.255  Mask:255.0.0.0
          inet6 addr: fe80::f66d:4ff:fe31:bd9d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:159989347 errors:0 dropped:0 overruns:0 frame:0
          TX packets:147886526 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:30006954301 (27.9 GiB)  TX bytes:22179281081 (20.6 GiB)
          Interrupt:30 Base address:0xc000

eth1      Link encap:Ethernet  HWaddr 1c:bd:b9:e7:7b:22
          inet addr:192.168.6.2  Bcast:192.168.6.255  Mask:255.255.255.0
          inet6 addr: fe80::1ebd:b9ff:fee7:7b22/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:8038667 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7442181 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2653823511 (2.4 GiB)  TX bytes:2606417964 (2.4 GiB)
          Interrupt:16 Base address:0xd000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:10885706 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10885706 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1237634745 (1.1 GiB)  TX bytes:1237634745 (1.1 GiB)

ppp0      Link encap:Point-to-Point Protocol
          inet addr:XXXXXXXXXXXX  P-t-P:10.153.0.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:7820702 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7261934 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:2458823462 (2.2 GiB)  TX bytes:2438114481 (2.2 GiB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.5.0.46  P-t-P:10.5.0.45  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:673336 errors:0 dropped:0 overruns:0 frame:0
          TX packets:675304 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:59150866 (56.4 MiB)  TX bytes:262112794 (249.9 MiB)
 
 
 
# Generated by iptables-save v1.4.8 on Thu Nov 17 23:55:59 2011
*nat
:PREROUTING ACCEPT [782935:265098721]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [566780:48078796]
:vpnnat - [0:0]
-A PREROUTING -i tun0 -j vpnnat
-A POSTROUTING -j MASQUERADE
-A POSTROUTING -o tun0 -j vpnnat
-A vpnnat -s 10.0.5.0/24 -j NETMAP --to 10.13.7.0/24
-A vpnnat -d 10.13.7.0/24 -j NETMAP --to 10.0.5.0/24
COMMIT
# Completed on Thu Nov 17 23:55:59 2011
# Generated by iptables-save v1.4.8 on Thu Nov 17 23:55:59 2011
*filter
:INPUT DROP [467355:230875956]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [121876649:18154844988]
:fail2ban-apache - [0:0]
:fail2ban-pam-generic - [0:0]
:fail2ban-ssh - [0:0]
:fail2ban-vsftpd - [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p udp -m udp --sport 53 -j ACCEPT
-A INPUT -p udp -m udp --sport 123 -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -s XXXXXXXXXXXXX -j ACCEPT
-A INPUT -s 10.0.0.0/8 -j ACCEPT
-A INPUT -s XXXXXXXXXXXXX -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p udp -m udp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p udp -m udp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp -m multiport --dports XXXXXXXXX -j ACCEPT
-A INPUT -p udp -m udp -m multiport --dports XXXXXXXXX -j ACCEPT
-A INPUT -p tcp -m tcp --dport XXXX -j ACCEPT
-A INPUT -p udp -m udp --dport XXXX -j ACCEPT
-A INPUT -i eth0 -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A FORWARD -s 10.0.5.1/32 -j ACCEPT
-A FORWARD -s 10.0.1.42/32 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A fail2ban-apache -j RETURN
-A fail2ban-pam-generic -j RETURN
-A fail2ban-ssh -j RETURN
-A fail2ban-vsftpd -j RETURN
COMMIT
# Completed on Thu Nov 17 23:55:59 2011
# Generated by iptables-save v1.4.8 on Thu Nov 17 23:55:59 2011
*mangle
:PREROUTING ACCEPT [131166287:23766924318]
:INPUT ACCEPT [130421215:23621736963]
:FORWARD ACCEPT [689134:140927436]
:OUTPUT ACCEPT [121877877:18154973620]
:POSTROUTING ACCEPT [122596355:18299100507]
-A PREROUTING -i ppp0 -j CONNMARK --set-xmark 0x1/0xffffffff
-A PREROUTING -i eth0 -j CONNMARK --set-xmark 0x2/0xffffffff
-A PREROUTING -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff
-A PREROUTING -m mark --mark 0x0 -j MARK --set-xmark 0x1/0xffffffff
-A OUTPUT -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff
-A OUTPUT -m mark --mark 0x0 -j MARK --set-xmark 0x1/0xffffffff
COMMIT




route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.5.0.45       0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.153.0.1      0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
192.168.6.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
10.5.0.0        10.5.0.45       255.255.255.0   UG    0      0        0 tun0
10.13.0.0       10.5.0.45       255.255.0.0     UG    0      0        0 tun0
10.0.0.0        0.0.0.0         255.0.0.0       U     0      0        0 eth0
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 lo


это параметры упомянутого роутера на Debian 6
к сожалению не могу дать конфиг роутера на Ubuntu так как там оч много придется крестиками закрывать

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

ifconfig -a
eth0      Link encap:Ethernet  HWaddr f4:6d:04:31:bd:99
          inet addr:10.0.5.1  Bcast:10.255.255.255  Mask:255.0.0.0
          inet6 addr: fe80::f66d:4ff:fe31:bd99/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:94618773 errors:0 dropped:0 overruns:0 frame:0
          TX packets:88128148 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:9151550122 (8.5 GiB)  TX bytes:24737729999 (23.0 GiB)
          Interrupt:30 Base address:0xc000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1233874 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1233874 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:155432120 (148.2 MiB)  TX bytes:155432120 (148.2 MiB)

 
route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.5.0.0        10.0.5.2        255.255.255.0   UG    0      0        0 eth0
10.13.0.0       10.0.5.2        255.255.0.0     UG    0      0        0 eth0
10.0.0.0        0.0.0.0         255.0.0.0       U     0      0        0 eth0
0.0.0.0         10.0.5.2        0.0.0.0         UG    0      0        0 eth0

это соответственно параметры клиента Debian 6
iptables-save ничего не выдал (таблицы пусты) первые две строчки в route -n добавил я чтобы обойти обсуждаемую проблему

Всё-таки было бы интересно посмотреть tracepath до клиента VPN

я так понимаю от клиента в локальной сети до клиента в VPN? без строчек в роутинге или фокусами с конфигурацией VPN trace молчит как и ping (даже ответа роутера нет)

[drako]

Подсети на сервере "порадовали" неудивительно что на клиенте приходится маршруты добавлять... Это -A POSTROUTING -j MASQUERADE тоже "красиво"...

P.S. Для тех кто не понял - сети 10.13.0.0/16 и 10.5.0.0/24 являются частью сети 10.0.0.0/8, поэтому комп и не пытается обраться к шлюзу, поскольку маршрут уже есть.

[fisher74]

Потому и просил конкретику. Сразу расставились все точки над i

А вот кто прояснит про дефолтный маршрут на роутере? Это результат iproute2?

[andrey465]

А вот кто прояснит про дефолтный маршрут на роутере? Это результат iproute2?

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

Подсети на сервере "порадовали" неудивительно что на клиенте приходится маршруты добавлять... Это -A POSTROUTING -j MASQUERADE тоже "красиво"...

P.S. Для тех кто не понял - сети 10.13.0.0/16 и 10.5.0.0/24 являются частью сети 10.0.0.0/8, поэтому комп и не пытается обраться к шлюзу, поскольку маршрут уже есть.

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

[fisher74]

а в основной таблице ставлю маршрут по умолчанию - lo чтоб им никто воспользоватся не мог

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

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

Да у Вас, батенька, с осознанием сети совсем беда. Бегом изучать построение сетей: адресация, маски.

И, кстати, клиенты у маршрутизатора не спрашивают маршрут, а работают через него. Т.е. если в локальной таблице маршрутизации указано идти на шлюз, то и пакеты идут туда, а уже маршрутизатор принимает решение в какую стоону эти пакеты направить.

ЗЫ Хотя есть некий механизм для снижения нагрузки на роутер в случае нахождения абонентов (или ещё одного шлюза с абонентом) в одной физической сети, но это совсем другая история.

[andrey465]

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

интересный вариант, попробую

Да у Вас, батенька, с осознанием сети совсем беда. Бегом изучать построение сетей: адресация, маски.

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

Всем большое спасибо за консультацию!