Не буду спорить, но перезапуская клиента Вы не обеспечиваете обновление IP-адреса на сервере DynDNS, если до последнего нет маршрута. А его нет.
Предлагаю провести эксперимент таким образом:
1. Запускаем всё с дефолтным маршрутом через VPN
2. Убеждаемся, что клиент OpenVPN "присосался" и в одной из консолей пингуем его внутри OpenVPN
3. Добавляем до NAT-шлюза клиента маршрут через ppp (как Вы выше сами писали)
4. убиваем дефолтный маршрут
На всех этапах пинг до клиента должен скакать.
В этой последовательности работает. Пинг есть. А вот если после этого разорвать OpenVPN соединение, ничего не меняя в маршрутах, то в этот раз входящего подключения от OpenVPN клиента уже нету. Очень странно. Думаю что в этом и есть суть проблемы.
Но это только для проверки теории. Для практики - это всё ерунда, потому как у клиента, как Вы сами написали IP скачет.
Так что мне кажется, что выходом будет полное блокирование траффика средствами iptables через ppp0, кроме OpenVPN и DynDNS
У какого клиента скачет? У OpenVPN клиента, который за NAT-ом IP NAT-а всегда один и тот же. Динамический адрес у моего ноута, на котором установлен OpenVPN сервер и на котором же DynDNS клиент.
Пользователь решил продолжить мысль 18 Декабря 2010, 20:02:27:
У кого еще есть идеи?
Пользователь решил продолжить мысль 18 Декабря 2010, 23:08:05:
Ответ был найден.
Во-первых. Для того чтобы трафик только до и с определенных IP-адресов шел через VPN соединение, нужно было добавить маршрут такого вида:
sudo route add ext_host gw vpn_ext_ip if
где:
ext_host — IP-адрес хоста до которого должен идти трафик
vpn_ext_ip — внешний IP-адрес, выдаваемый VPN-сервером
if — название интерфейса VPN-соединения (например, ppp0).
И так тоже вроде работает:
sudo route add ext_host if
Во-вторых, нужно было заставить DynDNS-клиент отправлять IP-адрес интерфейса, на котором был поднят VPN-сервис, а не вычислять его через WEB.