Мониторинг сети в Linux (ping, traceroute, mtr)
Существует несколько хороших утилит, позволяющих искать неисправности в сети на уровне TCP/IP. Большинство из них выдает низкоуровневую информацию, поэтому для того чтобы пользоваться ими, нужно хорошо понимать принципы работы протоколов TCP/IP и маршрутизации. В этой статье мы рассмотрим основные инструменты поиска неисправностей в сети: утилитами ping, traceroute и mtr.
Утилита ping
Проверка доступности компьютера
Утилита ping предназначена для того, чтобы при помощи отправки ICMP пакетов убедиться в работоспособности хоста. Команда ping посылает запрос (ICMP ECHO_REQUEST) конкретному компьютеру и фиксирует поступающие ответы (ICMP ECHO_RESPONSE). Её можно применять для работоспособности отдельных компьютеров и сегментов сети. В обработке ее запроса участвуют таблицы маршрутизации, физические компоненты сетей и сетевые шлюзы, поэтому для достижения успешного результата сеть должна быть в более или менее рабочем состоянии. Если команда не работает, можно быть совершенно уверенным в том, что более сложные средства тем более не функционируют. Однако это правило неприменимо в сетях, где брандмауэры блокируют эхо-запросы ICMP. Убедитесь в том, что брандмауэр не препятствует работе команды ping, прежде чем подозревать, что зондируемый компьютер игнорирует эту команду. В конце концов, отключите на короткое время брандмауэр для проверки работоспособности сети.
Если не задан аргумент «число пакетов», команда ping работает в бесконечном цикле. Чтобы прервать работу команды, нужно нажать специальную клавиатурную комбинацию .
Например, пропингуем neoserver.ru (это имя хоста):
Информация о компьютере neoserver.ru включает его IP-адрес, порядковый номер ответного ICMP-пакета и полное время прохождения пакета. Полученные результаты свидетельствуют о том, что компьютер neoserer.ru работает и подключен к сети.
Min — минимальное время ответа хоста, кторому был отправлен запрос.
Avg — среднее время ответа хоста, кторому был отправлен запрос
Max — максимальное время ответа хоста, кторому был отправлен запрос.
Ещё вы увидите TTL — определяет максимальное количество хопов (то есть прыжок, участок между маршрутизаторами), которые пакет может пройти. Наличие этого параметра не позволяет пакету бесконечно ходить по сети.
В ОС Linux, как уже было сказано выше, команда ping без дополнительных параметров будет пинговать заданный хост бесконечно. Чтобы отправить, например, 10 запросов, необходимо добавить ключ -с:
В итоге, мы видим, что было отпралено 10 запросов и выведен результат.
Другие примеры задействования разын ключей:
Не резолвить имена адресов, выводить только ip-адреса
Завершение работы ping по заданному времени (тут 5 секунд)
Установить размер отправляемых пакетов в 1000 байт
Увеличить интервал времени пинга на 3 секунды
Утилита traceroute
Каждый пакет проходит на своем пути определенное количество узлов, пока достигнет своей цели. И, как мы уже знаем, каждый пакет имеет свое время жизни. Это количество узлов, которые может пройти пакет перед тем, как он будет уничтожен. Этот параметр записывается в заголовке TTL, каждый маршрутизатор, через который будет проходить пакет уменьшает его на единицу. При TTL=0 пакет уничтожается, а отправителю отсылается сообщение Time Exceeded.
Команда traceroute linux использует UDP пакеты. Она отправляет пакет с TTL=1 и смотрит адрес ответившего узла, дальше TTL=2, TTL=3 и так пока не достигнет цели. Каждый раз отправляется по три пакета и для каждого из них измеряется время прохождения. Пакет отправляется на случайный порт, который, скорее всего, не занят. Когда утилита traceroute получает сообщение от целевого узла о том, что порт недоступен трассировка считается завершенной.
Синтаксис утилиты не сложный:
Адресом узла может служить как IP адрес, так и доменное имя. Основные опции:
Для примера, выпоним трасировку к ресурсу yandex.ru:
В итоге, пакет прошел через 6 узлов перед тем, как дойти до указанного хоста. На каждый узел отправлялось по три пакета и для каждого из них было засечено время прохождения. И если на одном из узлов возникнет проблема, теперь вы будете знать на каком.
Иногда, вместо одного узла вы можете видеть звездочки. Это значит, что шлюзы либо не высылают нам ICMP с сообщением «time exceeded», либо у их сообщений слишком маленький TTL и оно нас не достигает. В точности нельзя сказать, что происходит на самом деле, но ясно, что по какой-то причине хост не захотел нам отвечать:
Бывает, что трассировка с помощью UDP не работает, это может произойти потому, что фаервол блокирует все лишние пакеты. Можно воспользоваться ICMP с помощью опции -I:
Рассмотреных выше простых примеров, вполне достаточно для первичной диагностики сети как для обычныз пользователей, так и для начинающих администраторов.
Утилита MTR
MTR – это альтернатива программе traceroute. Объединяя функции ping и traceroute, mtr позволяет постоянно опрашивать удаленный сервер и отслеживать изменения задержки и производительности с течением времени.
Синтаксис утилиты также несложный:
Вывод похож на traceroute, но mtr имеет существенное преимущество – ее вывод постоянно обновляется. Это позволяет собирать средние показатели, а также отслеживать тенденции и изменения производительности сети. Как и с утилитой ping, mtr будет работать бесконечно. Чтобы прервать работу команды, нужно нажать специальную клавиатурную комбинацию .
Источник
Маршрутизация в Linux: VRF Lite
Типы маршрутов, таблицы маршрутизации и PBR в Linux
Прежде чем понять суть происходящего, познакомимся с некоторыми отличительными чертами сетевого стека Linux.
Первый отличительный момент — это специальные типы маршрутов. Когда ip-пакет приходит с какого-нибудь интерфейса, надо определить, адресован ли он этому хосту, или другому. Определяется это довольно элегантно — просто для адреса назначения ищется нужный маршрут в таблицах маршрутизации. Если пакет попадает на маршрут типа «local», значит он адресован непосредственно хосту, если нет, то значит его надо маршрутизировать дальше (при этом дальнейший маршрут уже известен) или сделать что-то ещё, в зависимости от типа маршрутов.
На данный момент поддерживается несколько типов маршрутов (подробнее о них можно посмотреть в мане ip-route, если пишет, что такого мана нет, то обновите пакет iproute на более свежий). Нас в данный момент интересуют только маршруты следующих типов:
- unicast — обычный маршрут. Ничего интересного.
- local — адрес назначения находится на данном хосте. После того, как выяснится, что пакет попадает на этот маршрут, будет производиться поиск подходящего сокета для него.
- broadcast — широковещательный маршрут. Для входящих пакетов, попадающих на этот маршрут, практически нет отличий от маршрута local, за исключением дополнительных проверок на игнорирование широковещательных пакетов. Для исходящих же есть небольшое отличие: в заголовке канального уровня так же выставляется широковещательный адрес назначения при использовании широковещательных сетей.
- unreachable — запрещающий маршрут. Для пакетов, попадающий на этот маршрут будет отослан отправителю icmp-пакет с сообщением о недоступности.
- prohibit — подобен типу unreachable, только сообщение другое будет отправлено.
- blackhole — пакет на этом маршруте будет молча отброшен
Таким образом, для маршрутизации транзитных пакетов нам достаточно наличия маршрута типа unicast, а для того, чтобы хост мог отвечать на пакеты, нужны ещё маршруты типов local и, опционально, broadcast. Ещё следует учесть то, что нам также нужны маршруты direct-connected сетей для того, чтобы обеспечить связность с соседними маршрутизаторами.
Маршруты сгруппированы в таблицы маршрутизации. По-умолчанию изначально в системе присутствуют три таблицы:
- local (255) — в этой таблице находятся локальные и широковещательные маршруты. Эта таблица обслуживается автоматически и генерируется на основе адресов, назначенных интерфейсам.
- main (254) — основная таблица маршрутизации. Автоматически в неё добавляются direct-connected маршруты. Так же если в параметрах утилиты ip не указана таблица маршрутизации, то подразумевается таблица main.
- default (253) — таблица для маршрутов по-умолчанию. Её использование не прижилось и поэтому она, как правило, пустует всё время.
Имена таблиц хранятся в файле /etc/iproute2/rt_tables. Под номер таблицы отдано 32 бита, но максимальное количество таблиц в данный момент жёстко ограничено числом 256. Как добавлять/удалять/редактировать маршруты можно почитать в мане к ip-route.
Таблица, в которой надо искать маршруты, определяется политиками маршрутизации. Эта технология называется Policy Based Routing — маршрутизация на основе политик. Суть её в том, что основываясь на каких-либо критериях сетевого пакета мы либо выбираем таблицу, в которой надо искать маршрут, либо определяем действие, которое надо выполнить над пакетом. Каждая политика имеет номер (он может быть даже не уникальным), он же определяем приоритет. Просмотр политик осуществляется в порядке возрастания их приоритетов. Новые политики добавляются перед существующими.
На данный момент «критериями» политики являются
- адреса источника и/или назначения
- значение поля tos
- интерфейс, с которого получен пакет
- интерфейс, к которому привязан сокет
- метка файерволла
Каждая политика имеет тип, который определяет действие над пакетом, если он под неё попадает:
- unicast — используется по-умолчанию, при этом будет производиться поиск маршрута в заданной таблице маршрутизации.
- blackhole/prohibit/unreachable — по действиям аналогичны соответствующим типам маршрутов.
- nat — трансляция адресов без учёта состояний, практически не используется.
Запираем маршруты в таблицу
Теперь небольшой практический пример после скучного введения. Для начала, мы реализуем схему с vrf-lite вручную, а затем уже усложним пример динамической маршрутизацией.
Допустим, у нас есть вот такая схема: 
Задача состоит в том, чтобы изолировать трафик различного «цвета» друг от друга. При этом адресные пространства цветов могут пересекаться, что делает задачу ещё более интересной. Неформально сформулируем цель: сделать так, чтобы пакеты каждого цвета не уходили за пределы своей таблицы маршрутизации и передавались только по интерфейсам своего цвета.
Для этого для каждого цвета создадим свою таблицу маршрутизации, и для удобства дадим им имя. Затем, добавим в таблицы direct-connected маршруты принадлежащих цвету интерфейсов. И в конце, добавим политики маршрутизации, чтобы пакеты использовали только свою таблицу.
Сначала назначаем интерфейсам адреса. При этом подключенные маршруты будут попадать в таблицу main, а локальные и широковещательные — в таблицу local.
Добавляем для удобства имена таблиц маршрутизации.
Добавляем прямые маршруты в соответствующие таблицы. Нужны это для того, чтобы нам были доступны соседние маршрутизаторы.
Добавляем остальные маршруты.
Есть один нюанс: что будет, если пакет одного цвета не находит маршрута в своей таблице? Значит, будет продолжен поиск маршрута в других таблицах, что для нас не очень хорошо. Чтобы «запереть» пакет в пределах своего цвета, мы можем в каждую изолированную таблицу добавить маршрут по-умолчанию (либо юникастовый, либо запрещающий), либо после каждой политики поиска маршрута в пределах цвета добавить запрещающую политику. Сделаем для одного цвета первый вариант, а для другого — второй.
Так же, желательно перенести все маршруты local и broadcast из таблицы local в таблицы соответствующих цветов, чтобы невозможно было обращаться к локальным интерфейсам маршрутизатора из «чужого» цвета. Для этого лучше всего написать какой-нибудь скрипт, чтобы было не так утомительно.
В итоге, наши таблицы маршрутизации и политики будут выглядеть примерно так:
Собранный в GNS3 стенд показал правильность работы схемы. При обращении к чужому цвету, отправитель получает сообщение о недоступности точки назначения, как и было задумано.
На этом пока всё, но продолжение следует. В нём постараюсь рассказать про динамическую маршрутизацию применительно к vrf с помощью демона маршрутизации bird, и обмен маршрутами между таблицами (vrf leaking).
Источник
Таблица маршрутизации в Linux
Статическая маршрутизация — это процесс, в котором администратор сети вручную настраивает сетевые интерфейсы, таким образом, чтобы пакеты пересылались из одной сети в другую.
Администратор создает так называемую таблицу маршрутизации, в ней описаны различные маршруты пакетов.
Любому из маршрутизаторов необходимо понимать на какой хост отправлять следующий пакет. Вот про это и будет идти речь в данной статье. Сегодня мы раскроем вопрос про маршрутизацию в Линукс, функциональность, настройку правил и правильное функционирование.
Когда хосту необходимо послать пакет другому хосту он просматривает таблицу маршрутизации. В данной таблице указаны IP-address конечного пункта назначения, метрика, название интерфейсов, адреса маршрутизаторов по которые могут отправить пакет конечному получателю.
В случае отсутствия маршрута для узла, применяется так называемый default шлюз, default маршрут. Подобное можно наблюдать на маршрутизаторе. Он сравнивает необходимый IP-address с таблицей маршрутизации, затем посылает дальше.
Ниже будем рассматривать проверку проходящих маршрутов в системе, процесс настройки новых.
Способы просмотра таблицы маршрутизации в Линукс
Для просмотра таблицы в ОС Линукс можно использовать команду:
Как видно из скриншота выше, команда показала всего две записи. В первой записи указан шлюз (gateway) 192.168.168.254, вторая запись говорит о наличии доступа в подсеть 192.168.168.0 на интерфейсе eth0.
Другой способ вывести информацию о статических маршрутов — использовать команду «route», однако, как правило утилита просит права супер пользователя, поэтому предварительно введем «su-«.
Бывает, выводимых данных route и netstat недостаточно, так как в них выводится легкая информация, ее не хватает для понимания всей картины. Чтобы получить более подробную таблицу, можно воспользоваться утилитой «routel».
В этой информации содержится:
- target (цель) — IP-адрес.
- gateway — адрес шлюза.
- source — адрес отправителя.
- dev — интерфейс.
Наиболее подходящий метод для просмотра таблицы маршрутизации в ОС Линукс – использовать утилиту «ip».
$ ip route
Подробней про «ip» можно посмотреть в другой статье: https://www.vseprolinux.ru/komanda-ip
- default – IP-адрес по умолчанию.
- via 192.168.168.254 — адрес шлюза, куда будут отправлять пакеты по умолчанию.
- dev eth0 — интерфейс сети, за счёт него открывается доступ к шлюзу.
- proto kernel — обозначает, что маршрут устанавливался ядром, если static, то установка выполняется администратором.
Настройка
Для настройки таблицы маршрутизации будем использовать команду ip route. Добавим временный статический маршрут 192.168.22.0/24 через шлюз 192.168.168.254.
ip route add 192.168.22.0/24 via 192.168.168.254
ВАЖНО! При выполнении такой команды добавиться временный статический маршрут, после перезагрузки системы он сотрется.
Для проверки необходимо проверить, проходит ли пакет из сети 192.168.22.0. Для этого будем использовать ip route get.
ip route get 192.168.22.30
Как говорилось выше, после перезагрузки Linux все эти добавленные адреса сотрутся. Для того, чтобы данные не стирались, необходимо записать их в файле.
post-up route add -net 192.168.22.0 netmask 255.255.255.0 gw 192.168.168.254
pre-down route del -net 192.168.22.0 netmask 255.255.255.0 gw 192.168.168.254
- post-up — запустить команду после включения интерфейса.
- pre-down — запустить команду перед отключением интерфейса.
- net — задает целевую сеть
- netmask — сетевая маска.
- gw — шлюз.
Не так сложно, как могло показаться. После всей выполненной работы присоединенные маршруты будут работать даже после перезагрузки операционной системы Линукс.
Рассмотрим еще несколько примеров.
Изменяем статический маршрут:
ip route change 192.168.22.0/24 via 192.168.168.254
ip route del 192.168.22.0/24
ЗАКЛЮЧЕНИЕ
Подобная работа написана для краткого рассмотрения функционирования маршрутизации в Линукс, как происходит настройка маршрутизации, а также для чего она необходима.
Источник
