Jump to content

Recommended Posts

Всех приветствую!

Возник вопрос по маршрутизации трафика в туннелях, т.е имеем такую схему

LAN(192.168.0.0/24)>(eth1)HW1000(eth0)inet-----inet(eth0)HW1000(eth1)<(172.16.50.0/24)

Сети 192 и 172 туннелируются на координаторе

Как работает механизм маршрутизации из одной сети в другую, весь сети даже не connected.

Share this post


Link to post
Share on other sites

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

Все.

Share this post


Link to post
Share on other sites

Я видимо не совсем правильно выразился

берем 2 роутера A B

на роутера A lan сеть 192.168.***.yyy, роутер B lan 172.16.***.yyy

сеть для связи между роутероми A B возьмем 10.10.10.0/30

получаем такую схему

lan 192.168(fa0/1)A(fa0/0)10.10.10.1 <---->10.10.10.2(fa0/0)B(fa0/1)172.16 lan

соответственно на роутера А пишу маршрут что сеть 172,16 искать за 10.10.10.2

на роутере Б сеть 192,168 искать за 10.10.10.1

тут же ситуация другая

Координатор 1

netstat -rn

Kernel IP routing table

Destination Gateway Genmask Flags MSS Window irtt Iface

***.***.***.xx 0.0.0.0 255.255.255.248 U 0 0 0 eth1

192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

0.0.0.0 ***.***.***.xx 0.0.0.0 UG 0 0 0 eth1

Координатор 2

netstat -rn

Kernel IP routing table

Destination Gateway Genmask Flags MSS Window irtt Iface

***.***.***.xx 0.0.0.0 255.255.255.248 U 0 0 0 eth1

172.16.50.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

0.0.0.0 ***.***.***.xx 0.0.0.0 UG 0 0 0 eth1

обе локальной сети туннелируються, сети не connected

без прописывания маршрутов, без использования механизмов NAT локалки видят друг друга, вот этот момент я не совсем понимаю

Share this post


Link to post
Share on other sites

С хоста 192.168.0.x сети (допустим .10 ) идет пакет в 172.16.0.x (допустим .20).

Хост просматривает: мой броудкаст? - нет. Маршрут есть? - да/нет. Значит отправляю либо по конкретному маршруту, либо на шлюз.

Шлюз - координатор (может и другое устройство, но главное, чтобы электроны долетели до координатора).

Пакет приходит на координатор.

Пакет попадает в драйвер IpLir.

В драйвере загружено правило: я туннелирую 192.168.x.10 , другой координатор - 172.x.x..20 Шифруем? - да. (про firewall опустил).

Пакет шифруется на ключе координатора, который туннелирует 172.16.х.20, инкапсулируется в udp:55777 и отсылается на адрес доступа координатора

Адреса пакета меняется полностью: src своего интерфейса, dst - адрес доступа к другому координатору.

(Замечу, что изначальны пакет src - 192.168.х.10, dst -172.16.х.20 остается неизменным и находится в зашифрованном виде).

Зашифрованный пакет прилетел на другой координатор.

Координатор расшифровывает пакет и получает исходный: src - 192.168.х.10, dst -172.16.х.20 (часть идентификации опускаю).

Смотрит dst - 172.16.x.20. Мой броудкаст? - да. Беру mac и отправляю напрямую (или на следующих hop по маршрутизации).

Надеюсь понятно описал.

В принципе, это и есть принцип работы vpn технологии. VPN - ВИРТУАЛЬНАЯ частная сеть. Это не реальная сеть, где на коммутаторах и маршрутизаторах присутствует понятие как connected (грубо упростим - link).

Share this post


Link to post
Share on other sites

Возникла следующая ситуация:

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

2. Документация пишет, что максимальное количество туннелей для координатора надо заводить в ЦУС, иначе туннели работать на координаторе не будут.

3. Имеем два координатора: один виндовый, второй 1000.

4. При просмотре в ЦУС сведений о лицензии в строке "туннели" стоит 0/0.

5. В окне настройки координаторов софтовая кнопка "Туннели" отсутствует.

