Openvpn\Tunnelblick hide `unrecognized option` window

Давненько ничего не приходилось записать, но вот...

На текущем рабочем месте доступ к ряду ресурсов организован через OpenVPN. Помимо прочих опций сервер выдает настройки DNS сервера, однако используются эти опции исключительно в win-среде, а мой macos-ный Tunnelblick на них ругается как на `unrecognized`:

Линуксовый openvpn-клиент сругнется ровно также:

2019-02-06 22:16:04 Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:1: block-outside-dns (2.4.6)

2019-02-06 22:16:04 Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:3: register-dns (2.4.6)

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

Однако решение есть! В документации находим следующее:

--pull-filter accept|ignore|reject text

Filter options received from the server if the option starts with text. Runs on client. The action flag accept allows the option, ignore removes it and reject flags an error and triggers a SIGUSR1 restart. The filters may be specified multiple times, and each filter is applied in the order it is specified. The filtering of each option stops as soon as a match is found. Unmatched options are accepted by default.
Prefix comparison is used to match text against the received option so that
--pull-filter ignore "route"would remove all pushed options starting with route which would include, for example, route-gateway. Enclose text in quotes to embed spaces.
--pull-filter accept "route 192.168.1."--pull-filter ignore "route "would remove all routes that do not start with 192.168.1.
This option may be used only on clients. Note that reject may result in a repeated cycle of failure and reconnect, unless multiple remotes are specified and connection to the next remote succeeds. To silently ignore an option pushed by the server, use ignore.

 Добавив в конфигурационный файл нужные строки:

pull-filter ignore redister-dns

pull-filter ignore block-outside-dns

Получаем тишь и благодать:

2019-02-06 22:38:37 Pushed option removed by filter: 'block-outside-dns'
2019-02-06 22:38:37 Pushed option removed by filter: 'register-dns'

 

ocserv DTLS error

Попался на глаза довольно интересный на первый взгляд продукт - Openconnect VPN Server, который реализует SSL VPN (по образу и подобию решения от Cisco и совместимый с их клиентом AnyConnect). Для Debian он доступен в репозитории (на момент написания - в testing). Если дистрибутив на нестабильный обновлять нет желания или возможности, можно подключить testing только для установки ocserv:

root@vpn:~# cat /etc/apt/preferences.d/testing
Package: *
Pin: release a=testing
Pin-Priority: 50

Соответственно, установка будет выглядеть как

root@vpn:~# apt-get install -t testing ocserv

Базовая конфигурация довольно подробно описана в документации (есть и примеры, и сам конфиг-файл хорошо самодокументирован).

Я же хотел отметить следующее...

Собранный для Debian пакет ocserv идет с предустановленными unit-файлами для systemd, который в стабильном jessie теперь есть из коробки. И возникла вот какая проблема: при запуске через systemd сервер запускается и работает корректно, без ошибок, однако после установления соединения от клиента (находящегося в этой же подсети, с отключенными фаерволами), в логах при любом обмене данными появляются сообщения

bind UDP to [::]:443: Invalid argument
connect UDP socket from [::ffff:128.128.128.128]:62862: Network is unreachable

Со стороны клиента это выглядит как сообщение о невозможности установить DTLS соединение. Сам туннель работает, трафик ходит, однако, выходит, udp-метаданные или работают вовсе, или не защищены.

Исследования выявили, что при запуске без участия systemd, например

root@vpn:~# ocserv  -f -d 10 --config /etc/ocserv/ocserv.conf

Соединение устанавливается и ошибок с DTLS нет. Также было замечено, что в случае запуска через systemd сам ocserv не слушает 443 порт, а этим вместо него занимается systemd.

Оказалось, что (это мои предположения, которые могут быть далеки от истины) systemd запускает сокет, через который уже запускается и работает сам процесс worker от ocserv. То есть у нас есть ocserv.socket и ocserv.service, связанные друг с другом. При ручном запуске этого не происходит (хотя сам сокет, как и описано в конфиге, создается и, полагаю, используется), а netstat -nlp показывает слушаемый порт:

