Полный разбор файла конфигурации OpenVPN
apt-get install openvpn |
Далее создаём файл конфигурации сервера
touch /etc/openvpn/server.conf |
при загрузке системы автоматически поднимаются все VPN соединения, для которых в папке /etc/openvpn есть соответствующие файлы с расширением .conf у меня он получился примерно таким.
port 1194 #Порт proto udp #Протокол dev tun #Название виртуального устройства ca /etc/openvpn/ca.crt cert /etc/openvpn/server.crt key /etc/openvpn/server.key # This file should be kept secret dh /etc/openvpn/dh1024.pem server 10.10.10.0 255.255.255.0 # vpn subnet ifconfig-pool-persist ipp.txt # Тут будут храниться ip адреса клиентов push "route 192.168.5.0 255.255.255.0" # home keepalive 10 120 comp-lzo user nobody group nogroup persist-key persist-tun status openvpn-status.log log-append openvpn.log verb 4 mute 20 client-to-client client-config-dir /etc/openvpn/ccd # Тут будут настройки для каждого филиала route 192.168.0.0 255.255.255.0 # Маршрут от сервера до филиала 1 route 192.168.1.0 255.255.255.0 # Маршрут от сервера до филиала 2 |
Создаём каталог, в котором будут хранится индивидуальные настройки клиентов:
mkdir /etc/openvpn/ccd |
Теперь необходимо создать ключи и сертификаты для шифрования и авторизации
cd /usr/share/doc/openvpn/examples/easy-rsa/2.0 source ./vars ./clean-all ./build-ca |
UPD1
если у вас получается как-то так
# source ./vars ************************************************************** No /usr/share/doc/openvpn/examples/easy-rsa/2.0/openssl.cnf file could be found Further invocations will fail ************************************************************** NOTE: If you run ./clean-all, I will be doing a rm -rf on /usr/share/doc/openvpn/examples/easy-rsa/2.0/keys |
или вот так
# ./build-ca grep: /usr/share/doc/openvpn/examples/easy-rsa/2.0/openssl.cnf: Нет такого файла или каталога pkitool: KEY_CONFIG (set by the ./vars script) is pointing to the wrong version of openssl.cnf: /usr/share/doc/openvpn/examples/easy-rsa/2.0/openssl.cnf The correct version should have a comment that says: easy-rsa version 2.x |
то скорее всего нет файла openssl.cnf я вышел из ситуации примерно так
cp /usr/share/doc/openvpn/examples/easy-rsa/2.0/openssl-1.0.0.cnf /usr/share/doc/openvpn/examples/easy-rsa/2.0/openssl.cnf |
и тут снова продолжаем на том моменте где был косяк.
Теперь создадим сертификат и приватный ключ для сервера:
./build-key-server server |
Создаём ключ для клиента (если клиентов несколько, процедуру придётся повторить):
./build-key client1 |
для каждого клиента должно быть указано своё уникальное имя (в данном случае client1).
Процедура подключения Win клиентов описана тут
если новый клиент создаётся спустя некоторое время, процедура будет выглядеть следующим образом:
cd /usr/share/doc/openvpn/examples/easy-rsa/2.0 source ./vars ./build-key client2 |
Генерируем параметры Диффи-Хеллмана:
./build-dh |
Помещаем следующие файлы в директорию /etc/openvpn/
* ca.crt * server.crt * dh1024.pem * server.key |
Создаём файл /etc/openvpn/ipp.txt
Конфигурационный файл клиентской машины /etc/openvpn/client.conf у меня получился примерно таким
remote 111.111.111.111 1194 client dev tun proto udp resolv-retry infinite # this is necessary for DynDNS nobind user nobody group nogroup persist-key persist-tun ca /etc/openvpn/ca.crt cert /etc/openvpn/client1.crt key /etc/openvpn/client1.key comp-lzo verb 4 mute 20 redirect-gateway #show-net-up verb 4 |
Теперь необходимо скопировать с сервера в папку /etc/openvpn/ сгенерированные клиентские ключи и авторитарный сертификат сервера:
* ca.crt * client1.crt * client1.key |
Если за клиентом скрывается сеть 192.168.1.х то, чтоб сервер видел её нужно добавить на сервер маршрут до неё.
На сервере создаём файл /etc/openvpn/ccd/client1 такого содержания:
iroute 192.168.1.0 255.255.255.0 # роутинг на сеть филиала2, чтоб 2 филиала знали друг друга #push "route 192.168.100.0 255.255.255.0" #Заворачиваем весь трафик в OpenVPN push "redirect-gateway def1" |
Вот тут собственно и случилась самая злая проблема у меня.
OpenVPN получив директиву
push "redirect-gateway def1" |
(при наличии ‘pull’ в своей конфигурации), клиент не удаляет старый маршрут, а добавляет в таблицу маршрутизации записи вида:
0.0.0.0/1 via 192.168.231.5 dev tun0 128.0.0.0/1 via 192.168.231.5 dev tun0 |
и если openvpn идёт по ethernet то всё работает и радует админа и пользователей, но великий ppp любит поднимать вот такой маршрут.
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0 |
И вот OpenVPN ругается примерно вот так
Jul 2 19:28:53 ino ovpn-client[14465]: NOTE: unable to redirect default gateway -- Cannot read current default gateway from system |
Решение этой проблемы искалось долго и нудно, хотя оно на поверхности. если в этом «кривом» маршруте ppp указывать шлюз вместо 0.0.0.0 реальный шлюз, то ОpenVPN видит этот маршрут и добавляет свой без проблем.
Поэтому я создал файл
/etc/ppp/ip-up.d/routing |
В который прописал небольшой скрипт. (прошу ногами не пинать, я очень ленивый, и полноценный скрипт определения шлюза и правки маршрутов писать не стал, а сделал как простой костыль)
Буду очень рад, если кто-то предложит более логичный, надёжный, и универсальный метод правки маршрутов на лету.
Пока ещё нет уверенности, что всё будет на 100% работать при обрывах ppp, Но жизнь покажет, если что — поправлю топик.
#! /bin/sh
#Определяем выданный шлюз по умолчанию у меня он всегда разный но в сети 222.х.х.х
gw1=`ip route show | grep 222 | awk '{print $1}'`
# Удаляем 0.0.0.0 0.0.0.0
route del default
# Добавляем маршрут с верным шлюзом
route add -net default gw ${gw1} dev ppp0 |
Делаем его исполняемым
chmod ug+x /etc/ppp/ip-up.d/routing |
После чего ребут, спустя некоторое время сервер перестал пинговаться по внешнему ипу, но стал отзываться по внутреннему — 10.10.10.26
ЗЫ Прошу принять во внимание, что файрволл шлюза и сервера и клиента надо поправить, для того, чтоб у пользователей был жизненно важный интернет.
Например я, сделал это так:
-A POSTROUTING -s 192.168.0.0/255.255.0.0 -j MASQUERADE |
Тут не указана привязка ни к внешнему интерфейсу, ни ip
когда по разным причинам у нас не будет openvpn то у пользователей будет прямой инет, а когда он появится, то весь трафик полетит через него.
Заключение
В жизни эта система собирается поэтапно, сначала запускается впн сервер и впн клиент, пингуют друг друга по адресам 10.10.10.х дальше добавляются маршруты до сетей, что стоят за сервером и клиентом, пингуются проверяются, когда всё будет стабильно и надёжно добавляем директиву
push "redirect-gateway def1" |
И снова добиваемся работы и жизни, всё было проделано не выходя из офиса, на шлюзах филиалов, были подписаны сетевые интерфейсы, чтоб админ просто воткнул сетевые кабеля и питание, позвонил мне, а дальше я уже по ssh настраивал на рабочий лад.
Отзыв сертификата
http://mdex-nn.ru/page/blokirovka-sertifikat-openvpn.html
