Динамическая маршрутизация

[Tonny_Bennet]

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

Есть несколько офисов (читай локальных сетей /24), подключенных к различным провайдерам. У некоторых из офисов есть несколько каналов в интернет. В качестве шлюза везде используется Ubuntu Server. Между центральным офисом и филиалами настроены VPN каналы с настроенной статической маршрутизацией, т.е. при подключении клиента на сервере прописывается маршрут в клиентскую сеть. Рассмотрим пример из трёх филиалов:

Центральный офис 192.168.0.0/24
Первый филиал 192.168.3.0/24
Второй филиал 192.168.4.0/24

У центрального офиса есть два канала в интернет; у оставшихся по одному. Клиентские шлюзы (192.168.3.1, 192.168.4.1) подключаются к VPN серверу (VPN сеть 192.168.2.0/24), а именно к одному внешнему интерфейсу шлюза центрального офиса (192.168.0.10). Т.о. пакеты свободно попадают из сети 192.168.0.0/24 в сети 192.168.3.0/24 и 192.168.4.0/24, и из клиентских сетей в сеть центрального офиса. Но вот между клиентскими сетями (192.168.3.0/24 и 192.168.4.0/24) пакеты путешествовать не могут ибо не знают куда податься :).
http://i060.radikal.ru/1302/50/a12b541533a5.jpg (http://www.radikal.ru)
Что бы решить проблему в этом примере можно в одной из клиентских сетей поднять VPN сервер и подключаться к нему из другой клиентской подсети. Получится эдакий треугольник.
http://s017.radikal.ru/i413/1302/44/67a504eec55f.jpg (http://www.radikal.ru)
Можно завернуть трафик через центральный офис, но каналы не безграничны и гонять трафик просто так не хочется.

Возникает, как мне кажется, нормальный вопрос: как организовать маршрутизацию между несколькими локальными сетями (реально их 5), подключенными к различным провайдерам, не создавая в сети центральной точки маршрутизации трафика?

[cameron]

начнём с того, что реализация Site-to-Site VPN (LAN-to-LAN) через клиенское подключение и прописываение маршрутов руками неверно.
нужно делать Site-to-Site.
далее у вас появлется адекватная таблица маршрутизации, в которой всем понятко куда и откуда нужно бегать.
соотно в вашей схеме я вижу 3 Site-to-Site туннеля:
192.168.0.0/24 <->192.168.4.0/24
192.168.0.0/24 <->192.168.3.0/24
192.168.3.0/24 <->192.168.4.0/24
тогда, конечно же, не придётся гонять траффик через основной офис (192.168.0.0/24)

а по вопросу динамической маршрутизации - я бы выбрала либо несколько шлюзов с разными метриками, либо аналоги IP-SLA(cisco)/ip-monitoing(juniper), когда делаются два туннеля и в определённых условиях (нет пинга, к примеру) в таблицу маршрутизации заносятся изменения.
Можно, так же, рассмотреть OSPF или BGP.

[Tonny_Bennet]

начнём с того, что реализация Site-to-Site VPN (LAN-to-LAN) через клиенское подключение и прописываение маршрутов руками неверно.
нужно делать Site-to-Site. »

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

[cameron]

Повторюсь что сейчас все клиентские шлюзы подключаются к шлюзу центрального офиса, скрипты сами прописывают маршруты, при падении система пытается сама переподключиться. »
тогда я вас не совсем верно поняла.
обычно это и называется Site-to-Site, тогда не нужно писать много слов, а технология становится ясной.

[Tonny_Bennet]

cameron, всегда пытаюсь рассказать как можно подробнее.

Ваше сообщение, меня натолкнуло на мысль поднятия туннеля. Т.е. сейчас есть сервер, есть клиент, логины пароли и процедура авторизации. И при падении клиент должен заново инициализировать соединение. Когда-то я настраивал GRE туннель между двумя Linux системами. В системе он определялся просто как интерфейс tun0. В настройках интерфейса указывались внешние адреса двух взаимодействующих серверов. И, как я понимаю, пакетам просто добавлялся заголовок и пакет передавался на внешний интерфейс второго сервера. Сервер приняв такой пакет снимал заголовок и маршрутизировал дальше. Меня не обрадовало отсутствие шифрования.

