Перейти к содержимому
Калькуляторы

Вопрос по IPv6 - организация работы пользователей

Добрый день!

Обращаюсь с таким вопросом. Смотрим на сеть IPv6 со стороны провайдера.

 

В интернете уже довольно много примеров и инструкций по настройке. Некоторые делятся опытом кто как настраивал, но реальных примеров "настрой и все заработает" пока что нет. Вряд-ли они и будут.

Примерно вот такая упрощенная схема.

 

Visio_maket.jpg

 

 

 

 

Согласно всех рекомендаций, выдаем каждому абоненту /56 сеть, DCHPv6-PD. В данном случае не принципиален вопрос что выступает в роли DCHPv6-сервера.

Помимо /56 нам надо выдать еще один адрес абоненту для самого роутера (на WAN интерфейс). Все роутеры находятся в одном общем VLAN. Итого, выделяем общий /64 на весь VLAN, запрещаем в анонсах RA от маршрутизатора автоконфигурацию, разрешаем только DHCPv6.

 

На уровне L2 у нас изоляции нет, абоненты могут делать что угодно. Изолируем их при помощи Traffic Segmentation. Теперь, взаимодействовать они не могут. Ну и мешать друг другу аналогично. Только через ядро.

 

Теперь, как работает схема.

Роутер абонента R10 запрашивает адреса. DHCPv6 сервер ему выдает:

- один IPv6 адрес, например 2001:db8:6783:ffff::100/64;

- блок, например 2001:db8:6783::/56.

Как роутер будет распоряжаться со своей /56 - не наша забота. Наша задача - обеспечить связность. Для этого нам нужен маршрут в сторону абонента. Допустим, мы его создаем вручную (в идеале конечно это все автоматизировать скриптами). Роутер R10 сам должен создать маршрут типа "ipv6 route ::/0 2001:db8:6783:ffff::1". А на R1 создаем руками:

ipv6 route 2001:db8:6783::/56 2001:db8:6783:ffff::100

 

И, по идее, уже должно все работать. Надеюсь, ничего не забыл...

 

Далее. Изоляция - это хорошо, но кто мешает абоненту прописать чужой IP вместо того, что ему выдает DCHPv6, и кому-то очень сильно напакостить? Да никто не мешает. Роутер R11 прописывает себе точно такой же WAN IP, как и у R10. Роутер провайдера R1 просто не будет знать куда слать пакеты, потому что таблица соседей ND будет постоянно меняться. И вот тут я придумал следующее - статические ND записи. По аналогии со статическими ARPами. А абонентам на портах - Port Security, Permanent, чтоб МАСи не меняли.

И Циска, и Джунипер делать статические записи умеют. Пример:

Static IPv6 Neighbors

 

You can manually define a neighbor in the IPv6 neighbor cache. If an entry for the specified IPv6 address already exists in the neighbor discovery cache—learned through the IPv6 neighbor discovery process—the entry is automatically converted to a static entry. Static entries in the IPv6 neighbor discovery cache are not modified by the neighbor discovery process.

 

 

ipv6 neighbor binding vlan vlan-id {interface type number | ipv6-address | mac-address} [tracking [disable | enable | retry-interval value] | reachable-lifetime value]

Example:

 

Router(config)# ipv6 neighbor binding reachable-entries 100

 

 

Adds a static entry to the binding table database.

 

В итоге, роутер R1 просто не будет отправлять запросы NS - у него статическая запись есть. А вот роутер злоумышленника R11 может засыпать сообщениями NA, NS, но вот роутеру провайдера фиолетово, так как "Static entries in the IPv6 neighbor discovery cache are not modified by the neighbor discovery process".

 

Вроде ничего важного не упустил. Вот такая схема. Роутинг между абонентами осущевствляет R1.

 

Собственно сам вопрос: как будет вести себя R1, получая "фиктивные" пакеты от R11? У меня есть подозрение, что в одну сторону пакеты будут проходить, а вот обратно R1 будет отправлять их на R10, хотя тот их не "заказывал". Но могу ошибаться, поэтому и спрашиваю...

По сути, данная схема - аналог статической ARP-записи. Но вот интересует как оно работает. В сети валом статей как это настроить, но вот подробно описать как это работает...

 

И еще есть одна "дыра" - абонент пропишет себе чужой диапазон. UDP DDoS можно кому-то устроить, и в Source IP будут адреса другого абонента.

 

Буду благодарен за советы!

