IPv6 over OpenVPN в VPS Ubuntu 16.04.3 LTS

Для сервера на Ubuntu 16.04.3 LTS, со статическим IP-адресом (ради чего и  затевалось) достаточно просто  настроить IPv6 адресацию, посредством автоматического туннеля 6to4.
Далее, можно выданные подсети IPv6 распространить на тунельное подключение OpenVPN.
Клиенты OpenVPN смогут получить маршрутизируемые IPv6 адреса и стать доступными из сети Интернет.
Таким образом, обойдя NAT/NAT/NAT в цепочке подключения к ip-сети в своём городе, можно получить подключение к настоящей сети Интернет.
Настоящая сеть Интернет, даёт возможность оставить дома включённый компьютер, дисковый массив или камеру, уехать на край света и беспроблемно получить доступ - будь то VNC, FTPS, webdav - да что угодно.

В российской мобильной индустрии уже начали предлагать доступ к IPv6. Некоторые провайдеры тоже обеспечивают выдачу клиенту желаемого, но не всегда так, как хотелось бы - пока экспериментируют, смотрят.
Стоп, а что-же я жду и не бегу за 4g модемом и подключением. А ну да, отсутствует конкурентное тарифное предложение.


Итак, единственная трудность для подключения автоматического туннеля ipv6 - это как раз преобразование статического IP-адреса в шестнадцатиричный вид, чтобы поместить его в ipv6-префикс.
Но для этого есть сервисная страница по адресу:  6to4.version6.ru

А дальше, в файл /etc/network/interfaces вносится определение туннеля, полученное по ссылке выше на основе IP-адреса сервера, вот так:


auto tun6to4
iface tun6to4 inet6 v4tunnel
    pre-up modprobe ipv6
    address 2002:XXXX:XXXX::1
        netmask 16
    gateway ::192.88.99.1
    endpoint any
    local XX.XXX.XX.XXX

# If you have set up an IPv6-capable firewall (and you should),
# it can be enabled by using an "up" rule, such as the example below.
#       up /usr/local/sbin/ipv6firewall.sh tun6to4

local XX.XXX.XX.XXX - это IPv4-адрес сервера.
2002: - это префикс для туннелей 6to4.
XXXX:XXXX - IPv4-адрес сервера, в шестнадцатиричном формате.

После этого, стартуертся интерфейс:

ifup tun6to4


Для клиентов OpenVPN делается правка (3 строчки) для поддержки IPv6 в туннеле:

# OpenVPN server KVM1
# Open Virtual Private Network server test configuration
# server: kvm1
# date: april 28, 2018

port 1194
proto tcp
dev tun

# Certificate Authority (CA) - public key
ca /etc/openvpn/authorities/authority.crt
# Certificate - public key of the server, signed with CA private key via request
cert /etc/openvpn/keys/testserver.crt
# Private key (key) - secret data, private key of server
key /etc/openvpn/keys/testserver.key

# Diffie Hellman parameters
# openssl dhparam -out dh2048.pem 2048

dh /etc/openvpn/keys/dh2048.pem

# IP-address of the server
local 81.177.6.229

keepalive 10 120

topology subnet
server 192.168.6.0 255.255.255.0
push "route 192.168.6.0 255.255.255.0"
push "redirect-gateway def1"

# IPv6 support
server-ipv6 2002:XXXX:XXXX:abcd::/64
push "route-ipv6 2000::/3"
push "dhcp-option DNS 2001:4860:4860::8888"

abcd - это префикс, выделенный (придуманный мной) для подсети клиентов openvpn.

Это пока не полная конфигурация openvpn на стороне сервера, т.к. там ещё много всяких фишек, которые можно применить для своих задач. Учебная конфигурация.

После получение IPv6-адресов, настольные компьютеры становятся беззащитными. Но они, пока ещё в разряде тех, кто никому не нужен.

Для каждого надо настроить защиту от подключений и пр.
Это позже.

