MR_Andrew

Здравствуйте! 6 раз попробовал влить в обычный свежекупленный у вас unifi(mac на 24: а не на DC:) - не заводится. Пробовал разные прошивки BZ.v5.3.5.9634.120321.2303.bin BZ.v5.3.7782.110301.2247.bin BZ.v5.5.12536.120806.1601.bin Чувствую себя полным идиотом, ибо ранее 7 штук уже перепрошил, в т.ч. и LR реанимировал... Аналогично. Пробовал BZ.v5.3.7782.110301.2247.bin и BZ.v5.5.12536.120806.1601.bin. Смог завести ее только на BZ.v5.5.2.14464.130315.0303.bin. Вот на ней работает :) Именно... Видать какая-то новая HW ревизия вышла. В общем и целом - все хорошо, кроме одного... Не горит ЛЕД индикация. Вообще. http://community.ubnt.com/t5/airOS-SDK-Custom-Development/Building-AirOS-5-2-1-5-3-SDK-for-UniFi-AP-s-For-Standalone-Mode/td-p/114521/page/8 последнее сообщение темы. У меня аналогично: "Засветить" у меня не получается вообще никак. А надо.... Может кто-то смог решить эту проблему? Пусть она не мигает, а хоть просто зеленым светит. Но надо чтоб хоть как-то признаки жизни подавала.

И все же мне кажется, что предложенная мною в шапке схема будет вполне адекватно работать. Проделанная дома лаба (правда, криворовато проделана честно признаюсь) показала, что подменить neighbor discovery запись на маршрутизаторе ой как не просто. А если ее вообще статическую сделать, то и подавно. Если реально кто-то будет упорно пытаться "взломать" сеть методом прописывания себе чужих адресов, то "жертва" (чьи адреса отберут) и не заметит ничего даже. И реально очень сильно сомневаюсь (изначальный вопрос был как раз в этом!), что фиктивные пакеты выйдут куда-то за пределы маршрутизатора провайдера. P.S. Очень приятно удивлен, но на комутаторе без ИПв6 оказалась отличная поддержка Аксес листов: Vty-0(config)#access-list ipv6 extended 1111 Vty-0(config-ext-ipv6-acl)#? Configure commands: deny Specifies packets to drop end Exits from configure mode exit Exits from access-list configure mode help Description of the interactive help system no Negates a command or sets its defaults permit Specifies packets to permit Vty-0(config-ext-ipv6-acl)#permit ? any An abbreviation for the source IPv6 prefix ::/0 host Configures source host source-ipv6-prefix/prefix-length Source IPv6 network or class of networks Vty-0(config-ext-ipv6-acl)#permit host ? X:X:X:X::X Specifies source IPv6 address Vty-0(config-ext-ipv6-acl)#permit any ? any An abbreviation for the destination IPv6 prefix ::/0 destination-ipv6-prefix/prefix-length Destination IPv6 network or class of networks Итого, если есть такой свич, то реально внеднять ИПв6 будет гораздо проще.

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

Не буду с Вами спорить. Но я на практике убедился, что далеко не все можно резать АЦЛями. да понятно, что это - самый идеальный вариант. Но вот только далеко не самый простой в реализации. Я бы сказал один из самых сложных. не буду с Вами спорить. Но по моему мнению, L3 в поле - зло. Никому не навязываю :)

просто огромная. Китайские роутеры типа Tenda, дешевые Асус (старые) такое вытворять умеют... А еще есть роутер, вставленный в ЛАН порт. А я Вас и не критикую :) Не имею такого права. еще и как возникнут... Вам покажется смешно, но у меня практика работы всего чуть более 2-х лет) Но такие случаи я знаю. "Одна паршивая овца все стадо портит". В большинстве случаев как раз получается случайно. Я даже слышал про случаи, когда свичи воровали, чтоб вытащить оттуда конфиг и найти уязвимости, а потом устранить конкурента... Стыдно такое слушать, люди у нас не честные бывают. Найдется как-то кулхацкер, который захочет поиграться с генератором трафика, и будет беда.

есть еще вполне реальный вариант. Как для тестового запуска как раз подойдет. Traffic Segmentation, на ВЛАН выделяем /64, используем SLAAC. Каждый сам себе генерирует ИП, полная изоляция. Но.... Именно полная изоляция. Друг друга абоненты из одного ВЛАНа пинговать не будут. Зато мешать друг другу точно не будут :) не агрегация, а терминация. ага, а еще генератором, человеком, который будет его заводить, кондиционером, круглосуточным доступом, и в земле прорыть шахту и завести огромный жмут оптики. А потом застройщику (владельцу) ударит в голову снести стену, и вам отрубят оптику с 5-10к абонентов. Или арендную плату задрать до заоблачной. Я лично знаю такой случай, когда в офисном центре снесли стену вместе с ящиком. Прислали монтажника на обследование, чего абоненты (юрики) жалуются. А там лежит куча строймусора и сверху ящик со свичем. Самое смешное было в том, что обрезали витую пару, а оптику и питание оставили. И свич как бы работает))) А что в спальных районах делать прикажете? Вот я например живу на окраине города, хотя до метро тут 5-7 минут на маршрутке. Нет тут офисных центров. И что делать прикажете?

RIPE (если не путаю) рекомендует каждому абоненту по /56. Конечно, если это обычный роутер абонента, который обслуживает максимум десяток устройств, то само собой. Но если это небольшая сетка (организация, скажем), то им надо /56 давать. Вам что, адресов жалко? :) В плане безопастности это просто идеальная схема. А вот в плане реализации - крайне сложная. Да, но: 1. А вот не все свичи умеют 4к ВЛАНов. Есть свичи с жестким ограничением числа ВЛАНов на нем. 2. А если абонентов больше (и намного!), чем 4к? Вот и сели в лужу. А ставить в поле L3 железку такого уровня, чтоб все умела (Unnumbered, 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. И будет красота. Огромное спасибо, что ответили вместо меня :) Сам хотел написать, но у меня на тот момент лимит сообщений на форуме был исчерпал. Вы все описали вместо меня. Спасибо! Это вообще шедерв) Даже самые древние комутаторы умеют Port Security и IP Source Guard. Для этого DCHP провайдера должен выдавать ИП только по связке МАС-ИП. Тогда у абонента будет всегда один и тот же адрес. И если этот абонент взломает сервер пентагона - провайдер, по запросу людей в черном, выдаст всю информацию про абонента, а не будет сутками рыться в логах в поисках того, кто этот ИП использовал в указанный промежуток времени. Согласен. Увы, это так. xcme, man781 - спасибо за дискуссию! Хотя ответа на свой вопрос я так и не получил. Придется дома делать лабу. Благо, что для этого все есть.

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

от такой же для 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) сделали и горя не знаем. А вот на существующем... Рано или поздно внедрять провайдерам надо будет. Вот только боюсь, что внедрять может быть придется раньше, чем обновится парк свичей. Поэтому, для себя прорабатываю схемы :)

Добрый день! Обращаюсь с таким вопросом. Смотрим на сеть IPv6 со стороны провайдера. В интернете уже довольно много примеров и инструкций по настройке. Некоторые делятся опытом кто как настраивал, но реальных примеров "настрой и все заработает" пока что нет. Вряд-ли они и будут. Примерно вот такая упрощенная схема. Согласно всех рекомендаций, выдаем каждому абоненту /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, чтоб МАСи не меняли. И Циска, и Джунипер делать статические записи умеют. Пример: В итоге, роутер 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 будут адреса другого абонента. Буду благодарен за советы!