Автор: Александр Коленко
Привет, дорогой читатель!
Зарегистрируйтесь и получите доступ к бесплатному контенту. А также будьте в курсе нового учебного контента. Ссылка на учебную платформу:
Если материал полезен, то есть способ отблагодарить меня. Любая сумма будет отличной наградой и стимулом писать полезный контент для Вас.
В статье TCP/IP (Часть 3) TCP Options я затрагивал протокол ICMP, используемый встроенным механизмом Path MTU Discovery (PMD) для поиска максимального MTU от клиента до сервера. Так же я упоминал, что для работы данного механизма требуется поддержка ICMP на всех транзитных устройствах, чего в реальной жизни встретишь редко, ибо ИБ специалисты стараются максимально закрывать доступ к защищаемым ресурсам. На практическом примере я показывал как локализовать заниженный MTU и как его правильно рассчитать. Это был один из сценариев диагностики с использованием утилиты ping. Ping - самая часто используемая утилита диагностики. Суть ее заключается в отправке icmp-запроса (echo request) и получении icmp-ответа (echo replay). Но что если мы не получили echo replay? В чем может быть проблема? Возможно ICMP попросту закрыт или нет связности, тогда мы прибегаем к утилите treceroute, telnet для проверки работы необходимых нам сокетов и наличия связности. Открыть сокет с удаленным сервером не получается? Почему? Ну вариантов несколько: нет разрешения на межсетевом экране или попросту служба не запущена. А как понять, какой именно вариант проблемы у нас?
RTFM — изначально сокр. от англ. read the following manual, «обратитесь к прилагаемому руководству» — типичный ответ службы поддержки на вопрос пользователя, обычно сопровождающийся номером или названием этого руководства. Впоследствии фраза стала популярна в компьютерных сетях, уже используясь в значении read the fucking manual («читай, блядь, инструкцию» или «читай (эту) ёбаную инструкцию» в зависимости от контекста)
Очень часто начинающие инженеры начинают строить гипотезы. В лучшем случае если эти гипотезы базируются на 4-х уровневой модели TCP/IP (модель OSI оставьте для собесов) и поиск проблемы начинается с физического уровня, в худшем базируется на подходе - "проблема не на моей стороне". Порочный подход "проблема не на моей стороне" следствие лени или отсутствия понимания как производить диагностику. Первый случай - к психологу, а второй лечится небольшим объемом знаний и практическим навыком.
Ну что по второму варианту?
Итак с ping-ом все должно быть +- понятно. Эта утилита сообщает нам факты: связь есть или связи нет. И вот мы столкнулись с тем, что ping до конечного хоста не проходит, что делать дальше? Давайте я опишу верный подход к диагностики и самый популярный инструментарий.
1 Шаг
Необходимо проверить корректно ли настроены сетевые интерфейсы на диагностируемой машине, имеется ли информация о дефолтном маршруте, DNS?. Для Windows систем вам поможет ipconfig /all. Пример:
В данном выводе вы найдете всю необходимую для сверки информацию: тип используемого адаптера, mac адрес, включен ли DHCP клиент, использовалась ли авто настройка, IP адрес, маска подсети, данные о начале аренды IP адреса и сроке ее истечения, основной шлюз, IP адрес DHCP сервера, DNS-сервер для резолва FQDN->IP и дополнительная информация. Информации больше чем достаточно для того чтобы сверить и исключить человеческий фактор.
Аналогичную информацию, но для Linux систем можно получить введя команды: ip a (информация о сетевых интерфейсах), ip r (таблица маршрутизации), ip n (arp таблица), cat /etc/resolv.conf (информация об используемых DNS).
Справка:
В Linux имеется набор команд (ifconfig, route, iwconfig и тд.), которые обеспечивают настройки сети (доступно из пакета net-tools).
Эти команды вы можете увидеть в старых обучающих видео, либо в использовании по привычке. Однако из-за прогресса в ядре Linux, за последние годы они становятся устаревшими и уступают свое место более мощным и функциональным командам.
Более функциональная альтернатива — команда ip из пакета iproute2util.
⁃ Она намного шире по функциональности.
⁃ Организованна на двух уровнях: канальный и сетевой.
2 Шаг
На втором шаге проверяем доступен ли стандартный шлюз (default gateway) и правильно ли маршрутизируется трафик (при условии нескольких шлюзов в одном сегменте):
При проверке стандартного шлюза необходимо учитывать, что в таблице маршрутизации конечного хоста могут присутствовать и статические маршруты, переопределяющие шлюз по умолчанию для конкретных сетей. Понять есть ли статика можно опять же заглянув в раздел "Постоянные маршруты" вывода команды route print:
Для Linux, вариантом посмотреть таблицу маршрутизации будет команда ip r.
Команды route print и ip r по сути являются аналогами команд типа show ip route (в синтаксисе cisco) и выводят все содержимое таблицы маршрутизации. Однако есть более удобный способ выяснить (перепроверить) куда будет направляться трафик в зависимости от адреса назначения:
Для Windows в PowerShell:
К адресу 10.0.0.34 трафик будет направляться через шлюз 10.159.120.254
К адресу 8.8.8.8 трафик будет направляться через шлюз 10.159.120.200
Для Linux:
Команда ip route get позволяет получить ответ через какой шлюз будет маршрутизироваться трафик.
Данный способ гораздо проще, особенно в случаях перегруженной логики маршрутизации на хосте когда используется несколько шлюзов в одном сегменте или задействованы метрики, определяющие приоритет в зависимости от некоторых условий.
В целом для проверки первого хопа можно использовать и команду traceroute -d -h <адрес назначения> для Windows:
параметр -d - Без разрешения в имена узлов.
Ну в данном конкретном случае нам этот функционал не нужен, а на поиск имени по IP уйдет время. Попробуйте ввести команду без параметра -d и с ним и увидите разницу по времени. Да и в целом скорее всего результат трансляции IP в DNS будет безуспешен- имя требует наличие PTR записи на ваших локальных DNS. А ее там скорее всего нет.
параметр -h - Максимальное число прыжков при поиске узла.
Нас не интересует трассировка всей цепочки, а только первый хоп. Для этого мы и передаем параметру -h значение - 1
для Linux:
параметр -n - Без разрешения в имена узлов.
параметр -p - Максимальное число прыжков при поиске узла.
3 Шаг
Необходимо проверить есть ли у нас связность между клиентом и сервером. Под связностью я понимаю, что на всем пути от первого хопа по последнего у нас есть маршрутная информация. В данном случае нам поможет tracert/tracepath:
На втором скрине мы видим, что узел с IP 10.89.60.220 ничего не знает об адресе 10.0.0.34.
Наличие сообщения "Превышен интервал ожидания для запроса" в середине трассировки еще не говорит о том, что маршрута нет. Просто возможно на узле отключена поддержка ICMP. Да! утилиты трассировки используют в своей работе именно протокол ICMP. Каким образом расскажу позже.
C 8 по 16 хопы не поддерживают ICMP. Таким образом транзитные провайдеры могут скрывать маршрутную информацию. Однако самый последний хоп (сервер DNS) таки ответил.
Утилиты типа tracert/tracepath дают представление о том как в конкретный момент времени будет следовать пакеты от хоста источника к хосту назначения.
Если вы с столкнулись с ситуацией при которой наблюдается потеря пакетов (packet loss) и у вас есть подозрение, что это происходит где-то на транзитных участках, то тут потребуется применить более изощренную утилиту типа MTR (My Traceroute) . MTR задействует такой параметр как RTT (Round trip time). Встроенные механизмы утилиты и небольшой объем знаний как правильно интерпретировать ее вывод позволят вам локализовать проблемный участок. Описание данной утилиты тянет на отдельную статью, поэтому если интересно пишите в комментариях. По комментариям я пойму есть ли смысл ее рассматривать.
Пример вывода на экран диагностической информации утилиты MTR:
4 Шаг
Напомню:
На 1-м шаге мы проверяли все ли верно настроено на нашей стороне (на клиенте);
На 2-м шаге мы разобрались с тем куда трафик пойдет с нашего хоста (первый хоп);
На 3-м шаге мы проверили связность между клиентом и сервером на L3 уровне.
Итак 4-й шаг:
Переходим на уровень L4 - транспортный (TCP/UDP). Для проверки TCP сокета обычно используется telnet (Да! Та самая не безопасная утилита, если ее использовать для удаленного управления железом. А вот в качестве диагностического инструмента она в самый раз!)
Если не уверены в понимании, что есть сокет, то милости прошу в данную статью: TCP IP (Часть 1)
Предположим есть некоторый сервис доступный из вне по http (80 порт):
Проверим устанавливается ли у нас соединение по telnet.
Команда: telnet 172.17.74.64 80
Для использования telnet клиента в Windows необходимо его предварительно включить. Как это сделать коротко описано в данной статье.
Об успешном установлении TCP сессии будет свидетельствовать окно вида:
В верхнем левом углу будет периодически мигать строка ввода и окно закроется либо по таймауту ну или принудительно вами.
Сейчас я произведу некоторые манипуляции и картина будет такая:
Теперь сессия не устанавливается. Как понять в чем причина? Причин может быть несколько: закрыт порт на межсетевом экране, не запущенна служба, прослушивающая порт 80.
Подход к диагностики будет отличаться, в зависимости от того куда у вас есть доступ.
Предположим у вас есть доступ к серверу на котором должна быть активна служба http, тогда можно проверить активна ли служба командой netstat -tunlp | grep 80 (Для Linux систем). Если результат выполнения данной команды нулевой, то на 80 порту нет слушающих служб. Если же картина такая, то служба в готовности принять входящий запрос:
Состояние "LISTEN" означает, что демон httpd с PID (Process ID) №25674 слушает входящие запросы на 80-м порту. Если не отфильтровывать вывод утилитой grep, то можно увидеть все прослушиваемы порты и их службы:
Если доступа к серверу у вас нет, но вам необходимо понять в чем конкретно причина отсутствия доступа по 80-му порту, то можно сделать это по косвенным признакам:
Браузеры, в основной своей массе сообщают ошибку. ERR_CONNECTION_REFUSED сообщает о том, что по адресу 172.17.74.64 нет активной службы на 80-м порту.
А вот такая ошибка:
ERR_CONNECTION_TIMED_OUT говорит о том, что 80-й порт закрыт на межсетевом экране. В данной ситуации возникает вопрос, а на каком межсетевом? Межсетевых экранов на пути от клиента до сервера в большинстве случаев будет 1 или 2. Предположим у нас один межсетевой экран как на рисунке.
Понять где именно "режется доступ" можно используя tcpdump или wireshark. Первый для Linux систем, второй для Windows.
Запустив на нашем хосте, с которого мы инициируем подключение по http wireshark, то мы увидим следующую картину:
С нашей колокольни все выглядит так, как-будто сервер с IP адресом 172.17.74.64 режет нашу попытку подключения (флаг RST, в поле info). Но так ли это? Давайте я вам расскажу как это понять. Для этого нам придется препарировать 41-й пакет нашего дампа и заглянуть в заголовок сетевого уровня:
Нас будет интересовать поле "Time to live (TTL)":
В нашем случае значение поля = 64. Это начальное значение TTL.
Начальное значение бывает равно 64, 128, 256. Это значение зависит от типа операционной системы. Но сейчас не об этом.
Данное значение уменьшается на 1 каждый раз когда пакет передается следующему узлу. Т.е. можно смело сказать, что пакет №41 с флагом RST прислал нам наш шлюз (FW), а не удаленный сервер.
Вывод: для разрешения исходящего трафика на 80-й порт необходимо добавить разрешающее правило на нашем межсетевом экране.
Теперь рассмотрим такой вывод:
В данном случае TTL=63 и это говорит о том, что пакет TCP сессии успешно прошел транзитом через FW и режется на втором хопе. Сколько всего хопов мы уже умеем вычислять, но есть и альтернативная команда на Windows серверах - pathping:
Pathping предоставляет не только трассу, но и делает замеры RTT. Данный функционал похож на тот, что предоставляет MTR (My traceroute) о котором упоминалось выше.
И так мы видим, что трасса состоит из следующей цепочки:
1.Наш хост (test-cisco);
2.Файрвол (FW);
3. Хост назначения.
TTL=63 в ICMP сообщении "Destination Unreachable" говорит от то, что пакет успешно прошел 2 элемент цепочки, а дальше только Хост назначения - ipam.em.local. Следовательно с полной уверенностью можно сказать, что проблема на хосте назначения. Давайте взглянем на таблицу правил iptables:
Вот то самое правило которое режет нам доступ. Убираем правила командой iptables -F:
И пробуем установить соединение на 80-й порт (пример успешного обмена информацией в дампе):
Страница ресурса успешно загрузилась.
Iptables-утилита командной строки, является стандартным интерфейсом управления работой межсетевого экрана netfilter для ядер Linux, начиная с версии 2.4. Для использования утилиты iptables требуются привилегии суперпользователя.
Всегда нужно помнить, что фильтрация трафика может происходить не только на специальных устройствах (межсетевых экранах), но и непосредственно на уровне пакетных фильтров, встроенных в ядра операционных систем и управляемых специальными утилитами наподобие Iptables.
Итак мы рассмотрели способы траблшутинга сетевой связности и доступности сервиса с позиции клиента. Т.е. у нас есть доступ к клиентской машине и нет доступа к FW и серверу.
Если у вас есть доступ к FW, то обычно на современных железках есть функционал, позволяющий проверить есть ли drops/discards (сбросы) для целевого трафика, указав DST IP:port. У таких производителей как StoneGate, Checkpoint таблица срабатывания тех или иных правил отображается средствами интерфейса SMS (Security managment server). У Fortigate из коробки имеется packet capturing, позволяющий собрать дамп трафика и проанализировать в Wirechark. Есть у них и отдельное ПО - Fortigate Analyzer для централизованного логирования и аналитики.
И имеет место ситуация когда вы - владелец сервера. К примеру предоставляете web сервис внешним пользователям или API сторонним компаниям. К вам обращаются с проблемой мол запросы шлем, а ваш сервер их не обрабатывает. Как быть в этом случае? Ответ прост: "расчехляете" Wireshark(для серверов на базе Windows), tcpdump (для серверов на базе Linux) и смотрите действительно ли клиентские запросы долетают до вас и в каком виде. Ведь запросы могут долетать, но не в том виде в котором это определено договором по подключению к API например. К примеру у нас имеется VPN сервер к которому должны подключаться сторонние разработчики. Вы выпустили сертификат, настроили доступы, скинули инструкцию, а вам разработчик пишет: все сделал, но не подключается... Порядок ваших действий, чтобы понять можно ли слать лесом фразой RTFM следующий:
1. Уточните "белый IP" c которого производится подключение VPN клиентом. Узнать его просто, перейдя по ссылке https://2ip.ru/ из своего браузера:
2. Заходим в cli вашего VPN сервера:
3. Находим интерфейс в который производится NAT с пограничного устройства. В моем случае это интерфейс ens257
4. Запускаем tcpdump -i ens257 host 109.248.140.254 and port 64905 -n
-i - указываем какой интерфейс слушаем;
port - если знаете, то укажите - уменьшит количество лишнего трафика;
-n - не производить резолв в DNS имена.
Запустив команду, при наличии трафика подпадающего под указанные условия, на консоль начнет выводиться информация вида:
В данном выводе видно, что есть запросы с белого адреса и есть ответы. Т.е. TCP сессия корректно работает. Если на консоль ничего не прилетает, то проблема точно не на стороне сервера!
Иногда может быть неудобно принимать трафик на консоль. На консоль имеет смысл вывести если вас интересует сам факт: есть трафик или его нет. Если же вы хотите проанализировать трафик подробнее, то имеет смысл сохранить трафик в файл и открыть потом в Wireshark. Для этого немного модифицируем команду:
tcpdump -i ens257 host 109.248.140.254 and port 64905 -n -w dump.pcap
-w - записать весь перехваченный трафик в файл dump.pcap
tcpdump мощный инструмент. Вот ссылка для более подробного рассмотрения: https://habr.com/ru/company/alexhost/blog/531170/?ysclid=l4zmiuluio451754966
На этом буду завершать. Буду рад комментариям с вопросами или дополнениями. Так же было бы полезно узнать Ваше мнение о качестве материала и понять куда глубже копнуть для пользы дела)