Правительственная связь на базе Asterisk!

    Вертушки

    image

    «Вертушка» — закрытая система партийной и правительственной телефонной связи в СССР.

    Первоначально была создана по указанию Владимира Ленина, как внутренняя АТС Кремля. Получила название «Вертушка», так как в отличие от обычной телефонной сети, где в то время соединение происходило через оператора, абоненты соединялись друг с другом с помощью АТС и дискового номеронабирателя («Вертушки»).

    Система интенсивно расширялась, а также была снабжена выходом на другие системы правительственной и военной связи, которые в народе также зачастую также назывались «Вертушка», а официально:

    АТС-1 — наиболее престижная система связи для абонентов высшей категории — первые лица государства, министры.

    АТС-2 — более широкая сеть городской правительственной связи.

    «Вертушка» была важным статусным символом советской эпохи. Регулярно модернизируемая система правительственных АТС продолжает действовать по настоящее время.

    «Вертушка» не предназначена для ведения секретных переговоров, однако увязана с другими правительственными системами защищенной связи долговременной криптостойкости, в том числе подвижной радиотелефонной («Кавказ») и другими.

    image

    1922 год Телефонный номер «Вертушки» Ф. Э. Дзержинского — 007.

    Asterisk + OpenVPN «Правительственная связь» нашего времени!

    Организовать передачу данных между офисами по защищенному каналу связи с использованием шифрования возможно с помощью OpenVPN.

    Кроме этого, при объединении филиалов в одно номерное пространство и подключение их к Asterisk часто возникают проблемы с настройкой NAT и прохождением голосового трафика без помех.

    Данные проблемы устраняется при объединении офисов с помощью OpenVPN.

    image

    В качестве абонентских устройств рекомендуется использовать IP-телефоны, например Yealink, поддерживающие работу с OpenVPN. Это идеальная схема, которая позволит настроить VPN-туннель и шифрование между офисами без использования дорогостоящих шлюзов с поддержкой VPN.

    Выгоды от использования OpenVPN

    Удобство подключения дополнительных офисов к Asterisk и отсутствие проблем с NAT.

    Работа по защищенным каналам связи. Весь трафик между офисами находится под «семью замками», а вернее под защитой библиотеки OpenSSL. Благодаря этому задействуется весь набор шифров, доступных в данной библиотеке. Также может использоваться пакетная авторизация HMAC, для обеспечения большей безопасности, и аппаратное ускорение для улучшения производительности шифрования.

    Установка OpenVPN

    1. Скачиваем дистрибутив OpenVPN по ссылке swupdate.openvpn.net/community/releases/openvpn-2.1.4.tar.gz:

    wget swupdate.openvpn.net/community/releases/openvpn-2.1.4.tar.gz

    и распаковываем архив:

    tar -xf openvpn-2.1.4.tar.gz

    2. Скачиваем обязательную библиотеку компрессии LZO, необходимую для сжатия потока данных по ссылкеwww.oberhumer.com/opensource/lzo/download/lzo-2.04.tar.gz:

    wget www.oberhumer.com/opensource/lzo/download/lzo-2.04.tar.gz

    и распаковываем архив:

    tar -xf openvpn-2.1.4.tar.gz

    3. Также необходимо установить библиотеку gcc.i386
    Устанавливаем её из репозитория:

    yum install gcc.i386

    Возможно данная библиотека уже может быть установлена, что можно проверить командой yum list |grep gcc.i386. Должно быть что-то вроде:

    gcc.i386 4.1.2-48.el5 installed
    libgcc.i386 4.1.2-48.el5 installed


    Если же данная библиотека не установлена и вы попытаетесь установить непосредственно OpenVPN, то при компиляции выйдет ошибка:

    configure: error: no acceptable C compiler found in $PATH

    4. Устанавливаем LZO из распакованного архива (см. п.2):

    cd .../lzo-2.04
    ./configure
    make
    make install

    5. Устанавливаем непосредственно сам OpenVPN из распакованной папки (см. п.1):

    cd .../openvpn-2.1.4
    ./configure
    make
    make install


    6. Создаём для удобства все необходимые папки для OpenVPN (при установке данные папки автоматически не создаются) и копируем туда необходимые файлы из распакованного архива (см. п.1):

    mkdir /etc/openvpn
    cp .../openvpn-2.1.4/easy-rsa/2.0/* /etc/openvpn
    mkdir /etc/openvpn/keys
    — создаём папку для сертификатов и ключей

    7. По желанию редактируем файл /etc/openvpn/vars в соответствии с необходимыми параметрами, чтобы каждый раз при генерации ключей не вводить снова одни и те же параметры.

    8. Экпортируем переменные из файла vars и выполняем удаление всех возможно уже существующих ключей:

    cd /etc/openvpn
    source ./vars
    ./clean-all


    9. Генерируем закрытый ключ и сертификат сервера сертификации (СA) или назовём по-другому — Удостоверяющего центра, на основе которого будут созданы все остальные ключи (ключ и сертификат для VPN-сервера и ключи и сертификаты для VPN-клиентов)(т.е. используется обычный механизм PKI — public key infrastructure).

    ./build-ca

    10. Генерируем закрытый ключ и сертификат для сервера:

    ./build-key-server name

    11. Генерируем закрытый ключ и сертификат для клиента:

    ./build-key client1

    12. Генерируем 1024-битный ключ по алгоритму Диффи-Хэллмана, который используется в механизме аутентификации ключей при установлении VPN-туннеля. Данный ключ остаётся на сервере.
    Алгори́тм Ди́ффи — Хе́ллмана (англ. Diffie-Hellman, DH) — алгоритм, позволяющий двум сторонам получить общий секретный ключ, используя незащищенный от прослушивания, но защищённый от подмены, канал связи.

    ./build-dh

    13. (Не обязательно) Генерируем симметричный TLS-ключ для предварительной защиты канала, еще до установленимя VPN-туннеля. Данный ключ является симметричным и должен находится как на сервере, так и на клиенте. Генерируем в папке /etc/openvpn/keys/

    openvpn --genkey --secret ./ta.key

    — Все созданные ключи, сертификаты и запросы серверной части помещаем в папку /etc/openvpn/keys для удобства (в случае если они были сгенерированы в другом месте). Клиентские ключи и сертификаты передаются соответственно защищенным способом на клиентские машины. При этом для каждого сертификата существует свой закрытый ключ и файл запроса на сертификат:

    *.key — закрытый ключ;
    *.csr — запрос на сертификат;
    *.crt — сертификат;


    В идеале клиентские закрытые ключи не должны генерироваться на сервере и затем передаваться клиенту, а должны генерироваться на самом клиенте при помощи какого-либо установленного криптопровайдера (в качестве хранилища закрытого ключа используется например реестр, smart-карта или flash-накопитель). Затем создаётся файл запроса сертификата созданный на основе сгенерированного закрытого ключа, который уже отправляется по сети на сервер сертификации (Удостоверяющий центр), где в ответ по сети передаётся сгенерированный сертификат. (т.к. файл запроса сертификата и сам сертификат шифрования сами по себе не составляют ценности без закрытого ключа, то их можно передавать по незащищённым каналам связи).

    14. Копируем пример файла конфигурации VPN-сервера server.conf из разархивированной папки (см п.1) в боевую папку /etc/openvpn

    cp ...../openvpn-2.1.4/sample-config-files/server.conf /etc/openvpn/server.conf

    и редактируем необходимые параметры:

    vi /etc/openvpn/server.conf

    15. Копируем примеры скриптов для запуска и остановки OpenVPN из разархивированной папки (см п.1) в боевую папку /etc/openvpn и правим их в соответствии со своими предпочтениями:

    cp ...../openvpn-2.1.4/sample-config-files/openvpn-startup.sh /etc/openvpn

    16. Запускаем OpenVPN-сервер:

    /etc/openvpn/openvpn-startup.sh

    и проверяем запустился ли сервис:

    netstat -luntp |grep openvp

    На этом этапе серверная часть закончена.

    Настройку на IP телефон Yealink рассмотрим в следующей статье.
    • +5
    • 11,2k
    • 6
    MyAsterisk
    29,00
    Компания
    Поделиться публикацией

    Похожие публикации

    Комментарии 6

      +4
      начало интересное, но таких HOW-TO про опенВПН в интернетах очень много (сами знаете).
        +2
        Да и «make install» не true-путь. Сколько уже писали об этом.
      0
      Я пытался использовать такую схему, но упёрся в нежелание Asteriskа работать с Telepathy через SIP из коробки. Было бы неплохо, если бы вы описали, как их подружить.
        +1
        Только клиентам такое не предлагайте.

        А то за использование несертифицированных криптографических средств защиты информации да еще без соответствующей лицензии на данный вид услуг, в лучшем случае попадаете под КоАП ст. 13.13 и КоАП ст.13.12.
        В худшем — под ст. 171 УК РФ.

        А позиционирование применения под «правительственное», влечет под собой «государственную тайну». Что усугубляет деяние.
          0
          Аудитория — бандиты и разведки

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое