Ubuntu → Настраиваем OpenVPN клиент Linux на примере Ubuntu

Здравствуйте.
Как и обещал, в выкладываю статью по настройке OpenVPN клиента Linux, мы с вами уже настроили OpenVPN сервер, и нам осталось настроить подключение к нему, иначе для чего он нам нужен, если к нему никто не подключается… С данным мануалом настройка будет весьма проста, эта схема была успешно оттестирована в условиях IT компании и работает по сей день.

Установим пакет OpenVPN:

sudo apt-get install openvpn

Поднимем права до root:

sudo -s

Теперь нам необходимо создать конфигурационный файл клиента.

nano /etc/openvpn/client.conf

С содержимым:

# Тип подключения -клиент
client

# Через какое устройстов подлючаемся
dev tun0

# Через какой протокол работаем, такойже как на сервере
proto tcp

# Адрес OpenVPN сервера и его порт (можно указать IP или URL)
remote openvpn.example.org 1194

# Тип шифрования, как на OpenVPN сервере
cipher AES-256-CBC

# Сертификат удостоверяющего центра
ca ca.crt

# Сертификат и ключ клиента
cert user.crt
key user.key

# Клиент поддерживает шифрование
tls-client

# Указываем путь к ключу TLS
tls-auth ta.key 1

# Включаем компрессию данных
comp-lzo

persist-key
persist-tun

# В документации рекомендуется этот пункт для клиентов с нестабильым доступом, например Wi-Fi
resolv-retry infinite

# Не использовать специфический порт для работы
nobind

# Скрипт работает при подключении, он обновляет записи в resolv.conf при подключении к серверу и очищает их при отколючении от OpenVPN сервера
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

# Статус-лог переданные данные и т.п.
status /var/log/openvpn-status.log
# Лог клиента
log /var/log/openvpn.log
# Уровень логирования 0 в лог попадают только записи о критических ошибках, если нужно подробнее, то выставляем 9 для дебагинга
verb 0
# Количество записей после которых будет производиться запись в лог
mute 20

Нам остаётся скачать c OpenVPN сервера, где живет наш удостоверяющий центр, 4 файла:

ca.crt
user.crt
user.key
ta.key

И положить их в директорию /etc/openvpn рядом с файлом client.conf

Перезапускаем openvpn

/etc/init.d/openvpn restart

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

traceroute 172.16.1.20
traceroute to 172.16.1.20 (172.16.1.20), 30 hops max, 60 byte packets
1 172.16.10.1 (172.16.10.1) 4.066 ms 8.001 ms 7.974 ms
2 172.16.1.20 (172.16.1.20) 7.952 ms 7.931 ms 7.910 ms

Видно что пакет ушел на адрес 172.16.10.1 и с интерфеса eth1 в локальную сеть к целевому IP

Выполним трассировку к google.ru, получаем ответ вида:

traceroute google.ru
traceroute to google.ru (173.194.32.159), 30 hops max, 60 byte packets
1 111.111.111.111 (111.111.111.111) 1.360 ms 1.252 ms 1.177 ms
2 46.61.227.225 (46.61.227.225) 1.865 ms 1.271 ms 1.707 ms
3 95.167.90.39 (95.167.90.39) 18.209 ms 95.167.90.37 (95.167.90.37) 18.170 ms 95.167.90.39 (95.167.90.39) 18.496 ms
4 74.125.146.86 (74.125.146.86) 17.827 ms 17.984 ms 17.946 ms
5 216.239.42.97 (216.239.42.97) 17.771 ms 18.058 ms 18.319 ms
6 216.239.42.83 (216.239.42.83) 17.765 ms 216.239.42.49 (216.239.42.49) 19.130 ms 19.004 ms
7 72.14.236.242 (72.14.236.242) 19.287 ms 18.554 ms 18.802 ms
8 173.194.32.159 (173.194.32.159) 18.025 ms 18.269 ms 18.224 ms

Видно что ответ вылетел черз шлюз сети к которой подключен клиент, а не через наш VPN канал

Для обычного пользователя все работает как надо, чтобы проверить под пользователем supersuer нам необходимо положить ключи в директорию openvpn и поменять запись в client.conf указывающих на названия ключа и сертификата

перезапустить OpenVPN клиента и повторить трасисровку пакетов

traceroute 172.16.1.20
traceroute to 172.16.1.20 (172.16.1.20), 30 hops max, 60 byte packets
1 172.16.10.1 (172.16.10.1) 4.066 ms 8.001 ms 7.974 ms
2 172.16.1.20 (172.16.1.20) 7.952 ms 7.931 ms 7.910 ms

В локальную сеть пакеты ходят без изменений, тут ничего не поменялось

traceroute google.ru
traceroute to google.ru (173.194.122.248), 30 hops max, 60 byte packets
1 172.16.10.1 (172.16.10.1) 6.115 ms 11.448 ms 11.500 ms
2 222.222.222.222 (222.222.222.222) 11.614 ms 11.649 ms 11.676 ms
3 10.158.192.1 (10.158.192.1) 11.691 ms 11.705 ms 11.719 ms
4 v811.m9-3.caravan.ru (212.24.42.49) 11.729 ms 11.744 ms 11.751 ms
5 msk-ix-gw1.google.com (195.208.208.232) 11.736 ms 15.341 ms 15.350 ms
6 66.249.94.100 (66.249.94.100) 15.346 ms 5.884 ms 8.451 ms
7 72.14.252.22 (72.14.252.22) 49.777 ms 49.787 ms 49.796 ms
8 173.194.122.248 (173.194.122.248) 49.510 ms 49.620 ms 49.671 m

А тут видно что пакет попал на наш OpenVPN сервер и вылетел во внешний мир через интерфейс eth0
Значит и эта маршрутизация работает правильно

На этом я свой опус пожалуй и закончу, если нашли ошибку пишите в личку, возникли вопросы оставляйте их в комментариях.