root@vpn:~# netstat -nlp | grep ocserv
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      547/ocserv-main
udp        0      0 0.0.0.0:443             0.0.0.0:*                           547/ocserv-main
unix  2      [ ACC ]     STREAM     LISTENING     14164    547/ocserv-main     /var/run/occtl.socket
unix  2      [ ACC ]     STREAM     LISTENING     14174    822/ocserv-sm       /var/run/ocserv-socket.547

Таким образом, проблема локализуется где-то во взаимодействии systemd и ocserv.service через ocserv.socket

Текущая версия пакета:

root@vpn:~# apt-cache policy ocservocserv:Установлен: 0.11.4-1+b1Кандидат: 0.11.4-1+b1Таблица версий:*** 0.11.4-1+b1 0500 http://mirror.yandex.ru/debian/ testing/main amd64 Packages100 /var/lib/dpkg/status

Предлагаемый workaround:

Отключаем запуск сокета через systemd вовсе:

root@vpn:~# systemctl mask ocserv.socket

Комментируем зависимость службы от юнита сокета:

root@vpn:~# cp /lib/systemd/system/ocserv.service /etc/systemd/system/ocserv.service
root@vpn:~# sed -i s/Also=ocserv.socket/#Also=ocserv.socket/ /etc/systemd/system/ocserv.service
root@vpn:~# systemctl daemon-reload

Наблюдаем после перезапуска:

root@vpn:~# journalctl -n -u ocserv.service | grep 443
окт 06 11:24:13 vpn ocserv[547]: listening (TCP) on 0.0.0.0:443...
окт 06 11:24:13 vpn ocserv[547]: listening (UDP) on 0.0.0.0:443...

После этого в моем случае проблема перестала воспроизводиться.

Передача статических маршрутов в pptp-туннеле

Думал я, что сабж при использовании pptp vpn невозможен. Оказалось, ошибался. Да, сам ppp-протокол не умеет передавать при соединении маршруты. Однако, при установлении соединения клиентом в туннель посылаются запросы DHCPINFORM, с помощью которых ему можно вернуть практически любой dhcp-option, включая информацию о маршрутах!

Для этого, во-первых, нам потребуется dhcp-сервер. В моем случае имеется уже работающая инфраструктура доступа к ресурсам локальной сети через pptp, поэтому pptpd и dnsmasq уже подняты и выполняют свои функции. В конфигурационный файл dnsmasq.conf добавился следующий блок:

##pptp-vpn
listen-address=192.168.30.1
dhcp-range=pptp,192.168.30.100,192.168.30.120,255.255.255.0,1h
dhcp-option=tag:pptp,vendor:MSFT,2,1i
dhcp-option=tag:pptp,6,192.168.30.1
dhcp-option=tag:pptp,249,192.168.11.0/24,192.168.30.1,192.168.13.0/24,192.168.30.1

где:

listen-address - локальный адрес серверного конца vpn-туннеля (localip в /etc/pptpd.conf)

dhcp-range=pptp,... - объявление нового диапазона с отдельным тегом, дабы не затрагивать настройки других dhcp-зон.

dhcp-option=tag:pptp,vendor:MSFT,2,1i - спецопция для MS dhcp-клиента, говорящая ему делать dhcp-lease при выключении

dhcp-option=tag:pptp,6,192.168.30.1 - указание DNS-сервера

dhcp-option=tag:pptp,249,... - спецопция для MS dhcp-клиента, передающая статические маршруты (если среди клиентов есть Linux\MacOS, следует добавить dhcp-option=121 с аналогичным содержанием)

Далее проверяем корректность внесенных изменений с помощью dnsmasq --test и если все хорошо, перезапускаем демона для применения настроек. DHCP готов к работе.

Чтобы до него долетели DHCPINFORM пакеты от клиентов, в /etc/ppp/pptpd-options добавляется (или раскомментируется) опция proxyarp. Никаких дополнительных настроек не требуется. После перезапуска pptpd можно проверять работоспособность.

В результате при поднятии vpn-туннеля в таблице маршрутизации клиента должны появиться дополнительные маршруты, а ifconfig покажет для соответствующего интерфейса отдельный dns-сервер. Примерно так:

