Комментарии 123
По этому поводу много статей на хабре. Причина понятна. В данном конкретном случае, я запршу безопасность о возможности внести этот сайт в исключения блок-системы.
Попробовал со своего мобильного устройства. Вышел без проблем.
По иронии судьбы, у меня с домашнего провайдера, достаточно долго был заблокирован habrahabr и geektimes. Я даже писал об этом администрации хабра. На мой запрос провайдер ответил, что в DNS-е есть их IP адреса. Не ограничивать доступ к ним доступ оснований нет. DPI-я по анализу SNI у них нет.
Возможность подключения абонентам фиксированной сети в данной статье не обсуждался. Я сделаю запрос в профильное подразделение и, по возможности, отвечу.
Статичный адрес (префикс /64) для мобильных абонентов пока тоже не доступен. Если мы поймем, что это востребовано, сделаем. Тут сложность в том, что абонентов со статическими IP (не важно v4 или v6) нужно «приземлять» в «домашем» регионе. В случае, если мы говорим про APN internet.mts.ru, то «приземление» осуществляется по кротчайшему маршруту (так проще и нам и лучше сервис абонентам) вне зависимости от того где реально находится абонент. Соответственно, мы можем говорить про услуги “Real IP” или корп. APN.
Попробуйте Dynamic DNS для этих целей. Я пользовался русским сервисом DNS Master для этого (он приятно недорогой), когда я жил в доме, где был провайдер с IPv6 и даже написал скрипт для поддержания актуальности DNS-записей: https://gist.github.com/Envek/9aa53b06e7df369626a9
У нас APN internet.mts.ru "приземляется" на ближайший узел. К примеру, если абонент переместился из Москвы в Ижевск, то точка приземления изменится с Москвы на Н.Новгород.
Корпоративные APN-ы (с префиксами msk, sib и др.) жестко "прибиты" к узлам в соответствующих регионах. При этом куда бы не перемещался абонент, его трафик будет затягиваться именно в этот регион. К примеру, абонент с APN-ом с префиксом sib переместился из Сибири на Дальний Восток. В этом случае трафик все равно будет дотягиваться до Новосибирска.
По поводу статики я скажу, что мы и корпоративных абонентов отговариваем себе ее включать. Это накладно и для абонента и для нас. В большинстве случаев, спасает корпоративный APN с приватными статическими адресами.
С учетом того, что у нас 99% трафика APN internet.mts.ru "приземляется" на ближайший узел, проблем с пробросом трафика "префиксованных" APN-ов по месту их приписки нет. Да, задержка Москва — Владивосток 110ms — 120ms, но с этим ничего не поделаешь...
Мы планируем завершить настройки для APN internet.mts.ru, а чуть позже распространить на услугу "Real IP" (на этих APN-ах будет выдаваться динамические public IPv4 и public IPv6 адреса).
Public IPv4 адреса в последнее время покупаются на "свободном рынке" и за живые деньги. Закупочные процедуры в больших компаниях не простые и довольно длительные. Один IP адрес в NAT-пуле используется значительно эффективнее. А если кратко, то "Да, мы экономим IPv4 адреса".
Как тут уже было предложено, можно использовать DynDNS.
по поводу опроса… ну я бы не был так радикален в ответе НЕТ. Учитывая кучи легаси оборудования безовсяких файрволлов, светить им в мир тоже не айс.
Может имеет смысл таки включить блок по умолчанию с галочкой в личном кабинете "отключить фильтрацию"? Для тех, кто понимает что делает.
Эту позицию я услышал. Спасибо!
Скажем, на современном и продвинутом портативном LTE-роутере Netgear 810s по умолчанию включен adbd (ADB-сервер Android) на порту 5555, который доступен из WAN, без пароля и подтверждений со стороны пользователя. Подключившись к этому серверу, вы получаете shell-доступ от имени root на устройстве — большая дыра безопасности.
Я за то, чтобы ограничивать все новые входящие соединения для клиентов по умолчанию, с возможностью отключения этой функции. Или, не знаю, какой-нибудь upnp/NAT-PMP можно установить в сеть.
Я надеюсь, все понимают, что даже в случае "НЕТ" такие порты, как 135-139 и 445 все равно должны быть закрыты в обе стороны?
Тут я бы сказал и «да» и «нет». На основном APN internet.mts.ru у нас закрыт доступ с приватного ip на приватный. Отчасти, это было сделано потому, что были случаи когда абоненты «шарились» по открытым «шарам» windows машин. Чего там только не встречалось (от проектов сайтов, до бухгалтерских документов)… В случае с приватным IPv4 закрыли и ладно. Никто сильно не пострадал. IPv6 изначально паблик адреса и формальной причины закрывать к ним доступ у нас нет. Они должны быть доступны из интернет. Если общественность за закрыте, не вопрос — закроем. Именно то этой причина и был организован опрос.
Если общественность за закрыте, не вопрос — закроем.
Ну, вообще-то общественность о этом говорит с 2003 года.
Netbios порты windows уязвимы уже больше 20 лет, с момента своего появления в windows 9x и остаются уязвимы по текущий день.
Эти порты использовались для распространения WannaCry.
И эти порты — первое, что закрывают все провайдеры, точки обмена трафика и магистральные операторы, которые хоть как-то хотят защититься от ботнетов в сетях клиентов.
Я рекомендую посмотреть статьи про эти порты, самая частая рекомендация — просто закрывать их.
И если этого вам будет недостаточно, вы можете создать опрос "закрыть ли netbios порты клиентов или оставить открытыми миру".
Я думаю, общественность хабра недвусмысленно подскажет правильный ответ :)
Да, я услышал. Завтра обсужу это с "коллегами по цеху".
Почему тогда не закрыть, например, порт 161 или 23?
Почему тогда не закрыть, например, порт 161 или 23?
Им очень далеко до netbios по величине уже нанесенного урона.
Просто на одного крутого эксперта — вас, есть тысячи обычных win пользователей, которые три месяца назад пострадали (в том числе финансово) от WannaCry, просто потому, что у них были открыт порт 445.
Вредоносная программа сканирует в Интернете узлы в поисках компьютеров с открытым TCP-портом 445, который отвечает за обслуживание протокола SMBv1. Обнаружив такой компьютер, программа предпринимает несколько попыток проэксплуатировать на нём уязвимость EternalBlue и, в случае успеха, устанавливает бэкдор DoublePulsar, через который загружается и запускается исполняемый код программы WannaCry.
А насчет CIFS я согласен.
Правда, вот critical уязвимость 2 месячной давности и в ней.
Если у вас ещё есть открытая самба, рекомендую проверить, вдруг она уязвима.
В итоге:
1. широковещалки в сети становилось меньше (знаю, знаю, сейчас оборудование режет его за портом юзера, но всё же)
2. комп работал быстрее
3. безопасность лучше
А если закрыть все порты, то лишите народ торрента. Сейчас и так мало кто пробрасывает порт.
Пусть лучше юзер сам решает свои проблемы. Если он попросит IPv6, значит и подумать ему заранее как оно будет работать так же нужно.
А на этих портах по IPv6 что нибудь есть? Поскольку это другой протокол программы и драйвера отдельно открывают порт для ipv4 и ipv6. А скорей всего для ipv6 вообще не открывают если специально не настроить.
Уже 8-й год, как минимум, слышу эти прохладные истории про IPv6. А воз и ныне там.
Мы стараемся сдвинуть воз. Надеемся на конструктивное содействие.
3 из 9 российских домашних проводных провайдеров, опрошенных мной, поддерживают IPv6.
Мобильный оператор T-Mobile в США раздает клиентам (не всем, но многим) доступ только в IPv6 с 2014 года. Доступ в IPv4 осуществляется через протокол 464XLAT.
Стоит ли ждать абонентам домашнего проводного интернета от МТС такое благо?
«Внимание! IPv6 работает, но большие пакеты, видимо, теряются. Это даже может выглядеть так, как будто сайт сломан......»
Итого 1/10 тестов пройдено.
Есть еще одна неучтенная деталь — маршрутизация ipv6 требует больше ресурсов маршрутизатора.
+1
Да, CGNAT масштаба мобильного оператора — весьма затратная штука. Тут даже дело не столько в количестве белых адресов… Основное отличие мобильного оператора от фиксированного в том, что при сравнимом количестве трафика, мобильный оператор одновременно обслуживает бОльшее количество абонентов (сетевых устройств). Они создают бОльшую нагрузку на NAT (количество одновременных трансляций) и DNS (количество запросов на различные (ключевое слово)) ресурсов.
Доля трафика IPv6 пока крайне мала. В настоящий момент проблем с этим не вижу.
Куда бОльшую нагрузку создают технические средства блокировки по спискам РКН.
А новость — отличная. Не знаю, каков ваш опыт, сколько мобильных телефонов у народа на руках со сломанных IPv6-стеком, и каково поведение устройств, если вдруг на вашей стороне IPv6 перестанет работать (как скоро трафик попробует пробраться через IPv4, если вообще попробует), но я очень рад, что всего через 11 лет с момента изобретения IPv6 его начинают более-менее массово внедрять в крупных сетях. Еще бы Билайны с Мегой подтянулись, там, глядишь, и IPv6-адреса на стороне сервисов окажутся более востребованными.
Но, пожалуйста, как-то поменяйте текст, уж очень глаз режет выражение «услуга IPv6»! Прямо как «услуга воздух для дыхания»!
Прошу прощение. Я тоже был против такого названия, но, к сожалению, она называется как называется…
По поводу того, что пока это именно услуга я писал как раз в части того, что если что-то перестанет работать, то услугу можно отключить и вернуть все как было. На самом деле я изначально выступал и по-прежнему выступаю за то, чтобы это не было услугой и включалось бы только в настройках телефона. В этой битве с маркетингом я пока проиграл, но надежду, естественно, не потерял. Просто, как мы все знаем, разные производители устройств и ОС к ним, дают разные возможности "ручной" настройки. Сравните настройки точек доступа в Android и в iOS. Так вот в последней крайне мало вариантов что-то руками "подкрутить", а возможностей со стороны оператора выслать правильные настройки тоже крайне скудны. А во времена, когда большинство телефонов поддерживало настройки "по воздуху", большая часть абонентов не соглашалась получить и применить настройки.
Всего через 21 год ведь :) Написал и взгрустнул...
Москва, Ярославль, Тверь, Кострома, Калуга, Смоленск, Рязань, Тамбов, Тула, Владимир, Иваново, Липецк, Орел, Курск, Воронеж, Брянск, Белгород.
Во всех регионах, кроме регионов Дальнего Востока, целевой срок запуска — август (повторюсь, что прошу не сильно "бить" если не чуток задержимся). Вся техника готова (завершаем тесты).
Дальний Восток начнем делать осенью этого года.
Услуга будет доступна всем абонентам.
Привет!
г. Вологда.
Спасибо, жду с нетерпением :).
Тест IPv6 показывает 9/10 из за отсутствия реверс DNS.
Из не оправданных ожиданий — android(strongswan) не умеет создавать IPSec поверх IPv6 из за ограничений не привелегированного пользователя на доступ к интерфейсу ядра.
Есть у меня ещё вопрос, а умеет ли «сеть» посылать какие-либо сигналы клиенту если для него есть входящий трафик, для того чтобы клиентский телефон включился и получил его (где-то я раньше про это читал, но очень давно)? Дело в том что например когда открываешь машину с брелка на телефон прямо в тот же момент прилетает уведомление от сигнализации (не смс). Если запустить ping6 на адрес телефона то пока его кнопкой не включишь он пинговаться не начинает. Это не зависит от того как долго он лежал без пробуждения. «Жёра» батарейки при этом нет. Тело — Xiaomi Mi5s, сеть в режиме LTE. То же самое с Hangout — сообщения приходят сразу.
Тест IPv6 показывает 9/10 из за отсутствия реверс DNS.Покажите, пожалуйста, скриншот теста.
Есть у меня ещё вопрос, а умеет ли «сеть» посылать какие-либо сигналы клиенту если для него есть входящий трафик, для того чтобы клиентский телефон включился и получил егоЕсли для абонентского устройства, которое находится в сети и имеет IP адрес, получен IP трафик то со стороны сети инициируется процедура paging. Если устройство отвечает на paging, то трафик доставляется.
Если запустить ping6 на адрес телефона то пока его кнопкой не включишь он пинговаться не начинает.Я это потестирую на Samsung-е и посмотрю на трассировки с оборудования.
Если уж хочется попробовать, то элементарно поднять бесплатный тунель 6in4 от тех же HE или прокинув socks5 на какой-нибудь VPS.
Да, трафик будет ходить через какой-нибудь Стокгольм (для кого-то это плюс =), зато без подключения бесплатных услуг.
Хотя нормальный v6 хочется давно и везде, но провайдеры чешутся медленно.
HE давно уже посылают в лес пинать своего провайдера включить IPv6 и новые регистрации не принимают. :sad_trombone:
Попробуйте уменьшить MTU.
Как установить 6to4?
…
После применения сгенерированных настроек, проверьте, чему равен MTU созданного 6to4-интерфейса. В силу расходов на инкапсуляцию IPv6-пакета в IPv4, MTU должен быть на 20 байт меньше, чем MTU находящегося уровнем ниже IPv4-интерфейса.
Если заглянуть чуть глубже, можно сказать, что 3GPP Rel10 описывает технологию DHCPv6 Prefix Delegation (DHCPv6-PD). Сейчас необходимость ее использования в мобильной сети неочевидна. Если есть конкретные предложения — пишите в комментариях или в личку.Раздавать пользователям префикс меньше /64, например, /56. RFC 6177 настоятельно рекомендует выдавать от /48 до /56 конечному клиенту.
МТС продает стационарные LTE-роутеры, что подразумевает использование мобильного интернета в качестве основного канала дома или в офисе. Для полноценного использования, даже домашнего, вполне может потребоваться 3 /64-подсети для корректной настройки: одна для проводного интернета, вторая для гостевой сети Wi-Fi, третья для VPN. Продвинутый пользователь может выделить отдельную /64 в качестве подсети для виртуальных машин, например.
Даже для раздачи интернета по Wi-Fi с телефона может использоваться отдельная /64.
Статичный адрес (префикс /64) для мобильных абонентов пока тоже не доступен. Если мы поймем, что это востребовано, сделаем. Тут сложность в том, что абонентов со статическими IP (не важно v4 или v6) нужно «приземлять» в «домашем» регионе. В случае, если мы говорим про APN internet.mts.ru, то «приземление» осуществляется по кротчайшему маршруту (так проще и нам и лучше сервис абонентам) вне зависимости от того где реально находится абонент. Соответственно, мы можем говорить про услуги “Real IP” или корп. APN.Посмотрите в сторону Mobile IPv6. Я до конца не разбирался, как он работает, но мне кажется, что он сделан именно для этого, и позволит вам корректно «приземлять» статические подсети, не гоняя трафик в другой регион.
Пожалуйста, не раздавайте клиентам только одну /64. Вы большие молодцы, что занялись вредрением IPv6 первыми, но хочется, чтобы все было по уму, а не тяп-ляп. Я готов помогать вам советами и тестами, если они вам нужны: у меня есть Android-телефон, на который можно установить почти любую версию ОС (от 2.3.5 до 6.1), есть Blackberry, есть несколько LTE-модемов и роутеров разных производителей.
Пожалуйста, добавьте пост в хаб IPv6.
Вот это я понимаю: конкурентное преимущество одного оператора перед другим.
P.S> Включайте ещё IPv6 для домашнего интернета и подключайте мой дом. Пожалуйста!
Хочу вам перенести некоторые цитаты-вопросы из той темы, если можно
тестировали ipv6 от мтс и натив в дц, трафик в минск пошел через he немецкий на минск
Проблема заключается в том, что многие SOHO устройства поддерживают IPv6 для галочки. Шаг влево или вправо — не работает. Да и у самого МТС бывают проблемы в зависимости от области подключения
если вставить кабель мтс в сетевую карту компа, в свойствах сетевухи отключить ипв4, то никаково ипв6 я не получаю
P.S Так же у нас есть один Ethernet провайдер, который продаёт пользователям локальные дополнительные IP адреса вида 10… по цене 0,3 $ в месяц.
Я не понял первое предложение. Если речь идет про IPv4v6 на iOS, то скажу, что мы работаем с Apple. Поддержка IPv4v6 (и не только) включается так называемым Carrier Bundle, который вшивается в прошивку. Перед тем, как CB появляется в новом релизе ПО, производится его тестирование и оператором и самим Apple. Повторюсь, что мы работаем над этим.
Когда в Удмуртии можно ждать? Конкретно Ижевск интересует.
Постараемся запуститься в августе. Не "бейте" сильно если чуток задержимся.
Просто всё ещё не наблюдаю в доступных услугах ничего связанного с IPv6.
Техника на всей территории кроме Дальнего Востока и «города-спутника» Норильск настроена. Абоненты Москвы и соседних областей уже не должны «терять» IPv6 адрес при перемещении по бОльшей части страны. Август оказался крайне непродуктивным месяцем для работ. Нам осталось добить бумажно-административные формальности.
Если поставить исключительно IPv6 — сайт даже не открывается. :)
Если запрошен IPv6 only, то сеть выдает только IPv6 DNS.
Выдавать IPv4 DNS абоненту у которого нет IPv4 адреса смысла нет.
адрес IPv6 доступен снаружи, проверял запуском веб-сервера.
Я перед тем как написать предыдущий пост, специально проверил. Вот выдержка из сигнального обмена.
Адресную часть я подзатер, чтобы не было лишних соблазнов...
[PGW-S5/S2a/S2b]GTPv2C Tx PDU, from 213.87.xx.xx:2123 to 213.87.xx.xx:30512 (135)
TEID: 0x81900020, Message type: EGTP_CREATE_SESSION_RESPONSE (0x21)
Sequence Number: 0x4EA420 (5154336)
GTP HEADER
Version number: 2
TEID flag: Present
Piggybacking flag: Not present
Message Length: 0x0083 (131)
INFORMATION ELEMENTS
CAUSE:
Value:
Cause: EGTP_CAUSE_REQ_ACCEPTED (0x10)
PCE: 0
BCE: 0
CS: 0
PGW-CONTROL FTEID:
Value:
Interface: PGW S5/S8-C
IPv4 Flag: 1
IPv6 Flag: 0
Teid: 0x83242121
IPV4 Addr: 213.87.xx.xx
PDN ADDRESS ALLOC:
Value:
PDN Type: IPV6
IPV6 Addr: 2a00:1fa0:4680:bbbb:cccc:dddd:eeee:ffff
APN RESTRICTION:
Value: 0
AGGREGATE MAX BIT RATE:
Value:
Uplk AMBR: 314573 kbps
Dnlk AMBR: 314573 kbps
PCO:
Container id: 0x0003 (IPv6-DNS-Server)
Container length: 0x10 (16)
Container content:
IPv6 DNS Address: 2a02:28:2:3::116
Container id: 0x0010 (Link MTU)
Container length: 0x02 (2)
Container content:
Link MTU: 1500
BEARER CONTEXT CREATED:
Value:
EPS BEARER ID:
Value: 5
CAUSE:
Value:
Cause: EGTP_CAUSE_REQ_ACCEPTED (0x10)
PCE: 0
BCE: 0
CS: 0
PGW-DATA FTEID:
Value:
Interface: PGW S5/S8-U
IPv4 Flag: 1
IPv6 Flag: 0
Teid: 0x814DC1221
IPV4 Addr: 213.87.xx.xx
CHARGING ID:
Value: 0x0A5489FE
В телефоне, обычно, можно настроить DNS сервера руками.
Разумно будет блокировать по-умолчанию, чтобы оградить рядовых пользователей, которым это и не нужно, но предоставить возможность убрать эту меру защиты по инициативе пользователя. Если есть, конечно, такая техническая возможность.
Хотелось бы проверить IPv6 на МТС не в Москве. Как это возможно устроить?
Сегодня день запуска IPv6 на бОльшей части страны. Если возникнут проблемы — пишите в личку и я постараюсь помочь.
Прошу прощение за задержку. Техника действительно была готова в середине августа.
Дальний Восток делаем. Уже боюсь что-то обещать, но у меня цель доделать все регионы до конца этого года.
И правильно ли я понял, что раз по v6 идем мимо NAT, то можно с устройства, по принципу DDNS, слать свой адрес и общаться в обе стороны без статики?
Для IPv6 естественно, никакой NAT не используется. Каждое устройство, подключаемое к сети, получает префикс /64. Устройства, которые подключатся уже за модемом/смартфоном, получают также прямые IPv6 адреса все из того же префикса /64, что и основное устройство и тоже доступны из интернет по прямому адресу.
В следующем году мы планируем сделать prefix-delegation. Это означает, что роутерам будем выдавать дополнительный префикс /56.
Почему нельзя привязывать статику к v6, что бы клиентам не говорили «не дадим, закончились»?
Большое спасибо за ответ, попробую пойти этим путем.
У нас есть услуга, в рамках которой мы делаем отдельный APN и дотаскиваем транспорт (можно и VPN-ом) до сети клиента. В этом случае только SIM карты клиента получают доступ в эту сеть и можно каждому устройству сделать статичный адрес. Причём тут есть две опции. Первая — адрес выставляется у нас (HLR/HSS). Вторя — адрес запрашивается у radius-сервера клиента.
Статический IPv6 адрес мы пока тоже не делаем. Если почувствуем заинтересованность/востребованность этой опции, то рассмотрим и такую возможность.
Может быть вам хватит Dynamic DNS?
Я для этих целей специально менял DNS-провайдера для своего домена, выдавал каждому ноутбуку по поддомену и писал вот такой скрипт: https://gist.github.com/Envek/9aa53b06e7df369626a9
Если префикс не меняется то нужно просто отключить получение временных ipv6.
netsh interface ipv6 set global randomizeidentifiers=disabled
netsh interface ipv6 set privacy state=disabled
На самом телефоне IPv6 живет отлично (как в dualstack, так и в IPv6-only). Естественно по bluetooth/WiFi не раздается. Непорядок. Раз дают /64, буду искать решение не тревожа оператора. Но и от добрых советов в личку тоже не откажусь.
Вообщем резюме следующее: китайский Meizu с русифицированной прошивкой 5.1.5.0G (как они накатили G на device id 68101003 — непонятно. Видимо руками из образа) раздавать IPv6 через WiFi не умеет. Лечится либо прошивкой штатной китайской версии 6.1.0.0A (ничего не убьете), либо заменой device ID (лучше не делать, если нет опыта! Можно убить аппарат) и нормальной прошивкой международной версии 6.1.0.0G.
Оба варианта проверил, работают отлично.
Когда IP-адресов будет хватать всем?