Как заставить туннель использовать определённый интерфейс?

Question

[MaxxDamage]

Доброго времени суток. Вопрос возможно очень тривиальный, но при беглом поиске в интернете ответа не нашёл.
Суть в следующем. Имеется шлюз с тремя сетевыми интерфейсами. Два - интернет, с разными адресами, третий - локальная сеть. На шлюзе имеется VPN-туннель. Подскажите пожалуйста, как заставить клиентскую часть OpenVPN использовать нужный мне интерфейс? На серверной части такая настройка присутствует, в виде:

# Which local IP address should OpenVPN
# listen on? (optional)
local xx.xx.xx.xx
;local zz.zz.zz.zz

с возможностью переключения между основным и резервным каналом
Попытка применить такую же опцию в клиентской части ничего не дала, туннель вообще перестал работать

UPD: Неужели вопрос слишком сложный? Или наоборот, слишком тупой, что ответов нет?

Answer 1

[ky0]

Вопрос не сложный, просто вы непонятно его составили. Если несколько интерфейсов на шлюзе, при чём тут настройки на клиенте? Или шлюз и является клентом по отношению к какому-то внешнему впн-серверу?

Если я прав, то достаточно добавить статический маршрут до впн-сервера через нужный интерфейс. Поскольку впн-сервер про интерфейсы и резервирование ничего не знает (да и не должен знать), настраивать это нужно:
1. На клиенте
2. Разумеется, ДО подключения впна, то есть никак не в конфиге, приезжающем с сервера

Как вариант - написать скрипт, мониторящий туннель и в случае неработоспособности пытающийся подключиться с маршрутом через primary-интерфейс, а в случае неудачи - через secondary.

Comments

[MaxxDamage]

Да, наверное не очень понятно. Объясню детальнее:
Есть два офиса, в разных городах. Оба смотрят в интернет через шлюз на Debian. У обоих два интернет канала. Между собой связаны через OpenVPN. Само собой, один из них является сервером, другой клиентом. Так вот на серверной части есть вышеуказанная настройка, какой канал использовать. А в клиентской она не работает. Задача ещё усложняется тем что на серверной стороне два интернет канала от разных провайдеров, а на клиентской - от одного. Завтра буду в офисе, приложу конфиги примерные.
Второй канал на клиентской части нужен не как резерв, а постоянно - просто через туннель работает телефония, и её нужно развести с обычным инернетом, а как резервный вариант, всё пойдёт через один канал, но это я и ручками переключу.

[ky0]

MaxxDamage, ну, тогда просто добавьте статический маршрут на клиенте до впн-сервера через нужный интерфейс. Трогать конфиг впна при этом совершенно необязательно.

[MaxxDamage]

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 соединение всё равно идёт через дефолтный канал.

[ky0]

MaxxDamage, маршрут, если туннель пробрасывается через интернет, должен содержать внешний адрес впн-сервера - тот самый, который у вас в конфиге клиента указан.

[MaxxDamage]

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]

MaxxDamage, раз у вас филиалы в разных городах, маловероятно, что один шлюз подключается к другому по локальному адресу.

ip route add 1.2.3.4/32 dev ethX
Где 1.2.3.4 - адрес впн-сервера, devX - интерфейс, через который вы хотите, чтобы шёл трафик.

[MaxxDamage]

ky0, мда, эксперименты на расстоянии чреваты. Вообще пропал коннект к тому шлюзу (я к нему удалённо подключаюсь). Ладно, общий смысл я понял, буду экспериментировать дальше. Спасибо.

UPD: Коннект восстановился, часть траффика пошла по второму интерфейсу, вроде всё в порядке. Спасибо

UPD2: При такой настройке не могу подключиться к шлюзу по внешнему IP. Только по туннелю. Соответственно все веб-сервисы также недоступны по внешнему IP от меня. Я примерно понял в чём дело, но это уже частности.

[MaxxDamage]

ky0, извините что снова беспокою. Но проблему решить так и не получилось. Если на клиенте прописать вышеуказанный маршрут, то со стороны сервера его веб-сервисы становятся недоступны (те, доступ к которым идёт по IP)

[ky0]

MaxxDamage, нужно более подробное описание и хотя бы минимальная диагностика на сетевом уровне.

[MaxxDamage]

ky0,
На шлюзе со стороны клиента прописываю маршрут вида
route add 1.2.3.4/32 dev eth2
То он со стороны этого адреса (1.2.3.4/32) он (клиент) становится недоступен. Даже SSH не подключается, по туннелю доступ SSH остаётся.
Какого вида диагностика должна быть?

[ky0]

MaxxDamage, недоступен по внешнему адресу на eth2? А до добавления маршрута он по этому адресу доступен?

Дело может быть в несиметричности маршрутов - клиент получает данные через один интерфейс, а отправляет через другой. Иногда это нужно явным образом разрешить.

[MaxxDamage]

ky0, Нет, недоступен по адресу на eth1. Если маршрут убрать, снова становится доступен. Думаю дело в том, что я в маршруте прописываю адрес сервера, с которого потом и обращаюсь. Но что делать в этой ситуации, не соображу никак.

[ky0]

MaxxDamage, ну, собственно говоря - я именно про это и говорил =) Пакет прилетает на eth1, а отправляется с eth2. На сервере получается, что отправляется на один адрес, а возвращается с другого - конечно, так работать не будет.

Смотрите вот сюда: https://unix.stackexchange.com/questions/4420/repl...