LINUX.ORG.RU
решено ФорумAdmin

не строится тунель в облако

 ,


1

2

Строю тут IPSec Site-to-site VPN-тунель в облако одного небезизвестного провайдра. Прочитал интсрукцию как это все правильно делается, поставил в облаке убунточку, накатил туда OpenSwan и настроил все как в инструкции. Со стороны нашего офиса стоит такой же Linux, только StrongSwan.
Казалось бы, ничего особенного. Но тунель упорно не строится. Убунточка за НАТом. Конечно, я учел это в конфигурациях обоих роутеров и поставил параметр

nat_traversal=yes


вот конфиг офисного StrongSwan


conn mycon
left=<mypublicip>
leftsubnet=172.16.0.0/24
right=<mycloudip>
rightsubnet=10.240.82.0/24
ike=3des-md5-modp1024
esp=aes128-md5
type=tunnel
authby=secret
auto=start
pfs=no


вот конфиг облачного OpenSwan


conn mycon
right=<mypublicip>
rightsubnet=172.16.0.0/24
rightnexthop=%defaultroute
left=10.240.82.13
leftsubnet=10.240.82.0/24
leftnexthop=%defaultroute
type=tunnel
authby=secret
auto=start
pfs=no


В настройках NAT и списков доступа в конфигурялке провайдера облака разрешил весь трафик с офисного адреса на публичный адрес облачного сервера.
В логах офисного сервера только


Nov 14 17:47:24 debian charon: 10[IKE] initiating IKE_SA mycon[2] to <myIP>


вывод ipsec auto status на облачном сервере пишет


000 «mycon»: myip=unset; hisip=unset;
000 «mycon»: ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
000 «mycon»: policy: PSK+ENCRYPT+TUNNEL+UP+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD; prio: 24,24; interface: eth0;
000 «mycon»: newest ISAKMP SA: #0; newest IPsec SA: #0;
000
000 #1: «mycon»:500 STATE_MAIN_I1 (sent MI1, expecting MR1); EVENT_RETRANSMIT in 3s; nodpd; idle; import:admin initiate
000 #1: pending Phase 2 for «mycon» replacing #0



Похоже, что пакеты отправляются, но ответы не приходят.
Грешу на то, что список доступа не пускает. И вообще, эта схема с НАТом какая-то неправильная. Но пинги бегают, вроде все рабоает. Или есть какие-то нюансы в настройке между StrongSwan и OpenSwan? А может это руки у меня кривые? Кто-то настраивал подобную схему?
Any ideas?


стоит такой же Linux, только StrongSwan.

С какой целью в одинаковых дистрибутивах использовать разные ipsec?

Если StrongSwan должен только принимать соединение, а инициатором выступать всегда сторона с OpenSwan, то ″auto = add″.

Смотрите, что ходит на уровне пакетов, ЕМНИП, udp порт 500, на стороне вашего офисного сервера, приходят ли туда пакеты от облака, уходят ли ответные пакеты.

Или есть какие-то нюансы в настройке между StrongSwan и OpenSwan? А может это руки у меня кривые?

Соберите тестовую схему без облака и NAT и узнаете :-) Пока вобще не понятно, поднимали ли вы когда-либо ipsec между двумя linux-серверами.

mky ★★★★★ ()
Ответ на: комментарий от mky

С какой целью в одинаковых дистрибутивах использовать разные ipsec?

Нет, дистрибутивы разные. Я имел ввиду, что тоже линукс, а не циска какая-то.

Если StrongSwan должен только принимать соединение, а инициатором выступать всегда сторона с OpenSwan, то ″auto = add″.

Та не важно, кто будет инициатором. Лишь бы работало.

Смотрите, что ходит на уровне пакетов, ЕМНИП, udp порт 500, на стороне вашего офисного сервера, приходят ли туда пакеты от облака, уходят ли ответные пакеты.

Спасибо за подсказку, надо было первым делом это сделать.

Соберите тестовую схему без облака и NAT и узнаете :-) Пока вобще не понятно, поднимали ли вы когда-либо ipsec между двумя linux-серверами.

Я бы не против. Но руководству всегда надо на вчера и никто тебе не выделит времени на какое-то там тестирование. ipsec поднимали, но все было гораздо проще: на обоих концах strongswan и никакого НАТа.

Gu4 ()
Ответ на: комментарий от mky

Вобщем, рассказываю, может кому будет полезен мой опыт.
Во-первых, я использовал аутентификацию PSK, а не по сертификату. По-умолчанию сервера использовали ID, которое равно IP-адресу. И у меня ID сервера в облаке не совпадало с ID, которое ждал сервер в офисе, так как север в облаке был за NAT-ом и IP-адреса отличались. Strongswan в офисе этого не понимал.
В связи с этим был выставлен параметр rightid в файле ipsec.conf.
Следующий нюанс, это то что из-за разных ID пришлось слегка изменить ipsec.secrets. Я прописал на офисном роутере пароль для обоих облачных адресов, и глобального и локального. Подозреваю, что достаточно локального.
Словом, вот куски конфигов на сервере в офисе для наглядности.
ipsec.conf


conn myconn
left=<mypublicip>
leftsubnet=172.16.0.0/24
right=<mycloudip>
rightid=10.240.82.13
rightsubnet=10.240.82.0/24
authby=secret
auto=start
pfs=no


ipsec.secrets


<mypublicip> <mycloudip> : PSK «supersecretketkey»
<mypublicip> 10.240.82.13 : PSK «supersecretketkey»


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

P.S. И обратите внимание на тот NAT-файрвол, который у вас в облаке выпускает сервера в сеть. Не забудьте его соответственным образом настроить.

Gu4 ()
Ответ на: комментарий от Gu4

На опеннете или ещё каком-то ресурсе со светленькой темой был материалец пару лет назад, о том что PSK и айпишники в ipsec — уязвимое в перехвату говно. Поздравляю с успешным применением своих знаний ipsec.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.