Кто-нибудь уже создавал подобную тему или нет я хз.
Использует запрет или гдпи это я тоже хз.
Суть в чем, если при TCP Handshake задержать ответ ACK от клиента к серверу youtube, и блокировать SYN-ACK retransmission от сервера youtube, в течение 15 секунд, то DPI пропустит TLS handshake и ютуб будет работать.
Я вообще проверял как DPI отнесется к пакету с TLS handshake вне TCP-сессии, и судя по отсутствию ответов в вайршарке, решил что DPI TCP-сессию все-же хранит, после чего решил проверить как долго он ее хранит, и как выяснил, 15-ти секунд достаточно для того чтобы DPI дал ютубу работать.
Провайдер: Ростелеком.
Если кому-то надо код чтобы затестить на своем провайдере - я дам.
Не особо шарю че именно делают запрет с гдпи, так что возможно велосипед изобрел, ну а вдруг нет.
Проблема кастомных задержек в том, что скорее всего отвалится код JavaScript с подобранными таймаутами. Для скачивания файла или установки длинной сессии способ сгодиться, а для динамических веб-страниц нет.
Работало на подсетях с чёрными списками. С белыми списками если разрешительный пакет не приходит, то блокируется и обычный keep-alive. Давно уже не проверял. NAT сессия не привязана к сессии dpi фильтра. С белым ip наверняка можно ещё напридумывать способы обходов по таймаутам dpi.
при этом я пробовал использовать один и тот же айпи адрес гугла для всех доменов - результат тот же.
для успешного пробития youtube.com (чтобы каждый раз) мне пришлось делать задержку ACK на 32 секунды, если делать меньше секунд то шансы на пробитие уже примерно 30%
а вообще многие сайты закрывают соединение через <10 секунд, это с гуглом повезло ещё что такой большой таймаут