Я настраиваю сервер (точнее, виртуальную машину), на котором работает CentOS 6.4. у меня есть eth0 адаптер на машине CentOS, подключенной к Интернету (через мостовую сеть на хосте). Адаптер eth0 настраивается через DHCP. Все идет нормально.
Я также хочу, чтобы на сервере работал VPN-клиент и чтобы он подключился через tun0 адаптер к интернету. Клиент VPN успешно подключается с помощью OpenVPN. Он производит default маршрут с метрикой 0.
Итак, во-первых, это возможно, правда? Во-вторых, насколько я понимаю, это можно сделать двумя способами: увеличить метрику route что проходит через eth0 или уменьшите метрику route что проходит через tun0.
Я пытался сделать и то, и другое, но пока безуспешно. Я пробовал это: добавление METRIC=100 линия в /etc/sysconfig/network-scripts/ifcfg-eth0, однако это не меняет метрики маршрута.
Я также пробовал добавить metric вариант для client.conf файл для OpenVPN. Это тоже не повлияло (я считаю, что это из-за того, что pull вариант в этом файле).
Моя самая радикальная идея заключалась в том, чтобы вручную удалить route для eth0 и замените его тем же маршрутом, но с более высокой метрикой. К сожалению, я тоже не могу этого сделать, поскольку перезапуск сети приведет к сбросу настроек, а запуск демона, который делает это все время, не кажется хорошим решением.
Я открыт для предложений и идей. Спасибо.
Итак, если я правильно понимаю проблему, то в основном у вас есть компьютер с интерфейсом, настроенным на DHCP, и вы хотите подключиться к VPN и передавать весь свой трафик через VPN.
У вас возникают проблемы, когда DHCP-сервер продлевает аренду, он повторно добавляет шлюз, предоставленный DHCP-сервером.
Я предлагаю вам обновить client.conf и заменить redirect-gateway вариант с redirect-gateway def1. Это указывает OpenVPN добавить два маршрута, которые более конкретны, чем шлюз по умолчанию, вместо того, чтобы удалять уже существующий шлюз по умолчанию и добавлять новый.
Когда вы используете redirect-gateway def1 вы получите таблицу маршрутов, которая выглядит примерно так, как показано ниже. Поскольку наиболее точным совпадающим маршрутом является тот, который используется, маршруты для 0.0.0.0/1, и 128.0.0.0/1 взять прецедент по маршруту по умолчанию, но без беспорядочной работы по удалению / замене маршрута по умолчанию. Это также отменяет требование о том, чтобы никакое другое программное обеспечение не изменяло маршрут по умолчанию.
# ip route
10.3.195.17 dev tun_rem proto kernel scope link src 10.3.195.18
172.26.222.0/23 dev eth1 proto kernel scope link src 172.26.222.204
0.0.0.0/1 via 10.3.195.17 dev tun_rem
128.0.0.0/1 via 10.3.195.17 dev tun_rem
default via 172.26.222.1 dev eth1
Если redirect-gateway настройка не устанавливается в вашем client.conf, тогда вам может потребоваться также добавить "route-nopull возможность игнорировать маршруты, полученные от VPN-сервера.