Shadowsocks-туннелирование корпоративного VPN

Если у вашей компании имеются серверы, работающие за границей, и доступ для внутренних пользователей вы предоставляете посредством VPN-протоколов (достаточно типовая схема, особенно после Covid — 2019, когда удалённая работа стала особенно популярной), то настало время действовать на опережение. Конечно, применение административного ресурса, возможно, защитит ваши интересы от тотальных проблем в будущем, но лучше подстраховаться, чем в один прекрасный день получить 100500 сообщений от систем мониторинга о недоступности опекаемых клиентов. Статья демонстрирует, как скрыть от противодействия со стороны систем глубокого анализа трафика сервисы компании, доступ к бизнес-процессам которых обеспечивается посредством VPN, используя для этого туннели shadowsocks.

Текущий год сетевым инженерам и системным администраторам запомнится за майский и августовский перебои с сетями. Во втором случае были частично парализованы даже серверы, расположенные в отечественных дата-центрах (судя по всему, для персонала это тоже стало большой неожиданностью), и при этом не работал не только доступ посредством VPN. Получить информацию от технической поддержки, почему даже критически важный ssh-протокол отказывается отрабатывать до православного сервера, кроме отписок про нештатную ситуацию и мы уже работаем над этим, не вышло. В этом году на Хабре стали регулярно появляться статьи про частное применение протоколов shadowsocks, xray, dnstt и других для сохранения доступа к любимым сайтам в современных реалиях. Техническим специалистам уже стало абсолютно ясно, что случились первые звонки, и скоро весь этот DPI заработает по-настоящему. Новости пестрят ещё более серьёзными заявлениями о предстоящих блокировках. Ниже я покажу решение связанной, но другой задачи: применение туннеля shadowsocks для охранения работоспособности территориально распределённой локальной сети, построенной на базе OpenVPN. Если ваша локалка убегает далеко за пределы границ государства, то этот материал для вас.

В старые времена отечественному сетевому инженеру, работающему на предприятии, достаточно было строить локальные сети, которые со временем вышли за пределы офисов и расползлись между городами и странами. Наступило время VPN-протоколов и связанных с ними технических решений вроде pki. Очевидно, что в настоящее время мы вступили в период необходимости туннелирования распределённых локальных сетей. Сформулируем техническое задание. Существует корпоративная сеть, имеющая клиентов в зарубежном сегменте интернет. Подключение удалённых клиентов осуществляется по протоколу OpenVPN, порт сервера tcp/1200. Сеть должна сохранить работоспособность после воздействия на неё не контролируемого нами DPI.

В качестве эксперимента соберём практически нативный Linux-туннель между двумя серверами, работающими по обе стороны кордона, прямо поверх ssh-соединения. Без использования сторонних протоколов и программ:

# На одном из серверов сгенерируем пару RSA-ключей
ssh-keygen -t rsa -b 2048 -f ~/test
# Посмотрим содержимое открытого ключа
cat test.pub

ssh-rsa AAAAB3NzaC1yc…q4IVyz test@test_key

# На другом сервере сохраним его
echo 'ssh-rsa AAAAB3NzaC1yc…q4IVyz test@test_key' >> .ssh/authorized_keys
# Тестируем соединение
ssh -i ~/test test@test.ru
# Если всё нормально, запускаем туннель
ssh -i ~/test -D 3000  test@test.ru
# Проверяем состояние tcp сетевых соединений
netstat –tlnp

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:3000          0.0.0.0:*               LISTEN      139625/ssh

Туннель запущен, теперь завернём в него трафик VPN. Для этого дополним конфигурацию OpenVPN-клиента приведённой ниже строкой и перезапустим службу:

socks-proxy 127.0.0.1 3000

Трафик OpenVPN будет вложен внутрь ssh-соединения. Обращаемся к VPN-серверу и наблюдаем работоспособность соединения:

ping 192.168.16.1
PING 192.168.16.1 (192.168.16.1) 56(84) bytes of data.
64 bytes from 192.168.16.1: icmp_seq=1 ttl=64 time=1.90 ms

Разорвать ssh-туннель обычным exit не выйдет, поэтому при тестировании можно просто прибивать его:

# Смотрим PID нужного нам процесса
netstat -tlnp

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:3000          0.0.0.0:*               LISTEN      139625/ssh

# Прибиваем процесс
kill -9 139625

Можно убедиться, что никакие пинги до VPN-сервера больше не идут. Задача выполнена, но в прод такое выпускать не следует. Протокол ssh многофункциональный, вряд ли будет подвержен санкционному влиянию, так как глобально обеспечивает функционирование интернета. Однако это в первую очередь протокол удалённого управления, а из этого вытекают дополнительные эксплуатационные издержки. На текущий момент существуют уже проверенные временем туннельные протоколы, которые предназначены для обхода DPI. Тем более, с маскированием трафика они справляются гораздо лучше, так как разрабатывались изначально с этим требованием. Выбор пал на shadowsocks – открытый, надёжный, быстрый, обычно не детектируемый, простой в настройке и документированный. Устанавливаем необходимые пакеты на VPN-сервер, конфигурируем и запускаем службу:

apt install shadowsocks-libev
nano /etc/shadowsocks-libev/config.json

{
	"server": "0.0.0.0",
	"mode":"tcp_and_udp",
	"server_port":24,
	"password":" ahC....uzah",
	"timeout":300,
	"method":"chacha20-ietf-poly1305"
}

systemctl restart shadowsocks-libev
# Проверяем соединения на сервере
netstat –tlnp

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:24              0.0.0.0:*               LISTEN      14103/ss-server	

Размер ключа должен быть равен 32 символам, автоматически сгенерировать можно так:

apt install pwgen
pwgen 32 1

ahC....uzah

Сервер к работе готов, перемещаемся за кордон и настраиваем туннель на клиенте. Устанавливаем необходимые пакеты, выключаем серверную часть программы, конфигурируем и запускаем службу:

apt install shadowsocks-libev
systemctl stop shadowsocks-libev								
systemctl disable shadowsocks-libev		
nano /etc/shadowsocks-libev/test.ru.json

{
	"server": "ip адрес сервера",
	"mode":"tcp_and_udp",
	"server_port":24,
	"local_address": "127.0.0.1",
	"local_port":3000,
	"password":" ahC....uzah ",
	"timeout":300,
	"method":"chacha20-ietf-poly1305"
}

systemctl start shadowsocks-libev-local@test.ru.service
# Проверяем соединения на клиенте
netstat –tlnp

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:3000          0.0.0.0:*               LISTEN      118341/ss-local

Туннель сконфигурирован и запущен. Выполним тест работоспособности прокси. При первой проверке нам должен вернуться IP-адрес нашего VPN-сервера, при второй – действительный адрес сервера:

curl --proxy socks5://127.0.0.1:3000 https://ifconfig.me
curl https://ifconfig.me

Теперь можно перезапустить клиента VPN и так же убедиться в его работоспособности:

systemctl restart openvpn
tail /var/log/openvpn/user196.log –F

Из академического интереса запишем и взглянем на передаваемый трафик:

apt install tcpdump
tcpdump -w test.pcap

# Используемые фильтры в Wireshark
ip.addr == адрес vpn сервера && tcp.port == 1200
ip.addr == адрес vpn сервера && tcp.port == 24

На 1200 tcp пакетов ожидаемо не обнаружено. Зато на 24 tcp видим не похожий ни на что поток данных, это и есть работа протокола shadowsocks:


Техническое задание выполнено. Эксплуатируемая корпоративная сеть сохранит работоспособность даже в условиях противодействия со стороны систем глубокого анализа трафика. Если нет, и прокаченный грамотными специалистами DPI будет в автоматическом режиме находить и блокировать ни на что не похожий трафик, вроде нашего shadowsocks, тогда мигрируем в другие скрытые туннельные протоколы, и игра в кошки-мышки продолжится. Так как у нас работает полноценный vpn, то можно придумывать разные надстройки, маркируя трафик и маршрутизируя пакеты самым необычным для клиентов образом, например, выпуская их в интернет через закордонный шлюз. Но это уже другая история.

Telegram-канал с розыгрышами призов, новостями IT и постами о ретроиграх