res2001, а что, нужно на каждом компе сети прописывать маршрут? Но в старой конфигурации такого не было. Были указаны шлюзы по умолчанию и всё.
192.168.0.127 - это комп в сети сервера. Я его и пинговал с клиента. Результат выше.
Пинг изнутри сети клиента компьютера внутри сети сервера:
spoiler
20:26:11.696101 IP 192.168.1.105 > 192.168.0.127: ICMP echo request, id 1, seq 19, length 40
20:26:16.688104 IP 192.168.1.105 > 192.168.0.127: ICMP echo request, id 1, seq 20, length40
20:26:21.695406 IP 192.168.1.105 > 192.168.0.127: ICMP echo request, id 1, seq 21, length 40
res2001, так открыто всё на tun0, настройки iptables тоже приложил выше. Ошибок судя по всему в логах нет, но на всяки случай скину тоже их.
лог сервера:
res2001, причесал настройки OpenVPN. Маршруты есть, судя по выхлопу ip route
Сервер:
spoiler
ip route
default via 94.181.xxx.xxx dev eth2 onlink
10.8.0.0/24 via 10.8.0.2 dev tun0
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
94.181.xxx.x/24 dev eth2 proto kernel scope link src 94.181.xxx.xx
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.1
192.168.1.0/24 via 10.8.0.2 dev tun0
клиент:
spoiler
default via 94.180.zzz.zzz dev eth0
10.8.0.1 via 10.8.0.9 dev tun0
10.8.0.9 dev tun0 proto kernel scope link src 10.8.0.10
94.0.0.0/8 via 94.180.zzz.zzz dev eth0
94.180.zzz.z/24 dev eth0 proto kernel scope link src 94.180.zzz.zzz
94.180.250.0/24 dev eth2 proto kernel scope link src 94.180.250.147
192.168.0.0/24 via 10.8.0.9 dev tun0
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1
iptables на сервере:
spoiler
-A FORWARD -i tun0 -j ACCEPT
-A FORWARD -o tun0 -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -d 192.168.1.0/24 -j ACCEPT
-A FORWARD -s 192.168.1.0/24 -d 10.8.0.0/24 -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -d 192.168.0.0/24 -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -d 10.8.0.0/24 -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -d 192.168.1.0/24 -j ACCEPT
-A FORWARD -s 192.168.1.0/24 -d 192.168.0.0/24 -j ACCEPT
И всё равно не работает - с клиента пингуется только сервер, сеть за сервером не пингуется. С сервера не пингуется даже клиент.
Да это я уже экспериментировал с настройками. Изначально так и было - на сервере route 192.168.1.0 255.255.255.0, в ccd указано iroute 192.168.1.0 255.255.255.0.
Изначально конфиг переносился с уже работающего сервера, на клиенте только заменили ip адрес по которому он обращается к серверу, и всё. Но всё равно не работало. Точнее, работало, но только в одну сторону - со стороны сети сервера сеть клиента пинговалась, со стороны клиента пинговался только сервер. Все настройки iptables тоже были перенесены со старого шлюза, с заменой адресов на пробросах. Вот разве что у нового и старого сервера не совпадают сетевые интерфейсы. Сегодня вечером попробую переподключить их так же как на старом
res2001, да, шлюз, он же сервер OpenVPN. Клиент OpenVPN остаётся на старом месте, там ничего не меняется. Внутри сети IP адрес тот же, да (192.168.0.1). Поменялся собственно только сетевой интерфейс локальной сети (и в настройках был изменён), и внешний IP-адрес. Хотя возможно было правильнее подключить сети к тем же интерфейсам что и на старом...
res2001, да, клиент видит и пингует сервер (192.168.0.1), но дальше не видит. А сервер не пингует клиента. Логи щас уже приложить не могу, днём приходится переключать всё на старый шлюз, чтобы хоть как-то работало.
С маршрутизацией и прошу подсказать - вроде маршруты такие же как на старом шлюзе, но не работает.
local 94.181.xx.xx
port 649xx
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.1.0 255.255.255.0 10.8.0.2"
client-config-dir xxx
route 192.168.1.0 255.255.255.0 10.8.0.1
tls-auth ta.key 0
auth SHA512
tls-version-min 1.2
cipher AES-128-CBC
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
log /var/log/openvpn.log
Клиент
spoiler
client
dev tun
proto udp
remote 94.181.xx.xx 649xx
route 192.168.0.0 255.255.255.0
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ca ca.crt
cert kaxxx.crt
key kaxxx.key
ns-cert-type server
tls-auth ta.key 1
auth SHA512
cipher AES-128-CBC
comp-lzo
verb 3
log /var/log/openvpn.log
Ответ ip ro li
сервера:
spoiler
default via 94.181.xxx.xxx dev eth0 onlink
10.8.0.0/24 via 10.8.0.2 dev tun0
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
94.0.0.0/8 via 94.181.180.254 dev eth0
94.181.xxx.0/24 dev eth0 proto kernel scope link src 94.181.xxx.xx
94.181.xxx.0/24 dev eth1 proto kernel scope link src 94.181.xxx.xxx
192.168.0.0/24 dev eth2 proto kernel scope link src 192.168.0.1
192.168.1.0/24 via 10.8.0.2 dev tun0
клиента:
spoiler
default via 94.180.zzz.zzz dev eth0
10.8.0.1 via 10.8.0.9 dev tun0
10.8.0.9 dev tun0 proto kernel scope link src 10.8.0.10
94.0.0.0/8 via 94.180.249.254 dev eth0
94.180.zzz.0/24 dev eth0 proto kernel scope link src 94.180.zzz.zzz
94.180.zzz.0/24 dev eth2 proto kernel scope link src 94.180.zzz.zzz
192.168.0.0/24 via 10.8.0.9 dev tun0
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1
Собственно все настройки перенесены с другого сервера, к котором раньше подключался клиент. Но понадобилось перенести всё это на другую машину, с другими наружными IP-адресами. При переключении на старый шлюз всё работает. На новом, с аналогичными настройками (само собой заменены сетевые интерфейсы и IP-адреса в настройках) - не работает. Вывод ip ro li у старого шлюза тоже не отличается.
ky0, Нет, недоступен по адресу на eth1. Если маршрут убрать, снова становится доступен. Думаю дело в том, что я в маршруте прописываю адрес сервера, с которого потом и обращаюсь. Но что делать в этой ситуации, не соображу никак.
ky0,
На шлюзе со стороны клиента прописываю маршрут вида
route add 1.2.3.4/32 dev eth2
То он со стороны этого адреса (1.2.3.4/32) он (клиент) становится недоступен. Даже SSH не подключается, по туннелю доступ SSH остаётся.
Какого вида диагностика должна быть?
ky0, извините что снова беспокою. Но проблему решить так и не получилось. Если на клиенте прописать вышеуказанный маршрут, то со стороны сервера его веб-сервисы становятся недоступны (те, доступ к которым идёт по IP)
ky0, мда, эксперименты на расстоянии чреваты. Вообще пропал коннект к тому шлюзу (я к нему удалённо подключаюсь). Ладно, общий смысл я понял, буду экспериментировать дальше. Спасибо.
UPD: Коннект восстановился, часть траффика пошла по второму интерфейсу, вроде всё в порядке. Спасибо
UPD2: При такой настройке не могу подключиться к шлюзу по внешнему IP. Только по туннелю. Соответственно все веб-сервисы также недоступны по внешнему IP от меня. Я примерно понял в чём дело, но это уже частности.
ky0,
В таком виде?
route add -net 10.8.0.9 netmask 255.255.255.255 gw ZZ.ZZ.ZZ.ZZ где "gw ZZ.ZZ.ZZ.ZZ" - ip адрес vpn сервера? Не работает так, выдаёт "SIOCADDRT: Сеть недоступна"
ky0, указал маршрут вида
10.8.0.9 94x180x***x***. 255.255.255.255 UGH 0 0 0 eth2
Где 10.8.0.9 - gateway туннеля, 94x180x***x*** - gateway второго интернет-канала. Но судя по jnettop соединение всё равно идёт через дефолтный канал.