Geum.ru

Понятие протокола, и связанные с ним понятия

Вид материалаДокументы

Содержание


Факультативный материал – трансляция IP-адресов в IP-адреса. – протоколы NAT и NAPT.
Разрешение некоторых проблем, связанных с NAT. Протокол STUN.
Подобный материал:
1   ...   10   11   12   13   14   15   16   17   ...   20

Факультативный материал – трансляция IP-адресов в IP-адреса. – протоколы NAT и NAPT.


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

В самом деле, поскольку адреса, определенные как корпоративные, исключены из адресного пространства Internet, пакеты с такими адресами любым маршрутизатором Internet будут отброшены20. В случае же использования корпоративной сетью адресов, принадлежащих адресному пространству Internet, возникает проблема неуникальности адреса.

Разрешает эту проблему протокол NAT (Network address translation), существующий в двух вариантах – базисный NAT (Basic NAT), действительно транслирующий только сетевые адреса, и протокол NAPT (Network address and port translation), использующий при такой трансляции, как это следует из его названия, также номера портов протоколов транспортного уровня (TCP/UDP).

Идея базисного NAT заключается в следующем. При соединении с интернетом пограничный маршрутизатор получает от провайдера услуг один или несколько IP адресов Internet. Их уникальность гарантированна провайдером. Когда узлу корпоративной сети требуется доступ в Internet, он, естественно, посылает пакет пограничному маршрутизатору. Функционирующий в составе программного обеспечения пограничного маршрутизатора NAT-сервер сопоставляет адресу этого узла один из имеющихся в его распоряжении IP адресов Internet, запоминает это в соответствующей таблице, и далее выполняет трансляцию адресов в соответствии с этой таблицей – в приходящих из Internet пакетах адрес Internet заменяется на соответствующий ему локальный, в исходящих из корпоративной сети пакетах осуществляется обратная замена. Заметим, что изменение адресов назначения требует перерасчета контрольных сумм транспортных протоколов TCP и UDP, поскольку они при расчете контрольных сумм используют псевдозаголовок, содержащий IP-адреса отправителя и получателя. Это один из тех редких случаев, когда данные транспортного уровня обрабатываются на промежуточном узле.

Несмотря на ряд очевидных преимуществ – относительная простота, прозрачность для пользователя, возможность использования любых протоколов, инкапсулируемых в IP-пакеты – базисный NAT имеет один очень ощутимый недостаток. Он заключается в том, что взаимно однозначное соответствие корпоративных и сетевых адресов, устанавливаемое базисным NAT, ограничивает число узлов, одновременно имеющих доступ к Internet, количеством имеющихся в распоряжении NAT-сервера адресов Internet21.

От этого недостатка свободен протокол NAPT, который для идентификации узлов использует совокупность адреса и транспортного идентификатора. В качестве транспортных идентификаторов используются номера портов транспортных протоколов – TCP и UDP. В самом деле, доступное количество номеров портов, определяемое разрядностью соответствующего поля, достигает 64К-2, в то время как обычно узел образует значительно меньшее число сетевых соединений – от единиц до нескольких десятков. Фиксированными, т.н. «хорошо известными» являются только номера портов, используемые серверами сетевых служб для приема входящих соединений, в остальных случаях единственное требование к номеру порта – уникальность на данном узле. Это позволяет серверу установить соответствие парам «корпоративный адрес – номер порта» – «глобальный адрес – номер порта», и таким образом, обеспечить отображение на один глобальный адрес множества локальных, различая их по номерам портов.

К сожалению, такой подход ограничивает набор возможных протоколов TCP и UDP, причем, если не принять специальных мер, только исходящими соединениями (внешние узлы не могут обратится к корпоративным серверам по хорошо известным номерам портов, поскольку не знают, на какой внешний номер порта отобразит хорошо известный номер протокол NAPT). Но эта последняя проблема может быть разрешена, если соответствующий сервис присутствует в корпоративной сети в единственном числе, статической записью в таблице трансляции протокола NAPT – адрес и порт корпоративного сервера связываются с хорошо известным номером порта и для внешних соединений. Кроме того, неконтролируемый доступ извне к корпоративным серверам – это как раз та ситуация, которой администраторы обычно стремятся избежать по соображениям безопасности. Проблема эта усугубляется еще и тем, что при нынешней многофункциональности программных продуктов пользователь, невнимательно прочтя документацию и позволив установить типовой комплект программного продукта, может и не знать, что на его компьютере установлен соответствующий сервис. Так что NAPT даже снижает остроту этой проблемы. Несколько сложнее первая проблема, поскольку в список протоколов, пакеты которых не могут быть однозначно соотнесены с внутренним адресом, попадает ряд широко используемых, например, ICMP. Это требует ряда специальных мер. Скажем, в ICMP-сообщениях о проблемах с пакетом присутствует IP-заголовок и первые 8 байт (т.е. номера портов тоже) вложения. Это позволит NAPT-серверу соотнести сообщение с локальным узлом. Другие сообщения могут отправляться в локальную сеть широковещательно. Более общий подход состоит в расширении понятия «транспортный идентификатор», ,например, в качестве такового могут использоваться поля идентификатора ICMP-запросов (и не только), что, однако, усложняет реализацию протокола NAPT.

