Не Идут Пакеты В Туннель

[Алексей_]

Добрый день. Вот такой возник вопрос-проблема: У нас между двумя координаторами поднят туннель. Две подсети общаются между собой через координаторы. Необходимо чтобы в интернет ходили через первую подсеть. Для этого на втором координаторе отсутствуют nat правила и forward. И почему то пакеты для интернет из второй подсети не уходят в туннель. Команда trace из второй подсети до 8.8.8.8 выдает звездочки. В чем может быть проблема?

Этот вопрос был задан в тех. поддержку в итоге:

По телефону думали 10 минут, потом сказали что не знают.

По почте попросили номер договора на тех. поддержку, которого нет.

У меня простой вопрос умеет ли координатор отправлять все пакеты в туннель? Может кто подскажет.

[Stratos]

trace с какими режимами на интерфейсах запускаете?

Навскидку, проблемы в маршрутизации. А ответ на Ваш вопрос - умеет.

[ingenico]

Чтобы пакет ушел в туннель, надо чтобы IP-адрес назначения туннелировался другим Координатором.

У вас какой диапазон туннелируется первым Координатором? Входит ли туда адрес 8.8.8.8?

Что в журнале IP пакетов для такого трафика?

[Алексей_]

Спасибо, понял

[Алексей_]

Чуть подробней о сетях:

Одна в Москве другая в другом регионе России. Необходимо чтобы из другого региона в интернет попадали через московский ЦОД. Для туннелирования в config прописаны две подсети 192.168.10.0 и 192.168.20.0.

В firewall в секции

[nat] пусто

[tunnel] any any

[forward] any drop

Подключены два координатора между собой, на АП VipNet Client не стоит.

В журнале все запросы, кроме локальных сетей идут в drop (Drop forward public... пока нет доступа ко второму координатору)

[demda]

Здравствуйте! Задачка, честно говоря не очень тривиальна. Что бы пакеты уходили в туннель надо что бы Ваш координатор четко знал адреса туннелей на другом координаторе (на другой стороне, так сказать). Вы конечно теоретически можете сделать туннель на другой стороне tunnel = 0.0.0.0 -255.255.255.255 .... и.т.д. и натить. А на координаторе в регионе указать в секции координатора Москвы такой-же туннель. НО если честно как-то хмммм.... Не очень.... Не безопасно это.

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

[Алексей_]

Я думал, что если нет никаких правил, то все будет отправляться в туннель. По логике туннель это обычный "провод" и если не знаешь что делать отправь на шлюз по умолчанию, который находится в 192.168.10.0. а дальше в интернет. И почему не безопасно все в туннель?

[demda]

Я думал, что если нет никаких правил, то все будет отправляться в туннель. По логике туннель это обычный "провод" и если не знаешь что делать отправь на шлюз по умолчанию, который находится в 192.168.10.0. а дальше в интернет. И почему не безопасно все в туннель?

Насчет туннеля и провода не совсем понял.... Туннель это разрешение незащищенным машинам (без клиента ) попадать в защищенную сеть. Отличие: на клиенте шифрование на машине идет при туннеле на координаторе. Ну и соответственно при полном туннеле через координатор трафик летает от одной незащищенной машине к другой. Главное что координатор должен знать какие адреса туннелирует другой координатор. И делает так: запрос на маршрутизацию прилетает на координатор, координатор смотрит что в дестинэйшане, если в дейстинэйшане адресс, который у него в туннелях (у другого координатора) есть, значит шифруем и отправляем другому координатору, если нет, тогда смотрим что там в правилах открытой сети.

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

[demda]

Насчет туннеля и провода не совсем понял.... Туннель это разрешение незащищенным машинам (без клиента ) попадать в защищенную сеть. Отличие: на клиенте шифрование на машине идет при туннеле на координаторе. Ну и соответственно при полном туннеле через координатор трафик летает от одной незащищенной машине к другой. Главное что координатор должен знать какие адреса туннелирует другой координатор. И делает так: запрос на маршрутизацию прилетает на координатор, координатор смотрит что в дестинэйшане, если в дейстинэйшане адресс, который у него в туннелях (у другого координатора) есть, значит шифруем и отправляем другому координатору, если нет, тогда смотрим что там в правилах открытой сети.

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

Алексей, я еще на работе пишите dad@oepak22.ru пообщаемся, проще будет голосом объяснить.

[demda]

Попробую разъяснить

Координатор регион

[iD] -собственная

name - Координатор филиал

...

tunnel =192.168.0.1 - 192.168.0.20 to .....

[iD]- координатора Москвы

name = Координатор Мосвы

.....

tunnel = 0.0.0.0 to 255.255.255.255

Координатор Москва

[iD] -собственная

name - Координатор Москва

...

tunnel =0.0.0.0 - 255.255.255.255 to .....

[iD]- координатора Регион

name = Координатор филиал

....

tunnel = 192.168.0.1-192.168.0.20

На координаторе Москвы НАТ.....

Проще говоря

Что бы обратные пакеты из Инета отправлялись в туннель к координатору региона надо адреса инета в москве в собственной секции ИД прописать. Это предпологает, что любой адрес из инета может в туннель попасть. Да и коллапс будет получиться совпадение адресов с другими туннелями, с адресами клиентов и.т.д. Это не выход. То что я Вам предложил более выгодный вариант.

[demda]

Есть конечно вариант в туннель прописать только некоторые сети глобального интернета.... Исключив серые адреса....Но это не выход.... Мое предложение по туннелю 0.0.0.0 - 255.255.255.255 - не принимайте к действию

[Алексей_]

Спасибо за помощь и разъяснения. В моем случае наверное нужно делать l2overip или действительно пропишу нужные подсети для туннелирования. Просто у меня рядом спец по cisco сидит и говорит что на cisco это одной кнопкой делается.

[Алексей_]

И еще я не спец по координаторам, я так понимаю что поменять config на удаленном координаторе я смогу только через арм администратора, т.к. координатор стоит за nat провайдера и адрес получает по dhcp и физического доступа к координатору у меня нет.

[demda]

И еще я не спец по координаторам, я так понимаю что поменять config на удаленном координаторе я смогу только через арм администратора, т.к. координатор стоит за nat провайдера и адрес получает по dhcp и физического доступа к координатору у меня нет.

Не обязательно через АРМ Можно получить доступ с любой машины в туннелях у другого координатора. Главное что бы они друг доуга видели с машины в туннелях доступ получить можно по адресу acces ip для секции нужного Вам координатора. L2overIP - может быть и выход... НО мне по описанию не понравилась реализация этого механизма.... И представьте ситуацию если у вас на каналном уровне карточку заштормит.... Вам выштормит весь канал випнета... А по ЦИСКЕ... да конечно это не сравнимое оборудование... Но можно можно ЦИСКИ сделать в туннелях випнета.... И поднять между ними уже ЦИСКОВСКИЙ туннель. Упадете по скорости, выиграите по реализации. Я делал так: поднимал на линуксе микротиковский EOIP? , потом бриджевал ТАП интерфейс с физическим ETH и оба таких сервака стояли в туннелях у випнета. Удалось таким образом даже транки протащить... Но скорость...