Архив рубрики: Networks

Не запускается RRAS на Windows Server 2019

Networks, RRAS, Windows, ,

При настройке VPN-сервера на Windows Server 2019, после установки ролей Routing and Remote Access и NPS и после завершения первоначальной конфигурации роли, практически всегда возникает ошибка при старте службы RRAS. Ошибка выглядит как:

The Routing and Remote Access service terminated with the following service-specific error: 
The callback function must be invoked inline.

И в общем случае вообще ни о чем нам не говорит. При этом, если не устанавливать NPS — всё работает отлично. После долгих изысканий выяснилось, что ошибка возникает только в том случае, если сначала стартует NPS, а после него RRAS. При этом, RRAS в любом случае запускает NPS как зависимость. Очевидное решение — перевести службу NPS из автоматического старта в ручной. После этого проблема больше не воспроизводится.

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

Networks, VPN,

После настройки 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.

Networks, VPN, ,

В разных странах в разное время возникают проблемы с интернетом, которые официально объясняются 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

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

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

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

Group Policy, Networks, registry, Windows,

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

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

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

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

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

Route-based IPSEC VPN между Ubuntu 18.04 (libreswan) и Cisco Router. Часть 2

Cisco, IPSEC, libreswan, Networks, UNIX, , , ,

В этой статье (часть первую можно прочитать здесь) я опишу процесс настройки Cisco роутера на примере Cisco ISR 4331 для целей создания нашего VPN-соединения. Как мы помним, конечная цель настройки — отправлять интересующий нас трафик через VPN-туннель.

Для примера, я опишу настройку Cisco для отправки всего трафика к определенным серверам через туннель (например, для обхода блокировок по стране). Начнем с создания object-group — так в дальнейшем будет проще добавлять новые адреса назначения и сразу добавим туда адрес сервера, к которому надо ходить через туннель:

object-group network TOVPN
 host 3.3.3.3

Далее создаем ip access-list, которым мы будем ловить интересующий нас трафик:

ip access-list extended TOVPN
 permit ip any object-group TOVPN

Переходим к непосредственной настройке VPN:

crypto keyring VPN
 pre-shared-key address 11.11.11.11 key %908A2R5vX9O694aoxh1

crypto isakmp profile VPN
 keyring VPN
 match identity address 11.11.11.11 255.255.255.255

crypto ipsec transform-set ESP-AES256-SHA1 esp-aes 256 esp-sha-hmac
 mode tunnel

crypto ipsec profile VPN
 set transform-set ESP-AES256-SHA1

crypto isakmp policy 10
 encr aes 256
 authentication pre-share
 group 5

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

Далее необходимо создать виртуальный интерфейс, через который мы будем делать туннель.

interface Tunnel0
 ip address 172.16.0.21 255.255.255.252
 tunnel source 22.22.22.22
 tunnel mode ipsec ipv4
 tunnel destination 11.11.11.11
 tunnel protection ipsec profile VPN
 ip tcp adjust-mss 1300

Для корректной передачи данных по туннелю, чтобы в стандартный MTU пролазил пакет с «оберткой IPSEC» — нам необходимо ограничить размер MTU на интерфейсе. Делается это командой ip tcp adjust-mss MTU. В данном примере установлен MTU — 1300. Число 1300 не подбиралось экспериментальным путем, а было установлено таким, чтобы точно подходило в любых конфигурациях. На самом деле, вам, скорее всего, достаточно будет указать 1376. Если этого не сделать — обратный трафик будет проходить «частично». Если быть более точным — другой конец нашего туннеля при получении «ответных» пакетов (на наш трафик через туннель) «нормального» размера (т.е. 1476 байт) не сможет отправить их через туннель из-за превышения размера MTU. При этом мелкие пакеты будут бегать туда-сюда без особых проблем. Например, пинг и трэйсроут будут показывать наличие связи, а странички из интернета грузиться не будут.

Итак, туннель поднят, осталось отправить в него трафик. Для этого задействуем route-map:

route-map LOCAL permit 10
 match ip address TOVPN
 set interface Tunnel0

Не забываем применить этот route map к интерфейсу, к которому подключена локальная сеть.

Если все сделано по инструкции, но туннель не поднялся, проверяем:
— разрешен ли доступ снаружи к маршрутизатору по протоколам udp и gre;
— разрешен ли маршрутизатору доступ в сеть по протоколам udp и gre;

Если туннель поднялся, но трафик в него не ходит (или обратно не приходит):
— пробуем сделать ipsec restart на сервере с ubuntu;
— проверяем правила доступа с интерфейса Tunnel0 и на него (выбрана ли правильная зона для ZBFW при его использовании).