L2TP, GRE или IPsec: какой уровень должен нести сессию?

Два вопроса путаются, как только L2TP, GRE и IPsec попадают в одну проектную заметку: какую сессию я несу и какой уровень её защищает? Ошибка в первом оставляет всё ниже по цепочке внутренне согласованным, пока решается не та задача — маршрутизируемое наложение, построенное там, где пользователям нужно было дозваниваться, или концентратор удалённого доступа вместо шлюза между площадками. Таблица ниже заставляет провести это различие до того, как кто-то войдёт на устройство. Заполните её по порядку, и каждая строка станет тем, что можно проверить отдельно.

Начните с сессии, а не со списка протоколов

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

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

Дайте каждому уровню ровно одну задачу

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

GRE — это инкапсуляция между двумя адресами. Она несёт пакеты сетевого уровня через логическое наложение и сама по себе не даёт ни конфиденциальности, ни аутентифицированной идентичности узла. Это не дефект: заголовок спроектирован простым, чтобы оставаться дешёвым в обработке на оборудовании пересылки. Следствие в том, что GRE отвечает на вопрос «как переместить этот пакет между двумя адресами» и ни на что больше — ровно тот вопрос, который ему стоит задавать.

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

Опишите путь пакета до конфигурации

Возьмите один пакет и перечислите каждый добавляемый заголовок в порядке добавления, называя устройство, которое его добавляет. Для удалённого пользователя это обычно PPP внутри L2TP внутри IPsec; для наложения площадок — внутренний пакет IP внутри GRE внутри IPsec. Если два устройства добавляют один и тот же заголовок, у вас петля или дублированный туннель, и никакое изменение политики это не исправит.

Тот же список решает вопрос MTU, потому что полезный внутренний размер — это измеренный MTU пути минус только что перечисленные заголовки и ничего больше. Не копируйте число из сообщения на форуме: сложите накладные расходы внешнего IP, UDP и ESP, затем GRE или L2TP, затем PPP там, где он применяется, и вычтите из MTU пути, который вы действительно измерили. Симптомы, появляющиеся только при больших передачах, или сессии, которые устанавливаются и затем умирают на первом большом ответе, обычно восходят к тому, что это сложение сделали на глаз.

Проверяйте каждый уровень отдельно, снаружи внутрь

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

ip xfrm state                  # is the IPsec SA up?
ip -s link show gre1           # does the overlay interface carry packets?
ip route get 10.20.0.5         # does the inner prefix route where you think?
ss -lun | grep -E "1701|4500"  # are the L2TP and NAT-T listeners bound?

На оборудовании Cisco эквивалент зависит от роли, а точный синтаксис зависит от платформы и версии: show crypto session для узлов IPsec, счётчики интерфейса для интерфейса GRE или туннеля и проверка VPDN или PPP для роли удалённого доступа. Набор команд, завершающий PPP, ничего не доказывает о поддержке GRE, а работающий интерфейс GRE ничего не доказывает о службе PPP, поэтому проверяйте роль, которую вы действительно настроили, а не ту, что на схеме.

Записывайте каждый вывод рядом со строкой таблицы, к которой он относится. Заметки, сделанные пока сбой активен, ценнее топологии, перерисованной потом по памяти.

Упорядочьте демонтаж, затем проверьте снова

Демонтаж идёт в обратном порядке не случайно: уберите защищённый трафик из политики IPsec, прежде чем удалять инкапсуляцию, для которой она написана, иначе политика продолжит указывать на интерфейс, которого больше нет, и следующая загрузка конфигурации упадёт в месте, которое выглядит несвязанным. В Linux это означает удалить записи состояния и политики до интерфейса туннеля; на маршрутизаторе — удалить запись crypto map или профиля до туннеля.

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

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