Перейти на главную Журналы

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 [59] 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124

Протокол Encapsulation Security Payload

Протокол Encapsulation Security Payload (ESP, Безопасного закрытия содержания) обеспечивает аутентификацию и проверку целостности датаграммы и шифрование данных в ней. В транспортном режиме (transport mode) этот протокол защищает данные и заголовки, созданные протоколами более высоких уровней (такими как TCP). Не реализует защиту заголовка IP-пакета. Данный режим обычно работает с соединениями узел-узел (или узел-шлюз) и совместим с маршрутизаторами, не понимающими протоколы из набора IPSec.

Какие поля заголовка IP-пакета защищает протокол АН?

1 С помощью криптографических алгоритмов протокол АН защищает все поля \ \ датаграммы IP, за исключением полей, изменяющихся в процессе передачи, ! например TTL. Это позволяет определить на принимающем конце, имеются ли \ изменения в какой-либо защищенной протоколом части датаграммы, напри-i мер в адресе отправителя или получателя.

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

Связь протоколов АН и ESP

Для канала, в котором нужна повышенная безопасность, протоколы АН и ESP могут применяться вместе. Это гарантирует аутентификацию, конфиденциальность и проверку целостности. При совместном использовании этих протоколов заголовок АН следует за заголовком IP, а затем идет IP-пакет, упакованный в пакет ESP

О последовательный номер - счетчик, увеличивающийся на единицу при пересылке очередного пакета по связи с определенным индексом SPI;

О данные аутентификации - данные пакета, например цифровая подпись. Это поле дополняется нулями так, чтобы его длина составляла целое число 32-битных слов.

С помощью заголовка АН можно выполнять аутентификацию и проверку целостности данных, передаваемых между двумя сотрудничающими сторонами, но его нельзя использовать для шифрования данных IP-пакета. Для этого предназначен другой протокол.



Протокол РРТР

Большинство пользователей, выходивших в Internet из дома, знакомы с расшифровкой аббревиатуры РРР - Point-to-Point Protocol (протокол соединения точка-точка). Этот протокол поддерживает связь с провайдером и обеспечивает работу других протоколов (таких как TCP/IP, IPX или NetBEUI) поверх существующего соединения. Протокол Point-to-Point Tunneling Protocol (РРТР, протокол тун-нелирования между узлами) построен на основе РРР, но включает в себя шифрование передаваемых данных. Это означает, что РРТР позволяет удаленными клиентами устанавливать виртуальное закрытое соединение с внутренней сетью офиса через Internet.

Достоинства протокола РРТР:

О создается зашифрованный канал связи поверх Internet; О поддерживаются различные сетевые протоколы, такие как TCP/IP, IPX или NetBEUI;

О его поддержка встроена в современные версии операционных систем Windows;

О он позволяет пользоваться частными IP-адресами, поскольку адрес соединению РРР присваивается провайдером; клиент в состоянии посылать поверх соединения пакеты по адресу внутренней сети.

Протокол РРТР первоначально был разработан Microsoft и несколькими другими компаниями. В 1996 году форум РРТР представил организации Internet Engineering Task Force (IETF, Комитет по инженерным вопросам Internet) проект стандарта в виде документа Internet Draft, а текущий стандарт протокола определен в документе RFC 2637 «Point-to-Point Tunneling Protocol (РРТР)».

В типичном сценарии удаленный клиент вначале подключается к локальному провайдеру Internet с помощью РРР (см. рис. 10.4). После создания этого соединения

Удаленный

Модем

Провайдер

пользователь

Internet


Защищенный при помощи РРТР маршрут

Обычный сетевой трафик

Сервер удаленного доступа

Рабочая станция

Рабочая станция

Сервер

Рис. 10.4. Удаленный клиент использует туннель РРТР между рабочей станцией и сервером RAS в локальной сети



Управляющий канал РРТР

Управляющие сообщения пересылаются между клиентом и сервером РРТР для создания туннеля РРТР и управления им. Хотя РРТР позволяет туннелировать поверх РРР различные сетевые протоколы, для сообщений управления служат ТСР-датаграммы. После установки ТСР-соединения между клиентом-и сервером TCP происходит обмен следующими управляющими сообщениями РРТР:

О Start-Control-Connection-Request (Запрос на создание управляющего канала); О Start-Control-Connection-Reply (Ответ на запрос о создании управляющего канала);

О Stop-Control-Connection-Request (Запрос на закрытие управляющего канала); О Stop-Control-Connection-Reply (Ответ на запрос о закрытии управляющего

канала); О Echo-Request (Эхо-запрос); О Echo-Reply (Эхо-ответ);

О Outgoing-Call-Request (Запрос исходящего вызова);

О Outgoing-Call-Reply (Ответ на запрос исходящего вызова);

О Incoming-Call-Request (Запрос входящего вызова);

О Incoming-Call-Reply (Ответ на запрос входящего вызова);

О Incoming-Call-Connected (Подтверждение установки входящего соединения);

О Call-Clear-Request (Запрос на отмену вызова);

О Call-Disconnect-Notify (Извещение о разрыве соединения);

О \VAN-Error-Notify (Извещение об ошибке глобальной сети);

О Set-Link-Info (Запись информации о канале).

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

Эхо-сообщения позволяют контролировать управляющий канал и обнаруживать отказ. Если в течение 60 с после эхо-запроса не приходит ответ, соединение разрывается.

поверх соединения РРР устанавливается соединение РРТР. Конечными точками соединения РРТР являются удаленный клиент и сервер Remote Access Server в локальной сети офиса. Соединение между удаленным клиентом и сервером RAS называется туннелем (tunnel). Все передаваемые между двумя конечными точками данные шифруются и защищаются протоколом РРТР. На сервере RAS пакеты РРТР распаковываются, а исходная 1Р-датаграмма (или датаграмма другого сетевого протокола) проверяется и пересылается адресату в локальной сети, обслуживаемой сервером RAS.

При установке защищенного соединения РРТР вначале формируется управляющий канал, после чего начинается передача данных.




0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 [59] 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124