остановите трафик vpn и убедитесь, что он выглядит как трафик SSL на порту 443

OpenVPN через TLS

Ваш VPN использует TCP в качестве транспортного протокола. Экземпляр stunnel используется для инкапсуляции содержимого потока TCP в TLS / TCP. Вы получите этот стек протоколов:

[IP     ]<------------------------>[IP     ]
[OpenVPN]<------------------------>[OpenVPN]
            [TLS   ]<~~~~~>[TLS]
[TCP    ]<->[TCP   ]<----->[TCP]<->[TCP    ]
[IP     ]<->[IP    ]<----->[IP ]<->[IP     ]
[       ]   [      ]       [   ]   [       ]
 Server      stunnel      stunnel  Client

Между экземплярами stunnel у вас есть этот стек протоколов на проводе:

[IP      ]
[OpenVPN ]
[TLS     ]
[TCP(443)]
[IP      ]
[...     ]

Поскольку TLS шифрует свою полезную нагрузку, злоумышленник может видеть только:

[???     ]
[TLS     ]
[TCP(443)]
[IP      ]
[...     ]

Так что да, это простой трафик TLS (это может быть HTTP / TLS, SMTP / TLS, POP / TLS или что-то еще для тех, кто смотрит на трафик, но он очень похож на HTTP / TLS, поскольку используется TCP-порт 443). Вы можете проверить это с помощью wirehark: записать трафик между экземплярами stunnel. В пользовательском интерфейсе wirehark (правая кнопка на пакете потока) вы можете попросить wirehark интерпретировать трафик как 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 в wirehark, вы узнаете Сообщения 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.

        either OpenVPN/TCP
          or HTTP/TCP       
[1].---------.     .------.HTTP/TCP.-------------.
-->| stunnel |---->| sslh |------->| HTTP server |
   '---------'     '------'|       '-------------'
                           |       .----------------.
                           '------>| OpenVPN server |
                        OpenVPN/TCP'----------------'

[1]= Either OpenVPN/TLS/TCP or HTTP/TLS/TCP

OpenVPN через HTTP ПОДКЛЮЧЕНИЕ через TLS

Другое решение - использовать стандартный сервер HTTP / TLS и использовать HTTP CONNECT / TLS для подключения к серверу OpenVPN: он будет выглядеть как стандартный сервер HTTP. Вы даже можете потребовать аутентификацию клиента, чтобы авторизовать запрос HTTP CONNECT (squid должен уметь это делать).

OpenVPN может использовать HTTP-прокси:

http-proxy proxy.example.com

Вы должны иметь возможность объединить это с экземпляром stunnel, подключенным к удаленному HTTPS-ПРОКСИ:

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     ]
[       ]   [      ]       [   ]   [       ]
 Server    HTTPS PROXY     stunnel   Client

Ответ ysdx великолепен и очень хорошо описывает, как будет выглядеть трафик в сети.

Однако не упоминается, что анализ трафика может иметь большое значение для идентификации приложений.

Предположим, что ваше соединение OpenVPN выглядит так же, как соединение https на проводе, поэтому злоумышленник не может прочитать поток байтов и узнать, что это за соединение.

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

OTOH, соединение OpenVPN может существовать часами или днями и будет отправлять много данных туда и обратно на сервер openvpn.

Вы можете уменьшить долговременное соединение, периодически прерывая и перезагружая соединение. Предположительно, это повлияет на трафик вашего приложения, но может работать. Однако структуру большого и большого трафика, проходящего между вами и сервером openvpn, будет намного сложнее замаскировать.