По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Настройка EIGRP сильно напоминает RIP и состоит из двух шагов:
включения протокола глобальной командой router eigrp ASN_NUMBER;
выбора сетей, которые протокол будет «вещать», для чего используется команда(ы) network;
Первая команда включения говорит сама за себя, но поясним про ASN_NUMBER – это номер автономной системы, и для установления сетевой связности между несколькими маршрутизаторами, использующими EIGRP, данный номер должен быть одинаковым. Вторая команда работает также, как и в RIP по умолчанию – то есть включение протокола на интерфейсе и указание классовых сетей.
Пример настройки EIGRP
В нашей топологии у маршрутизаторов R1 и R2 есть напрямую подключенные подсети.
Нам нужно включить данные подсети в процесс динамической маршрутизации EIGRP. Для этого нам сначала нужно включить EIGRP на обоих маршрутизаторах и затем «вещать» данные сети с помощью команды network. На маршрутизаторе R1 переходим в глобальный режим конфигурации и вводим следующие команды:
router eigrp 1
network 10.0.0.0
network 172.16.0.0
Немного пояснений – сначала мы включаем протокол динамической маршрутизации, затем меняем версию на вторую, затем используем команду network 10.0.0.0 для включения интерфейса Fa0/1 на маршрутизаторе R1. Как мы уже говорили, команда network берет классовую сеть, так что каждый интерфейс с подсетью, начинающейся на 10 будет добавлен в EIGRP процесс. Также нам необходимо получить маршрут между двумя роутерами через EIGRP, для этого добавляем еще одну команду network – с адресом 172.16.0.0.
IP-адреса начинающиеся на 10, по умолчанию принадлежат к классу «А» и и имеют стандартную маску подсети 255.0.0.0.
На R2 настройка выглядит похожей, только с другой подсетью – т.к к маршрутизатору R2 напрямую подключена подсеть 192.168.0.0.
router eigrp 1
network 192.168.0.0
network 172.16.0.0
Вот и все – также просто, как и настроить RIP: главное не забывать указывать одинаковый номер автономной системы. Для проверки работоспособности EIGRP введите команду show ip eigrp neighbors на обоих маршрутизаторах и убедитесь, что там указан адрес другого маршрутизатора. Данная команда показывает список всех EIGRP «соседей», с разнообразной информацией – номером локального интерфейса и т.д Также проверить сетевую связность можно с помощью команды вывода таблицы маршрутизации sh ip route. Маршруты, получаемые по EIGRP будут отмечены буквой «D».
Пример настройки EIGRP 2
Как мы уже говорили, по умолчанию команда network использует классовую сеть, т.е все интерфейсы внутри это классовой сети будут участвовать в процессе маршрутизации. Для включения EIGRP только на нужном вам интерфейсе, необходимо использование обратной маски. То есть команда будет выглядеть следующим образом: network ОБРАТНАЯ_МАСКА
В нашем примере у маршрутизатора R1 есть две напрямую подключенные подсети, 10.0.0.0/24 и 10.0.1.0/24. Наша цель – включить EIGRP только на подсети, подключенной к интерфейсу Fa0/0. Если просто использовать команду network – обе подсети будут добавлены в EIGRP процесс, т.к будет использоваться классовая сеть. Для настройки EIGRP только на интерфейсе Fa0/0, нужно использовать команду network 10.0.0.0 0.0.0.255. Она включит EIGRP только на интерфейсах 10.0.0.Х.
Проверить можно с помощью команды sh ip protocols, что только сеть 10.0.0.0/24 добавлена в EIGRP процесс.
Сегодня в статье рассказываем про плагин kubectl, который использует tmux, чтобы быстрее устранить неполадки Kubernetes.
Kubernetes - это процветающая платформа для взаимодействия контейнеров с открытым исходным кодом, которая обеспечивает масштабируемость, высокую доступность, надежность и отказоустойчивость приложений. Одной из его многочисленных функций является поддержка запуска пользовательских сценариев или двоичных файлов через основной двоичный файл клиента, kubectl. Kubectl очень мощный, и позволяет пользователям делать с ним все, что они могли бы сделать непосредственно в кластере Kubernetes.
Устранение неполадок с псевдонимами Kubernetes
Каждый, кто использует Kubernetes для управления контейнерами, знает о его особенностях - а также о сложности, причиной которого является его дизайн. Например, существует острая необходимость упростить поиск и устранение неисправностей в Kubernetes с помощью чего-то более быстрого и практически не требующего ручного вмешательства (за исключением критических ситуаций).
Существует много сценариев, которые следует учитывать при устранении неполадок. В одном сценарии вы знаете, что нужно запускать, но синтаксис команды - даже если она может выполняться как одна команда - чрезмерно сложен, или для работы может потребоваться один-два входа.
Например, если часто требуется перейти в запущенный контейнер в пространстве имен System, вы можете неоднократно писать:
kubectl --namespace=kube-system exec -i -t <your-pod-name>
Для упрощения поиска и устранения неисправностей можно использовать псевдонимы этих команд в командной строке. Например, можно добавить следующие файлы dotfiles (.bashrc или .zshrc):
alias ksysex='kubectl --namespace=kube-system exec -i -t'
Это один из многих примеров из хранилища общих псевдонимов Kubernetes, который показывает один из способов упрощения функций в kubectl. Для чего-то простого, подобного этому сценарию, достаточно псевдонима.
Переключение на подключаемый модуль kubectl
Более сложный сценарий устранения неполадок включает в себя выполнение множества команд, одной за другой, для исследования среды и выведения заключения. Одних псевдонимов недостаточно для этого варианта использования; необходима воспроизведение логического узла и корреляция между многими частями развертывания Kubernetes. На самом деле вам нужна автоматизация для получения нужного результата за меньшее время.
Рассмотрим пространства имен от 10 до 20 или даже от 50 до 100, содержащие различные микросервисы в вашем кластере. Что поможет вам начать устранение неполадок в этом сценарии?
Вам потребуется что-то, что может быстро определить, какой модуль в каком пространстве имен вызывает ошибки.
Вам понадобится что-то, что сможет просматривать журналы всех модулей в пространстве имен.
Также может потребоваться просмотр журналов определенных модулей в определенном пространстве имен, в котором были обнаружены ошибки.
Любое решение, охватывающее эти вопросы, было бы очень полезно при изучении производственных проблем, а также в ходе циклов разработки и тестирования.
Чтобы создать нечто более мощное, чем простой псевдоним, можно использовать плагины kubectl. Плагины подобны автономным сценариям, написанным на любом языке сценариев, но предназначены для расширения функциональных возможностей главной команды при работе в качестве администратора Kubernetes.
Чтобы создать плагин, необходимо использовать правильный синтаксис kubectl- < имя-плагина > для того, чтобы скопировать сценарий в один из экспортированных путей в $PATH и предоставить ему исполняемые разрешения chmod+x.
После создания плагина и перемещения его в свой путь, вы можете немедленно запустить его. Например, у меня на пути есть kubectl-krwl и kubectl-kmux:
$ kubectl plugin list
The following compatible plugins are available:
/usr/local/bin/kubectl-krawl
/usr/local/bin/kubectl-kmux
$ kubectl kmux
Теперь давайте изучим, как выглядит обеспечение работы Kubernetes с tmux.
Использование силы tmux
Tmux - очень мощный инструмент, на который полагаются многие команды для устранения проблем, связанных с упрощением работы - от разделения окон на панели для выполнения параллельной отладки на нескольких машинах до мониторинга журналов. Одним из основных его преимуществ является то, что его можно использовать в командной строке или в сценариях автоматизации.
Я создал плагин kubectl, который использует tmux, чтобы сделать поиск и устранение неисправностей гораздо проще. Я буду использовать аннотации, чтобы пройти через логику за плагином (и оставить его для вас, чтобы пройти через полный код плагина):
#NAMESPACE is namespace to monitor.
#POD is pod name
#Containers is container names
# initialize a counter n to count the number of loop counts, later be used by tmux to split panes.
n=0;
# start a loop on a list of pod and containers
while IFS=' ' read -r POD CONTAINERS
do
# tmux create the new window for each pod
tmux neww $COMMAND -n $POD 2>/dev/null
# start a loop for all containers inside a running pod
for CONTAINER in ${CONTAINERS//,/ }
do
if [ x$POD = x -o x$CONTAINER = x ]; then
# if any of the values is null, exit.
warn "Looks like there is a problem getting pods data."
break
fi
# set the command to execute
COMMAND=”kubectl logs -f $POD -c $CONTAINER -n $NAMESPACE”
# check tmux session
if tmux has-session -t <session name> 2>/dev/null;
then
<set session exists>
else
<create session>
fi
# split planes in the current window for each containers
tmux selectp -t $n ;
splitw $COMMAND ;
select-layout tiled ;
# end loop for containers
done
# rename the window to identify by pod name
tmux renamew $POD 2>/dev/null
# increment the counter
((n+=1))
# end loop for pods
done< <(<fetch list of pod and containers from kubernetes cluster>)
# finally select the window and attach session
tmux selectw -t <session name>:1 ;
attach-session -t <session name>;
После запуска скрипта плагина он будет выдавать выходные данные, аналогичные изображению ниже. Каждый модуль имеет собственное окно, и каждый контейнер (если их несколько) разделяется панелями в окне модуля в потоковые журналы по мере их поступления. Преимущество tmux можно увидеть ниже; При правильной конфигурации можно даже увидеть, какое окно активно (см. белые вкладки).
Заключение
Псевдонимы всегда полезны для простого устранения неполадок в средах Kubernetes. Когда среда становится более сложной, плагин kubectl является мощным вариантом для использования более продвинутых сценариев. Ограничения в выборе языка программирования, который можно использовать для записи плагинов kubectl, нет. Единственное требование состоит в том, чтобы соглашение об именовании в пути являлось исполняемым и не имело того же имени, что и существующая команда kubectl.
Прочитать полный код или попробовать плагины можно тут
Зачастую взлом инфраструктуры происходит не с помощью сверхсекретных разработок или специально созданных "организмов" ("вирусов", "червей", "пауков", "дятлов" - нужное подчеркнуть), а из-за стандартных ошибок в настройках и дизайне. Ликвидировать эти недочёты - проще простого, но с такой же простотой они и создают огромные возможности для хакерских атак. Как отмечают специалисты по безопасности, появления подобных упущений в системе встречается настолько часто, что создаётся впечатление, что для таких ошибок существуют спецкурсы. Поэтому задачей данной статьи не является рассказ о самых современных методах защиты - мы просто постараемся заставить читателей задаться вопросом: "А всё ли хорошо в нашей системе безопасности и всё ли мы предусмотрели для того, чтобы конкуренты не смогли воспользоваться нашими данными и разработками и как устранить неполадки в нашей системе?".
Локальная учётная запись? Забудьте об этом.
Уж сколько раз твердили миру... Слова дедушки Крылова как нельзя лучше характеризуют данную ситуацию - она постоянно возникает и о ней всё время напоминают. Не надо (совсем нельзя) создавать доменной групповой политикой локальные учетные записи на хостах в вашем домене. Говоря военными терминами - уровень опасности красный.
Причина самая банальная - данные по записи (в том числе и пароль) хранится в открытом доступе и по умолчанию доступен всем участникам группы. Если кому интересно, то он находится в файле groups.xml, в ресурсе sysvol контроллера домена, но при этом ключ один на всех. Таким образом, любой желающий может скачать файл и путём нехитрых телодвижений стать администратором группы. Думаю о последствиях говорить не надо.
Чтобы не получилось подобных конфузов надо просто добавлять только доменные учетные записи в локальные группы на хостах.
Права юзеров - на необходимый минимум.
Каждая учётная запись имеет свои права для работы в системе и создана для работы конкретной направленности. Поэтому необходимо минимизировать права каждого пользователя системы, так чтобы они подходили под зону его ответственности. Таким образом, снизится риск утраты контроля над записью, и каждый будет знать только свою, необходимую ему информацию.
UAC - на максимум!
Поставьте на максимум User Account Control (UAC). Его, конечно, можно обойти, но он создаст лишнюю нагрузку для атаки, а время в таких вопросах - играет Вам на руку.
Никакого доступа к учетным данным и хэшам
MIMIKATZ - это утилита, которая очищает память процесса, ответственного за проверку подлинности Windows (LSASS). Затем она и выдает пароли в виде открытого текста и хеш-коды NTLM, которые злоумышленник может использовать для перемещения по сети. Чтобы защититься от неё, надо соблюдать несколько простых правил:
Обновите ваш Active Directory как минимум до 2012 R2;
Следите за обновлениями Windows и постоянно их устанавливайте;
Помещайте важные учетные записи в группу защищенных пользователей и установите параметр реестра;
Не предоставляйте учетной записи больше прав администратора, чем им нужно;
Продолжим тему NTLM, поднятую в предыдущем пункте. Его нужно запретить - от слова совсем. Есть такая замечательная штука, как pass-the-hash. Она, как это можно понять из названия, передаёт хеш NTLM на абсолютно любой хостинг, где разрешён NTLM и атакующий всё про вас узнает. Более того, его также можно передавать вместо учетной записи и ее пароля при атаках.
Навешайте ярлыков на рабочий стол
В прямом смысле - поставьте ярлыки на рабочий стол, которые будут связывать с общими файловыми ресурсами. Тем самым Вы уйдёте от сетевых дисков, а malware почти никогда не воспримет их как сетевые ресурсы. Причина, как всегда, банальная - malware путём перебора букв ищет названия дисков. Конечно, данный совет подходит не всем компаниям, но если возможность подобного похода существует - попробуйте.
Отключите скрытые файловые ресурсы!
И вновь из-за банальной причины. Они - первоочередная цель действия malware и злоумышленников. Конечно, это не все инструменты защиты инфраструктуры, но каждый случай нужно рассматривать отдельно, как и индивидуальные настройки для каждой инфраструктуры.