Hns container networking ics dns tcp in что это

Обновлено: 03.07.2024

Я планирую удалить повторяющиеся правила брандмауэра в Windows. Я знаю, что существует набор командлетов брандмауэра, таких как get-netfirewallrule , но он слишком медленный, когда я пытаюсь передать правило брандмауэра, чтобы получить дополнительную информацию, например Get-NetFirewallRule -displayname xxx | Get-NetFirewallApplicationFilter . Так что я планирую использовать старый метод, набор команд netsh advfirewall firewall .

Теперь я проанализировал вывод netsh advfirewall firewall как массив объектов.

Но проблема в том, что объекты в массиве имеют разные свойства. Например, это один объект:

Как видите, первое правило использует порты, а также программу для определения правила, а второе использует только порты. Как я могу сгруппировать объекты и найти повторяющиеся элементы (чтобы удалить соответствующие правила брандмауэра)? Я не могу просто использовать $objects | Group-Object -Property rulename,enabled. , потому что свойства не одинаковы для всех объектов.

Кстати, повторяющиеся правила брандмауэра созданы каким-то несовершенным скриптом, который я написал в прошлом.

1 ответ

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

Я объясню изменения, которые я внес в ваш код:

Установите $output в одну строку (здесь сделана многострочной для удобства чтения). Не обязательно.
Используйте оператор -split вместо [regex]::split() для согласованности с остальной частью вашего кода.
Создал список под названием $propertyNames . Это будет использоваться для отслеживания всех имен свойств, которые были прочитаны из вашего вывода.
Подвыпишите $() свой первый цикл foreach , чтобы избежать необходимости в промежуточной переменной и позволить нам передать вывод foreach по конвейеру. Это необходимо в конце. Это должно быть подвыражение, а не просто заключенное в () .
Сделайте $obj hashtable вместо PSCustomObject . С ним легче работать, изменяя объект, и его можно преобразовать в PSCustomObject в конце.
Add-Member больше не требуется, поскольку у нас есть hashtable , поэтому $obj.$name = $value будет достаточно для установки имени и значения свойства.
- Примечание. Если вы примените эту часть ответа в других областях, обратите внимание на подводные камни, если имя свойства не является строкой. В качестве альтернативы вы можете использовать традиционный синтаксис доступа к массиву, если это вызывает беспокойство: $obj[$name] = $value .
Вот разница между вашим кодом и моими изменениями:

Теперь каждый возвращаемый объект должен иметь одинаковые свойства, даже если они не отображаются в исходном выводе для этого правила.

На прошлой неделе фонд CNCF (Cloud Native Computing Foundation) объявил о принятии под своё крыло 10-го Open Source-проекта — CNI (Container Networking Interface). Его задача — обеспечить всё необходимое для стандартизированного управления сетевыми интерфейсами в Linux-контейнерах и гибкого расширения сетевых возможностей. В CNCF объяснили необходимость такого проекта активным распространением контейнеризированных приложений в мире production и утверждают, что «подобно тому, как Kubernetes позволяет разработчикам массово запускать контейнеры на тысячах машинах, этим контейнерам в больших масштабах требуется сетевое управление [и реализующий его фреймворк]».

Как же появился CNI и что он предлагает?

Предыстория CNI

Проект Container Network Interface (CNI) зародился в компании CoreOS, известной по движку для контейнеров rkt (недавно был тоже передан в CNCF, одновременно с containerd), NoSQL-хранилищу etcd, активной работе над Kubernetes и другими Open Source-проектами, связанными с контейнерами и DevOps. Первая подробная демонстрация CNI состоялась ещё в конце 2015 года (см. видео в октябре, презентацию в ноябре). С самого начала проект позиционировался в качестве «предлагаемого стандарта для конфигурации сетевых интерфейсов для Linux-контейнеров», а использовать его первым делом начали, конечно же, в rkt. Первыми «сторонними пользователями» CNI стали Project Calico, Weaveworks, а в скором времени к ним примкнул Kubernetes.

