Ярослав

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

Если важно, чтобы конкретный 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). Однако, нагадить всем разом не получится, гадить придётся поштучно и с постоянным страхом получить по ушам за хулиганство от оператора.

Да.
Логика работы та же, чего-то принципиально нового тут не придумать.
Протоколы те же.
Плюс, внезапно захочется придушить того, кто придумал синтаксис цисковых настроек.

Поскольку резолвинг DNS происходит корректно, промышленно готовых вариантов остаётся три:

1. Провайдерский DPI: наверняка он уже есть у всех провайдеров в том или ином виде.
Логически DPI обычно включается в разрыв линка между ядром и NAT.
Физически зачастую тоже.
Кроме обычных шейпинга и подсчёта трафика per-subscriber, там реализован набор ALG (Application Layer Gateway), которые представляют из себя, фактически, прозрачные прокси для типичных протоколов: HTTP, FTP, DNS и т.д.
Как правило, ALG умеют не только реагировать на определённые значения полей, но и вмешиваться в процесс передачи данных.
Количество ALG зависит от навороченности DPI; в Procera даже World of Warcraft есть )
Ну а уж подмена HTTP-страницы - пожалуй, самая используемая функция HTTP ALG.

2. Наколенное решение раз:
Описано у none7
Завести у себя в сети сервер с ip-адресами, совпадающими с Ip-адресами Вконтакта (ну, или NAT'ить все запросы к нему на сервер-заглушку, что примерно то же самое) - вполне себе решение, если надо заблокировать сервис целиком, а не отдельные страницы на нём.
Но если вдруг ваши политики наберутся дурости у наших, и список блокируемых ресурсов начнёт расти, провайдеры взвоют этот вариант поддерживать )

3. Наколенное решение два:
На самом деле, в России есть свой список блокируемых ресурсов (т.н. список Роскомнадзора) с сотнями тысяч URL.

Выяснилось, что таким количеством записей множество провайдерских DPI попросту давится, поэтому эта задача зачастую решается следующим образом: заводятся отдельные серверы, подключаемые непосредственно к провайдерским BR (Border router'ам).

Задачи серверов:
- заглотить список блокируемых ресурсов, выдрать оттуда имена доменов и разрезолвить их в ip-адреса; адресов получается несколько десятков тысяч
- полученные адреса через OSPF или BGP сливаются в BR. BR - он большой, спокойно держит BGP Full View, поэтому 10-20-50k лишних префиксов для него - капля в море

Получается, что весь трафик в сторону ip-адресов, на которых находится хотя бы одна заблокированная страница, теперь льётся на эти серверы.
Казалось бы, фиг какой сервер всё это переварит, но их можно плодить десятками: срабатывает ECMP/Load Balancing на уровне маршрутизации, и трафик размазывается между серверами примерно поровну.

На самих серверах Linux, а в Linux - squid в transparent mode и iptables )
Соответственно:
- tcp port 80 силами iptables отправляется в сквид, где каждый запрошенный абонентом URL ищется в списке блокированных ресурсов
- в tcp port 443 проверяется SNI чтобы понять, пропускать трафик дальше, или резать к такой-то матери
- весь остальной трафик (и пинги, угу) пропускается насквозь без изменения

В дополнение к варианту Eugene Khrustalev:
Предполагаю, что малина сидит не голым задом в интернете, а за каким-то маршрутизатором.

В таком случае, разумнее всего было бы выселить её в так называемую демилитаризованную зону (DMZ):
1. Поселить её в отдельный Ethernet-сегмент/VLAN
2. В этом сегменте:
2.1. Использовать отдельную серую ip-адресацию
2.2. Настроить NAT: Destination NAT для входящих и Source NAT для исходящих соединений с малины
2.3. Запретить любой доступ на сам маршрутизатор, разрешив только транзит трафика
3. На маршрутизаторе явно разрешить только разрешённые типы трафика:
3.1. Из внутренней сети в DMZ
3.2. Из DMZ во внутреннюю сеть (не стоит, но вдруг зачем-то очень надо)
3.3. Из DMZ в интернет
3.4. Из интернета в DMZ

Таким образом, даже при взломе сервера, получении рута и отключения iptables на малине злодей не сможет вылезти оттуда куда попало, поскольку трафик режется на условно неуязвимом для него маршрутизаторе.