NAT и интерфейс по требованию для VPN-соединения
 

Ситуация следующая. Есть две разделённые территориально ИП-сети. Они соединяются через VPN-соединение. Изначально, по ТЗ, VPN-соединение должно было подниматься автоматически при поступлении из локальной сети (А) в другую локальную сеть (Б) заданного трафика (определяется по соответствию фильтра протоколов). Но при реализации возникла следующая проблема. Если трафик генерируется непосредственно самим граничным VPN-сервером, то соединение поднимается без проблем. Но если трафик генерируется в подсети и затем поступает на граничный VPN-сервер, то соединение не поднимается, что странно. Возникло предположение, что эту проблему можно преодолеть, если загнать VPN-интерфейс за NAT. Но на практике пока реализовать не удалось. К тому же, несмотря на развёрнутый NAT и включение его на VPN-интерфейсе (интерфейс по требованию), пакеты приходят в целевую сеть всё равно с родными адресами посылающих хостов, а не с адресом граничного VPN-маршрутизатора. Может кто наведёт на мысль в чём может быть дело?

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

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

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

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

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

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

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

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

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

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