Туннель покупает топологию, а не шифрование или задержку

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

Миф: один туннель, три гарантии

Туннель надёжно делает одну вещь. Он заставляет две конечные точки, не соединённые напрямую, вести себя как соседние для какой-то цели, пока промежуточная сеть передаёт внешние пакеты. Это изменение топологии, и само по себе оно действительно полезно.

Шифрование, перенос протоколов и изоляция пересылки — это отдельные решения, наложенные сверху. У туннеля GRE нет ни одного из трёх в криптографическом смысле, а туннель IP-in-IP — допустимый проект вообще без конфиденциальности. Ни то ни другое не ошибка; это туннели, делающие именно то, что делают туннели. Метка на схеме не говорит, какие свойства присутствуют.

Как только вы разделяете свойства, вопросы становятся отвечаемыми: несёт ли этот туннель соседство маршрутизации, несёт ли кадры, скрывает ли внутренние адреса, обещает ли что-то насчёт задержки? Это четыре разных ответа с четырьмя разными последствиями для настройки.

Что туннель на самом деле добавляет к карте

Конечные точки получают путь, которого у них раньше не было. Ведёт ли этот путь себя как маршрутизированный хоп или как сегмент Ethernet, целиком зависит от инкапсуляции, и разница меняет то, что две площадки могут с ним делать. Маршрутизированный туннель даёт следующий хоп и префикс; расширение Ethernet даёт широковещательное поведение и гораздо больший домен отказа.

Туннель IP не делает удалённую площадку автоматически частью той же подсети и не заставляет протокол маршрутизации работать через него, если реализация не поддерживает это соседство. Multicast — ещё один отдельный вопрос со своим ответом.

ip -d link show type gre
ip route get 10.20.0.5
traceroute -n -T -p 443 10.20.0.5
mtr -n --report -c 20 10.20.0.5

Эти команды отвечают на разные части вопроса. Первая говорит, какой тип интерфейса существует, вторая — какой путь выбрало бы ядро, а последние две показывают фактическое поведение нижнего уровня, а не обещание метки.

Перенос — отдельное решение от доступности

Туннель может переносить протокол, который нижний уровень не пересылает. IPv6 поверх пути IPv4 — классический случай, и он работает, потому что конечные точки понимают оба семейства, а маршрутизаторам между ними нужно только доставить внешние пакеты. Нижнему уровню нужен работающий путь до конца туннеля и ничего больше.

Однако конечным точкам нужна полная поддержка: пересылка, адреса и приложение, которое действительно использует внутреннее семейство. Назначение префикса IPv6 туннелю не делает сервис, работающий только с IPv4, доступным через IPv6 и не делает нижний уровень двухстековым.

Перенос кадров — большее обязательство, чем перенос протоколов. Расширение широковещательного домена через туннель перемещает вместе с ним поведение остовного дерева, ARP и распространение отказов, а это проектное решение, а не переключатель функции.

Изоляция — это не конфиденциальность

Провайдерские VPN держат маршруты и трафик клиентов в отдельных контекстах пересылки, и это разделение реально и ценно. Это не шифрование. Спецификация BGP/MPLS VPN прямо говорит, что конфиденциальность происходит из модели пересылки, а не из криптографии, и именно это различие теряется на слайде, который просто говорит VPN.

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

Практическое следствие в том, что «это в VPN» отвечает на вопрос о контексте маршрутизации и ничего не говорит о том, кто может читать байты на пути. Две команды могут обе быть правы и при этом описывать разные вещи. Когда возникает вопрос безопасности, спрашивайте где заканчивается криптография и что аутентифицирует партнёров, а не существует ли туннель.

Задержка и QoS следуют за нижним уровнем

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

Обработка качества обслуживания хуже этого, потому что зависит от административных доменов, которыми вы можете не управлять. Внутренние метки нужно намеренно отображать на внешние, и каждый провайдер на пути должен предлагать ожидаемую вами обработку. Шифрование не создаёт приоритет; оно скрывает поле, которое промежуточное устройство могло использовать для классификации потока.

Измерьте нижний уровень, прежде чем что-то обещать. Отчёт, показывающий стабильную задержку и отсутствие потерь на внешнем пути, — это доказательство; схема с туннелем на ней — нет.

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