Comments 86
против лома нет приема.
можно врезаться между абонентом и PPPoE сервером, сделать свой сервер PPPoE и подслушать логин/пароль: habrahabr.ru/post/158781/
можно врезаться между абонентом и PPPoE сервером, сделать свой сервер PPPoE и подслушать логин/пароль: habrahabr.ru/post/158781/
PPTP + MSCHAPv2
Конечно его тоже уже поломали, но не каждый хакер Вася имеет FPGA-based box, чтобы “crack any MS-CHAPv2 handshake in less than a day”
Конечно его тоже уже поломали, но не каждый хакер Вася имеет FPGA-based box, чтобы “crack any MS-CHAPv2 handshake in less than a day”
Действительно, не каждый. Зато у каждого есть возможность заплатить совсем небольшие деньги за взлом тем, кто такую коробочку имеет.
Может и пруф есть? Очень интересно сколько стоит подобрать DES 56.
Когда я плотно интересовался данным вопросом актуально было это www.cloudcracker.com/blog/2012/09/24/chap-v2-discounted/ Сейчас, полагаю, они берут $200, что тоже, согласитесь, не бог весть какая сумма.
Да, впечатляет. Спасибо за ссылку.
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.
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.
как страшно жить
как абоненту мне нужна максимальная прозрачность — воткнул шнурок (неважно в ноут ли или роутер) и всё работает, а эти изыски с PРPOE по мне лишь лишний гимор, которым должен заниматься провайдер, а не абонент
как абоненту мне нужна максимальная прозрачность — воткнул шнурок (неважно в ноут ли или роутер) и всё работает, а эти изыски с PРPOE по мне лишь лишний гимор, которым должен заниматься провайдер, а не абонент
На данную технологию даже нет RFC
Правда? Пацаны-то не знали :)
tools.ietf.org/html/rfc894
A Standard for the Transmission of IP Datagrams over Ethernet Networks
April 1984
Ваш аргумент понятен. Но внимание, вопрос: какой процент конечных пользователей страдает от подобных атак на физическом уровне?
К вам домой приходит телефонная пара? Кошмар! Кто угодно может врезаться в нее и звонить на платные номера в Нигерию!
В контексте данной статьи IPoE подразумевает под собой организацию доступа в интернет без использования PPTP/PPPOE, а не банальную передачу IP over Ethernet. Это, как минимум, тянет за собой DHCP с opt. 82 и NAT. Возможно еще какой-нибудь ISG если хочется, например, web авторизацию. Исходя из этого, ваша ссылка на rfc894 мягко говоря не в тему.
В целом, на мой взгляд, проблема описанная топик стартером несколько высосана из пальца. Интернет стоит копейки, скорости достаточны для комфортной работы и двух и трех пользователей. Проще пойти договориться с тетей Глашей или другом Петей, чем врезаться куда-то и тянуть шнурок к себе. Это все равно, что на своей двери написать «я ворую инет у тети Глаши».
В целом, на мой взгляд, проблема описанная топик стартером несколько высосана из пальца. Интернет стоит копейки, скорости достаточны для комфортной работы и двух и трех пользователей. Проще пойти договориться с тетей Глашей или другом Петей, чем врезаться куда-то и тянуть шнурок к себе. Это все равно, что на своей двери написать «я ворую инет у тети Глаши».
Предлагаю вспомнить, что такое «RFC». Это — описание некоторой технологии. То, о чем вы говорите в контексте IPoE — архитектура, состоящая из множества разных технологий. RFC никакого отношения к этому не имеет, и более того — каждый может решить задачу по-своему, в зависимости от собственных требований.
DHCP (с 82-й опцией или без нее), NAT, web аутентификация и прочее ни под каким видом не могут считаться обязательными компонентами обеспечения доступа конечным устройствам в интернет. Особенно NAT, от которого и многие IPoE провайдеры наконец отказались. Даже хомячковые, не говоря уже о корпоративных, где и DHCP обычно не используется.
И да, есть RFC и на 82-ю опцию, и на сам DHCP, и на NAT, и тем более на HTTP — те кирпичи, на которых может строиться итоговая архитектура.
Так что мое указание на RFC894 очень даже в тему. Автор сказал «нет RFC», я говорю — есть.
DHCP (с 82-й опцией или без нее), NAT, web аутентификация и прочее ни под каким видом не могут считаться обязательными компонентами обеспечения доступа конечным устройствам в интернет. Особенно NAT, от которого и многие IPoE провайдеры наконец отказались. Даже хомячковые, не говоря уже о корпоративных, где и DHCP обычно не используется.
И да, есть RFC и на 82-ю опцию, и на сам DHCP, и на NAT, и тем более на HTTP — те кирпичи, на которых может строиться итоговая архитектура.
Так что мое указание на RFC894 очень даже в тему. Автор сказал «нет RFC», я говорю — есть.
Вы сами себе противоречите.
В контексте статьи IPoE — архитектура.
RFC894 — IP over Ethernet, т.е. технология. Формально, да — буквы теже, но суть совершенно разная. И автор совершенно прав, что на данную архитектуру RFC нету, правда он применил слово «технология», отсюда и путаница.
Что касается, что RFC никакого отношения к архитектуре не имеет (если я правильно вас понял). То это не так — смотрите, например, RFC3031 (MPLS), RFC2401 (IPsec). Более того, RFC — не только стандарты, но также концепции, введения в новые направления в исследованиях, исторические справки, результаты экспериментов, руководства по внедрению технологий, предложения и рекомендации по развитию существующих Стандартов и другие новые идеи в информационных технологиях
И даже есть отдельная категория RFC — лучший современный опыт (Best Current Practice). Например, RFC2505 (BCP0030) Anti-Spam Recommendations for SMTP MTAs.
В контексте статьи IPoE — архитектура.
RFC894 — IP over Ethernet, т.е. технология. Формально, да — буквы теже, но суть совершенно разная. И автор совершенно прав, что на данную архитектуру RFC нету, правда он применил слово «технология», отсюда и путаница.
Что касается, что RFC никакого отношения к архитектуре не имеет (если я правильно вас понял). То это не так — смотрите, например, RFC3031 (MPLS), RFC2401 (IPsec). Более того, RFC — не только стандарты, но также концепции, введения в новые направления в исследованиях, исторические справки, результаты экспериментов, руководства по внедрению технологий, предложения и рекомендации по развитию существующих Стандартов и другие новые идеи в информационных технологиях
И даже есть отдельная категория RFC — лучший современный опыт (Best Current Practice). Например, RFC2505 (BCP0030) Anti-Spam Recommendations for SMTP MTAs.
В контексте статьи 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 — не суть важно.
Все дело в том, что вы под буквами 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
Я же, как и автор топика, под 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
как правило, ведется про массовый доступ для физлиц.
С какой стати «как правило»? В данном контексте — да, но не более того.
Отказ от 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
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». Примерно об этом я и говорю.
Не надо мешать мух с котлетами.
Это скорее к вам вопрос :)
Почему глючит? Провайдеры бывают разные, используют разные схемы. Некоторые белые 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. Работает — нехрен трогать (существующую сеть).
У вас используется 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. Работает — нехрен трогать (существующую сеть).
Провайдеры бывают разные, используют разные схемы.
Ага, то есть уже не «необходимость в NAT»…
Проблема только в том, что тот же ip unnumbered поддерживается у циски в железках класса 6500/7600.
ASRов не существует? 7600 вообще EOL. 6500 немного не для того предназначен.
Да и не цисками едиными…
Соотношение online пользователей (PPTP) к подключенным — 0.5.
Учитывая, что сейчас эра айпадов и, соответственно, вайфайных роутеров — очень странный результат. И как считается эта цифра? Надеюсь, пиковое значение за типичный день (а только так и надо закладываться)? Как-то не верится мне, что ближе к вечеру лишь половина абонентов будет в сети.
Что-то мне подсказывает, что вы все равно исходите из «95% абонентов могут одновременно выйти в сеть» при выделении адресного пространства — если, конечно, обходитесь без PAT. Разве нет? И когда блоки адресов уже распределены, нет ни малейшего смысла экономить их.
Работает — нехрен трогать (существующую сеть).
В этом есть смысл, так как изменение архитектуры => факапы => недовольные пользователи (я сам подобным образом от корбины сбежал, когда она начала мутировать в билайн). Но вот для новых домов можно бы параллельно и более красивую архитектуру сделать.
>ASRов не существует?
Существуют. Речь шла про ценник решения. У ASR он тоже весьма хороший.
>Да и не цисками едиными…
Смена вендора, это тоже определенные затраты. Хотя рекомендации в какую сторону посмотреть — с удовольствием выслушаю.
>очень странный результат. И как считается эта цифра?
Считается очень просто; k = количество договоров / количество пользователей online.
Коэффициент одинаковый для Тольятти и Самары.
>Что-то мне подсказывает, что вы все равно исходите из «95% абонентов могут одновременно выйти в сеть»
Не могут. И поэтому не исходим из этого. На основе многолетней практики знаем когда какие колебания происходят. Колебания эти, как правило, не более 10%. И происходят не за 1 день. Поэтому держим запас чуть больше + имеем возможность расшириться (аплинки, сервера) очень быстро. + конечно мониторинг и отработанные процедуры по расширению. Тригер в системе мониторинга сработал — запустился механизм расширения. Перед сезонными колебаниями (сентябрь, НГ) — расширяемся заблаговременно. Вот так и живем. Экономисты и бизнес довольны.
>Но вот для новых домов можно бы параллельно и более красивую архитектуру сделать.
Поддержка/совмещение двух архитектур — весьма хлопотное занятие. Нужно не только построить, но еще и персонал обучить. К тому же последняя тенденция — покупать оператора на интересной территории, а не строить свою сеть.
Существуют. Речь шла про ценник решения. У ASR он тоже весьма хороший.
>Да и не цисками едиными…
Смена вендора, это тоже определенные затраты. Хотя рекомендации в какую сторону посмотреть — с удовольствием выслушаю.
>очень странный результат. И как считается эта цифра?
Считается очень просто; k = количество договоров / количество пользователей online.
Коэффициент одинаковый для Тольятти и Самары.
>Что-то мне подсказывает, что вы все равно исходите из «95% абонентов могут одновременно выйти в сеть»
Не могут. И поэтому не исходим из этого. На основе многолетней практики знаем когда какие колебания происходят. Колебания эти, как правило, не более 10%. И происходят не за 1 день. Поэтому держим запас чуть больше + имеем возможность расшириться (аплинки, сервера) очень быстро. + конечно мониторинг и отработанные процедуры по расширению. Тригер в системе мониторинга сработал — запустился механизм расширения. Перед сезонными колебаниями (сентябрь, НГ) — расширяемся заблаговременно. Вот так и живем. Экономисты и бизнес довольны.
>Но вот для новых домов можно бы параллельно и более красивую архитектуру сделать.
Поддержка/совмещение двух архитектур — весьма хлопотное занятие. Нужно не только построить, но еще и персонал обучить. К тому же последняя тенденция — покупать оператора на интересной территории, а не строить свою сеть.
Речь шла про ценник решения. У ASR он тоже весьма хороший.
Смотря какая нужна пропускная способность.
Хотя рекомендации в какую сторону посмотреть — с удовольствием выслушаю.
Ну например где-то писалось, что онлайм использует алкатели.
k = количество договоров / количество пользователей online.
В 3 часа ночи? Или ближе к вечеру, когда все пришли с работы? И вы так и не ответили: какова у вас переподписка по соотношению глобально маршрутизируемых адресов к числу договоров? Неужели 1/2? :)
Поэтому держим запас чуть больше + имеем возможность расшириться (аплинки, сервера) очень быстро.
Речь идет исключительно о маршрутизируемых адресах, т.е. о числе подключенных приблизительно одновременно клиентов. Даже если все они лишь раз в полчаса пингуют яндекс и больше ничего не делают.
>Смотря какая нужна пропускная способность.
10G с возможностью расширения до 20G. В дуплексе конечно, т.е. по 10G в обе стороны. ip unnumbered
>В 3 часа ночи?
В ЧНН (час наибольшей нагрузки). Т.е. максимум по графику. Это 21-22 часа.
Текущее соотношение — 0.61 (приходится еще некоторое количество IP задействовать из-за неровной балансировки).
>Речь идет исключительно о маршрутизируемых адресах, т.е. о числе подключенных приблизительно одновременно клиентов. Даже если все они лишь раз в полчаса пингуют яндекс и больше ничего не делают.
Да, именно так.
10G с возможностью расширения до 20G. В дуплексе конечно, т.е. по 10G в обе стороны. ip unnumbered
>В 3 часа ночи?
В ЧНН (час наибольшей нагрузки). Т.е. максимум по графику. Это 21-22 часа.
Текущее соотношение — 0.61 (приходится еще некоторое количество IP задействовать из-за неровной балансировки).
>Речь идет исключительно о маршрутизируемых адресах, т.е. о числе подключенных приблизительно одновременно клиентов. Даже если все они лишь раз в полчаса пингуют яндекс и больше ничего не делают.
Да, именно так.
10G с возможностью расширения до 20G. В дуплексе конечно
Так это мало. ASR1002-X (махонькая 2-юнитовая коробка), почти младший представитель линейки 1k, такое потянет. Не говоря уже о 9к. По GPL расценки навскидку: 65к за шасси 1002-X с 20G лицензией и 6-ю 1G портами, и по 30к за 10G порт (ага, не спорю, порты у них стоят безумных денег).
Текущее соотношение — 0.61
Я и говорю — странно как-то. Может, особенности заМКАДья, что ни у кого роутеров нет?
> Так это мало.
Дак мне нужно как минимум 4 шт (или 2 с полным резервом внутри одного шасси).
Не дешевая «красота» получается, при том что существующее решение на порядок дешевле и в принципе полностью устраивает.
>Я и говорю — странно как-то. Может, особенности заМКАДья, что ни у кого роутеров нет?
Удаленность от Москвы, конечно, накладывает свой отпечаток. Я думаю от вас мы года на 2-3 отстаем.
Дак мне нужно как минимум 4 шт (или 2 с полным резервом внутри одного шасси).
Не дешевая «красота» получается, при том что существующее решение на порядок дешевле и в принципе полностью устраивает.
>Я и говорю — странно как-то. Может, особенности заМКАДья, что ни у кого роутеров нет?
Удаленность от Москвы, конечно, накладывает свой отпечаток. Я думаю от вас мы года на 2-3 отстаем.
существующее решение на порядок дешевле и в принципе полностью устраивает.
Таким образом можно спуститься до хомячкового класса дэлинков опуститься. Еще на порядок дешевле, зависают не слишком часто, кого-то всем устраивают…
Но что шеститонник на порядок дешевле ASRов — это забавно :) GPL категорически возражает.
>Таким образом можно спуститься до хомячкового класса дэлинков опуститься. Еще на порядок дешевле, зависают не слишком часто, кого-то всем устраивают…
Чем вам не нравится DLink? Весьма не плох для доступа. На агрегации и в ядре, конечно циска.
>Но что шеститонник на порядок дешевле ASRов — это забавно :) GPL категорически возражает.
Я не говорил что существующее решение (PPTP) на шеститоннике.
Чем вам не нравится DLink? Весьма не плох для доступа. На агрегации и в ядре, конечно циска.
>Но что шеститонник на порядок дешевле ASRов — это забавно :) GPL категорически возражает.
Я не говорил что существующее решение (PPTP) на шеститоннике.
а wifi тогда вообще использовать как страшно. соседу и врезаться не надо в кабель.
Для защиты от этой ситуации я использую автоматический мониторинг длины кабеля до абонента.
Как только длина кабеля вдруг резко сокращается, создаётся тикет. Двоих подобных придурков уже поймали.
Пример, как это выглядит:
Как только длина кабеля вдруг резко сокращается, создаётся тикет. Двоих подобных придурков уже поймали.
Пример, как это выглядит:
DGS-3200-10:4#cable_diag ports 1-10Command: 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 -
ну наверное не совсем удобно мониторить несколько тысяч абонов, а если тупой коммутатор? тем более что кабельный тестер на длинках штука чудливая
А когда тест кабеля происходит, разве линк не отваливается?
Когда в кабель врезаются — линк тоже отваливается :-)
Скрипт ждёт следующего события — «восстановление линка + [dhcp запрос/ответ либо истечение 10 секунд]».
Также проводится плановое еженедельное тестирование — в 4-5 ночи на понедельник.
Это позволяет выловить жуликов и воров, которые врезались в кабель в момент дайнтайма мониторинга.
Скрипт ждёт следующего события — «восстановление линка + [dhcp запрос/ответ либо истечение 10 секунд]».
Также проводится плановое еженедельное тестирование — в 4-5 ночи на понедельник.
Это позволяет выловить жуликов и воров, которые врезались в кабель в момент дайнтайма мониторинга.
Во-первых, хотел бы сказать всем спасибо за отзывы. Даже не ожидал, что такая, несколько шуточная статья вызовет дебаты.
Способ мне нравится, спасибо за идею.
И, немного лирики:
Мне кажется, что сравнения с замками очень точно. Замок в двери не спасет от грабителей профессионалов, но спасет от дилетантов, а их куда больше.
PPPoE+PAP используют только маргинальные провайдеры, у них, видимо и к серверам есть доступ с внешнего мира по ssh.v1.
PPPoE+MS-CHAP не так-то просто взломать.
Веб-авторизация — а разница с PPPoE? Тот же логин пароль. Ip-tv? Что мешает использовать какой-нибудь MVR, а в случае с DSL другой vpi/vci?
Любая привязка мака к порту, по моему глубоком убеждению — лишний геморрой, который будет разрастаться по мере роста сети. Думаю, почему не нужно объяснять?
Есть движение людей, цель которого бегать по домам и искать не запороленный wi-fi. А чем проще получить халяву, тем она желанней. Подбор ключей, перехват сессий итд. — вещь не самая простая и требует ресурсов, времени и знаний. А врезка в кабель — не требует сколько-нибудь серьёзных умений.
И давайте не будем сравнивать интернет и телефон.
Спасибо.
Способ мне нравится, спасибо за идею.
И, немного лирики:
Мне кажется, что сравнения с замками очень точно. Замок в двери не спасет от грабителей профессионалов, но спасет от дилетантов, а их куда больше.
PPPoE+PAP используют только маргинальные провайдеры, у них, видимо и к серверам есть доступ с внешнего мира по ssh.v1.
PPPoE+MS-CHAP не так-то просто взломать.
Веб-авторизация — а разница с PPPoE? Тот же логин пароль. Ip-tv? Что мешает использовать какой-нибудь MVR, а в случае с DSL другой vpi/vci?
Любая привязка мака к порту, по моему глубоком убеждению — лишний геморрой, который будет разрастаться по мере роста сети. Думаю, почему не нужно объяснять?
Есть движение людей, цель которого бегать по домам и искать не запороленный wi-fi. А чем проще получить халяву, тем она желанней. Подбор ключей, перехват сессий итд. — вещь не самая простая и требует ресурсов, времени и знаний. А врезка в кабель — не требует сколько-нибудь серьёзных умений.
И давайте не будем сравнивать интернет и телефон.
Спасибо.
Купите коммутатор с IPMB и будет вам счастье, а так как вы рассказываете про врезку здесь любым методом можно получить инет, могу добавить еще минус к PPPoE — это маршруты для iptv которые нужно прописывать хомякам
А также видел кучу роутеров которые по pppoe могут прожевать скажем 20Мбит/сек, а на ipoe 60-80, да согласен вопрос решается в 70-80% обновлением ПО, Вообще сравнивать 2 технологии не совсем корректно, PPPoE хорошо использовать в неуправляемой сети.
А в каком месте у вас абоненты между собой маршрутизируются? Просто хочу понять как пойдет трафик если абонент из влана 101 захочет скачать файлик у абонента из влана 102.
У IPoE есть ещё одна большая проблема — отсутствие возможности контроля живучести абонентской CPE или компа в случае если шнурок подключается напрямую. Здесь есть несколько методик, позволяющих снизить даунтайм сервиса для абонента в случае возникновения той или иной проблемы на сети:
1. Выдавать короткую лизу. Вариант хороший, но повышает нагрузку на BRAS, который яростно атакуют постоянными запросами на обновление лизы.
2. Использование arping клиентским оборудованием для детектирования отвала шлюза. Тоже, казалось бы, хорошее решение, но далеко не все домашние CPE умеют делать arping.
3. Использование RFC 3203 для форсирования обновления лизы клиентом. И тут не без проблем — фичу мало кто поддерживает как на стороне BRAS, так и на стороне клиентских CPE.
Если срезюмировать, то практически все IPoE провайдеры идут по первому пути. Самая жесть, которую я встречал, была лиза в 5 минут длиной, что выливалось в то, что раз в 150 секунд каждый клиент делал запрос на обновление.
1. Выдавать короткую лизу. Вариант хороший, но повышает нагрузку на BRAS, который яростно атакуют постоянными запросами на обновление лизы.
2. Использование arping клиентским оборудованием для детектирования отвала шлюза. Тоже, казалось бы, хорошее решение, но далеко не все домашние CPE умеют делать arping.
3. Использование RFC 3203 для форсирования обновления лизы клиентом. И тут не без проблем — фичу мало кто поддерживает как на стороне BRAS, так и на стороне клиентских CPE.
Если срезюмировать, то практически все IPoE провайдеры идут по первому пути. Самая жесть, которую я встречал, была лиза в 5 минут длиной, что выливалось в то, что раз в 150 секунд каждый клиент делал запрос на обновление.
отсутствие возможности контроля живучести абонентской CPE или компа в случае если шнурок подключается напрямую.
Я не понял… Речь про отслеживание доступности CPE, или PE (браса)?
А зачем это? Типичному хомячку некуда фейловериться кроме как в пределах того же провайдера. Тут можно сделать VRRP для защиты от падения браса. Ну и некоторую избыточность на пути до браса. Всё. Свитч в доме никто все равно резервировать не будет хоть так, хоть этак.
Ну и всегда есть arp таймаут. Запись заекспайрилась, нового reply не дождались => у нас проблемы.
Хочется хомячку мгновенно видеть аварии на сети? Не вопрос. IP SLA или тому подобное, и шквал пингов на первый хоп. Ничего страшного для провайдеров — таких хомячков мало.
ericsson se100. врежиме dhcp-proxy с лизой 5 минут без видимой нагрузки держит более 1000 онлайн абонентов. это самый старый и самый слабый из серии. так что короткая лиза не проблема. у некоторых сессия больше месяца длится.
пруф:
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
Противопоставить мне нечего:) Любопытно взлянуть на коробку со 100k пользователей (не на se100, разумеется).
А мужики-то не знали.
Onlime работает по IPoE, Qwery работает по IPoE и даже Akado работает по IPoE поверх DOCSIS.
А насчет стандарта. Автор текста не в курсе про BroadBand Forum TR-101, например.
Советую почитать — полезно будет.
И, кстати, RFC описывают стандарты, протоколы, но никак не рекомендуемые архитектуры решений.
Onlime работает по IPoE, Qwery работает по IPoE и даже Akado работает по IPoE поверх DOCSIS.
А насчет стандарта. Автор текста не в курсе про BroadBand Forum TR-101, например.
Советую почитать — полезно будет.
И, кстати, RFC описывают стандарты, протоколы, но никак не рекомендуемые архитектуры решений.
Что то не пойму, какое отношение 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
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
Уважаемый. Вы хоть TR-101 читали дальше заголовка?
Очень советую изучать документ прежде чем писать глупости.
А насчет RFC — еще раз, нет ни одного RFC, который описывает end-to-end архитектуру. В этом и слабость RFC.
Очень советую изучать документ прежде чем писать глупости.
А насчет RFC — еще раз, нет ни одного RFC, который описывает end-to-end архитектуру. В этом и слабость RFC.
>Уважаемый. Вы хоть TR-101 читали дальше заголовка?
>Очень советую изучать документ прежде чем писать глупости.
Читал конечно. Поэтому и спросил. Первые 60 страниц можно смело пропустить, при прочтении остальных нужно тщательно фильтровать слова xDSL и ATM. Какое отношение этот документ имеет к обсуждаемой теме — лично для меня загадка.
Если и рекомендовать, что либо к прочтению — то это TR-145 Multi-service Broadband Network Functional Modules and Architecture. Кстати рекомендую.
>Очень советую изучать документ прежде чем писать глупости.
Читал конечно. Поэтому и спросил. Первые 60 страниц можно смело пропустить, при прочтении остальных нужно тщательно фильтровать слова xDSL и ATM. Какое отношение этот документ имеет к обсуждаемой теме — лично для меня загадка.
Если и рекомендовать, что либо к прочтению — то это TR-145 Multi-service Broadband Network Functional Modules and Architecture. Кстати рекомендую.
Вы в послесловии написали о необходимости пользователю диктовать свой mac адрес, дикие у вас однако провайдеры, наши сами смотрят на порту новый mac. Ни разу еще ни один провайдер из 3-х к которым я в Челябинске подключался не требовал от меня mac адрес.
Проблема решается всего-навсего страничкой авторизации. Что-нибудь не так? Переспросили у пользователя логин/пароль (с карточки, которую выдали при подключении).
самое зло, какое может быть.
А в чем, собственно, проблема?
1) Это не удобно. Надо искать бумажку или где записано. А что если я с телефоном в туалете в это время?!
2) Где мой доступ к домашнему NAS, если вдруг провайдер решил запросить авторизацию.
3) Технически я не хочу чтоб провайдер что-то подменял у меня и заставлял меня использовать свои DNS.
Я бы с таким провайдером точно не остался, особенно если бы были нормальные альтернативы. Я вообще только хочу чтоб провайдер выдал мне IP, канал и больше никуда не лез, а занимался качеством своих каналов и оборудования.
2) Где мой доступ к домашнему NAS, если вдруг провайдер решил запросить авторизацию.
3) Технически я не хочу чтоб провайдер что-то подменял у меня и заставлял меня использовать свои DNS.
Я бы с таким провайдером точно не остался, особенно если бы были нормальные альтернативы. Я вообще только хочу чтоб провайдер выдал мне IP, канал и больше никуда не лез, а занимался качеством своих каналов и оборудования.
1) Это неудобно для 2-3 человек из тысячи.
2) Авторизация запрашивается не просто так, а только если что-нибудь случилось.
3) При чем тут DNS?
Ну и в конце-концов я могу у себя в биллинге для конкретного абонента, которого это по каким-либо причинам не устраивает, ткнуть флажок «не использовать веб-авторизацию» :).
2) Авторизация запрашивается не просто так, а только если что-нибудь случилось.
3) При чем тут DNS?
Ну и в конце-концов я могу у себя в биллинге для конкретного абонента, которого это по каким-либо причинам не устраивает, ткнуть флажок «не использовать веб-авторизацию» :).
Как будто этому кулцхакеру Василию (который может обжать, врезаться и настроить) сложно договорится со всем этажом, что интернет будет идти через него за в 4ре раза меньшую стоимость чем они платят сейчас провайдеру.
Как-то ни о чем.
>не нужен дорогостоящий BRAS
И PPPoE и IPoE можно поднять на тазике.
>не нужно тратиться на подсети внешних адресов
Серые адреса можно в обоих случаях раздавать.
>схема, изображенная на рисунке 3
Врезаться можно и в PPPoE.
>не нужен дорогостоящий BRAS
И PPPoE и IPoE можно поднять на тазике.
>не нужно тратиться на подсети внешних адресов
Серые адреса можно в обоих случаях раздавать.
>схема, изображенная на рисунке 3
Врезаться можно и в PPPoE.
На мой взгляд PPPoE — зло. Даже какой-нибудь дешёвый miktroik RB751G в качестве домашнего роутера снизит свою пропускную способность в разы.
Пруф имеется?
Есть чипы, котрые оффлоадят обработку PPPoE на себя, на таких разница в производительности IPoE и PPPoE различается на уровне погрешности.
которые из SOHO (и даже средего офиса) роутеров имеют в себе такой чип?
Ну, например, Asus RT-N56U и его старший брат Asus RT-N65U, построенные на Raink RT3662.
а этот чип работает всегда, или если я добавлю хоть одно правило, то вся нагрузка уйдёт на процессор?
Не на то вы нападаете.
Указанный подход реально упростил жизнь пользователям. Проблем с пользователями по Ethernet — не так много, а особенно — с качеством их доступа в интернет. Куда хуже те, кто используют DSL-модем и у которых проблемы с физикой после каждого дождя.
А вот есть провайдеры с PPTP и/или L2TP и ужасным извращением, которое принято называть Russian Dual PPTP — когда я вижу всё это, реально хочется УБИВАТЬ. Уж лучше PPPoE, чем так жить.
Указанный подход реально упростил жизнь пользователям. Проблем с пользователями по Ethernet — не так много, а особенно — с качеством их доступа в интернет. Куда хуже те, кто используют DSL-модем и у которых проблемы с физикой после каждого дождя.
А вот есть провайдеры с PPTP и/или L2TP и ужасным извращением, которое принято называть Russian Dual PPTP — когда я вижу всё это, реально хочется УБИВАТЬ. Уж лучше PPPoE, чем так жить.
Простите, я больше двадцати лет на DSL сижу. У меня был интернет даже тогда, когда у местных Ethernet провайдеров были проблемы магистрального характера. А за дожди и ураганные ветры… Владивосток вам о чём нибудь говорит? Суровей края конечно бывают, но с нашими ветрами, дождями, тайфунами очень часто прикалываются воздушки местных провайдеров. А DSL — надёжен как скала!
UFO just landed and posted this here
Привязка к маку это очень нехорошо и неудобно. Она создает новые неудобства, при этом не решая старых. Вас что именно в описанной в статье ситуации беспокоит — то что Вася ворует интернет у Глаши или то, что он сидит в нем на халяву?
Ситуация на самом деле неприятная со многих сторон.
То, что Вася мне в этой ситуации не платит, а может, и мог бы — это самая малая из проблем.
Гораздо хуже то, что услуга, оказываемая Глаше, становится некачественной.
Мигнул свет в подъезде — железка в щитке зависла. Глаша считает, что я плохой провайдер.
Глаша случайно задела патчкорд и жалуется на «сетевой кабель не подключен» — а мой биллинг видит, что линк есть и все пары активны. Моя поддержка вводит её в заблуждение. Она опять приходит к выводу, что я плохой провайдер.
Вася ставит сниффер и влезает в её вконтактик. Глаша десять раз меняет пароль, выводит все вирусы, заходит даже с мобильника, а всё впустую. А виноват я — я не обеспечил безопасность.
Вася пишет «смерть жуликам и ворам» на каком-нибудь форуме. К Глаше приходят с обыском и изымают всю электронику от фоторамки до кардиостимулятора. Она не понимает, причём она тут. А виноват-то опять я — я опять не обеспечил безопасность!
Все примеры условны, но наглядно показывают, почему Васе не место в разрыве кабеля Глаши :-)
То, что Вася мне в этой ситуации не платит, а может, и мог бы — это самая малая из проблем.
Гораздо хуже то, что услуга, оказываемая Глаше, становится некачественной.
Мигнул свет в подъезде — железка в щитке зависла. Глаша считает, что я плохой провайдер.
Глаша случайно задела патчкорд и жалуется на «сетевой кабель не подключен» — а мой биллинг видит, что линк есть и все пары активны. Моя поддержка вводит её в заблуждение. Она опять приходит к выводу, что я плохой провайдер.
Вася ставит сниффер и влезает в её вконтактик. Глаша десять раз меняет пароль, выводит все вирусы, заходит даже с мобильника, а всё впустую. А виноват я — я не обеспечил безопасность.
Вася пишет «смерть жуликам и ворам» на каком-нибудь форуме. К Глаше приходят с обыском и изымают всю электронику от фоторамки до кардиостимулятора. Она не понимает, причём она тут. А виноват-то опять я — я опять не обеспечил безопасность!
Все примеры условны, но наглядно показывают, почему Васе не место в разрыве кабеля Глаши :-)
Первый пункт — мучение для клиента.
Особенно учитывая то, что половина клиентов вообще не поймёт, что это и как это. Простые работяги, домохозяйки, пенсионеры. Бесконечно далеки вы от народа :)
Третий пункт мешает подключать абонентское оборудование через свич.
При этом, злодею всё перечисленное не помешает никак.
Из моей практики — злодей поставил вайфай в щитке в разрыв. Даже не стал заморачиваться с протяжкой кабеля.
Данный факт был выявлен вторым способом.
Оставили роутер на месте неподключённым, рядом положили листочек с распечаткой пары статей УК РФ. :)
Особенно учитывая то, что половина клиентов вообще не поймёт, что это и как это. Простые работяги, домохозяйки, пенсионеры. Бесконечно далеки вы от народа :)
Третий пункт мешает подключать абонентское оборудование через свич.
При этом, злодею всё перечисленное не помешает никак.
Из моей практики — злодей поставил вайфай в щитке в разрыв. Даже не стал заморачиваться с протяжкой кабеля.
Данный факт был выявлен вторым способом.
Оставили роутер на месте неподключённым, рядом положили листочек с распечаткой пары статей УК РФ. :)
Прошли те времена, когда интернет стоил как заправка Белаза и для того, чтобы задуматься о врезке в чей-то кабель — нужно заболеть психическим расстройством. Проще соседу пойти к тете Глаше и договориться с ней платить за интернет 50/50, поставив у нее роутер и сделав себе ответление. Стремиться нужно к тому, чтобы услуга интернет рано или поздно стало максимально бесплатной, — это как базовая потребность: водопровод, электричество.
Насмешил. А разве водопровод, электричество бесплатны? Минимальные тарифиы за интернет обходятся дешевле, чем счёт за электричество. А вот школьники хитровывернутые не поленятся этим заняться, потому что на роутер один раз наковырять, чтобы потом вообще не платить вполне себе вариант. Из практики провайдера, в котором я работал, такие случаи встречались.
А кто вообще оперирует термином IPoE? IP over Ethernet — связка старше некуда. Приплетение туда опции 82 является не более чем частным взглядом. Лет 10 назад были ещё «авторизаторы» — это тоже вполне себе IPoE и прекрасно работало в своём времени. Но сдохло сугубо по экономическим причинам — инет перестали воровать и распространился HTTPS для чувствительных соединений.
Кстати, а кто мешает врезаться в провод с PPPoE? Злоумышленник просто виртуально присвоит себе адрес сервера, узнает логин/пароль и потом и будет им представляться жертве. Ни PPTP ни L2TP без использования сертификатов сервера (которые никто из операторов не юзает) не поможет.
Кстати, а кто мешает врезаться в провод с PPPoE? Злоумышленник просто виртуально присвоит себе адрес сервера, узнает логин/пароль и потом и будет им представляться жертве. Ни PPTP ни L2TP без использования сертификатов сервера (которые никто из операторов не юзает) не поможет.
Забавно читать:
Автор явно не шибко разбирается в народах нашей необъятной, но зачем-то вставляет такие интересные отступления.
Поясню. Ашот, скорей всего армянин. А вахабитское движение возможно на просторах нашей большой родины в Дагестане, Чечне или Ингушетии. Так же к этому движению причисляли маломальски всех не угодных по всей нашей необъятной, кто исповедует ислам. Армяне, чтобы вы понимали, христиане в своей основе. Поэтому когда Ашот, или его дедушка слышит это имя и рядом слово вахабит, то это вызывает очень сильное оскорбление и негодование. Потому что для армян мусульманин это уже плохо, а ещё и террорист и убийца, это вообще какая-то дикая жесть. Это такой же офтом, как и иллюстрация в статье про вахабита. Не пишите глупостей, в серьёзных статьях, тогда и не будете выглядеть начитанным опытным глупцом.
А статья в общем мне понравилась.
Что мешает потомственному ваххабиту Ашоту прийти...
Автор явно не шибко разбирается в народах нашей необъятной, но зачем-то вставляет такие интересные отступления.
Поясню. Ашот, скорей всего армянин. А вахабитское движение возможно на просторах нашей большой родины в Дагестане, Чечне или Ингушетии. Так же к этому движению причисляли маломальски всех не угодных по всей нашей необъятной, кто исповедует ислам. Армяне, чтобы вы понимали, христиане в своей основе. Поэтому когда Ашот, или его дедушка слышит это имя и рядом слово вахабит, то это вызывает очень сильное оскорбление и негодование. Потому что для армян мусульманин это уже плохо, а ещё и террорист и убийца, это вообще какая-то дикая жесть. Это такой же офтом, как и иллюстрация в статье про вахабита. Не пишите глупостей, в серьёзных статьях, тогда и не будете выглядеть начитанным опытным глупцом.
А статья в общем мне понравилась.
Sign up to leave a comment.
Проблема IPoE