IPv4 таблица маршрута
=========================================================
Активные маршруты:
Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
   <.....skip......>
  192.168.30.0     255.255.255.0     192.168.30.1  192.168.30.111     21
  192.168.30.111 255.255.255.255  On-link           192.168.30.111    276
  192.168.11.0     255.255.255.0      On-link           192.168.30.111     21
  192.168.11.255 255.255.255.255  On-link           192.168.30.111    276
  192.168.13.0     255.255.255.0      On-link           192.168.30.111     21
  192.168.13.255 255.255.255.255  On-link           192.168.30.111    276
<.....skip......>
=========================================================
Постоянные маршруты:

  Отсутствует

VPN inside OpenVZ

Возникла задача - установить vpn-подключение (openvpn, keriovpn, неважно) из openvz-контейнера (в нем запущен Debian Lenny). Облом случился в виде невозможности создать tun/tap устройство. Решается внесением следующих изменений в настройки контейнера (в примере его VeID 101):

vzctl set 101 --devices c:10:200:rw --save
vzctl set 101 --capability net_admin:on --save ##возможно только при выключенном контейнере

Несколько изменений вносится и в саму виртуальную ОС:

vzctl exec 101 mkdir -p /dev/net
vzctl exec 101 mknod /dev/net/tun c 10 200
vzctl exec 101 chmod 600 /dev/net/tun

Рецепт подсмотрен здесь.

PirateISP problem

Отвалился туннель в Швецию, который так недавно и непросто настраивался на этих страницах. Говорят, PirateISP зачем то поделил старые ключи. Заказал новые, жду..

Настройка openvpn-туннеля к PirateISP (Швеция)

Получил я приглашение от PirateISP на закрытое бета-тестирование их VPN-анонимайзера, который они замутили на OpenVPN. При настройке подключения возникли две проблемы, и об их решении мы сегодня поговорим. 

Во-первых, провайдером присылается сертификат, зашифрованный паролем, который вводился при регистрации. И, соответственно, опенвпн его при поднятии туннеля спрашивает. Неудобно, к тому же и пароль "кучерявый" у меня. Эта проблема решается простым добавлением в конфигурационный файл строчки  askpass /etc/openvpn/pass, где /etc/openvpn/pass есть файл, в котором, собственно, пароль и записан. 

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

inspire:/home/delayer# route -n | grep 0.0.0.0

0.0.0.0         0.0.0.0          0.0.0.0         UG    0      0        0 ppp200

При таком раскладе опенвпн (версия 2.1.3-2) не может отработать push-нутую сервером команду redirect-gateway, которая подменяет текущий маршрут по умолчанию новым, проходящим внутри туннеля, и задает дополнительный статический маршрут на удаленный vpn-сервер через старый маршрут по умолчанию, дабы туннель после смены дефгейтвея не отвалился сам по себе. При этом туннель все же поднимается, но трафик через него наотрез ходить отказывается.

Эту проблему удалось решить, подменяя перед запуском опенвпн-а маршрут по умолчанию через ppp-интерфейс маршрутом по умолчанию через шлюз, являющийся внешним ip-адресом означенного ppp-интерфейса. К сожалению, сделать это сразу (например, при начальной конфигурации интерфейсов при запуске ОС) не представляется возможным, ибо мой ISP дает мне хоть и "белый", но динамический IP-адрес. Поэтому приходится выкручиваться, определяя каждый раз выданный адрес снова и подставляя его в качестве маршрута.

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

cat /usr/local/bin/pisp.sh
#!/bin/bash

# Дано ;)
SUDO=/usr/bin/sudo
ROUTE=/sbin/route
OVPN_INIT=/etc/init.d/openvpn
EXP=/usr/bin/expect
PirateISP=pirateisp
FLUSH=/usr/bin/flush

# Получение внешнего IP
Rtel_IP=`/sbin/ifconfig ppp200 | grep "inet addr:" | awk {'print $2'} | sed "s/addr://"`

# Функция поднятия туннеля, включает в себя операции
# по изменению маршрутов по умолчанию
function up_tunnel {
    $SUDO $ROUTE del default dev ppp200
    $SUDO $ROUTE add default gw $Rtel_IP
    $SUDO $OVPN_INIT start $PirateISP
}

