Проблема IPoE

В последнее время очень популярна стала технология IPoE. Популярна настолько, что некоторые провайдеры решились внедрить её в существующую сеть. И ведь действительно, на первый взгляд сплошные плюсы.

Приведу несколько плюсов на вскидку: в отличии, от PPPoE, не нужен дорогостоящий BRAS, не нужно тратиться на подсети внешних адресов, меньшая нагрузка на оборудование, за счет отсутствия тоннелей, нет необходимости гонять внутренний трафик через BRAS. Плюсов можно найти кучу, но, почему-то, мало кто задумался о минусах. На данную технологию даже нет RFC, не говоря уже о том, что многое дешевое оборудование, использующееся на доступе, не всегда корректно работает с options 82.
Самый главный минус, на мой взгляд – безопасность конечных пользователей.

Рассмотрим для примера metro ethernet сеть, в которой услуга предоставляется по технологии PPPoE (рис.1).

image
рис.1

В данной схеме используется технология Q-in-Q. Если говорить грубо – виллан в виллане. На кольцо доступа выделяется один vlan для PPPoE. На коммутаторах в кольце доступа, куда включаются непосредственно абоненты, номера vlan'ов идет в зависимости от места коммутатора в кольце доступа и порта. Например:
  • первый коммутатор 1 порт – vlan 101, 2 порт – vlan – 102;
  • второй коммутатор 1 порт – vlan 201, 2 порт – vlan – 202.


Далее, на L3 коммутаторе агрегации, это собирается в C-Vlan вида 33290101, 33290102 итд.
В таком виде, это отправляется к BRAS. Причем, оборудование, которое стоит на канале между BRAS и роутером в кольце агрегации может и не поддерживать Q-in-Q.
При такой схеме, у каждого пользователя есть свой логин/пароль. И, даже если его украдет злоумышленник, то использовать он его сможет только с порта абонента. Если включится в другой порт, логин/пароль будет бесполезен.

Теперь, рассмотрим ситуацию, Когда пришел начальник Ибрагим Аврамович и сказал – я хочу IPoE (рис.2).

image
рис.2

Сказано – сделано. Вы перетрясли всю сеть. Сделали IPoE. В наиболее распространенном варианте, привязка будет идти к порту и маку коммутатора доступа. Завязали ваш dhcp сервер с биллингом, причем, вся завязка состоит в том, что биллинг отправляет куски конфига на dhcp сервер.
Поставили NAT! Теперь можно давать хомячкам серые адреса и натить, экономия же! Ибрагим Аврамович доволен, но замечает, что можно выдавать и белые адреса особо ретивым пользователям, за отдельную плату конечно.
Q-in-Q вы решили оставить, чтобы хоть как-то разделить пользователей.
Вы все сделали – вы молодец. От пользователей теперь не требуется вбивать логин и пароль, тех. поддержка забыла про ошибки 691. Ибрагим Аврамович выбирает новый Лексус. Вам дали прtмию 2048 рублей. Все счастливы.

Казалось бы, что может нарушить данную стройную идиллию? А нарушить её может схема, изображенная на рисунке 3.

image
рис.3

Давайте посмотрим на неё внимательнее. Тетя Глаша из квартиры №1 честно платит за интернет. Для наглядности, у тети Глаши будет серый адрес. А её сосед – кулцхакер Василий, за интернет платить не хочет. Идёт в ближайший магазин и покупает:
  • мыльницу-роутер (а-ля dir-100);
  • несколько метров витой пары;
  • обжимку, пару конекторов.


Пока, тетя Глаша и прочие жильцы на работе, Василий нагло врезается в кабель тети Глаши. Проводит кабель к себе домой. По 1,2,3,6 жиле, он будет сосать халявный интернет, а по оставшимся, он подключит тётю Глашу (что называется – по обратке), чтобы она ничего не заподозрила и не вызвала монтажника. Так как, никаких логин/паролей нет. Ничто не помешает Василию получить свой бесплатный интернет. А далее – дело техники. На роутере поднимается dhcp и NAT. Причем, при желании ip тете Глаше можно выдать из той же подсети, что использует провайдер, чтобы свести подозрения к минимуму. В случае, если серые ip выдаются не из пула, а существует жесткая привязка ip к порту, все ещё проще.

И так, Вася получил халявный интернет. Тетя Глаша ничего не заметила, только стала удивляться столь частым взломам любимых однакласников и – «картинкидолгогрузятся».

Послесловие:
Согласен, что некоторые делают ещё и привязку к mac адресу абонента. Но, господа, вы создаете себе геморрой. А если у хомячка нет локалки/роутера, а компьютера два, три итд? А если сгорела сетевая? Каждый раз звонить в тех/ поддержку и диктовать mac. И хорошо, если хомячек не впадет в панику, при слове mac. К тому же, Васе mac узнать не составляет труда, а подменить ещё проще.

К вопросу о СОРМЕ и кровавой Гэбне. Что мешает потомственному ваххабиту Ашоту прийти в любой подъезд, скрутить кабель, написать похабщины в интернете /накачать торрентов и скрыться не пойманным? Здесь не будет стопорных механизмов публичных wi-fi сетей.

На какое-то серьёзное исследование по безопасности естественно не претендую, но, на мой взгляд, есть повод задуматься.
Share post

