Актуальная проблема не в том, есть или нет автообновление прошивки, а в том, что производители в принципе не хотят и не будут поддерживать прошивки в актуальном состоянии на весь свой зоопарк выпущенных устройств десятилетиями.
Пользователи и сейчас успешно могут зайти на устройство и нажать две кнопки (или найти того, кто сможет) по пинку от своего интернет-провайдера (из своего опыта, при чем намеки в письме что это «в связи с вашими действиями/бездействием причиняются убытки» сильно помогают). Но толку с того, если веб-камера выпущена в 2005 году, уже 6 лет EOL и сменилось 5 поколений камер у этого вендора? Себе в убыток содержать штат инженегров для патчинга старья вендор не будет.
P.S. авторы ботнетов, пожалуй, будут первыми, кто воспользуется стандартизированным интерфейсом заливания себя в устройства :)
Значительному количеству людей — стало.
Лицокнига значительно более неудобная в плане UI/UX.
Видимо, именно оттуда авторы «редзайна» решили поднатаскать сомнительных приемов повышения монетизации.
Теперь ВК СНОВА выглядит как плохой клон ФБ.
Может, автор имеет ввиду возможности линзы Барлоу?
Хотя что можно делать с фокусными 10-ю метрами на обычном бытовом телескопе, мне представить сложно.
Что вы понимаете под «атакой на NAT/PAT»?
Проблемы в реализации конкретного вендора? Возможность использовать его как инструмент для совершения вредоносной активности?
Моя реплика изначально была в том ключе, что обычный -j MASQUERADE считают достаточным уровнем защиты локальной сети. Хотя уровень защиты, обеспечиваемый подобным решением, ничем не превосходит аналогичное решение для IPv6 в виде -m state! RELATED,ESTABLISHED -j DROP, но при этом значительно сужает возможности.
Современные Л3-коммутаторы отлично маршрутизируют и IPv4 и IPv6 аппаратно, на скорости порта. С пакет-фильтром(stateless-файрволом), динамической маршрутизацией и прочими радостями.
Железки, способные делать быстрый NAT стоят намного дороже, а их функционал и область применения ограничены: это либо небольшие SOHO мыльницы, либо Security-девайсы по цене вертолета, либо специализированные Carrier Grade NAT платы/устройства по цене самолета.
default-route имеет смысл только на PE, если есть несколько full-view. В ядре оно не нужно: все, что есть в FW — пророутится куда надо, остальное — unreachable.
На цисках/кваггах даже есть neighbor xxx default-originate, такой дефолт в принципе существует только в виде абстрактоного BGP-анонса.
Хотя, наверное, технически правильнее организовать aggregate 0/0 с правильной политикой и именно его редистрибьютить (нет фул-вью — нет дефолта), но я не сталкивался с таким, обычно не заморачиваются и с раздают default-originate или static 0/0.
Вот, к примеру, OSPF. ECMP вполне себе работает:
$ vtysh -c «show ip route 172.16.163.12/30»
Routing entry for 172.16.163.12/30
Known via «ospf», distance 110, metric 20, best
Last update 04:52:00 ago
* 172.16.172.77, via eth2.700
* 172.16.172.90, via eth2.700
$ ip route list 172.16.163.12/30
172.16.163.12/30 proto zebra metric 20
nexthop via 172.16.172.77 dev eth2.700 weight 1
nexthop via 172.16.172.90 dev eth2.700 weight 1
В отличии от conditional/more-specific/eem, комьюнити, все-таки, совсем не универсальный метод т.к. опирается на возможности конкретного оператора. Хотя и, пожалуй, самый гибкий и многофункциональный. Он, скорее, идет в дополнение к остальным методам.
Далеко не у всех есть даже backup community с выставлением минимального localpref, обычно ограничиваются препендами на различные направления.
Это да. Распишите, пожалуйста, подробнее. Статьи на хабре часто используются как готовый мануал на все случаи жизни :)
С другой стороны, основной способ из статьи, проверяющий состояние bgp neigbor, я считаю далеко не самым надежным в ситуации, когда у аплинка сессия с вами есть, а вот выше — уже проблемы. Хотя, конечно, последняя миля обычно более подвержена проблемам, чем ядро оператора.
С цисками я практически не работал, но, кажется, у них есть возможность проверять наличие/отсутствие во входящих анонсах конкретного префикса, и в зависимости от этого что-то делать? Такой вариант намного надежнее. Правда, работает только при получении FW (или хотя бы локальный ix + дефолт — распространенная схема для приземления bgp на L3 коммутатор с нерезиновой forwarding table).
Есть еще один очень простой, но очень действенный способ борьбы с localpref:
В оба аплинка анонсится агрегированный префикс, в качестве резерва, и в каждый аплинк дополнительно — соответствующий аплинку more-specific префикс. Таким образом, трафик практически всегда будет литься на more-specific анонс, а в случае падения — на оставшийся агрегированный.
Заодно исчезают игры с ивентами и прочими лишними сервисами, работает даже на самом простом софте/железе.
Единственное, что надо иметь более чем /24
>И как мне эти «несколько маков» прикажете разруливать
Коммутатором.
>Хабы мы запретили.
Кто запретил? Кому? Зачем?
>почему ПРОИЗВОДИТЕЛИ ничего не делают
Производители все делают. Вопрос в деньгах. Коммутатор с IP-MAC-BINDING/DHCP+ARP Snooping/IP Source Guard стоит в полтора-два раза дороже аналогичного по портам, но без этих фич, а с простым Static MAC.
Провайдеру банально дешевле сделать кнопочку в ЛК или через сапорт, чтоб биллинг скриптом обновил привязку ip-mac на терминации и port-mac на коммутаторе, чем покупать более дорогие коммутаторы на доступ.
Профит с ухода от кнопки/звонка весьма сомнительный а затраты серьезные. Юзеры не так часто меняют железки.
На порту вполне может быть не один мак, а несколько, со своими айпишниками.
Функционал IP Source Guard/IP-Mac-binding это уже L2+/L3 функционал с заглядыванием в содержимое фрейма, хабы здесь ни при чем.
Даже там, где есть эта фича, далеко не всегда есть глубокий DHCP Snooping, который нормально обрабатывает ответ сервера.
Если не резать лишнее на порту, значит надо тянуть инфу мак-порт дальше в ядро сети. Хорошо, если DHCP и коммутатор умеет Option82, и БРАСы умеют правильно его обрабатывать, а биллинг успешно работает с идентификатором свич/порт/мак вместо просто мак.
А по факту у многих зоопарк из разных вендоров/серий/моделей, в каждой из которых свой формат Opt82, древний/самописный/глючный биллинг, брасы на линуксовом тазике или на микротике каком-нибудь… В итоге, в такой ситуации намного проще статически прибить MAC-PORT на коммутаторе и IP-MAC на БРАСе, чем пытаться связать в кучу весь зоопарк, а потом выхватывать множественные и разнообразные глюки не самого простого функционала.
>что сложно делать по принципу — кто появился в порту, тому и IP выдадим
Сложно.
Не всякое железо умеет обновлять привязку IP-MAC-PORT по ответу DHCP-сервера.
А без такой привязки нужна архитектура провайдерской сети вида vlan-per-user, а ее далеко не всегда можно сделать из уже существующей сети с нормальными затратами. К тому же, она в принципе не всем подходит.
Ошибаетесь, маршруты «туда» и «обратно» не связаны практически никак, за редким исключением типа различных физических хостов при одинаковом Anycast IP. Маршрутизация, она в принципе несимметрична по своей природе, о чем частенько забывают начинающие.
Во многих случаях трафик идет не тудой, кудой ближе/быстрее/стабильнее, а кудой дешевле, или вообще «куда попало».
Методы для рулежки входящим и исходящим направлениями различаются.
В договоре все прописано :)
В некоторых случаях есть SLA с различными компенсациями при нарушениях, начиная от 25-50-100% скидки на месячной абонплату в месяце с простоем, и даже с выплатой неустоек клиенту. Впрочем, эти выплаты никак не связаны с упущенными выгодами, а, обычно, жестко указаны в документах и привязаны к длительности отсутствия/деградации услуги.
Естественно, подобные подключения стоят значительно дороже обычных тарифов для юрлиц, и месячная абонплата может исчисляться сотнями/тысячами долларов за далеко не самые скоростные тарифы.
На каждого разбирающегося приходится два-три десятка «умников», нахватавшихся иностранных слов в «Типичном сисадмине», либо «связистов с 40летним стажем».
К сожалению, далеко не всегда можно сразу понять, действительно ли обратившийся клиент понимающий, или он только думает, что понимает.
А иногда даже более-менее адекватные админы не желают отвечать на некоторые вопросы принципиально, ссылаясь на «я вам все что надо сказал, решайте проблему». Лучше бы, в таких случаях, секретарша звонила, чесслово.
Пользователи и сейчас успешно могут зайти на устройство и нажать две кнопки (или найти того, кто сможет) по пинку от своего интернет-провайдера (из своего опыта, при чем намеки в письме что это «в связи с вашими действиями/бездействием причиняются убытки» сильно помогают). Но толку с того, если веб-камера выпущена в 2005 году, уже 6 лет EOL и сменилось 5 поколений камер у этого вендора? Себе в убыток содержать штат инженегров для патчинга старья вендор не будет.
P.S. авторы ботнетов, пожалуй, будут первыми, кто воспользуется стандартизированным интерфейсом заливания себя в устройства :)
Лицокнига значительно более неудобная в плане UI/UX.
Видимо, именно оттуда авторы «редзайна» решили поднатаскать сомнительных приемов повышения монетизации.
Теперь ВК СНОВА выглядит как плохой клон ФБ.
Хотя что можно делать с фокусными 10-ю метрами на обычном бытовом телескопе, мне представить сложно.
Проблемы в реализации конкретного вендора? Возможность использовать его как инструмент для совершения вредоносной активности?
Моя реплика изначально была в том ключе, что обычный -j MASQUERADE считают достаточным уровнем защиты локальной сети. Хотя уровень защиты, обеспечиваемый подобным решением, ничем не превосходит аналогичное решение для IPv6 в виде -m state! RELATED,ESTABLISHED -j DROP, но при этом значительно сужает возможности.
Железки, способные делать быстрый NAT стоят намного дороже, а их функционал и область применения ограничены: это либо небольшие SOHO мыльницы, либо Security-девайсы по цене вертолета, либо специализированные Carrier Grade NAT платы/устройства по цене самолета.
На цисках/кваггах даже есть neighbor xxx default-originate, такой дефолт в принципе существует только в виде абстрактоного BGP-анонса.
Хотя, наверное, технически правильнее организовать aggregate 0/0 с правильной политикой и именно его редистрибьютить (нет фул-вью — нет дефолта), но я не сталкивался с таким, обычно не заморачиваются и с раздают default-originate или static 0/0.
$ vtysh -c «show ip route 172.16.163.12/30»
Routing entry for 172.16.163.12/30
Known via «ospf», distance 110, metric 20, best
Last update 04:52:00 ago
* 172.16.172.77, via eth2.700
* 172.16.172.90, via eth2.700
$ ip route list 172.16.163.12/30
172.16.163.12/30 proto zebra metric 20
nexthop via 172.16.172.77 dev eth2.700 weight 1
nexthop via 172.16.172.90 dev eth2.700 weight 1
Далеко не у всех есть даже backup community с выставлением минимального localpref, обычно ограничиваются препендами на различные направления.
С другой стороны, основной способ из статьи, проверяющий состояние bgp neigbor, я считаю далеко не самым надежным в ситуации, когда у аплинка сессия с вами есть, а вот выше — уже проблемы. Хотя, конечно, последняя миля обычно более подвержена проблемам, чем ядро оператора.
С цисками я практически не работал, но, кажется, у них есть возможность проверять наличие/отсутствие во входящих анонсах конкретного префикса, и в зависимости от этого что-то делать? Такой вариант намного надежнее. Правда, работает только при получении FW (или хотя бы локальный ix + дефолт — распространенная схема для приземления bgp на L3 коммутатор с нерезиновой forwarding table).
В оба аплинка анонсится агрегированный префикс, в качестве резерва, и в каждый аплинк дополнительно — соответствующий аплинку more-specific префикс. Таким образом, трафик практически всегда будет литься на more-specific анонс, а в случае падения — на оставшийся агрегированный.
Заодно исчезают игры с ивентами и прочими лишними сервисами, работает даже на самом простом софте/железе.
Единственное, что надо иметь более чем /24
Коммутатором.
>Хабы мы запретили.
Кто запретил? Кому? Зачем?
>почему ПРОИЗВОДИТЕЛИ ничего не делают
Производители все делают. Вопрос в деньгах. Коммутатор с IP-MAC-BINDING/DHCP+ARP Snooping/IP Source Guard стоит в полтора-два раза дороже аналогичного по портам, но без этих фич, а с простым Static MAC.
Провайдеру банально дешевле сделать кнопочку в ЛК или через сапорт, чтоб биллинг скриптом обновил привязку ip-mac на терминации и port-mac на коммутаторе, чем покупать более дорогие коммутаторы на доступ.
Профит с ухода от кнопки/звонка весьма сомнительный а затраты серьезные. Юзеры не так часто меняют железки.
Функционал IP Source Guard/IP-Mac-binding это уже L2+/L3 функционал с заглядыванием в содержимое фрейма, хабы здесь ни при чем.
Даже там, где есть эта фича, далеко не всегда есть глубокий DHCP Snooping, который нормально обрабатывает ответ сервера.
Если не резать лишнее на порту, значит надо тянуть инфу мак-порт дальше в ядро сети. Хорошо, если DHCP и коммутатор умеет Option82, и БРАСы умеют правильно его обрабатывать, а биллинг успешно работает с идентификатором свич/порт/мак вместо просто мак.
А по факту у многих зоопарк из разных вендоров/серий/моделей, в каждой из которых свой формат Opt82, древний/самописный/глючный биллинг, брасы на линуксовом тазике или на микротике каком-нибудь… В итоге, в такой ситуации намного проще статически прибить MAC-PORT на коммутаторе и IP-MAC на БРАСе, чем пытаться связать в кучу весь зоопарк, а потом выхватывать множественные и разнообразные глюки не самого простого функционала.
Сложно.
Не всякое железо умеет обновлять привязку IP-MAC-PORT по ответу DHCP-сервера.
А без такой привязки нужна архитектура провайдерской сети вида vlan-per-user, а ее далеко не всегда можно сделать из уже существующей сети с нормальными затратами. К тому же, она в принципе не всем подходит.
Во многих случаях трафик идет не тудой, кудой ближе/быстрее/стабильнее, а кудой дешевле, или вообще «куда попало».
Методы для рулежки входящим и исходящим направлениями различаются.
В некоторых случаях есть SLA с различными компенсациями при нарушениях, начиная от 25-50-100% скидки на месячной абонплату в месяце с простоем, и даже с выплатой неустоек клиенту. Впрочем, эти выплаты никак не связаны с упущенными выгодами, а, обычно, жестко указаны в документах и привязаны к длительности отсутствия/деградации услуги.
Естественно, подобные подключения стоят значительно дороже обычных тарифов для юрлиц, и месячная абонплата может исчисляться сотнями/тысячами долларов за далеко не самые скоростные тарифы.
К сожалению, далеко не всегда можно сразу понять, действительно ли обратившийся клиент понимающий, или он только думает, что понимает.
А иногда даже более-менее адекватные админы не желают отвечать на некоторые вопросы принципиально, ссылаясь на «я вам все что надо сказал, решайте проблему». Лучше бы, в таких случаях, секретарша звонила, чесслово.