One place for hosting & domains

      сетевых

      Установка и использование Radamsa для фаззи-тестирования программ и сетевых служб в Ubuntu 18.04


      Автор выбрал Electronic Frontier Foundation Inc для получения пожертвований в рамках программы Write for DOnations.

      Введение

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

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

      Radamsa — инструмент для фаззинга с открытым исходным кодом, позволяющий генерировать тестовые примеры на основе задаваемых пользователем входных данных. Radamsa полностью поддерживает скрипты и успешно выявляет уязвимости в реальных приложениях, таких как Gzip.

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

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

      Предварительные требования

      Для прохождения этого обучающего руководства вам потребуется следующее:

      • Один сервер Ubuntu 18.04, настроенный в соответствии с указаниями руководства Начальная настройка сервера Ubuntu 18.04, включая пользователя sudo без привилегий root и активный брандмауэр для блокирования ненужных портов.
      • Приложение командной строки или сетевое приложение, которое вы хотите протестировать, например Gzip, Tcpdump, Bind, Apache, jq или любое другое приложение по вашему выбору. Для целей этого обучающего руководства в качестве примера мы будем использовать jq.

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

      Подготовив все вышеперечисленное, войдите на сервер без привилегий root, чтобы начать подготовку.

      Шаг 1 — Установка Radamsa

      Прежде всего, мы загрузим и выполним компиляцию Radamsa для использования этого инструмента в нашей системе. Исходный код Radamsa доступен в официальном репозитории на GitLab.

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

      Затем мы установим пакеты gcc, git, make и wget, необходимые для компиляции исходного кода в исполняемый двоичный файл:

      • sudo apt install gcc git make wget

      После подтверждения установки apt выполнит загрузку и установку указанных пакетов и всех необходимых зависимостей.

      Затем мы загрузим копию исходного кода Radamsa, клонировав ее из репозитория на GitLab:

      • git clone https://gitlab.com/akihe/radamsa.git

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

      Далее вы можете запустить процесс компиляции с помощью make:

      Теперь мы можем установить скомпилированный двоичный файл Radamsa в директорию $PATH:

      После этого мы можем проверить установленную версию и убедиться, что все работает правильно:

      Экран результатов должен выглядеть примерно следующим образом:

      Output

      Radamsa 0.6

      Если появится сообщение об ошибке radamsa: command not found, необходимо проверить установку всех требуемых зависимостей и убедиться в отсутствии ошибок при компиляции.

      Мы установили Radamsa и теперь можем рассмотреть примеры тестов, чтобы понять, как работает Radamsa и для чего его можно использовать.

      Шаг 2 — Подготовка примеров для фаззинга

      Мы установили Radamsa и теперь можем использовать его для рассмотрения нескольких примеров фаззинга.

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

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

      Вначале следует передать в Radamsa простой текстовый элемент и посмотреть, что произойдет в результате:

      • echo "Hello, world!" | radamsa

      Вводимые данные будут изменены (фаззинг) и получится пример для тестирования:

      Output

      Hello,, world!

      В данном случае Radamsa добавил запятую между Hello и world. Это изменение может выглядеть незначительным, но в некоторых приложениях это может привести к неправильной интерпретации данных.

      Повторим попытку, запустив ту же самую команду еще раз. Вы увидите другой результат:

      Output

      Hello, '''''''wor'd!

      На этот раз мы вставили в строку несколько одинарных кавычек ('), в том числе один символ, заменивший l в слове world. Этот пример с большей вероятностью вызовет проблемы в приложении, поскольку одинарные и двойные кавычки часто используются как разделители элементов данных в списке.

      Повторим попытку еще один раз:

      Output

      Hello, $+$PATHu0000`xcalc`world!

      В данном случае Radamsa вставляет строку оболочки, которая поможет тестировать приложение на уязвимость к вставке команд.

      Мы использовали Radamsa для фаззинга вводимой строки и подготовили ряд примеров для тестирования. Далее мы используем Radamsa для фаззинга приложения командной строки.

      Шаг 3 — Фаззинг приложения командной строки

      На этом шаге мы используем Radamsa для фаззинга приложения командной строки и получения отчета о сбоях.

      Конкретные методики фаззинга различаются для разных случаев, и для каждой программы подходят свои методы. В этом обучающем руководстве мы используем в качестве примера программу командной строки jq, предназначенную для обработки данных JSON.

      Вы можете использовать любую другую программу подобного рода, если она также принимает структурированные или неструктурированные данные, выполняет с ними какие-то операции и выводит результат. В частности, данный пример также подойдет для Gzip, Grep, bc, tr и т. д.

      Если вы еще не установили jq, вы можете выполнить установку сейчас с помощью apt:

      Сейчас будет выполнена установка jq.

      Чтобы начать фаззинг, создайте образец файла JSON, который будете использовать в качестве исходного для Radamsa:

      Добавьте в файл следующие данные JSON:

      test.json

      {
        "test": "test",
        "array": [
          "item1: foo",
          "item2: bar"
        ]
      }
      

      Вы можете проверить этот файл с помощью jq, если хотите убедиться в правильности синтаксиса JSON:

      Если синтаксис JSON правильный, jq выведет файл. В противном случае будет выведено сообщение об ошибке, которое вы сможете использовать для исправления синтаксиса в случае необходимости.

      Далее мы проведем фаззинг тестового файла JSON в Radamsa и передадим его в jq. В результате jq прочитает измененный тестовый файл, а не первоначальные правильные данные JSON:

      Если Radamsa изменит данные JSON так, что синтаксис останется верным, jq выведет данные со всеми изменениями, которые были внесены Radamsa.

      Если Radamsa изменит формат данных JSON на неверный, программа jq выдаст сообщение об ошибке. Например:

      Output

      parse error: Expected separator between values at line 5, column 16

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

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

      Создайте файл с именем jq-fuzz.sh:

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

      Скопируйте скрипт в файл jq-fuzz.sh:

      jq-fuzz.sh

      #!/bin/bash
      while true; do
        radamsa test.json > input.txt
        jq . input.txt > /dev/null 2>&1
        if [ $? -gt 127 ]; then
          cp input.txt crash-`date +s%.%N`.txt
          echo "Crash found!"
        fi
      done
      

      Этот скрипт содержит оператор while, чтобы сделать его содержимое цикличным. При каждом цикле скрипта Radamsa генерирует тестовый пример на базе файла test.json и сохраняет его в файл input.txt.

      Тестовый пример input.txt пропускается через jq так, что все стандартные сообщения и сообщения об ошибках направляются в /dev/null для предотвращения переполнения экрана терминала.

      В заключение проверяется значение jq на выходе. Если значение на выходе превышает 127, это означает критическое завершение работы (сбой), и в этом случае входные данные сохраняются для последующего использования в файле с именем crash- и суффиксом текущей даты Unix с указанием секунд и наносекунд.

      Отметьте этот скрипт как исполняемый и запустите его для автоматического тестирования jq методом фаззинга:

      • chmod +x jq-fuzz.sh
      • ./jq-fuzz.sh

      Вы можете в любой момент нажать CTRL+C для остановки скрипта. Затем вы сможете проверить наличие сбоев, используя ls для вывода списка директории с созданными файлами регистрации сбоев.

      Вы можете улучшить входные данные JSON, поскольку использование более сложного входного файла, вероятно, повысит качество результатов фаззинга. Избегайте использовать большие файлы или файлы с большим объемом повторяющихся данных. Идеальный исходный файл должен иметь небольшой размер, но при этом содержать как можно больше сложных элементов. Например, хороший входной файл будет содержать образцы данных, сохраненные во всех форматах, включая строки, целые числа, булевы операторы, списки и объекты, а также вложенные данные, если это возможно.

      Мы использовали Radamsa для фаззинга приложения командной строки. Далее мы будем использовать Radamsa для фаззинга запросов сетевых служб.

      Шаг 4 — Фаззинг запросов сетевых служб

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

      Цель фаззинга сетевых служб заключается в проверке устойчивости сетевой службы к отправке клиентами неправильно сформированных и/или вредоносных данных. Многие сетевые службы, в том числе веб-серверы и серверы DNS, обычно доступны из Интернета и часто становятся целью злоумышленников. Сетевая служба, которая недостаточно устойчива к неправильно сформированным данным, может прекратить работу или даже потерять работоспособность в открытом состоянии, в результате чего злоумышленники получат доступ к важным данным, таким как ключи шифрования или пользовательские данные.

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

      Вначале нужно настроить веб-сервер для тестирования. Для этой цели можно использовать встроенный сервер разработки, входящий в состав пакета php-cli. Также для тестирования веб-сервера нам потребуется curl.

      Если у вас не установлены php-cli и/или curl, вы можете установить их с помощью apt:

      • sudo apt install php-cli curl

      Затем создайте директорию для хранения файлов веб-сервера и перейдите в нее:

      Далее создайте файл HTML с образцом текста:

      Добавьте в файл следующее:

      index.html

      <h1>Hello, world!</h1>
      

      Теперь вы можете запустить свой веб-сервер PHP. Вам потребуется возможность просматривать журнал веб-сервера во время использования другого сеанса терминала, и поэтому нужно открыть другой сеанс терминала и канал SSH для подключения к серверу:

      • cd ~/www
      • php -S localhost:8080

      Будет выведен текст следующего вида:

      Output

      PHP 7.2.24-0ubuntu0.18.04.1 Development Server started at Wed Jan 1 16:06:41 2020 Listening on http://localhost:8080 Document root is /home/user/www Press Ctrl-C to quit.

      Теперь вы можете вернуться к исходному сеансу терминала и проверить работу веб-сервера с помощью curl:

      В результате будет выведен образец файла index.html, который вы создали ранее:

      Output

      <h1>Hello, world!</h1>

      Для вашего веб-сервера потребуется только локальный доступ, поэтому не следует открывать для него порты брандмауэра.

      Мы настроили тестовый веб-сервер и теперь можем начать фаззинг с помощью Radamsa.

      Для начала нам потребуется создать образец запроса HTTP, который будет использоваться в качестве исходных данных Radamsa. Создайте новый файл для его сохранения:

      Затем скопируйте в файл следующий образец запроса HTTP:

      http-request.txt

      GET / HTTP/1.1
      Host: localhost:8080
      User-Agent: test
      Accept: */*
      

      Теперь мы можем использовать Radamsa для отправки этого запроса HTTP на локальный веб-сервер. Для этого нужно использовать Radamsa в качестве клиента TCP, что можно сделать посредством указания IP-адреса и порта для подключения:

      • radamsa -o 127.0.0.1:8080 http-request.txt

      Примечание. Использование Radamsa в качестве клиента TCP может привести к передаче через сеть неправильно сформированных или вредоносных данных. Это может повлечь за собой неисправности, и поэтому вы должны использовать только сети, которые вам разрешено тестировать, а лучше всего использовать только адрес localhost (127.0.0.1).

      Если вы просмотрите журналы локального веб-сервера, вы увидите, что он получал запросы, однако вряд ли обрабатывал их, поскольку они были недопустимыми или неправильно сформированными.

      Журналы будут отображаться во втором окне терминала:

      Output

      [Wed Jan 1 16:26:49 2020] 127.0.0.1:49334 Invalid request (Unexpected EOF) [Wed Jan 1 16:28:04 2020] 127.0.0.1:49336 Invalid request (Malformed HTTP request) [Wed Jan 1 16:28:05 2020] 127.0.0.1:49338 Invalid request (Malformed HTTP request) [Wed Jan 1 16:28:07 2020] 127.0.0.1:49340 Invalid request (Unexpected EOF) [Wed Jan 1 16:28:08 2020] 127.0.0.1:49342 Invalid request (Malformed HTTP request)

      Для получения оптимальных результатов и гарантированной регистрации сбоев можно использовать скрипт автоматизации, аналогичный использованному на шаге 3. Также следует попробовать использовать более сложный исходный файл, который может содержать такие дополнения, как дополнительные заголовки HTTP.

      Мы провели тестирование сетевой службы методом фаззинга, использовав Radamsa в качестве клиента TCP. Теперь мы проведем фаззинг сетевого клиента, используя Radamsa в качестве сервера.

      Шаг 5 — Фаззинг сетевых клиентских приложений

      На этом шаге мы используем Radamsa для тестирования сетевого клиентского приложения методом фаззинга. Это реализуется посредством перехвата ответов сетевой службы и их искажения до поступления на клиент.

      Цель такого фаззинга заключается в проверке устойчивости клиентских приложений сети к получению неправильно сформированных или вредоносных данных от сетевых служб. В качестве примера можно привести тестирование браузера (клиента), получающего неправильно сформированный код HTML от веб-сервера (сетевой службы) или тестирование клиента DNS, получающего неправильно сформированные ответы DNS от сервера DNS.

      Как и в случае с фаззингом приложений командной строки или сетевых служб, конкретная методика фаззинга разных сетевых клиентских приложений может значительно различаться, однако в этом примере мы используем whois, простое приложение для приема/передачи на базе TCP.

      Приложение whois используется для отправки запросов на серверы WHOIS и получения записей WHOIS в составе ответов. WHOIS работает через порт TCP 43 в формате простого текста, что делает его отличным вариантом для фаззинга сетевого клиента.

      Если у вас еще нет приложения whois, вы можете установить его с помощью apt:

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

      • whois example.com > whois.txt

      Далее вам потребуется настроить Radamsa в качестве сервера, который будет отправлять искаженные версии этого ответа whois. Когда Radamsa будет работать в серверном режиме, вам нужна будет возможность и дальше использовать терминал, и для этого нужно будет открыть другой сеанс терминала и канал SSH для связи с сервером:

      • radamsa -o :4343 whois.txt -n inf

      Теперь Radamsa будет работать в режиме сервера TCP и будет отправлять искаженную версию файла whois.txt при каждой попытке подключения к серверу, вне зависимости от того, какие данные запроса будут получены.

      Теперь вы можете перейти к тестированию клиентского приложения whois. Вам потребуется нормальный запрос whois для любого домена по вашему выбору (не обязательно для того, для которого предназначен образец), но при этом whois должен указывать на ваш локальный сервер Radamsa:

      • whois -h localhost:4343 example.com

      Ответ будет содержать образец данных, искаженный Radamsa. Пока Radamsa будет работать, вы сможете и дальше отправлять запросы на локальный сервер, и каждый раз он будет выдавать разные искаженные ответы.

      Как и в случае с фаззингом сетевых служб, вы можете написать скрипт автоматизации, аналогичный использованному на шаге 3, чтобы повысить эффективность фаззинга сетевых клиентов и гарантировать регистрацию сбоев.

      На этом заключительном шаге мы использовали Radamsa для тестирования сетевого клиентского приложения методом фаззинга.

      Заключение

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

      Если вы хотите узнать больше о Radamsa, вы можете более подробно ознакомиться с файлом Radamsa README, где содержится дополнительная техническая информация и дополнительные примеры использования:

      Также вы можете рассмотреть и другие инструменты для фаззинга, например продвинутую программу фаззинга American Fuzzy Lop (AFL), предназначенную для тестирования двоичных приложений с очень высокой скоростью и точностью:



      Source link

      Инспектирование сетевых компонентов Kubernetes


      Введение

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

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

      Если вы хотите узнать больше о Kubernetes, вам поможет наше руководство «Введение в Kubernetes». Для обзора сетевых возможностей Kubernetes прочитайте статью «Сети в Kubernetes: под капотом».

      Начало работы

      В этом обучающем модуле предполагается, что у вас имеется кластер Kubernetes с установленным локальным компонентом kubectl, настроенным для подключения к кластеру.

      В следующих разделах содержатся различные команды, которые предполагается выполнять на узлах Kubernetes. Они выглядят примерно так:

      • echo 'this is a node command'

      Команды для выполнения на локальном компьютере будут выглядеть так:

      • echo 'this is a local command'

      Примечание. Большнство команд в этом обучающем модуле должно выполняться от имени пользователя root Если вы используете пользователя с привилегиями sudo на узлах Kubernetes, добавьте sudo для запуска команд, когда это требуется.

      Поиск IP-адреса кластера пода

      Чтобы найти IP-адрес кластера пода Kubernetes, запустите на локальном компьютере команду kubectl get pod с опцией -o wide. Эта опция выводит больше информации, включая узел размещения пода и IP-адрес кластера пода.

      Output

      NAME READY STATUS RESTARTS AGE IP NODE hello-world-5b446dd74b-7c7pk 1/1 Running 0 22m 10.244.18.4 node-one hello-world-5b446dd74b-pxtzt 1/1 Running 0 22m 10.244.3.4 node-two

      В столбце IP будет указан внутренний IP-адрес кластера для каждого пода.

      Если вы не видите под, который вам нужен, проверьте правильность выбора пространства имен. Вы можете вывести список всех подов во всех пространствах имен с помощью флага --all-namespaces.

      Поиск IP-адреса службы

      С помощью команды kubectl также можно определить IP-адрес службы. В данном случае мы выводим список всех служб во всех пространствах имен:

      • kubectl get service --all-namespaces

      Output

      NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE default kubernetes ClusterIP 10.32.0.1 <none> 443/TCP 6d kube-system csi-attacher-doplugin ClusterIP 10.32.159.128 <none> 12345/TCP 6d kube-system csi-provisioner-doplugin ClusterIP 10.32.61.61 <none> 12345/TCP 6d kube-system kube-dns ClusterIP 10.32.0.10 <none> 53/UDP,53/TCP 6d kube-system kubernetes-dashboard ClusterIP 10.32.226.209 <none> 443/TCP 6d

      IP-адрес службы указывается в столбце CLUSTER-IP.

      Поиск и ввод сетевых пространств имен подов

      Каждому поду Kubernetes присваивается собственное сетевое пространство имен. Сетевые пространства имен (netns) — это примитив сетей Linux, обеспечивающий изоляцию сетевых устройств.

      Запускать команды через netns пода может быть полезно для проверки разрешения DNS или общей работоспособности сети. Для этого нужно предварительно посмотреть идентификатор процесса одного из контейнеров в поде. Для Docker мы можем сделать это с помощью серии из двух команд. Вначала выведите список контейнеров, запущенных на узле:

      Output

      CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 173ee46a3926 gcr.io/google-samples/node-hello "/bin/sh -c 'node se…" 9 days ago Up 9 days k8s_hello-world_hello-world-5b446dd74b-pxtzt_default_386a9073-7e35-11e8-8a3d-bae97d2c1afd_0 11ad51cb72df k8s.gcr.io/pause-amd64:3.1 "/pause" 9 days ago Up 9 days k8s_POD_hello-world-5b446dd74b-pxtzt_default_386a9073-7e35-11e8-8a3d-bae97d2c1afd_0 . . .

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

      • Первый контейнер — это приложение hello-world, запущенное в поде hello-world
      • Второй — это контейнер pause, запущенный в поде hello-world. Этот контейнер используется исключительно для захвата сетевого пространства имен пода

      Чтобы получить идентификатор процесса любого из контейнеров, запишите идентификатор контейнера или имя и используйте его в следующей команде docker:

      • docker inspect --format '{{ .State.Pid }}' container-id-or-name

      Output

      14552

      Будет выведен идентификатор процесса (или PID). Теперь мы можем использовать программу nsenter для запуска команды в сетевом пространстве имен этого процесса:

      • nsenter -t your-container-pid -n ip addr

      Обязательно используйте собственный PID и замените ip addr командой, которую вы хотите запустить в сетевом пространстве имен пода.

      Примечание. Использование nsenter для запуска команд в пространстве имен пода дает преимущества по сравнению с такими программами как docker exec. Это преимущество заключается в том, что у вас имеется доступ ко всем командам, поддерживаемым узлом, а не только к ограниченному набору команд, установленному в контейнерах.

      Поиск интерфейса виртуальной сети Ethernet пода

      Каждое пространство имен пода взаимодействует с пространством root netns через виртуальный конвейер ethernet. Со стороны узла этот конвейер выглядит как устройство, которое обычно начинается с veth и заканчивается уникальным идентификатором, например veth77f2275 или veth01. Внутри пода этот конвейер выглядит как eth0.

      Его можно использовать для корреляции устройств veth, сопряженных с конкретными подами. Для этого мы выводим список всех сетевых устройств в узле, а затем выводим список устройств в сетевом пространстве имен пода. Для получения связи мы можем провести корреляцию номеров устройств в двух списках.

      Запустите команду ip addr в сетевом пространстве имен пода, используя nsenter. Более подробную информацию об этом можно найти в предыдущем разделе «Поиск и ввод пространств имен подов»:

      • nsenter -t your-container-pid -n ip addr

      Output

      1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 10: eth0@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default link/ether 02:42:0a:f4:03:04 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 10.244.3.4/24 brd 10.244.3.255 scope global eth0 valid_lft forever preferred_lft forever

      Данная команда выводит список интерфейсов пода. Запишите номер if11 после eth0@ на экране результатов примера. Это означает, что конвейер eth0 этого пода связан с 11-м интерфейсом узла. Теперь запустите команду ip addr в пространстве имен по умолчанию узла для перечисления его интерфейсов:

      Output

      1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever . . . 7: veth77f2275@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master docker0 state UP group default link/ether 26:05:99:58:0d:b9 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet6 fe80::2405:99ff:fe58:db9/64 scope link valid_lft forever preferred_lft forever 9: vethd36cef3@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master docker0 state UP group default link/ether ae:05:21:a2:9a:2b brd ff:ff:ff:ff:ff:ff link-netnsid 1 inet6 fe80::ac05:21ff:fea2:9a2b/64 scope link valid_lft forever preferred_lft forever 11: veth4f7342d@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master docker0 state UP group default link/ether e6:4d:7b:6f:56:4c brd ff:ff:ff:ff:ff:ff link-netnsid 2 inet6 fe80::e44d:7bff:fe6f:564c/64 scope link valid_lft forever preferred_lft forever

      В этом примере 11-й интерфейс — это интерфейс veth4f7342d. Это конвейер виртуальной сети ethernet к исследуемому нами поду.

      Проверка отслеживания соединения Conntrack

      До выпуска версии 1.11 в Kubernetes для отслеживания соединений использовались таблицы NAT iptables и модуль ядра conntrack. Для вывода списка всех отслеживаемых соединений используйте команду conntrack:

      Чтобы постоянно отслеживать новые соединения, используйте флаг -E:

      Чтобы вывести отслеживаемые conntrack соединения на определенный адрес назначения, используйте флаг -d:

      • conntrack -L -d 10.32.0.1

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

      /var/log/syslog

      Jul 12 15:32:11 worker-528 kernel: nf_conntrack: table full, dropping packet.
      

      Это настройка sysctl для отслеживания максимального количества соединений. Вы можете вывести список текущих значений с помощью следующей команды:

      • sysctl net.netfilter.nf_conntrack_max

      Output

      net.netfilter.nf_conntrack_max = 131072

      Используйте флаг -w для установки нового значения:

      • sysctl -w net.netfilter.nf_conntrack_max=198000

      Чтобы сделать этот параметр постоянным. добавьте его в файл sysctl.conf:

      /etc/sysctl.conf

      . . .
      net.ipv4.netfilter.ip_conntrack_max = 198000
      

      Проверка правил таблиц Iptables

      До выпуска версии 1.11 в Kubernetes использовались таблицы NAT iptables для преобразования виртуальных IP-адресов и балансировки нагрузки служебных IP-адресов.

      Чтобы сохранить все правила таблиц iptables на узле, используйте команду iptables-save:

      Поскольку результаты могут быть длинными, вы можете отправить результаты через конвейер в файл (iptables-save > output.txt) или на пейджер (iptables-save | less) для большего удобства просмотра.

      Чтобы вывести только правила NATдля службы Kubernetes, используйте команду iptables и флаг -L для указания правильной цепочки:

      • iptables -t nat -L KUBE-SERVICES

      Output

      Chain KUBE-SERVICES (2 references) target prot opt source destination KUBE-SVC-TCOU7JCQXEZGVUNU udp -- anywhere 10.32.0.10 /* kube-system/kube-dns:dns cluster IP */ udp dpt:domain KUBE-SVC-ERIFXISQEP7F7OF4 tcp -- anywhere 10.32.0.10 /* kube-system/kube-dns:dns-tcp cluster IP */ tcp dpt:domain KUBE-SVC-XGLOHA7QRQ3V22RZ tcp -- anywhere 10.32.226.209 /* kube-system/kubernetes-dashboard: cluster IP */ tcp dpt:https . . .

      Запросы DNS кластера

      Один из способов отладки разрешения DNS кластера заключается в развертывании контейнера отладки с помощью всех необходимых инструментов и использование kubectl для выполнения команды nslookup. Это описывается в официальной документации по Kubernetes.

      Еще один способ запроса DNS кластера заключается в том, чтобы использовать dig и nsenter с узла. Если dig не установлен, его можно установить с помощью apt в дистрибутивах Linux на базе Debian:

      Вначале найдите IP-адрес кластера службы kube-dns:

      • kubectl get service -n kube-system kube-dns

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kube-dns ClusterIP 10.32.0.10 <none> 53/UDP,53/TCP 15d

      IP-адрес кластера подсвечен выше. Теперь мы используем nsenter для запуска dig в пространстве имен контейнера. Дополнительную информацию об этом можно найти в разделе «Поиск и ввод сетевых пространств имен подов»:

      • nsenter -t 14346 -n dig kubernetes.default.svc.cluster.local @10.32.0.10

      Команда dig ищет полное доменное имя службы service-name.namespace.svc.cluster.local и указывает IP-адрес службы DNS кластера (@10.32.0.10).

      Просмотр деталей IPVS

      В версии Kubernetes 1.11 команда kube-proxy может настроить IPVS для обработки преобразования виртуальных IP-адресов служб в IP-адреса подов. Вы можете вывести таблицу преобразования IP-адресов с помощью команды ipvsadm:

      Output

      IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 100.64.0.1:443 rr -> 178.128.226.86:443 Masq 1 0 0 TCP 100.64.0.10:53 rr -> 100.96.1.3:53 Masq 1 0 0 -> 100.96.1.4:53 Masq 1 0 0 UDP 100.64.0.10:53 rr -> 100.96.1.3:53 Masq 1 0 0 -> 100.96.1.4:53 Masq 1 0 0

      Чтобы вывести IP-адрес одной службы, используйте опцию -t и укажите желаемый IP-адрес:

      • ipvsadm -Ln -t 100.64.0.10:53

      Output

      Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 100.64.0.10:53 rr -> 100.96.1.3:53 Masq 1 0 0 -> 100.96.1.4:53 Masq 1 0 0

      Заключение

      В этой статье мы рассмотрели некоторые команды и методики изучения и проверки сетевых подключений вашего кластера Kubernetes. Более подробную информацию по Kubernetes можно найти в наших обучающих модулях по Kubernetes и официальной документации по Kubernetes.



      Source link