6. На виндовом координаторе туннели не поднимаются (на HW пока не нужны).

Хотелось бы понять, как такое вообще получилось и как исправлять.

Заранее благодарен за помощь.

Share this post


Link to post
Share on other sites

Что касается HW1000, то никакие туннели в ЦУСе активировать не нужно (я про ограничения сейчас говорю). Просто прописываем адреса - и всё работает. Что касается координатора под windows - с каждым координатором (софтовым) даётся 5 туннелируемых лицензий. Но они должны отображаться в сведениях о лицензии. Советую Вам обратиться с этим вопросом в техническую поддержку или к менеджеру. Необходимо узнать почему лицензии не были добавлены. Возможно, у них опять какие-то изменения в лицензионной политике.

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

Так, а на самом деле, поменялось ли что-то в плане количества туннелей по умолчанию?

Share this post


Link to post
Share on other sites

Насколько я знаю не поменялось.

Share this post


Link to post
Share on other sites

Возникла следующая непонятка:

1. Имеются два координатора HW1000 (А) и (В), смотрящие в интернет, которые (кроме координации защищенных клиентов)туннелируют по одному адресу А.А.А.А и В.В.В.В соответствено.

2. Координаторы являются для туннелируемых ими аресов шлюзами по умолчанию.

3. На обоих координаторах в соответствующих секциях [id] информация о туннелях прописана.

4. Защищенным клиентам обоих координаторов оба туннелируемых адреса доступны.

5. С координатора (А) пингуется компьютер В.В.В.В, с координатора (В) пингуется компьютер А.А.А.А

6. С компьютера A.A.A.A пингуются оба интерфейса координатора (В), с компьютера В.В.В.В пингуются оба интерфейса координатора (А).

7. Тем не меннее, машины А.А.А.А и В.В.В.В друг друга не видят.

Чего я еще не сделал?

Заранее благодарен за советы.

Share this post


Link to post
Share on other sites

Рассмотрим такой вариант:

координатор А eth0 - inet, eth1 - 192.168.0.0/24

координатор Б eth0 - inet, eth1 - 192.168.1.0/24

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

в iplir.conf

для вашего координатора должен быть указан туннель

tunnel= 192.168.0.2-192.168.0.254 to 192.168.0.2-192.168.0.254

для координатора Б на координаторе а должен быть туннель

tunnel= 192.168.1.2-192.168.1.254 to 192.168.1.2-192.168.1.254

соответственно на координаторе Б обратная схема

На всех компьютерах что находятся в туннеле default route должен быть координатор.

Так же посмотрите в каком режиме находятся интерфейсы, если во 2 то нужно настраивать firewall

Share this post


Link to post
Share on other sites

Спасибо, но:

В iplir.conf все именно так и сделано (см.мой п.3). Координаторы являются шлюзами по умолчанию (см.мой п.2) Интерфейсы в 4-м режиме. В firewall так же разрешено все и всем.

Edited by scroller

Share this post


Link to post
Share on other sites

Пишется в журнал на координаторе (А) при пинге с компьютера А.А.А.А компьютера В.В.В.В вот что:

пинг с одного туннелируемого адреса на другой ложится в туннель (событие 63-IP packet is allowed by tunnel filter) но остается без ответа.

Share this post


Link to post
Share on other sites

Судя по событию, пакеты не блокируются, по всей видимости что то на клиентских машинах.

Странный вариант: вы проверяете связь с сети А в сеть Б, а что если наоборот проверить?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Когда работал в поддержке, то поначалу верил людям))

Потом перестал. Пока глазами сам не увидишь, не разберешься.

Share this post


Link to post
Share on other sites

На компьютере за Координатором А добавляйте статический маршрут в сеть за Координатором Б через Координатор Б.

Share this post


Link to post
Share on other sites

ну если в Windows то примерно так:

route ADD "IP компьютера/сети за Координатором Б" MASK "маска компьютера/сети за Координатором Б" "IP Координатора А"

в Linux аналогично, синтаксис похож.

Главное отправить пакет, предназначенный сети "за Координатором Б" на интерфейс "Координатора А".

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.