OpenVPN Server PSK autostart

При загрузке OpenVPN сервер спрашивает  PSK, в случае если частный ключ был создан с защитой ключем. Как избежать вопроса без использования скриптов?

In my openvpn.conf:

...
askpass /etc/openvpn/jdoe.pass   <<< new line here
ca /etc/openvpn/jdoe_ca.crt
cert /etc/openvpn/jdoe.crt
key /etc/openvpn/jdoe.key
...

The file /etc/openvpn/jdoe.pass just contains the password. You can chmod this file to 600. This method save my life... ;-)

https://stackoverflow.com/questions/11240184/pass-private-key-password-to-openvpn-command-directly-in-ubuntu-10-10

https://community.openvpn.net/openvpn/wiki/EasyRSA3-OpenVPN-Howto

GRE внутри IPSec между Mikrotik и Cisco

Медленно, но верно корпоративный сектор отказывается от маршрутизаторов Cisco в пользу устройств Mikrotik. В данном случае было решено ставить микроты в качестве шлюзов для филиалов.
Изначально вся сеть была построена на Cisco. Центральный маршрутизатор - Cisco 2800 серии, который собирается на себе кучу IPSec туннелей, по какой-то причине сделанных без VTI.
Так вот, лет через 10-15 филиальные цыски начали дохнуть. Ставить вместо них аналогичную железку дорого. Было принято решения закупать микроты RB951G-2HdD. После первой интеграции микрота в эту сеть мне хотелось сделать заметку о том, как подружить по GRE over IPsec (рассуждения на тему что же все таки over что можно почитать тут - http://linkmeup.ru/blog/50.html) микрот и sysko, но как-то не было времени. И вот подвернулась задачка, о которой хочу написать.
Был один узел в сети, у которого белый адрес остался жить на ADSL модеме в силу того, что там использовалось PPPoA, а не PPPoE. Был сделан NAT таким образом, что UDP 500 пролетал на внешний серый адрес роутера филиала. На хабе включен режим NAT-T. Работало это на карте шифрования, пакующей только юникаст трафик с одной сети в другую. В качестве пиров указаны внешние адреса. Упоминания о том, что внешним адресом филиального роутера является серый адрес нигде в конфиге не было.

ASA. Резервирование IPSec туннелей, RA VPN.

Итак, с чего бы начать повествование… Пожалуй, начну с того, как все было раньше и как развивалось. Я пришел в компанию-интегратор около двух лет назад. До этого в течении пяти лет я трудился у операторов ШПД и мобилников. Там я занимался магистральной сетью. Здесь же пришлось перейти на другой уровень - сетей предприятия. Если операторские сети характеризуются большим трафиком и кучей маршрутов, то сети предприятий - это интеллектуальные услуги с небольшим трафиком. Везде своя специфики, разные устройства.

Любой интегратор - контора проектная, где прибыль приносят исключительно проекты. Когда специалист занимается настройкой или проектированием по какому-либо проекту, оплата его труда идет из бюджета этого проекта. В компании есть внешние проекты - проекты, которые приносят деньги, и есть внутренние - такие как “Поддержка внутренней сетевой инфраструктуры” и т.д. Внутренние тоже требуют затрат труда, но руководители проектов не любят тратить бюджет вутренний, да и специалисты не любят внутренние проекты из-за того, что по ним час труда стоит меньше (эдакая мотивация заниматься внешними коммерческими проектами). Из вышесказанного можно сделать вывод, что внутренняя структура ИТ находится на уровне “чтобы работало”, но с минимальными затратами.

Когда я пришел в фирму, внутренняя сеть представляла собой классический пример SOHO (даже не SMB). Единственное, что отличало  её от домашней сети - наличие нескольких VLAN (DMZ, WLAN, LAN). На периметре стояла одинокая ASA 5505 с единственным каналом в интернет. На этой железке был поднят сервис Remote Access VPN на Cisco Anyconnect с авторизацией через LDAP. Нужно заметить, что был реализован и доступ через Clientless SSL VPN со всеми его фичами такими как split-tunnel, java-приложения (rdp, vnc, telnet/ssh).

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

  На ASA я реализовал автоматическое переключение с использованием IP SLA и Track. Пингуем гугловский публичный днс через основной канал. Если пинги не проходят, убираем статический маршрут “по-умолчанию” с наибольшей метрикой (по срабатывани. track). Остается маршрут постоянный с большей метрикой. Резервирование интернета есть.

 Прошло некоторое время, и у фирмы появился офис в другом городе. Вся инфраструктуара находится, соответственно, в основном офисе. Появилась новая задача - подключить офис к существующим ресурсам с минимальными затратами. Так появилась ещё одно ASA и IPSec site-to-site туннель. И всё шло хорошо до первого падения основного канала. Туннель не резервируется. На ASA основного офиса нет возможности построить два туннеля через разные интерфейсы на один IP адрес т.к. маршрут наружу для удаленного хоста идет только через один интерфейс. В момент падения туннели приходилось переделывать руками.

 Так получилось, что у меня оказалась одна свободная ASA 5505. Я решил задействовать её, переместив на нее резервный канал в интернет. В виду минимальных расходов на собственную инфраструктуру в ядре нашей сети нет коммутатора L3, поэтому пока не реализовано резервирования “шлюза по-умолчанию”, в связи с чем я решил включить вторую ASA в первую (ASA не поддерживает ни один из FHRP). При начилчии коммутатора L3 в ядре резервирование “шлюза по-умолчанию” делается на динамическом протоколе маршрутизации.

 Начальная схема:

PPTP. network behind client.

Две площадки объединены туннелем. На одной стоит PPTP сервер на линуксе, на другой микротик, который цепляется к первому клиентским туннелем. За микротиком сетка 192.168.3.0/24. В линуксе нужно прописать маршрут. Делаем это динамически при подключении определенного пира. IP-адрес для пира постоянный. Итак, в файл /etc/ppp/ip-up дописываем:

#!/bin/sh
#
# This script is run by the pppd after the link is established.
# It uses run-parts to run scripts in /etc/ppp/ip-up.d, so to add routes,
# set IP address, run the mailq etc. you should create script(s) there.
#
# Be aware that other packages may include /etc/ppp/ip-up.d scripts (named
# after that package), so choose local script names with that in mind.
#
# This script is called with the following arguments:
#    Arg  Name                          Example
#    $1   Interface name                ppp0
#    $2   The tty                       ttyS1
#    $3   The link speed                38400
#    $4   Local IP number               12.34.56.78
#    $5   Peer  IP number               12.34.56.99
#    $6   Optional ``ipparam'' value    foo

# The  environment is cleared before executing this script
# so the path must be reset
PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin
export PATH

# These variables are for the use of the scripts run by run-parts
PPP_IFACE="$1"
PPP_TTY="$2"
PPP_SPEED="$3"
PPP_LOCAL="$4"
PPP_REMOTE="$5"
PPP_IPPARAM="$6"
export PPP_IFACE PPP_TTY PPP_SPEED PPP_LOCAL PPP_REMOTE PPP_IPPARAM

# as an additional convenience, $PPP_TTYNAME is set to the tty name,
# stripped of /dev/ (if present) for easier matching.
PPP_TTYNAME=`/usr/bin/basename "$2"`
export PPP_TTYNAME

case "$5" in
        172.26.100.42)
                /sbin/route add 192.168.3.161/32 gw 172.26.100.42
                ;;
        *)
