[exo]

дайте, пожалуйста, настройки ВПН соеденений и НАТа.

а не с адресом граничного VPN-маршрутизатора »

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

[wertyg]

нет НАТ не нужен вообще, если дело только в связи по ВПН. да он и работать не станет. т.к. маршрутизатор видит что пакетик в сеть наход. на той стороне ВПН тунеля (это настраеваеться при создании ВПН соединения) и пихает его в ВПН тунель обходя НАТ.

пиши реализацию. на чём и как построена ВПН.

я так понял ВПН поднимаеться между маршрутизаторами сети А и Б, так?
если реализовано на винде то там наблюдаеться один интересный глюк. на маршрутизаторе к которому подключаеться конец ВПН тунеля не регестрируется обратный маршрут. как следствие пакеты входят в сеть но не выходят. т.к. маршрутизатор к которому произошло подключение не знает куда пихать пакеты с адресом удалённой сети(на первом то мы ручками в настройке ВПН прописали). можеш это увидить сам в таблице маршрутизации после того как подключение ВПН установиться(увидеть там надо отсутствие маршрута.) ). это исправляеться только с помощью командной строки.) :
на маршрутизаторе к которому подключаешся выполни следующие действия в командной строке.

netsh routing ip add interface internal - добавиться новый интерфейс "внутренний"
netsh routing ip add persistentroute <net> <mask> internal <gateway> - добавиться постоянный маршрут.
netsh routing ip show persistentroute - просмотр только что добавленного маршрута.

<net> - обратная сеть. из которой устанавлевалось соединение.
<mask> - маска обратной сети.
<gatewey> - шлюз в обратной сети(ВПН присвой статические адреса а не раздавай их по ДХЦП иначе не укажеш этот параметр). ИП интерфейса ВПН установившего связь.

в оснастке RRAS всё это появиться но с некорректными данными - необращай внимания.)

з.ы. я это делал давно, возможно что то напутал, хотя врядли. удачи.)

[Kirill_80]

exo, я, наверное, слишком путано объяснил. Для ВПН используется Вынь-платформа (пожелание заказчика). В методике внедрения ВПН-решений от Микрософт рекомендуется в сетях с ненадёжным соединением использовать так называемые Интерфейсы по требования с фильтрами интересующего трафика. Т.е. в случае разрыва соединения с удалённой подсетью, если на маршрутизатор поступает трафик в эту удалённую подсеть, RRAS автоматически поднимает соединение (для начала с ISP, а потом и с удалённым маршрутизатором). Но на практике почему-то происходит следующее. RRAS самостоятельно поднимает соединение если только трафик исходит из самого компьютера-маршрутизатора, на котором установлен RRAS. Для 2000-ого Выня рекомедовалось использовать NAT для решения данной проблемы. Но с 2003-тьим такая схема не прокатывает.

wertyg, спасибо за твою версию (она, кстати, неверная, это так, замечание для тех, кто будет читать впоследствии), но Микрософт издаёт довольно подробную и доходчивую методологию внедрения VPN на их решениях, которая успешно работает, так что выдумывать велосипед смысла нет (читайте о внедрении межсайтовых VPN-соединений). Просто некоторые сложные моменты они обходят. Видимо по маркетинговым соображениям.