Jump to content
nixtrian

Пробросить Тунеллируемый Ресурс В Реальную Подсеть

Recommended Posts

Добрый день!

Пытаюсь настроить проброс айпи-адреса как показано на картинке:

3527966dc1ff.jpg

Координатор А тунеллирует ресурс 10.Х.Х.А, координатор Б смотрит в сеть 10.Y.Y.0/24 интерфейсом eth1 с адресом 10.Y.Y.A. Конечная цель: любой ip-пакет, отправленный на 10.Y.Y.B долетает до 10.X.X.A.

В ходе долгих экспериментов с тунеллированием выяснил:

если

1) прописать в iplir config

на Координаторе А:

в собственной секции id:

tunnel= 10.X.X.A-10.X.X.A to 10.X.X.A-10.X.X.A

в секции id Координатора Б:

tunnel= 10.Y.Y.B-10.Y.Y.B to 10.X.X.A-10.X.X.A

на Координаторе Б:

в собственной секции id:

tunnel= 10.Y.Y.B-10.Y.Y.B to 10.Y.Y.B-10.Y.Y.B

к секции id координатора А:

tunnel= 10.X.X.A-10.X.X.A to 10.Y.Y.B-10.Y.Y.B

2) прописать айпи 10.Y.Y.B в качестве дополнительного на интерфейс eth1 координатора Б

3) пустить пинги на 10.Y.Y.B с хоста 10.Y.Y.C (пинг будет успешен)

4) удалить дополнительный айпи адрес 10.Y.Y.B с интерфейса eth1 Координатора Б

5) быстро запустить iplir

Проброс работает какое-то время, то есть icmp-пакеты, отправленные хостом 10.Y.Y.C на 10.Y.Y.B, в tcpdump хоста 10.X.X.A можно наблюдать:


18:48:40.169349 IP 10.Y.Y.C > 10.X.X.A: ICMP echo request, id 1, seq 4008, length 40
18:48:40.169658 IP 10.X.X.A > 10.Y.Y.C: ICMP echo reply, id 1, seq 4008, length 40
18:48:41.185221 IP 10.Y.Y.C > 10.X.X.A: ICMP echo request, id 1, seq 4009, length 40
18:48:41.185475 IP 10.X.X.A > 10.Y.Y.C: ICMP echo reply, id 1, seq 4009, length 40

Но не проходит и минуты, как сетевая связанность разрушается.

Дело в ARP, если я просто прописываю туннель, то координатор Б не отвечает на ARP-запросы хоста 10.Y.Y.С касательно хоста 10.Y.Y.B.

Но в то же время при прописанном дополнительном айпи-адресе 10.Y.Y.B на "Координаторе Б", туннель не подымается, при iplir start ругается на конфликт.

Добавлю также, что пытался решить эту задачу при помощи dst-nat. Но, как написано в руководстве, dst-nat должен использоваться для проброса отдельных портов, а не IP-адресов целиком. И по факту ничего не работает даже tcpdump на "Координаторе Б" не видит icmp-пакетов или arp-запросов от 10.Y.Y.C на 10.Y.Y.B при прописанном дополнительном ip-адресе и включенном правиле nat

num 50 proto any from anyip to 10.Y.Y.B change dst=10.X.X.A

Share this post


Link to post
Share on other sites

У Вас пропадает связь, когда координаторы между собой синхронизируются. Те настройки, которые Вы задаёте на двух разных координаторах, различаются и эти различия ликвидируются автоматически. Почему бы просто не прописать через ЦУС туннели для двух подсетей?!

Share this post


Link to post
Share on other sites

У Вас пропадает связь, когда координаторы между собой синхронизируются. Те настройки, которые Вы задаёте на двух разных координаторах, различаются и эти различия ликвидируются автоматически. Почему бы просто не прописать через ЦУС туннели для двух подсетей?!

Связь пропадает не когда координаторы синхронизируются, а когда в ARP-таблице пропадает запись, а на новые ARP-запросы координатор Б уже не отвечает, а появляется она когда координаторы синхронизировались, но ARP-таблица еще не обновилась.

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

Мне необходим туннель именно с трансляцией (то есть необходимо выставить хост именно под адресом 10.Y.Y.B, так как про адреса 10.X.X.X хосты, которым необходима связь, не знают - у них нет маршрутов/туннелей и прописать на них эти маршруты/туннели - трудновыполнимая с административной точки зрения задача.

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

К слову, на циске (если бы она стояла на месте координатора Б) это решалось бы строчкой конфига

ip nat inside source static 10.X.X.A 10.Y.Y.B

Share this post


Link to post
Share on other sites

Извиняюсь за ошибку - уточнил в документации. Параметры tunnel автоматически не синхронизируются - задаются исключительно в ручном режиме или через ЦУС. Возможно, я не до конца понимаю смысл задачи, но возникает простой вопрос: зачем нужна трансляция? Если у Вас координатор является шлюзом по умолчанию, то никакие маршруты прописывать не нужно - пакеты и так замечательно пройдут через координаторы. А если Вы решили использовать трансляцию (причём через функцию отображения в туннелях), то тут всё забавнее - как раз и вылезает проблема, что это не очень-то и трансляция в прямом смысле. Компьютеры за одним координатором думают, что данный узел находится в этой подсети и пакеты не попадают сразу на координатор. Тут, действительно, координатор должен ответить на ARP запрос, чтобы сказать, что он и есть тот узел. А поддерживает ли это координатор?! Думаю, что нет. Если после прихода первого пакета в кэше ещё остаётся информация о том, что пакет приходил с определённого MAC-адреса, то потом ему такую информацию брать просто негде. Вот у Вас связь и пропадает. Даже не знаю что Вам будет проще - добавлять статические записи в ARP-таблицу или прописывать маршруты. Если координатор - шлюз, то никакая трансляция Вам не нужна.

Share this post


Link to post
Share on other sites

Извиняюсь за ошибку - уточнил в документации. Параметры tunnel автоматически не синхронизируются - задаются исключительно в ручном режиме или через ЦУС. Возможно, я не до конца понимаю смысл задачи, но возникает простой вопрос: зачем нужна трансляция? Если у Вас координатор является шлюзом по умолчанию, то никакие маршруты прописывать не нужно - пакеты и так замечательно пройдут через координаторы. А если Вы решили использовать трансляцию (причём через функцию отображения в туннелях), то тут всё забавнее - как раз и вылезает проблема, что это не очень-то и трансляция в прямом смысле. Компьютеры за одним координатором думают, что данный узел находится в этой подсети и пакеты не попадают сразу на координатор. Тут, действительно, координатор должен ответить на ARP запрос, чтобы сказать, что он и есть тот узел. А поддерживает ли это координатор?! Думаю, что нет. Если после прихода первого пакета в кэше ещё остаётся информация о том, что пакет приходил с определённого MAC-адреса, то потом ему такую информацию брать просто негде. Вот у Вас связь и пропадает. Даже не знаю что Вам будет проще - добавлять статические записи в ARP-таблицу или прописывать маршруты. Если координатор - шлюз, то никакая трансляция Вам не нужна.

Для некоторых хостов сети 10.Y.Y.0 он не является шлюзом по умолчанию. Трансляция нужна именно потому, что координатор не шлюз. Сеть 10.Y.Y.0 служит для организации связи нашей и других маршрутизируемых сетей, она является согласованной всеми сторонами (в т.ч. нами) подсетью.

Share this post


Link to post
Share on other sites

Для некоторых хостов сети 10.Y.Y.0 он не является шлюзом по умолчанию. Трансляция нужна именно потому, что координатор не шлюз. Сеть 10.Y.Y.0 служит для организации связи нашей и других маршрутизируемых сетей, она является согласованной всеми сторонами (в т.ч. нами) подсетью.

Тогда просто на шлюзе (маршрутизаторе) пропишите маршрут на координатор для данной удалённой подсети. Мы именно так в своей организации поступаем. У нас ни один координатор не является шлюзовым. Маршруты все на цисках прописаны.

Share this post


Link to post
Share on other sites

Тогда просто на шлюзе (маршрутизаторе) пропишите маршрут на координатор для данной удалённой подсети. Мы именно так в своей организации поступаем. У нас ни один координатор не является шлюзовым. Маршруты все на цисках прописаны.

Под удаленной подсетью понимается 10.X.X.0?

Маршрут не мне прописывать придется, и маршрут уже прописан 10.Y.Y.0 желательно использовать его, это упростит мне жизнь в будущем (при необходимости я буду высовывать какие надо хосты в эту подсеть, а другая сторона уже будет иметь маршруты на неё)

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

Share this post


Link to post
Share on other sites

Опять же, не знаю что из описанной выше схемы к какой организации относится. В случае, если речь идёт о ПЭВМ из сети 10.X.X.0, то маршрут должен быть на основном шлюзе данной подсети. Маршут - всё, что 10.Y.Y.0 - направляем на координатор A. С другой стороны соответственно должно быть (если, опять же, там тоже координатор не шлюз) - всё, что из 10.X.X.0 - направляем на координатор Б. В ЦУСе (или на HW1000) прописываем туннели без всяких хитроумных трансляций - и туннелирование работает. Если не хотите трогать маршрутизаторы, то прописывайте маршруты на сетевых узлах. Ну, а если Вы хотите оставить Вашу схему, то прописывайте статические записи в ARP-таблицах на сетевых узлах. Правда, не знаю насчёт того, как несколько адресов в одной таблице будет с одним MACом. Может и заработает - не встречался с такой задачей. А смысл делать VLAN для взаимодействия?

Share this post


Link to post
Share on other sites

Опять же, не знаю что из описанной выше схемы к какой организации относится. В случае, если речь идёт о ПЭВМ из сети 10.X.X.0, то маршрут должен быть на основном шлюзе данной подсети. Маршут - всё, что 10.Y.Y.0 - направляем на координатор A. С другой стороны соответственно должно быть (если, опять же, там тоже координатор не шлюз) - всё, что из 10.X.X.0 - направляем на координатор Б. В ЦУСе (или на HW1000) прописываем туннели без всяких хитроумных трансляций - и туннелирование работает. Если не хотите трогать маршрутизаторы, то прописывайте маршруты на сетевых узлах. Ну, а если Вы хотите оставить Вашу схему, то прописывайте статические записи в ARP-таблицах на сетевых узлах. Правда, не знаю насчёт того, как несколько адресов в одной таблице будет с одним MACом. Может и заработает - не встречался с такой задачей. А смысл делать VLAN для взаимодействия?

Из описанной схемы все относится к моей организации, но сеть 10.Y.Y.0 относится также и к другим.

2 арпа с 1 маком работают прекрасно. только прописать статический арп не получится на випнетах (чужих) которые в подсеть 10.Y.Y.0 смотрят. И VLANа тут нет никакого (dot1q во всяком случае).

Схему я хочу именно такую как описал в топике.

Вопрос только в том, возможно ли сделать это средствами ViPNet (tunnel, dst nat, etc).

Share this post


Link to post
Share on other sites

Из описанной схемы все относится к моей организации, но сеть 10.Y.Y.0 относится также и к другим.

2 арпа с 1 маком работают прекрасно. только прописать статический арп не получится на випнетах (чужих) которые в подсеть 10.Y.Y.0 смотрят. И VLANа тут нет никакого (dot1q во всяком случае).

Схему я хочу именно такую как описал в топике.

Вопрос только в том, возможно ли сделать это средствами ViPNet (tunnel, dst nat, etc).

Вы сказали про виртуальную подсеть - я сразу и подумал про VLAN. Если Вы обратите внимание на документацию, то там чётко сказано - функции трансляции применяются только для открытого трафика. Эти функции были добавлены в VipNet, чтобы была возможность на нём поднять полноценный сетевой экран и использовать его в качестве шлюза. Что касается защищённой сети (именно VPN), то там как таковая трансляция не предусмотрена. Тут мы просто создаём виртуальную сеть. Главная задача отражения туннелируемых адресов - во избежания конфликтов поставить в соответствие им виртуальные адреса (а никак не для NAT). Я, конечно, не так хорошо знаю технологию VipNet, как хотелось бы, но,основываясь на моём опыте, могу сказать, что VipNet вряд ли может подобное сотворить. Конечно, лучше услышать комментарии специалистов из Инфотекс. На форуме есть хороший специалист Инфотекс - Anton©. Может, он что-нибудь посоветует.

Share this post


Link to post
Share on other sites

Вы сказали про виртуальную подсеть - я сразу и подумал про VLAN. Если Вы обратите внимание на документацию, то там чётко сказано - функции трансляции применяются только для открытого трафика. Эти функции были добавлены в VipNet, чтобы была возможность на нём поднять полноценный сетевой экран и использовать его в качестве шлюза. Что касается защищённой сети (именно VPN), то там как таковая трансляция не предусмотрена. Тут мы просто создаём виртуальную сеть. Главная задача отражения туннелируемых адресов - во избежания конфликтов поставить в соответствие им виртуальные адреса (а никак не для NAT). Я, конечно, не так хорошо знаю технологию VipNet, как хотелось бы, но,основываясь на моём опыте, могу сказать, что VipNet вряд ли может подобное сотворить. Конечно, лучше услышать комментарии специалистов из Инфотекс. На форуме есть хороший специалист Инфотекс - Anton©. Может, он что-нибудь посоветует.

под "виртуальной" сетью я подразумевал - что она не будет ни к какой железке direct connected, а будет спрятана за моим "випнетом Б". И такая схема действительно работает (достаточно прописать туннели используя трансляцию в сеть 10.Z.Z.0 то есть

на координаторе А:

в собственной секции:

tunnel= 10.X.X.A-10.X.X.A to 10.X.X.A-10.X.X.A

в секции координатора Б

tunnel= 10.X.X.A-10.X.X.A to 10.Z.Z.B-10.Z.Z.B

на координаторе Б только в секции координатора A:

tunnel= 10.Z.Z.B-10.Z.Z.B to 10.X.X.A-10.X.X.A

и тунеллирование работает.

возможно, действительно придется согласовать с Москвой еще одну подсеть (виртуализованную), чтобы тунеллировать в нее ресурсы из моих сетей.

В общем, ждем комментариев от представителей инфотекс.

Share this post


Link to post
Share on other sites

под "виртуальной" сетью я подразумевал - что она не будет ни к какой железке direct connected, а будет спрятана за моим "випнетом Б". И такая схема действительно работает (достаточно прописать туннели используя трансляцию в сеть 10.Z.Z.0 то есть

на координаторе А:

в собственной секции:

tunnel= 10.X.X.A-10.X.X.A to 10.X.X.A-10.X.X.A

в секции координатора Б

tunnel= 10.X.X.A-10.X.X.A to 10.Z.Z.B-10.Z.Z.B

на координаторе Б только в секции координатора A:

tunnel= 10.Z.Z.B-10.Z.Z.B to 10.X.X.A-10.X.X.A

и тунеллирование работает.

возможно, действительно придется согласовать с Москвой еще одну подсеть (виртуализованную), чтобы тунеллировать в нее ресурсы из моих сетей.

В общем, ждем комментариев от представителей инфотекс.

Пытался осились Вашу схему с виртуальной подсетью Z - не понял. Какая-то непонятная петля получается. Если Вам не сложно, то не могли бы прокомментировать смысл и механизм работы?

Share this post


Link to post
Share on other sites

Пытался осились Вашу схему с виртуальной подсетью Z - не понял. Какая-то непонятная петля получается. Если Вам не сложно, то не могли бы прокомментировать смысл и механизм работы?

никакой петли, просто траффик, адресованный на 10.Z.Z.B в итоге попадает на 10.X.X.A (происходит подмена адреса получателя).

аналогично трафик от 10.X.X.A приходит на определенные хосты (например на тот же 10.Y.Y.B) как трафик с 10.Z.Z.B (подмена адреса отправителя)

Share this post


Link to post
Share on other sites

никакой петли, просто траффик, адресованный на 10.Z.Z.B в итоге попадает на 10.X.X.A (происходит подмена адреса получателя).

аналогично трафик от 10.X.X.A приходит на определенные хосты (например на тот же 10.Y.Y. B) как трафик с 10.Z.Z.B (подмена адреса отправителя)

Забавная схемка. Общий принцип понял. Только непонятно как это решит Вашу проблему. Ваша задача - пробросить туннель, чтобы всё работало без всяких дополнительных маршрутов. Если в сеть Y придёт пакет, то какая разница из подсети A или подсети Z?! Вам, конечно, виднее.

Share this post


Link to post
Share on other sites

решено при помощи


[nat]
rule= num 53 proto any from anyip to 10.Y.Y.B change dst=10.X.X.A
rule= num 60 proto any from 10.X.X.A to anyip change src=10.Y.Y.B

[forward]
rule= num 1 proto any from 10.Y.Y.0/24 to 10.X.X.A pass

и

tunnel= 10.X.X.A-10.X.X.A to 10.X.X.A-10.X.X.A

в секциях координатора А на обоих координаторах

до этого, видимо, я забывал разрешающее правило в секции forward в конфигурации файрволла координатора Б

Share this post


Link to post
Share on other sites

А трафик при этом идёт открытый или зашифрованный?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

By using this site, you agree to our Terms of Use.