Изменено пользователем MR_Andrew

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А для IPv4 вы как решаете аналогичную проблему? В чем принципиальное отличие проблемы:

Изоляция - это хорошо, но кто мешает абоненту прописать чужой IP вместо того, что ему выдает DCHPv6, и кому-то очень сильно напакостить?

от такой же для IPv4?

 

Некоторые делятся опытом кто как настраивал, но реальных примеров "настрой и все заработает" пока что нет. Вряд-ли они и будут.

Вот статья моего коллеги на тему IPv6. Пытались, но... пока слишком много "НО". :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А для IPv4 вы как решаете аналогичную проблему? В чем принципиальное отличие проблемы:

Изоляция - это хорошо, но кто мешает абоненту прописать чужой IP вместо того, что ему выдает DCHPv6, и кому-то очень сильно напакостить?

от такой же для IPv4?

 

В данном случае принимаем, что свичи "до отказа" напичканы функционалом IPv4 - Port Security, IPSG, DHCP Snooping, ARP Inspection, IGMP Snooping.

Функционал у них просто отличный, но вот IPv6 они не умеют.

 

На более скупом функционале (D-Link) - Address Binding, Traffic Segmentation. На ядре - Local Proxy ARP. Работает :)

Некоторые делятся опытом кто как настраивал, но реальных примеров "настрой и все заработает" пока что нет. Вряд-ли они и будут.

Вот статья моего коллеги на тему IPv6. Пытались, но... пока слишком много "НО". :)

 

Спасибо! Ознакомлюсь.

Конечно много НО, это бесспорно. На L2-оборудовании с поддержкой IPv6 таких проблем не будет - IP Sourсe Guard (Prefix Guard) сделали и горя не знаем. А вот на существующем...

 

Рано или поздно внедрять провайдерам надо будет. Вот только боюсь, что внедрять может быть придется раньше, чем обновится парк свичей. Поэтому, для себя прорабатываю схемы :)

Изменено пользователем MR_Andrew

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

