stringtranslate.com

Протокол управления портом

Протокол управления портами ( PCP ) — это сетевой протокол , который позволяет хостам в сетях IPv4 или IPv6 контролировать, как входящие пакеты IPv4 или IPv6 преобразуются и пересылаются маршрутизатором восходящего потока , который выполняет преобразование сетевых адресов (NAT) или фильтрацию пакетов . Позволяя хостам создавать явные правила переадресации портов , можно легко настроить обработку сетевого трафика, чтобы сделать хосты, размещенные за NAT или брандмауэрами, доступными из остальной части Интернета (чтобы они также могли действовать как сетевые серверы ), что является требованием для многих приложений. [1] [2]

Кроме того, явные правила переадресации портов, доступные через PCP, позволяют хостам сократить объем генерируемого трафика за счет устранения обходных путей в виде исходящих сообщений NAT keepalive , которые требуются для поддержания соединений с серверами и для различных методов обхода NAT, таких как TCP hole punching . В то же время, меньше генерируемого трафика снижает потребление энергии , напрямую улучшая время работы батареи мобильных устройств . [1]

PCP был стандартизирован в 2013 году как преемник протокола NAT Port Mapping Protocol (NAT-PMP), с которым он разделяет схожие концепции протокола и форматы пакетов. [3] PCP добавляет поддержку IPv6 и дополнительных сценариев NAT.

В средах, где в локальной сети используется UPnP IGD , необходимо, чтобы функция взаимодействия между UPnP IGD и PCP была встроена в IGD. Функция взаимодействия UPnP IGD-PCP указана в RFC6970. [4]

Параметры DHCP (IPv4 и IPv6) для настройки хостов с IP-адресами сервера протокола управления портами (PCP) указаны в RFC7291. [5] Процедура выбора сервера из списка серверов PCP обсуждается в RFC7488. [6]

В средах, где развернут NAT64, PCP позволяет узнать префикс(ы) IPv6, используемые устройством NAT64, контролируемым PCP, для создания преобразованных в IPv4 адресов IPv6 с помощью NAT64 (RFC7225). [7]

Обзор

Многие приложения и сетевое оборудование требуют, чтобы их сетевые местоположения были доступны из-за пределов их локальных сетей , следуя изначально задуманной модели сквозного IP- подключения через Интернет, чтобы они могли работать как сетевые серверы и принимать соединения от удаленных клиентов . Примером такого оборудования является IP-камера , которая включает сетевой сервер, обеспечивающий удаленное наблюдение по IP-сетям.

Обычно при развертывании сетевого оборудования устройства размещаются за маршрутизаторами или брандмауэрами, которые выполняют NAT ( например, для обеспечения совместного использования адреса IPv4 ) или фильтрацию пакетов (для повышения безопасности и защиты сети ), что в конечном итоге приводит к разрыву сквозного соединения и делает оборудование и приложения недоступными для остальной части Интернета. [1] [3]

Проблема

Обеспечение доступности развернутого оборудования путем расширения его роли сервера за пределы локальной сети требует либо ручной настройки переадресации портов на сетевом шлюзе (который обычно является CPE ), либо обходных путей на уровне приложений, которые инициируют соединения с развернутого оборудования на дополнительные промежуточные серверы, используемые для «слияния» этих «брандмауэрных» соединений и соединений от реальных клиентов. Оба подхода имеют свои недостатки — ручная настройка CPE обычно либо неудобна, либо невозможна, в то время как использование дополнительных промежуточных серверов увеличивает сложность и стоимость. [2] [3]

Например, онлайн-компьютерная игра (которая действует как клиент) требует связи с игровым сервером для обмена игровыми данными. Для того чтобы игровой сервер мог предоставлять данные своим клиентам, эти клиенты должны быть доступны серверу. Обычно клиенты инициируют соединения с игровым сервером для открытия каналов связи. Однако такие открытые соединения могут стать неактивными и впоследствии могут быть закрыты сетевыми шлюзами, что приводит к необходимости их поддержания с помощью формы сообщений keepalive. [3] Сообщения keepalive — это небольшие сообщения, которые отправляются между клиентом и сервером, которые создают трафик по каналу связи и, следовательно, не позволяют серверам шлюзов закрывать его. Таким образом, поддержание соединения в активном состоянии требует постоянного обмена пустыми сообщениями между клиентом и сервером. Это увеличивает сетевой шум, тратит пропускную способность сети и циклы ЦП , а также снижает автономность устройств с питанием от батареи .

