All streams
Search
Write a publication
Pull to refresh
0
0

User

Send message
Как раз СОРМ решает эту проблему, поскольку позволяет органам прослушивать «серый» трафик.
В условиях отсутствия СОРМ единственный способ понять, кто набедокурил — «вычислять по айпи»…
Подозреваю, что тут дело в другом — когда все абоненты сидят за одним огромным NAT, затруднительно определить по заявке из органов, кто выходил с конкретного IPv4 адреса «в ночь с пятницы на понедельник» ©.
Но вся эта лафа быстро закончится, когда закончатся IPv4 адреса.

Повторюсь — это гипотеза. Я не знаком с реалиями украинского телекома. Просто провожу параллели с нашими российскими реалиями.

Данный вопрос я решил просто: каждому абоненту-физлицу даётся блок IPv4 адресов, который NATится в некий реальный.
В силу нехватки IPv4 адресов, физлица группируются на этих NAT.
В данный момент они у меня группируются по двое. Далее будут по трое, четверо и т.д.
Органы это устраивает — найти конкретного из 2-3-4 человек всё равно весьма несложно.
Порт QinQ коммутатора может работать в двух режимах — NNI и UNI.
NNI — это традиционный режим. Прилетели 32 влана и коммутатор их понимает как 32 разных влана.
UNI — это режим свёртки в QinQ. В этом режиме коммутатор перестаёт обращать внимания на vlan-теги в пакетах, а вместо этого на абсолютно все приходящие пакеты, без разбору, вешает указанный vlan-тег «поверх».
Соответственно, на порту агрегирующего коммутатора, который смотрит на наш коммутатор доступа, мы включаем UNI. 32 влана сворачиваются в один влан, который улетает в ядро.
В итоге, в ядре мы имеем один влан на весь указанный доступ, пакеты в котором имеют двойной тег: снаружи тег, которым их обернул агрегирующий коммутатор, а внутри тег какого-то из 32 вланов.

Всё это прилетает на роутер в ядре, в котором созданы интерфейсы — по интерфейсу на абонента.
У всех интерфейсов указаны оба vlan-тега — внешний и внутренний.
На Juniper это прямо так и пишется в явном виде в свойствах интерфейса — например,

vlan-tags outer 3 inner 121;

На PC-роутерах же, просто создаются вложенные vlan-интерфейсы — сначала «внешний», цепляемый к физическому интерфейсу, а потом 32 «внутренних», цепляемых к «внешнему» — например,

ifconfig vlan3 create vlan 3 vlandev em0 up
ifconfig vlan121 create vlan 121 vlandev vlan3 up
1. Использование NAT решает проблему провайдеров.
Провайдеры-то да — они могут преспокойно упаковывать абонентов за NAT всё плотнее и плотнее ещё десятки лет.

А вот для датацентров, нехватка IPv4-адресов — это полный абзац.
Сервер или виртуалочку абонента за NAT не засунешь, они должны быть высунуты в интернет.
Датацентры уже начали взвинчивать цены на IPv4-адреса, надеясь «отжать» их у тех, кто берёт более чем один адрес на сервер. Допустим, они преуспеют, и практически у всех серверов будет не более чем один адрес.
Потом они вычерпают весь «чёрный рынок» IPv4.
А дальше — всё, приехали.
Можно и без QinQ, но тогда будет лимит в четыре тысячи абонентов. В случае QinQ, теоретический предел порядка 16 миллионов.

vlan на пользователя имеет массу преимуществ:

— во-первых, как я написал выше, можно вводить IPv6 даже на самых старых свичах. Например, у меня в сети в нескольких местах трудятся D-Link DES-3226, которые датируются чуть ли не 2001 годом. Несмотря на столь почтенный возраст, они прекрасно работают по сей день. Им без разницы, что пропускать — IPv4 ли, IPv6 ли…
Конечно, для них нет плат с поддержкой wdm sfp модулей, но «вторым» свичом на доступе, будучи присоединённым к «первому» свичу медным гигабитом, они работают прекрасно.

— при предоставлении IPv6, можно выделять независимую /64 подсеть каждому абоненту, вместо «общеколхозной».
Это резко упрощает идентификацию абонента по адресу, ведение базы и администрирование адресного пространства в целом.

— практически исчезает необходимость в пользовательском роутере.
Абонент может воткнуть неуправляемый свич и кучу устройств в него, все они автоматом получат адреса (что v6, что серые v4) по DHCP — благодаря тому, что отсутствует необходимость в идентификации адресов и защитной привязке адресов к порту, лимит на их количество практически исчезает.
А это не только экономия денег, но ещё и экономия на поддержке — не нужно разбираться, проблема с сетью или с абонентским роутером, не нужно гонять сотрудника к абоненту, чтобы настраивать роутер, или полчаса пытаться объяснять абоненту, как его настроить самостоятельно (в итоге плюнув и выслав сотрудника).
Да и абонент при проблемах с роутером склонен пенять на провайдера.

