Subnets.ru

Есть вот такая технология:
http://www.brynosaurus.com/pub/net/p2pnat/
http://en.wikipedia.org/wiki/Hole_punching

Конкретную реализацию для вашего случая сказать не могу, но думаю возможно вам пригодится

Т.е. на время сеанса будет считаться, что вся 10-я сеть находится у пира и своя локалка не работает. Еще один геморрой - маршрутизация у клиента. Дефолт ведь уйдет в тоннель...
Ежели кто сталкивался с такой проблемой - подскажите, есть ли решение попроще...

У меня была аналогична ситуация, после сигментирования сети. Я решил все тем, что создал bat файлы для каждого сигмента и при возникновении вопроса о пребывании в инете и неработающих локальных сервисах - посылал на файлы.

zaikini интересно интересно, почитаем

Андрей писал(а):У меня была аналогична ситуация

да другая у тебя ситуация, абсолютно другая

zaikini писал(а):Есть вот такая технология:
http://www.brynosaurus.com/pub/net/p2pnat/
http://en.wikipedia.org/wiki/Hole_punching

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

Андрей писал(а):У меня была аналогична ситуация, после сигментирования сети.

Тут проблема, которая с сегментированием сети имеет мало общего. Проблема называется "пересечение адресного пространства" - и простым роутингом она не решается. Есть у меня мысль посмотреть в сторону маркирования пакетов на границе сети, но тут нужно думать, как эти маркеры обрабатывать у клиента.

В сети есть dhcp? Если есть, и при это выдается по макам, то можно:
1. сменить на основных узлах (NAS, Биллинг и т.п. параметры под новую сеть, к примеру 192.168.0.0/12)
2. Перебить конфиг dhcp на раздачу ip из вышеуказанной сети.
3. Имеет ли смысл того, чтобы клиенты из той сети видели машины твоих клиентов в твоей сети? Если нет, если нужен только твои сервисы, то поднимай сервера на границе.
Я бы так сделал.

да другая у тебя ситуация, абсолютно другая

Речь шла о том, что все пакеты летят в туннель и о недоступности сервисов в своей сети при поднятом VPN.
Я написал как я вышел из данного положения.
Пиринг от сигментации я отличить могу.

Андрей писал(а):В сети есть dhcp? Если есть, и при это выдается по макам, то можно:
1. сменить на основных узлах (NAS, Биллинг и т.п. параметры под новую сеть, к примеру 192.168.0.0/12)
2. Перебить конфиг dhcp на раздачу ip из вышеуказанной сети.

Надеюсь, вы понимаете, что смена адресного плана на другой на работающей сети - занятие сложное и достаточно трудоемкое? Даже несмотря на наличие DHCP-серверов. Да и зачем? Что ж теперь под каждого пира перестраивать свою транспортную сеть? Нет никакого смысла. Маска, кстати, у вас указана неверная - максимум, что можно использовать - 192.168.0.0/16.

Андрей писал(а):Речь шла о том, что все пакеты летят в туннель и о недоступности сервисов в своей сети при поднятом VPN.
Я написал как я вышел из данного положения.
Пиринг от сигментации я отличить могу.

При наличии DHCP сервера это решается передачей маршрута 10/8 клиенту через опции DHCP. Проблема не в этом.

Андрей писал(а):Речь шла о том, что все пакеты летят в туннель и о недоступности сервисов в своей сети при поднятом VPN.

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

spd2 писал(а):Когда установлено PPTP-соединение, придется выбрать, где находится 10-я сеть - за туннелем, или у нас, локально

spd2 писал(а):это решается передачей маршрута 10/8

spd2 да не надо мутить с маршрутом в сеть 10/8
пусть все остается как есть чичас
я про то, что сделать пиринг на PPTP адресах и все, т.е. оба клиента, из двух сетей, устанавливают соединение до PPTP сервера, который выдает им IP-адреса из сети 172.16.0.0/12, например:
Клиент А: 172.16.1.25
Клиент Б: 172.16.88.36
после создания туннеля и получения адресов клиенты будет прекрасно видеть друг друга, если они на одном PPTP сервере
если на разных серверах, то тут пару строчек роутинга на PPTP серверах до поделенных между провами сети 172.16.0.0/12 на подсети, например:
Сервер А: 192.168.1.1/30 -> route add 172.16.88.0/24 192.168.1.2
Сервер Б: 192.168.1.2/30 -> route add 172.16.1.0/24 192.168.1.1
в таком раскладе клиенты получат пиринг и при этом будут и дальше видеть ресурсы в своих локалках
теперь понятно о чем именно я толкую ?

Да, технически решение неплохое и правильное, спасибо Правда, на практике всё испортят организационные вопросы. Народ-то привык сидеть на своих хабах без всяких ВПН-ов. И тут мы ему говорим - запускай ВПН и коннектись на такой-то сервак. Он коннектится и заходит на чужой хаб, находит чего качнуть - и обламывается... С чужой-то стороны, народ сидит без ВПН-ов, говоря - "а нам сейчас не нужно в другую локалку, мы пока так посидим...". Тут только поможет общий на двух провов хаб, к которому присоединиться можно только через ВПН...

spd2 писал(а):Народ-то привык сидеть на своих хабах без всяких ВПН-ов

ну как бы или так или замена адресов
больше пока ничего в голову так и не пришло

spd2 писал(а):Правда, на практике всё испортят организационные вопросы

смотря как преподнесете юзверям новость, от этого тоже много зависит, т.е. как преподнесете информацию

spd2 писал(а):спасибо

пжалста