VPN Site-to-Site (Ubuntu Server ipsec)

[TonnyBennet]

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

Есть пять сетей /24 с шлюзами под Ubuntu Server, между которыми нужно сделать VPN тунели Site-to-Site. Сейчас в одном офисе поднят pptpd сервер, остальные четыре поднимают к нему клиентские подключения. Соответственно трафик ходит между клиентом и сервером отлично. Для обмена трафиком между двумя клиентами нужно гонять его через сервер, что не совсем приятно. При падении туннели не всегда сами поднимаются.

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

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

Опять же к слову: как быть если таких сетей не пять а сто? не поднимать же по сто туннельных интерфейсов между шлюзами? Как выкручиваются в таких ситуациях?

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

Поделитесь пожалуйста опытом. Кто и как реализовывал подобные схемы. Подскажите пожалуйста можно ли заставить ipsec создавать виртуальные интерфейсы.

[Bizdelnick]

Есть такая штука - http://www.tinc-vpn.org/. Сам, правда, дела с ней не имел - просто необходимости не возникало. Но Вам, возможно, подойдёт.

[TonnyBennet]

Есть такая штука - http://www.tinc-vpn.org/. Сам, правда, дела с ней не имел - просто необходимости не возникало. Но Вам, возможно, подойдёт.

Уже пробовал tinc, но настроить толком не получилось. Сейчас пришло новое виденье проблемы и решил попробовать снова. Подключение проходит. Интерфейсы создаются. Маршрут есть. А пакеты не ходят... гуглю

[TonnyBennet]

Сделал по примеру

В итоге из одной сети в другую пакеты ходят. А с шлюза в соседние сети пинги не проходят...

[nerve]

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

[TonnyBennet]

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

У меня есть сеть 192.168.0.0/24 с шлюзом 192.168.0.10. И есть сеть 192.168.3.0/24 с шлюзом 192.168.3.1.

На шлюзе в первой сети vpn интерфейс имеет адрес 192.168.10.1; во второй сети 192.168.10.3; (оба интерфейса в сети 192.168.0.0/16)

В конфигурационных файлах хостов указаны только сети 192.168.0.0/24 и 192.168.3.0/24. И соответственно между сетями трафик ходит.

При попытке с шлюза 192.168.0.10 пропинговать адрес из сети 192.168.3.0/24, пакет отправляется с интерфейса 192.168.10.1.

[Sleeping Daemon]

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

У меня есть сеть 192.168.0.0/24 с шлюзом 192.168.0.10. И есть сеть 192.168.3.0/24 с шлюзом 192.168.3.1.

На шлюзе в первой сети vpn интерфейс имеет адрес 192.168.10.1; во второй сети 192.168.10.3; (оба интерфейса в сети 192.168.0.0/16)

В конфигурационных файлах хостов указаны только сети 192.168.0.0/24 и 192.168.3.0/24. И соответственно между сетями трафик ходит.

При попытке с шлюза 192.168.0.10 пропинговать адрес из сети 192.168.3.0/24, пакет отправляется с интерфейса 192.168.10.1.

ip ro ls в студию на 0.10

[TonnyBennet]

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

У меня есть сеть 192.168.0.0/24 с шлюзом 192.168.0.10. И есть сеть 192.168.3.0/24 с шлюзом 192.168.3.1.

На шлюзе в первой сети vpn интерфейс имеет адрес 192.168.10.1; во второй сети 192.168.10.3; (оба интерфейса в сети 192.168.0.0/16)

В конфигурационных файлах хостов указаны только сети 192.168.0.0/24 и 192.168.3.0/24. И соответственно между сетями трафик ходит.

При попытке с шлюза 192.168.0.10 пропинговать адрес из сети 192.168.3.0/24, пакет отправляется с интерфейса 192.168.10.1.

ip ro ls в студию на 0.10

Код:

ip route default dev ppp0 scope link realm 6 127.0.0.0/8 dev lo scope link realm 6 172.0.0.0/30 via 192.168.0.12 dev eth0 realm 6 192.168.0.0/28 dev eth0 scope link realm 6 192.168.0.0/16 dev vpn_net proto kernel scope link src 192.168.10.1 192.168.0.14 dev ppp1 proto kernel scope link src 192.168.2.1 192.168.0.32/28 dev eth0 scope link realm 6 192.168.0.64/29 dev eth0 scope link realm 6 192.168.0.80/29 dev eth0 scope link realm 6 192.168.0.96/29 dev eth0 scope link realm 6 192.168.0.112/29 dev eth0 scope link realm 6 192.168.0.128/28 dev eth0 scope link realm 6 192.168.0.160/28 dev eth0 scope link realm 6 192.168.0.192/29 dev eth0 scope link realm 6 192.168.0.208/30 dev eth0 scope link realm 6 192.168.0.216/30 dev eth0 scope link realm 6 192.168.0.224/27 dev eth0 scope link realm 6

Код:

