Автоматический запуск openvpn и obfsproxy

После настройки openvpn и obfsproxy в предыдущей части, необходимо допилить всё до красивого состояния. А именно: автоматизировать запуск obfsproxy, openvpn и восстановление настроек iptables после поднятия соединения.

Итак, для автоматического запуска клиента openvpn и подключения к серверу нам необходимо:

  1. Скопировать конфигурационный файл openvpn в директорию /etc/openvpn и переименовать его в client.conf
  2. Раскомментировать строку AUTOSTART=»all» в файле /etc/default/openvpn
  3. Разрешить автозапуск сервиса:
sudo systemctl enable openvpn@client.service

После этих действий openvpn будет автоматически стартовать и пытаться установить подключение. Но для подключения ему необходим obfsproxy (весь трафик идет через него).

Настроим автозапуск obfsproxy:

1. Создадим конфигурационный файл для сервиса:

sudo nano /etc/systemd/system/obfsproxy.service

2. Поместим в него следующие строки:

[Unit]
Description=Obfsproxy Server

[Service]
ExecStart=/usr/bin/obfsproxy --log-min-severity=info obfs2 --shared-secret=<some-random-key> socks 127.0.0.1:10194

[Install]
WantedBy=multi-user.target

3. Выполним перезагрузку юнитов с диска:

sudo systemctl daemon-reload

4. Разрешим автозапуск сервиса и запустим его:

sudo systemctl start obfsproxy.service
sudo systemctl enable obfsproxy.service

Obfsproxy запущен, openvpn подключился. Осталось активировать NAT через iptables:

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

И, желательно, делать это автоматически. Для этого:

1. В конфигурационный файл openvpn добавляем:

script-security 2
up /etc/openvpn/up.sh

2. Создаем скрипт /etc/openvpn/up.sh с содержимым:

#!/bin/sh
/sbin/iptables-restore < /etc/iptables.rules

3. Сохраняем текущие настройки iptables при помощи:

iptables-save > /etc/iptables.rules

4. Не забываем сделать скрипт исполняемым.

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

Как обойти цензуру в интернете? Обфускация трафика obfsproxy + openvpn.

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

Один из способов — построение туннеля к тем серверам, которые доступны извне. Существуют различные виды туннелей, но сегодня мы будем настраивать openvpn с обфускацией через obfsproxy на базе ubuntu 18.04.

Итак, нам понадобится:
1. Сервер, который доступен по любому порту из места, где бывают проблемы с интернетом.
2. Openvpn клиент и obfsproxy на компьютере, с которого мы планируем выходить в интернет.

Установка серверной части

Установку OpenVPN-сервера, для краткости, описывать не буду. Описаний этого процесса в интернете достаточно, есть даже готовые скрипты. Например, https://git.io/vpn

После установки и базовой настройки openvpn, устанавливаем obfsproxy:

apt install obfsproxy

Его настройка и использование достаточно просты. Все необходимые параметры перечисляются прямо в строке запуска. Выглядит это как-то так:

obfsproxy --log-min-severity=info obfs2 --dest=127.0.0.1:1194 --shared-secret=<some-random-key> server 0.0.0.0:8080

В примере выше подразумевается, что openvpn слушает порт 1194 на адресе 0.0.0.0, либо, как минимум, 127.0.0.1. Если вы прописали в конфиге openvpn строго один айпишник — замените 127.0.0.1 на свой адрес. Сам obfsproxy будет слушать порт 8080, но вы можете повесить его на любой доступный вам порт (80, 443 или 22, если ssh вы перенесли на другой).

Для работы openvpn через obfsproxy необходимо, чтобы openvpn был настроен на работу по протоколу tcp. В противном случае вы получите ошибку:

[ERROR] Invalid SOCKS command: '3'

Кроме этого, в настройки сервера openvpn необходимо добавить следующие строки:

push "redirect-gateway local"
push "route xx.xx.xx.xx 255.255.255.255 yy.yy.yy.yy"

где xx.xx.xx.xx — внешний адрес вашего VPN-сервера, а yy.yy.yy.yy — адрес шлюза в сети клиента. После подключения клиента к VPN-серверу, будет автоматически добавляться маршрут к нему, а остальной трафик будет уходить через прокси. Если маршрут не добавлять, трафик по соединению не пойдет и оно само будет разрываться после таймаута.

Примерный конфиг сервера должен выглядеть так:

local 22.22.22.22
port 1194
proto tcp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt tc.key
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 8.8.8.8"
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
crl-verify crl.pem
push "redirect-gateway local"
push "route xx.xx.xx.xx 255.255.255.255 yy.yy.yy.yy"

Запускаем openvpn-server. Если вы устанавливали его при помощи скрипта по ссылке, то запуск будет выглядеть так:

systemctl start openvpn-server@server

Не забываем открыть необходимые порты снаружи. В этом примере нужен как минимум порт 8080.