На D-Link весь "скупой" функционал умеет все вышеперечисленное кошечное, только называется оно там по другому. Но многое зависит еще от реализации (раньше на D-Link'е это дико глючило) и от дизайна сети. В моем случае для ipv4 лучшим решением оказалась фильтрация пакетов по содержимому на доступе - 100% надежно и не использует софтовые ресурсы или логику коммутатора.

 

В случае IPv6 все пока не так радужно. Из д-линков опцию 82 для ipv6 умеет только ревизия /C1. Новые гигабитные коммутаторы пока еще не умеют, а старые - не умеют и не будут. И есть большие сомнения что ACL для IPv6 будут отрабатывать так, как ожидалось.

 

Так что внедрение откладывается не столько из-за нежелания, сколько из-за технических сложностей.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

(раньше на D-Link'е это дико глючило)

Отож.

В случае IPv6 все пока не так радужно. Из д-линков опцию 82 для ipv6 умеет только ревизия /C1. Новые гигабитные коммутаторы пока еще не умеют, а старые - не умеют и не будут. И есть большие сомнения что ACL для IPv6 будут отрабатывать так, как ожидалось.

Совсем не радужно. Обеспечить безопастность пользователей оказалось крайне не простой задачей.

 

Так что внедрение откладывается не столько из-за нежелания, сколько из-за технических сложностей.

Согласен. Больно много препядствий.

 

Но все же - моя схема будет работать, как считаете? Хоть какую-то безопастность она вроде бы обеспечивает...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

/56 много, /64 вполне достаточно. На /56 можно своего небольшого провайдера сделать.

По остальному не скажу.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В данном случае принимаем, что свичи "до отказа" напичканы функционалом IPv4 - Port Security, IPSG, DHCP Snooping, ARP Inspection, IGMP Snooping.

Функционал у них просто отличный, но вот IPv6 они не умеют.

Отсюда простой вывод - юзать схему VLAN per customer -> от свичей доступа требуется только VLAN.

Все остальное рулить на нормальных свичах агрегации и приземлять на нормальном BRAS.

Т.е. еще раз - не нужно вкладывать деньги на модернизацию свичей доступа - нужно вложить в интеллектуальный современный "центр".

 

P.S. Сами пока не представляем как слезть с L2TP на IPoE на живых абонентах (десятки тысяч их).

Но это другая тема. А вот раздать IPv6 в тунели типа pppoe или l2tp - в теории куда проще, чем ipoe.

(но тоже пока нечем похвастаться - много чего еще не поддерживает у нас (например: биллинг/радиус/скрипты/СОРМ и т.д, что накрутилось за десятки лет существования ipv4)).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Но все же - моя схема будет работать, как считаете? Хоть какую-то безопастность она вроде бы обеспечивает...

Честно, не готов ответить конкретно по этой схеме. У себя я просто попробую действовать по уже проторенной дорожке - ACL.

И еще, мне кажется, что безопасность в IPv6 на доступе на данном этапе не так актуальна. Можно вообще без всяких фильтров внедрять, никто не начнет сразу эксплуатировать слабые места и "дыры" сети. В IPv4 тоже существует много потенциально уязвимых мест, которые мало кто закрывает и ничего - все работает. А когда это станет актуально для IPv6 там, глядишь, уже и доступ поменяется и ядро.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

И еще, мне кажется, что безопасность в IPv6 на доступе на данном этапе не так актуальна

 

Думаю, что безопасность весьма актуальна для ipv6.

Так как уже много статей доходчиво и популярно объясняют векторы злоупотреблений (напомню, IPv6 включен по дефолту в современных ОСях).

Хотя бы на хабре/гиктаймс описаны способы, как заставить трафик юзеров черех себя идти, как свой трафик отправить через соседа и т.д.

 

P.S.

В IPv4 тоже существует много потенциально уязвимых мест, которые мало кто закрывает и ничего - все работает

Например?

 

У себя я просто попробую действовать по уже проторенной дорожке - ACL.

Как показала практика - на определенном масштабе сети - это уже весьма хреновый вариант, начиная от того, что возникает со временем зоопарк свичей из разных поколений и вендоров,с разными ACL и заканчивая тем, что размазывать логику "защиты" на сотни/тысячи свичей доступа нифига не надежно (в теории все хорошо, на практике - это ад. Я знаю о чем говорю. В итоге пришел к идеологии - от самого простого доступа с поддержкой влан и полной сегментацией - и умным центром, где все и рулится)

Еще раз уточню - важна поправка на объем сети.

В небольшой сети оправданы любые извращения )

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Например?

Можно вручную нарисовать себе метку 802.1q и отправить данные в другой vlan.

Можно сгенерировать большое число DHCP Discovery и зафлудить DHCP и MySQL провайдера.

Можно сгенерировать большое число IGMP-пакетиков и зафлудить Radius и вызвать избыточную нагрузку на CPU коммутаторов.

Можно при помощи обычного ping вызвать отказ в обслуживании некоторых маршрутизаторов провайдера.

Можно подставить себе MAC шлюза и вызвать проблемы коммутации во всем сегменте.

Можно отвечать на все подряд ARP и также вызвать проблемы коммутации.

Можно сгенерировать большое число пакетиков с поддельными SRC IP, и исчерпать весь пул внешних адресов, парализовав работу всей сети.

Можно организовать DDoS атаку тем же способом, что описан выше.

Можно тем же способом пробить ограничения trusted hosts на коммутаторах и помешать их нормальной работе.

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

Можно начать вещать мультикаст на тех же группах, что использует провайдер.

Можно исчерпать весь свободный пул DHCP.

Да и в конце концов можно стать воздушной планетой, а можно - воздушным асом. © :)

 

Много есть способов чтобы создать какую то проблему в сети и без IPv6. Да, некоторые топологии исключают некоторые проблемы by design, но серебрянной пули не существует. И все как то живут и работают, услугу предоставляют.

 

Думаю, что безопасность весьма актуальна для ipv6.

 

Проблема безопасности IPv6 не актуальна, она вероятна. Но эта вероятность достаточно низка. Если сегодня взять и забить на безопасность IPv6, то с вероятностью 99.99% ничего не случится. И завтра тоже. И послезавтра. Но думать над этим надо, я согласен. Но на первый момент, имхо, достаточно защитить только свои устройства и сервера.

 

Как показала практика - на определенном масштабе сети - это уже весьма хреновый вариант

...

важна поправка на объем сети.

А где эта граница? У меня на доступе сейчас 3200 коммутаторов, это так себе/средне/пойдет? И те же ACL я же не рисую вручную. Так что будь коммутаторов не 3200, а 6400, то это одно и то же.

Изменено пользователем xcme

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Все эти детские болезни из 2000-х на неуправляемых свичах?

 

