Для обладателей разлоченного загрузчика и Magisk это не проблема.
а можно узнать реализацию шифрования такого эффективного? заинтересовала тема
Погуглил (VPS Disk Encryption Tutorial: Step-by-Step Guide to Securing Your Virtual Server Storage - USAVPS):
- сделать sshd в initrd и через него получать ключ разблокировки (т.е. вручную)
- идти (аналогично из initrd) на доверенный сервер за ключом - полностью автоматическое решение, но нужен хотя бы один сервер, которому доверяем.
- (комбинация этих двух методов, разумеется)
UPD: это оффтопик, может модератор может это в отдельную тему выделить?
Не вижу в этом необходимости, у VPN на VPS есть очевидное применение, не связанное с обходом блокировок - объединение в одну сеть нескольких сетей без доступа к внешнему IP. VPN вообще-то и предназначен для объединения сетей первоначально.
Можно конечно попытаться пробить NAT, но это не очень надёжно.
И бинарники можно переименовать, использовать свои сборки, добавить xor в протокол, чтобы избавиться от сигнатур и т.п. Тем более от описанных мной способов обнаружения входной адрес на российском VPS не помогает, если потом идёт проброс на иностранный VPS для обхода блокировок, то это только увеличивает задержку.
Жестко туплю и не понимаю, что тут написано. Кто делает запрос? Мы? Кто замеряет – сервис?
Насколько мне известно, явные показатели випиэн – пулы айпи и примерно равный входящий/исходящий трафик
Тут учитывается задержка от последнего узла по маршруту с внешним IP (перед NAT) и клиентом.
Если туннелирования нет, то она небольшая (может быть за исключением 3G и 2G мобильных сетей и спутниковых, но мобильные сети можно определить по диапазонам IP). Если туннелирование есть (особенно из-за границы), то она гораздо больше.
Замер идёт со стороны сервиса, а не клиента.
Откуда сервис знает наш IP, если он никак не утёк? Сервис же получит запрос из сети впн
А сервису знать реальный адрес не обязательно, достаточно только факта использования VPN.
Но реальный адрес можно определить, если сервисы и операторы будут передавать государству статистику по соединениям клиентов. Это технически возможно, хотя и на мой взгляд довольно затратно.
Ладно.. то бишь суждение выносится только исходя из задержки?
В моём эксперименте только один критерий, в реальных системах могут применяться и другие критерии, например, категория IP (датацентровый, резидентский или мобильный).
Небольшие изменения в скрипте: для повышения точности измерения задержка от клиента измеряется 3 раза.
А то я видел, как с одного IP было как очень большое время отклика, так и маленькое (видимо на вайфае).
Я придумал, как можно использовать информацию о TTL для повышения точности определения.
При прохождении пакетов за NAT TTL продолжает уменьшаться. А при проксировании - нет.
Если клиент - пользователь мобильной сети с заметной разницей задержки, у него после операторского NAT ещё пара хопов, TTL получается заметно меньше, чем если бы с адреса шлюза оператора напрямую шло бы подключение.
Если клиент - пользователь прокси-сервера (или VPN, работающего без NAT), то у него будет тот же самый TTL, что с сервера напрямую, так как соединение перенаправляется выше протокола IP.
Я проверил на своём VPN - по этому признаку он тоже палится. Но администратор сервера может переопределить TTL для соединений и обойти эту проверку.
Добавил эту проверку в свой скрипт.
Да, обнаруживает:
Welcome to VPN checking page.
Processing time is 54.2 msec
TTL: 55
RTT (mtr) is 2.2 msec from X.X.X.X
RTT (ping) time is 2.6 msec from X.X.X.X TTL=57 dT=1
Delta time is 52.0 msec
Too big delta, you are a VPN or mobile network client!
Delta TTL is 1, you are probably a VPN client!
По такой эвристике даже тех кто сервер в РФ держит можно определять получается. Если раньше с 60% точностью для меня определяло, то теперь намного больше, если не все 100.
UPD: после простоя прошмыгнуло
Welcome to VPN checking page.
Processing time is 52.0 msec
TTL: 55
RTT (mtr) is 2.3 msec from X.X.X.X
RTT (ping) time is 2.6 msec from X.X.X.X TTL=57 dT=1
Delta time is 49.7 msec
You aren't a VPN user.
Снова
Welcome to VPN checking page.
Processing time is 52.1 msec
TTL: 55
RTT (mtr) is 2.4 msec from X
RTT (ping) time is 2.5 msec from X TTL=57 dT=1
Delta time is 49.7 msec
You aren’t a VPN user.
Короче, даже так, на 100% не определяет. Причем у меня трёхэтажная прокси-цепочка (схема маршрутизации), разница TTL должна быть сильно больше.
Там порог допустимой разницы 50 мс, а у вас 49,7. Не хватило совсем чуть-чуть.
Это всё при относительно стабильной сети. Если у пользователя интернет идет через какие-то хитросплетения или есть деградация и помехи в сети – будет выше.
Нет, это конечно можно комбинировать со многими прочими факторами, тогда будет полезно, но как один из многих усиляющих факторов, фильтрующие ложные срабатывания, повышающие процент уверенности.
А зачем вы ркн готовый и даже протестированный алгоритм даете?)
написало, что не vpn user, хотя это не так ) и, у меня split tunneling - ру-зона на один сервак, остальное на финку.
Я думаю, что в РКН наверняка додумались до чего-то такого, но публично об этом не говорят. А тут можно попробовать работоспособность идеи.
Может додумались, а может и нет, 50 на 50, как в том анекдоте про женскую логику)