Так не должно быть, походу шпионы в смартфоне каким-то образом триггерят блок. Проверьте, отключите Wi-Fi, переключившись на сотовую связь, доступ к VPS появляется?
- Если да, то active probing по связке SRC → DST продолжается.
- Если нет, то на ПК тоже пропадает?
Надо было наоборот 
Выход с заблокированного (тот IP что уже “грязный”), а вход – с нового, ещё неизвестного шпионам IP.
У вас не прекратится active probing из-за этого, новый IP теперь возможно тоже стал грязным, если вы сливаете сервисам-шпионам его как exit узел.
Я на 99% уверен, что шпион просто запомнил связку приложение (с аккаунтом) → грязный IP и блокирует подключения с смартфона к грязному IP. Провал в том, что нужно было грязный IP оставить на выходе, а на вход сделать новый, а не наоборот новый на выход.
Если схема кривая и есть утечки – да, но моя схема чинит “кривизну тостера” архитектурно на уровне сети, делая любые “слития доп инфы” невозможными. Разумеется, если проливать трафик мимо туннеля в direct с того же устройства – это всё поможет шпионам.
То есть железное требование у тостера одно – не сливать в direct трафик от шпионов. Гарантировать TUN интерфейс с пылесосом всех запросов в системе.
При неполной маршрутизации – согласен, но важно учитывать, что новый IP нельзя палить шпионам, он должен стать входным, а грязный – выходным. И шпионский трафик в direct не слать, это очень помогает шпионам.
Зерно статьи – разделение. Её полная задумка – это полная схема маршрутизации трафика.
Первое – чинит простой слив IP логам шпиона. Второе – устраняет дополнительные утечки, которые шпион использует для проверки на наличие туннеля.
Что за утечки? Например, те что обсуждали здесь, этот шпион экспуатирует уязвимость split маршрутизации:
Его цель даже не IP узнать, а просто подтвердить наличие туннеля, это уже достаточно для инициализации дальнейших расследований со стороны шпиона.