Кроме того, некоторые сетевые приложения (например, FTP ) требуют динамического открытия нескольких соединений, что подразумевает использование шлюзов уровня приложений (ALG) и дополнительно увеличивает сложность. [2] [3]

PCP как решение

PCP позволяет оборудованию и приложениям создавать явные сопоставления между внешним IP-адресом , протоколом и портом и внутренним IP-адресом, протоколом и портом. При наличии таких явных сопоставлений входящая связь может достигать хостов за NAT или брандмауэром, что либо расширяет их серверные роли за пределы границ локальных сетей, либо упрощает использование различных служб и делает их менее ресурсоемкими. Созданные сопоставления являются постоянными в той мере, в какой они имеют известный срок службы, который может быть продлен, что аналогично тому, как протокол динамической конфигурации хоста (DHCP) реализует свои аренды . В то же время PCP позволяет приложениям динамически создавать дополнительные сопоставления по мере необходимости, что снижает или устраняет необходимость в наличии устройств NAT и брандмауэров с поддержкой ALG . [1] [3]

Созданные явные сопоставления имеют известный срок службы, обычно несколько часов, без необходимости обмена сообщениями keepalive на уровне приложений между хостами и серверами с целью сохранения сопоставления. В результате использование сети и энергопотребление сокращаются, а логика keepalive на уровне приложений больше не нуждается в реализации на стороне клиента и сервера. Ответ сопоставления PCP предоставляет приложению связанные с ним внешне видимые параметры (IP-адрес, протокол и порт), которые затем могут быть объявлены другим клиентам способами, специфичными для приложения, чтобы можно было устанавливать входящие соединения. Кроме того, PCP может информировать приложения об изменении внешнего IP-адреса, когда сопоставление уже установлено. [1] [3]

PCP может обрабатывать различные типы NAT, обеспечивая поддержку NAT64 , NAT66 и NAT44 ; также поддерживается включение PCP в устройства брандмауэра IPv4 и IPv6. PCP предназначен для использования как в крупномасштабных точках агрегации (например, как часть NAT операторского класса ), так и внутри менее дорогих устройств потребительского класса . Поддерживаются как долгосрочные (например, для IP-камеры или датчика температуры, действующего как сервер), так и краткосрочные сопоставления (например, во время игры в онлайн-компьютерную игру). [1] [2] [3]

