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

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

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

PCP был стандартизирован в 2013 году как преемник протокола сопоставления портов NAT (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]

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

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

ПКП как решение

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

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

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

PCP поддерживает протоколы транспортного уровня , которые используют 16-битные номера портов (например, TCP , UDP , протокол передачи управления потоком (SCTP) или протокол управления перегрузкой дейтаграмм (DCCP). Протоколы, которые не используют номера портов (например, протокол резервирования ресурсов). (RSVP), инкапсуляция полезных данных безопасности (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 ( 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

Устройства Apple с macOS и iOS ^[9]
OpenWrt , OPNsense и pfSense Программное обеспечение маршрутизатора с открытым исходным кодом
Снятые с производства маршрутизаторы Apple AirPort Wi-Fi
Интернет-провайдеры, использующие NAT операторского уровня для абонентских услуг, например Dual-Stack Lite ^[10]

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

За исключением злоумышленников, способных изменить сетевые пакеты, которыми обмениваются во время создания явного сопоставления 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]
Код операции	Описание
КАРТА	Создает или обновляет сопоставление для входящей пересылки, позволяя узлу действовать как сервер и получать входящие сообщения.
ВГЛЯДЕТЬСЯ	Создает или обновляет исходящее сопоставление, позволяя хосту поддерживать открытую связь с одним узлом.
ОБЪЯВИТЬ	Объявляет о различных изменениях на хостах, включая перезапуск сервера и изменение внешнего IP-адреса.

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

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

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

См. также

Протокол сопоставления портов NAT (NAT-PMP)
Протокол устройства интернет-шлюза (UPnP IGD)
Универсальная технология Plug and Play (UPnP)
DMZ (вычисления) - подсеть, которая содержит внешние службы и предоставляет доступ к более крупной и ненадежной сети.
Перфорация (сеть) – установление прямых соединений между двумя сторонами сети, находящимися за межсетевыми экранами или маршрутизаторами с поддержкой NAT.

Ссылки

^ Перейти обратно: ^а ^б ^с ^д ^и ^ж ^г ^час Дэн Винг (декабрь 2011 г.). «Протокол управления портом» . Журнал Интернет-протокола . Сиско Системы . Проверено 31 января 2014 г.
^ Перейти обратно: ^а ^б ^с ^д «Обзор протокола управления портами (Junos OS 13.3)» . Джунипер Нетворкс . 14 августа 2013 года . Проверено 31 января 2014 г.
^ Перейти обратно: ^а ^б ^с ^д ^и ^ж ^г ^час ^я ^дж ^к ^л ^м ^н ^тот ^п ^д ^р ^с Д. Винг; С. Чешир; М. Букадер; Р. Пенно; П. Селкирк (апрель 2013 г.). Винг, Д. (ред.). «RFC 6887: Протокол управления портами (PCP)» . Целевая группа инженеров Интернета (IETF). дои : 10.17487/RFC6887 . Проверено 5 июня 2023 г. {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
^ Букадер, М.; Пенно, Р.; Винг, Д. (июль 2013 г.). «Устройство интернет-шлюза Universal Plug and Play (UPnP) — функция взаимодействия протокола управления портами (IGD-PCP IWF)» . дои : 10.17487/rfc6970 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
^ Букадер, М.; Пенно, Р.; Винг, Д. (июль 2014 г.). «Параметры DHCP для протокола управления портами (PCP)» . дои : 10.17487/rfc7291 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
^ Букадер, М.; Пенно, Р.; Винг, Д.; Патил, П.; Редди, Т. (март 2015 г.). «Выбор сервера протокола управления портами (PCP)» . дои : 10.17487/rfc7488 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
^ Букадер, М. (май 2014 г.). «Обнаружение префиксов NAT64 IPv6 с помощью протокола управления портами (PCP)» . дои : 10.17487/rfc7225 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
^ Перейти обратно: ^а ^б С. Чешир; М. Крохмаль (апрель 2013 г.). «RFC 6886: Протокол сопоставления портов NAT (NAT-PMP)» . Целевая группа инженеров Интернета (IETF). дои : 10.17487/RFC6886 . Проверено 8 августа 2014 г. {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
^ https://developer.apple.com/documentation/dnssd/kdnsserviceerr_natportmappingunsupported/
^ https://datatracker.ietf.org/doc/html/draft-ietf-pcp-dslite-00
^ М. Каллен; С. Хартман; Д. Чжан; Т. Редди (сентябрь 2015 г.). «RFC 7652: Механизм аутентификации протокола управления портами (PCP)» . Целевая группа инженеров Интернета (IETF). дои : 10.17487/RFC7652 . Проверено 29 апреля 2016 г. {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )

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

[ipj-14-4-1] Перейти обратно: ^а ^б ^с ^д ^и ^ж ^г ^час Дэн Винг (декабрь 2011 г.). «Протокол управления портом» . Журнал Интернет-протокола . Сиско Системы . Проверено 31 января 2014 г.

[juniper-pcp-2] Перейти обратно: ^а ^б ^с ^д «Обзор протокола управления портами (Junos OS 13.3)» . Джунипер Нетворкс . 14 августа 2013 года . Проверено 31 января 2014 г.

[rfc-6887-3] Перейти обратно: ^а ^б ^с ^д ^и ^ж ^г ^час ^я ^дж ^к ^л ^м ^н ^тот ^п ^д ^р ^с Д. Винг; С. Чешир; М. Букадер; Р. Пенно; П. Селкирк (апрель 2013 г.). Винг, Д. (ред.). «RFC 6887: Протокол управления портами (PCP)» . Целевая группа инженеров Интернета (IETF). дои : 10.17487/RFC6887 . Проверено 5 июня 2023 г. {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )

[4] Букадер, М.; Пенно, Р.; Винг, Д. (июль 2013 г.). «Устройство интернет-шлюза Universal Plug and Play (UPnP) — функция взаимодействия протокола управления портами (IGD-PCP IWF)» . дои : 10.17487/rfc6970 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )

[5] Букадер, М.; Пенно, Р.; Винг, Д. (июль 2014 г.). «Параметры DHCP для протокола управления портами (PCP)» . дои : 10.17487/rfc7291 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )

[6] Букадер, М.; Пенно, Р.; Винг, Д.; Патил, П.; Редди, Т. (март 2015 г.). «Выбор сервера протокола управления портами (PCP)» . дои : 10.17487/rfc7488 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )

[7] Букадер, М. (май 2014 г.). «Обнаружение префиксов NAT64 IPv6 с помощью протокола управления портами (PCP)» . дои : 10.17487/rfc7225 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )

[rfc-6886-8] Перейти обратно: ^а ^б С. Чешир; М. Крохмаль (апрель 2013 г.). «RFC 6886: Протокол сопоставления портов NAT (NAT-PMP)» . Целевая группа инженеров Интернета (IETF). дои : 10.17487/RFC6886 . Проверено 8 августа 2014 г. {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )

[9] ttps://developer.apple.com/documentation/dnssd/kdnsserviceerr_natportmappingunsupported/

[10] ttps://datatracker.ietf.org/doc/html/draft-ietf-pcp-dslite-00

[11] М. Каллен; С. Хартман; Д. Чжан; Т. Редди (сентябрь 2015 г.). «RFC 7652: Механизм аутентификации протокола управления портами (PCP)» . Целевая группа инженеров Интернета (IETF). дои : 10.17487/RFC7652 . Проверено 29 апреля 2016 г. {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]