Дано:

Рутер A: DI-824VUP+, выходит в Инет через одного провайдера (PPPoE), имеет реальный внешний IP. Локальная сеть 172.16.0.0/24.

Рутер B: DI-824VUP+, выходит в Инет через другого провайдера (PPTP), сидит за провайдерским NAT (т.е. без внешнего IP). Локальная сеть 172.16.2.0/24.


Есть желание иметь доступ из сети 172.16.0.0 в 172.16.2.0 и наоборот.

В силу доступности "из вне" только рутера A, на нем настроен Dynamic VPN. На рутере B настроен соответствующий VPN туннель на внешний IP-адрес рутера A. Туннель поднимается, ошибок нет. В статусе VPN рутера A вижу следующее:

Remote network: 172.16.2.0/255.255.255.0/195.135.239.4
Local network: 172.16.0.0/255.255.255.0
Type: ESP tunnel
State: IKE established

Для рутера B аналогичная картина, только соответственно с "перевернутыми" Remote и Local Network.

При этом ssh-сессия от компьютера в сети 172.16.2.0 на компьютер в сети 172.16.0.0 открывается и работает нормально. А вот наоборот (из сети 172.16.0.0 на 172.16.2.0) - никак. Ping'и также заканчиваются на 172.16.0.1.

Такое ощущение, что затык происходит по причине недоступности рутера B "из вне", т.е. несмотря на поднятый VPN-туннель, запрос приходит на NAT'овый адрес провайдера и, естественно, до рутера B не доходит.

Можно ли это как-то обойти? Что я делаю не так???

Заранее спасибо!

Какие прошивки на устройствах

Прошивки 1.06b09, но пробовал и 1.06b14.

Пробовал также соединить WAN-интерфейсы обоих рутеров "напрямую", без всяких провайдеров (и без доступа в Инет), настроив на обоих подключение по WAN как Fixed IP. В этом случае VPN поднимается, пакеты ходят из одной сети в другую и наоборот, все без проблем. Но и рутеры, соответственно, в этом эксперименте доступны друг для друга - никто из них за NAT'ом не прячется.

Удалите статический туннель на Роутере А(с реальным IP) и создайте туннель с динамеческим IPSec.

Прошу прощения, не очень понял.
На рутере A сейчас настроен Dynamic VPN Tunnel.
Local Subnet: 172.16.0.0
Local Netmask: 255.255.255.0

Надо настроить как-то еще?

Да, на обоих устройствах включен также xAUTH, но не думаю что это как-то влияет...

xAuth используется для авторизации одиночных станиций. Попробуйте установить соединение без него.

Отключил xAUTH, все без изменений.

Из 172.16.0.0/24 у меня нет доступа к 172.16.2.0/24.
А из 172.16.2.0/24 к 172.16.0.0/24 доступ есть.

Что же все-таки не так?

Проверил с помощью FTP.

На машине 172.16.0.101 работает ftp-сервер.
На машине 172.16.2.120 запустил ftp-клиент (обычный клиент из командной строки Windows XP).
Навигация, листинг и т.д. с машины 172.16.2.120 - все работает. Но при попытке скачать файл - появляется сообщение:

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

Клиент, запущеный на любой машине из сети 172.16.0.0/24, скачивает файл с этого сервера без каких-либо проблем, т.е. это не проблема самого сервера.

Очевидно, соединение из сети 172.16.0.0/24 на сеть 172.16.2.0/24 не проходит! И это, IMHO, связано с тем, что WAN-адрес роутера сети 172.16.2.0/24 находится за NAT'ом, а не смотрит напрямую в Инет.

У кого-нибудь вообще работает связка двух 824-ых, один из которых с реальным IP, а другой - за NAT'ом?

Уважаемый саппорт!

Поделитесь пожалуйста хоть какими-нибудь идеями! А то я уже в ступор вхожу...

У вас есть возможность на своем оборудовании эмулировать подобную ситуацию (один рутер за NAT'ом, другой напрямую)?

Спасибо!

experimentator
FTP
Если канал есть и проходят пакеты, то советую обратить внимание на MTU.

Ваш тест с FTP наводит на более банальное обьяснение - может большие пакеты не проходят? Попробуйте протестить ping длинными нефрагментироваными пакетами, или какой-нибуть утилиткой по портам побомбить. Попробуйте уменьшите размер MTU на обоих машинах.

Можно еще поигратся с параметрами VPN канала - возможно вы потеряете в скорости, но вдруг соединение заработает с медленными параметрами???

Может какой-то маршрутизатор (tracert) некореектно фрагментирует?

И какой у Вас тестовый стенд?

Я бы вам рекомендовал поднять на одном конце машину с RDP (VNC или RAdmin...). Если есть возможность тестировать с того конца, где нет реального IP - вообще прекрасно. В другой точке (с реальным IP) настроить удаленное администрирование 824, машину с RDP и VPN-сервер PPTP (на 824) - и можно тестировать практически все параметры из одного места. И проверять через любые сетевые утилиты в дополнение к реальным сервисам (типа FTP).

Провайдер со стороны рутера B дал реальный IP. Никакие настройки не менялись, но обе сети стали доступны друг из друга - так, как и ожидалось с самого начала.

Ну и что это может быть?

Кстати, пока с другой стороны есть реальный IP, я проверил также VPN-туннель с xAUTH: все работает без каких-либо проблем, обе сети доступны друг из друга.

Сегодня реальный IP снова должны отключить. Полагаю, связь снова станет "односторонней" - чудес же не бывает?

Обратитесь пожалуйста с проблемой на emai к Сергею Васильеву svasiliev@dlink.ru С описанием проблемы