Если есть мысли по этому вопросу - прошу озвучить ;)

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

[cameron]

И при падении клиент должен заново инициализировать соединение. Когда-то я настраивал GRE туннель между двумя Linux системами. В системе он определялся просто как интерфейс tun0. В настройках интерфейса указывались внешние адреса двух взаимодействующих серверов. И, как я понимаю, пакетам просто добавлялся заголовок и пакет передавался на внешний интерфейс второго сервера. Сервер приняв такой пакет снимал заголовок и маршрутизировал дальше. »
похоже что, наконец, мы сошлись в понимании процесса.
Меня не обрадовало отсутствие шифрования. »
IPsec over GRE?
По идее мне бы сначала найти вариант передачи трафика между сетями с минимальными количеством настроек на точках, »
я не сильна в Linux системах, но, по описанию похоже, что вы начинаете говорить о том, о чём говорила я.
вот пример
http://clauseriksen.net/2011/02/02/ipsec-on-debianubuntu/

[Tonny_Bennet]

IPsec over GRE? »
Чем-то мне не нравился этот вариант и я не стал его использовать.... возможно из за отсутствия острой необходимости в таком тунеле или отсутствия опыта и страха перед последствиями ошибок.

я не сильна в Linux системах, но, по описанию похоже, что вы начинаете говорить о том, о чём говорила я.
вот пример
http://clauseriksen.net/2011/02/02/i...-debianubuntu/ »

За ссылку спасибо, в ночи или на выходных попробую сделать. Как заработают тунели - вернусь и будем думать, что делать с маршрутизацией :)

[cameron]

Чем-то мне не нравился этот вариант и я не стал его использовать.... возможно из за отсутствия острой необходимости в таком тунеле или отсутствия опыта и страха перед последствиями ошибок. »
Меня не обрадовало отсутствие шифрования. »
определитесь ;)

[exo]