Comments 82

    +13
    против лома нет приема.
    можно врезаться между абонентом и PPPoE сервером, сделать свой сервер PPPoE и подслушать логин/пароль: habrahabr.ru/post/158781/

      0
      PPTP + MSCHAPv2

      Конечно его тоже уже поломали, но не каждый хакер Вася имеет FPGA-based box, чтобы “crack any MS-CHAPv2 handshake in less than a day”
        0
        Действительно, не каждый. Зато у каждого есть возможность заплатить совсем небольшие деньги за взлом тем, кто такую коробочку имеет.
          0
          Может и пруф есть? Очень интересно сколько стоит подобрать DES 56.
            0
            Когда я плотно интересовался данным вопросом актуально было это www.cloudcracker.com/blog/2012/09/24/chap-v2-discounted/ Сейчас, полагаю, они берут $200, что тоже, согласитесь, не бог весть какая сумма.
              0
              Да, впечатляет. Спасибо за ссылку.

              David Hulton's company, Pico Computing, specializes in building FPGA hardware for cryptography applications. They were able to build an FPGA box that implemented DES as a real pipeline, with one DES operation for each clock cycle. With 40 cores at 450mhz, that's 18 billion keys/second. With 48 FPGAs, the Pico Computing DES cracking box gives us a worst case of ~23 hours for cracking a DES key, and an average case of about half a day.
      +8
      как страшно жить
      как абоненту мне нужна максимальная прозрачность — воткнул шнурок (неважно в ноут ли или роутер) и всё работает, а эти изыски с PРPOE по мне лишь лишний гимор, которым должен заниматься провайдер, а не абонент
        0
        Как страшно жить!
        Как жильцу дома мне нужна максимальная прозрачность — взял и вошел, а эти изыски замками, ключами, дверьми по мне лишь лишняя проблема. И пофиг, что есть бомжи, которые не проч переночевать у вас дома, пофиг на воров, пофиг, что в вашей квартире бомжи могут подратся с ворами и кого то убьют — главное удобство без дверей, замков и ключей.
          +2
          Невероятно, но замок можно взломать. Только занимаются этим единицы. Так же и врезка в чужой кабель — возможно, но риск минимален.
            –1
            До но если есть замок, то взломом будут заниматься единицы, а если не будет замка, то взламывать не будет никто — любой будует приходить в ваше отсутствие и свободно делать в вашей квартире все что угодно.
            С кабелями будет такая же ситуация еще появятся предприимчивые люди, которые будут подключать тех кто сам не может. Пример, дыры в ПО и сайтах, стоит появится незакрытой дыре, как появляются люди которые могут за награду помочь «непрофессионалу» или продать утилиту.
              +3
              В первом комментарии уже упоминалось, что нередко используемый у провайдеров PAP не дает ничего кроме иллюзии безопасности и элементарно взламывается любым сниффером.
          –1
          Странно. У нас так уже давно. Никаких логинов/паролей — просто шнурок вставил и в интернете. А ещё остались провайдеры с PPPoE?
          +11
          На данную технологию даже нет RFC

          Правда? Пацаны-то не знали :)
          tools.ietf.org/html/rfc894
          A Standard for the Transmission of IP Datagrams over Ethernet Networks
          April 1984

          Ваш аргумент понятен. Но внимание, вопрос: какой процент конечных пользователей страдает от подобных атак на физическом уровне?
          К вам домой приходит телефонная пара? Кошмар! Кто угодно может врезаться в нее и звонить на платные номера в Нигерию!
            –1
            В контексте данной статьи IPoE подразумевает под собой организацию доступа в интернет без использования PPTP/PPPOE, а не банальную передачу IP over Ethernet. Это, как минимум, тянет за собой DHCP с opt. 82 и NAT. Возможно еще какой-нибудь ISG если хочется, например, web авторизацию. Исходя из этого, ваша ссылка на rfc894 мягко говоря не в тему.

            В целом, на мой взгляд, проблема описанная топик стартером несколько высосана из пальца. Интернет стоит копейки, скорости достаточны для комфортной работы и двух и трех пользователей. Проще пойти договориться с тетей Глашей или другом Петей, чем врезаться куда-то и тянуть шнурок к себе. Это все равно, что на своей двери написать «я ворую инет у тети Глаши».
              +2
              Предлагаю вспомнить, что такое «RFC». Это — описание некоторой технологии. То, о чем вы говорите в контексте IPoE — архитектура, состоящая из множества разных технологий. RFC никакого отношения к этому не имеет, и более того — каждый может решить задачу по-своему, в зависимости от собственных требований.

              DHCP (с 82-й опцией или без нее), NAT, web аутентификация и прочее ни под каким видом не могут считаться обязательными компонентами обеспечения доступа конечным устройствам в интернет. Особенно NAT, от которого и многие IPoE провайдеры наконец отказались. Даже хомячковые, не говоря уже о корпоративных, где и DHCP обычно не используется.

              И да, есть RFC и на 82-ю опцию, и на сам DHCP, и на NAT, и тем более на HTTP — те кирпичи, на которых может строиться итоговая архитектура.
              Так что мое указание на RFC894 очень даже в тему. Автор сказал «нет RFC», я говорю — есть.
                0
                Вы сами себе противоречите.

                В контексте статьи IPoE — архитектура.
                RFC894 — IP over Ethernet, т.е. технология. Формально, да — буквы теже, но суть совершенно разная. И автор совершенно прав, что на данную архитектуру RFC нету, правда он применил слово «технология», отсюда и путаница.

                Что касается, что RFC никакого отношения к архитектуре не имеет (если я правильно вас понял). То это не так — смотрите, например, RFC3031 (MPLS), RFC2401 (IPsec). Более того, RFC — не только стандарты, но также концепции, введения в новые направления в исследованиях, исторические справки, результаты экспериментов, руководства по внедрению технологий, предложения и рекомендации по развитию существующих Стандартов и другие новые идеи в информационных технологиях

                И даже есть отдельная категория RFC — лучший современный опыт (Best Current Practice). Например, RFC2505 (BCP0030) Anti-Spam Recommendations for SMTP MTAs.
                  0
                  В контексте статьи IPoE — архитектура.

                  IPoE — всегда конкретная технология.
                  С помощью нее можно кучей разных способов (начиная с цепочки из неуправляемых свитчей с дэлинком на конце) передавать конечному пользователю пакеты. А реализация с vlan-per-user, с транспортом до первого хопа в еще одном .1q заголовке, с получением DHCP сервером от свитча 82-й опции — лишь один из вариантов, вовсе не самый лучший и тем более не самый универсальный. С какой стати ему быть описанным где-то?
                  PPPoE, L2TP, PPTP — это тоже лишь технологии. И на реализацию доступа к интернету с их помощью тоже нет и не может быть никаких RFC.
                  Что касается, что RFC никакого отношения к архитектуре не имеет (если я правильно вас понял). То это не так — смотрите, например, RFC3031 (MPLS), RFC2401 (IPsec).

                  Вот тут я вас не понял. Можно поподробнее? В данных примерах я не вижу ни намека на архитектуру. Только (к примеру, в случае MPLS) детальное описание концепции передачи разного рода пакетов с MPLS метками, схема обмена метками в разных сценариях, а также упоминание LDP+BGP+RSVP как механизмов обмена метками между LSR.
                  И даже есть отдельная категория RFC — лучший современный опыт (Best Current Practice).

                  Расскажите про свое видение best current practice (да хотя бы название придумывайте такое, чтобы после его прочтения ни у кого не возникло претензий) в случае последней мили на IPoE. Я вот сходу заявляю, что никакого NATа там быть не должно, как и DHCP (у меня сотни железок подключены к огромному числу провайдеров, и всегда оговаривается "/30 сеть на PE-CE, только глобально маршрутизируемый адрес и никак иначе"). Вы же почему-то говорите «Это, как минимум, тянет за собой DHCP с opt. 82 и NAT». Теперь вам становится ясно, почему никаких RFC тут не будет, видимо, никогда?

                  А раз уж шла речь про PPPoE и про якобы наличие RFC про архитектуры на базе него: дайте пример. Само собой, по минимуму должно быть оговорено, как доставить инкапсулированный в ethernet трафик до браса и как аккаунтить этот трафик. Ну или то же самое про L2TP — не суть важно.
                    0
                    Все дело в том, что вы под буквами IPoE понимаете, видимо, банальную передачу IP поверх Ethernet.

                    Я же, как и автор топика, под IPoE понимаю архитектуру построения сети провайдера без использования тунельных протоколов.
                    Причем речь, как правило, ведется про массовый доступ для физлиц.

                    >Вот тут я вас не понял. Можно поподробнее?

                    Да я всего лишь хотел сказать, что RFC это не только стандарты, как думают многое. На самом деле это несколько больше.

                    Про best current practice — это не моя придумка. Вам сюда: www.rfc-editor.org/categories/rfc-best.html :)

                    >Я вот сходу заявляю, что никакого NATа там быть не должно, как и DHCP

                    Где не должно быть? В предоставлении массовых услуг физлицам? Или все же юрлицам?

                    Если первое, то как провайдер могу вам сказать, что вы, извините, ерунду говорите. Особенно про DHCP. Отказ от PPPoE/PPTP в данном случае влечет необходимость в NAT. Конечно можно выдать каждому устройству каждого хомячка по белому IP, но в связи с окончанием IP у RIPE это несколько проблематично.

                    Если второе, то какое это имеет отношение к данному топику? Автор явно ведет речь про физлиц, вон у него Васи в кв.5 и Глаши в кв.1

                    >А раз уж шла речь про PPPoE и про якобы наличие RFC про архитектуры на базе него.

                    Не надо мешать мух с котлетами.

                    RFC 2661 — Layer Two Tunneling Protocol «L2TP»
                    RFC 2516 — A Method for Transmitting PPP Over Ethernet (PPPoE)
                    RFC 2637 — Point-to-Point Tunneling Protocol (PPTP)
                    RFC 2866 — RADIUS Accounting
                    RFC 5851 — Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks
                    RFC 4779 — ISP IPv6 Deployment Scenarios in Broadband Access Networks

                    Если хотите именно архитектуру, то с этим уже на Broadband Forum.

                    Several documents like Broadband Forum TR-058 [TR-058], Broadband Forum TR-059 [TR-059], and Broadband Forum TR-101 [TR-101] describe possible architectures for these access networks

                      0
                      как правило, ведется про массовый доступ для физлиц.

                      С какой стати «как правило»? В данном контексте — да, но не более того.
                      Отказ от PPPoE/PPTP в данном случае влечет необходимость в NAT.

                      Правда? Вот я захожу на свой домашний роутер:
                      Скрытый текст
                      #show int gi0/0
                      GigabitEthernet0/0 is up, line protocol is up
                      Hardware is CN Gigabit Ethernet, address is 1cdf.0f2a.d940 (bia 1cdf.0f2a.d940)
                      Description: Outside
                      Internet address is 77.37.XXX.YYY/21
                      MTU 1500 bytes, BW 15000 Kbit/sec, DLY 100 usec,
                      reliability 255/255, txload 188/255, rxload 6/255
                      Encapsulation ARPA, loopback not set

                      Меня глючит, или же мне все-таки выдают глобально маршрутизируемый адрес? Но где же «необходимость»?
                      Я могу получить на порт пять таких… Да и DHCP сделан лишь для удобства: у многих провайдеров его нет. Хотя само собой, без DHCP никто не даст пять адресов на порт хомячка. И да, адресное пространство в любом случае транжирится на несколько процентов сильнее в любом случае — кошмар :)
                      Про best current practice — это не моя придумка.

                      А я говорил, что это — выдумка?
                      Но: «Если хотите именно архитектуру, то с этим уже на Broadband Forum». Примерно об этом я и говорю.
                      Не надо мешать мух с котлетами.

                      Это скорее к вам вопрос :)
                        0
                        Почему глючит? Провайдеры бывают разные, используют разные схемы. Некоторые белые IP выдают, некоторые серые. Зависит от многих факторов — от тараканов в голове, от толщины кошелька и т.д.

                        У вас используется vlan per user + ip unnumbered (может вариации, на тему vlan per switch, vlan per building). Проблема только в том, что тот же ip unnumbered поддерживается у циски в железках класса 6500/7600. Причем, чтобы терминировать Q-in-Q нужны платы ES20, которые тоже весьма не дешевы сами по себе.

                        Можно конечно пробовать на мелких каталистах или на линуксе, но это только для тех «многих провайдеров», у которых DHCP нет. Т.е. мелких. Очень хочу посмотреть на провайдера без DHCP имеющего хотя бы 10к пользователей. Речь про физлиц конечно.

                        >И да, адресное пространство в любом случае транжирится на несколько процентов сильнее в любом случае — кошмар :)

                        Тут вот как-раз если «без DHCP», то для моего города — всего то в два раза. Соотношение online пользователей (PPTP) к подключенным — 0.5. Без DHCP, конечно не наш метод, поскольку пользователей очень сильно больше за 10к.

                        Если же с DHCP, то все зависит от времени аренды IP адреса. Что-то мне подсказывает, что даже при аренде в 4 часа это будет несколько больше «нескольких процентов». В понедельник посчитаю. Опять же даже несколько % на больших объемах, это достаточно внушительный блок IP.

                        IPoE конечно красиво и более дружественно к абоненту, но лично мое мнение — ну его нафиг, до IPv6. Работает — нехрен трогать (существующую сеть).
                          0
                          Провайдеры бывают разные, используют разные схемы.

                          Ага, то есть уже не «необходимость в NAT»…
                          Проблема только в том, что тот же ip unnumbered поддерживается у циски в железках класса 6500/7600.

                          ASRов не существует? 7600 вообще EOL. 6500 немного не для того предназначен.
                          Да и не цисками едиными…
                          Соотношение online пользователей (PPTP) к подключенным — 0.5.

                          Учитывая, что сейчас эра айпадов и, соответственно, вайфайных роутеров — очень странный результат. И как считается эта цифра? Надеюсь, пиковое значение за типичный день (а только так и надо закладываться)? Как-то не верится мне, что ближе к вечеру лишь половина абонентов будет в сети.
                          Что-то мне подсказывает, что вы все равно исходите из «95% абонентов могут одновременно выйти в сеть» при выделении адресного пространства — если, конечно, обходитесь без PAT. Разве нет? И когда блоки адресов уже распределены, нет ни малейшего смысла экономить их.
                          Работает — нехрен трогать (существующую сеть).

                          В этом есть смысл, так как изменение архитектуры => факапы => недовольные пользователи (я сам подобным образом от корбины сбежал, когда она начала мутировать в билайн). Но вот для новых домов можно бы параллельно и более красивую архитектуру сделать.
                            0
                            >ASRов не существует?

                            Существуют. Речь шла про ценник решения. У ASR он тоже весьма хороший.

                            >Да и не цисками едиными…

                            Смена вендора, это тоже определенные затраты. Хотя рекомендации в какую сторону посмотреть — с удовольствием выслушаю.

                            >очень странный результат. И как считается эта цифра?

                            Считается очень просто; k = количество договоров / количество пользователей online.
                            Коэффициент одинаковый для Тольятти и Самары.

                            >Что-то мне подсказывает, что вы все равно исходите из «95% абонентов могут одновременно выйти в сеть»

                            Не могут. И поэтому не исходим из этого. На основе многолетней практики знаем когда какие колебания происходят. Колебания эти, как правило, не более 10%. И происходят не за 1 день. Поэтому держим запас чуть больше + имеем возможность расшириться (аплинки, сервера) очень быстро. + конечно мониторинг и отработанные процедуры по расширению. Тригер в системе мониторинга сработал — запустился механизм расширения. Перед сезонными колебаниями (сентябрь, НГ) — расширяемся заблаговременно. Вот так и живем. Экономисты и бизнес довольны.

                            >Но вот для новых домов можно бы параллельно и более красивую архитектуру сделать.

                            Поддержка/совмещение двух архитектур — весьма хлопотное занятие. Нужно не только построить, но еще и персонал обучить. К тому же последняя тенденция — покупать оператора на интересной территории, а не строить свою сеть.
                              0
                              Речь шла про ценник решения. У ASR он тоже весьма хороший.

                              Смотря какая нужна пропускная способность.
                              Хотя рекомендации в какую сторону посмотреть — с удовольствием выслушаю.

                              Ну например где-то писалось, что онлайм использует алкатели.
                              k = количество договоров / количество пользователей online.

                              В 3 часа ночи? Или ближе к вечеру, когда все пришли с работы? И вы так и не ответили: какова у вас переподписка по соотношению глобально маршрутизируемых адресов к числу договоров? Неужели 1/2? :)
                              Поэтому держим запас чуть больше + имеем возможность расшириться (аплинки, сервера) очень быстро.

                              Речь идет исключительно о маршрутизируемых адресах, т.е. о числе подключенных приблизительно одновременно клиентов. Даже если все они лишь раз в полчаса пингуют яндекс и больше ничего не делают.
                                0
                                >Смотря какая нужна пропускная способность.

                                10G с возможностью расширения до 20G. В дуплексе конечно, т.е. по 10G в обе стороны. ip unnumbered

                                >В 3 часа ночи?

                                В ЧНН (час наибольшей нагрузки). Т.е. максимум по графику. Это 21-22 часа.

                                Текущее соотношение — 0.61 (приходится еще некоторое количество IP задействовать из-за неровной балансировки).

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

                                Да, именно так.
                                  0
                                  10G с возможностью расширения до 20G. В дуплексе конечно

                                  Так это мало. ASR1002-X (махонькая 2-юнитовая коробка), почти младший представитель линейки 1k, такое потянет. Не говоря уже о 9к. По GPL расценки навскидку: 65к за шасси 1002-X с 20G лицензией и 6-ю 1G портами, и по 30к за 10G порт (ага, не спорю, порты у них стоят безумных денег).
                                  Текущее соотношение — 0.61

                                  Я и говорю — странно как-то. Может, особенности заМКАДья, что ни у кого роутеров нет?
                                    0
                                    > Так это мало.

                                    Дак мне нужно как минимум 4 шт (или 2 с полным резервом внутри одного шасси).
                                    Не дешевая «красота» получается, при том что существующее решение на порядок дешевле и в принципе полностью устраивает.

                                    >Я и говорю — странно как-то. Может, особенности заМКАДья, что ни у кого роутеров нет?

                                    Удаленность от Москвы, конечно, накладывает свой отпечаток. Я думаю от вас мы года на 2-3 отстаем.
                                      0
                                      существующее решение на порядок дешевле и в принципе полностью устраивает.

                                      Таким образом можно спуститься до хомячкового класса дэлинков опуститься. Еще на порядок дешевле, зависают не слишком часто, кого-то всем устраивают…

                                      Но что шеститонник на порядок дешевле ASRов — это забавно :) GPL категорически возражает.
                                        0
                                        >Таким образом можно спуститься до хомячкового класса дэлинков опуститься. Еще на порядок дешевле, зависают не слишком часто, кого-то всем устраивают…

                                        Чем вам не нравится DLink? Весьма не плох для доступа. На агрегации и в ядре, конечно циска.

                                        >Но что шеститонник на порядок дешевле ASRов — это забавно :) GPL категорически возражает.

                                        Я не говорил что существующее решение (PPTP) на шеститоннике.
                                          0
                                          «до хомячкового класса дэлинков»
                                          Мне не нравятся хомячкового класса дэлинки. С более серьезными классами их железа не работал, но говорят, что тоже некачественный ширпотреб.
            +4
            а wifi тогда вообще использовать как страшно. соседу и врезаться не надо в кабель.
              0
              Вы используете wi-fi без WPA2? Тогда ваш интернет уже вам не принадлежит…
              +14
              Для защиты от этой ситуации я использую автоматический мониторинг длины кабеля до абонента.
              Как только длина кабеля вдруг резко сокращается, создаётся тикет. Двоих подобных придурков уже поймали.

              Пример, как это выглядит:

              DGS-3200-10:4#cable_diag ports 1-10
              Command: cable_diag ports 1-10

               Perform Cable Diagnostics …

               Port     Type       Link Status          Test Result          Cable Length (M)
               ---- ------------  -------------  -------------------------  -----------------
                1    1000Base_T    Link Up        OK                                50
                2    1000Base_T    Link Up        OK                                1
                3    1000Base_T    Link Up        OK                                3
                4    1000Base_T    Link Down      Pair1 Open      at 3   M          -
                                                  Pair2 Open      at 4   M
                                                  Pair3 Open      at 3   M
                                                  Pair4 Open      at 4   M
                5    1000Base_T    Link Up        OK                                -
                6    1000Base_T    Link Down      No Cable                          -
                7    1000Base_T    Link Down      No Cable                          -
                8    1000Base_T    Link Down      No Cable                          -
                9    1000Base_T    Link Down      No Cable                          -
                10   1000Base_T    Link Down      No Cable                          -
                0
                ну наверное не совсем удобно мониторить несколько тысяч абонов, а если тупой коммутатор? тем более что кабельный тестер на длинках штука чудливая
                  +4
                  Удобство не имеет значения — мониторинг проводится автоматически, скриптом на сервере.
                  Чудливость кабельного тестера проблем не создаёт, его достаточно для такой задачи.

                  А если коммутатор тупой — то проблема, которую сформулировал автор поста, встанет в полный рост и так :)
                  0
                  А когда тест кабеля происходит, разве линк не отваливается?
                    +2
                    Когда в кабель врезаются — линк тоже отваливается :-)
                    Скрипт ждёт следующего события — «восстановление линка + [dhcp запрос/ответ либо истечение 10 секунд]».

                    Также проводится плановое еженедельное тестирование — в 4-5 ночи на понедельник.
                    Это позволяет выловить жуликов и воров, которые врезались в кабель в момент дайнтайма мониторинга.
                      0
                      Хм, хорошая идея, пожалуй, стоит у себя реализовать
                        +1
                        На здоровье.
                    0
                    Во-первых, хотел бы сказать всем спасибо за отзывы. Даже не ожидал, что такая, несколько шуточная статья вызовет дебаты.

                    Способ мне нравится, спасибо за идею.

                    И, немного лирики:
                    Мне кажется, что сравнения с замками очень точно. Замок в двери не спасет от грабителей профессионалов, но спасет от дилетантов, а их куда больше.

                    PPPoE+PAP используют только маргинальные провайдеры, у них, видимо и к серверам есть доступ с внешнего мира по ssh.v1.

                    PPPoE+MS-CHAP не так-то просто взломать.

                    Веб-авторизация — а разница с PPPoE? Тот же логин пароль. Ip-tv? Что мешает использовать какой-нибудь MVR, а в случае с DSL другой vpi/vci?

                    Любая привязка мака к порту, по моему глубоком убеждению — лишний геморрой, который будет разрастаться по мере роста сети. Думаю, почему не нужно объяснять?

                    Есть движение людей, цель которого бегать по домам и искать не запороленный wi-fi. А чем проще получить халяву, тем она желанней. Подбор ключей, перехват сессий итд. — вещь не самая простая и требует ресурсов, времени и знаний. А врезка в кабель — не требует сколько-нибудь серьёзных умений.

                    И давайте не будем сравнивать интернет и телефон.

                    Спасибо.
                    +2

                    Купите коммутатор с IPMB и будет вам счастье, а так как вы рассказываете про врезку здесь любым методом можно получить инет, могу добавить еще минус к PPPoE — это маршруты для iptv которые нужно прописывать хомякам
                      0
                      IPMB никак не спасёт от MITM атаки
                        0
                        а что спасет если врезались в кабель? имелось ввиду что pppoe не привязывается к маку, а ipmb привязывается к порту, маку и адресу
                          0
                          есть два подхода — аутентификация 802.1x, либо описанный мной контроль по косвенным признакам.
                          аутентификация — это опять логины, пароли, в общем тот же геморрой для пользователя, что и при pppoe. ещё и далеко не со всеми железками/ос работает.
                          так что возвращаемся к контролю по косвенным…
                      +1
                      А также видел кучу роутеров которые по pppoe могут прожевать скажем 20Мбит/сек, а на ipoe 60-80, да согласен вопрос решается в 70-80% обновлением ПО, Вообще сравнивать 2 технологии не совсем корректно, PPPoE хорошо использовать в неуправляемой сети.
                        0
                        А в каком месте у вас абоненты между собой маршрутизируются? Просто хочу понять как пойдет трафик если абонент из влана 101 захочет скачать файлик у абонента из влана 102.
                          0
                          Если нет особых требований к СОРМ, то обычно это всё исполняется на первой L3-коробке, т.е. на BRAS.
                            0
                            Абсолютно верно.
                          0
                          У IPoE есть ещё одна большая проблема — отсутствие возможности контроля живучести абонентской CPE или компа в случае если шнурок подключается напрямую. Здесь есть несколько методик, позволяющих снизить даунтайм сервиса для абонента в случае возникновения той или иной проблемы на сети:
                          1. Выдавать короткую лизу. Вариант хороший, но повышает нагрузку на BRAS, который яростно атакуют постоянными запросами на обновление лизы.
                          2. Использование arping клиентским оборудованием для детектирования отвала шлюза. Тоже, казалось бы, хорошее решение, но далеко не все домашние CPE умеют делать arping.
                          3. Использование RFC 3203 для форсирования обновления лизы клиентом. И тут не без проблем — фичу мало кто поддерживает как на стороне BRAS, так и на стороне клиентских CPE.

                          Если срезюмировать, то практически все IPoE провайдеры идут по первому пути. Самая жесть, которую я встречал, была лиза в 5 минут длиной, что выливалось в то, что раз в 150 секунд каждый клиент делал запрос на обновление.
                            +1
                            отсутствие возможности контроля живучести абонентской CPE или компа в случае если шнурок подключается напрямую.

                            Я не понял… Речь про отслеживание доступности CPE, или PE (браса)?
                            А зачем это? Типичному хомячку некуда фейловериться кроме как в пределах того же провайдера. Тут можно сделать VRRP для защиты от падения браса. Ну и некоторую избыточность на пути до браса. Всё. Свитч в доме никто все равно резервировать не будет хоть так, хоть этак.
                            Ну и всегда есть arp таймаут. Запись заекспайрилась, нового reply не дождались => у нас проблемы.

                            Хочется хомячку мгновенно видеть аварии на сети? Не вопрос. IP SLA или тому подобное, и шквал пингов на первый хоп. Ничего страшного для провайдеров — таких хомячков мало.
                              0
                              Да, речь о фэйловере в случае отвала BRAS. VRRP — не всегда панацея, т.к. BRAS вполне может быть доступен по IP, но у него может покрашиться демон, отвечающий за BRAS-функционал, я такое видел. В этом случае arping тоже не у дел, разумеется.
                              +1
                              ericsson se100. врежиме dhcp-proxy с лизой 5 минут без видимой нагрузки держит более 1000 онлайн абонентов. это самый старый и самый слабый из серии. так что короткая лиза не проблема. у некоторых сессия больше месяца длится.
                                0
                                пруф:
                                        begin        |         end         |     duration     |  live   |        mac
                                ---------------------+---------------------+------------------+---------+-------------------
                                 2012-11-28 11:52:48 | 2013-02-23 11:26:12 | 86 days 23:33:24 | working | 1c:af:f7:37:b8:f9
                                 2012-12-12 16:21:03 | 2013-02-23 11:26:03 | 72 days 19:05:00 | working | 00:1d:7e:bd:55:64
                                 2012-12-14 09:37:47 | 2013-02-23 11:25:54 | 71 days 01:48:07 | working | 10:bf:48:e6:4c:a6
                                 2012-12-14 09:37:45 | 2013-02-23 11:24:39 | 71 days 01:46:54 | working | e0:cb:4e:38:0c:07
                                 2012-12-14 09:37:41 | 2013-02-23 11:23:31 | 71 days 01:45:50 | working | 00:0f:02:3a:33:3e
                                 2012-12-14 09:37:52 | 2013-02-23 11:23:12 | 71 days 01:45:20 | working | 00:0f:01:34:3b:3e
                                 2012-12-14 09:37:43 | 2013-02-23 11:22:39 | 71 days 01:44:56 | working | 20:cf:30:ce:26:f0
                                 2012-12-14 09:37:41 | 2013-02-23 11:22:31 | 71 days 01:44:50 | working | 00:0f:02:3a:4b:f8
                                 2012-12-14 09:37:42 | 2013-02-23 11:21:03 | 71 days 01:43:21 | working | 90:f6:52:2d:49:6b
                                 2012-12-14 09:37:41 | 2013-02-23 11:20:59 | 71 days 01:43:18 | working | 00:0f:01:34:0c:1c
                                 2012-12-14 09:37:42 | 2013-02-23 11:17:34 | 71 days 01:39:52 | working | 00:0f:01:34:10:6c
                                 2012-12-14 21:40:02 | 2013-02-23 11:21:11 | 70 days 13:41:09 | working | 00:0f:02:3a:32:fc
                                 2012-12-14 23:05:11 | 2013-02-23 11:21:36 | 70 days 12:16:25 | working | 88:9f:fa:1e:b8:14
                                 2012-12-16 17:27:00 | 2013-02-23 11:26:32 | 68 days 17:59:32 | working | 00:18:e7:fc:ef:2d
                                 2012-12-16 17:27:11 | 2013-02-23 11:24:34 | 68 days 17:57:23 | working | c8:6c:87:3e:e8:f6
                                 2012-12-20 17:55:47 | 2013-02-23 11:21:57 | 64 days 17:26:10 | working | c8:6c:87:42:f0:18
                                 2012-12-23 11:31:29 | 2013-02-23 11:18:47 | 61 days 23:47:18 | working | 00:18:e7:e3:92:3b
                                 2012-12-25 21:58:02 | 2013-02-23 11:22:40 | 59 days 13:24:38 | working | 1c:bd:b9:91:cf:1b
                                 2012-12-31 12:09:09 | 2013-02-23 11:23:30 | 53 days 23:14:21 | working | 54:04:a6:e8:7f:80
                                 2013-01-04 20:56:09 | 2013-02-23 11:21:41 | 49 days 14:25:32 | working | f4:ec:38:f5:f5:3d
                                 2013-01-06 15:07:31 | 2013-02-23 11:24:18 | 47 days 20:16:47 | working | 00:0f:01:34:0e:6e
                                 2013-01-08 03:12:38 | 2013-02-23 11:23:36 | 46 days 08:10:58 | working | 00:0f:02:3a:53:3c
                                 2013-01-14 11:24:31 | 2013-02-23 11:26:39 | 40 days 00:02:08 | working | 00:0f:02:10:16:ae
                                
                                  0
                                  Противопоставить мне нечего:) Любопытно взлянуть на коробку со 100k пользователей (не на se100, разумеется).
                                +1
                                А мужики-то не знали.
                                Onlime работает по IPoE, Qwery работает по IPoE и даже Akado работает по IPoE поверх DOCSIS.

                                А насчет стандарта. Автор текста не в курсе про BroadBand Forum TR-101, например.
                                Советую почитать — полезно будет.

                                И, кстати, RFC описывают стандарты, протоколы, но никак не рекомендуемые архитектуры решений.
                                  0
                                  Что то не пойму, какое отношение TR-101 имеет к обсуждаемой теме?

                                  DSL Forum, TR-101, Migration to Ethernet-Based DSL Aggregation

                                  >И, кстати, RFC описывают стандарты, протоколы, но никак не рекомендуемые архитектуры решений.

                                  Есть целая категория RFC — Best Current Practice — www.rfc-editor.org/categories/rfc-best.html

                                  RFC 6853 — DHCPv6 Redundancy Deployment Considerations
                                    0
                                    Уважаемый. Вы хоть TR-101 читали дальше заголовка?
                                    Очень советую изучать документ прежде чем писать глупости.

                                    А насчет RFC — еще раз, нет ни одного RFC, который описывает end-to-end архитектуру. В этом и слабость RFC.
                                      0
                                      >Уважаемый. Вы хоть TR-101 читали дальше заголовка?
                                      >Очень советую изучать документ прежде чем писать глупости.

                                      Читал конечно. Поэтому и спросил. Первые 60 страниц можно смело пропустить, при прочтении остальных нужно тщательно фильтровать слова xDSL и ATM. Какое отношение этот документ имеет к обсуждаемой теме — лично для меня загадка.

                                      Если и рекомендовать, что либо к прочтению — то это TR-145 Multi-service Broadband Network Functional Modules and Architecture. Кстати рекомендую.

                                  0
                                  Вы в послесловии написали о необходимости пользователю диктовать свой mac адрес, дикие у вас однако провайдеры, наши сами смотрят на порту новый mac. Ни разу еще ни один провайдер из 3-х к которым я в Челябинске подключался не требовал от меня mac адрес.
                                    0
                                    Проблема решается всего-навсего страничкой авторизации. Что-нибудь не так? Переспросили у пользователя логин/пароль (с карточки, которую выдали при подключении).
                                      +2
                                      самое зло, какое может быть.
                                        0
                                        А в чем, собственно, проблема?
                                          0
                                          1) Это не удобно. Надо искать бумажку или где записано. А что если я с телефоном в туалете в это время?!
                                          2) Где мой доступ к домашнему NAS, если вдруг провайдер решил запросить авторизацию.
                                          3) Технически я не хочу чтоб провайдер что-то подменял у меня и заставлял меня использовать свои DNS.

                                          Я бы с таким провайдером точно не остался, особенно если бы были нормальные альтернативы. Я вообще только хочу чтоб провайдер выдал мне IP, канал и больше никуда не лез, а занимался качеством своих каналов и оборудования.
                                            0
                                            1) Это неудобно для 2-3 человек из тысячи.
                                            2) Авторизация запрашивается не просто так, а только если что-нибудь случилось.
                                            3) При чем тут DNS?

                                            Ну и в конце-концов я могу у себя в биллинге для конкретного абонента, которого это по каким-либо причинам не устраивает, ткнуть флажок «не использовать веб-авторизацию» :).
                                      0
                                      Как будто этому кулцхакеру Василию (который может обжать, врезаться и настроить) сложно договорится со всем этажом, что интернет будет идти через него за в 4ре раза меньшую стоимость чем они платят сейчас провайдеру.
                                        +1
                                        Как-то ни о чем.

                                        >не нужен дорогостоящий BRAS
                                        И PPPoE и IPoE можно поднять на тазике.

                                        >не нужно тратиться на подсети внешних адресов
                                        Серые адреса можно в обоих случаях раздавать.

                                        >схема, изображенная на рисунке 3
                                        Врезаться можно и в PPPoE.
                                          0
                                          На мой взгляд PPPoE — зло. Даже какой-нибудь дешёвый miktroik RB751G в качестве домашнего роутера снизит свою пропускную способность в разы.
                                            0
                                            Пруф имеется?
                                              0
                                              ну вот сегодня-завтра я тест прогнать не смогу, но замечал такое. а вам кажется это странным?

                                              учитывая, что «25 Firewall filter rules» снижают пропускную способность с 708.1 Mbps до 162.6 Mbps (http://routerboard.com/RB751G-2HnD).
                                              0
                                              Есть чипы, котрые оффлоадят обработку PPPoE на себя, на таких разница в производительности IPoE и PPPoE различается на уровне погрешности.
                                                0
                                                которые из SOHO (и даже средего офиса) роутеров имеют в себе такой чип?
                                                  0
                                                  Ну, например, Asus RT-N56U и его старший брат Asus RT-N65U, построенные на Raink RT3662.
                                                    0
                                                    он кстати и на одном процессоре наверное нормально 100, которую сейчас дают наши провайдеры, прогонит. но не многие покупают роутер за 4 т.р. Да и сами операторы такие не ставят.
                                                      0
                                                      На процессоре оно сотку и на PPTP/L2TP даёт, что уводит CPU в полку, но работает. IPoE и PPPoE дают софтовую производительность на уровне 300-350Mbps, не помню точно.
                                                  0
                                                  а этот чип работает всегда, или если я добавлю хоть одно правило, то вся нагрузка уйдёт на процессор?
                                                    0
                                                    С iptables можно делать что угодно, трафик офлоадится на PPE.
                                                    Если нужно шейпить трафик, то да, придётся гнать трафик софтовым способом с просадкой производительности.
                                                0
                                                Не на то вы нападаете.

                                                Указанный подход реально упростил жизнь пользователям. Проблем с пользователями по Ethernet — не так много, а особенно — с качеством их доступа в интернет. Куда хуже те, кто используют DSL-модем и у которых проблемы с физикой после каждого дождя.

                                                А вот есть провайдеры с PPTP и/или L2TP и ужасным извращением, которое принято называть Russian Dual PPTP — когда я вижу всё это, реально хочется УБИВАТЬ. Уж лучше PPPoE, чем так жить.
                                                  +2
                                                  Зачем автор надумал гипотетическую проблему и выставляет её за реалии жизни? За мою практику работы в телекомах, похожие случаи были настоль редки, насколько легко эта административная проблема решается техническими средствами (исключение из правил, ага).

                                                  А технические средства просты и незамысловаты:
                                                  • прибивание в биллинге гвоздями mac-адреса оборудования пользователя. Ну и разрешить ему самому менять его в личном кабинете.
                                                  • cable_diag (bingo!) для всех активных пользовательских портов. Как? Ваш биллинг не настолько хорошо интегрирован с автоматизацией вокруг? Не хватает ресурсов для опроса? Свитчи не умеют cable_diag? У меня для Вас плохие новости.
                                                  • port_security в permanent на доступе по 1 mac на порт. Использовать только во время войны.

                                                  Ах да, одна из главных фич IPoE с dynamic pool на IP unnumbered — в политиках ISG разрешать трафик-класс в интернеты первой авторизованной сеcсии с порта пользователя (option 82, привет!), остальные сессии могут получать IP, но в эти ваши интернеты их не пускать.
                                                    0
                                                    Привязка к маку это очень нехорошо и неудобно. Она создает новые неудобства, при этом не решая старых. Вас что именно в описанной в статье ситуации беспокоит — то что Вася ворует интернет у Глаши или то, что он сидит в нем на халяву?
                                                      0
                                                      Ситуация на самом деле неприятная со многих сторон.
                                                      То, что Вася мне в этой ситуации не платит, а может, и мог бы — это самая малая из проблем.

                                                      Гораздо хуже то, что услуга, оказываемая Глаше, становится некачественной.
                                                      Мигнул свет в подъезде — железка в щитке зависла. Глаша считает, что я плохой провайдер.
                                                      Глаша случайно задела патчкорд и жалуется на «сетевой кабель не подключен» — а мой биллинг видит, что линк есть и все пары активны. Моя поддержка вводит её в заблуждение. Она опять приходит к выводу, что я плохой провайдер.
                                                      Вася ставит сниффер и влезает в её вконтактик. Глаша десять раз меняет пароль, выводит все вирусы, заходит даже с мобильника, а всё впустую. А виноват я — я не обеспечил безопасность.
                                                      Вася пишет «смерть жуликам и ворам» на каком-нибудь форуме. К Глаше приходят с обыском и изымают всю электронику от фоторамки до кардиостимулятора. Она не понимает, причём она тут. А виноват-то опять я — я опять не обеспечил безопасность!

                                                      Все примеры условны, но наглядно показывают, почему Васе не место в разрыве кабеля Глаши :-)
                                                      +1
                                                      Первый пункт — мучение для клиента.
                                                      Особенно учитывая то, что половина клиентов вообще не поймёт, что это и как это. Простые работяги, домохозяйки, пенсионеры. Бесконечно далеки вы от народа :)

                                                      Третий пункт мешает подключать абонентское оборудование через свич.

                                                      При этом, злодею всё перечисленное не помешает никак.
                                                      Из моей практики — злодей поставил вайфай в щитке в разрыв. Даже не стал заморачиваться с протяжкой кабеля.
                                                      Данный факт был выявлен вторым способом.
                                                      Оставили роутер на месте неподключённым, рядом положили листочек с распечаткой пары статей УК РФ. :)
                                                      0
                                                      Прошли те времена, когда интернет стоил как заправка Белаза и для того, чтобы задуматься о врезке в чей-то кабель — нужно заболеть психическим расстройством. Проще соседу пойти к тете Глаше и договориться с ней платить за интернет 50/50, поставив у нее роутер и сделав себе ответление. Стремиться нужно к тому, чтобы услуга интернет рано или поздно стало максимально бесплатной, — это как базовая потребность: водопровод, электричество.
                                                        0
                                                        А кто вообще оперирует термином IPoE? IP over Ethernet — связка старше некуда. Приплетение туда опции 82 является не более чем частным взглядом. Лет 10 назад были ещё «авторизаторы» — это тоже вполне себе IPoE и прекрасно работало в своём времени. Но сдохло сугубо по экономическим причинам — инет перестали воровать и распространился HTTPS для чувствительных соединений.

                                                        Кстати, а кто мешает врезаться в провод с PPPoE? Злоумышленник просто виртуально присвоит себе адрес сервера, узнает логин/пароль и потом и будет им представляться жертве. Ни PPTP ни L2TP без использования сертификатов сервера (которые никто из операторов не юзает) не поможет.

                                                        Only users with full accounts can post comments. Log in, please.