Можно вручную нарисовать себе метку 802.1q и отправить данные в другой vlan.

Нельзя - ingress check vlan

Можно сгенерировать большое число DHCP Discovery и зафлудить DHCP и MySQL провайдера.

нельзя

Любой свич имеет функцию ограничения к-ва DHCP запросов в сек с юзерского порта.

 

Можно сгенерировать большое число IGMP-пакетиков и зафлудить Radius и вызвать избыточную нагрузку на CPU коммутаторов.

Нельзя - на свичах есть функция ограничения игмп пакетов в сек с юзерского порта.

И вообще мультик потиху уйдет - OTT сервисы юникастовые коммерчески/маркетингово/принудительно убьют нафиг все "локальные" полулегальные iptv в ближайшие 5-10 лет )

 

Можно при помощи обычного ping вызвать отказ в обслуживании некоторых маршрутизаторов провайдера.

Нельзя - любой маршрутизатор или фаер на линупсе умеет тротлить ппс icmp и другие пакеты

 

Можно подставить себе MAC шлюза и вызвать проблемы коммутации во всем сегменте.

Нельзя - есть куча фич, которые не дадут это сделать (всякие arp inspection).

А если юзать vlan на юзера - вообще пофиг - один юзер - один сегмент.

Можно отвечать на все подряд ARP и также вызвать проблемы коммутации.

Нельзя - есть куча фич, которые не дадут это сделать (всякие arp inspection).

А если юзать vlan на юзера - вообще пофиг - один юзер - один сегмент.

Любой приличный свич, брас, роутер, фаервол на линуксе умеет тротлинг к-во арп запросов/пакетов в сек

Можно сгенерировать большое число пакетиков с поддельными SRC IP, и исчерпать весь пул внешних адресов, парализовав работу всей сети.

Нельзя.

А из своих пулов вручную не пропишешь - никакой брас не даст этого сделать для pppoe/l2tp/pptp/ipoe - если юзер не получил адрес через radius/dhcp.

Тем более чужие ипы не пройдут - любой нормальный провайдер вообще дропает все неизвестные src ипы, которые идут транзитом со стороны юзеров.

 

Можно организовать DDoS атаку тем же способом, что описан выше.

Нельзя. Выше описано почему это не возможно.

 

Можно тем же способом пробить ограничения trusted hosts на коммутаторах и помешать их нормальной работе.

Нельзя. По тем же причинам

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

Любые проблемы кеширования и DDOS - являются серьезными, но мы сечас вообще-то не про это.

Мы про детские проблемы организации доступа, и про ipv4 против ipv6.

Можно начать вещать мультикаст на тех же группах, что использует провайдер.

Нельзя.

Если вы все еще мучаете мультикаст - то любой современный свич имеет функцию IGMP/Multicast фильтрации, которая для юзерских портов не допустит вещания от клиента в сеть.

А лишь разрешит подписываться ему на разрешенные группы мультикаст вещания.

Я юзал MVR - он льет разрешенный юзеру мультик из мультикаст влан в юзерский. Наоборот - не нальет (из юзерского влана в другой юзерский или в мультикаст влан).

 

Много есть способов чтобы создать какую то проблему в сети и без IPv6. Да, некоторые топологии исключают некоторые проблемы by design, но серебрянной пули не существует. И все как то живут и работают, услугу предоставляют.

Вы не путайте детские проблемы организации сети доступа и вообще фундаментальные проблемы IP любой версии и пакетной передачи в глобальных сетях в частности.

Никто не спорит, что есть много проблем и их надо как-то решать... (Самое стремное - DDOS снаружи, который вы никак не контролируете и от он уже прилетел к вам со всего света и занял всю трубу (если речь про провайдера доступа) или занял все прочие ресурсы (если речь о хостинге и сервисах))

 

А где эта граница? У меня на доступе сейчас 3200 коммутаторов, это так себе/средне/пойдет? И те же ACL я же не рисую вручную. Так что будь коммутаторов не 3200, а 6400, то это одно и то же.

Это приличное к-во. Но неужели Вы не понимаете о какой проблеме я говорю - о проблеме, когда логика/конфиги разбросаны по тысячам свчией доступа.

Я понимаю, что все автоматизировано.

Но акутальность конфигов соблюсти на счиах доступа сложно. Сравните - когда все рулится на свчиах/брасах в центре.

