И все страны СНГ тоже относятся к европейской зоне RIPE, как и Россия, даже среднеазиатские вроде Узбекистана и Киргизии, поэтому их адреса тоже не должны пересекаться с китайскими.
Россия и Китай находятся в разных зонах интернет-регуляторов (Россия в европейском RIPE, а Китай в азиатском APNIC), поэтому пересечение IP маловероятно.
Не все адреса на 175 китайские, навскидку взятый адрес 175.33.33.33 вообще австралийский (Австралия тоже относится к азиатской зоне). Но все адреса на 175 относятся к азиатской зоне, поэтому там не должно быть российских (российскими они могут быть в том случае, если какая-то международная компания из азиатской страны использует часть своих адресов в России, российские компании должны регистрировать свои адреса в европейской зоне).
В вопросе имеется в виду доверие не между клиентом и сервером, а между двумя клиентами на разных серверах. Укажет alice сервер eve.com - так это будет alice@eve.com, другой SIP URI.
Cредства шифрования сейчас используются повсеместно, и в сервисах google/apple тоже (HTTPS и QUIC хотя бы). Конечно, правительство хочет и до них дотянуться, но это сложно будет, и заблокировать эти сервисы тоже не получится без последствий.
Поэтому не думаю, что это решающий фактор. Может быть, наличие средств шифрования в Blackberry заявлялось явно, поэтому они проходили как криптосредства? так и в обычных самых распространённых мессенджерах (ватсапе и телеграме) тоже наличие шифрования заявляется, не говоря уже о приложениях для гиков вроде Tox и Jami.
В таком случае проще просто коммутатор поставить вместо роутера, если wi-fi не нужен. Хотя в таком случае роутер и будет работать как коммутатор.
Разница между работой роутера в режиме коммутатора и нормального роутера состоит в ограничении broadcast трафика, но в домашней сети устройств мало и там это неактуально.
podvox23, ещё самый простой вариант c IPv6, если не хочется городить ссылки и какие-то дополнительные действия на стороне клиента. Спрашиваем у пользователя, с каких операторов и из каких регионов ему нужен доступ, и открываем доступ для соответствующих диапазонов IPv6 на псевдослучайный адрес сервера (например, 2001:db8:11:44:e871:10cc:981a:bc41). Снаружи его не насканить (только если это не роутер, который может засветить адрес в трейсе). Хотя адрес может засветиться где-то в интернете, особенно если на сервере браузер запускают, но можно на сервере назначить несколько адресов, и пусть для выхода в инет используется другой адрес, а на файрволе входящие разрешены на отдельный.
Диапазоны адресов клиента могут быть, например, 2a00:1fa0::/33 (МТС Центр), 2a00:1fa0:8000::/33 (МТС Северо-Запад), 2a00:1fa0::/32 (весь МТС), или 2a00:1370::/32 (МГТС)
podvox23, если хочется вообще без сторонних приложений, тогда подойдёт только HTTPS ссылка.
По ней пользователь вводит логин и пароль, и получает информацию "Для вашего IP открыт доступ к такому-то сервису до определённого времени на таком-то порту нашего внешнего IP". С IPv4 схема тоже работает через открытие портов, но IPv6 ещё лучше тем, что его трудно найти сканированием адресов (если вдруг возникнет какая-то ошибка и порт останется открыт для всех, то ваш сервис будет в опасности, а на IPv6, особенно если младшая половина адреса какая-нибудь псевдослучайная, такой риск гораздо ниже).
Допустим, мне известно, что у какого-то нехорошего человека IP-телефония на мобильном, чтобы насолить не кому попало, а именно ему. Он физлицо, и оператор из-за него чесаться не будет (оператору наоборот это выгодно, больше потребление трафика, больше можно содрать денег).
И флудить можно не со своего адреса, а с какого-нибудь абузоустойчивого иностранного.
Вопрос в том, как защититься от этого с минимальными затратами, и велик ли риск от такой уязвимости.
Хотя на большинстве мобильных тарифов просто отключается интернет после окончания пакета, поэтому ущерб от атаки на обычного абонента будет не очень большой, порядка нескольких сотен рублей.
Скорее всего, если есть такая проблема, то решается она так же, как и с другими типами DoS атак: подключение идёт через промежуточный узел с широким каналом и фильтрацией, где трафик фаерволится. Если это мобильный VoIP, то можно использовать VPN. Если это какой-то нехороший человек, он и так будет использовать VPN, чтобы спрятаться.
Озузер Юзеров, в настройках роутера должно быть. Но для этого и роутер, и провайдер должны уметь делать prefix delegation, а это пока ещё не очень распространено. Если у вас в техподдержке не знают, что такое NAT, то про prefix delegation тем более никто не скажет.
Ещё такая мысль, раз вам нужен гугл и ютуб, они могут работать по IPv6.
IPv6 обычно идентифицирует пользователя по /64 подсети (это стандартная аллокация), но некоторые провайдеры или туннельные брокеры могут давать больше, /56 или /48. Задаёте на разных компах адреса из разных /64 и вперёд. Снаружи нельзя определить, это два пользователя от одного провайдера (например, у нас МГТС даёт /48 на район и /64 на пользователя), или один пользователь с бóльшей подсетью.
Насколько я знаю, управление сетью доступно хоть в какой-то мере для VPN приложений. Например, если нужно сделать reverse tethering, то на компьютере, к которому подключён телефон в режиме USB модема, включается VPN сервер, и он уже может выдать на телефон нужные настройки, IP-адрес, DNS и т.п. Можно через VPN задать адрес, независимый от типа подключения (Wi-Fi, провод или мобильный интернет), тогда при переключении канала обмен продолжится по тому же адресу. VPN сервер может работать по разным протоколам, которые поддерживаются разными приложениями VPN клиентов: OpenVPN, Wireguard и т.д.
Напрямую без рута и без VPN недоступно никак. Чтобы не засыпало, можно прописать в исключения энергосбережения, но это ничего не гарантирует, как я понимаю. В андроиде есть служба уведомлений, которая работает через серверы гугла и способна разбудить приложение при получении уведомления.
Если устройство работает в качестве сервера по Wi-Fi, можно включать на нём точку доступа - тогда она должна оставаться активной вне зависимости от того, включён ли мобильный интернет или нет. Но в таком режиме довольно быстро садится батарейка.
Хотя я звоню маме по IP-телефонии напрямую на телефон, и звонки на её мобильный андроид проходят без проблем и без всяких уведомлений (но исключения энергосбережения пришлось добавлять, без этого выгружается быстро).
Бутфлаги это скорее всего параметры загрузки ядра, они хранятся в конфиге загрузчика. Загрузчиком может быть GRUB (тогда они лежат в grub.cfg), или UEFI сам по себе (тогда они хранятся в памяти UEFI и задаются с помощью efibootmgr).
