По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Беспроводные точки доступа могут быть настроены для работы в не инфраструктурных режимах, когда обычный BSS не может обеспечить необходимую функциональность. Далее рассмотрим наиболее распространенные топологии.
Кстати, почитайте статью где мы сравниваем проводные и беспроводные сети
Ретранслятор (repeater)
Обычно каждая точка доступа в беспроводной сети имеет проводное соединение с DS (системой распределения) или коммутируемой инфраструктурой. Чтобы расширить зону покрытия беспроводной сети за пределы области действия обычной точки доступа (AP), можно добавить дополнительные точки доступа. Иногда бывают ситуации, когда невозможно выполнить проводное подключение к новой точке доступа, поскольку расстояние слишком велико для поддержки Ethernet-связи.
В этом случае можно добавить дополнительную точку доступа, настроенную в режиме ретранслятора. Беспроводной ретранслятор принимает сигнал, ретранслирует его в новой области ячейки, окружающей ретранслятор. Размещается ретранслятор на таком расстоянии от точки доступа, чтобы он все еще находился в пределах досягаемости как точки доступа, так и удаленного клиента, как показано на рисунке 1.
На рисунке показано увеличение диапазона точки доступа. Точка доступа соединена с коммутатором третьего уровня посредством кабеля. Диапазон точки доступа формирует базовый набор услуг (BSS). Клиент А подключен к точке доступа по беспроводной сети и находится в BSS. Ретранслятор помещается на удалении от точки доступа, но в пределах ее видимости так, чтобы он мог соединиться с удаленным клиентом B. Ретранслятор соединен с точкой доступа и клиентом B по беспроводной сети.
Если ретранслятор имеет один передатчик и приемник, он должен работать на том же канале, что и точка доступа. Это связано с тем, что сигнал точки доступа будет принят и ретранслирован повторителем для того, чтобы быть снова принятым точкой доступа. Ретранслятор в двое уменьшает эффективную пропускную способность, потому что канал будет занят в два раза дольше, чем раньше. В качестве средства защиты некоторые ретрансляторы могут использовать два передатчика и приемника, чтобы изолировать исходные и повторные сигналы на разных каналах. Одна пара передатчика и приемника предназначена для сигналов в ячейке точки доступа, в то время как другая пара предназначена для сигналов в собственной ячейке ретранслятора.
Мост рабочей группы (Workgroup)
Предположим, есть устройство, которое поддерживает проводную связь Ethernet, но не может работать в беспроводной сети. Например, некоторые мобильные медицинские устройства могут быть сконструированы только с проводным подключением. Хоть при наличии проводного подключения устройства к сети Ethernet, беспроводное соединение было бы гораздо более практичным. Для подключения проводного сетевого адаптера устройства к беспроводной сети используется мост рабочей группы (WGB).
Вместо того, чтобы обеспечить BSS для беспроводного обслуживания, WGB становится беспроводным клиентом BSS. Фактически WGB выступает в качестве внешнего адаптера беспроводной сети для устройства, которое не имеет такового. На рисунке 2, точка доступа обеспечивает BSS, где клиент А - это обычный беспроводной клиент, а клиент Б связан с точкой доступа через WGB.
На рисунке показано подключение проводного устройства через мост рабочей группы (WGB). Точка доступа соединена с коммутатором третьего уровня через кабель. Диапазон точки доступа формирует базовый набор услуг (BSS). Клиент А подключен к точке доступа по беспроводной связи. Клиент B в пределах BSS соединен с мостом рабочей группы, через кабель. Мост рабочей группы подключен к точке доступа по "воздуху".
WGB бывают двух типов:
Универсальный мост рабочей группы (uWGB-Universal WORKGROUP BRIDGE): только одно проводное устройство может быть соединено с беспроводной сетью;
Мост рабочей группы (WGB): проприетарный режим Cisco, который позволяет соединять несколько проводных устройств в беспроводную сеть
Открытый мост
Точка доступа может быть настроена в качестве моста для формирования единой беспроводной линии связи от одной локальной сети к другой на большом расстоянии. Данный тип подключения используется для связи между зданиями или между городами.
Если необходимо соединить две локальные сети, то можно использовать мостовую связь "точка-точка". На каждом конце беспроводной линии связи должна одна точка доступа, настроенная в режиме моста. Специальные антенны обычно используются с мостами для фокусировки их сигналов в одном направлении к антенне точки доступа. Это позволяет максимально увеличить расстояние между звеньями, как показано на рисунке 3.
На рисунке показан открытый мост "точка-точка". Два здания расположены на значительном расстоянии друг от друга. Сеть A соединена с мостом, который в свою очередь соединен с антенной на здании, через кабель. Сеть B соединена с другим мостом, который в свою очередь соединен с другой антенной в другом здании, так же через кабель. Между этими двумя зданиями настроена беспроводная связь, и сигналы фокусируются с помощью антенн.
Иногда сети нескольких подразделений компании должны быть объединены. Мостовая связь "точка-множественное подключение" (point-to-multipoint) позволяет соединять головной (центральный) офис с удаленными офисами. Мост головного офиса соединен с всенаправленной антенной, так что его сигнал передается одинаково во всех направлениях. Это позволяет передавать данные в удаленные офисы одновременно. Мосты на каждом из других участков могут быть соединены с направленной антенной, смотрящей на головной офис. На рисунке показано подключение point-to-multipoint.
На рисунке показан открытый мост (outdoor bridge) типа "point-to-multipoint". Показанная сеть состоит из трех зданий, расположенных линейным образом на равном расстоянии. Первый и третий корпуса содержат специальные антенны, которые фокусируют сигнал друг на друга. Второе здание в центре содержит всенаправленную антенну. Сеть А, Сеть B, Головной офис все эти сети соединены через мосты, каждая в своем здании.
Ячеистая сеть
Чтобы обеспечить беспроводное покрытие на очень большой площади, не всегда практично использовать провода Ethernet к каждой точке доступа, которая будет необходима. Вместо этого можно использовать несколько точек доступа, настроенных в режиме ячейки. В ячеистой топологии беспроводной трафик передается от точки доступа к точке доступа с помощью другого беспроводного канала.
Точки доступа ячеистой топологии используют два радиоканала-один канал используется в одном диапазоне частот, а другой -в другом диапазоне. Каждая точка доступа ячеистой топологии обычно поддерживает BSS на одном канале, с которым могут связываться беспроводные клиенты. Затем клиентский трафик обычно соединяется через мост от точки доступа к точке доступа по другим каналам. На границе ячеистой сети обратный трафик соединяется с инфраструктурой проводной локальной сетью. На рисунке 5 показана типичная ячеистая сеть. С Cisco APs можно построить ячеистую сеть в помещении или на улице. Ячеистая сеть использует свой собственный протокол динамической маршрутизации, чтобы определить наилучший путь для обратного трафика, который будет проходить через сеть AP.
Виртуализация часто применяется для поиска более простого способа решения некоторых проблем, отмеченных в начальных статьях этой темы, таких как разделение трафика. Как и все в мире сетевой инженерии, здесь есть компромиссы. На самом деле, если вы не нашли компромисс, вы плохо искали. В этом разделе будут рассмотрены некоторые (хотя, конечно, не все) различные компромиссы сложности в области виртуализации сети. Основой этого обсуждения будет триада компромиссов сложности:
Состояние: количество состояний и скорость, с которой изменяется состояние в сети (особенно в плоскости управления).
Оптимизация: оптимальное использование сетевых ресурсов, включая такие вещи, как трафик, следующий по кратчайшему пути через сеть.
Поверхность: количество слоев, глубина их взаимодействия и широта взаимодействия.
Поверхности взаимодействия и группы связей общих рисков
Каждая система виртуализации, когда-либо задуманная, реализованная и развернутая, создает в некотором роде общий риск. Например, рассмотрим одну линию, по которой передается несколько виртуальных каналов, каждый из которых передает трафик. Должно быть очевидным (на самом деле тривиальным) наблюдение, что в случае отказа одного физического канала произойдет сбой всех виртуальных каналов. Конечно, вы можете просто перенаправить виртуальные каналы на другой физический канал. Правильно? Может быть, а может и нет. Рисунок 1 иллюстрирует это.
С точки зрения A и D, есть две линии, доступные через B и C, каждая из которых обеспечивает независимое соединение между хостом и сервером. В действительности, однако, и провайдер 1, и провайдер 2 приобрели виртуальные каналы через единственное соединение у провайдера 3. Когда единственное соединение в сети провайдера 3 выходит из строя, трафик может быть перенаправлен с основного пути через провайдера 1 на путь через провайдера. 2, но поскольку оба канала используют одну и ту же физическую инфраструктуру, ни одна из них не сможет передавать трафик.
Говорят, что эти два звена в этой ситуации разделяют одну общую судьбу, потому что они являются частью Shared Risk Link Group (SRLG). Можно найти и обойти SRLG или ситуации с shared fate, но это усложняет плоскость управления и/или управление сетью. Например, невозможно обнаружить эти shared fate без ручного тестирования различных ситуаций отказа на физическом уровне или изучения сетевых карт, чтобы найти места, где несколько виртуальных каналов проходят по одному и тому же физическому каналу. В ситуации, описанной на рисунке 1, найти ситуацию с shared fate было бы почти невозможно, поскольку ни один из провайдеров, скорее всего, не скажет вам, что использует линию от второго провайдера, показанного на рисунке как провайдер 3, для предоставления услуг.
Как только эти ситуации с shared fate обнаружены, необходимо предпринять некоторые действия, чтобы избежать серьезного сбоя в работе сети. Обычно для этого требуется либо вводить информацию в процесс проектирования, либо усложнять дизайн, либо вводить информацию в плоскость управления (см. RFC8001 в качестве примера типа сигнализации, необходимой для управления группами SRLG в плоскости управления, спроектированной трафиком). По сути, проблема сводится к следующему набору утверждений:
Виртуализация - это форма абстракции.
Абстракция удаляет информацию о состоянии сети с целью снижения сложности или предоставления услуг за счет реализации политики.
Любое нетривиальное сокращение информации о состоянии сети так или иначе снизит оптимальное использование ресурсов.
Единственным противодействием конечному состоянию из этих трех, является протекание информации через абстракцию, поэтому можно восстановить оптимальное использование ресурсов - в этом случае отказ одного канала не вызывает полного отказа потока трафика через сеть. Единственное решение, таким образом, - сделать абстракцию сквозной абстракцией, что снизит эффективность абстракции при контроле области действия состояния и реализации политики.
Поверхности взаимодействия и наложенные плоскости управления
В сетевой инженерии принято накладывать друг на друга два протокола маршрутизации или две плоскости управления. Хотя это не часто рассматривается как форма виртуализации, на самом деле это просто разделение состояния между двумя различными плоскостями управления для контроля количества состояний и скорости изменения состояний, чтобы уменьшить сложность обеих плоскостей управления. Это также часто встречается при запуске виртуальных наложений в сети, поскольку между головным и хвостовым узлами туннеля будет существовать нижележащая плоскость управления, обеспечивающая достижимость, и плоскость управления наложением, обеспечивающая достижимость в виртуальной топологии. Две наложенные друг на друга плоскости управления будут взаимодействовать иногда неожиданным образом. Для иллюстрации используется рисунок 2.
На рисунке 2:
Каждый маршрутизатор в сети, включая B, C, D и E, использует две плоскости управления (или, если это проще, протоколы маршрутизации, отсюда протокол 1 и протокол 2 на рисунке).
Протокол 1 (оверлей) зависит от протокола 2 (базовый) для обеспечения доступности между маршрутизаторами, на которых работает протокол 1.
Протокол 2 не содержит информации о подключенных устройствах, таких как A и F; вся эта информация передается в протоколе 1.
Протокол 1 требует гораздо больше времени для схождения, чем протокол 2.
Более простой путь от B к E проходит через C, а не через D.
Учитывая этот набор протоколов, предположим, что C на рисунке 2 удален из сети, двум управляющим плоскостям разрешено сходиться, а затем C снова подключается к сети. Каков будет результат? Произойдет следующее:
После удаления C сеть снова объединится с двумя путями в локальной таблице маршрутизации в B:
F доступен через E.
E доступен через D.
После повторного подключения C к сети протокол 2 быстро сойдется.
После повторной конвергенции протокола 2 лучший путь к E с точки зрения B будет через C.
Следовательно, у B теперь будет два маршрута в локальной таблице маршрутизации:
F доступен через E.
E достижимо через C.
B перейдет на новую информацию о маршрутизации и, следовательно, будет отправлять трафик к F через C до того, как протокол 1 сойдется, и, следовательно, до того, как C узнает о наилучшем пути к F.
С момента, когда B начинает пересылку трафика, предназначенного для F в C, и момента, когда протокол 1 сойдется, трафик, предназначенный для F, будет отброшен.
Это довольно простой пример неожиданного взаимодействия наложенных протоколов. Чтобы решить эту проблему, вам необходимо ввести информацию о состоянии конвергенции протокола 1 в протокол 2, или вы должны каким-то образом заставить два протокола сходиться одновременно. В любом случае вы по существу добавляете состояние обратно в два протокола, чтобы учесть их разницу во времени конвергенции, а также создавая поверхность взаимодействия между протоколами.
Примечание: Этот пример описывает фактическое взаимодействие конвергенции между IS-IS и BGP, или протоколом Open Shortest Path First (OSPF) и BGP. Чтобы решить эту проблему, более быстрый протокол настроен на ожидание, пока BGP не сойдется, прежде чем устанавливать какие-либо маршруты в локальной таблице маршрутизации.
Одной из важнейших потребностей системы Linux является постоянное обновление последних исправлений безопасности, доступных для соответствующего дистрибутива.
В этой статье мы объясним, как настроить систему Debian и Ubuntu для автоматической установки и обновления необходимых пакетов безопасности или исправлений при необходимости.
Для выполнения задач, описанных в этой статье, вам понадобятся права суперпользователя.
Настройка автоматических обновлений безопасности в Debian и Ubuntu
Для начала установите следующие пакеты:
# aptitude update -y && aptitude install unattended-upgrades apt-listchanges -y
где apt-listchanges сообщит, что было изменено во время обновления.
Кстати, у нас есть статья, как сделать автоматическое обновление пакетов безопасности на CentOS или RHEL
Затем откройте /etc/apt/apt.conf.d/50unattended-upgrades в текстовом редакторе и добавьте эту строку в блок Unattended-Upgrade :: Origins-Pattern :
Unattended-Upgrade::Mail "root";
Наконец, используйте следующую команду для создания и заполнения необходимого файла конфигурации /etc/apt/apt.conf.d/20auto-upgrades для активации автоматических обновлений:
# dpkg-reconfigure -plow unattended-upgrades
Выберите Yes, когда будет предложено установить автоматические обновления (Automatically download and install stable updates? ) и затем убедитесь, что следующие две строки были добавлены в /etc/apt/apt.conf.d/20auto-upgrades:
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
И добавьте эту строку, чтобы сделать отчеты подробными:
APT::Periodic::Verbose "2";
Наконец, проверьте /etc/apt/listchanges.conf, чтобы убедиться, что уведомления будут отправлены в root.
email_address=root
Готово! В этой статье мы объяснили, как обеспечить регулярное обновление вашей системы последними обновлениями безопасности. Кроме того, вы узнали, как настроить уведомления, чтобы держать себя в курсе, когда применяются исправления.