Вспомогательные механизмы

Работа хоста с несколькими подключениями

Мы завершим нашу умозрительную работу над основами IPv6, рассмотрев такой простой вопрос: каким образом хост IPv6 с несколькими сетевыми подключениями сможет эффективно использовать их? Ведь до сих пор мы старательно закладывали фундамент для ответа на этот вопрос, но от самого ответа столь же старательно уходили.

Чтобы в полной мере оценить значение этого вопроса, давайте мысленно вернемся во времена господства IPv4 и посмотрим, как тогда обеспечивали отказоустойчивое подключение отдельной сети к Internet.

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

Если сеть принадлежала достаточно крупному провайдеру, у которого были статус LIR, автономная система и прочие атрибуты серьезного игрока в этом бизнесе, то сеть объявляла о себе с помощью BGP, и все образовывалось как бы само собой. Это вполне устоявшаяся схема, и LIR IPv6 сообщают о себе точно так же при помощи MBGP.

Но что если сеть принадлежала абстрактной организации, применявшей свои подключения к Internet для сугубо внутренних целей? Пока адреса IPv4 еще были относительно доступны, такая организация могла получить прямиком из рук RIR автономную систему и отдельный блок адресов, не привязанный к определенному провайдеру ,^{6 Известный как PI (Provider Independent).} после чего подключиться к нескольким провайдерам и, по взаимному с ними соглашению, объявить о себе по BGP. Альтернативой этому было получение блока адресов из пространства провайдера №1 и анонсирование этого блока, по соглашению с провайдером №1, прочими провайдерами той же организации. Независимо от выбранного пути, глобальным следствием этой практики было дробление адресного пространства и рост числа маршрутов в глобальном облаке Internet. Ведь каждая такая сеть была представлена, как минимум, одним маршрутом, а число независимых сетей может на порядки превышать число провайдеров. Неудивительно, что независимые сети попали в немилость современных политик распределения адресов IPv6, принятых RIR.

Самая "интересная" участь ожидала те сети, которые не были достаточно велики или весомы, чтобы оказаться представленными в глобальном облаке маршрутизации Internet. Им не оставалось ничего иного, кроме как подключиться к нескольким провайдерам, получить от каждого из них по блоку адресов и после этого заняться сооружением пирамиды из различных ухищрений, чтобы обеспечить работу сети по нескольким подключениям. Вот лишь краткий и неполный список препятствий, которые им приходилось преодолевать:

• Один провайдер вряд ли пропустит от клиента транзитный трафик, адрес источника в котором принадлежит другому провайдеру. Это вполне обоснованное ограничение в рамках борьбы с подделкой адресной информации.
• Отказоустойчивость на входе, например, для публично доступного сервера внутри сети, можно обеспечить, назначив ему и опубликовав в DNS адреса от разных провайдеров. Однако тогда надо следить, чтобы ответный трафик возвращался в соответствующее подключение — иначе см. первый пункт. Так как обычная маршрутизация не учитывает адрес источника пакета, приходится использовать нестандартные трюки, например, маршрутизацию согласно политике.
• Отказоустойчивость на выходе, чтобы пользователи сети сохранили доступ к Internet при отказе одного из подключений, возможна только путем сочетания NAT и каких-то доморощенных механизмов наблюдения за состоянием подключений в стиле: "Ping на Google не прошел, значит, провайдер "упал". Переключаем default route…" Ведь у каждого пользовательского хоста IPv4 всего один адрес.

Но даже эти ухищрения обладали весьма ограниченными возможностями. В частности, никакими трюками нельзя было сохранить обычное соединение TCP при переключении между провайдерами, потому что менялся локальный адрес сокета. В результате, чем меньше была сеть, тем трудней ей давалось надежное подключение к Internet.

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

Поставим себя на место владельца хоста IPv6, которому необходимо надежное подключение к Internet, работоспособность которого не зависит от одного провайдера. Как бы мы поступили в этой ситуации?

Первый вариант (рис. 9.6) состоит в том, чтобы установить два (или больше) сетевых интерфейса и одновременно подключиться к двум (или больше) разным провайдерам (в надежде, что они независимы). При этом каждый сетевой интерфейс получит адрес из блока соответствующего провайдера. Эталонный хост IPv6 на базовом уровне уже готов к работе в такой конфигурации, потому что с каждым его интерфейсом связан отдельный список маршрутизаторов по умолчанию.

Рис. 9.6. Множественное подключение по разным каналам

Второй вариант (рис. 9.7) возможен, если есть канал, на котором уже присутствуют маршрутизаторы нескольких провайдеров (или маршрутизаторы, подключенные к разным провайдерам). Тогда достаточно подключить хост к одному каналу, но назначить его сетевому интерфейсу несколько адресов, по одному от каждого провайдера. В этом случае у хоста будет всего один список маршрутизаторов по умолчанию, но в нем будут представлены все провайдеры.

Рис. 9.7. Множественное подключение по одному каналу