stunnel vpn трафик и убедитесь, что он выглядит как трафик SSL на порту 443
Я пытаюсь сделать так, чтобы мой исходящий и входящий трафик выглядели как можно ближе к трафику SSL. Есть ли способ добавить мой трафик в DPI, чтобы он выглядел как трафик SSL, а не трафик OpenVPN? И на основании моих настроек конфигурации весь трафик использует порт 443, который является портом SSL?
Моя конфигурация выглядит следующим образом:
STUNNEL на ноутбуке:
[openvpn]
# Set sTunnel to be in client mode (defaults to server)
client = yes
# Port to locally connect to
accept = 127.0.0.1:1194
# Remote server for sTunnel to connect to
connect = REMOTE_SERVER_IP:443
OPENVPN CONFIG ON ноутбук:
client
dev tun
proto tcp
remote 127.0.0.1 1194
resolv-retry infinite
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun
STUNNEL CONFIG ON SERVER:
sslVersion = all
options = NO_SSLv2
;chroot = /var/lib/stunnel4/
; PID is created inside the chroot jail
pid = /stunnel4.pid
; Debugging stuff (may useful for troubleshooting)
debug = 7
output = /var/log/stunnel4/stunnel4.log
setuid = root
setgid = root
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
compression = zlib
[openvpn]
accept = REMOTE_SERVER_IP:443
connect = REMOTE_SERVER_IP:11440
cert=/etc/stunnel/server.pem
key=/etc/stunnel/server.key
OPENVPN CONFIG на сервере:
local REMOTE_SERVER_IP
port 11440
proto tcp
2 ответа
OpenVPN через TLS
Ваш VPN использует TCP в качестве транспортного протокола. Экземпляр stunnel используется для инкапсуляции содержимого потока TCP в TLS/TCP. Вы получаете этот стек протоколов:
[IP] <------------------------> [IP ]
[OpenVPN] <------------------------> [OpenVPN]
[TLS] <~~~~~> [TLS]
[TCP] <-> [TCP] <-----> [TCP] <-> [TCP]
[IP] <-> [IP] <-----> [IP] <-> [IP ]
[] [] [] []
Сервер Stunnel Stunnel Клиент
Между экземплярами stunnel у вас есть стек протоколов на проводе:
[IP ] [OpenVPN] [TLS] [TCP (443)] [IP ] [...]
Поскольку TLS шифрует свою полезную нагрузку, злоумышленник может видеть только:
[??? ] [TLS] [TCP (443)] [IP ] [...]
Так что да, это обычный трафик TLS (это может быть HTTP/TLS, SMTP/TLS, POP/TLS или что-то еще для того, кто смотрит на трафик, но он очень похож на HTTP / TLS, когда используется TCP-порт 443). Вы можете проверить это с помощью wireshark: запишите трафик между экземплярами Stunnel. В пользовательском интерфейсе wireshark (правая кнопка в пакете потока) вы можете попросить wireshark интерпретировать трафик как TLS: он распознает его как трафик TLS (вы увидите разные сообщения TLS, но не полезную нагрузку сеанса TLS),
Возможно, вы захотите использовать SNI в клиенте, чтобы выглядеть так, как поступил бы современный браузер. Возможно, вы также захотите использовать ALPN, но в настоящее время stunnel не справляется с этим.
OpenVPN со встроенным TLS
Для сравнения, если вы используете OpenVPN, у вас будет что-то вроде этого:
[IP ] [OpenVPN] [TCP] [IP ] [...]
Который выглядит так:
[??? ] [OpenVPN] [TCP] [IP ] [...]
Встроенный уровень TLS не инкапсулирует пакеты (IP, Ethernet), а используется только для настройки сеанса и аутентификации:
[TLS] [OpenVPN] [TCP] [IP ] [...]
В этом случае ваш трафик не выглядит как обычный трафик TLS, но, очевидно, является OpenVPN. Если вы интерпретируете этот трафик как OpenVPN в Wireshark, вы узнаете сообщения OpenVPN и внутри них сообщения TLS (но не полезную нагрузку).
Предупреждение
Вы должны знать, что если пассивный злоумышленник не сможет сказать, что ваш удаленный сервер на самом деле является сервером OpenVPN, активный злоумышленник сможет это выяснить: просто подключившись к вашему серверу по TLS, он сможет чтобы подтвердить, что это не сервер HTTP / TLS. Пытаясь говорить по протоколу OpenVPN, он сможет обнаружить, что ваш сервер является сервером OpenVPN/TLS.
OpenVPN через TLS с аутентификацией клиента
Если вы беспокоитесь об этом, вы можете включить аутентификацию клиента TLS: злоумышленник не сможет инициировать рабочий сеанс TLS и не сможет угадать, какая полезная нагрузка инкапсулирована в TLS.
* Предупреждение:** Я не говорю о встроенной поддержке TLS в OpenVPN (см. Выше объяснение того, почему это не поможет).
Мультиплексированный OpenVPN/TLS и HTTP / TLS
Другое решение состоит в том, чтобы обслуживать как HTTP, так и OpenVPN через сеанс TLS. sslh может использоваться для автоматического определения полезной нагрузки протокола и отправки либо на простой сервер HTTP/TCP, либо на сервер OpenVPN/TCP. Сервер будет выглядеть как стандартный HTTP / TLS-сервер, но кто-то, пытающийся говорить на OpenVPN/TLS с этим сервером, сможет обнаружить, что на самом деле он также является OpenVPN/TLS-сервером.
либо OpenVPN/TCP
или HTTP/TCP
[1].---------. .------.HTTP/TCP.-------------.
->| stunnel |---->| sslh |------->| HTTP-сервер |
'---------' '------'| '-------------'
| .----------------.
"------>| OpenVPN сервер |
OpenVPN/TCP '----------------'
[1] = либо OpenVPN/TLS/TCP, либо HTTP / TLS / TCP
OpenVPN через HTTP CONNECT через TLS
Другое решение состоит в том, чтобы использовать стандартный сервер HTTP / TLS и использовать HTTP CONNECT/TLS для подключения к серверу OpenVPN: он будет выглядеть как стандартный сервер HTTP. Вы даже можете потребовать аутентификацию клиента, чтобы авторизовать запрос HTTP CONNECT (squid должен это сделать).
OpenVPN имеет возможность использовать HTTP-прокси:
http-proxy proxy.example.com
Вы должны быть в состоянии объединить это с экземпляром Stunnel, подключающимся к удаленному HTTPS PROXY:
http-proxy 127.0.0.1 8443
remote vpn.example.com
Который реализовал бы этот стек протоколов:
[IP] <------------------------> [IP] [OpenVPN] <-------------- ----------> [OpenVPN] [HTTP] <-------------> [HTTP] [TLS] <~~~~~> [TLS] [TCP ] <-> [TCP] <-----> [TCP] <-> [TCP] [IP] <-> [IP] <-----> [IP] <-> [IP] [] [] [] [] Сервер HTTPS PROXY stunnel Client
Ответ ysdx великолепен и очень хорошо описывает, как будет выглядеть трафик в сети.
Однако не упоминается, что анализ трафика может иметь большое значение для идентификации приложений.
Предположим, что ваше OpenVPN-соединение выглядит как соединение https на проводе, поэтому злоумышленник не может прочитать поток байтов и узнать, что это за соединение.
Типичное соединение https не будет жить слишком долго. Может быть, ваш браузер поддерживает соединение с почтовым сервером, я не знаю. В общем, будет много относительно коротких подключений ко многим разнородным удаленным серверам.
OTOH, соединение OpenVPN может существовать часами или днями и отправлять много данных туда и обратно на сервер openvpn.
Вы могли бы смягчить долгоживущее соединение, периодически сбрасывая и перезапуская соединение. Предположительно это имеет значение для трафика вашего приложения, но может быть работоспособным. Тем не менее, структура большого и большого количества трафика между вами и сервером openvpn будет намного сложнее замаскировать.