Я о том, что когда наступает какое-либо событие и отсылается команда на свич (например: ACL добавить/удалить/отредактировать) - а в это время не было эл-ва в этом доме.

А еще бывает просто в свичах доступа не пройдет команда - вообще управление отваливается на время. При этом форвард юзерского трафа нормально аппаратно свитчится в это время.

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

В общем - проблемка есть. Рулить несколькими свчиами ядра и брасом проще по определению, чем рулить логикой на тысячах разных свчией доступа.

Неспа?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В итоге я щитаю, мы вернулись к тому, что - на ipv4 на самом деле все детские болезни решены и свичи доступа набиты функционалом для ipv4.

Для ipv6 - пока все слабовато. И для существующих свичей врядли сильно улучшиться.

И никто пока не собирается из-за этого выкидывать деньги на апгрейд доступа.

Что приводит к мысли - нужно юзать влан на юзера и перенести весь фуекционал в центр - вкладывать деньги в брас с поддержкой ipv6 (если еще нету нормального).

Либо пока не тратить деньги и продолжать динамить/игнорить ipv6.

Что мы и наблюдаем.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нельзя

...

Я не про то, что это не решаемые проблемы, а про то, что о многих попросту не задумываются и даже не пытаются решать, хотя в их топологии проблемы возможны. При этом сеть не падает (хотя могла бы), все работает. Раньше сети вообще были на 100% тупом доступе и не намного более умном ядре и все работало.

 

У меня сейчас есть участки, где нет практически никаких фильтров, при этом все работает так же, как и там, где все ненужное жестко порезано.

 

А для IPv6 все это можно еще поделить на 100.

 

В остальном (про vlan-per-customer, брасы и т.п.) я согласен, просто мы немножко о разном. :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Теперь и я понял, о чем Вы )

Похоже, мы пришли к согласию.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

/56 много, /64 вполне достаточно. На /56 можно своего небольшого провайдера сделать.

По остальному не скажу.

 

RIPE (если не путаю) рекомендует каждому абоненту по /56. Конечно, если это обычный роутер абонента, который обслуживает максимум десяток устройств, то само собой. Но если это небольшая сетка (организация, скажем), то им надо /56 давать.

Вам что, адресов жалко? :)

 

Отсюда простой вывод - юзать схему VLAN per customer -> от свичей доступа требуется только VLAN.

В плане безопастности это просто идеальная схема. А вот в плане реализации - крайне сложная.

 

Все остальное рулить на нормальных свичах агрегации и приземлять на нормальном BRAS.

Да, но:

1. А вот не все свичи умеют 4к ВЛАНов. Есть свичи с жестким ограничением числа ВЛАНов на нем.

2. А если абонентов больше (и намного!), чем 4к? Вот и сели в лужу.

А ставить в поле L3 железку такого уровня, чтоб все умела (Unnumbered, IPv6), невозможно. Думаю всем понятно почему и объяснять не надо.

 

 

И еще, мне кажется, что безопасность в IPv6 на доступе на данном этапе не так актуальна.

Еще и как актуально! С этого начинать вообще надо. А то если делать "и так сойдет", то такая сеть долго не протянет.

 

В IPv4 тоже существует много потенциально уязвимых мест, которые мало кто закрывает и ничего - все работает.

Это уже на совесте администраторов сети.

 

Думаю, что безопасность весьма актуальна для ipv6.

Полностью согласен. Навредить можно как угодно и кому угодно. Запускать, даже для тестов, надо уже с глубоким пониманием того чем это чревато.

Заменить весь L2 на "IPv6 Support" задача трудная. Пройдет еще очень много времени. Конечно, когда коммутаторы будут поголовно уметь:

- RA Guard;

- DHCPv6 Snooping;

- ND Inspection;

- IPv6 Source Guard (Prefix Guard);

- ACLv6;

- DHCP-relay + Options

 

то данная тема будет вообще не актуальная. Все будет по полной красоте фильтроваться на доступе, и такая сеть будет супер-стабильно работать.

 

А если, как предлагает xcme, и так запустить, то я вам в сеть тыкну роутер в ЛАН порт с поддержкой SLAAC IPv6 (RA-анонсы), или DHCPv6, и будете вы меня очень долго ловить. Или через механизм DAD всем подряд буду отвечать "IP занят", и компьютеры абонентов будут до бесконечности генерировать себе ИП-адреса.

 

Короче говоря, навредить - масса возможностей. Без изоляции на Л2 просто никак.

 

