Компьютерный форум OSzone.net  

Компьютерный форум OSzone.net (http://forum.oszone.net/index.php)
-   Сетевые технологии (http://forum.oszone.net/forumdisplay.php?f=31)
-   -   Динамическая маршрутизация (http://forum.oszone.net/showthread.php?t=254647)

Tonny_Bennet 22-02-2013 11:04 2096535
Динамическая маршрутизация
 
Здравствуйте.

Есть несколько офисов (читай локальных сетей /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) пакеты путешествовать не могут ибо не знают куда податься :).

Что бы решить проблему в этом примере можно в одной из клиентских сетей поднять VPN сервер и подключаться к нему из другой клиентской подсети. Получится эдакий треугольник.

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

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

cameron 22-02-2013 11:22 2096540
начнём с того, что реализация 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 22-02-2013 11:27 2096547
Цитата:
Цитата cameron
начнём с того, что реализация Site-to-Site VPN (LAN-to-LAN) через клиенское подключение и прописываение маршрутов руками неверно.
нужно делать Site-to-Site. »
Не понял что именно не так? Повторюсь что сейчас все клиентские шлюзы подключаются к шлюзу центрального офиса, скрипты сами прописывают маршруты, при падении система пытается сама переподключиться.

cameron 22-02-2013 11:29 2096548
Цитата:
Цитата Tonny_Bennet
Повторюсь что сейчас все клиентские шлюзы подключаются к шлюзу центрального офиса, скрипты сами прописывают маршруты, при падении система пытается сама переподключиться. »
тогда я вас не совсем верно поняла.
обычно это и называется Site-to-Site, тогда не нужно писать много слов, а технология становится ясной.

Tonny_Bennet 22-02-2013 11:57 2096566
cameron, всегда пытаюсь рассказать как можно подробнее.

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

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

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

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

Tonny_Bennet 22-02-2013 13:09 2096610
Цитата:
Цитата cameron
IPsec over GRE? »
Чем-то мне не нравился этот вариант и я не стал его использовать.... возможно из за отсутствия острой необходимости в таком тунеле или отсутствия опыта и страха перед последствиями ошибок.

Цитата:
Цитата cameron
я не сильна в Linux системах, но, по описанию похоже, что вы начинаете говорить о том, о чём говорила я.
вот пример
http://clauseriksen.net/2011/02/02/i...-debianubuntu/ »
За ссылку спасибо, в ночи или на выходных попробую сделать. Как заработают тунели - вернусь и будем думать, что делать с маршрутизацией :)

cameron 22-02-2013 14:02 2096669
Цитата:
Цитата Tonny_Bennet
Чем-то мне не нравился этот вариант и я не стал его использовать.... возможно из за отсутствия острой необходимости в таком тунеле или отсутствия опыта и страха перед последствиями ошибок. »
Цитата:
Цитата Tonny_Bennet
Меня не обрадовало отсутствие шифрования. »
определитесь ;)

exo 22-02-2013 14:19 2096679
Цитата:
Цитата Tonny_Bennet
В качестве шлюза везде используется Ubuntu Server. »
OpenVPN поддерживает Site-to-Site и SSL
Цитата:
Цитата Tonny_Bennet
Как заработают тунели - вернусь и будем думать, что делать с маршрутизацией »
как заработают тунели - над маршрутизацией будет думать OpenVPN... ну как и другие site-to-site шлюзы...

p.s.: русскоязычная статья про opens\wan

Tonny_Bennet 22-02-2013 14:58 2096714
exo, спасибо.

Нашёл ещё одну статью.

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

exo 22-02-2013 15:10 2096725
Цитата:
Цитата Tonny_Bennet
Но в любом случае придётся на каждом из пяти шлюзов настроить четыре интерфейса смотрящих в соседние шлюзы. »
зачем? одного, думаю, должно хватить. правил будет просто на каждую соседнюю сеть. У меня на солярке 75 туннелей было с одного интерфейса. Но там оборудование и ПО позволяли.
я сейчас параллельно буду на виртуалке пробовать настраивать.

ещё статья на IBM )

Tonny_Bennet 05-03-2013 16:14 2104697
Удалось поднять 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 05-03-2013 16:31 2104703
Цитата:
Цитата 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 05-03-2013 16:55 2104720
Цитата:
Цитата exo
Цитата:
Проверить 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
есть веб сервер в другом сегменте? »
Нет. Но если нужно - подниму.

exo 05-03-2013 17:04 2104727
Tonny_Bennet, а по какой доке настраивали?

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

Tonny_Bennet 05-03-2013 17:25 2104736
Цитата:
Цитата exo
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 05-03-2013 17:33 2104746
я в документациях видел, что этот интерфейс создаётся вручную...

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

Tonny_Bennet 05-06-2013 20:42 2162943
Сделал всё описанное при помощи tinc.

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

Официальный сайт проекта

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

exo 05-06-2013 20:53 2162946
Цитата:
Цитата Tonny_Bennet
Русскоязычная статья http://www.samag.ru/archive/article/423 »
статья за 2005 год ;)
кстати, tinc есть в PFSense

Tonny_Bennet 06-06-2013 11:41 2163181
Цитата:
Цитата exo
статья за 2005 год »
да хоть за 1998, лишь бы работало :) а у меня заработало чему я несказанно рад!

Цитата:
Цитата exo
кстати, tinc есть в PFSense »
и это хорошо


Время: 06:57.

Время: 06:57.
© OSzone.net 2001-