Что такое хендшейк BGP-сессии между вашим хостером и миром

MAATRIX

Если вы арендовали VPS и настраиваете на нём сайт или приложение, вы скорее всего никогда не видели слово BGP и не должны его видеть — это забота вашего хостинг-провайдера, а не ваша. Но когда сервер вдруг на пару минут пропадает для половины мира без единой ошибки в его собственных логах, или скорость до него из разных стран заметно различается, полезно понимать, что за кулисами интернет держится на постоянном разговоре между независимыми сетями — и разговор этот начинается именно с хендшейка BGP-сессии.

Интернет — это не одна сеть, а множество договаривающихся между собой

Первое, что стоит честно себе прояснить: интернета как единой управляемой системы не существует. Есть тысячи отдельных, независимо управляемых сетей — их называют автономными системами (AS, Autonomous System). Своя AS есть у вашего хостинг-провайдера, у оператора связи, к которому этот провайдер подключён, у крупного магистрального оператора, у Google, у любого крупного дата-центра. Каждая такая сеть сама решает, что происходит у неё внутри — какие у неё маршрутизаторы, как устроена её собственная топология, — но за пределами своих границ она ничего не контролирует и не видит.

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

Ровно так работает BGP (Border Gateway Protocol) — протокол, по которому автономные системы объявляют друг другу: "вот такой блок IP-адресов доступен через меня". Это не команда сверху и не центральный реестр, а именно распределённый обмен слухами по правилам — миллионы отдельных объявлений, из которых постепенно складывается коллективная карта маршрутов для всего интернета. Если хочется увидеть эту механику на уровне одного конкретного пакета данных, а не абстрактной схемы, есть отдельный разбор — как маршрутизируется пакет от дома до сервера в США.

Прежде чем говорить — нужно "познакомиться": что такое BGP-сессия

Прежде чем два соседних почтовых отделения начнут обмениваться списками районов, у них должна быть договорённость: кто кому звонит, по какому номеру, как проверить, что на связи действительно нужное отделение, а не кто-то посторонний. В мире BGP эта договорённость называется BGP-сессией, а её начальный этап установления — тем самым хендшейком, о котором эта статья.

Технически BGP-сессия устанавливается между двумя маршрутизаторами, каждый из которых принадлежит своей автономной системе — например, граничный маршрутизатор вашего хостинг-провайдера и граничный маршрутизатор оператора связи, к которому этот провайдер подключён (upstream). Это не разовое действие, а постоянно поддерживаемая связь: пока сессия жива, стороны непрерывно обмениваются новостями о маршрутах; если сессия обрывается, все маршруты, полученные от этого соседа, снимаются с учёта, будто сосед разом перестал существовать.

Важно, что таких сессий у одного провайдера обычно не одна, а сразу несколько — с разными соседями (peers) и с разными вышестоящими операторами (upstream). Хендшейк проходит отдельно с каждым из них, и от того, сколько таких соседей и насколько они надёжны, зависит устойчивость сети провайдера в целом — тема, близкая к тому, зачем вообще нужен выделенный IP-адрес и как он привязан к конкретной подсети, за которую отвечает провайдер.

Из чего состоит сам хендшейк

BGP работает поверх обычного TCP-соединения на порт 179 — в этом смысле его хендшейк начинается точно так же, как любое TCP-соединение: обмен SYN/SYN-ACK/ACK, три пакета, устанавливающих транспортный канал между двумя маршрутизаторами. Но это только транспортная часть, "поднять трубку". Дальше начинается собственно BGP-хендшейк — согласование условий самого разговора о маршрутах.

Внутренне BGP-сессия проходит через несколько стадий (в документации это называется машиной состояний, BGP Finite State Machine), и практический смысл каждой стадии можно объяснить без формул:

• Idle — маршрутизатор ещё даже не пытается связаться с соседом, сессия просто настроена, но не активна.
• Connect — маршрутизатор пытается установить то самое TCP-соединение до адреса соседа.
• Active — TCP-соединение пока не удалось, идёт повторная попытка (или маршрутизатор ждёт входящего соединения от соседа).
• OpenSent — TCP-канал установлен, и сторона отправила сообщение OPEN — по сути "представление": какой у меня номер автономной системы (ASN), какой у меня router ID, с какой версией протокола и с какими дополнительными возможностями (capabilities) я готов работать — например, поддерживаю ли я IPv6-маршруты в дополнение к IPv4.
• OpenConfirm — сосед прислал в ответ своё OPEN-сообщение, и параметры совпали (или были приняты) — стороны как бы кивнули друг другу, подтвердив, что готовы к разговору по существу.
• Established — сессия установлена. С этого момента стороны обмениваются полными таблицами маршрутов, которые у них есть, и дальше — только изменениями (сообщениями UPDATE), плюс регулярными сообщениями KEEPALIVE, чтобы подтверждать, что канал жив, даже если никаких изменений маршрутов не произошло.