Еще раз уточню - важна поправка на объем сети.

Сейчас идет тенденция к глобализации. Мелкие сетки продаются, из совокупности мелких вырастают большие. Надо делать расчет на большой объем сети. И везде должна быть единая схема.

 

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

 

И тогда самые высоконагруженные ветки, с годами, можно будет заменить на полноценное железо с массой функционала, а в какие-то регионы, где, например, всего пару тысяч абонентов, вывести весь хлам и сделать там VLAN per user. И будет красота.

 

Можно вручную нарисовать себе метку 802.1q и отправить данные в другой vlan.

Можно сгенерировать большое число DHCP Discovery и зафлудить DHCP и MySQL провайдера.

Можно сгенерировать большое число IGMP-пакетиков и зафлудить Radius и вызвать избыточную нагрузку на CPU коммутаторов.

Можно при помощи обычного ping вызвать отказ в обслуживании некоторых маршрутизаторов провайдера.

Можно подставить себе MAC шлюза и вызвать проблемы коммутации во всем сегменте.

Можно отвечать на все подряд ARP и также вызвать проблемы коммутации.

Можно сгенерировать большое число пакетиков с поддельными SRC IP, и исчерпать весь пул внешних адресов, парализовав работу всей сети.

Можно организовать DDoS атаку тем же способом, что описан выше.

Можно тем же способом пробить ограничения trusted hosts на коммутаторах и помешать их нормальной работе.

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

Можно начать вещать мультикаст на тех же группах, что использует провайдер.

Можно исчерпать весь свободный пул DHCP.

Все эти детские болезни из 2000-х на неуправляемых свичах?

 

Огромное спасибо, что ответили вместо меня :) Сам хотел написать, но у меня на тот момент лимит сообщений на форуме был исчерпал. Вы все описали вместо меня. Спасибо!

 

 

Можно подставить себе MAC шлюза и вызвать проблемы коммутации во всем сегменте.

Это вообще шедерв)

Даже самые древние комутаторы умеют Port Security и IP Source Guard.

 

Можно исчерпать весь свободный пул DHCP.

Для этого DCHP провайдера должен выдавать ИП только по связке МАС-ИП. Тогда у абонента будет всегда один и тот же адрес. И если этот абонент взломает сервер пентагона - провайдер, по запросу людей в черном, выдаст всю информацию про абонента, а не будет сутками рыться в логах в поисках того, кто этот ИП использовал в указанный промежуток времени.

 

Для ipv6 - пока все слабовато. И для существующих свичей врядли сильно улучшиться.

Согласен. Увы, это так.

 

xcme, man781 - спасибо за дискуссию!

Хотя ответа на свой вопрос я так и не получил. Придется дома делать лабу. Благо, что для этого все есть.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Имхо, без влан на пользователя с ipv6 делать нефиг.

И про то, что агрегация в полях невозможна, я конечно не знаю как у вас, но арендовать 1кв.м. настенной площади в ближайшем офисном здание/магазине с охраной проблем у нас не вызывало. Зачастую это является неотъемлемой частью ТУ для юриков/застройщиков

Изменено пользователем SyJet

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Даже самые древние комутаторы умеют Port Security и IP Source Guard.

Вопрос не в том, что это легко решить, а в том, какова вероятность что проблема вообще возникнет?

 

Для этого DCHP провайдера должен выдавать ИП только по связке МАС-ИП.

Не надо только воспринимать это как трудности, с которыми я не справился. :) Как раз наоборот.

 

Но, видимо, мне так и не удалось донести основной посыл поста. А он в том, что все это - гипотетические проблемы, которые никогда не возникнут! На практике юзер лезет в контактик или на порнолаб, ему не до хаков. Когда вы введете IPv6 он этого даже не заметит. Да и я, кстати, заметил случайно. :) Пока в отпуске был коллеги включили IPv6, случайно глянул - оказывается я на некоторые ресурсы по IPv6 хожу. Потом нашли проблему в ядре (SCE8000 не корректно хавает большие префиксы) и все выключили. Ничего не взорвалось, ни один хомячок не пострадал. :)

 

Вы лучше скажите, много вы помните за последние 5 лет в вашей сети случаев, когда кто-то целенаправленно что-то пытался сломать?

 

p.s. Я не говорю о том, что не надо делать свою сеть более безопасной. Надо, конечно, но без фанатизма. :)

Изменено пользователем xcme

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Имхо, без влан на пользователя с ipv6 делать нефиг.