esac

# If /var/log/ppp-ipupdown.log exists use it for logging.
if [ -e /var/log/ppp-ipupdown.log ]; then
  exec > /var/log/ppp-ipupdown.log 2>&1
  echo $0 $*
  echo
fi

# This script can be used to override the .d files supplied by other packages.
if [ -x /etc/ppp/ip-up.local ]; then
  exec /etc/ppp/ip-up.local "$*"
fi

run-parts /etc/ppp/ip-up.d \
  --arg="$1" --arg="$2" --arg="$3" --arg="$4" --arg="$5" --arg="$6"

# if pon was called with the "quick" argument, stop pppd
if [ -e /var/run/ppp-quick ]; then
  rm /var/run/ppp-quick
  wait
  kill $PPPD_PID
fi

Тут есть описание переменных, можно сделать это в отдельном файле ip-up.local. Да, чтобы одинаковые маршруты не плодились не забудьте прописать аналогичное в ip-down (route del).

Easy VPN Server and Remote hardware client

Готовлюсь к экзамену 642-637 SECURE. Все лабораторные работы проходили спокойно и по расписанию. Все понятно. Но тут дошло дело до Easy VPN. Название не предвещает ничего плохого, наоборот, говорит о том, что это «легко». Не тут то было. Настроить сервер через CLI в IOS для подключения программного клиента из Windows не составило большого труда, хотя конфигурация в количестве строчек выглядит внушительно. Проблемы начались, когда я подошел к конфигурации «сервер – аппаратный клиент». В рамках экзамена SECURE я рассматриваю соединение двух IOS устройств. Несмотря на то, что в офисе имеется два 2911, я решил реализовать схемы лабораторных работ в GNS.

Итак, изучив теорию, поняв, какие параметры IKE устраивают программные клиенты, какие подходят для аппаратных, я решил запустить простую схему сервер клиент. Уточню, что клиент находится в режиме «network-extension». Схема указана на рисунке ниже. В данном случае я столкнулся с проблемой, что клиент не помещает маршрут на приватную сеть сервера VPN в таблицу маршрутизации, хотя в split-tunnel она приезжает. Для того чтобы частная сеть клиента видела частную сеть сервера на маршрутизаторе клиента необходимо прописать статический маршрут на сеть сервера через внешний интерфейс. На этом интерфейсе уже есть карта шифрования, которая подхватит пакеты с нужным адресом назначения и завернет их в туннель.

Не буду приводить тут выводы дебагов, пингов и трасс. Это всё вам придется исследовать самостоятельно. Тут я положу схему сети и конфиги маршрутизаторов из GNS. Для этих экспериментов я использовал образ «c3745-adventerprisek9-mz.124-15.T14».

Cisco IOS SSL VPN Configuration Guide

http://yadhutony.blogspot.ru/2013/06/cisco-ios-ssl-vpn-configuration-guide.html

Практические советы по выбору и настройке Cisco VPN

http://youtu.be/J2OPdwsqKXs

Site-to-site туннель GRE через IPSEC на маршрутизаторе Cisco 2911R с использованием модуля шифрования NME-RVPN

Первая схема

Казалось бы, обыденная задача - объединить два офиса шифрованным каналом. Всего-то нужно построить site-to-site VPN и зашифровать с помощью crypto map. Все так и есть, если речь идет не о государственной структуре. Нельзя использовать вражеские шифровальные алгоритмы и железо. Именно под эту задачу были выбраны маршрутизаторы ISR второго поколения 2911R. Буква R в конце названия говорит о том, что данные рутеры были произведены на территории РФ. Для шифрования трафика будем использовать модули для этих рутеров - NME RVPN, выполненные в качестве карты расширения для ISR. Они несут на борту русский софт от компании S-Terra и, конечно же, «Крипто про». По сути, платы представляют собой отдельную машинку под управлением redhat linux с несколькими кастомными софтинами. Имеет один внешний порт помимо общей коммутационной шины, которой подключаются все подобные модули в ISR.