1. 1 История tcpIP
 Скачать 340.83 Kb.
|
2.6 Сжатие данных в PPPПротокол PPP включает дополнительную функцию сжатия данных, которая позволяет повысить производительность на медленных последовательных линиях связи. Об использовании этой функции стороны могут договориться в процессе переговоров LCP. За настройку, активизацию и отключение алгоритмов сжатия на обоих концах канала PPP отвечает протокол Compression Control Protocol (CCP). Он использует механизм обмена пакетами, аналогичный LCP. Протокол CCP, так же как и NCP, начинает обмен пакетами в фазе пересылки дейтаграмм сетевого уровня (NETWORK). Процесс настройки сжатия и переговоров о параметрах выполняется с помощью пакетов Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject. Конфигурационные параметры, передаваемые в этих пакетах, специфичны для протокола CCP. Пакет Code-Reject отправляется в том случае, когда одна из сторон канала получила пакет CCP с неизвестным кодом. Два новых типа сообщений Reset-Request и Reset-Ack используются для прекращения сжатия в случае обнаружения проблем с восстановлением сжатых данных одной из сторон. Для завершения CCP одна из его сторон отправляет пакет Terminate-Request, на который другая сторона отвечает пакетом Terminate-Ack. Закрытие CCP не приведет к закрытию канала PPP. После того, как CCP перейдет в открытое состояние, РРР начинает передачу сжатых пакетов. Конфигурационные опции CCP позволяют договориться об алгоритмах сжатия и их параметрах. В настоящее время поддерживаются следующие алгоритмы сжатия: PPP Predictor Compression Protocol (RFC 1978); Puddle Jumper (RFC 1962); Hewlett-Packard PPC (RFC 1962); PPP Stac LZS Compression Protocol (RFC 1974); Microsoft Point-To-Point Compression (MPPC) Protocol (RFC 2118); PPP Gandalf FZA Compression Protocol (RFC 1993); V.42bis compression (RFC 1962); PPP BSD Compression Protocol (RFC 1977); PPP LZS-DCP Compression Protocol (LZS-DCP) (RFC 1967); PPP Deflate Protocol (RFC 1979). 2.7 Протоколы шифрования данных PPPПротоколы аутентификации гарантируют, что только авторизованные устройства могут установить соединение PPP. После установления соединения данные передаются по каналу в открытом виде. Шифрование данных, как и аутентификация, является опциональной функцией. Стороны могут договориться об используемом алгоритме шифрования с помощью протокола Encryption Control Protocol (ECP). Протокол ECP отвечает за конфигурацию и активацию алгоритмов шифрования на обоих концах канала PPP. Он использует механизм обмена пакетами аналогичный LCP, который начинается в фазе пересылки дейтаграмм сетевого уровня (NETWORK). Если используется аутентификация или выполняется проверка качества канала, протокол ECP должен ожидать завершения этих процессов. Аналогично LCP, протокол ECP выполняет установление, обслуживание и завершение канала. Для выполнения этих функций обе стороны канала обмениваются пакетами протокола ECP. Процесс установки канала и переговоров об алгоритмах шифрования и их параметрах выполняется с помощью пакетов Configure-Request, Configure-Ack, Configure-Nak и Configure-Reject, аналогичных LCP. Конфигурационные параметры, передаваемые в этих пакетах, специфичны для протокола ECP. Пакет Code-Reject отправляется в том случае, когда одна из сторон канала получила пакет ECP с неизвестным кодом. Два новых типа сообщений Reset-Request и Reset-Ack используются для прекращения шифрования в случае обнаружения проблем с дешифрованием одной из сторон. Для завершения ECP одна из его сторон отправляет пакет Terminate-Request, на который другая сторона отвечает пакетом Terminate-Ack. Закрытие ECP не приведет к закрытию канала PPP. После того, как ECP перейдет в открытое состояние, РРР начинает передачу шифрованных пакетов. Конфигурационные опции ECP используются для определения типа алгоритма шифрования, который будет использоваться сторонами. В настоящее время ECP поддерживает два алгоритма шифрования: 3DESE (RFF 2420 «The PPP Triple-DES Encryption Protocol (3DESE)») и DESE-bis (RFF 2419 «The PPP DES Encryption Protocol, Version 2 (DESE-bis)»). Также предусмотрена возможность использования собственных протоколов производителей. 2.7.1 Протокол шифрования МРРЕПротокол Microsoft Point-to-Point Encryption (МРРЕ) разработан компанией Microsoft для шифрования пакетов РРР (RFC 3078). MPPE работает как подфункция протокола Microsoft Point-To-Point Compression (MPPC). Этот протокол служит для сжатия данных при их передаче по каналу PPP. MPPC является опцией протокола Compression Control Protocol, поэтому переговоры о параметрах MPPE происходят внутри опции 18 протокола CCP. Для обеспечения конфиденциальности данных в протоколе используется алгоритм шифрования RC4. В настоящее время MPPE поддерживает сессионные ключи, длиной 40, 56 и 128 бит. Стороны могут договориться о длине ключа, используемой для шифрования в процессе переговоров. Инициатор переговоров отправляет сообщение Configure-Request и указывает в опциях все алгоритмы, которые он поддерживает. Получатель отвечает сообщением Configure-Nak с единственной установленной опцией. Если получатель поддерживает несколько алгоритмов шифрования, то указывается наиболее сильный. Затем инициатор должен либо отправить другой запрос Configure-Request, содержащий ту же самую опцию, что и в полученном сообщении Configure-Nak, либо прервать переговоры и сбросить соединение. В случае согласия с конфигурацией, получатель отправляет сообщение Configure-Ack. MPPE требует использования ключей шифрования, генерируемых в процессе аутентификации по протоколу MS-CHAP v1, MS-CHAP v2 или EAP-TLS (Extensible Authentication Protocol-Transport Level Security). Чтобы включить шифрование данных с использованием MPPE, на устройствах необходимо активизировать проверку подлинности по протоколу MS-CHAP v1, MS-CHAP v2 или EAP-TLS. Все эти методы проверки подлинности генерируют ключи на основе пароля пользователя. Для того чтобы передавать зашифрованные с помощью МРРЕ пакеты, протокол РРР должен перейти в состояние обмена дейтаграммами сетевого уровня. В поле Информация кадра РРР инкапсулируется одна МРРЕ-дейтаграмма. Для всех зашифрованных дейтаграмм в поле Протокол указан тип 0х00FD. Внимание: протокол MPPE имеет известные принципиальные уязвимости, позволяющие взломать его. Поэтому он обеспечивает весьма слабую защиту и его не рекомендуется использовать для шифрования критически важных данных. Виртуальные частные сети (Virtual Private Network, VPN) широко используются для организации подключения пользователей к сетям провайдеров услуг, доступа удаленных пользователей в локальную сеть или соединения удаленных локальных сетей одной организации. VPN — это набор технологий, которые позволяют создавать логические сети, использующие сети других сетевых протоколов в качестве транспорта. VPN-соединения могут создаваться на различных уровнях модели OSI. Создаваемая логическая сеть не обязательно должна быть маршрутизируемой, она может обеспечивать соединение типа «точка-точка». Характеристики безопасности созданной логической сети могут отличаться от характеристик безопасности транспортной сети. При создании VPN всегда следует помнить, что безопасность компьютерной системы и сетевого трафика зависит от многих факторов. Развертывание VPN с использованием той или иной технологии является только частью комплексного подхода к обеспечению безопасности. Безопасность, обеспечиваемая VPN, зависит от многих параметров операционного окружения, в котором VPN выполняется. Например, от безопасности ОС, источника случайных чисел, способов управления системой и т. д. Виртуальные частные сети второго уровня модели OSI представлены соединениями PPP over Ethernet (PPPoE), PPP over AAL5 (PPPoA), Point-to-Point Tunneling Protocol (PPTP) и Layer Two Tunneling Protocol (L2TP). Эти протоколы представляют собой расширения PPP, позволяющие устанавливать соединения «точка-точка» через сети Ethernet, ATM и IP. Все эти протоколы имеют ряд свойств, унаследованных от PPP: Соединения имеют сеансовый, а не статический, характер. При установке PPP-соединения может быть выполнена аутентификация и авторизация (односторонняя или взаимная), а по мере работы — учет работы пользователей. Для этих целей может быть использована локальная база данных пользователей или централизованные серверы TACACS+ и RADIUS. При установке IP-соединения могут быть согласованы параметры IP. При передаче трафика может использоваться сжатие с использованием различных методов, а также защита по протоколу MPPE. Перечисленные свойства полностью решают задачи, определяющие сущность VPN: аутентификацию сторон, обеспечение целостности данных и защиту от несанкционированного доступа к ним. Протоколы PPPoE, PPTP и L2TP широко применяются в сетях доступа для аутентификации, авторизации и учета работы клиентов городских и домовых сетей Ethernet и xDSL. PPTP и L2TP также удобны для решения задач удаленного доступа сотрудников к корпоративной сети и соединения локальных сетей головного офиса и филиалов через сети общего пользования (как проводные, так и беспроводные). После подключения к Интернет, клиентское устройство доступа инициирует со своей стороны установление туннеля до центрального маршрутизатора корпоративной сети. Через этот туннель узлы, расположенные в головном офисе, уже могут инициировать взаимодействие с филиалом. Существенное отличие PPPoE, PPPoA, PPTP и L2TP от PPP заключается в том, что эти протоколы — асимметричные, т. е. основаны на четком разделении ролей клиента и сервера. Клиент всегда инициирует соединение со своей стороны, сервер находится в режиме пассивного ожидания соединений. Как правило, сервер динамически назначает клиенту параметры IP. 2.9 Передача PPP через Ethernet Современные технологии доступа предназначены для нескольких конфликтующих друг с другом целей. С одной стороны желательно установить соединение с несколькими узлами через одно и то же устройство доступа. С другой стороны необходимо обеспечить управление доступом и возможности биллинга, аналогичные Dial-Up сервисам, использующим РРР. Во многих технологиях доступа подключение нескольких узлов к устройству доступа выполняется через Ethernet. Протокол Point-to-Point Protocol over Ethernet (PPPoE) обеспечивает способ передачи кадров РРР через сеть Ethernet и позволяет подключать сетевые узлы локальной сети через одно абонентское устройство к концентратору доступа (Access Concentrator, AC), расположенному на стороне провайдера.
Основную идею PPPoE можно объяснить следующим образом. Он моделирует телефонное соединение, в котором каждая сессия PPP трактуется как отдельная телефонная линия. Чтобы обеспечить соединение «точка-точка» через Ethernet, каждая сессия PPP должна знать МАС-адрес удаленного узла и установить уникальный идентификатор сессии. Эти задачи в РРРоЕ выполняет протокол обнаружения. В то же время PPPoE не позволяет пользователю постоянно оставаться на связи. Он должен сообщать свое имя и пароль каждый раз, когда хочет подключиться к сети. Протокол PPPoE использует клиент-серверную модель. Сервером является концентратор доступа. Роль клиента может исполнять узел или абонентское устройство, которым обычно является маршрутизатор. В связи с этим существуют две сетевые модели PPPoE: Сессия PPP устанавливается между узлом, подключенным к абонентскому устройству, и сервером PPPoE. На узле должно быть установлено программное обеспечение клиента PPPoE. В настройках клиента PPPoE указываются имя пользователя и пароль, предоставленные провайдером. Маршрутизатор работает в качестве прозрачного моста (RFC 1483 bridging), т. е. передает кадры от узла в сеть провайдера. Для этого в его настройках надо активировать функцию PPPoE pass through (Проброс PPPoE). Эта функция разрешает маршрутизатору пропускать PPPoE-трафик из локальной сети и в нее. Если в сети несколько узлов, и каждый из них надо подключить в Интернет, то провайдер должен назначить каждому узлу индивидуальные имя пользователя и пароль. Сессия PPP будет устанавливаться между каждым узлом и сервером доступа. Данная сетевая модель обычно используется для организации доступа в Интернет одного узла, т. к. подключение множества узлов требует от администратора значительных временных затрат на настройку, мониторинг и контроль каждого из них, а также увеличивает стоимость подключения. Сессия PPP устанавливается между абонентским устройством и концентратором доступа провайдера. В этой модели роль клиента PPPoE исполняет абонентское устройство. Другими словами, PPPoE-клиент реализован в маршрутизаторе. Такой режим его работы называется «режимом маршрутизации» (RFC 1483 routing). Все узлы локальной сети, подключающиеся к маршрутизатору по Ethernet или Wi-Fi, передают данные, используя одно PPPoE-соединение, которое установлено между ним и концентратором доступа. В настройках PPPoE-соединения на маршрутизаторе указываются имя пользователя и пароль, предоставленные провайдером. При этом не требуется, чтобы на узлах было установлено программное обеспечение PPPoE-клиента. Решение о перенаправлении пакетов маршрутизатор принимает на основе информации, хранимой в его таблице маршрутизации. Данная сетевая модель используется при подключении в Интернет множества устройств с использованием одной учетной записи. Метод доступа PPPoE получил широкое распространение у провайдеров. Так как каждый клиент идентифицируется собственным именем и паролем провайдеры могут выполнять управление доступом, биллинг, предоставление различных типов сервиса для каждого пользователя в отдельности. Формат пакета PPPoE Пакет PPPoE представляет собой кадр PPP инкапсулированный в кадр Ethernet. Перечислим поля пакета: Поле DESTINATION_ADDR содержит уникальный адрес Ethernet получателя или широковещательный адрес Ethernet (0xffffffffffff). Для пакетов стадии Discovery это поле является или уникальным или широковещательным адресом. Клиент PPPoE использует широковещательный адрес для обнаружения сервера PPPoE. После обнаружения сервера, для передачи трафика сессии PPP используется уникальный адрес, определенный во время стадии Discovery. Поле SOURCE_ADDR содержит MAC-адрес устройства-отправителя. Поле ETHER_TYPE имеет значения 0x8863 (стадия Discovery) или 0x8864 (стадия PPP Session). В поле данных кадра Ethernet (payload) помещен пакет PPPoE. Он имеет следующие поля: Поле VER, длиной 4 бита, определяет версию протокола PPPoE и должно иметь значение 0x1. Поле TYPE, длиной 4 бита, имеет значение 0x1 для данной версии спецификации PPPoE. Поле CODE, длиной 8 битов, определяет типы пакетов, отправляемых в процессе выполнения стадий Discovery и PPP Session. Поле SESSION_ID имеет длину 16 битов. Оно определяет уникальный идентификатор сессии PPP. Значение поля фиксировано для каждой сессии и фактически определяет PPP-сессию наряду с полями SOURCE_ADDR и DESTINATION_ADDR. Значение 0xffff зарезервировано на будущее и не используется. Поле LENGTH имеет длину 16 битов и определяет длину поля данных (payload) пакета PPPoE. Оно не включает длины заголовков Ethernet и PPPoE. Содержимое поля payload зависит от выполняемой стадии. В стадии Discovery оно содержит ноль или более атрибутов, называемых тегами (TAG). В стадии PPP Session оно содержит кадр PPP. |