RFC: 4306
Оригинал: Internet Key Exchange (IKEv2) Protocol
Другие версии: RFC 2407, RFC 2408, RFC 2409, RFC 5996
Категория: Предложенный стандарт
Дата публикации:
Автор:
Перевод: Николай Малых

RFC 4306, Страница 4 из 62

1.1.3. Туннель между конечной точкой и защитным шлюзом

В этом сценарии защищенная конечная точка (обычно портативный компьютер) подключается к корпоративной сети с использованием защищенного туннеля IPsec. Туннель может использоваться только для доступа к информации, хранящейся в корпоративной сети, или служить для передачи всего трафика портативного компьютера через офисную сеть для обеспечения возможности использования корпоративного межсетевого экрана, защищающего компьютер от атак из сети Internet. В любом случае защищенной точке будет нужен IP-связанный с защитным шлюзом, чтобы адресованные этой точке пакеты попадали на защитный шлюз и передавались им через туннель на защищенную точку. Этот алрес может выделяться защитным шлюзом статически или динамически. Во втором случае IKEv2 включает механизм, с помощью которого инициатор соединения запрашивает адрес IP, принадлежащий шлюзу, для использования в течение срока действия SA.

+-+-+-+-+-+-+                          +-+-+-+-+-+
!           !         Туннель          !Конечная !     Защищенная
!Защищенная !          IPsec           !  точка  !     подсеть
!   точка   !<------------------------>! туннеля !<--- и/или
!           !                          !         !     Internet
+-+-+-+-+-+-+                          +-+-+-+-+-+
Рисунок 3: Туннель между конечной точкой и защитным шлюзом

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

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

1.1.4. Другие сценарии

Возможны и другие сценарии, представляющие собой комбинации перечисленных выше вариантов. Один примечательный вариант объединяет в сете аспекты 1.1.1 и 1.1.3. Подсеть может организовать весь доступ наружу через удаленный защитный шлюз, используя туннель IPsec и тогда внешние сети (Internet) будут маршрутизировать пакеты для подсети защитному шлюзу. Например, некая домашняя сеть может виртуально представляться в сети Internet статическими адресами IP, несмотря на то, что эта сеть подключена через ISP, который выделяет один динамический адрес пользовательскому защитному шлюзу (видимый в Internet Internet Internet Internet статический адрес IP и трансляция IPsec обеспечивается третьей стороной, расположенной в другом месте).

Страница 4 из 62

2007 - 2022 © Русские переводы RFC, IETF, ISOC.