Адаптация CNI в платформе Kubernetes стоит отдельного внимания. Поскольку потребность в стандартизации сетевой конфигурации Linux-контейнеров была очевидной и всё более актуальной на тот момент (

2015 год), CNI оказался не единственным таким проектом. Конкурирующий продукт — Container Network Model (CNM) от Docker, представленный в том же 2015-м, — решал те же задачи и получил свою эталонную реализацию в виде libnetwork — библиотеки, которая выросла из сетевого кода в libcontainer и Docker Engine. И важным этапом в противостоянии CNI и CNM стал выбор, сделанный Kubernetes. В статье «Почему Kubernetes не использует libnetwork?» (январь 2016 года) разработчики подробно описывают все технические и иные причины, объясняющие их решение. Основная же суть (помимо ряда технических моментов) сводится к следующему:

CNI ближе к Kubernetes с философской точки зрения. Он гораздо проще CNM, не требует демонов и его кроссплатформенность по меньшей правдоподобна (исполняемая среда контейнеров CoreOS rkt поддерживает его) [… а Kubernetes стремится поддерживать разные реализации контейнеров — прим. перев.]. Быть кроссплатформенным означает возможность использования сетевых конфигураций, которые будут одинаково работать в разных исполняемых средах (т.е. Docker, Rocket, Hyper). Этот подход следует философии UNIX делать одну вещь хорошо.

По всей видимости, именно это (не только выбор Kubernetes, но и сторонний взгляд технических специалистов на существующие реализации) предопределило будущее CNI и его принятие в CNCF. Для сравнения, другие конкурирующие продукты CoreOS и Docker: среды исполнения контейнеров rkt и conatinerd — были приняты в фонд вместе и одновременно, а вот с CNI/CNM этого не произошло.

Взгляд проекта Calico на сети для контейнеров в марте 2016 года

Дополнительное сравнение CNI и CNM по состоянию на сентябрь 2016 года можно также найти в англоязычной статье на The New Stack.

Устройство CNI

Авторы CNI пошли путём создания минимально возможной спецификации, предназначение которой — стать лёгкой прослойкой между исполняемой средой контейнера и плагинами. Все необходимые сетевые функции реализуются именно в плагинах, взаимодействие с которыми определено схемой в формате JSON.

CNI состоит из трёх частей:

1. Спецификации (см. GitHub), определяющей API между исполняемой средой контейнера и сетевыми плагинами: обязательные поддерживаемые операции (добавление контейнера в сеть и удаление его оттуда), список параметров, формат конфигурации сети и их списков (хранятся в JSON), а также известных структур (IP-адресов, маршрутов, DNS-серверов).

Пример конфигурации сети в CNI:

2. Официальных плагинов, предоставляющих сетевые конфигурации для разных ситуаций и служащих примером соответствия спецификации CNI. Они доступны в containernetworking/plugins и разбиты на 4 категории: main (loopback, bridge, ptp, vlan, ipvlan, macvlan), ipam (dhcp, host-local), meta (flannel, tuning), sample. Все написаны на Go. (Про сторонние плагины см. в следующем разделе статьи.)

3. Библиотеки (libcni), предлагающей реализацию спецификации CNI (тоже на языке Go) для удобного использования в исполняемых средах контейнеров.

Весь имеющийся код (и спецификация) опубликованы под свободной лицензией Apache License v2.0.

Быстро попробовать CNI

«Потрогать руками» CNI можно и без контейнеров. Для этого достаточно загрузить себе файлы из репозитория проекта (и, по желанию, нужных плагинов), собрать их с ./build.sh (или скачать уже бинарную сборку), после чего — воспользоваться исполняемым файлом плагина (например, ./bin/bridge ), передав ему необходимые для функционирования аргументы через переменные окружения CNI_* , а сетевую конфигурацию — прямо JSON-данными через STDIN (так предусмотрено в спецификации CNI).

Подробности о таком эксперименте можно найти в этой статье, автор которой делает приблизительно следующее (на хосте в Ubuntu):

Дополнительные примеры для быстрого запуска CNI и сетевых плагинов представлены в README проекта (раздел «How do I use CNI?»).