Настройка клиента

Клиент будет выступать в роли шлюза, на который можно удобно завернуть весь трафик. Также, это все можно настроить у себя на компьютере под управлением Linux (в таком случае включать форвардинг пакетов и выполнять команду iptables не надо).

Устанавливаем openvpn и obfsproxy:

apt install openvpn obfsproxy

Запускаем obfsproxy с тем же shared secret, что и в серверном варианте:

obfsproxy --log-min-severity=info obfs2 --shared-secret=<some-random-key> socks 127.0.0.1:10194

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

socks-proxy-retry
socks-proxy 127.0.0.1 10194

Запускаем клиент командой:

openvpn --client --config /path/to/config/file

Если все настроено правильно, у вас появится интерфейс tun0 и весь трафик пойдет через него.

Включаем ip forwarding для того, чтобы наш клиент мог выступать в качестве шлюза для хостов в локальной сети:

sysctl -w net.ipv4.ip_forward=1

И раскомментируем строку в файле /etc/sysctl.conf:

net.ipv4.ip_forward = 1

И последнее — настройка iptables:

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

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

О том, как сделать так, чтобы все запускалось автоматически — в следующей части (ссылка на нее будет добавлена после публикации).

Outlook оставляет копии писем во входящих при перемещении правилами

После миграции с Exchange 2010 на Exchange 2016 всплыл один неприятный глюк: письма, которые автоматически сортируются правилами в аутлуке, начали оставаться в инбоксе. Более подробный анализ показал, что на самом деле они копируются в те директории, в которые они должны перемещаться по правилам.

Стоит заметить, что аутлук 2010 был настроен на хранение всей почты в локальном файле данных, а не на сервере. То есть вся почта хранилась в локальном PST-файле и автоматически удалялась с сервера.

Во всех правилах, которые перемещали письма по директориям, было установлено также действие «Stop processing more rules» (эта рекомендация также встречается при исправлении такой проблемы). Но это не помогало — часть писем исправно сыпались как в инбокс, так и в свою директорию.

После подробного анализа всех писем, которые попадали не по адресу и правил, их сортирующих, была замечена одна маленькая деталь: корректно отрабатывали те правила, в которых было добавлено условие «on this computer only». В итоге, ко всем правилам, которые отрабатывали некорректно, было применено дополнительное условие «on this computer only» и проблема исчезла.

APC PowerChute Business Edition не находит UPS

С недавних пор APC PowerChute Business Edition сам умеет отвечать на SNMP без дополнительных плясок с установкой «фичи» SNMP на сервер. Таким образом, его установка и настройка значительно упростилась. И, конечно же, появился дополнительный стимул мониторить при помощи Zabbix входное напряжение, статус батареи и другие параметры. Впрочем, иногда при установке этой софтины, она в упор не видит бесперебойник, подключенный к серверу по USB. При этом, сама система его прекрасно распознает и даже показывает уровень заряда (появляется иконка, как на ноутбуках).

Итак, одна из причин может заключаться в установке «неправильных» драйверов для бесперебойника системой. Необходимо зайти в device manager, найти Batteries и проверить как определился ваш бесперебойник. Если вы увидите HID UPS Battery или что-то похожее на это — с большой долей вероятности проблема именно в этом. Вам необходимо принудительно установить «правильные» драйвера, которые уже есть в системе. А именно — APC UPS. Для этого надо «обновить» драйвер, выбрав вручную из списка необходимый нам. На некоторых версиях ОС для этого придется снять галочку «Show compatible hardware» и согласиться с установкой.

После этого повторите автообнаружение бесперебойника в установщике — скорее всего он будет обнаружен.

Зависает подключение к удаленному рабочему столу (RDP) при подключении через VPN

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

При использовании RDP поверх VPN периодически могут возникать странные «зависания» удаленного рабочего стола, с последующими дисконнектами или без них или просто значительные подтормаживания интерфейса. Конечно, сначала необходимо исключить проблемы на сетевом уровне (потери пакетов, низкая скорость, высокие задержки и т.д.), но если они уже исключены, а проблемы повторяются — с большой долей вероятности ваш клиент работает по протоколу UDP. Этот режим работы стал режимом по умолчанию начиная с версии RDP 8.0. Сам по себе он призван ускорить работу с RDP, но в связке с VPN-подключением, когда пакеты начинают фрагментироваться перед отправкой в туннель и собираться заново на другом конце — могут возникать проблемы с одновременной доставкой всех «частей» пакета и невозможностью его сборки и, как следствие — задержки и зависания интерфейса.

Отключить работу через UDP можно двумя способами:

  1. Правка реестра. В ветке HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client необходимо создать параметр fClientDisableUDP и установить значение 1.
  2. Групповые политики. Необходимо перейти в Computer Configuration -> Administration Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Connection Client и установить настройку «Turn Off UDP On Client» в Enabled.

После этого зависания должны прекратиться.