есть еще вполне реальный вариант. Как для тестового запуска как раз подойдет. Traffic Segmentation, на ВЛАН выделяем /64, используем SLAAC. Каждый сам себе генерирует ИП, полная изоляция.

Но.... Именно полная изоляция. Друг друга абоненты из одного ВЛАНа пинговать не будут. Зато мешать друг другу точно не будут :)

 

агрегация в полях невозможна,

не агрегация, а терминация.

 

 

но арендовать 1кв.м. настенной площади в ближайшем офисном здании/магазине с охраной проблем у нас не вызывало

ага, а еще генератором, человеком, который будет его заводить, кондиционером, круглосуточным доступом, и в земле прорыть шахту и завести огромный жмут оптики.

 

А потом застройщику (владельцу) ударит в голову снести стену, и вам отрубят оптику с 5-10к абонентов. Или арендную плату задрать до заоблачной.

Я лично знаю такой случай, когда в офисном центре снесли стену вместе с ящиком. Прислали монтажника на обследование, чего абоненты (юрики) жалуются. А там лежит куча строймусора и сверху ящик со свичем. Самое смешное было в том, что обрезали витую пару, а оптику и питание оставили. И свич как бы работает)))

 

Зачастую это является неотъемлемой частью ТУ для юриков/застройщиков

А что в спальных районах делать прикажете? Вот я например живу на окраине города, хотя до метро тут 5-7 минут на маршрутке. Нет тут офисных центров. И что делать прикажете?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вопрос не в том, что это легко решить, а в том, какова вероятность что проблема вообще возникнет?

просто огромная. Китайские роутеры типа Tenda, дешевые Асус (старые) такое вытворять умеют... А еще есть роутер, вставленный в ЛАН порт.

 

Не надо только воспринимать это как трудности, с которыми я не справился. :) Как раз наоборот.

А я Вас и не критикую :) Не имею такого права.

 

все это - гипотетические проблемы, которые никогда не возникнут!

еще и как возникнут...

 

Вы лучше скажите, много вы помните за последние 5 лет в вашей сети случаев, когда кто-то целенаправленно что-то пытался сломать?

Вам покажется смешно, но у меня практика работы всего чуть более 2-х лет)

Но такие случаи я знаю. "Одна паршивая овца все стадо портит". В большинстве случаев как раз получается случайно.

 

Я даже слышал про случаи, когда свичи воровали, чтоб вытащить оттуда конфиг и найти уязвимости, а потом устранить конкурента... Стыдно такое слушать, люди у нас не честные бывают.

 

Найдется как-то кулхацкер, который захочет поиграться с генератором трафика, и будет беда.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Но, видимо, мне так и не удалось донести основной посыл поста. А он в том, что все это - гипотетические проблемы, которые никогда не возникнут! На практике юзер лезет в контактик или на порнолаб, ему не до хаков. Когда вы введете IPv6 он этого даже не заметит. Да и я, кстати, заметил случайно. :) Пока в отпуске был коллеги включили IPv6, случайно глянул - оказывается я на некоторые ресурсы по IPv6 хожу. Потом нашли проблему в ядре (SCE8000 не корректно хавает большие префиксы) и все выключили. Ничего не взорвалось, ни один хомячок не пострадал. :)

 

Вы лучше скажите, много вы помните за последние 5 лет в вашей сети случаев, когда кто-то целенаправленно что-то пытался сломать?

Недавно был целенаправленный случай. Но ввиду больших масштабов, это случается. Да, в целом, специально редко гадят в сеть оператора. Но случайно(криво настроенные роутеры, кривое железо) и т.д. - на регулярной основе. Чтоб сделать native IPv6 без влан-на-юзера нужно ещё больше всяческих извращений чем всякие IPMB в IPv4, тут всеми любимый длинк может не успеть допилить софт до end-of-sale железа :) . Хорошо тем, у кого PPPoE, поменял/допилил брас и IPv6 внедрено и плохо тем, кто наколхозил в "лихие" 2000-е L3-агрегацию и прочую веселуху

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

И вообще мультик потиху уйдет - OTT сервисы юникастовые коммерчески/маркетингово/принудительно убьют нафиг все "локальные" полулегальные iptv в ближайшие 5-10 лет )

Мультик никуда не уйдёт, это уникальная и полезная технология, которая теперь лежит в основе работы IPv6.

