Looking glass провайдера: как посмотреть на себя глазами дата-центра

MAATRIX

Обычный traceroute с домашнего компьютера показывает только половину картины — маршрут пакета от вас к серверу. Как выглядит путь обратно, глазами самого дата-центра, вы этим способом не увидите никогда, а маршруты в интернете почти всегда асимметричны — то есть это не мелкая деталь, а буквально вторая половина диагностики, недоступная с вашей стороны провода. Looking glass — бесплатный публичный инструмент, который решает именно эту проблему: он даёт запустить ping, traceroute, а иногда и BGP-запрос не с вашего компьютера, а изнутри сети дата-центра или оператора, из его собственной точки присутствия.

Что такое looking glass на самом деле

Looking glass (дословно «зеркало», отсылка к кэрролловскому «Алисе в Зазеркалье») — веб-страница, которую многие дата-центры, магистральные операторы и точки обмена трафиком (IX) держат в открытом доступе. Внешне это обычно простая HTML-форма: поле для IP-адреса или домена, выпадающий список команд (ping, traceroute, иногда bgp show route/bgp summary), может быть выбор конкретной точки присутствия или пограничного маршрутизатора, если у оператора их несколько. Нажимаете кнопку — и сервис за кулисами реально выполняет эту команду на одном из пограничных роутеров оператора, а вам возвращает сырой вывод, как будто вы сами зашли на этот роутер по SSH и ввели её руками.

Технически это почти всегда тонкая обёртка вокруг CLI сетевого оборудования (Cisco IOS, Juniper JunOS, реже что-то основанное на Linux с FRR/BIRD) с жёстко ограниченным набором разрешённых команд и без интерактивной сессии — вы отправляете один запрос, получаете один ответ, никакого произвольного ввода. Родились looking glass серверы как неформальный инструмент сетевых инженеров для инженеров: способ быстро попросить коллегу «глянь, как это видно у вас», не давая постороннему реальный доступ к оборудованию. Со временем многие крупные операторы и дата-центры сделали такие страницы публичными — не из щедрости, а потому что это снижает число обращений в поддержку с формулировкой «у вас что-то не так с сетью», на которые иначе пришлось бы отвечать вручную.

Почему это не то же самое, что попросить у хостера доступ к серверу

Если у вас есть SSH-доступ к своему серверу в нужном дата-центре, вы и так можете запустить traceroute/mtr с него в любую сторону — и это даёт даже больше гибкости, чем looking glass. Разница в том, что looking glass не требует своего сервера в этом дата-центре вообще. Это особенно полезно в двух ситуациях: когда сервер, до которого вы диагностируете связность, чужой (например, вы пытаетесь понять, почему плохо грузится сторонний сервис), и когда нужно быстро сравнить точки зрения нескольких сетей подряд — открыть несколько looking glass разных операторов и за пару минут увидеть, как выглядит путь до вашего IP с точки зрения каждого из них, не поднимая для этого ни одной виртуалки.

Главная польза: асимметрия маршрута перестаёт быть слепой зоной

Ключевая причина, по которой looking glass вообще стоит держать в закладках, а не только в списке диагностических утилит — асимметрия маршрутизации. Путь пакета от клиента к серверу и путь ответа от сервера к клиенту в интернете формируются независимо: на каждом хопе решение принимает сеть, через которую пакет сейчас идёт, исходя из своей собственной таблицы BGP и договорённостей с соседями, а не по общей карте маршрутов. Подробно механика того, почему туда и обратно почти никогда не совпадают полностью, разобрана в статье про асимметричный маршрут — здесь достаточно зафиксировать практическое следствие: traceroute, запущенный с вашего компьютера, физически не может показать вам путь «обратно», потому что этот путь формируется не на вашей стороне.

Обычно с этим слепым пятном мирятся — ну не видно и не видно, работает же. Но когда есть конкретная жалоба на качество связи с конкретным сервером, эта слепая зона превращается в реальную проблему диагностики: вы видите половину картины, а вторая половина, где, возможно, и живёт причина, остаётся недоступной. Looking glass дата-центра, в котором стоит сервер, — это чужие глаза именно на ту половину пути, которую вы иначе не увидите вообще. Причины, по которым маршрут может делать неожиданный крюк и не совпадать с ожиданиями по географии, разобраны отдельно в статье про маршрутизацию против географии — looking glass не объясняет, почему маршрут выбран именно так, но позволяет увидеть сам факт, каким он получился с той стороны.