Именно переход от TCP-соединения через OpenSent и OpenConfirm до состояния Established и называют хендшейком BGP-сессии — это тот самый момент, когда две ранее незнакомые (или временно разошедшиеся) сети договариваются, что теперь будут доверять друг другу объявления маршрутов. На маршрутизаторе провайдера состояние сессии с соседом можно увидеть буквально одной командой — например, в FRRouting или Cisco это show bgp summary, а в BIRD — birdc show protocols, и напротив нужного соседа будет написано либо Established, либо одна из промежуточных стадий, либо счётчик времени с последнего сброса. Это команда, которая выполняется на пограничном маршрутизаторе оператора связи, а не на вашем арендованном VPS, — но полезно понимать, что за словом "сеть провайдера стабильна" стоит именно устойчиво держащееся состояние Established на нескольких таких сессиях одновременно.

Что происходит после того, как "познакомились"

Хендшейк — это только начало. Дальше, пока сессия жива, соседи обмениваются сообщениями UPDATE — в них перечисляются конкретные блоки адресов (префиксы, вида 198.51.100.0/24) и путь через какие автономные системы к ним нужно идти (AS-path). Получив такое сообщение, маршрутизатор записывает его в свою таблицу маршрутов и, если считает нужным, пересылает дальше — уже своим соседям, дописав себя в начало AS-path.

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

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

Почему обычный арендатор VPS с этим не работает напрямую

Здесь важно быть честным про уровень абстракции. Если вы арендуете отдельный VPS — даже с выделенным IP, даже с несколькими серверами под балансировщиком — вы в подавляющем большинстве случаев никогда не настраиваете BGP-сессию сами и не должны этого делать. Это зона ответственности:

• вашего хостинг-провайдера, у которого есть собственная автономная система и граничные маршрутизаторы;
• операторов связи (upstream), с которыми провайдер заключил договор о пиринге или транзите;
• операторов узлов обмена трафиком (Internet Exchange), через которые проходят многие такие сессии.

BGP настраивается на уровне сети провайдера в целом, а не на уровне отдельного арендованного сервера внутри неё. Ваш VPS получает свой IP-адрес из подсети, которую провайдер уже анонсировал через собственные BGP-сессии, — вам не нужно ничего "включать" на своей стороне, чтобы адрес стал видимым интернету. Исключение — редкий и специфичный случай, когда компания сама становится держателем собственного блока адресов и собственного номера AS и заключает прямые договоры о пиринге с операторами; это уровень сложности и масштаба, сильно превышающий типичную аренду VPS или даже выделенного сервера, и обычно требует отдельной инфраструктурной команды, а не одного администратора.

Так что если вы ищете, что именно настроить на своём сервере по поводу BGP, — короткий честный ответ: скорее всего ничего, это не ваш уровень абстракции. Ваша зона ответственности начинается там, где заканчивается работа глобальной маршрутизации: firewall, сетевые интерфейсы внутри самой машины, DNS-записи для вашего домена, и то, как ваше приложение слушает порты.

Зачем всё-таки полезно понимать эту механику

Раз вы не настраиваете BGP сами, зачем вообще в этом разбираться? Практическая польза в другом — понимание базовой механики помогает правильно интерпретировать симптомы, а не искать проблему не там.

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

Во-вторых, объясняет один специфичный трюк, о котором стоит знать хотя бы для общей картины: один и тот же IP-адрес физически может отвечать сразу из нескольких городов и стран одновременно — и обеспечивается это именно тем, что один и тот же префикс анонсируется через BGP из нескольких точек мира сразу, а маршрутизаторы по всему интернету сами выбирают ближайшую по факту работы протокола. Этот приём называется anycast, и подробный разбор механики — в статье как работает anycast и почему один IP отвечает из разных стран.

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

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