Предыстория
Радость от появления пакета OpenVPN для сетевого хранилища Synology быстро прошла. Попытка настроить сеть для малого офиса, закончилась практически не начавшись. В интерфейсе для настройки пакета отсутствовали все прелести этого самого пакета (доступна только авторизация по логину и паролю).
Недавно наткнулся на статью: «Учим NAS Synology маршрутизировать трафик в OpenVPN туннель с аутентификацией по сертификату».
Вроде бы то, что надо. Но!
Как оказалось, даже подобное вмешательство «руками» в недра прошивки не позволяет поднимать соединения через TAP-интерфейсы.
Ну, что ж. Не останавливаться же на половине пути…
Суть проблемы
Если сделать все, как указано в статье, упомянутой выше, только с типом адаптера TAP, то получим следующий эффект:
1. Выбираем соединение VPN, нажимаем подключить.
2. В SSH сессии видим что туннель поднялся, сервер пингуется, данные идут. Но интерфейс Synology говорит нам что происходит «Подключение».
3. Через 15-20 секунд интерфейс вежливо сообщает, что подключится не удалось, и закрывает работающее соединение.
Детальное изучение происходящего выявило, что во всех скриптах устройства, прописаны алгоритмы для определения статуса OpenVPN соединения, основываясь на том, что они могут быть только TUN.
Об этом так же свидетельствуют все комментарии в скриптах.
Решение проблемы
На момент написание статьи на устройстве установлена прошивка DMS 5.0-4493 Update 1.
Соответственно, все описанное здесь актуально для неё.
Для удобства управления скриптами было решено хранить все на админской сетевой шаре.
Создаем на ней папку OpenVPN, в ней будет располагаться всё необходимое для работы клиента:
1. Файл конфигурации OpenVPN «tap.conf»:
dev tap
proto udp
remote ServerIP 444
client
tls-client
ns-cert-type server
ca key/ca.crt
cert key/Client1.crt
key key/Client1.key
comp-lzo yes
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
ping-restart 12
ping 3
status log/openvpn-status.log
log log/openvpn.log
script-security 2
float
2. Папка с сертификатами: «key»
3. Папка с логами: «log»
4. Скрипты запуска/остановки VPN.
Start.sh (запуск туннеля):
#!/bin/sh
CONF_DIR="/volume1/adm/OpenVPN/"
OPENVPN_CONF="tap.conf"
KERNEL_MODULES="x_tables.ko ip_tables.ko iptable_filter.ko nf_conntrack.ko nf_defrag_ipv4.ko nf_conntrack_ipv4.ko nf_nat.ko iptable_nat.ko ipt_REDIRECT.ko xt_multiport.ko xt_tcpudp.ko xt_state.ko ipt_MASQUERADE.ko tun.ko"
SERVICE="ovpnc"
# Make device if not present (not devfs)
if [ ! -c /dev/net/tun ]; then
# Make /dev/net directory if needed
if [ ! -d /dev/net ]; then
mkdir -m 755 /dev/net
fi
mknod /dev/net/tun c 10 200
fi
/usr/syno/bin/iptablestool --insmod $SERVICE ${KERNEL_MODULES}
echo "Starting openvpn client..."
/usr/sbin/openvpn --daemon --cd ${CONF_DIR} --config ${OPENVPN_CONF} --writepid /var/run/ovpn_client.pid
Stop.sh (остановка туннеля):
#!/bin/sh
echo "Kill openvpn client..."
/bin/kill `cat /var/run/ovpn_client.pid` 2>/dev/null
OnLine.sh (перезапуск туннеля, если сервер не доступен):
#!/bin/sh
ping -c 3 10.23.122.1
if [ $? -ne 0 ]; then
echo "Stoping VPN.."
sh Stop.sh
echo "Sleep 5."
sleep 5
echo "Start...."
sh Start.sh
fi
В общем этого достаточно.
Как показали тесты, VPN успешно перезапускается автоматически при отключении интернета или удаленного сервера. Скрипт OnLine писался больше для автоматического запуска VPN вместе с NAS. Но штатный планировщик позволяет добавить выполнение скрипта «каждый час», поэтому добавил проверку на доступность.
При такой реализации прошивка NAS понятия не имеет о туннели (оно и к лучшему), но при этом все ресурсы удаленной сети доступны (сетевое резервирование на IP из VPN прекрасно проходит).
Автор: Venom13
