Совместное использование протоколов L2TP и IPSec
Начальные записи в политике, необходимые для защиты SCCRQ
Добавление начальных записей на стороне Инициатора и Получателя необходимо для защиты SCCRQ, посылаемого Инициатором для открытия L2TP-туннеля. Как Инициатор, так и Получатель должны либо быть заранее сконфигурированы с этими дополнительными записями, либо в L2TP должен быть определен метод добавления этой информации в БД политик IPSec. В любом случае данные записи должны быть определены до того, как будет послано первое сообщение об установке L2TP-туннеля.
Записи на стороне Получателя:
Записи на стороне Получателя: | |||||
---|---|---|---|---|---|
Для исходящего трафика | Нет. Они должны быть динамически созданы IKE при успешном завершении фазы II. | ||||
Записи на стороне Инициатора: | |||||
Для исходящего трафика | from I-IPAddr | to R-IPAddr1 | UDP | src I-Port | dst 1701 |
Для входящего трафика | from R-IPAddr1 | to I-IPAddr | UDP | src 1701 | dst I-Port |
from R-IPAddr1 | to I-IPAddr | UDP | src Any-Port | dstI-Port |
Если Инициатор использует динамические порты, то L2TP должен вставить записи в БД политик IPSec после того, как стал известен номер порта источника. Если Инициатор использует фиксированный порт 1701, эти записи могут быть определены статически.
Определение Any-Port во второй записи для входящего трафика Инициатора необходимо для обработки потенциального изменения порта, которое может произойти в результате изменения номера порта Получателем.
Если на фазе II все еще нет SA для защиты SCCRQ, посылка SCCRQ Инициатором должна привести к тому, что IKE установит необходимые SA для защиты данного пакета. В качестве альтернативы L2TP может запросить IKE установить SA. Если по какой-то причине SA не может быть установлена, пакет должен быть отброшен.
Номера портов в ID Quick Mode, посылаемые Инициатором, должны содержать номера портов, используемые для идентификации UDP-сокета. Номера портов будут либо I-Port/1701, либо 1701/1701 для начального SCCRQ. ID Quick Mode, посылаемые Инициатором, являются подмножеством первой записи для входящего трафика на стороне Получателя. В результате этого после завершения обмена Quick Mode IKE должен вставить определенный набор записей в БД политик IPSec и связать этот набор записей с SA фазы II, установленной между участниками. Эти записи должны существовать до тех пор, пока существует L2TP-туннель. Новый набор записей на стороне Получателя будет:
Записи на стороне Получателя: | |||||
---|---|---|---|---|---|
Для исходящего трафика | from R-IPAddr1 | to I-IPAddr | UDP | src 1701 | dst I-Port |
Для входящего трафика | from I-IPAddr1 | to R-IPAddr11 | UDP 1 | src I-Port1 | dst 17011 |
from Any-Addr | to R-IPAddr1 | UDP | src Any-Port | dst 1701 |
Между L2TP и IPSec должны существовать такие механизмы, чтобы L2TP мог не передавать повторно SCCRQ, если SA уже установлена.
Механизмы повторной передачи в управляющем канале L2TP должны запускаться только после того, как SA уже установлена.
SCCRQ должно посылаться от Инициатора к Получателю только после того, как SA фазы II между участниками установлена.
Если Получатель не использует новый IP-адрес или порт, то установление L2TP-туннеля может быть продолжено.
Получатель выбрал новый IP-адрес
Опишем процесс, который выполняется, если Получатель решает ис-пользовать новый IP-адрес. После получения SCCRQ и перед отправлением SCCRP у Получателя существует единственная возможность изменить свой IP-адрес.
Новый адрес, который выбирает Получатель, должен быть указан в AVP Result и Error Code в STOPCCN сообщении. Сообщение STOPCCN посылается на тот же самый адрес и UDP-порт, которые Инициатор ис-пользовал для посылки SCCRQ. Данное сообщение будет защищено начальными SA, установленными для защиты SCCRQ.
При получении STOPCCN Инициатор должен извлечь IP-адрес и вста-вить новый набор записей в БД политик IPSec. Если используется аутентификация по предварительно распределенному секрету, L2TP может запросить IKE связать новый IP-адрес с этим секретом, который использовался для исходного IP-адреса.
Так как IP-адрес Получателя был изменен, то между участниками должны быть установлены новые SA фазы I и II до того, как будет послано новое SCCRQ.
В предположении, что начальный туннель был удален, а также удалены записи, необходимые для создания туннеля, новые записи Инициатора и Получателя будут следующие:
Записи на стороне Инициатора: | |||||
---|---|---|---|---|---|
Для исходящего трафика | from I-IPAddr | to R-IPAddr2 | UDP | src I-Port | dst 1701 |
Для входящего трафика | from R-IPAddr2 | to I-IPAddr | UDP | src 1701 | dst I-Port |
from R-IPAddr2 | to I-IPAddr | UDP | srcAny-Port | dstI-Port |
После того, как II фаза IKE завершится, новый набор записей у Полу-чателя будет следующим:
Записи на стороне Получателя: | |||||
---|---|---|---|---|---|
Для исходящего трафика | from R-IPAddr2 | to I-IPAddr | UDP | src 1701 | dst I-Port |
from Any-Addr | to R-IPAddr1 | UDP | src Any-Port | dst 1701 |
Если Получатель не изменил номер порта, то установка L2TP-туннеля может быть завершена.
Получатель выбрал новый номер порта
Получатель может решить использовать новый UDP-порт источника для трафика L2TP-туннеля. Это решение должно быть принято до посылки SCCRP. Если выбран новый номер порта, то L2TP должен вставить новые записи в БД политик IPSec. Получатель должен начать с Инициатором новую II фазу переговоров IKE.
Заключительный набор записей у Инициатора и Получателя следующий:
Записи на стороне Инициатора: | |||||
---|---|---|---|---|---|
Для исходящего трафика | from I-IPAddr | to R-IPAddr | UDP | src I-Port | dst R-Port |
from I-IPAddr | to R-IPAddr | UDP | src I-Port | dst 1701 | |
Для входящего трафика | from R-IPAddr | to I-IPAddr | UDP | src R-Port | dst I-Port |
from R-IPAddr | to I-IPAddr | UDP | src 1701 | dst I-Port | |
from R-IPAddr | to I-IPAddr | UDP | srcAny-Port | dstI-Port |
Первая запись для входящего трафика на стороне Инициатора будет добавлена IKE при успешном завершении II фазы переговоров, инициированных участником.
Записи на стороне Получателя: | |||||
---|---|---|---|---|---|
Для исходящего трафика | fromR-IPAddr | to I-IPAddr | UDP | srcR-Port | dstI-Port |
fromR-IPAddr | to I-IPAddr | UDP | src1701 | dstI-Port | |
Для входящего трафика | fromI-IPAddr | to R-IPAddr | UDP | srcI-Port | dstR-Port |
fromI-IPAddr | to R-IPAddr | UDP | srcI-Port | dst 1701 | |
fromAny-Addr | to R-IPAddr1 | UDP | srcAny-Port | dst 1701 |
После того, как переговоры завершены, посылается SCCRP, и установление L2TP-туннеля может быть завершено. После того, как L2TP-туннель установлен, любые оставшиеся SA и связанные с ними записи могут быть удалены.
Обсуждение топологий шлюз-шлюз и исходящего канала L2TP
В топологии шлюз-шлюз и исходящего канала L2TP каждая сторона может инициировать создание L2TP-канала. Эти сценарии отличаются от предыдущих единственным дополнением. Начальный набор правил на каждой стороне должен включать следующее правило:
Когда любая из сторон решит установить туннель, L2TP должен вставить необходимые входящий и исходящий правила для защиты SCCRQ. После этого установка туннеля полностью соответствует предыдущим сценариям.