Протоколы трансляции адресов скрывают от внешней сети внутреннюю структуру локальной (обратное неверно – информация о внешних маршрутах, как правило, распространяется в локальной сети). С точки зрения безопасности, это, безусловно, плюс, а, например, с точки зрения оптимальной маршрутизации это минус – если пограничных маршрутизаторов у локальной сети несколько, возможность оптимального распределения между ними потоков внешних данных осложняется. Вообще наличие нескольких NAT/NAPT серверов создает проблемы. Поскольку пакеты в сети распространяются независимо друг от друга, не все пакеты одного потока обязательно пройдут через один NAT/NAPT сервер, следовательно, необходима синхронизация таблиц трансляции адресов во всех серверах. Если за статическую трансляцию в этом случае ответственен администратор, то динамическая требует какого-то протокола синхронизации NAT/NAPT таблиц.

Еще один интересный вариант применения NAT/NAPT – инженерия трафика. Обычно пакеты, направляемые на один адрес маршрутизируются сходным образом. В случае, если по этому адресу находится сервер, к которому осуществляется обращение из многих сетей, это может привести к перегрузке некоторых сетей или каналов связи. В этом случае для разных сетей можно объявить сервер под разными адресами. Этими адресами будут NAPT серверы, статически транслирующие соответствующий адрес и соответствующий «хорошо известный» номер порта TCP в действительный адрес сервера с тем же номером порта. Это позволит обойти «узкие места» в сети.

Классический NAT/NAPT самые распространенные, но не единственные протоколы преобразования адресов. Так, в случае, когда адресные пространства корпоративной и глобальной сети перекрываются, для разрешения коллизий, связанных с неуникальностью адреса, приходится прибегать к двойной трансляции адресов, когда изменяется не только адрес отправителя, но и адрес получателя. Часто весь комплекс протоколов NAT реализуется одним сервером.

Разрешение некоторых проблем, связанных с NAT. Протокол STUN.


Как уже говорилось, NAT затрудняет доступ в сеть извне, поскольку как внешние узлы, так и внутренние узлы сети не знают, как преобразует адреса сервер NAT. Проблема может быть решена посредством интеграции NAT-сервера с прокси-сервером соответствующего прикладного протокола. Но прикладных протоколов в сети великое множество, так что если NAT не интегрирован с прокси-сервером протокола HTTP, это по нынешним временам даже как-то неприлично, протокол FTP обычно реализуется HTTP прокси, при этом клиент с прокси работает по протоколу HTTP, а прокси с FTP сервером – уже по FTP протоколу, корпоративный сервер электронной почты можно установить на тот же сервер, что и NAT, а вот с другими протоколами – проблемы.

Котрые еще усугубляются тем, что NAT на пути от конечного пользователя в Internet может быть не один. Например, локальная сеть Вашей организации получает доступ в Internet через свой NAT, но, возможно, нри этом попадает не сразу в Internet, а во внутреннюю сеть вашего Internet-провайдера, которая, в свою очередь, получает доступ в Internet через свой NAT. Для своего сервера NAT Вы, возможно, решили соответствующие проблемы, но NAT-сервер провайдера Вам недоступен!

В частности, проблемы возникают при использовании систем Internet-телефонии, которые в настоящее время получают все большее распространение. В этих системах, прежде чем установить соединение, собеседники должны объявить друг другу, кто, что и по каким портам будет передавать и принимать. Но пользователь, находящийся за NAT, не знает, в какой внешний адрес и номер порта будут преобразованы его внутренний адрес и номер порта! Если только NAT-сервер не анализирует и не изменяет сообщения прикладного уровня (т.е. не является одновременно прокси-сервером соответствующего протокола), установление соединения становится невозможным! И это при том, что счастливые обладатели скоростного доступа, которые могли бы сполна насладиться и высококачественной (лучше проводного телефона!) передачей речи, и видеообменом, как правило, почти всегда работают из-за NAT, очень редко напрямую!