# Обратная предыдущей функция опускания туннеля
function down_tunnel {
    $SUDO $OVPN_INIT stop $PirateISP
    $SUDO $ROUTE del default gw $Rtel_IP
        $SUDO $ROUTE add default dev ppp200
}
# Выбор действия
case "$@" in
# Старт туннеля и запуск торрент-клиента
# (ради чего всё и писалось =) )
    flush)
        up_tunnel
        sleep 5
        $FLUSH
    ;;
# Поднятие туннеля
    start)
        up_tunnel
    ;;
# Отключение соединения
    stop)
        down_tunnel
    ;;
# Справка
    *)
          echo "Usage: $0 {start|stop|flush}" >&2
          exit 1
      ;;
esac

Теперь, набрав pisp.sh start, я через несколько секунд получаю openvpn-туннель с белым адресом, который Яндекс определяет как стокгольмский. Ввиду закрытости бета-теста народу немного, поэтому скорости отличные (по сравнению с тем же IPredator'ом, где, по слухам, больше 200kbps не дождешься). Такая скорость, по мнению Яндекса, у меня напрямую (IP: 94.181.193.48):

Я.Интернет. Измерьте вашу скорость.

А такая - через PirateISP (IP: 194.14.172.146):
Я.Интернет. Измерьте вашу скорость.

Вот и сказочке конец, а кто слушал - молодец =).

Проблема с VPN (& FTP) из-за NAT

Столкнулся с неприятной проблемой - у меня в офисе инет раздается через проксю, а ssh и vpn - маскарадится напрямую (дабы не заморачиваться с настройками и пробросом портов). И если с шеллом проблем никаких нет, все как из ружья работает, то с vpn вышла оказия - соединение на заведомо рабочий vpn-сервер не проходит, зависая на проверке логина-пароля. Сам PoPToP в логах ругается на что-то там связанное с LCP-таймаутами. Короче, полный и бесповоротный реконнект. Гугление по сабжу и проглядывание манов показало следующее (углубляться в методологию и причинно-следственные связи решения не хочется да и при авральном решении вопроса не так и важно) - для правльиного маскарадинга VPN (а также, как выяснилось и FTP) обычной подмены заголовков пакетов недостаточно и требуется более глубокая их модификация. Сам модуль NAT-a этого сделать не может и поэтому для решения вставшей задачи (а у кого-то эта задача - активный FTP-коннект из-за маскарадинга) требуются следующие kenrel-модули: ip_nat_pptp и ip_nat_ftp соответственно. Подгрузив оные modprobe'ом, мы получаем щастие.
Для совсем экстаза пихаем их в автозагрузку, для чего в /etc/modules (в случае Debian Etch, в других ОС файлик с автозагружаемымми модулями может варьироваться) пишем построчно оба эти модуля в конце файла, не забывая EOF (то бишь пустую строку в конце).

VPN via kvpnc

Итак, простенький мануальчик по сабжу. Даже со скриншотами ;) Правда, немного с артефактами некоторые получились, ну да ладно, на информационную составляющую сии огрехи не влияют особо. Но, тем не менее приступим.
Для поднятия VPN-соединения в SuSE я рекомендую использовать kvpnc версии не ниже 0.8.6 (у меня на момент написания стоит 0.8.8). Взять софтинку можно практически в любом репозитории, а если лень, то есть и на инсталляционном dvd. Однако в таком случае нужно контролировать версию: в более старых есть бага, не позволяющая клиенту пройти MS-CHAP аутенфикацию на впн-сервере (ошибка unrecognized option: mppe-requied).

В нашем случае, считаем, что актуальная версия уже установлена и готова к работе:
(первый артефакт должен был быть курсором мыши с всплывающей посказкой функции кнопы Мастера) - ето думаю итак все догадались ;) Так вот, кликаем на волшебную палочку и запускаем Мастера установки соединения. В появившемся окне выбираем тип соединения - в моем случае сабжевым является vpn, так что берем Microsoft PPTP (а что поделать, такой сервер ;) большая часть клиентов - винда, так что на openVPN'e не разбежишься)

