Поясняю за популярные VLESS, WireGuard и может затронем другие.

Когда у вас спрашивают или вы видите упоминание о ***, что для вас значит эта аббревиатура? Или тот же VLESS допустим, а ведь еще есть и не менее популярные IPsec, O***, L2TP, DM***, SOCKS и прочие протоколы для шифрование/проксирования, а ведь, эта малая часть из сетевого стека, которые позволяют маскировать трафик.

Так вот, что же такое *** (WireGuard) и популярный VLESS?
Казалось бы, работа у них одна - направить ваш трафик до нужного назначения минуя системы блокировок, в целом - да, но, нужно знать, что, они работают на абсолютно разных архитектурах и уровнях сетевой модели, используют разные подходы чтобы отправитель (SRC) дошел до получателя (DST).

Всем привет и в этой теме, мы разберем работу двух разно-архитектурных протокола VLESS и WireGuard.

Начнем с основы.
Вся наша необъятная сеть WWW состоит из 7 мамонтов и черепах (модель OSI), углубляться в это не будем, можете сами почитать, так вот, протоколы WG и VLESS работают на разных ступенях:

WG - работает на транспортном/сетевом уровне (L3/L4), а это значит, что, Wireguard напрямую работает с IP пакетами, не поняли? Давайте подробнее:
Все что вы шлете в интернет состоит из IP пакетов, к примеру, вот вы проверяете пинг до восьмерок допустим (ping 8.8.8.8) и вам приходит ответ, мол TTL такой-то, столько-то мс и так далее, так вот, это и есть IP пакет и он состоит из:

⁡

⁡[IP заголовок] -> [TCP/UDP заголовок] -> [Payload]

⁡

1. В IP заголовке у нас информация откуда и куда мы направляем пакет
2. В TCP/UDP - src/dst port (откуда и куда на какой порт шагаем)
3. Payload - данные

Ну и сверху еще сетевой кабель или вафля.

И вот мы решили установить WG и передавать трафик через него, что в таком случае будет? Вспоминаем, что, у нас обычный пакет состоит из трех основ (IP, TCP/UDP заголовки и Payload), в случае с WG добавляет еще кое-что:

⁡

⁡[IP заголовок] -> [UDP заголовок] -> [WG заголовок] -> [Encrypted Payload]

⁡

Если с обычным трафиком, у нас в IP заголовке был наш адрес и адрес получателя, то с WG, адрес получателя становится сервер, где у нас размещен Wireguard.
UDP заголовок, здесь будет во многих случаях порт 51820, это порт, на котором работает Wireguard (офк, можно свой поставить, но, я указал дефолтный) и он всегда работает по UDP.
WG заголовок говорит о хендшейке с сервером, когда он последний раз был (рукопожатие и обмен ключами)
И затем уже зашифрованные данные.

Ах да, я же не рассказал в чем разница между UDP и ТСР, картинка я думаю все объяснит.

Ну короче, TCP гарантирует доставку пакета до адресата, а UDP - нет.

И уже при дампе трафика у нас будет показываться только содержимое WG, а не данных.
Возможно, я какие-то моменты упустил или что-то не раскрыл более детально, буду рад, если напишите, старался более поверхностно и понятно.

Теперь про VLESS.
Если WG работает на L3/L4, то VLESS работает на L7 уровне (уровень приложения).
VLESS работает по принципу маскарада, когда трафик маскируется под другой, когда мы обращаемся за закрытому ресурсу, VLESS делает так, что, мы обращаемся не к данному ресурсу, а к сайту по типа Google (он же не закрыт у нас).
Теперь разберем поподробнее:
Вот наш пакет без VLESS:

⁡

⁡[TCP заголовок] -> [TLS заголовок] -> [Payload]

⁡

Здесь все понятно, куда мы направляем пакет, от кого, используем шифрование TLS (HTTPS) и сами данные

А вот пакет с VLESS:

⁡

⁡[TCP заголовок] -> [TLS заголовок] -> [VLESS] -> [Payload]

⁡

То есть, VLESS работает уже на установленном TCP соединении и делает обертку, направляя трафик на закрытый ресурс, мы, якобы отправляем пакет на открытый ресурс.

PS: Казалось бы тема раскрыта, но, есть еще кое-что.
Все чаще и чаще всплывают новости и том, почему же VLESS еще живет, а Wireguard и прочие *** протоколы блокируются?
Ответ раскрыт в теме, но, напишу еще раз.
Wireguard и другие протоколы вешают свои заголовки в пакет и DPI их распознает, как следствие, по этим заголовкам и происходит блокировка, а VLESS, он же не имеет своей метки и проходит как обычный HTTPS трафик, но и тут скоро скорее всего будет несладко. VLESS он же вешает TLS и РКН уже блокирует TLS трафик (вспомните историю с CloudFlare, когда закрыли доступы к сайтам, которые за ним находятся, а ведь там тоже TLS, насколько я помню)