Комментарии 60
Суть в том, что иранские провайдеры и файрволы не могут эффективно блокировать трафик Starlink без непосредственной конфискации или отключения терминалов, так как спутники взаимодействуют с этими терминалами через зашифрованные проприетарные протоколы.
Эмм, и какая связь у шифрования спутник-терминал с невозможностью заблокировать без конфискации?
Канал старлинка провайдеру не подконтролен, даже для чтения, так что даже будь там plaintext для регулятора бы ничего не изменилось
Чет в этой переводной статье есть некоторая каша
Угу, немного непонятно
Как я понял, NIN у них работает всегда, но часто режут каналы наружу. Далее предлагается Матрикс, но есть же рабочие NIN-каналы? Ладно бы Матрикс давал связь наружу, но толку от него внутри страны? Разве что тайно осуждать правительство или содержать какой-нить сайтик с настоящими новостями?
Ctrl+H Иран > Россия. И можно публиковать второй раз
туннелируя TCP-трафик через поток запросов
ping. Это очень медленный способ
Это вполне нормальный способ, даже Youtube в HD позволяет смотреть. При недавних полных блокировках зарубежных ресурсов единственное, что работало — icmp-туннели.
Ну, не единственное... OpenVPN на своей VPS-ке уже года 3 как безотказно выручает нас в плане доступа до YouTube-чика. По крайней мере в Москве и МО.
У нас OpenVPN давным-давно порубили.
Ростелеком - не соединяется openvpn. То же с WireGuard. Пытается, но сразу рвется. На мобильных операторах вообще наглухо. Москва.
В Калининградской области всё, что заблокировано - действительно заблокировано. У нас тут всего 4 линка с внешним миром, если я не ошибаюсь, и все они управляются Ростелекомом.
Ограничения управляются ТСПУ, на которые провайдер повлиять не может, все вопросы в РКН.
В Калининградской области всё, что заблокировано - действительно заблокировано
У вас Польша и Литва рядом, вместе с их мобильными сетями. Неужели не дотянуться?
Дотянуться вполне возможно. Прошлым летом отдыхали на берегу Немана (граница с Литвой). Там нам постоянно приходили оповещения типа "Вы находитесь в зоне действия [условного] Лит-телекома, при желании можете подключиться". Естественно, мы всегда сбрасывали это предложение - зачем нам переплачивать за роуминг? Однажды не уследили, переключение каким-то образом произошло автоматически (возможно, из-за того, что мы вышли из зоны покрытия нашего опсоса - там с этим делом весьма нестабильно), и за один сеанс лесного интернета с телефонного счёта утекла 1000 рублей.
Как там на эту тему сейчас, можно ли подключиться, и допускают ли литовцы такое подключение - не знаю. Много дополнительных санкций было введено с тех пор. По идее, они должны нам помогать преодолеть тоталитарные барьеры - в качестве положительного примера вспомним КВ-вещание в брежневские времена (и его глушение). Однако на эту тему у них (впрочем, как и у украинцев) своеобразные представления на сей счёт, иногда идущие поперёк обычной логики.
Только у границы, да и не стоит оно того. Симку в том числе оплачивать надо, что не тривиально в нынешних условиях.
У нас возможность подключения к мобильной сети Польши или Литвы скорее как проблема рассматривается, когда телефон в международный роуминг сам уходит. в 2010х обычной практикой было отключать автоматический поиск и выбор сети.
Это если у Вас мелкий местечковый оператор, если оператор с крупной сетью, то ни wg ни ovpn не работают за пределы страны.
Ни у ростелеги, ни у экотелекома, ни у местного кварца эти два протокола не работают.
Я так понимаю, с 1 сентября за свой ВПН сервер на своей ВПСке будет положен штраф.
А как же SSH-туннели? Как по мне, это один из самых безопасных, и при этом примитивных методов проброски трафика на забугорные сервера.
Связь с интернетом сильно замедляется или пропадает полностью.
Сталкивался с подобным в РФ. В этом месяце (июль, 2025). Не единожды.
Что касается ICMP - вы самого главного не казали: того что ICMP - это не только PING. Этот протокол не только и не столько "используются для диагностики", его главная задача - контроль доступности узлов и межсетевых ограничений для обычных соединений. И если в UDP этот функционал используется только в рамках "Path MTU Discovery" и то опционально, то для TCP это гораздо более важно. Тут это нужно для контроля загрузки канала а некоторые реализации протокола TCP (congestion control алгоритмы но и не только) без этой информации являются неустойчивыми и через какое-то время при работе через такую "черную дыру" (когда узел просто кидает пакет в сеть и ждет от нее ответного сообщения ответного узла и надеется на лучшее, потому как никаких сведений о встретивших этот пакет на пути затруднениях и вообще о его маршруте у узла-отправителя нет) гарантированно происходит разрыв соединения (перед этим ваша система, разумеется, накидает в сеть как следует мусора, который в ней собственно в итоге и застрянет). И если полная блокировка ICMP в небольшой локальной сети просто приведет к повышению времени установления соединений, увеличению загрузки сети служебными пакетами, и как итог - к снижению эффективной пропускной способности сети, то полная блокировка же этого протокола в сети масштабов национального сегмента Интернета просто в течение нескольких минут наглухо положит весь этот сегмент и все.
Так что, если бы могли - не сомневайтесь, отрубили бы, может даже разок попробовали уже. Не от большой щедрости, заботы о ближнем и доброты у них эта дыра существует. Даже при полной и тотальной изоляции сети как минимум до IP-адресов из "белого списка" пропускать ICMP все равно прийдется (а уж на них то каким-нибудь админам по тихому развернуть несколько VPN "для своих" как раз и будет самое милое дело). Просто заткнуть эту дыру без радикального изменения архитектуры сети и перехода на альтернативные протоколы передачи данных при сохранении емкости сети практически невозможно. А с учетом того что мы даже на IPv6 уже сколько лет перейти никак не можем, не то что какие-то новые протоколы сетевого уровня разрабатывать и внедрять, ожидать тут каких-то изменений в ближайшем будущем не стоит. Поэтому дыры всегда были, есть, и будут. Как говорится, ищущий да обрящет :).
А какие именно реализации TCP используют ICMP для congestion control? Это будут какие-то совсем странные реализации, не совместимые ни с чем другим.
Ну если косвенно - тогда default-ная реализация в том же Linux например. Версия ядра 4.1, tcp_ipv4.c - при получении ICMP-сообщения от роутера о необходимости фрагментации (уменьшения MTU для снижения потери пакетов - тот же стандартный Path MTU Discovery только для TCP он уже обязательный), автоматически формируется SYN-пакет, при этом обновляются данные MTU для текущего алгоритма congestion control, и тут же перепосылается уже сразу ясно что потерянный (отброшенный маршрутизатором) пакет. Все индицируемые в рамках ICMP ошибки также в этом модуле обрабатываются. Это только то что я так сходу увидел. Уверен, есть и еще куча подвязок и на разных системах они разные.
То что TCP со временем в таких сетях жестко тормозит и стабильно периодически уходит в разрыв соединения - это просто было проверено экспериментально, на реальном контроллере при подключении к реальному Linux-серверу (у РЖД одна такая изолированная сеть есть). В общих четрах причины, конечно, понятны, но как в точности это происходит, поможет ли включение в конфиге ядра "TCP: advanced congestion control" и смена алгоритма CUBIC на что-то другое (на большей части узлов сети, разумеется), как это будет проявляться на других реализациях TCP, начиная с какого размера и загрузки сети это происходит гарантированно, какие особенности конфигурации сети могли бы на этот эффект повлиять, и как можно полностью воспроизвести этот эффект на маленькой стендовой сети - ответы на все эти вопросы я не выяснял и точных моделей не строил. Возможно, если хорошо погуглить, найдутся какие-то исследования на эту тему, но итогового практического вывода о необходимости оставлять ICMP как минимум внутри сети это в любом случае не меняет.
А насколько просто местному радиоконтролю засечь работающий терминал старлинка? Он же не только на приём работает, как спутниковая тв-тарелка, но и на передачу тоже. Понятное дело, что исходящий луч весьма узкий - но тем не менее у властей, когда им это действительно надо, вполне найдутся и оборудование нужное, и персонал квалифицированный.
Термин "узкий луч" очень и очень абстрактный и приблизительный...я как человек в далеком прошлом немного связан с радиолокацией могу смело заявлять что луч в виде узкой иглы не бывает в природе, и даже в виде бейсбольной биты (как часто его схематически рисуют) тоже не бывает.
Во первых форма диаграммы излучения эта штука очень абстрактная поскольку излучение всегда светит во все стороны, просто условно кудато лучше, кудато хуже, а поэтому см пункт 2
Всегда у всех антенн есть так называемые боковые липестки, у некоторых они широкие, у некоторых узкие но при этом "яркие", но они есть всегда и светят во все стороны.
Поэтому - да, найти радиопередающее устройство специалистам как два пальца об асфальт (даже если оно "светит" вверх...азимут, пеленг в течении нескольких минут. Главное иметь хороший приемник с высоким сигнал/шум.
Спасибо за ответ. Думаю, главное, что нужно иметь в таком случае - это желание найти "радиохулигана". Будет у властей желание - всё остальное найдётся за наносекунды. ;)
Можно брать переносной терминал, ехать в лес, качать что-то по быстрому и уезжать. По заветам прадедов!
Так-то да, но для начала надо вообще понять, что радиохулиган существует. Это можно определить либо по косвенным признакам (помехам в эфире), либо напрямую, если оборудование для сканирования эфира стоит повсюду и работает непрерывно - что, разумеется, возможно лишь местами, например, рядом со стратегическими объектами.
Наверное ещё и спектр излучения характерный, проще искать.
А там луч даже шире, чем у обычной тарелки. ФАР - на всю полусферу излучает.
В статье пропущен момент как эти иранские борцы с цензурой платят за Starlink.
По поводу SMS - шифрования SMS в сети SS7 и конкретно в стеке SIGTRAN, не существует в принципе. Как раз одна из главных проблем протоколов SS7 - полное отсутствие шифрования. (Речь о протоколах SCCP, TCAP, MAP, GSM SMS)
А по поводу надежности доставки - для SMS-центра нет никакой разницы, короткий текст у SMS или нет, длинная смс будет разбита на определннье количество частей в зависимости от кодировки и каждая часть будет доставлена получателю по отдельности. А повторные сценарии доставки SMS тем более гарантируют доставку SMS-сообщений
Заебали канал про технологии инновации.... Нехуй свои б свое военное а таблоиду технический
В старлинке есть GPS и умельцы давно придумали как его обойти чиповкой. Так что на границах территорий где старлинка нет, его в теории можно использовать.
Интересно, можно ссылку? GNSS в терминале используется не для применения ограничений напрямую, он используется для определения местоположения. И уже в соответствии с местоположением терминал получает свою карту/расписание спутников, для своей ячейки (около 15 миль). Спуфить gnss не особо сложно и для этого не нужно внедряться в железо терминала, но получив «неправильную карту» терминал все равно не сможет подключиться к спутникам
А на границе оно и так работает, если ты попадаешь в «ячейку», общую для тебя и соседней страны, где оно разрешено
Т.е. нужно чтобы тарелка передавала координаты страны где старлинк разрешён, но работала с «ячейкой» для фактического местоположения
Технический взгляд на отключения интернета в Иране