— полная изоляция абонентов друг от друга.
Абонент не имеет даже теоретической возможности «нагадить» соседу. Ни намеренно, ни сдуру.
Абоненты не связаны между собой — по сути, они всё равно что подключены к разным провайдерам. Могут достучаться до друг друга только «через интернет».

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

— нет нужды в разного рода «привязках», которыми страдают некоторые провайдеры. Просто воткнул и работает, никаких звонков «у меня сменился mac-адрес».

— можно регулировать локалку.
Фильтровать вирусный трафик, разного рода попытки сканирования соседей.
Можно предотвратить ситуацию типа «добрый юзер купил 100-мегабитный тариф и открыл прокси на весь дом» — халявщикам с младшими тарифами локалку можно зашейпить, и у них не будет смысла сидеть на прокси.

В общем, по сути палочка-выручалочка. Одни плюсы.
Минус только один — нужны управляемые свичи с вланами.
Интересно, они от соседей тоже требуют убирать точки доступа?
И как далеко их посылают соседи? =)
Использую шифрование всех дисков и на ноуте, и на десктопе.
Снижения производительности нет вообще, в том числе на очень быстром SSD.
Процессор при активной работе с диском загружен очень сильно, это да — но безопасность данных важнее, да и активная работа с диском бывает не особо-то и часто.
Всё не так печально. Для оператора связи есть простая схема — называется vlan per customer.
При этом на доступе можно использовать даже самые дряхлые управляемые коммутаторы, от которых не требуется вообще знать, что такое IPv6 — управлять ими можно и по IPv4.

На агрегации нужна железка посвежее, умеющая «влан во влане», но и это не проблема — они сейчас дешёвые. Например, DGS-3120-24SC.

Пока полоса не превышает 5-10 гигабит — в ядре вполне справятся обычные PC-роутеры, при нехватке одного роутера трафик можно разбросать по роутерам. При полосе более 10 гигабит становится оправданной покупка, например, младшего Juniper MX, который позволяет терминировать, если мне не изменяет память, до 32 тысяч вланов.

В итоге абонент получает автоконфигурацию по DHCP+RA и у него всё работает.
IPv6 — стандартная подсеть /64, IPv4 — например, серая подсеть /28.

Теперь про абонентское железо — опять же, есть одно очень простое решение: абонентский вайфай можно перевести в режим моста. Либо отключить на нём DHCP и воткнуть провайдерский кабель в LAN. И с этого момента уже неважно, что старая абонентская железка ничего не знает про IPv6 — всё будет работать и так.

Если абоненту не требуется вайфай — то роутер не нужен вообще, никакой, достаточно неуправляемого свича за 300руб.
«Очень удобный Cisco-like CLI» — оксюморон.
Cisco CLI — птичий язык. Особенно после работы с JunOS.
И мощность ~400mW против ~1W, для дачи уже не столь интересно.

А для городской квартиры идеальный вариант — Nanostation M2.
Устанавливается в «дальнем углу» таким образом, чтобы луч (60х20 градусов, насколько я помню) покрывал всю квартиру и уходил через наружную стену.
В результате убиваем двух зайцев — и гораздо меньше мешаем соседям, и меньше ловим шума, прилетающего от соседских вайфаев.
Всем, кто жалуется на «плохой вайфай», я ставлю NanoM2, опять же с неизменно превосходным результатом.
PowerAP N — великолепное решение для дачи. Неоднократно советовал знакомым с неизменно превосходным результатом — покрывает все этажи, подвал, и весь участок. Очень жаль, что они сняты с производства — я себе даже 2шт купил на всякий случай…
Мощнее в десять раз. Частоты — стандартный WiFi 802.11n 2.4GHz.
Интересно, а каким образом МТС предполагает делать автопополнение одной картой более чем одного номера?
Например, я и мои родственники?
Это без следствия решается — опротестованием транзакции через банк.
Я не продавец. Цена указана розничная, в качестве иллюстрации альтернативы микротику.

А строгость закона у нас, как известно, компенсируется необязательностью его исполнения.
Полукомплект Ubiquiti Nanobridge M5 стоит 3500р. Даёт 150 Мбит/с полудуплекс на дистанциях до 10-15км.
Полоса от 5 до 40 МГц (150 Мбит/с будет при 40 МГц), выбирается в интервале 4900-6200 МГц.

Также есть M2 — диапазон 2300-2700 МГц, полоса та же.
Да, тогда вопрос снимается.
Правда, появляется большое неудобство — оплата «наугад» в среднем с 2 попыток…
В роуминге — платные =)
Я оплачиваю кредиткой с сайта оператора. Чем здесь поможет API?
Палка о двух концах…
Теперь банальное пополнение счёта человека, до которого не можешь дозвониться, превратится в лотерею.
Потеряют смысл тарифы «безлимит по сети оператора» — заранее не поймёшь, будет звонок безлимитным или нет.

Information

Rating
Does not participate
Registered
Activity