Мультик для иптв - да, это давать абонентам не серьёзно, если только граница отвественности оператора не кончается в hdmi порте приставки.

 

Нельзя - любой маршрутизатор или фаер на линупсе умеет тротлить ппс icmp и другие пакеты

Некоторые роутят всякими коммутаторами, вот они то и могут не выдержать.

 

Для ipv6 - пока все слабовато. И для существующих свичей врядли сильно улучшиться.

Влан на юзера и нет проблем.

 

Что приводит к мысли - нужно юзать влан на юзера и перенести весь фуекционал в центр - вкладывать деньги в брас с поддержкой ipv6 (если еще нету нормального).

Я вот тут уже который год "каркаю" что как изобретут передачу данных на связанных квантах (лет через 5-15) так оно везде примерно по такой схеме и начнёт работать.

 

Проблема безопасности IPv6 не актуальна, она вероятна.

Она актуальна для юзера - теперь чёто с фаерволом надо делать, раньше нат тупо всё резал.

Зато админам админить удобно, и расцвет п2п нас только ждёт.

 

Да, но:

1. А вот не все свичи умеют 4к ВЛАНов. Есть свичи с жестким ограничением числа ВЛАНов на нем.

2. А если абонентов больше (и намного!), чем 4к? Вот и сели в лужу.

куинку делать. Иногда можно и патчкордиком.

 

- RA Guard;

- DHCPv6 Snooping;

- ND Inspection;

- IPv6 Source Guard (Prefix Guard);

- ACLv6;

Вот это всё делается на обычных ACL, просто нужно включить голову и рассчитать маски и оффсеты.

А то что вы перечислили это маркетинговые фичи, когда для офисных админов в вебсмартах сделают интерфейсы с такими словами.

Но это всё не нужно если хомяк может обмениватся пакетами только с провайдерской железкой.

 

плохо тем, кто наколхозил в "лихие" 2000-е L3-агрегацию и прочую веселуху

Там же тоже есть целая пачка технологий как по IPv4 выдавать тунелями и прочей хренью IPv6.

Кажется кто то из французов делился опытом в одном из RFC.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

не агрегация, а терминация.

Хрен редьки не слаще, у меня это на одном уровне

ага, а еще генератором, человеком, который будет его заводить, кондиционером, круглосуточным доступом, и в земле прорыть шахту и завести огромный жмут оптики.

Плохому танцору яйца мешают, так что всегда есть решения, когда кондиционер не нужно, инвертер+200аh вполне достаточно, нет так второй 200аh

А что в спальных районах делать прикажете? Вот я например живу на окраине города, хотя до метро тут 5-7 минут на маршрутке. Нет тут офисных центров. И что делать прикажете?

Придомовой магазин, где сигареты и пепси покупаете. Ну не верю, что их нет. Опсосы вон на столбах шкафы ставят, на крышах бски ценой как пять коммутаторов, и ничего. Все это отмазки отдела развития сети и не более.

Изменено пользователем SyJet

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вот это всё делается на обычных ACL, просто нужно включить голову и рассчитать маски и оффсеты.

А то что вы перечислили это маркетинговые фичи, когда для офисных админов в вебсмартах сделают интерфейсы с такими словами.

 

Не буду с Вами спорить. Но я на практике убедился, что далеко не все можно резать АЦЛями.

 

Но это всё не нужно если хомяк может обмениватся пакетами только с провайдерской железкой.

 

да понятно, что это - самый идеальный вариант. Но вот только далеко не самый простой в реализации. Я бы сказал один из самых сложных.

 

 

Плохому танцору яйца мешают, так что всегда есть решения, когда кондиционер не нужно, инвертер+200аh вполне достаточно, нет так второй 200аh

 

не буду с Вами спорить. Но по моему мнению, L3 в поле - зло. Никому не навязываю :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

не буду с Вами спорить. Но по моему мнению, L3 в поле - зло. Никому не навязываю :)

 

К сожалению, либо так, либо mpls - при арендованных l3 каналах.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

К сожалению, либо так, либо mpls - при арендованных l3 каналах.

 

Или гнать до ядра по L2, но не более 4000 пользователей. Может быть, это даже оправданно. Это сейчас 9 тыс пользователей в 8 Гбит влазят свободно. Это при 100 мбит и 1 Гбит тарифах. В будущем, трафик будет расти. Может как раз 4 тыс пользователей на 1 узел будет и нормально.

Время покажет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.