Также замечу, что нужно настроить форвардинг пакетов (IPv4 и IPv6 в туннель. Маскарад и пр. правила netfilter.


P.S. Всё меньше и меньше мне нравится Mikrotik. Своей замшелостью и запутанностью интерфейса, неявными проблемами. Не могу пока настроить его в качестве openvpn-клиента к vps-серверу, так, чтобы и клиенты роутера получали доступ к настоящей сети Интернет. IPv4 режим работает, а IPv6 где-то засада.


P.P.S. Раньше я как-то обходился без сторонних собственных серверов, но теперь жизнь заставляет, поэтому просьба о финансовой поддержке добавлена справа вверху. Я конечно не ожидаю сюрпризов, но рубль к рублику - сервер будет жить.

※※※

※

OpenVPN certificates. Подготовка ключей и сертификатов туннеля для Ubuntu 16.04.3 LTS

В учебных целях исследования openvpn сервиса был запущен выделенный сервер у хостинг-провайдера. Был установлен сервис OpenVPN для исследования возможностей туннелей.

Место хранения сертификатов и ключей на виртуальном сервере

Нужно определить где на виртуальном частном сервере будут хранится
ключи.
Здесь существует дыра в безопасности, т.к. поставщик
виртуального частного сервера может иметь доступ к приватному, закрытому ключу сервера.
Поставщик всегда имеет доступ уровня root. Это часто прямо написано в
пользовательском соглашении. Там же написано и об юридической ответственности пользователя за всё.

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

Пусть авторитетные сертификаты будут лежать в папке /etc/openvpn/authorities
Пусть приватный и публичный ключ (сертификат) сервера будут лежать в папке /etc/openvpn/keys

mkdir /etc/openvpn/authorities
mkdir /etc/openvpn/keys
В принципе, виртуальный частный сервер надо условно считать частным.

Старая максима - "что знают двое, знает и свинья". В свете этой мудрости,
когда для преобразования сообщения используется два ключа... Мда...

Очень интересно, где та свинья, которая знает.

Т.е. для частного обмена информацией, даже со "своим" сервером, требуется ограничение физического доступа третьих лиц к серверу.
Если этого нет, то это не частный обмен, а общественный.

※※※

Частный удостоверяющий центр Certificate Authority (CA)

Минимально, частный удостоверяющий центр сводится к двум файлам - частному (секретному) ключу и общественному (открытому) самоподписанному сертификату частного удостоверяющего центра.

Местом хранения данных частного удостоверяющего центра (CA) можно выбрать usb-накопитель и хранить его в труднодоступном месте, после использования.

Генерация ключа и самоподписанного сертификата (genrsa) собственного удостоверяющего центра, на 10 дней (под root-пользователем):

openssl genrsa -out authority.key 4096
openssl req -x509 -new -key authority.key -days 10 -out authority.crt

Для шифрования (шифром -idea) частного ключа собственного удостоверяющего центра и неинтерактивной генерации:
openssl genrsa -idea -out authority.key 4096
openssl req -x509 -new -key authority.key -days 10 -out authority.crt -subj '/C=RU/ST=SPBFC/L=SPB/CN=Private Authority'

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

Для большей анонимности можно опустить заполнение полей опции -subj. Кто выпустил, зачем выпустил?
Не надо упрощать работу читателю сертификатов. Цифры. Только цифры и ничего более.
Каждый день отсрочки - ценен.

Генерация SSL-ключей сервера и клиентов

Для подписи публичных ключей openvpn-сервера и openvpn-клиента,
надо сформировать 2 запроса на подпись (CSR).
Один с использованием частного ключа сервера, второй с использованием частного ключа клиента.
В примере 3 запроса.

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

Генерация незашифрованных закрытых ключей (genrsa) сервера и клиентов:

openssl genrsa -out testserver.key 2048
openssl genrsa -out client1.key 2048
openssl genrsa -out client2.key 2048

или
Генерация шифрованных (-des -des3 -idea) закрытых ключей (genrsa) сервера и клиентов:
openssl genrsa -idea -out testserver.key 2048
openssl genrsa -idea -out client1.key 2048
openssl genrsa -idea -out client2.key 2048


Генерация запросов на подпись (CSR) для сервера и клиентов (команда req):
Дабы избежать интерактивности при генерации используется опция -subj
Одновременно, в файлы сертификатов сохраняются и открытые ключи. Каждая команда одной строкой:

openssl req -new -key testserver.key -out testserver.csr -subj '/C=RU/ST=SPBFC/L=SPB/CN=mytestserver.ru/emailAddress=admin@mytestserver.ru'

openssl req -new -key client1.key -out client1.csr -subj '/C=RU/ST=SPBFC/L=SPB/CN=test.client1.ru'

openssl req -new -key client2.key -out client2.csr -subj '/C=RU/ST=SPBFC/L=SPB/CN=test.client2.ru'

mytestserver.ru - это доменное имя, тут нужно указать то, которое привязано к серверу.

Подписываение запросов на подпись (CSR) и создание подписанных сертификатов (команда x509), на их основе, выполняется в частном удостоверяющем центре - в выделенной папке usb-накопителя, желательно отдельного компьютера. Для пущей безопасности можно выбрать специальное аппаратное устройство хранения ключей и сертификатов. Также можно использовать TPM-модуль в компьютере. 

openssl x509 -req -in testserver.csr -CA authority.crt -CAkey authority.key -CAcreateserial -out testserver.crt -days 10

openssl x509 -req -in client1.csr -CA authority.crt -CAkey authority.key -CAcreateserial -out client1.crt -days 10

openssl x509 -req -in client2.csr -CA authority.crt -CAkey authority.key -CAcreateserial -out client2.crt -days 10

Дополнительный секретный ключ TLS и настройка для OpenVPN

Сгенерировать специальные параметры алгоритма:

openssl dhparam -out dh2048.pem 2048

Сгенерировать специальный общий закрытый ключ (pre-shared key) для TLS надо на сервере.

root@testserver# openvpn --genkey --secret psk.key

Загрузить его потом на клиентов и на сервер - но источником этого ключа должен быть сервер.

Распространение ключей OpenVPN

Итак, после всего этого нам нужны файлы, которые мы раскладываем по папкам:

В папку удостоверяющего центра на флешке и храним в сейфе:
authority.key
authority.crt

В папки на сервере /etc/openvpn/authorities:
authority.crt

В папки на сервере /etc/openvpn/keys
testserver.key
testserver.crt
dh2048.pem
psk.key

В папку на клиенте №1:

authority.crt
testserver.crt
client1.key
client1.crt
psk.key
 
В папку на клиенте №2:

authority.crt
testserver.crt
client2.crt
client2.key
psk.key
 
Также в папке частного удостоверяющего центра (CA) можно завести журнал, в виде текстового файла, в который записывать что и когда было сделано.  Это поможет освежить историю, спустя 10 лет.

※※※

Фишки для удобства OpenVPN

Генерирование и вывод в один файл частного и общественного ключей, без шифрования:
openssl req \
-x509 -nodes -days 10 -sha256 \
-newkey rsa:2048 -keyout test.pem -out test.pem

Упаковка частного ключа и сертификата сервера, а также сертификата удостоверяющего частного центра в контейнер формата pkcs12:

openssl pkcs12 -aes256 -export -in  testserver.crt -inkey testserver.key -certfile authority.crt -name "PKCS12" -out testserver.p12
При этом, опция в настройках OpenVPN указывает на один файл-контейнер pkcs12.
pkcs12 /etc/openvpn/keys/testserver.p12

Удобно, вместо 3 файлов оперировать одним.


Копирование файла на сервер по протоколу scp:

scp -2  authority.crt root@XX.XXX.X.XXX:/etc/openvpn/authorities/authority.crt
scp -2 testserver.key root@XX.XXX.X.XXX:/etc/openvpn/keys/testserver.key
scp -2 testserver.crt root@XX.XXX.X.XXX:/etc/openvpn/keys/testserver.crt

Копирование файла с сервера на клиент по scp:

scp -2 root@XX.XXX.X.XXX:/etc/openvpn/keys/psk.key .

- точка в конце - это текущий каталог где лежат клиентские все ключи

※※※

Простейшая тестовая настройка на стороне сервера OpenVPN

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

Приведённая настройка не даёт доступа к интернету, т.к. надо настроить маршруты и пр. Отваливается по таймауту. Нет IPv6.

Это позже.

Содержимое файла: /etc/openvpn/home.conf

Его надо сформировать в редакторе nano.

# OpenVPN server KVM1
# Open Virtual Private Network server configuration
# server: kvm1
# date: april 28, 2018

port 1194
proto udp
dev tun

# Certificate Authority (CA) - public key
ca /etc/openvpn/authorities/authority.crt
# Certificate - public key of the server, signed with CA private key via request
cert /etc/openvpn/keys/testserver.crt
# Private key (key) - secret data, private key of server
key /etc/openvpn/keys/testserver.key

# Diffie Hellman parameters
# openssl dhparam -out dh2048.pem 2048

dh /etc/openvpn/keys/dh2048.pem

topology subnet
server 192.168.6.0 255.255.255.0

Или кратко, без комментариев:

port 1194
proto udp
dev tun
ca /etc/openvpn/authorities/authority.crt
cert /etc/openvpn/keys/testserver.crt
key /etc/openvpn/keys/testserver.key
dh /etc/openvpn/keys/dh2048.pem
topology subnet
server 192.168.6.0 255.255.255.0

Для проверки запуска сервиса OpenVPN надо зайти по SSH на сервер

и запустить сервис OpenVPN:

openvpn --config  /etc/openvpn/home.conf

При этом на клиенте надо установить BC-CBC, SHA1, в настройках графического клиента, т.к. это включено на сервере по-умолчанию.

※※※

Ресурсы

1. https://community.openvpn.net/openvpn/wiki

※※※

※

Свежий OpenVPN на Ubuntu 16.04 LTS Xenial

Для поднятия тестового VPN сервера для интрасети, нужно приобрести VPS-сервер KVM у поставщика, а затем установить свежую версию OpenVPN из официального репозитория OpenVPN.
Это даст возможность, при обнаружении некоторых проблем безопасности с openvpn, получить обновления openvpn-сервера от производителя.

Подключение сторонних репозиториев стандартно (под учётной записью root):
1. Получение подписи репозитория и внесение его в apt.
wget -O - https://swupdate.openvpn.net/repos/repo-public.gpg|apt-key add -
2. Сформировать указание для пакетного менеджера apt на репозиторий openvpn
echo "deb http://build.openvpn.net/debian/openvpn/release/2.4 xenial main" > /etc/apt/sources.list.d/openvpn-aptrepo.list

Теперь надо обновить список пакетов и установить OpenVPN 2.4:
3.Обновляем список пакетов
apt-get update
4. Установить пакет openvpn
apt-get install openvpn

Там может встретиться проблема с подписью, но у меня не встретилась, а если встретилась, то смотреть по ссылке [1].


Конфигурационный файл OpenVPN: /etc/openvpn/server.conf
Специфическое конфигурирование OpenVPN, позже.

※※※

Ресурсы

1. https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos

 ※※※

 ※

The People’s Communication Charter note. О непредоставлении доступа в сеть Интернет

Мне не предоставляют доступ в сеть Интернет, а именно, не выделяют корректный IP-адрес из диапазона IPv4.
Мне не предоставляют доступ в сеть Интернет, а именно, не выделяют корректный IP-адрес из диапазона IPv6.

Мне предоставляют доступ в некую телекоммуникационную сеть, построенную по образцу ip-сети.
Мне выделяют каждый раз разный ip-адрес.

И это уже давно.
Из-за этого всё трудности с Linux и с прогрессом в области телекоммуникаций на территории г. Санкт-Петербурга.

Итого, полное нарушение права человека на свободу ассоциаций и союзов.

Ну а про цифровые права, расширяющие обычные права человека, можно глянуть и осознать в The People’s Communication Charter.

Ресурсы:

http://www.waag.org/pcc

RIPE database query

Существует такой ресурс в ipv4-сети, как RIPE database. RIPE https://www.ripe.net/ - сетевой координационный центр (RIPE NCC). Эта организация наблюдает за куском сети Интернет куда входит Европа и пока ещё другая территория.
Полезность её в том, что это база данных, во-первых, - актуальная база-данных, во-вторых,  - уникальная актуальная база данных ip-сетей, в-третьих, а других таких нету в открытом доступе, в-четвёртых.

Как база данных RIPE по сетям может быть полезна простым гражданам, страдающим от постоянных проблем с интернет-связью?

Итак, допустим есть web-ресурс, пользователи которого, постоянно мешают нормальному функционированию сервера.
Нужно сделать так, чтобы не мешали. Одно из решений - ограничить доступ к собственному серверу, со стороны некоторой подсети.
Порядок:
1. Определяем ip-адрес, web-ресурса. Для этого используем встроенную в Linux команду nslookup.
nslookup domain
где domain - доменное имя веб-ресурса.
В качестве ответа получим один или несколько ip-адресов.

2. Идём на сайт RIPE в раздел запросов к базе данных RIPE. https://apps.db.ripe.net/db-web-ui/#/query
и ищём по ip-адресам из первого пункта.

3. Анализируем ответы базы данных RIPE. Потерпевших пользователей интересует строки inetnum, netname, descr.
inetnum - это диапазон ip-адресов, выданных посети netname, с человеческим описанием descr.

4. Идём в интерфейс нашего сервера, роутера и чего-ещё-там-есть у обычного пользователя и вносим полученную подсеть (диапазон ip-адресов) в ip-фильтр входящих соединений. Устанавливаем правило отбрасывать все соединения исходящие из этой вредной подсети.

Полезность этой процедуры, пока недооценена массами системных администраторов, но при должном подходе может быть эффект.

5. Сейчас, в конце апреля 2018 года, такая простая процедура, может помочь очень многим пользователям частных серверов.