Смотрим в looking-glass
Замечательным примером сетевой солидарности являются многочисленные сервисы looking-glass, позволяющие заглянуть за кулисы очень многих больших и маленьких сетей во всём мире. Это настолько удивительно в современном мире, спрятанном за сотней систем безопасности, просто так взять и выполнить команды на маршрутизаторах являющихся одними из самых критичных устройств всей инфраструктуры передачи данных.
Надо лишь ввести IP адрес или префикс в поле и получить в ответ таблицу маршрутизации или трассировку и результаты работы утилиты ping. Поэтому когда понимаешь, что можно вводить не только адреса, но и некоторые другие символы сформированные в осмысленные команды и получать осмысленные результаты, наступает ступор. Хочется бежать и кричать на всех углах: «Да что же это такое надо немедленно запретить, что за несуразность?». Это всё последствия последних лет, когда безопасность превыше открытости и удобности и на это, несомненно, есть причины.
Речь пойдёт об очень популярной реализации looking-glass от version6.net и о том что-же можно получить от этого сервиса.
Если вам вдруг покажется обычным что интерфейс looking-glass позволяет вводить что-то кроме IP адреса, то вероятно вы относитесь к «старой школе» или не читаете новости. Мне показалось это необычным, тем более что другие реализации этого сервиса такого не позволяют.
Открываем lg.cgi, который читается достаточно тяжело и Perl здесь совсем не помогает:
Команда передаётся в переменной $addr, в которой удаляются все символы кроме пробельных (включая табы, опция \s), букв, цифр, символов «-«, «_», «/», «$», «.», «:».
Условие с ping значительно строже. Насколько я вижу вытирается весь ввод после пробельного символа. Поэтому добавить что-то лишнее в команду ping и traceroute значительно сложнее.
Потом формируется команда для непосредственного выполнения из шаблона $query_cmd и выполняется проверка на принадлежность ввода немного другой группе символов: исключаются табы, потому что явно указаны пробелы, символ «_» остаётся включённым потому что попадает под опцию \w вместе с цифрами, появляется символ «^». Дополнительная проверка делается на «:», которое возможно только при работе с IPv6.
Вот собственно и всё, оставшиеся проверки только на пустую строку для некоторых режимов работы. Команда для выполнения уже сформирована ранее и она без изменений уходит на устройство:
Что же мы можем? Из полезного потеряли кавычки, символы «|», «?» и все скобки. Но осталось очень много, даже очень. Шаблон формирующий команды выглядит вот так (для Cisco):
Основные команды show ip bgp, ping и traceroute. Очевидно что show ip bgp summary и show ip bgp neighbors %s advertised-routes, можно сформировать из show ip bgp %s.
show ip bgp
Наш хлеб. Стоит отметить что на разных сайтах всё же производится дополнительная фильтрация, или доработка под другие системы отличные от стандартных, поэтому не всегда ввод произвольных символов возможен. Скорее даже он возможен, но дальнейшее выполнение команд приводит к ошибкам. Однако если мы имеем базовые устройства предусмотренные в оригинальном коде то можем вводить широкий спектр команд. Сайт Cisco, остановимся на одном вендоре, предлагает много вариантов. Немного полезных, для примера.
show ip bgp regexp
Смотрим все маршруты по заданному AS-PATH. Например, до всех сетей Yandex из Стокгольма, ТТК (GET отправит напрямую к результатам запроса):
show ip bgp neighbors
Подробная информация об установленных соседствах. Команда иногда косвенно доступна в подсвеченном выводе при выполнении других команд. Например, подробная информация об одном из соседств Билайна в Ставрополе:
Можно расширить до advertised-routes, чтобы посмотреть какие маршруты анонсируются в сторону определённого соседа, часто присутствует непосредственно в интерфейсе.
show ip bgp summary
Команда не всегда доступна напрямую, поэтому можно попробовать выполнить в обход. Например, для РТКОММ:
Ping и Traceroute
И эти команды можно расширить: увеличить размер пакета, выключить фрагментирование. Но сделать это сложнее, потому что код для фильтрации строже. Примеры, однако можно найти — Starnet, кстати здесь Juniper:
Looking-glass замечательный инструмент, даже отличный, решающий многие проблемы и сплачивающий ряды сетевых специалистов по всему миру, очень чёткий признак зрелости компании. Упомянув несколько разных компаний, в своей я пока не решился выставить подобный сервис наружу.
Экспериментировать можно долго, сервисов LG доступно очень много по всему миру и достаточное количество из них построено на версии предлагаемой version6.net. Но любой инструмент должен быть предсказуем, некоторые из нефильтруемых команд ужасно ресурсоёмки, некоторые открывают чуть больше чем можно позволить в современном мире. Загляните в свой код и сделайте так как вам будет достаточно. Будьте внимательны друг к другу, взаимовыручка и открытость позволили построить Интернет, не будем это разрушать.
Диагностика сетевых проблем с помощью Looking Glass
Для многих наших клиентов критерием выбора серверных услуг является сетевая связность. Под сетевой связностью понимается степень взаимодействия сети одного оператора с сетями других операторов и, как следствие, количество маршрутов и количество промежуточных узлов для интернет-трафика.
Проверку сетевой связности удобно осуществлять с помощью сервисов, называемых «Looking Glass» (в переводе с английского — зеркало). Они позволяют проверять маршрутизацию из удаленной сети. Такие сервисы есть у многих организаций (с информацией обо всех Looking Glass мира можно ознакомиться, например, здесь ).
Свой сервис «Looking Glass» есть и у нашей компании. Он расположен по адресу: http://lg.selectel.ru. Диагностика с помощью «Looking Glass» позволяет конкретизировать возникшую неисправность и выдвинуть обоснованное предположение о ее причине. О диагностических процедурах, которые можно осуществить с помощью этого сервиса, пойдет речь ниже.
Интерфейс нашего «Looking Glass» предельно прост:
Все команды выполняются с двух маршрутизаторов, расположенных в Санкт-Петербурге и в Москве (выбрать маршрутизатор можно, установив флажок в поле Router; можно осуществлять проверку с двух маршрутизаторов одновременно).
Наш сервис «Looking Glass» выполняет следующие команды (выбор команды осуществляется в выпадающем меню «Operation»):
Выбрав команду, нужно указать в поле «Host» адрес хоста назначения (можно ввести как IP-адрес, так и DNS-имя) и нажать на кнопку «Do it». Рассмотрим более подробно, как работает каждая из этих команд и как следует интерпретировать их результаты.
Команда ping
С помощью этой команды можно проверить доступность указанного узла используя специальный протокол ICMP. Принцип ее работы заключается в следующем: получив команду ping, маршрутизатор отправляет запросы к указанному узлу, который, в свою очередь, отправляет его обратно (по тому адресу, откуда он пришел). Из результатов запроса ping можно узнать, (1) вернулись ли отправленные пакеты обратно и (2) сколько времени (в миллисекундах) потребовалось для движения пакетов туда и обратно.
Результаты команды ping могут выглядеть, например, так:
Из этого примера видно, что узел назначения исправно отвечает на запросы, потерь пакетов нет. Рассмотрим еще один пример:
В данном случае из результатов видно, что узел назначения доступен, потери пакетов нет, но время ответа несколько увеличено по причине географической удаленности: узел назначения находится в Японии, а запросы отправлялись из Санкт-Петербурга.
Иногда может иметь место и такая ситуация:
Результаты работы команды в данном случае показывают, что ни один из пакетов не дошел до цели и что узел, скорее всего, недоступен, или не отвечает на ICMP-запросы.
Таким образом, с помощью запроса ping можно проверить соединение с удаленным узлом. Сам факт успешного возвращения запросов дает основания предполагать, что все устройства на пути от маршрутизатора к указанному узлу работают нормально. Следует отметить, что потеря пакетов может иметь место даже при отсутствии неисправностей: она может быть обусловлена, например, перегруженностью сети. Часто бывает и так, что маршрутизаторы дают диагностирующим пакетам низкий приоритет. Но если хотя бы один из отправленных пакетов возвращается, то это уже свидетельствует о наличии соединения и доступности узла.
На основании результатов запроса ping однозначного вывода о наличии неисправности сделать невозможно. Можно лишь выдвинуть предположение, которое нуждается в дополнительной проверке с помощью других инструментов.
Команда traceroute
Проблемы с доступностью веб-сервисов могут также быть обусловлены техническими проблемами на промежуточных узлах, через которые проходят пакеты на пути к хосту назначения. Выявить эти проблемы можно с помощью команды traceroute.
Как работает эта команда? Одной из характеристик пересылаемых по сети пакетов является время жизни (англ. time to live, сокращенно TTL) — число хопов (англ. hop — прыжок, т.е. переход пакета от одного маршрутизатора — к другому) или время в миллисекундах, в течение которого пакет может находиться в сети. Каждый маршрутизатор, обрабатывающий пакет, уменьшает значение TTL на единицу. Когда TTL становится равным нулю, пакет уничтожается, а отправителю высылается IMCP-сообщение time exceeded (время истекло). Изначально этот механизм использовался для предотвращения бесконечного копирования сетевых пакетов при ошибочном закольцевании сети.
Получив команду traceroute, маршрутизатор отправляет в направлении хоста назначения пакет с TTL=1. Узел, с которого приходит ответ time exceeded, определяется как первый хоп (т.е. первый шаг на пути к цели). Затем поочередно отправляются пакеты с TTL=2,3,4,5 и так далее — до тех пор, пока один из пакетов не достигнет узла назначения и не получит от него ответ.
В результате на экран выводится список всех промежуточных узлов на пути пакета от маршрутизатора к узлу назначения. Он может, выглядеть, например, так:
Что видно из представленного результата?
В девятом переходе вместо одного из значений времени ответа отображается звездочка. Это означает, что на какой-то из отправленных пакетов не было получено ответа. Это может быть вызвано, например, перегрузкой сети. Или тем, что многие маршрутизаторы отбрасывают низкоприоритетные ICMP-пакеты. Появление таких звездочек в выводе traceroute — вполне типичная ситуация, которая не является причиной для беспокойства.
Если для одного из промежуточных маршрутизаторов отображается три звездочки, то это значит, что от него не было получено ни одного ответа. Но не следует делать вывода о наличии неисправности на основании одних лишь этих звездочек. Их появление может быть обусловлено самыми разными причинами. Например, маршрутизаторы нередко конфигурируют таким образом, чтобы они “молча” отбрасывали устаревшие пакеты. В этом случае пакеты благополучно переходят на следующий маршрутизатор.
Причина может заключаться и в том, что ответные пакеты от этого маршрутизатора идут слишком долго, и Looking Glass перестает ждать их прибытия. Если же три звездочки отображаются для узлов в конце маршрута (как в приведенном примере), то это, скорее всего, свидетельствует о том, что пакеты до узла назначения не дошли.
Интерпретация выводов traceroute представляет собой более сложную и тонкую задачу, чем это может показаться на первый взгляд; более подробно об этом можно прочитать здесь и здесь (на английском языке).
Команды для диагностики BGP
BGP (англ. Border Gateway Protocol, протокол граничного шлюза) — это основной протокол динамической маршрутизации в Интернете. Он предназначен для обмена информацией не между отдельными маршрутизаторами, а между автономными системами. Автономной системой, согласно определению, данному в RFC1930, называется система IP-сетей и маршрутизаторов, управляемых одним или несколькими операторами и имеющими отдельную политику маршрутизации с Интернетом. Собственно, Интернет можно рассматривать как набор связанных друг с другом автономных систем.
С помощью BGP-протокола автономные системы сообщают друг другу: (1) о факте своего существования и (2) о том, какие сети могут быть получены через них. Они также собирают информацию о том, как добраться до других сетей в Интернете. Получая информацию о маршрутах до цели назначения, они определяют из них наилучший (на основе правил сети, а не технических метрик) и добавляют в свои таблицы маршрутизации. Именно поэтому BGP-протокол иногда называют клеем, связующим весь Интернет.
Протокол BGP был создан во времена, когда в Интернете не существовало многих проблем и опасностей, которые существуют сегодня, и он характеризуется повышенной уязвимостью. Ошибки в работе протокола, которые могут быть вызваны как техническими проблемами конкретной автономной системы, так и намеренными действиями злоумышленников, могут приводить к очень серьезным последствиям (более подробно об этом можно прочитать, например, здесь ). В результате этих ошибок трафик перенаправляется и/или отбрасывается, не доходя до сети назначения — из-за этого возникают проблемы с сетевой доступностью.
Проверить работу BGP-протокола можно при помощи команд bgp route detail, bgp route terse и bgp summary. Результатом работы команды bgp route detail является таблица маршрутизации c перечнем всех автономных станций на пути движения пакетов. Команда bgp terse выводит на экран сокращенный вариант таблицы маршрутизации. Команда bgp summary выводит список всех автономных систем, с которыми есть связность у наших маршрутизаторов.
Заключение
В этой статье мы привели лишь краткое описание возможностей нашего сервиса «Looking Glass». Диагностика сетевых проблем представляет собой тему, которую невозможно охватить в рамках одной публикации. Если у вас возникли вопросы по работе нашего «Looking Glass» — добро пожаловать в комментарии. Будем также рады конструктивным замечаниям и предложениям по работе сервиса.
Looking Glass
Looking Glass (LG) (англ. зеркало ) — серверы в Интернет для проверки маршрутизации из удалённой автономной системы. По сути это сильно ограниченный доступ (только чтение) на маршрутизаторы организации, где запущен сервер Looking Glass. Обычно это интернет-провайдеры.
Ссылки
Смотреть что такое «Looking Glass» в других словарях:
Looking Glass — may refer to: *Looking glass is another term for mirror. *Looking Glass (airplane) is a codename for an airplane that provides command and control of U.S. nuclear forces. Two different models of planes have been used: **E 6B United States Navy… … Wikipedia
Looking Glass EP — EP par The Birthday Massacre Sortie 6 mai 2008 Enregistrement 2008 Durée 32:27 Genre electro rock alternative rock Label … Wikipédia en Français
looking glass — looking glasses also looking glass N COUNT A looking glass is a mirror. [OLD FASHIONED] … English dictionary
looking-glass — 1520s, from looking (see LOOK (Cf. look)) + GLASS (Cf. glass) … Etymology dictionary
looking glass — n. a (glass) mirror … English World dictionary
looking glass — n old fashioned a ↑mirror … Dictionary of contemporary English
looking glass — ► NOUN ▪ a mirror … English terms dictionary
Looking Glass — Der Begriff Looking Glass (engl. für „Spiegel“) steht für: einen fliegenden Gefechtsleitstand für Atomkriegsführung der USA, siehe Looking Glass (Luftgestütztes Kommandozentrum) einen Internet Dienst zum Auffinden gewisser Routing Informationen,… … Deutsch Wikipedia
Диагностика сетевых проблем с помощью Looking Glass
Для многих наших клиентов критерием выбора серверных услуг является сетевая связность. Под сетевой связностью понимается степень взаимодействия сети одного оператора с сетями других операторов и, как следствие, количество маршрутов и количество промежуточных узлов для интернет-трафика.
Проверку сетевой связности удобно осуществлять с помощью сервисов, называемых «Looking Glass» (в переводе с английского — зеркало). Они позволяют проверять маршрутизацию из удаленной сети. Такие сервисы есть у многих организаций (с информацией обо всех Looking Glass мира можно ознакомиться, например, здесь).
Свой сервис «Looking Glass» есть и у нашей компании. Он расположен по адресу: http://lg.selectel.ru. Диагностика с помощью «Looking Glass» позволяет конкретизировать возникшую неисправность и выдвинуть обоснованное предположение о ее причине. О диагностических процедурах, которые можно осуществить с помощью этого сервиса, пойдет речь ниже.
Интерфейс нашего «Looking Glass» предельно прост:
Все команды выполняются с двух маршрутизаторов, расположенных в Санкт-Петербурге и в Москве (выбрать маршрутизатор можно, установив флажок в поле Router; можно осуществлять проверку с двух маршрутизаторов одновременно).
Команда ping
С помощью этой команды можно проверить доступность указанного узла используя специальный протокол ICMP. Принцип ее работы заключается в следующем: получив команду ping, маршрутизатор отправляет запросы к указанному узлу, который, в свою очередь, отправляет его обратно (по тому адресу, откуда он пришел). Из результатов запроса ping можно узнать, (1) вернулись ли отправленные пакеты обратно и (2) сколько времени (в миллисекундах) потребовалось для движения пакетов туда и обратно.
Результаты команды ping могут выглядеть, например, так:
Из этого примера видно, что узел назначения исправно отвечает на запросы, потерь пакетов нет. Рассмотрим еще один пример:
В данном случае из результатов видно, что узел назначения доступен, потери пакетов нет, но время ответа несколько увеличено по причине географической удаленности: узел назначения находится в Японии, а запросы отправлялись из Санкт-Петербурга.
Иногда может иметь место и такая ситуация:
Результаты работы команды в данном случае показывают, что ни один из пакетов не дошел до цели и что узел, скорее всего, недоступен, или не отвечает на ICMP-запросы.
Таким образом, с помощью запроса ping можно проверить соединение с удаленным узлом. Сам факт успешного возвращения запросов дает основания предполагать, что все устройства на пути от маршрутизатора к указанному узлу работают нормально. Следует отметить, что потеря пакетов может иметь место даже при отсутствии неисправностей: она может быть обусловлена, например, перегруженностью сети. Часто бывает и так, что маршрутизаторы дают диагностирующим пакетам низкий приоритет. Но если хотя бы один из отправленных пакетов возвращается, то это уже свидетельствует о наличии соединения и доступности узла.
На основании результатов запроса ping однозначного вывода о наличии неисправности сделать невозможно. Можно лишь выдвинуть предположение, которое нуждается в дополнительной проверке с помощью других инструментов.
Команда traceroute
Проблемы с доступностью веб-сервисов могут также быть обусловлены техническими проблемами на промежуточных узлах, через которые проходят пакеты на пути к хосту назначения. Выявить эти проблемы можно с помощью команды traceroute.
Как работает эта команда? Одной из характеристик пересылаемых по сети пакетов является время жизни (англ. time to live, сокращенно TTL) — число хопов (англ. hop — прыжок, т.е. переход пакета от одного маршрутизатора — к другому) или время в миллисекундах, в течение которого пакет может находиться в сети. Каждый маршрутизатор, обрабатывающий пакет, уменьшает значение TTL на единицу. Когда TTL становится равным нулю, пакет уничтожается, а отправителю высылается ICMP-сообщение time exceeded (время истекло). Изначально этот механизм использовался для предотвращения бесконечного копирования сетевых пакетов при ошибочном закольцевании сети.
Получив команду traceroute, маршрутизатор отправляет в направлении хоста назначения пакет с TTL=1. Узел, с которого приходит ответ time exceeded, определяется как первый хоп (т.е. первый шаг на пути к цели). Затем поочередно отправляются пакеты с TTL=2,3,4,5 и так далее — до тех пор, пока один из пакетов не достигнет узла назначения и не получит от него ответ.
В результате на экран выводится список всех промежуточных узлов на пути пакета от маршрутизатора к узлу назначения. Он может, выглядеть, например, так:
Что видно из представленного результата?
В девятом переходе вместо одного из значений времени ответа отображается звездочка. Это означает, что на какой-то из отправленных пакетов не было получено ответа. Это может быть вызвано, например, перегрузкой сети. Или тем, что многие маршрутизаторы отбрасывают низкоприоритетные ICMP-пакеты. Появление таких звездочек в выводе traceroute — вполне типичная ситуация, которая не является причиной для беспокойства.
Если для одного из промежуточных маршрутизаторов отображается три звездочки, то это значит, что от него не было получено ни одного ответа. Но не следует делать вывода о наличии неисправности на основании одних лишь этих звездочек. Их появление может быть обусловлено самыми разными причинами. Например, маршрутизаторы нередко конфигурируют таким образом, чтобы они “молча” отбрасывали устаревшие пакеты. В этом случае пакеты благополучно переходят на следующий маршрутизатор.
Причина может заключаться и в том, что ответные пакеты от этого маршрутизатора идут слишком долго, и Looking Glass перестает ждать их прибытия. Если же три звездочки отображаются для узлов в конце маршрута (как в приведенном примере), то это, скорее всего, свидетельствует о том, что пакеты до узла назначения не дошли.
Интерпретация выводов traceroute представляет собой более сложную и тонкую задачу, чем это может показаться на первый взгляд; более подробно об этом можно прочитать здесь и здесь (на английском языке).
Команды для диагностики BGP
BGP (англ. Board Gateway Protocol, протокол граничного шлюза) — это основной протокол динамической маршрутизации в Интернете. Он предназначен для обмена информацией не между отдельными маршрутизаторами, а между автономными системами. Автономной системой, согласно определению, данному в RFC1930, называется система IP-сетей и маршрутизаторов, управляемых одним или несколькими операторами и имеющими отдельную политику маршрутизации с Интернетом. Собственно, Интернет можно рассматривать как набор связанных друг с другом автономных систем.
С помощью BGP-протокола автономные системы сообщают друг другу: (1) о факте своего существования и (2) о том, какие сети могут быть получены через них. Они также собирают информацию о том, как добраться до других сетей в Интернете. Получая информацию о маршрутах до цели назначения, они определяют из них наилучший (на основе правил сети, а не технических метрик) и добавляют в свои таблицы маршрутизации. Именно поэтому BGP-протокол иногда называют клеем, связующим весь Интернет.
Протокол BGP был создан во времена, когда в Интернете не существовало многих проблем и опасностей, которые существуют сегодня, и он характеризуется повышенной уязвимостью. Ошибки в работе протокола, которые могут быть вызваны как техническими проблемами конкретной автономной системы, так и намеренными действиями злоумышленников, могут приводить к очень серьезным последствиям (более подробно об этом можно прочитать, например, здесь). В результате этих ошибок трафик перенаправляется и/или отбрасывается, не доходя до сети назначения — из-за этого возникают проблемы с сетевой доступностью.
Проверить работу BGP-протокола можно при помощи команд bgp route detail, bgp route terse и bgp summary. Результатом работы команды bgp route detail является таблица маршрутизации c перечнем всех автономных станций на пути движения пакетов. Команда bgp terse выводит на экран сокращенный вариант таблицы маршрутизации. Команда bgp summary выводит список всех автономных систем, с которыми есть связность у наших маршрутизаторов.
Заключение
В этой статье мы привели лишь краткое описание возможностей нашего сервиса «Looking Glass». Диагностика сетевых проблем представляет собой тему, которую невозможно охватить в рамках одной публикации. Если у вас возникли вопросы по работе нашего «Looking Glass» — добро пожаловать в комментарии. Будем также рады конструктивным замечаниям и предложениям по работе сервиса.
Для тех кто не может комментировать посты на Хабре, приглашаем к нам в блог.
