Протокол управления портами - Port Control Protocol

Набор интернет-протоколов
Уровень приложения
Транспортный уровень
Интернет-уровень
Связующий слой

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

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

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

В средах, где в локальной сети используется универсальное устройство Интернет-шлюза Plug and Play (UPnP IGD), в IGD должна быть встроена функция взаимодействия между UPnP IGD и PCP. UPnP IGD-PCP IWF определен в RFC6970.[4]

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

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

Обзор

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

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

Проблема

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

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

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

PCP как решение

PCP позволяет оборудованию и приложениям создавать явные сопоставления между внешними айпи адрес, протокол и порт, а также внутренний IP-адрес, протокол и порт. При наличии таких явных сопоставлений входящая связь может достигать хостов за NAT или брандмауэром, что либо расширяет их серверные роли за пределы локальных сетей, либо использует различные службы, упрощенные и менее ресурсоемкие. Созданные сопоставления являются постоянными в той мере, в какой для них известно время жизни, которое может быть продлено, что аналогично способу Протокол динамического конфигурирования сервера (DHCP) реализует свои аренда. В то же время PCP позволяет приложениям динамически создавать дополнительные сопоставления по мере необходимости, что снижает или устраняет необходимость в ALG -подключенные устройства NAT и межсетевые экраны.[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). Протоколы, которые не используют номера портов (например, Протокол резервирования ресурсов (ПРОСЬБА ОТВЕТИТЬ), Инкапсуляция полезной нагрузки безопасности (ESP), ICMP или же ICMPv6 ) поддерживаются межсетевым экраном IPv4, межсетевым экраном IPv6 и NPTv6 (Трансляция префикса IPv6), но не может поддерживаться более чем одним клиентом на внешний IP-адрес в случае NAT.[3]

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

История

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

NAT-PMP относится к Протокол интернет-шлюза (IGDP), который был стандартизирован в 2001 году как часть Универсальный Plug and Play (UPnP) спецификация. Хотя протокол IGDP является сложным и настраивается вручную, NAT-PMP предназначен для простоты и использования в программных приложениях.[7]:26–32

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

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

От безопасность точки зрения, важной особенностью PCP является ТРЕТЬЯ СТОРОНА отображение запрос вариант. При использовании этот параметр означает, что IP-адрес, указанный дополнительно как часть запроса сопоставления, должен использоваться в качестве внутреннего адреса для созданного явного сопоставления, а не следовать поведению по умолчанию при использовании исходного IP-адреса фактического пакета запроса сопоставления для этого. цель. Такие запросы на сопоставление могут закончиться тем, что устройство NAT или брандмауэр с поддержкой PCP предоставляет явные привилегии сопоставления выше, чем разрешено неявным сопоставлением из-за неизвестных правил, наложенных где-то в другом месте для указанного IP-адреса, что позволяет злоумышленнику украсть некоторый трафик или провести а отказ в обслуживании (DOS атаки.[3]

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

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

Внутренне 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 состоит из заголовка запроса или ответа, содержащего код операции который определяет связанную операцию, любую соответствующую информацию, относящуюся к коду операции (например, какие порты должны быть сопоставлены), и ноль или более параметров (например, ТРЕТЬЯ СТОРОНА описанный вариант над ). Коды результатов возвращаются как часть ответов сервера; с каждым кодом результата связано время жизни, которое сообщает хостам, когда определенные операции можно повторить или их следует повторить. Например, время жизни результата может указывать, как долго, как ожидается, будет сохраняться условие отказа или как долго будет длиться созданное отображение.[3]

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

Рекомендации

  1. ^ а б c d е ж грамм час Дэн Винг (декабрь 2011 г.). «Протокол управления портами». Журнал Интернет-протокола. Cisco Systems. Получено 31 января, 2014.
  2. ^ а б c d «Обзор протокола управления портами (Junos OS 13.3)». Juniper Networks. 14 августа 2013 г.. Получено 31 января, 2014.
  3. ^ а б c d е ж грамм час я j k л м п о п q р s D. Крыло; С. Чешир; М. Букадар; Р. Пенно; П. Селкирк (апрель 2013 г.). «RFC 6887: протокол управления портами (PCP)». Инженерная группа Интернета (IETF). Получено 31 января, 2014.
  4. ^ Boucadair, M .; Penno, R .; Винг, Д. (июль 2013 г.). «Универсальное устройство Интернет-шлюза Plug and Play (UPnP) - функция взаимодействия протоколов управления портами (IGD-PCP IWF)». Дои:10.17487 / rfc6970. Цитировать журнал требует | журнал = (помощь)
  5. ^ Boucadair, M .; Penno, R .; Винг, Д. (июль 2014 г.). «Параметры DHCP для протокола управления портами (PCP)». Дои:10.17487 / rfc7291. Цитировать журнал требует | журнал = (помощь)
  6. ^ Boucadair, M .; Penno, R .; Крыло, Д .; Патил, П .; Редди, Т. (март 2015 г.). «Выбор сервера протокола управления портом (PCP)». Дои:10.17487 / rfc7488. Цитировать журнал требует | журнал = (помощь)
  7. ^ а б С. Чешир; М. Крохмаль (апрель 2013 г.). «RFC 6886: протокол сопоставления портов NAT (NAT-PMP)». Инженерная группа Интернета (IETF). Получено 8 августа, 2014.
  8. ^ М. Каллен; С. Хартман; Д. Чжан; Т. Редди (сентябрь 2015 г.). «RFC 7652: механизм аутентификации протокола управления портами (PCP)». Инженерная группа Интернета (IETF). Получено 29 апреля, 2016.

внешняя ссылка