route -n Таблица маршутизации ядра протокола IP Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 172.0.0.0 192.168.0.12 255.255.255.252 UG 0 0 0 eth0 192.168.0.0 0.0.0.0 255.255.255.240 U 0 0 0 eth0 192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 vpn_net 192.168.0.14 0.0.0.0 255.255.255.255 UH 0 0 0 ppp1 192.168.0.32 0.0.0.0 255.255.255.240 U 0 0 0 eth0 192.168.0.64 0.0.0.0 255.255.255.248 U 0 0 0 eth0 192.168.0.80 0.0.0.0 255.255.255.248 U 0 0 0 eth0 192.168.0.96 0.0.0.0 255.255.255.248 U 0 0 0 eth0 192.168.0.112 0.0.0.0 255.255.255.248 U 0 0 0 eth0 192.168.0.128 0.0.0.0 255.255.255.240 U 0 0 0 eth0 192.168.0.160 0.0.0.0 255.255.255.240 U 0 0 0 eth0 192.168.0.192 0.0.0.0 255.255.255.248 U 0 0 0 eth0 192.168.0.208 0.0.0.0 255.255.255.252 U 0 0 0 eth0 192.168.0.216 0.0.0.0 255.255.255.252 U 0 0 0 eth0 192.168.0.224 0.0.0.0 255.255.255.224 U 0 0 0 eth0

[elve]

OSPF работает на 2-м уровне OSI. Если вы делаете GRE-туннель то вам нужно будет по протоколу BGP делать динамическую маршрутизацию, т.к. вы будете работь на 3-м уровне.

[TonnyBennet]

OSPF работает на 2-м уровне OSI. Если вы делаете GRE-туннель то вам нужно будет по протоколу BGP делать динамическую маршрутизацию, т.к. вы будете работь на 3-м уровне.

К сожалению я не понял к чему данное сообщение.


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

[nerve]

пытке с шлюза 192.168.0.10 пропинговать адрес из сети 192.168.3.0/24, пакет отправляется с интерфейса 192.168.10.1.

то есть отправляется правильно?
но назад не приходит?

Код:

ip route 192.168.0.0/28 dev eth0 scope link realm 6 192.168.0.0/16 dev vpn_net proto kernel scope link src 192.168.10.1 192.168.0.14 dev ppp1 proto kernel scope link src 192.168.2.1

Код:

route -n Таблица маршутизации ядра протокола IP Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0 192.168.0.0 0.0.0.0 255.255.255.240 U 0 0 0 eth0 192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 vpn_net 192.168.0.14 0.0.0.0 255.255.255.255 UH 0 0 0 ppp1 192.168.0.32 0.0.0.0 255.255.255.240 U 0 0 0 eth0 192.168.0.64 0.0.0.0 255.255.255.248 U 0 0 0 eth0

ну и со шлюза в 3.0 сети роуты покажи

[TonnyBennet]

Сейчас скину таблицу, проснифить пакеты и сказать приходит ли пакет с шлюза 0.10 не получится. Чуть позже.

Код:

~$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 <шлюз_провайдера> 0.0.0.0 UG 100 0 0 eth1 95.80.66.76 0.0.0.0 255.255.255.252 U 0 0 0 eth1 192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 vpn_net 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 ~$ ~$ ip route default via 95.80.66.77 dev eth1 metric 100 95.80.66.76/30 dev eth1 proto kernel scope link src <мой_внешний_адрес> 192.168.0.0/16 dev vpn_net proto kernel scope link src 192.168.10.3 192.168.3.0/24 dev eth0 proto kernel scope link src 192.168.3.1

[TonnyBennet]

Итак, запустил на локальном интерфейсе 192.168.3.1 дамп пакетов. Пример работающего обмена данными между сетями.

Код:

~$ sudo tcpdump -vvvvv -i eth0 -n src host 192.168.0.97 and dst host 192.168.3.3 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 14:07:08.440183 IP (tos 0x0, ttl 126, id 23238, offset 0, flags [none], proto ICMP (1), length 6 0) 192.168.0.97 > 192.168.3.3: ICMP echo request, id 1, seq 11782, length 40 14:07:09.448002 IP (tos 0x0, ttl 126, id 23242, offset 0, flags [none], proto ICMP (1), length 6 0) 192.168.0.97 > 192.168.3.3: ICMP echo request, id 1, seq 11784, length 40 14:07:10.479299 IP (tos 0x0, ttl 126, id 23245, offset 0, flags [none], proto ICMP (1), length 6 0) 192.168.0.97 > 192.168.3.3: ICMP echo request, id 1, seq 11786, length 40 14:07:11.435553 IP (tos 0x0, ttl 126, id 23248, offset 0, flags [none], proto ICMP (1), length 6 0) 192.168.0.97 > 192.168.3.3: ICMP echo request, id 1, seq 11788, length 40 ^C 4 packets captured 4 packets received by filter 0 packets dropped by kernel

Как видно отправитель из сети 192.168.0.0/24 принимает пакет и отвечает узел из сети 192.168.3.0/24. Такая же картина на всех интерфейсах на обоих шлюзах.

Теперь со шлюза 192.168.0.10 я пингую тот же хост 192.168.3.3. Снимаю дамп на 192.168.3.1 на локальном интерфейсе.

Код:

tcpdump -vvvvv -i eth0 -n src net 192.168.0.0/16 and dst host 192.168.3.3 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 14:12:48.224699 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.10.1 > 192.168.3.3: ICMP echo request, id 23512, seq 18, length 64 14:12:48.224995 IP (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto ICMP (1), length 112) 192.168.10.1 > 192.168.3.3: ICMP net 192.168.10.1 unreachable - unknown, length 92 IP (tos 0x0, ttl 127, id 11590, offset 0, flags [none], proto ICMP (1), length 84) 192.168.3.3 > 192.168.10.1: ICMP echo reply, id 23512, seq 18, length 64 14:12:49.186958 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.10.1 > 192.168.3.3: ICMP echo request, id 23512, seq 19, length 64 14:12:49.187164 IP (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto ICMP (1), length 112) 192.168.10.1 > 192.168.3.3: ICMP net 192.168.10.1 unreachable - unknown, length 92 IP (tos 0x0, ttl 127, id 11595, offset 0, flags [none], proto ICMP (1), length 84) 192.168.3.3 > 192.168.10.1: ICMP echo reply, id 23512, seq 19, length 64 ^C 4 packets captured 4 packets received by filter 0 packets dropped by kernel

Пакет имеет адрес отправителя не из сети 192.168.0.0/24, а из сети VPN интерфейса 192.168.0.0/16. Ответ направляется на vpn интерфейс.... и не доходит.

VPN-интерфейсы находящиеся в сети 192.168.10.0/24 не видят друг друга (не пингуются). Хотя маршруты в сеть 192.168.0.0/16 есть на всех шлюзах.

У кого какие соображения на эту тему?

[Sleeping Daemon]

Итак, запустил на локальном интерфейсе 192.168.3.1 дамп пакетов. Пример работающего обмена данными между сетями.

Код:

~$ sudo tcpdump -vvvvv -i eth0 -n src host 192.168.0.97 and dst host 192.168.3.3 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 14:07:08.440183 IP (tos 0x0, ttl 126, id 23238, offset 0, flags [none], proto ICMP (1), length 6 0) 192.168.0.97 > 192.168.3.3: ICMP echo request, id 1, seq 11782, length 40 14:07:09.448002 IP (tos 0x0, ttl 126, id 23242, offset 0, flags [none], proto ICMP (1), length 6 0) 192.168.0.97 > 192.168.3.3: ICMP echo request, id 1, seq 11784, length 40 14:07:10.479299 IP (tos 0x0, ttl 126, id 23245, offset 0, flags [none], proto ICMP (1), length 6 0) 192.168.0.97 > 192.168.3.3: ICMP echo request, id 1, seq 11786, length 40 14:07:11.435553 IP (tos 0x0, ttl 126, id 23248, offset 0, flags [none], proto ICMP (1), length 6 0) 192.168.0.97 > 192.168.3.3: ICMP echo request, id 1, seq 11788, length 40 ^C 4 packets captured 4 packets received by filter 0 packets dropped by kernel

Как видно отправитель из сети 192.168.0.0/24 принимает пакет и отвечает узел из сети 192.168.3.0/24. Такая же картина на всех интерфейсах на обоих шлюзах.

Теперь со шлюза 192.168.0.10 я пингую тот же хост 192.168.3.3. Снимаю дамп на 192.168.3.1 на локальном интерфейсе.

Код:

tcpdump -vvvvv -i eth0 -n src net 192.168.0.0/16 and dst host 192.168.3.3 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 14:12:48.224699 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.10.1 > 192.168.3.3: ICMP echo request, id 23512, seq 18, length 64 14:12:48.224995 IP (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto ICMP (1), length 112) 192.168.10.1 > 192.168.3.3: ICMP net 192.168.10.1 unreachable - unknown, length 92 IP (tos 0x0, ttl 127, id 11590, offset 0, flags [none], proto ICMP (1), length 84) 192.168.3.3 > 192.168.10.1: ICMP echo reply, id 23512, seq 18, length 64 14:12:49.186958 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.10.1 > 192.168.3.3: ICMP echo request, id 23512, seq 19, length 64 14:12:49.187164 IP (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto ICMP (1), length 112) 192.168.10.1 > 192.168.3.3: ICMP net 192.168.10.1 unreachable - unknown, length 92 IP (tos 0x0, ttl 127, id 11595, offset 0, flags [none], proto ICMP (1), length 84) 192.168.3.3 > 192.168.10.1: ICMP echo reply, id 23512, seq 19, length 64 ^C 4 packets captured 4 packets received by filter 0 packets dropped by kernel

Пакет имеет адрес отправителя не из сети 192.168.0.0/24, а из сети VPN интерфейса 192.168.0.0/16. Ответ направляется на vpn интерфейс.... и не доходит.

VPN-интерфейсы находящиеся в сети 192.168.10.0/24 не видят друг друга (не пингуются). Хотя маршруты в сеть 192.168.0.0/16 есть на всех шлюзах.

У кого какие соображения на эту тему?

Запись 192.168.0.0/16 dev vpn_net proto kernel scope link src 192.168.10.1
перекрывает все последующие записи, касающиеся подсети 192.168.

[TonnyBennet]

И что это значит?