По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Если вы на пути изучения Kubernetes, начните с лабораторной среды. Использование лабораторной среды позволит вам правильно развернуть и получить рабочую среду Kubernetes и это является одним из лучших способов проведения экспериментов и обучения.
В этой статье рассмотрим установку Minikube на Windows Hyper-V Server 2019, его конфигурацию и работу с приложениями и их развертываниями.
Что такое Minikube?
Minikube это простой и быстрый способ создать локальный кластер Kubernetes. Он работает на MacOs, Lunix и Windows системах. Также это отличный вариант для разработчиков и тех, кто еще плохо знаком или только начинает изучать Kubernetes.
Некоторые возможности и особенности решения Minikube:
Кроссплатформенность, т.е. поддерживает все основные ОС: Linux, macOS и Windows;
В зависимости от возможностей, можно развернуть в виртуальной машине, контейнере или на железо;
Поддержка Docker;
Наличие драйверов для VmWare, VirtualBox, Docker, KVM, Hyper-V и др.;
Поддержка последних версий Kubernetes;
Docker API для быстрого развертывания образов;
Использование дополнений (addons);
Minikube обладает интегрированной поддержкой Dashboard Kubernetes
Установка Minikube
Для работы в Minikube на Hyper-v нужно выполнить следующие действия:
Проверить соответствие минимальным требованиям
Предварительно настроить Hyper-v server
Выбрать диспетчер пакетов для установки Minikube
Установить Minikube
Запустить кластер Kubernetes
Подключиться к кластеру, посмотреть дашборд
1. Проверка соответствия минимальным требованиям:
Для развертывания и использования Minikube в соответствии с его документацией должны удовлетворяться следующие требования:
2 GB свободной оперативной памяти
2 или более CPU
От 20 GB или более свободного дискового пространства
Наличие интернет
Docker container или виртуальная машина, например, VirtualBox или Hyper-V
2. Настройка Hyper-v server
Какой-то специальной настройки Hyper-v не требует, должны выполняться стандартные требования для работы Hyper-v: 64-разрядный процессор с преобразованием адресов второго уровня (SLAT), достаточный объем оперативной памяти и быстрые диски. Поддержка виртуализации в BIOS/UEFI (у Intel - Intel VT, у AMD - AMD-V). Чтобы виртуальные системы имели доступ в интернет, нужно заранее создать внешний виртуальный коммутатор.
Вначале посмотрим доступные сетевые адаптеры:
Get-NetAdapter
Найденное имя адаптера добавим в команду ниже.
Создать новый внешний сетевой адаптер можно командой PowerShell
New-VMSwitch -name ExternalSwitch -NetAdapterName "Ethernet 2" -AllowManagementOS $true
В противном случае при первом запуске Minikube покажет ошибку:
! StartHost failed, but will try again: creating host: create: precreate: no External vswitch nor Default Switch found. A valid vswitch must be available for this command to run.
Попросит выполнить minikube delete и отправит читать документацию: https://docs.docker.com/machine/drivers/hyper-v/
3. Диспетчер пакетов
В этой статье используется Windows Server 2019, и мы будем использовать Chocolatey, так как другой диспетчер пакетов - Windows Package Manager поддерживает только Windows 10.
Из PowerShell выполним команды:
iwr https://chocolatey.org/install.ps1 -outfile C:install.ps1
c:install.ps1
4. Инсталляция Minikube
После установки Chocolatey нужно выполнить команду:
choco install minikube
5. Запуск
Если после выполнения команды minikube start он не запускается, значит нужно установить соответствующие драйвера и провайдер
Для запуска с привилегированными правами, выполним:
runas /noprofile /user:администратор powershell
В нашем случае для Hyper-V выполняем:
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All
Проверим установку компонентов:
Get-WindowsFeature –Name –hyper-v
Выяснилось, что актуальная версия Minikube не работает c Hyper-v, понизим версию командой
choco install minikube --version 1.6.2 --allow-downgrade
затем удалим minikube delete и снова запустим
minikube start
6. Подключение
Проверить, что VM запущена, поможет команда PowerShell
Get-vm
Просмотреть, что окружение запущено можно командой kubectl get po –A
Подготовим хостовую систему для работы браузеров, установив дополнительные компоненты:
Add-WindowsCapability -Online -Name ServerCore.AppCompatibility~~~~0.0.1.0
И перезагрузим сервер, затем выполним команду minikube dashboard
На сервер предварительно скопирован браузер Firefox, в нем откроем ссылку и убедимся в работоспособности.
Предыдущая статья из цикла про устранение неисправностей DHCP на Cisco доступна по ссылке.
Последняя статья будет посвящена некоторым проблемам с FHRP, мы начнем с VRRP!
Урок 1
В сценарии выше у нас есть проблема с HSRP. Сначала разберем топологию. С левой стороны находится клиент (мы используем маршрутизатор, чтобы иметь возможность воссоздать его в GNS3), который использует виртуальный IP-адрес в качестве шлюза по умолчанию. R2 и R3 настроены для HSRP. На правой стороне есть маршрутизатор с IP-адресом 4.4.4.4 на интерфейсе loopback0. К сожалению, наш клиент не может пропинговать 4.4.4.4. Что здесь происходит?
Сначала мы отправим эхо-запрос от клиента на IP-адрес 4.4.4.4. Вы видите символ U (недостижимый), поэтому мы знаем, что получаем ответ от шлюза по умолчанию.
Таблица маршрутизации была отключена на этом клиентском маршрутизаторе (нет ip-маршрутизации), но вы можете видеть, что шлюз по умолчанию был настроен. Давайте посмотрим, доступен ли этот IP-адрес.
Достигнуть шлюза по умолчанию не проблема, поэтому мы можем перенести фокус на R2 или R3.
Мы можем использовать команду show standby, чтобы убедиться, что R3 является активным маршрутизатором HSRP. Давайте проверим, может ли он достичь IP-адреса 4.4.4.4.
Увы ...пинг не проходит.
Его нет в таблице маршрутизации, и если вы посмотрите внимательно, то увидите, что FastEthernet1/0 не находится в таблице маршрутизации как непосредственно подключенный, это указывает на то, что что-то не так с этим интерфейсом.
Ну вот...интерфейс отключен.
R3(config)#interface fastEthernet 1/0
R3(config-if)#no shutdown
Включим его!
Ну вот, теперь он работает.
Проблема устранена ... теперь клиент может пинговать 4.4.4.4! Есть еще одна вещь, хотя ... мы используем HSRP, так что наш шлюз по умолчанию не является единственной точкой отказа, но в этом случае R3 имел сбой соединения...разве R2 не должен взять на себя управление?
interface tracking было включено, и вы можете видеть, что приоритет должен уменьшиться на 10, если интерфейс FastEthernet1/0 перейдет в состояние down. Это означает, что обычно R2 должен взять на себя управление, но preemption is disabled по умолчанию для HSRP.
R2(config)#interface fastEthernet 0/0
R2(config-if)#standby 1 preempt
R3(config)#interface fastEthernet 0/0
R3(config-if)#standby 1 preempt
Прежде чем отпраздновать нашу победу в устранении неполадок, мы должны убедиться, что эта проблема больше не возникнет в будущем. Мы включим приоритет на обоих маршрутизаторах. Теперь все готово!
Итог урока: убедитесь, что preemption включена для HSRP, если вы используете interface tracking
Урок 2
Вот та же топология, но на этот раз мы используем VRRP вместо HSRP. Однако проблема заключается в другом: клиент жалуется, что не все IP-пакеты попадают в 4.4.4.4.
Некоторые из IP-пакетов не поступают в 4.4.4.4.
IP-адрес шлюза: 192.168.123.254.
Шлюз пингуется без проблем.
R2 не может достичь 4.4.4.4, но у R3 нет никаких проблем. Прежде чем мы продолжим проверять, почему R2 не может достичь 4.4.4.4, мы взглянем на конфигурацию VRRP, чтобы увидеть, какой маршрутизатор является главным.
Вывод show vrrp интересен. Оба маршрутизатора считают, что они активны, и, если вы посмотрите внимательно, вы поймете, почему. Аутентификация включена, и в key-string имеется несоответствие. Поскольку оба маршрутизатора активны, половина пакетов окажется в R2, а остальные в R3. Вот почему наш клиент видит, что некоторые пакеты приходят, а другие нет. Давайте исправим нашу аутентификацию:
R2(config)#interface fa0/0
R2(config-if)#vrrp 1 authentication md5 key-string SECRET
Мы сделаем key-string одинаковыми.
Это сообщение в консоли R2 является многообещающим.
R3 был выбран в качестве главного маршрутизатора. Теперь давайте выясним, почему R2 не смог достичь 4.4.4.4, поскольку эта проблема устранена.
Странно, R2 показывает только одну запись в таблице маршрутизации, что-то не так с FastEthernet 1/0.
Кажется, кому-то нравится команда shutdown Имейте в виду, что это может быть что-то еще списки доступа, blocking traffic между R2 и R4, port-security (если был коммутатор в середине), интерфейсы в режиме err-disabled, неправильные IP-адреса и другое. Проверьте все!
R2(config)#interface fastEthernet 1/0
R2(config-if)#no shutdown
Включим интерфейс!
Проблема устранена!
Итог урока: убедитесь, что маршрутизаторы VRRP могут связаться друг с другом.
Также, как и системы электронной почты, системы VoIP телефонии есть практически у каждой компании. Это могут быть простые облачные АТС, арендуемые у провайдера или собственные выделенные под IP-АТС серверные мощности, но среда, по которой передаётся сигнализация и пользовательский трафик данных систем один – Интернет. Это делает систему VoIP телефонии одной из самых востребованных злоумышленниками целей, ведь получив к ней доступ, открывается масса возможностей для извлечения прибыли или нанесения другого ущерба. Если Вы банально откроете логи своего межсетевого экрана и поищите запросы, поступающие извне, то наверняка увидите, что тысячи сканеров каждую секунду пробуют узнать какие сервисы работают на вашем внешнем адресе. И даже если этот адрес никак не связан с IP-телефонией, то вы всё равно там увидите запросы, связанные с VoIP. Это говорит о том, что злоумышленники очень хотят найти уязвимые системы телефонии и знают как проэксплуатировать выявленную брешь. В этой статье разберём какой профит получают хакеры, взломавшие VoIP систему, основные методы атак и протоколы, на которые они направлены. Чего хотят плохие парни? Как только Ваша систему IP-телефонии будет зарегистрирована в сети VoIP провайдера – вы сможете позвонить в любой уголок мира - на мобильный телефон в Тайване, на такософон в одной из красных будок Лондона и даже на декадно-шаговую АТС в музее Франкфурта-на-Майне! Что сделает злоумышленник, получивший такую возможность? – Воспользуется ею за Ваш счёт! В большинстве плачевно известных случаев, получая доступ к системе по средствам какой-либо уязвимости, злоумышленники делают следующее: совершают дорогостоящие звонки на дальние расстояния (long-distance calls); перепродают возможность звонка третьим лицам, не подозревающим, что услуга предоставляется на украденных мощностях звонят на номера с премиум обслуживанием, зарабатывая кэшбэк на свой счёт Существует провайдеры телефонных номеров с премиум обслуживанием (international premium rate number - IPRN). Это такие номера, звонки на которые, происходят очень часто и со всего мира. Например, номера для технической поддержки, прогноза погоды, сервисы для взрослых. Провайдеры таких номеров платят часть прибыли тому, кто гонит на них трафик - генератору звонков (call generator). В некоторых случаях провайдер осознанно участвует в мошеннической схеме, а иногда и вовсе не подозревает, что платит кэшбэк злоумышленникам за трафик, сгенерированный на "угнанных" мощностях. В конечном итоге и провайдеры и call generator'ы остаются в выигрыше, а платить приходится тому кого взломали. Всё вышеописанное подпадает под одно определение, которому в английской литературе дали название - toll fraud. На русский язык это можно перевести как неправомочные действия и несанкционированное пользование чужими ресурсами телефонной связи. Злоумышленникам также может быть интересно вывести вашу систему телефонии из строя, устроив атаку типа DoS (Denial of service) - отказ в обслуживании, хотя это случается реже toll fraud'а. Нам известны случаи, когда целый ботнет из серверов FreePBX начинал забрасывать IP-АТС заказчика "мусорными" вызовами, в результате чего на какое-то время, пользоваться системой стало просто невозможно. Техническая реализация Согласно исследованию IBM наиболее атакуемыми VoIP протоколами являются SIP, SCCP и H.255. Самым распространённым VoIP протоколом на сегодняшний день является SIP, поэтому и большинство атак осуществляется именно на этот протокол. Всё начинается с поиска сервера для проведения атаки. Протокол SIP использует стандартный порт 5060, поэтому первое, что сделает потенциальный злоумышленник – это отправит SIP-запрос на данный порт, чтобы посмотреть какой придет ответ. Как правило, для поиска SIP-сервиса используются стандартные запросы INVITE, REGISTER или OPTIONS. Хорошей практикой является перенос SIP-сервиса со стандартного порта на какой-нибудь другой. Таким образом мы можем увести сервис из-под удара. Ещё лучше – ограничить доступ к этому порту только для доверенного списка IP-адресов. Однако, иногда такой возможности просто нет. Для изначального установления соединения в SIP используется метод “тройного рукопожатия” , начинающийся с запроса INVITE, который подтверждается ответом 200 OK. Однако, если этот ответ от вызывающей стороны не получен, то соединение не устанавливается. Если наблюдается много таких незаконченных соединений за коротких промежуток времени, то это может быть признаком того, что против сервера идёт DoS-атака. Кстати, точно таким же образом, злоумышленник может провести атаку против легитимного устройства пользователя, чтобы сбросить его регистрацию на сервере и зарегистрироваться самому. Существует также метод “флуда” запросами REGISTER. Для этого злоумышленник должен знать параметры зарегистрированного устройства, регистрацию которого он хочет сбросить, подделать заголовок Contact в SIP пакете и отправить много (достаточно раз в 15 секунд) запросов REGISTER на сервер. Такой метод называется Registration-hijacking. Эти атаки возможны благодаря тому, что протокол SIP передает информацию в открытом виде, а значит атакующий может её собрать, модифицировать и воспроизвести. Помимо этого, в протоколе SIP не предусмотрено проверки целостности сообщений, поэтому атаки с модифицированной информацией и воспроизведенными пакетами не детектируются. Злоумышленникам совсем не обязательно перехватывать ваш трафик, чтобы вытащить запросы регистраций легитимных пользователей, потом модифицировать их и подсовывать обратно серверу. После обнаружения открытого SIP-порта, можно просто устроить перебор зарегистрированных внутренних номеров, например, от 10 до 9999. Ответ от сервера на запрос регистрации по такой схеме будет однозначно свидетельствовать о том, какие номера есть на IP-АТС, а каких там нет. Например, я могу отправить запрос на регистрацию с номера 2526 с неправильным паролем. Если на сервере зарегистрирован такой номер, то я получу ответ, что пароль неверен (Wrong Password), а если нет – то сообщение о том, что номер не найден (Not Found). Собрав список зарегистрированных номеров можно потом применить против них метод перебора паролей и получить доступ к внутреннему номеру легитимного пользователя. Другой неприятные метод атаки на VoIP позволяет прослушивать ваши телефонные разговоры. Для этого необходимо перехватить сигнальную информацию и соответствующие медиа потоки определенного соединения. Медиа потоки, которые как раз и содержат пакеты с голосом, обычно передаются по UDP с использованием протокола RTP. Захватив достаточное количество пакетов, можно декодировать RTP поток, а затем сделать из них простой аудио файл, который и будет содержать голос. Сделать это можно с помощью программы Wireshark. Мы рассказали про базовые методы проведения атак на VoIP системы. В следующих статьях, мы обязательно расскажем как защититься от каждого типа атаки, как выявить признаки атак и какие инструменты можно для этого использовать.