По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
В этой первой части статьи мы сначала рассмотрим некоторые методы обслуживания сетей. Существуют различные модели, которые помогут вам поддерживать ваши сети и сделать вашу жизнь проще. Во второй части статьи мы рассмотрим некоторые теоретические модели, которые помогут вам в устранении неполадок. Ну что давайте начнем рассматривать техническое обслуживании сети! Обслуживание сети в основном означает, что вы должны делать все необходимое для поддержания сети в рабочем состоянии, и это включает в себя ряд задач: Устранение неполадок в сети; Установка и настройка аппаратного и программного обеспечения; Мониторинг и повышение производительности сети; Планирование будущего расширения сети; Создание сетевой документации и поддержание ее в актуальном состоянии; Обеспечение соблюдения политики компании; Обеспечение соблюдения правовых норм; Обеспечение безопасности сети от всех видов угроз. Конечно, этот список может отличаться для каждой сети, в которой вы работаете. Все эти задачи можно выполнить следующим образом: Структурированные задачи; Interrupt-driven задачи. Структурированный означает, что у вас есть заранее определенный план обслуживания сети, который гарантирует, что проблемы будут решены до того, как они возникнут. Как системному администратору, это сделает жизнь намного проще. Управляемый прерыванием означает, что вы просто ждете возникновения проблемы, а затем исправляете ее так быстро, как только можете. Управляемый прерыванием подход больше похож на подход "пожарного" ...вы ждете, когда случится беда, а затем пытаетесь решить проблему так быстро, как только можете. Структурированный подход, при котором у вас есть стратегия и план обслуживания сети, сокращает время простоя и является более экономичным. Конечно, вы никогда не сможете полностью избавиться от Interrupt-driven, потому что иногда все "просто идет не так", но с хорошим планом мы можем точно сократить количество задач, управляемых прерываниями. Вам не нужно думать о модели обслуживания сети самостоятельно. Есть ряд хорошо известных моделей обслуживания сети, которые используются сетевыми администраторами. Лучше всего использовать одну из моделей, которая лучше всего подходит для вашей организации и подкорректировать, если это необходимо. Вот некоторые из известных моделей обслуживания сети: FCAPS: Управление неисправностями. Управление конфигурацией. Управление аккаунтингом. Управление производительностью. Управление безопасностью. Модель обслуживания сети FCAPS была создана ISO (Международной организацией стандартизации). ITIL: библиотека ИТ-инфраструктуры - это набор практик для управления ИТ-услугами, который фокусируется на приведении ИТ-услуг в соответствие с потребностями бизнеса. TMN: сеть управления телекоммуникациями - это еще одна модель технического обслуживания, созданная ITU-T (сектор стандартизации телекоммуникаций) и являющаяся вариацией модели FCAPS. TMN нацелена на управление телекоммуникационными сетями. Cisco Lifecycle Services: конечно, Cisco имеет свою собственную модель обслуживания сети, которая определяет различные фазы в жизни сети Cisco: Подготовка Планирование Проектирование Внедрение Запуск Оптимизация Выбор модели обслуживания сети, которую вы будете использовать, зависит от вашей сети и бизнеса. Вы также можете использовать их в качестве шаблона для создания собственной модели обслуживания сети. Чтобы дать вам представление о том, что такое модель обслуживания сети и как она выглядит, ниже приведен пример для FCAPS: Управление неисправностями: мы будем настраивать наши сетевые устройства (маршрутизаторы, коммутаторы, брандмауэры, серверы и т. д.) для захвата сообщений журнала и отправки их на внешний сервер. Всякий раз, когда интерфейс выходит из строя или нагрузка процессора превышает 80%, мы хотим получить сообщение о том, чтобы узнать, что происходит. Управление конфигурацией: любые изменения, внесенные в сеть, должны регистрироваться в журнале. Чаще всего используют управление изменениями, чтобы соответствующий персонал был уведомлен о планируемых изменениях в сети. Изменения в сетевых устройствах должны быть зарегистрированы и утверждены до того, как они будут реализованы. Управление аккаунтингом: Мы будем взимать плату с (гостевых) пользователей за использование беспроводной сети, чтобы они платили за каждые 100 МБ данных или что-то в этом роде. Он также обычно используется для взимания платы с людей за междугородние VoIP-звонки. Управление производительностью: производительность сети будет контролироваться на всех каналах LAN и WAN, чтобы мы знали, когда что-то пойдет не так. QoS (качество обслуживания) будет настроено на соответствующих интерфейсах. Управление безопасностью: мы создадим политику безопасности и реализуем ее с помощью брандмауэров, VPN, систем предотвращения вторжений и используем AAA (Authorization, Authentication and Accounting) для проверки учетных данных пользователей. Сетевые нарушения должны регистрироваться, и должны быть приняты соответствующие мероприятия. Как вы видите, что FCAPS - это не просто "теоретический" метод, но он действительно описывает "что", "как" и "когда" мы будем делать. Какую бы модель обслуживания сети вы ни решили использовать, всегда есть ряд рутинных задач обслуживания, которые должны иметь перечисленные процедуры, вот несколько примеров: Изменения конфигурации: бизнес никогда не стоит на месте, он постоянно меняется. Иногда вам нужно внести изменения в сеть, чтобы разрешить доступ для гостевых пользователей, обычные пользователи могут перемещаться из одного офиса в другой, и для облегчения этой процедуры вам придется вносить изменения в сеть. Замена оборудования: старое оборудование должно быть заменено более современным оборудованием, и также возможна ситуация, когда производственное оборудование выйдет из строя, и нам придется немедленно заменить его. Резервные копии: если мы хотим восстановиться после сетевых проблем, таких как отказавшие коммутаторы или маршрутизаторы, то нам нужно убедиться, что у нас есть последние резервные копии конфигураций. Обычно вы используете запланированные резервные копии, поэтому вы будете сохранять текущую конфигурацию каждый день, неделю, месяц или в другое удобное для вас время. Обновления программного обеспечения: мы должны поддерживать ваши сетевые устройства и операционные системы в актуальном состоянии. Обновления позволяют исправлять ошибки ПО. Также обновление проводится для того, чтобы убедиться, что у нас нет устройств, на которых работает старое программное обеспечение, имеющее уязвимости в системе безопасности. Мониторинг: нам необходимо собирать и понимать статистику трафика и использования полосы пропускания, чтобы мы могли определить (будущие) проблемы сети, но также и планировать будущее расширение сети. Обычно вы создаете список задач, которые должны быть выполнены для вашей сети. Этим задачам можно присвоить определенный приоритет. Если определенный коммутатор уровня доступа выходит из строя, то вы, вероятно, захотите заменить его так быстро, как только сможете, но нерабочее устройство распределения или основного уровня будет иметь гораздо более высокий приоритет, поскольку оно влияет на большее число пользователей Сети. Другие задачи, такие как резервное копирование и обновление программного обеспечения, могут быть запланированы. Вы, вероятно, захотите установить обновления программного обеспечения вне рабочего времени, а резервное копирование можно запланировать на каждый день после полуночи. Преимущество планирования определенных задач заключается в том, что сетевые инженеры с меньше всего забудут их выполнить. Внесение изменений в вашу сеть иногда влияет на производительность пользователей, которые полагаются на доступность сети. Некоторые изменения будут очень важны, изменения в брандмауэрах или правилах списка доступа могут повлиять на большее количество пользователей, чем вы бы хотели. Например, вы можете установить новый брандмауэр и запланировать определенный результат защиты сети. Случайно вы забыли об определенном приложении, использующем случайные номера портов, и в конечном итоге устраняете эту проблему. Между тем некоторые пользователи не получат доступ к этому приложению (и возмущаются, пока вы пытаетесь его исправить...). Более крупные компании могут иметь более одного ИТ-отдела, и каждый отдел отвечает за различные сетевые услуги. Если вы планируете заменить определенный маршрутизатор завтра в 2 часа ночи, то вы можете предупредить парней из отдела "ИТ-отдел-2", о том, что их серверы будут недоступны. Для этого можно использовать управление изменениями. Когда вы планируете внести определенные изменения в сеть, то другие отделы будут проинформированы, и они могут возразить, если возникнет конфликт с их планированием. Перед внедрением управления изменениями необходимо подумать о следующем: Кто будет отвечать за авторизацию изменений в сети? Какие задачи будут выполняться во время планового технического обслуживания windows, linux, unix? Какие процедуры необходимо соблюдать, прежде чем вносить изменения? (например: выполнение "copy run start" перед внесением изменений в коммутатор). Как вы будете измерять успех или неудачу сетевых изменений? (например: если вы планируете изменить несколько IP-адресов, вы запланируете время, необходимое для этого изменения. Если для перенастройки IP-адресов требуется 5 минут, а вы в конечном итоге устраняете неполадки за 2 часа, так как еще не настроили. Из-за этого вы можете "откатиться" к предыдущей конфигурации. Сколько времени вы отводите на устранение неполадок? 5 минут? 10 минут? 1 час? Как, когда и кто добавит сетевое изменение в сетевую документацию? Каким образом вы создадите план отката, чтобы в случае непредвиденных проблем восстановить конфигурацию к предыдущей конфигурации? Какие обстоятельства позволят отменить политику управления изменениями? Еще одна задача, которую мы должны сделать - это создать и обновить вашу сетевую документацию. Всякий раз, когда разрабатывается и создается новая сеть, она должна быть задокументирована. Более сложная часть состоит в том, чтобы поддерживать ее в актуальном состоянии. Существует ряд элементов, которые вы должны найти в любой сетевой документации: Физическая топологическая схема (физическая карта сети): здесь должны быть показаны все сетевые устройства и то, как они физически связаны друг с другом. Логическая топологическая схема (логическая карта сети): здесь необходимо отобразить логические связи между устройствами, то есть как все связано друг с другом. Показать используемые протоколы, информация о VLAN и т. д. Подключения: полезно иметь диаграмму, которая показывает, какие интерфейсы одного сетевого устройства подключены к интерфейсу другого сетевого устройства. Инвентаризация: вы должны провести инвентаризацию всего сетевого оборудования, списков поставщиков, номера продуктов, версии программного обеспечения, информацию о лицензии на программное обеспечение, а также каждое сетевое устройство должно иметь инвентарный номер. IP-адреса: у вас должна быть схема, которая охватывает все IP-адреса, используемые в сети, и на каких интерфейсах они настроены. Управление конфигурацией: перед изменением конфигурации мы должны сохранить текущую запущенную конфигурацию, чтобы ее можно было легко восстановить в предыдущую (рабочую) версию. Еще лучше хранить архив старых конфигураций для дальнейшего использования. Проектная документация: документы, которые были созданы во время первоначального проектирования сети, должны храниться, чтобы вы всегда могли проверить, почему были приняты те или иные проектные решения. Это хорошая идея, чтобы работать с пошаговыми рекомендациями по устранению неполадок или использовать шаблоны для определенных конфигураций, которые все сетевые администраторы согласны использовать. Ниже показаны примеры, чтобы вы понимали, о чем идет речь: interface FastEthernet0/1 description AccessPoint switchport access vlan 2 switchport mode access spanning-tree portfast Вот пример интерфейсов доступа, подключенных к беспроводным точкам доступа. Portfast должен быть включен для связующего дерева, точки доступа должны быть в VLAN 2, а порт коммутатора должен быть изменен на "доступ" вручную. interface FastEthernet0/2 description VOIP interface FastEthernet0/2 description ClientComputer switchport access vlan 6 switchport mode access switchport port-security switchport port-security violation shutdown switchport port-security maximum 1 spanning-tree portfast spanning-tree bpduguard enable Вот шаблон для интерфейсов, которые подключаются к клиентским компьютерам. Интерфейс должен быть настроен на режиме "доступа" вручную. Безопасность портов должна быть включена, поэтому допускается только 1 MAC-адрес (компьютер). Интерфейс должен немедленно перейти в режим переадресации, поэтому мы настраиваем spanning-tree portfast, и, если мы получаем BPDU, интерфейс должен перейти в err-disabled. Работа с предопределенными шаблонами, подобными этим, уменьшит количество ошибок, потому что все согласны с одной и той же конфигурацией. Если вы дадите каждому сетевому администратору инструкции по ""защите интерфейса", вы, вероятно, получите 10 различных конфигураций interface GigabitEthernet0/1 description TRUNK switchport trunk encapsulation dot1q switchport mode trunk switchport trunk nonegotiate Вот еще один пример для магистральных соединений. Если вы скажете 2 сетевым администраторам "настроить магистраль", вы можете в конечном итоге получить один интерфейс, настроенный для инкапсуляции 802.1Q, а другой-для инкапсуляции ISL. Если один сетевой администратор отключил DTP, а другой настроил интерфейс как "dynamic desirable", то он также не будет работать. Если вы дадите задание им настроить магистраль в соответствии с шаблоном, то у нас будет одинаковая конфигурация с обеих сторон.
img
Вопрос о балансировке нагрузки на WAN-линках встает довольно часто, и, к сожалению, в отличие от некоторых других вещей, которые можно настроить на оборудовании MikroTik быстро и безболезненно - в случае настройки Load Balancing придется немного постараться. Тема относительно сложная, наличие нескольких WAN-линков и задача по настройке балансировки нагрузки включает в себя настройку нескольких шлюзов и маршрутов по умолчанию, множество правил трансляции NAT и так далее. Настройка маршрутизатора Итак, в наличие у нас имеется один маршрутизатор MikroTik, который подключен к двум провайдерам - Тарс Телеком и Милайн на портах ether1 и ether2 соответственно, и локальной сетью на порту ether3. Трафик из локальной сети будет NATирован из обоих WAN портов и будет сбалансирован по нагрузке. Топология ниже: Настраиваем локальные IP-адреса: /ip address add address=1.1.1.199/24 interface=ether1 comment="Tars" add address=2.2.2.199/24 interface=ether2 comment="Meeline" add address=192.168.1.1/24 interface=ether3 comment="LAN Gateway" Настраиваем шлюзы по умолчанию: /ip route add dst-address=0.0.0.0/0 check-gateway=ping gateway=1.1.1.1,2.2.2.1 Настраиваем NAT на WAN портах для исходящего направления: /ip firewall nat add action=masquerade chain=srcnat comment="Tars" out-interface=ether1 add action=masquerade chain=srcnat comment="Meeline" out-interface=ether2 Если на данном этапе перестать настраивать роутер, то это будет являть собой пример настройки отказоустойчивости. Если один из линков “отвалится”, то вместо него будет использоваться второй. Однако, никакой балансировки нагрузки здесь нет и в помине, и, с экономической точки зрения, это является плохой идеей - вряд ли найдется компания, которая захочет платить абонентскую плату за второй канал и использовать его только в случае аварии. Исходящая и входящая Mangle маркировка Одной из типичных проблем при использовании более одного WAN-соединения является то, что пакеты принятые на одном WAN интерфейсе, могут тут же быть отправлены через другой WAN-интерфейс, что может, к примеру, сломать VPN-based сеть. Нам нужно чтобы пакеты “принадлежащие” одному и тому же соединению принимались и отправлялись через один и тот же WAN порт. В случае аварии у одного из провайдеров, все подключения на порту “умрут” и затем будут переподключены на другом WAN порту. Для этого необходимо промаркировать соединения: /ip firewall mangle add action=mark-connection chain=input comment="Tars Input" in-interface=ether1 new-connection-mark="Tars Input" add action=mark-connection chain=input comment="Meeline Input" in-interface=ether2 new-connection-mark="Meeline Input" Это поможет маршрутизатору отслеживать порт для каждого входящего подключения. Теперь мы будем использовать отметку подключения для входящих пакетов для вызова отметки маршрутизации. Это отметка маршрутизации будет использована позднее на маршруте, который будет сообщать подключению через какой WAN-порт необходимо слать пакеты наружу. add action=mark-routing chain=output comment="Tars Output" connection-mark="Tars Input" new-routing-mark="Out Tars" add action=mark-routing chain=output comment="Meeline Output" connection-mark="Meeline Input" new-routing-mark="Meeline Telecom" Помеченные подключения затем получают метку маршрута, так что роутер сможет маршрутизировать пакеты так, как нам необходимо. В следующем шаге мы настроим роутер таким образом, чтобы помеченные пакеты отправлялись наружу из корректного WAN-подключения. Маркировка LAN маршрута Понадобится также настроить несколько Mangle правил - они необходимы, чтобы сообщить роутеру о необходимости балансировки пакетов, которые отправляются из локальной сети. Сам механизм балансировки в этой статье не описывается, можно только сказать что происходить много операций хеширования - если же интересно копнуть глубже, то вы можете обратиться к официальной документации MikroTik. В соответствии с этими правилами маршрутизатор будет балансировать трафик приходящий на порт ether3 (LAN-порт), который направлен на любой нелокальный адрес в Интернете. Мы захватываем трафик в цепочке предварительной маршрутизации для перенаправления его на необходимый нам WAN-порт в соответствии с меткой маршрутизации. Следующие команды балансируют трафик на LAN-интерфейсе через две группы: add action=mark-routing chain=prerouting comment="LAN load balancing 2-0" dst-address-type=!local in-interface=ether3 new-routing-mark= "Out Tars" passthrough=yes per-connection-classifier= both-addresses-and-ports:2/0 add action=mark-routing chain=prerouting comment="LAN load balancing 2-1" dst-address-type=!local in-interface=ether3 new-routing-mark= "Out Meeline" passthrough=yes per-connection-classifier= both-addresses-and-ports:2/1 Настройка меток маршрутизации выше была выполнена точно такие же как и в предыдущем шаге и соответствуют тем маршрутам, которые будут созданы в следующем шаге. Особые маршруты по умолчанию. В данный момент у нас должны быть помечены соединения поступающие на WAN-порты и эти метки были использованы для создания меток маршрутизации. Балансировка нагрузки в LAN, описанная в предыдущем шаге, также создает метки маршрутизации в соответствии со следующим шагом, в котором будут созданы маршруты по умолчанию, которые будут захватывать трафик с данными метками маршрутизации. /ip route add distance=1 gateway=1.1.1.1 routing-mark="Out Tars" add distance=1 gateway=2.2.2.1 routing-mark="Out Meeline" Данные маршруты используются только при наличии необходимой метки маршрутизации. Непомеченные пакеты используют обычный маршрут по умолчанию. Маршруты, относящиеся к Тарс Телеком получают метку подключения, которая вызывает метку маршрутизации. Эта метка маршрутизации совпадает с меткой в маршруте выше и обратный пакет выходит из того же интерфейса, на котором был получен изначальный пакет. Заключение Итого, какие шаги по настройке роутера были выполнены: Маркировка новых подключений в WAN Соединения с этой маркировкой получают метку маршрутизации Исходящий из локальной сети трафик балансируется с теми же метками маршрутизации Метки маршрутизации соответствуют маршрутам по умолчанию и отправляются из соответствующего интерфейса Если количество WAN-линков более 2 - необходимо проделать такие же действия для остальных подключений. Итого, теперь у вас настроена балансировка трафика для двух WAN-соединений.
img
Свершилось. Старая добрая программа сертификации Cisco изменилась навсегда. Мы решили расписать по пунктам изменения, которые на этот раз коснулись не только уровня CCNA. Хорошие новости в том, что сетевой гигант меняет свои сертификации по причине возросшего спроса со стороны индустрии и работодателей. Итак, читайте ниже. Больше никакого CCENT Вот как будет выглядеть новый путь сертификации Cisco: Самый начальный сертификат CCENT (Cisco Certified Entry Networking Technician) перестал существовать. Хотя, на мой взгляд, в России люди всегда стремились получить CCNA сертификат, не останавливаясь на самой начальной сертификации. Но для всего остального мира такие изменения были легким шоком. Теперь есть только сертификат CCT (Cisco Certified Technician) под CCNA. Но CCT не равен CCENT, т.к CCT направлен в большей степени на провайдерскую специфику и не покрывает теорию сетей как CCENT. Однако ранее CCENT также являлся неким "трамплином" - его сдача позволяла получить ваучер на сдачу первого из двух CCNA экзаменов, и теперь, в его отсутствие, для новичков может быть несколько сложнее начинать свой путь в мир сертификаций Cisco. Но в новых реалиях остался только один CCNA экзамен (200-301) - что также в какой-то мере снижает трудоемкость сертификации. Новый CCNA Одной из самых громких новостей в 2018 году от Cisco были их планы по изменению CCNA сертификации. По слухам, Cisco прислушались к работодателям и изменили пути сертификации CCNA для упрощения процедуры их получения. В результате получились некие наборы CCNA сертификаций, которые подходят для начала карьеры в различных сферах работы, причем без какой-либо чрезмерной квалификации. Основная идея в том, что людям не придется тратить время и энергию на обучение узкоспециализированным навыкам на данном этапе. Ранее CCNA состоял из нескольких различных путей: CCNA Cloud CCNA Collaboration CCNA Cyber Ops CCNA Data Center CCNA Industrial CCNA Routing and Switching CCNA Service Provider CCNA Wireless Эти опции позволяли начать с одного (или нескольких) сертификата и двинуться далее до CCNP (Cisco Certified Network Professional) и вплоть до самого топового CCIE (Cisco Certified Internetworking Expert). Однако, все было не так просто: работодатели не особо горели желанием обучать сотрудников по этим специализированным трекам, т.к в основном они искали новичков с крепкими базовыми знаниями, что можно использовать для развития буквально в любом направлении, а сфокусироваться на узкой задаче люди всегда могут успеть. По этой причине, 8 старых CCNA окончат свое жалкое существование и будут заменены единым CCNA сертификатом, и новый CCNA будет покрывать широкий спектр тем в сетях и безопасности. Новый CCNP На уровне CCNP было не так много сертификатов, но здесь от людей ожидается уже серьезный уровень специализации. Ранее это были следующие сертификаты: CCNP Routing and Switching CCNP Collaboration CCNP Wireless CCNP Data Center CCNP Service Provider CCDP Начиная с 24 февраля 2020 года CCNP сертификации предстанут в следующем виде: CCNP Enterprise CCNP Data Center CCNP Security CCNP Service Provider CCNP Collaboration Cisco Certified DevNet Professional В новой программе сертификации CCNP RS, CCNP Wireless и CCDP будут собраны под зонтиком сертификации CCNP Enterprise. Необходимо будет подготовиться к двум экзаменам - основному и фокусному. Вне зависимости от выбранного пути, нужно будет сдать основной экзамен 300-401 ENCOR и один из фокусных: 300-410 ENARSI (Advanced Routing and Services) 300-415 ENSDWI (SD-WAN) 300-420 ENSLD (Networks) 300-425 ENWLSD (Designing Wireless Networks) 300-430 ENWLSI (Implementing Wireless Networks) 300-435 ENAUTO (Automating and Programing) Новый CCIE Мы оставили CCIE на сладкое - самый жестокий, сложный и харкдорный экзамен. Но если уж у вас есть CCIE сертификат, то шансы, что вы являетесь высокооплачиваемой персоной сильно возрастают. Кроме того, сертификация не очень сильно изменилась, так, немного навели блеск. Список старых CCIE сертификаций: CCIE Routing Switching CCIE Wireless CCIE Service Provider CCIE Security CCIE Data Center CCIE Collaboration А поменяли их на: CCIE Enterprise Infrastructure CCIE Enterprise Wireless CCIE Data Center CCIE Security CCIE Service Provider CCIE Collaboration Новая программа CCIE делит с CCNP основной экзамен, но вам также нужно будет выполнить лабораторную работу и впихнуть ее в достаточно узкие рамки (8 часов). Если ты хорош и считаешь себя половым гигантом в плане сетей, то можешь попробовать сдать CCIE сразу, не притрагиваясь к CCNP. Появление сертификации для разработчиков (DevNet) Вот как выглядит трек обучения DevNet: DevOps и программирование в более широком смысле нереально важны в текущем IT мире, и Cisco подстроились: встречайте новые сертификации DevNet Associate, Specialist и Professional. Сертификации сфокусированы на следующих вещах: стратегия кодинга относительно решений Cisco, API, и автоматизация сетей. Как можно заметить, пока что на этом уровне нет экспертной сертификации - но пока непонятно, когда этого ожидать. Что это означает для тех, кто хотел сдать экзамен Cisco Если вы собирались вот-вот сдавать старый экзамен, то самое страшное, что могло произойти - это то, что вы не успели его сдать перед Днем Защитника Отечества (23 февраля). Если вы таки не успели, то лучшее, что вы можете сделать - это найти новый экзамен, темы в котором максимально пересекаются с тем, что вы успели в себя впитать. Для всех остальных, давайте подведем итоги изменений: Меньше (прям вот сильно меньше) специализаций на уровне CCNA, сертификация стала более широкой и менее глубокой Изменился контент и его направления Добавился DevNet Кстати, если вы горели желанием сдать CCENT - посмотрите на CompTIA Network+ экзамен - они во многом схожи.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59