Первая растпространенная система IP-телефонии, способная работать через NAT, знаменитый Skype, выходит из положения весьма своеобразно, имитируя HTTPS протокол, и связывая абонентов, находящихся за NAT, через прокси, так называемые «суперузлы», размещенные на компьютерах пользователей, имеющих прямой доступ в Internet (реальный, а не транслированный IP адрес). Голос и видео – поверх TCP! Да еще и прокси-сервер, интегрированный в клиент! А что делать?

Протокол STUN (Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs), RFC-3489) призван решить эту проблему. STUN – типичный клиент-серверный протокол. Клиент, отделенный от публичной сети одним или более NAT, посылает серверу запросы, а сервер, расположенный в Internet, на них отвечает.

Существует 2 типа запросов – разделенные засекреченные (Shared Secret Requests), применяемые для целей авторизации клиента на сервере, и осуществляемый последством TLS (TCP с засекречиванием информации уровня выше транспортного), и пробные (Binding Requests), которые, собственно, и служит для определения отображения локальных адресов на глобальные, и передаются посредством UDP. После того, как клиент соединяется с сервером, и посредством разделенных засекреченных запросов проходит авторизацию, а сервер проверяет, что этому узлу обслуживание разрешено, клиент получает возможность посылать пробные запросы.

Пробные запросы, собственно, и служат как для определения самого факта, что между клиентом и Internet присутствует NAT, так и для исследования карты преобразования внутренних адресов и номеров портов в публичные. Это осуществляется следующим образом. Клиент STUN посылает пробный/пробные запрос/запросы с одного или более портов на известный ему порт сервера. Сервер STUN, получив пробный запрос, определяет адрес и порт отправителя, как они представлены в его адресном пространстве, и помещает эту информацию в ответ. Ответ направляется посредством того же протокола (UDP) на тот же адрес и порт, откуда пришел запрос. При всех вариантах реализации NAT ответ будет корректно принят клиентом22. Если сообщаемые в ответе адрес и/или номер порта отличаются от локальных, между клиентом и сервером присутствует по крайней мере один NAT. В противном случае клиент и сервер находятся в объщем адресном пространстве.

С точки зрения STUN выделяются 4 основных типа реализации NAT-серверов:

Динамический неограниченный (Full Cone). В этом случае все запросы от определенного внутреннего IP-адреса и порта отображаются на один и тот же внешний IP-адрес и порт. Кроме того, различные узлы Интернета могут послать пакеты узлу за NAT, отправляя их на соответствующий порт NAT-сервера.

Динамический, ограниченный по IP-адресам (Restricted Cone). То же, но внешние узлы могут посылать пакеты только в том случае, если узел за NAT сам предварительно посылал им какие-либо пакеты.

Динамический, ограниченный по IP-адресам и портам (Port Restricted Cone). То же, что и предыдущее, но ограничения заданы более жестко: узел в Интернет может отсылать пакеты только с того порта, на который он предварительно что-то получил от узла из-за NAT.

Симметричный (Symmetric) – все пакеты от внутреннего IP-адреса и порта к внешнему IP-адресу и порту преобразуются в один и тот же IP-адрес и порт NAT-сервера. Отличие заключается в том, что при обращении к различным внешним IP-адресам порты на NAT-сервере тоже будут изменяться. Таким образом, только один интернет-узел может посылать пакеты узлу, находящемуся за NAT-сервером.

Определить тип NAT-сервера STUN клиент может следующим образом. Послав запрос на другой STUN-сервер, или другой интерфейс (IP-адрес) того же сервера (согласно описанию протокола, STUN-сервер должен иметь как минимум 2 IP-адреса), с того же порта клиента, сравнить ответы. Если ответы различаються, NAT-сервер симметричный. Если нет, STUN предоставляет клиенту возможность послать пробный запрос с флагом, указывающим серверу, что ответ следует направить с другого адреса или номера порта (такой возможностью любой STUN-сервер обладать должен). Если ответы не достигают клиента, мы имеем дело с NAT-сервером, ограниченным по адресам или адресам и номерам портов соответственно23. Если все ответы успешно достигают клиента, NAT-сервер неограниченный.

Для первых трех типов NAT можно с успехом использовать внешний STUN-сервер, а вот для четвертого типа этот метод уже не поможет – номера портов, назначаемые для пакетов к STUN-серверу и второму участнику разговора будут разными. Единственным возможным здесь вариантом является интеграция функциональности STUN-сервера в прокси-сервер вашего протокола.

Следует учесть, что STUN нельзя использовать для обеспечения входящих TCP соединений – NAT-сервер может использовать различные карты отображения адресов/портов для разных транспортных протоколов.