Ну, традиционное решение, когда конечное устройство лезет на сервер с белым IP адресом, поддерживает соединение и ждёт сообщений — продолжает оставаться хоть и тяжелым, но надежным вариантом, который работал всегда и везде, если ему сильно не мешать.
STUN/TURN сервисы тоже будут помогать, благо IP телефония за годы жизни уже накопила типовой набор костылей и протезов.
Для этого устройство должно самостоятельно инициировать сессию с сервером и поддерживать ее в жизнеспособном состоянии. Это, помимо прочего, доп затраты электроэнергии и расход аккумулятора.
Архитектура ip-телефонии не самая простая и ее приемы во многих приложениях сложно адаптировать.
Во многих сферах пионеры отрасли накопили такое количество технического долга, что исправлять сложно.
Все ведь в продакшн. Дернешь за ухо, нос отвалится.
Имхо, стоило бы использовать блокировку по url и доменным именам.
А блокировка по ip это как подкладывать гвозди на шоссе.
Рокеры на танках не заметят, а водителям с правами не понравится.
Один из методов: на NAT-устройствах искать и менять ip-адреса внутри ip-пакетов.
С учетом использования https вместо http 'и переход на NAT, это будет невозможно
поясните свое утверждение пожалуйста
в моей вселенной трансляция NAT происходит на сетевом уровне L3
И устройству, которое осуществляет NAT-трансляцию совершенно по барабану http или https использует приложение
На firewall-ах устройство смотрит не только на ip-заголовки, но и на уровни выше.
Эту возможность приспособили решать некоторые проблемы уровня приложений.
Один из костылей передавать свой ip-адрес на сервер внутри ip-пакетов для установки сессии со стороны сервера.
DPI аналогично.
Не увиливайте. Операторы для NAT не используют файрволы и DPI.
Вы утверждаете что при использовании NAT и протокола http все более менее работает
но при использовании NAT и протокола https все пропало
Проясните этот момент
Это может означать, что nat выполняется где-то централизованно.
И nat маршрутизатор, возможно, удален от пакетного ядра на несколько хопов.
Разбираться не стал.
Небольшой разбор полетов показал, что nat, похоже, выполнен до pe с внешним ip-адресом.
Для обычного пользователя эта информация обычно закрыта, т.к. раскрывает информацию о структуре сети оператора.
Это не мое утверждение. И суть описанной проблемы не в этом. :)
Я отвечу на вопрос. Только сначала уточните, пожалуйста, какие операторы не используют DPI?
По идее операторы используют dualsteck ipv4 и ipv6 в одном флаконе для массовых apn. Разрешение на dualsteck прописывается в HLR/HSS.
Сомневаюсь что тупо убрали ipv6. Возможно убрали ipv6 для конкретных сим или ваше оборудование перестало запрашивать ipv6 и запрашивает только ipv4. Cтоит все таки и свое железо проверить, прежде чем винить «нескольких» операторов.
А можно уточнить — какие именно операторы, и в какой стране?
Потому что у меня МТС, Россия, услуга IPv6 подключена, и глобальный v6-адрес никуда не делся.
А у остальных российских операторов, насколько мне известно — v6 в последние два года и не было.
Ранее ipv4-адреса раздавались внешние.
Что касается ipv6, обращал внимание, что ранее раздавались.
Не отслеживал специально, игрался с ssh на телефоне и, возможно случайно попал на какие-то профилактические работы.
Megafon. Нужен был ipv6 — тыкал их в их же новость, на их же сайте (двухгодичной где-то давности) о запуске поддержки протокола для клиентов. Долго техподдержка мычала, в конце концов признались что нету и неизвестно когда будет.
Когда почти каждое абонентское устройство жаждет интернета, а самих устройств под сотню миллионов (официально — вообще две с половиной) другого варианта просто нет. Ибо целая /8 сеть это всего-навсего шестнадцать миллионов адресов. А роскоши в виде /8 у ни у кого из наших операторов нет. Все гораздо-гораздо скромнее:
комментарии (43)