Далее предлагается указать некоторые параметры PPTP. В принципе, если у вас в локалке ничего специфического не понастроено (уточните у того кто настраивал что ли..), то добавлять или видоизменять ничего не требуется. В моем случае, как уже было сказано выше, сервер заточен под виндовых клиентов, так что требуется MS-CHAP аутенфикация, в линуксе реализованная в качестве модуля ядра MPPE (MPPC). Да, примечание... если у вас ядро ниже 2.6.13, то придется его или обновить, или пропатчить дабы сия опция там появилась. Патч я где то на просторах инета видел. Нужно наложить его на исходники ядра и пересобрать последнее с включенной модульно или константно option MPPE. все как обычно ;). Но лучше уж сразу поновее ядрышко иметь, так онои секурнее, и эстетичнее ;)

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

Тут я и сказать не знаю чего... одно поле выбора сетевого интерфейса... причем еси через локалку впн - то палюбому eth0... неинтересно (тока артефакт картинку чуток веселит). Топаем дальше.

А дальше у нас окно работы с роутингами. Тут в приципе на любителя, вернее, по обстоятельствам. В моей локалке прописанный в настройках маршрутизации default gateway в курсе, куда пулять мои пакеты как на запрос соединения, так и вообще в инет. ;) На то он и default $) Если у вас такого счастья нет, то ставим галку Use additional network routes, жмем Добавить маршрут (Add route) и в появившемся окошечке все вбиваем. Еси я все правильно понял, то етот маршрут создастся при подключении, и удалится при завершении работы программы. Да, как видно на скрине, в моем случае следует проставить опцию Replace default route. В иных ситуациях, возможно, правильным будет выбрать Keep default route. ( Скорее всего в тех случаях, когда сервер смотрит уже непосредственно в инет, а то у нас там куча всего за ним...traceroute классный выводится ;) )

Дальше нам предлагается включить\выключить проверку статуса соединения, указать ее временные интервалы, сказать, что удаленное пинговать для проверки степени живости коннекта и ресконнектить в случае отрицательного результата. В принципе, если соединение не мрет постоянно при отсутствии сетевой активности, то можно и отключить.

И последний штрих. Дженеральные, так сказать настройки. Помните капитана Врунгеля? "как вы судно назовете, так оно и поплывет"... воот! Так что придумываем имя и описание профиля не абы как, а с фантазией и вкусом. Вот только, прошу вас, отключить фантазерство напрочь при введении VPN gateway'я. Тут нужна счетверготоченность и полное осознание собственных действий. Неверный путь к впн шлюзу - и софтинка будет ломиться незнамо куда, и никакого инета вам не будет. Если не в курсе, спросите у уже упоминавшегося выше настройщика впн-шлюза вашего, или хотя бы у более прошаренных (читай, уже подключившихся) товарищей.

Вот и все. Дальше коннект! И если все было сделано правильно - вы в Сети. И можете с легкостью прочитать этот мануал ;)) Действительно, уже дописывая эти строки, опять вспомнились слова про то, что дрова от модема всегда оказываются в интернете. Но ведь надо же все-таки хотя бы пытаться сеять разумное-доброе-вечное на просторах Сети в общем, и на страницах моего блога в частности. Ищущий да обрящет. И для облегчения поиска и создания Коннекта и был накорябан сей пост. Хочется надеяться, что кому нибуть он поможет. Еще раз сорри за артефакты ;) и антрям.
Постскриптум: Добавочка выяснилась одна. Немаловажная как вышло. В общем, если в вашей сети VPN-шлюз и ваш хост находятся в пределах одной подсети, то дальше можно не читать. У меня к примеру, ситуация иная - я нахожусь в подсети 10.0.0.0/21, а мой впн-шлюз - в 10.1.0.0/19. Поэтому по умолчанию хост шлюз не видит, и соответственно, kvpnc будет стучаться неизвестно фкуда - а именно, выдавать ошибку о том что no route to host или что то в этом роде. Поэтому топаем в Yast - Сетевые службы - Маршрутизация, жмем Добавить - и добавляем маршрут в нужную подсеть (предварительно поставив тычку Настройки эксперта). Точные настройки будут у каждого свои, но у меня они выглядят так:
хЫ.... только сейчас заметил. Оболочки окон разные получились ;) Последний скрин - с Большого Брата (привет Emerald'у) Так что дополнительно оцените различия между оным и kwin. Но это ...уже совсем другая история, о ней - в следующий раз.