Сторонние плагины для CNI

Одной из главных ценностей CNI, конечно же, являются сторонние плагины, обеспечивающие поддержку различных современных решений для Linux-контейнеров. Среди них:
- Project Calico (виртуальная сеть L3, интегрированная с инструментами оркестровки и облачными платформами);
- Weave (простая сеть для multi-host Docker-инсталляций);
- Contiv Netplugin (политики/ACL/QoS и другие возможности для контейнеров в кластерных установках типа multi-host);
- Flannel (сетевая фабрика для контейнеров от CoreOS);
- SR-IOV, Cilium (BPF/XDP), Multus (плагин Multi для Kubernetes от Intel), VMware NSX и другие…
Дополнительным индикатором зрелости проекта является его интеграция в существующие исполняемые среды для контейнеров: rkt и Kurma, — и платформы для работы с контейнерами: Kubernetes, OpenShift, Cloud Foundry, Mesos.

Заключение

Текущий статус CNI позволяет уже сейчас говорить не только о «больших перспективах» проекта, но и ощутимых реалиях его практической применимости. Принятие в CNCF — официальное признание индустрией и гарантия для дальнейшего развития. А всё это означает, что самое время как минимум узнать про CNI, с которым скорее всего рано или поздно придётся встретиться.

Общие сетевые команды DOCKER, параметры и синтаксис см. в справочнике по сетевым контейнерам DOCKER. за исключением любых случаев, описанных в разделе неподдерживаемые функции и сетевые параметры, все сетевые команды docker поддерживаются в Windows с тем же синтаксисом, что и в Linux. однако сетевые стеки Windows и linux отличаются друг от друга, и поэтому вы обнаружите, что некоторые сетевые команды Linux (например, ifconfig) не поддерживаются в Windows.

Базовая сетевая архитектура

В этом разделе приведено описание того, каким образом Docker создает и администрирует сети узлов в Windows. В отношении сетевых подключений контейнеры Windows функционируют аналогично виртуальным машинам. У каждого контейнера есть виртуальный сетевой адаптер (vNIC), который подключен к виртуальному коммутатору Hyper-V (vSwitch). Операционная система Windows поддерживает пять различных сетевых драйверов (или по-другому "режимов"), которые можно создать через Docker: nat, overlay, transparent, l2bridge и l2tunnel. В зависимости от особенностей физической сетевой инфраструктуры и от того, должна ли сеть быть одно- или многоузловой, необходимо выбрать сетевой драйвер, который наилучшим образом соответствует вашим потребностям.

при первом запуске подсистема docker создает сеть nat по умолчанию, nat, которая использует внутренний vSwitch и компонент Windows с именем WinNAT . При наличии на узле других внешних виртуальных коммутаторов, созданных с помощью оболочки командной строки PowerShell или диспетчера Hyper-V, они также будут доступны подсистеме Docker посредством сетевого драйвера transparent и будут отображаться при запуске команды .
- Внутренний vSwitch — это не подключенное напрямую к сетевому адаптеру на узле контейнера.
- Внешняя vSwitch — это тот, который напрямую подключен к сетевому адаптеру на узле контейнера.
Сеть "nat" — это сеть по умолчанию для контейнеров под управлением Windows. Все контейнеры, которые работают под управлением Windows без каких-либо флагов или аргументов, использующихся для реализации конкретной сетевой конфигурации, будут подключены к сети "nat" по умолчанию и им будет автоматически присвоен IP-адрес из диапазона IP-адресов внутреннего префикса сети "nat". Для "nat" по умолчанию используется следующий внутренний префикс IP-адреса: 172.16.0.0/16.

Управление сетью контейнера с помощью сетевой службы узлов

Сетевая служба узлов (HNS) и вычислительная служба узлов (HCS) совместно используются для создания контейнеров и подключения конечных точек к сети. Вы можете взаимодействовать с HNS с помощью модуля поддержки HNS PowerShell.