Практический сценарий: сравниваем свою трассировку с трассировкой дата-центра

Возьмём типичную жалобу: «до сервера в дата-центре плохо — пинг скачет, соединение рвётся». Прежде чем писать в поддержку хостинга, полезно понять, на какой половине пути реальная проблема — на вашей стороне (домашний провайдер, ближайшие к вам сети) или на стороне дата-центра и его аплинков. План действий:

1. Снимите трассировку с вашей стороны до сервера. Обычным mtr или traceroute, желательно с накоплением статистики за несколько минут, а не одним снимком:

mtr -rwzb -c 100 203.0.113.10

1. Откройте looking glass того же дата-центра (или, если у оператора его нет — looking glass ближайшего к вам крупного оператора или точки обмена трафиком, через которую предположительно идёт трафик) и запустите traceroute обратно к своему собственному IP-адресу. Если постоянного публичного IP у вас нет — подойдёт любой стабильный адрес того же провайдера, который вы контролируете или про который точно знаете, что он в той же сети.

1. Сравните списки хопов и ASN в обе стороны. Не сами IP-адреса — они часто отличаются даже на симметричном маршруте из-за балансировки нагрузки, — а сети (ASN) по пути и общую форму трассы: сколько хопов, где маршрут «упирается» в задержку или потери.

1. Сделайте вывод по совпадению или расхождению картины. Если оба направления идут через одни и те же сети и обе трассы чистые, а проблема тем не менее ощущается — вероятнее дело не в сети, а в самом сервере или в конкретном приложении. Если трасса «туда» чистая, а трасса «обратно» (по данным looking glass) явно проблемная на каком-то участке — вы нашли направление и примерный участок, с которым обращаться в поддержку дата-центра или транзитного оператора. Если наоборот — проблема на вашей стороне и стоит начинать разговор со своим провайдером, а не с хостингом.

Типичный вывод looking glass выглядит примерно так же, как обычный traceroute, только заголовок сообщает, что запрос выполнен с конкретного пограничного маршрутизатора конкретного оператора:

traceroute to 198.51.100.20 (198.51.100.20), 30 hops max
 executed from router edge1.fra.example-dc.net (AS64500)
 1  10.255.0.1 (10.255.0.1)  0.312 ms
 2  ix-fra.example-ix.net (192.0.2.1)  0.891 ms
 3  transit1.upstream.net (192.0.2.45)  4.221 ms
 4  border.otherisp.net (198.51.100.1)  12.044 ms
 5  198.51.100.20 (198.51.100.20)  12.980 ms

Сопоставив это построчно с собственным mtr до того же дата-центра, вы фактически восстанавливаете обе половины пути — то, что раньше было доступно только при наличии SSH-доступа на сам сервер, как описано в статье про асимметричный маршрут. Looking glass даёт похожий результат без этого доступа — правда, только с точки зрения пограничного роутера дата-центра, а не конечного сервера внутри него, что почти всегда достаточно близко для практических выводов.

Что можно запросить через looking glass, а что — нет

Looking glass — не полноценный shell-доступ и никогда им не задумывался. Набор команд сознательно ограничен по соображениям безопасности сети оператора: если бы через веб-форму можно было выполнять произвольные команды на пограничном маршрутизаторе, это была бы дыра, которой рано или поздно кто-нибудь воспользовался бы для разведки внутренней топологии сети или чего похуже. Обычно доступны:

Чего почти никогда не будет: интерактивной shell-сессии, просмотра конфигурации оборудования, произвольных DNS-запросов, доступа к статистике конкретного порта, а тем более — команд с побочными эффектами. Почти всегда стоит и защита от злоупотребления: rate limiting на число запросов с одного адреса за минуту, иногда простая CAPTCHA перед формой. Это ожидаемо — looking glass существует, чтобы дать диагностическую видимость, а не заменить полноценный доступ к сети оператора.