PCP поддерживает протоколы транспортного уровня , которые используют 16-битные номера портов (например, TCP , UDP , Stream Control Transmission Protocol (SCTP) или Datagram Congestion Control Protocol (DCCP). Протоколы, которые не используют номера портов (например, Resource Reservation Protocol (RSVP), Encapsulating Security Payload (ESP), ICMP или ICMPv6 ), поддерживаются для функций брандмауэра IPv4, брандмауэра IPv6 и NPTv6 (трансляция префикса IPv6), но не могут поддерживаться более чем одним клиентом на внешний IP-адрес в случае NAT. [3]

Спецификация PCP не определяет механизм для работы с многосетевыми сетями (которые имеют несколько сетевых шлюзов или маршрутов по умолчанию ). Тем не менее, возможно реализовать PCP в таких сетях с помощью механизма координации, такого как conntrackd . Однако, если разные сети имеют свои собственные внешние IP-адреса, заданное сопоставление PCP может использовать только один или другой, поскольку протокол требует предоставления клиенту одного определенного внешнего IP-адреса. Если эта сеть затем станет недоступной, сопоставление PCP должно быть обновлено для использования внешнего IP-адреса из другой сети. [3]

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

История

PCP был стандартизирован в 2013 году как преемник протокола NAT Port Mapping Protocol ( NAT-PMP ), разделяя с ним схожие концепции протокола и форматы пакетов. Одним из отличий дизайна является то, что NAT-PMP в значительной степени ограничен развертыванием на потребительских устройствах, в то время как PCP также предназначен для поддержки оборудования операторского класса . [3] : 50, 87  С 2005 года NAT-PMP был реализован в различных продуктах Apple . [8] : 1 

PCP относится к протоколу шлюза Интернета (UPnP IGD), который был стандартизирован в 2001 году как часть спецификации UPnP . В то время как UPnP IGD сложен и рассчитан на ручную настройку, PCP разработан для простоты и автоматизированного использования в программных приложениях. Спецификация NAT-PMP содержит список проблем с UPnP IGD, которые побудили создать NAT-PMP, а затем и его преемника PCP. [8] : 26–32 

использование ПХФ

Безопасность

За исключением злоумышленников, способных изменять сетевые пакеты, которыми обмениваются во время создания явного сопоставления PCP (пакеты, которые содержат согласование, необходимое для установления явного сопоставления, которым обмениваются хосты и устройства NAT с поддержкой PCP или брандмауэры), PCP считается безопасным, пока созданные явные сопоставления не выходят за рамки неявных сопоставлений. Другими словами, неявные сопоставления создаются в результате того, как устройства NAT и брандмауэры обрабатывают обычные исходящие клиентские соединения, что означает, что PCP безопасен, пока не вводятся новые возможности сопоставления посредством механизма явного сопоставления. [3]

С точки зрения безопасности важной функцией PCP является опция запроса сопоставления THIRD_PARTY . При использовании эта опция означает, что IP-адрес, указанный дополнительно как часть запроса сопоставления, должен использоваться в качестве внутреннего адреса для созданного явного сопоставления, а не следовать поведению по умолчанию, используя исходный IP-адрес фактического пакета запроса сопоставления для этой цели. Такие запросы сопоставления могут закончиться тем, что устройство NAT или брандмауэр с поддержкой PCP предоставит явные привилегии сопоставления выше, чем разрешено неявными сопоставлениями из-за неизвестных правил, наложенных в другом месте для указанного IP-адреса, что позволит злоумышленнику украсть часть трафика или провести атаку типа « отказ в обслуживании» (DoS). [3]

Кроме того, явные механизмы безопасности PCP доступны как расширения протокола PCP, предоставляя механизмы аутентификации и контроля доступа с использованием аутентифицированного и защищенного целостностью внутриполосного канала сигнализации, который опирается на расширяемый протокол аутентификации (EAP) для выполнения аутентификации между устройствами, участвующими в сеансе переговоров PCP. Такие устройства NAT или брандмауэры с поддержкой PCP могут по-прежнему принимать неаутентифицированные запросы на сопоставление; в то же время все ранее описанные явные ограничения сопоставления по-прежнему применяются. [1] [3] [11]

Внутренности

Внутри PCP работает путем обмена управляющими сообщениями между хостами и устройствами NAT с поддержкой PCP или брандмауэрами (называемыми серверами), используя протокол пользовательских датаграмм (UDP) в качестве базового протокола. Это взаимодействие состоит из запросов на сопоставление портов, создаваемых хостами, которые приводят к ответам , отправленным и обработанным серверами. Следуя природе ненадежности UDP, которая означает, что датаграммы UDP могут быть потеряны, продублированы или переупорядочены, после отправки запроса нет никакой гарантии на ответ любого рода, поэтому запросы хостов также называются «подсказками». В дополнение к прямым ответам серверы также генерируют безвозмездные уведомления — например, одноадресные уведомления для информирования хостов об изменениях внешнего IP-адреса. [1] [3]

Обмен сообщениями не содержит средств для определения транзакции, к которой они принадлежат, или этапа «сеанса», который они представляют. Такая упрощенная конструкция основана на том, что все сообщения самоописываемые и полные, без дополнительного контекста , необходимого для успешной обработки каждого сообщения. Серверы могут решить молча игнорировать запросы хоста, если они не могут обработать их в данный момент; в таких случаях хостам необходимо повторно передать запрос. Кроме того, хосты могут безопасно решить молча игнорировать любые нежелательные ответы сопоставления. [3]

Для создания запросов PCP IP-адрес сервера либо вручную настраивается на хосте, находится как часть аренды DHCP хоста, либо устанавливается на настроенный шлюз по умолчанию хоста . Сообщения с запросами хоста отправляются с любого исходного порта UDP на клиенте на порт UDP 5351 сервера, который он прослушивает; незапрошенные многоадресные уведомления сервера (например, объявления о перезапуске сервера) отправляются с порта UDP 5351 сервера на порт UDP 5350 на хостах, которые они прослушивают. [3]

Максимальная длина полезной нагрузки UDP для всех сообщений PCP составляет 1100 октетов . Каждое сообщение PCP состоит из заголовка запроса или ответа, содержащего код операции , который определяет связанную операцию, любую соответствующую информацию, специфичную для кода операции (например, какие порты должны быть сопоставлены), и ноль или более опций (например, описанная выше опция THIRD_PARTY ). Коды результатов возвращаются как часть ответов сервера; каждый код результата имеет связанное время жизни, которое сообщает хостам, когда определенные операции могут быть повторены или должны быть повторены. Например, время жизни результатов может указывать, как долго, как ожидается, будет сохраняться состояние сбоя или как долго будет длиться созданное сопоставление. [3]

Смотрите также

Ссылки

  1. ^ abcdefgh Дэн Винг (декабрь 2011 г.). "Протокол управления портами". The Internet Protocol Journal . Cisco Systems . Получено 31 января 2014 г. .
  2. ^ abcd "Обзор протокола управления портами (Junos OS 13.3)". Juniper Networks . 14 августа 2013 г. . Получено 31 января 2014 г. .
  3. ^ abcdefghijklmnopqrs D. Wing; S. Cheshire; M. Boucadair; R. Penno; P. Selkirk (апрель 2013 г.). Wing, D. (ред.). "RFC 6887: Port Control Protocol (PCP)". Internet Engineering Task Force (IETF). doi : 10.17487/RFC6887 . Получено 5 июня 2023 г. {{cite journal}}: Цитировать журнал требует |journal=( помощь )
  4. ^ Boucadair, M.; Penno, R.; Wing, D. (июль 2013 г.). "Универсальное устройство шлюза Plug and Play (UPnP) для Интернета - функция взаимодействия протокола управления портами (IGD-PCP IWF)". Редактор RFC . doi : 10.17487/rfc6970 .
  5. ^ Boucadair, M.; Penno, R.; Wing, D. (июль 2014 г.). "Параметры DHCP для протокола управления портами (PCP)". Редактор RFC . doi : 10.17487/rfc7291 .
  6. ^ Boucadair, M.; Penno, R.; Wing, D.; Patil, P.; Reddy, T. (март 2015 г.). "Выбор сервера протокола управления портами (PCP)". Редактор RFC . doi : 10.17487/rfc7488 .
  7. ^ Boucadair, M. (май 2014 г.). «Обнаружение префиксов NAT64 IPv6 с использованием протокола управления портами (PCP)». Редактор RFC . doi : 10.17487/rfc7225 .
  8. ^ ab S. Cheshire; M. Krochmal (апрель 2013 г.). "RFC 6886: Протокол сопоставления портов NAT (NAT-PMP)". Internet Engineering Task Force (IETF). doi : 10.17487/RFC6886 . Получено 8 августа 2014 г. . {{cite journal}}: Цитировать журнал требует |journal=( помощь )
  9. ^ "KDNSServiceErr_NATPortMappingUnsupported". Разработчик Apple .
  10. ^ Дюпон, Фрэнсис; Цоу, Тина; Цинь, Жакни; Каллен, Маргарет; Чжан, Дачэн (13 июня 2013 г.). «Протокол управления портами в средах Dual-Stack Lite».
  11. ^ M. Cullen; S. Hartman; D. Zhang; T. Reddy (сентябрь 2015 г.). "RFC 7652: Port Control Protocol (PCP) Authentication Mechanism". Internet Engineering Task Force (IETF). doi :10.17487/RFC7652 . Получено 29 апреля 2016 г. . {{cite journal}}: Цитировать журнал требует |journal=( помощь )

Внешние ссылки