В качестве шлюза везде используется Ubuntu Server. »
OpenVPN (http://openvpn.net/index.php/access-server/section-faq-openvpn-as/27-server-config/209-how-do-i-setup-openvpn-access-server-to-use-site-to-site.html) поддерживает Site-to-Site и SSL
Как заработают тунели - вернусь и будем думать, что делать с маршрутизацией »
как заработают тунели - над маршрутизацией будет думать OpenVPN... ну как и другие site-to-site шлюзы...

p.s.: русскоязычная (http://www.opennet.ru/base/net/openswan_tunnel.txt.html) статья про opens\wan

[Tonny_Bennet]

exo, спасибо.

Нашёл ещё одну статью (http://bespud.ru/administrirovanie/ubuntu-ospf-%D0%BF%D0%BE%D0%B2%D0%B5%D1%80%D1%85-ipsec).

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

[exo]

Но в любом случае придётся на каждом из пяти шлюзов настроить четыре интерфейса смотрящих в соседние шлюзы. »
зачем? одного, думаю, должно хватить. правил будет просто на каждую соседнюю сеть. У меня на солярке 75 туннелей было с одного интерфейса. Но там оборудование и ПО (http://www.s-terra.com/products/productline/server) позволяли.
я сейчас параллельно буду на виртуалке пробовать настраивать.

ещё статья на IBM (http://www.ibm.com/developerworks/ru/library/os-ipsec/) )

[Tonny_Bennet]

Удалось поднять ipsec-туннель между шлюзами. Трафик от клиента одной сети до клиента другой сети ходит нормально.

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


# ifconfig
eth0 Link encap:Ethernet HWaddr 1a:8c:69:28:80:f4
inet addr:192.168.6.1 Bcast:192.168.6.255 Mask:255.255.255.0
inet6 addr: fe80::188c:69ff:fe28:80f4/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:338 errors:0 dropped:0 overruns:0 frame:0
TX packets:357 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:130490 (130.4 KB) TX bytes:66233 (66.2 KB)

eth1 Link encap:Ethernet HWaddr 42:41:d9:a0:ba:80
inet addr:XXX.XXX.XXX.XXX Bcast:YYY.YYY.YYY.YYY Mask:255.255.255.252
inet6 addr: fe80::4041:d9ff:fea0:ba80/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5614 errors:0 dropped:1345 overruns:0 frame:0
TX packets:4024 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:530329 (530.3 KB) TX bytes:1078878 (1.0 MB)

# tcpdump -i eth1 -A -vvv 'src host 192.168.0.97 and proto \icmp'
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
16:12:50.276463 IP (tos 0x0, ttl 127, id 5818, offset 0, flags [none], proto ICMP (1), length 60)
192.168.0.97 > vlg-mail: ICMP echo request, id 1, seq 82, length 40
E..<.......T...a......M ...Rabcdefghijklmnopqrstuvwabcdefghi
16:12:51.266487 IP (tos 0x0, ttl 127, id 5826, offset 0, flags [none], proto ICMP (1), length 60)
192.168.0.97 > vlg-mail: ICMP echo request, id 1, seq 83, length 40
E..<.......L...a......M....Sabcdefghijklmnopqrstuvwabcdefghi
16:12:52.267479 IP (tos 0x0, ttl 127, id 5830, offset 0, flags [none], proto ICMP (1), length 60)
192.168.0.97 > vlg-mail: ICMP echo request, id 1, seq 84, length 40
E..<.......H...a......M....Tabcdefghijklmnopqrstuvwabcdefghi
16:12:53.267241 IP (tos 0x0, ttl 127, id 5834, offset 0, flags [none], proto ICMP (1), length 60)
192.168.0.97 > vlg-mail: ICMP echo request, id 1, seq 85, length 40
E..<.......D...a......M....Uabcdefghijklmnopqrstuvwabcdefghi
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

[exo]

ещё статья на IBM ) »
Проверить IPsec-соединение можно запуском утилиты tcpdump, например так: tcpdump -n -i eth0 host my_net1.com.
Пакет должен содержать заголовок AH и данные ESP. При этом наличие ESP будет означать, что шифрование работает. Ниже показан пример просмотра такого пакета из установленного соединения:
12:24:26.155529 my_net2.com > my_net1.com: AH(spi=0x021c9834,seq=0x358): \
my_net2.com > my_net1.com: ESP(spi=0x00c887ad,seq=0x358) (DF) \
(ipip-proto-4)
есть веб сервер в другом сегменте?

[Tonny_Bennet]

Цитата:
Проверить IPsec-соединение можно запуском утилиты tcpdump, например так: tcpdump -n -i eth0 host my_net1.com.
Пакет должен содержать заголовок AH и данные ESP. При этом наличие ESP будет означать, что шифрование работает. Ниже показан пример просмотра такого пакета из установленного соединения:
12:24:26.155529 my_net2.com > my_net1.com: AH(spi=0x021c9834,seq=0x358): \
my_net2.com > my_net1.com: ESP(spi=0x00c887ad,seq=0x358) (DF) \
(ipip-proto-4) »

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

есть веб сервер в другом сегменте? »
Нет. Но если нужно - подниму.

[exo]

Tonny_Bennet, а по какой доке настраивали?

веб-сервер просто для проверки, вместо банального ping

[Tonny_Bennet]

Tonny_Bennet, а по какой доке настраивали? »
http://www.opennet.ru/base/net/openswan_tunnel.txt.html

там в конце стати автор дампит пакеты на интерфейсе ipsec0, который у меня не появляется

В случае, если IpSec работает корректно, вы должны наблюдать примерно
следующую картину:

19:16:32.046220 192.168.0.2 > 192.168.99.9: ESP(spi=0 *3be6c4dc,seq=0 *3)
19:16:32.085630 192.168.99.9 > 192.168.0.2: ESP(spi=0 *5fdd1cf8,seq=0 *6)

[exo]

я в документациях видел, что этот интерфейс создаётся вручную...

[Tonny_Bennet]

Я сейчас увидел что на каждом шлюзе вывод ipsec showhostkey --left не отличается от ipsec showhostkey --right. А из контекста кажется что "правая" и "левая" часть ключа должны быть разными.

[Tonny_Bennet]

Сделал всё описанное при помощи tinc.

Русскоязычная статья http://www.samag.ru/archive/article/423

Официальный сайт проекта (http://www.tinc-vpn.org/)

В итоге сейчас связаны пять сетей /24 на каждом шлюзе по одному интерфейсу.

[exo]

Русскоязычная статья http://www.samag.ru/archive/article/423 »
статья за 2005 год ;)
кстати, tinc есть в PFSense