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 соединение всё равно идёт через дефолтный канал.
Да, наверное не очень понятно. Объясню детальнее:
Есть два офиса, в разных городах. Оба смотрят в интернет через шлюз на Debian. У обоих два интернет канала. Между собой связаны через OpenVPN. Само собой, один из них является сервером, другой клиентом. Так вот на серверной части есть вышеуказанная настройка, какой канал использовать. А в клиентской она не работает. Задача ещё усложняется тем что на серверной стороне два интернет канала от разных провайдеров, а на клиентской - от одного. Завтра буду в офисе, приложу конфиги примерные.
Второй канал на клиентской части нужен не как резерв, а постоянно - просто через туннель работает телефония, и её нужно развести с обычным инернетом, а как резервный вариант, всё пойдёт через один канал, но это я и ручками переключу.
АртемЪ, мда... то есть, если восстановление GRUB не поможет, то только вручную все настройки восстанавливать из имеющихся данных? Да я рехнусь чёрт побери...
Ну, то есть, толку особо с этого восстановления нет в моей ситуации, как я понимаю, так как диск был чисто системный, и из данных на нём была собственно только система, которая не грузится.
З.Ы. Ошибок при восстановлении было всего 3, я надеялся что как-то можно восстановить хотябы MBR
Ezhyg, ТС вроде про объем ничего не говорил. Если выводить картинку с компа, ну грубо говоря, интерфейс винды - то это и будет плоская картинка, разве нет?
Я скорее всего глупость скажу, а как же проецирование на бесконечность, как в коллиматоре? На нём же можно сфокусироваться, или он тоже работает до какого-то минимального расстояния от глаза?
Рональд Макдональд,
ii kav4fs 8.0.2-256 i386 Kaspersky Anti-Virus for Linux File Server
un kav4samba <нет> (описание недоступно)
un kav4ws <нет> (описание недоступно)
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
Клиент
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
сервера:
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
клиента:
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 у старого шлюза тоже не отличается.