Создание сети
- Служба HNS создает виртуальный коммутатор Hyper-V для каждой сети
- Служба HNS создает преобразование сетевых адресов (NAT) и пулы IP-адресов по мере необходимости
Создание конечных точек
- Служба HNS создает пространство имен сети для каждой конечной точки контейнера
- Служба HNS/HCS размещает сетевой адаптер виртуальной машины в пространстве имен сети
- Служба HNS создает порты виртуального коммутатора
- Служба HNS назначает конечной точке IP-адрес, сведения DNS, маршруты и т. д. (в зависимости от сетевого режима)
Создание политики
- для сети преобразования сетевых адресов (NAT) по умолчанию в службе HNS создаются правила пересылки портов WinNAT и сопоставления, соответствующие Windows брандмауэр разрешают правила.
- Для всех остальных сетей служба HNS использует виртуальную платформу фильтрации (VFP) для создания политики, которая включает в себя балансировку нагрузки, списки ACL и инкапсуляцию. Дополнительные сведения об API-интерфейсах и схеме для службы HNS см. в статье API служб для виртуальных машин и контейнеров (хкн).
Неподдерживаемые функции и сетевые параметры

В настоящее время в Windows не поддерживаются следующие сетевые параметры:

Все перечисленные ниже команды протестированы с правами root в Ubuntu.

Для управления сетевыми операциями, такими как создание новой сети, подключение контейнера к сети, отключение контейнера от сети, перечисление доступных сетей, удаление сетей и т. д., мы используем следующую команду:

Типы сетевых драйверов Docker

Чтобы получить список всех ваших сетей, запустите:
- Bridge network при запуске Docker автоматически создается сеть типа мост по умолчанию. Недавно запущенные контейнеры будут автоматически подключаться к нему. Вы также можете создавать пользовательские настраиваемые мостовые сети. Пользовательские мостовые сети превосходят сетевые мосты по умолчанию.
- Host network : удаляет сетевую изоляцию между контейнером и хостом Docker и напрямую использует сеть хоста. Если вы запускаете контейнер, который привязывается к порту 80, и вы используете хост-сеть, приложение контейнера доступно через порт 80 по IP-адресу хоста. Означает, что вы не сможете запускать несколько веб-контейнеров на одном хосте, на одном и том же порту, так как порт теперь является общим для всех контейнеров в сети хоста.
- None network : в сети такого типа контейнеры не подключены ни к одной сети и не имеют доступа к внешней сети или другим контейнерам. Итак, эта сеть используется, когда вы хотите полностью отключить сетевой стек в контейнере.
- Overlay network : Создает внутреннюю частную сеть, которая охватывает все узлы, участвующие в кластере swarm. Таким образом, оверлейные сети облегчают обмен данными между сервисом Docker Swarm и автономным контейнером или между двумя автономными контейнерами на разных демонах Docker.
- Macvlan network : Некоторые приложения, особенно устаревшие приложения, отслеживающие сетевой трафик, ожидают прямого подключения к физической сети. В такой ситуации вы можете использовать сетевой драйвер Macvlan для назначения MAC-адреса виртуальному сетевому интерфейсу каждого контейнера, что делает его физическим сетевым интерфейсом, напрямую подключенным к физической сети.
Позвольте мне показать вам практические упражнения для сетей Bridge и Host.
Сеть типа bridge

Я буду использовать два Alpine-контейнера для объяснения этого типа сети.

Теперь я собираюсь запустить два контейнера Alpine, а именно C1 и C2, используя команды:

Далее, давайте выясним IP-адрес этих запущенных контейнеров. Для этого запустите:

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

Как вы можете видеть на скриншотах, показанных выше, происходит конекшен между контейнерами в одной сети.

Мы также можем проверить это, проверив сеть типа мост с помощью команды:
Приведенная выше команда отобразит всю информацию о сети, такую как тип сети, подсеть, шлюз, имя контейнера и IP-адрес и т. д.

1.1 Создание пользовательской Bridge сети

Как я уже говорил, при запуске Docker автоматически создается сеть bridge по умолчанию.

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

Однако вы также можете создавать пользовательские мостовые сети.

