Ярослав

Это был крик души, или действительно интересны технические подробности? )

Если кратко, то причина вполне техническая, и звучит она "экономии для".
Далее должна быть фраза типа "снижая расходы на дополнительное оборудование, мы добиваемся снижения стоимости наших услуг". Как инженер, я не могу судить, сколько именно в ней правды, но логика подсказывает, что какая-то корреляция быть действительно должна.

В общем, блокировать абоненту мобильный интернет можно в нескольких точках, и самый дубовый, но эффективный и дешёвый, не требующий расширения узлов сети, именно так и проявляется: кончились деньги - интернет пропал до перерегистрации в сети.

У одной из стороны проблемы со связью?

Скорее всего, именно так.

Дело в том, что канал голосовой связи что в проводной, что в мобильной сети, особенно если задействовано несколько операторов связи, может "собираться" достаточно долго - если правильно помню, речь идёт о десятках секунд.
Чтобы звонящий, пока собирается канал, тишины в трубке не пугался, его родная АТС начинает играть в трубку длинные гудки сразу же.

А потом какому-то устройству посереди будущего канала связи показалось, что канал собирается уж слишком долго, и оно шлёт всем остальным сигнал "Мне надоело ждать. разбираем канал обратно".

Ну да, именно что отдельная сетевая инфраструктура.
Местами поверх существующей, местами вообще отдельное оборудование.

Входящее в состав этой сети оборудование не участвует в глобальной ip-маршрутизации.

Там свои, независимые от интернета планы адресации: свои принципы выделения ip-адресации, свои организации, отвечающие за выделение BGP AS.
В общем, это свой маленький отдельный интернетик - только для своих.
А протоколы все те же, дабы ничего нового не придумывать.

Примером много: и тот же Swift, ГАС Выборы, и ведомственные сети, и связывающая мобильных операторов связи друг с другом сеть IPX/GRX.

Собственно, это - в широком смысле огромный, как гоеграфически, так и топологически, VPN с многими тысячами узлов.
А что тут удивительного?

Это зависит от того, что там, за Dlink DES-1024A, и как устроена Ваша сеть.
Вообще, Ваши коммутатору настройке не подлежат: они неуправляемые.

Если:
1. Ваши устройства получают ip-адреса по DHCP, и
2. За Dlink DES-1024A находится Ваш маршрутизатор, эти ip-адреса выдающий любому желающему, и
3. На Вашем маршутизаторе настроены NAT и политики доступа "Ip-адреса, выдаваемые по DHCP, пускать куда угодно"

То проблем при каскадном включении "sip-телефон + компьютер" -> D-link DGS-1005A -> Dlink DES-1024A быть не должно.

Невыполнение любого из этих трёх условий уже потребует что-то делать руками.

Вообще, в Казахстане, говорят, HTTPS MITM есть:
https://habrahabr.ru/post/303736/
Было бы интересно пообщаться с казахскими коллегами - чем там всё кончилось?

Но в данном конкретном случае, полагаю, всё проще:
Из казахского чегототамнадзора во Вконтакте приходит требование заблокировать некую группу на территории Республики Казахстан.
Вконтакте ссориться с казахами по такому мелкому поводу не хочет, и где-то в глубине настроек Вконтакта напротив этой группы ставится метка "Если GeoIP покажет, что пользователь зашёл с казахского ip-адреса, группу ему не показывать".

Через Тор же всё работает потому, что в таком случае Вконтакте увидит Ip-адрес абстрактного Зимбабве, а из Зимбабве таких запросов не приходило.

Здесь, всё-таки, придётся лезть теорию.

В общем виде, технология называется TCP Hole Punching: https://en.wikipedia.org/wiki/TCP_hole_punching

Работает она так:
Есть маршрутизатор с внешним ip-адресом 1.2.3.4 и спрятанной за ним сетью 192.168.0.0/24.
Допустим, находящееся за NAT устройство с Ip-адресом 192.168.0.100 решило вылезти в Интернет и подключиться к серверу с ip-адресом 5.6.7.8 к порту 8080.
Устройство поднимает TCP-соединение: со стороны устройства пара ip-адрес:порт будет, допустим, 192.168.0.100: 1111, а со стороны принимающей стороны 5.6.7.8:8080.
Маршрутизатор, пропуская сквозь себя эти пакеты, подменяем ip-адрес и, что важно, порт спрятанного за ним устройства: на, предположим, 1.2.3.4:7890.

Если на маршрутизаторе включен TCP Hole Punching, то он начинает преобразовывать пары адрес-порт 192.168.0.100: 1111 -> 1.2.3.4:7890 не только для соединений, исходящих изнутри, но и для входящих соединений снаружи.
Это значит, что, начиная с момента установки соединения "изнутри наружу", запрос на TCP-соединение из интернета к 1.2.3.4:7890 будет прокинут маршрутизатором до спрятанного устройства, и дойдёт до 192.168.0.100: 1111.

