История изменений
Исправление vel, (текущая версия) :
1. Прописать на openvpn-сервере маршрут до роутера для пакетов, предназначенных в сеть 192.168.1.0/24. Я попробовал такую команду:
route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.2.50 metric 1
Да, без этого никак, но метрика нафиг не нужна. Это обычно делается из конфига openvpn через
route 192.168.1.0 255.255.255.0 192.168.2.50# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default gw.special.maro 0.0.0.0 UG 0 0 0 eth0 192.168.1.0 192.168.2.50 255.255.255.0 UG 1 0 0 tun0 192.168.2.0 * 255.255.255.0 U 0 0 0 tun0 193.124.184.0 * 255.255.248.0 U 0 0 0 eth0Тут меня смущает два гейтвея. Но вроде из-за того что метрика для 192.168.1.0/24 равна 1, эта маршрутизация должна происходит раньше маршрута default.
Какие 2 гейтвея? Где?
Удалите нафиг этот упоротый route! Или хотя бы запускайте его с "-n"
С таблицами маршрутизации все нормально. Все маршруты есть.
«ip ro get 192.168.1.5» нам пофиг есть живой адрес или нет. Интересует куда ядро отправит пакет если адрес назначения находится в удаленной сети.
Если на vds запустить «ping 192.168.1.X» где Х > 1 и «tcpdump -ni tun0» будет показывать пакеты с 192.168.2.1 на 192.168.1.X, то на vds все хорошо и проблему нужно искать в ddwrt.
На ddwrt нужно отключить NAT на tun1. Нужно убедиться, что на ddwrt нет фильтраци на tun1. Я никогда не сталкивался с ddwrt, так что как это сделать не знаю.
IMHO годный рецепт
Если на ddwrt есть tcpdump, то это упростит диагностику.
Про openvpn сервер. IMHO лучше сделать для ddwrt ccd, где через «ifconfig-push 192.168.2.50 255.255.255.0» выдавать ему всегда один и тот же адрес.
Исходная версия vel, :
1. Прописать на openvpn-сервере маршрут до роутера для пакетов, предназначенных в сеть 192.168.1.0/24. Я попробовал такую команду:
route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.2.50 metric 1
Да, без этого никак, но метрика нафиг не нужна. Это обычно делается из конфига openvpn через
route 192.168.1.0 255.255.255.0 192.168.2.50# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default gw.special.maro 0.0.0.0 UG 0 0 0 eth0 192.168.1.0 192.168.2.50 255.255.255.0 UG 1 0 0 tun0 192.168.2.0 * 255.255.255.0 U 0 0 0 tun0 193.124.184.0 * 255.255.248.0 U 0 0 0 eth0Тут меня смущает два гейтвея. Но вроде из-за того что метрика для 192.168.1.0/24 равна 1, эта маршрутизация должна происходит раньше маршрута default.
Какие 2 гейтвея? Где?
Удалите нафиг этот упоротый route! Или хотя бы запускайте его с "-n"
С таблицами маршрутизации все нормально. Все маршруты есть.
«ip ro get 192.168.1.5» нам пофиг есть живой адрес или нет. Интересует куда ядро отправит пакет если адрес назначения находится в удаленной сети.
Если на vds запустить «ping 192.168.1.X» где Х > 1 и «tcpdump -ni tun0» будет показывать пакеты с 192.168.2.1 на 192.168.1.X, то на vds все хорошо и проблему нужно искать в ddwrt.
На ddwrt нужно отключить NAT на tun1 Нужно убедиться, что на ddwrt нет фильтраци на tun1. Я никогда не сталкивался с ddwrt, так что как это сделать не знаю.
IMHO годный рецепт
Если на ddwrt есть tcpdump, то это упростит диагностику.
Про openvpn сервер. IMHO лучше сделать для ddwrt ccd, где через «ifconfig-push 192.168.2.50 255.255.255.0» выдавать ему всегда один и тот же адрес.