Зачем нужен BGP-запрос, если обычно хватает ping и traceroute

Пункт bgp show route в looking glass пригождается реже, чем ping и traceroute, но отвечает на вопрос, который traceroute показать не может напрямую: через какую именно автономную систему оператор сейчас видит путь до нужной подсети, и не изменился ли этот путь неожиданно. Если сеть заявляет, что видит ваш префикс через одного транзитного партнёра, а по факту трафик идёт через другого — это симптом либо изменения политики маршрутизации у кого-то из посредников, либо, в более редких случаях, некорректного анонса где-то по цепочке. Подробнее о том, как локализовать участок с проблемой, если её причина именно в маршрутизации, — в статье про то, как теряются пакеты и как найти проблемный участок.

Для рядового пользователя bgp show route обычно избыточен — 90% практических случаев закрываются сравнением traceroute в обе стороны. Но если картина странная (маршрут внезапно и надолго изменился, задержка резко выросла без видимой причины на промежуточных хопах), быстрый взгляд на BGP-таблицу конкретного оператора через looking glass отличает «маршрут поменялся по объективной причине» от «что-то сломано», не дожидаясь ответа от поддержки.

Где искать looking glass нужного дата-центра или оператора

Единого каталога всех looking glass в интернете не существует и не может существовать — их держат сотни независимых операторов, часть появляется, часть закрывается или переезжает на новый адрес без предупреждения. Практический порядок поиска:

• Сайт самого дата-центра или оператора. Ищите разделы вроде «Network», «Tools», «Looking Glass», «Status», «NOC» — обычно в футере сайта или в документации для клиентов. Запрос вида «<название оператора> looking glass» почти всегда приводит прямо на нужную страницу, если она есть.
• Публичные агрегаторы списков looking glass. В сети есть сайты, которые собирают ссылки на десятки и сотни публичных looking glass по операторам и странам — удобная отправная точка, если точный адрес неизвестен. Конкретные названия здесь сознательно не приводятся: список живых, а не битых ссылок со временем меняется, надёжнее один раз найти актуальный агрегатор через поиск.
• PeeringDB. Не сам looking glass, а база данных сетей и точек присутствия, но у многих записей операторов там указана прямая ссылка на их looking glass — удобно, если вы уже знаете ASN или название нужной сети.

Если у конкретного оператора публичного looking glass нет — это нормально, далеко не все его держат. Остаётся либо looking glass соседних по маршруту крупных сетей (точки обмена трафиком, крупного транзитного оператора), либо, если сервер там всё же ваш, обычный mtr по SSH с самого сервера, как разобрано в статье про асимметричный маршрут.

Ограничения инструмента: чего от looking glass ждать не стоит

Looking glass — быстрый и бесплатный способ получить вторую точку зрения, но не замена полноценной диагностике:

• Один снимок, а не непрерывный мониторинг. Большинство looking glass выполняют разовый запрос — эквивалент одного ping/traceroute, а не mtr со статистикой за несколько минут. Перемежающиеся проблемы одним запросом поймать сложно; если сервис поддерживает несколько попыток подряд, стоит запускать команду несколько раз с интервалом.
• Точка зрения ограничена конкретным пограничным роутером оператора, а не самим сервером внутри дата-центра — путь от пограничного роутера до стойки с сервером looking glass не покажет, это уже внутренняя сеть дата-центра.
• Не у всех операторов на пути есть публичный looking glass. Если проблемный участок — транзитная сеть где-то в середине маршрута без своего looking glass, посмотреть на неё её собственными глазами не выйдет, только оценить по данным до и после этого участка.
• Результат может отличаться от реального трафика приложения. Как и обычный traceroute/ping, looking glass использует ICMP или похожие служебные пакеты, которые некоторые сети сознательно обрабатывают иначе, чем TCP/UDP, — вплоть до ограничения скорости ответа на диагностические запросы. * * * на промежуточном хопе часто ничего не говорит о судьбе обычного пользовательского трафика через этот же узел.

Частые вопросы