Получается, клиентская сторона для приёма соединений из-за NAT должна подготовиться следующим образом:
1. Установить соединение с каким-то узлом в Интернет. Вообще неважно с кем: нам надо просто "пробить дырку" в NAT для приёма входящих соединений. Установив соединение, мы запоминаем source port.
2. Создаём Listening socket на порту, запомненном в предыдущем шаге. Теперь мы можем принимать входящие соединения из интернет!

И всё бы здорово, но возникает следующий вопрос: номер порта, на котором мы слушаем, маршрутизатор подменит совершенно непредсказуемым образом.
Если мы хотим установить прямое соединение с устройством, которое тоже находится за NAT, как нам узнать, к какой публичной паре Ip-адрес:порт нам цепляться? Ведь каждый раз номер порта может непредсказуемо меняться!

Ответ здесь один: нужен посредник - что-то типа каталога. Сервер с публичным ip-адресом, на котором можно зарегистрироваться. Ну никак без него!

Работать это может так:
1. Есть каталог с ip-адресом, допустим, 11.12.13.14, принимающий входящие соединения на порту 80.

2. Устройство А с ip-адресом 192.168.0.100, находящееся за NAT 1.2.3.4, готовится к приёму входящих соединений. Оно устанавливает TCP-соединение с каталогом:
192.168.0.100:1111 ===> 11.12.13.14:80.
NAT A в проходящих сквозь него ip-пакетах преобразует ip-адрес и номер порта для спрятанного за ним устройства, и запоминает это соответствие:
192.168.0.100:1111 <-> 1.2.3.4:1112.
С точки зрения каталога, он принял такое входящее TCP-соединение:
1.2.3.4:1112 ===> 11.12.13.14:80, ибо реальную адресацию устройства A ему узнать просто неоткуда. Ну и ладно: всё и так прекрасно работает!

3. Устройство B с ip-адресом 192.168.2.200, находящееся за NAT 5.6.7.8, устанавливает TCP-соединение с каталогом:
192.168.2.200:2221 ===> 11.12.13.14:80.
NAT B в проходящих сквозь него ip-пакетах преобразует ip-адрес и номер порта для спрятанного за ним устройства, и запоминает это соответствие:
192.168.2.200:2221 <-> 5.6.7.8:2222.

4. Устройство B спрашивает у каталога: "А кто к тебе ещё подключен?"
Каталог ответчает: "Да вот есть один такой, 1.2.3.4:1112"

5. Устройство B устанавливает TCP-соединение с полученным от каталога ресурсом:
192.168.2.200:9876 ===> 1.2.3.4:1112

NAT B подменяет и запоминает ip-адрес и номер порта устройства B: 192.168.2.200:9876 -> 5.6.7.8:4321

Соответственно, на NAT A прилетает запрос на установление соединения:
5.6.7.8:4321 ===> 1.2.3.4:1112

NAT A смотрит в таблицу NAT-трансляций, видит там знакомый номер порта, и подставляет из таблицы ip-адрес и номер порта устройства A: 1.2.3.4:1112 -> 192.168.0.100:1111

6. Устройство A получает запрос на подключение:
5.6.7.8:4321 ===> 192.168.0.100:1111

Собственно, в зависимости от требований, сервер каталога можно:
1. Написать самому
2. А можно не изобретать велосипед, и воспользоваться готовыми реализациями того же протокола STUN

Забрать обратно - уже никак. Как минимум, придётся ждать, пока истечёт срок жизни.

Если важно, чтобы конкретный ip-адрес назначался конкретному устройству, можно:
1. Посмотреть MAC-адрес устройства и в настройках DHCP-сервера явно прописать соответствие MAC -> IP, или
2. В настройках DHCP-сервера изменить диапазон автоматически выдаваемых ip-адресов так, чтобы желаемый IP-адрес в него не попадал, и на устройстве прописать желаемый IP-адрес вручную

10.0.0.0/8 - это адресный пул.
Однако, каждый абонент живёт в отдельном Point-to-point-тоннеле.

Вообще, ip-броадкаста в мобильном интернете нет за ненадобностью.
Есть что-то вроде мультикаста (MBMS, прости Господи), который полностью управляется оператором и работает строго в одну сторону: из специального узла сети в сторону абонента.

Поэтому:
1. То, что несколько разных корпоративных клиентов оказались не просто в одной ip-подсети (это ещё ладно бы), а ещё и увидели друг друга - это, конечно, безобразие, стыд и позор.

2. То, что traceroute показывает один хоп, тоже нормально: ip-пакет из одного ppp-тоннеля в другой вполне можно переложить и без уменьшения TTL, а зациклить ip-пакет не даст проверка на совпадение source ip address и собственно ip-адреса, выделенного абоненту.

3. Запинговать/зафлудить кого-либо насмерть теоретически можно, но при условии, что uplink-канал отправителя шире, чем downlink жертвы (например, если флудить из более новой технологии пользователя более старой: 3G -> GSM или LTE -> GSM). Однако, нагадить всем разом не получится, гадить придётся поштучно и с постоянным страхом получить по ушам за хулиганство от оператора.