Чтобы создать новый сетевой драйвер, просто запустите:
Если вы не укажете имя драйвера, сеть будет создана в сетевом драйвере по умолчанию, т.е. bridge.

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

Чтобы убедиться, что контейнеры могут взаимодействовать друг с другом, давайте запустим три alpine контейнера, а именно A1, A2 и A3 в сети dhruv_net, которую мы создали ранее.

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

Из приведенных выше снимков экрана доказано, что контейнеры могут общаться друг с другом.
2. Хостовая Сеть

Мы запускаем контейнер, который привязывается к порту 80, используя хост-сеть, приложение контейнера доступно через порт 80 по IP-адресу хоста.

Что такое Handshake (HNS)?
Handshake - это программное обеспечение, которое направлено на поощрение работы распределенной компьютерной сети и управления новой системой владения доменным именем.

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

Есть еще один важный побочный эффект от создания альтернативы централизованной организации, такой как ICANN. Со временем группа компаний, занимающихся управлением доменными именами, называемая центрами сертификации или ЦС, может устареть.

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

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

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

Проще говоря, Handshake - это система распределения адресов веб-сайтов через аукционы.

При Handshake аукционы для доменов верхнего уровня проводятся каждые две недели. Для участия в аукционе пользователи должны делать ставки на криптовалюту HNS компании Handshake.

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

Цепочка блоков Handshake
Блокчейн Handshake имеет несколько общих черт с блокчейном Bitcoin. Например, майнеры, использующие программное обеспечение Handshake, соревнуются, чтобы разблокировать недавно отчеканенные токены HNS, решая математические головоломки и добавляя блоки в цепочку блоков Handshake.

Как и в случае с Bitcoin, новые блоки добавляются в цепочку блоков каждые 10 минут. Также, как и Bitcoin, у Handshake есть фиксированный лимит в 2,04 миллиарда на предложение HNS, которое может быть создано.

Майнерам, занимающимся Handshake , платят 2000 HNS каждые 10 минут за выполнение этой задачи.

Имена Handshake должны быть запрошены на аукционе. Все возможные имена рукопожатий будут доступны для торгов в течение одного года после запуска сети рукопожатия.

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

100 000 веб-адресов с наибольшим объемом трафика, по данным Alexa, зарезервированы для их нынешних владельцев в Handshake, чтобы предотвратить злоупотребления системой.

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

Аукционы являются основным средством получения имен Handshake. Пользователи могут делать ставки на имя примерно каждые 14 дней. Предложения являются специальными, и выигрывает самая высокая ставка.

Handshake - это продукт группы технологов, глубоко вовлеченных в криптовалюту.

В эту группу входят Джозеф Пун, который помог создать сеть Bitcoin Lightning Network, и Кристофер «Джей Джей» Джеффри, технический директор раннего стартапа Bitcoin Purse.

На данный момент команда Handshake получила 10,2 миллиона долларов инвестиций от авторитетных венчурных компаний. К ним относятся Andreesen Horowitz, Draper Associates и Фонд учредителей Питера Тиля. Всего в финансовом туре приняли участие 67 инвесторов.

Инвесторы получили 7,5% от первоначального предложения 1,36 млрд HNS.

Следует отметить, что создатели Handshake попытались быстро инициировать коррупцию криптовалюты HNS, творчески установив цены и распределяя токены HNS.

После того, как команда выделила около 15% токенов HNS для разработчиков и инвесторов, 68% пошли разработчикам с открытым исходным кодом и продолжили распределять оставшуюся часть первоначального предложения.

Поскольку создатели Handshake чувствовали, что всем сторонам, заинтересованным в доменных именах, понадобится стимул для принятия их новых систем, остальная часть HNS была выделена ICANN и CA, ведущим веб-сайтам сети.

Handshake был официально запущен 3 февраля 2020 года.

Почему HNS имеет ценность?
Официальная валюта сети Handshake - HNS. Это означает, что пользователи должны приобретать HNS, чтобы участвовать в аукционах по доменным именам и платить сборы за продление для этих существующих адресов.

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

Читайте также: