ОБЛАСТЬ ТЕХНИКИ
Виртуальная частная сеть (ВЧС), использующая протокол TCP/IP, обеспечивает надежную скоростную связь между удаленными компьютерными сайтами, используя Интернет в качестве средства связи. Информация, проходящая между сайтами через Интернет, может быть защищена от вмешательства нежелательных подслушивающих устройств или злоумышленников-хакеров разнообразными средствами безопасности. Эффективные меры безопасности должны, как минимум, осуществлять функции, которые обеспечивают любое или все из следующих форм защиты: целостность данных против ненамеренного или злоумышленного изменения данных во время передачи; предотвращение атак “отказ от обслуживания” путем применения мер против повторения; подтверждение источника; конфиденциальность адреса источника и другой головной информации во время передачи и защита пакетов данных от нежелательного перехвата. Одной из стандартных моделей обеспечения безопасности в Интернете является набор программ для безопасности протокола в Интернете - IPSec. IPSec работает вместе с протоколом связи TCP/IP для обеспечения безопасной связи между устройствами, подсоединенными к Интернету или соединенными в частные ЛВС (локальные вычислительные сети), которые сами соединены с Интернетом.
УРОВЕНЬ ТЕХНИКИ
Комплект программ протокола TCP/IP (протокол управления передачей/протокол Интернет) использует IP-адреса для идентификации каждого устройства в сети. Глобальный IP-адрес уникально идентифицирует устройство в Интернете. Такими устройствами могут быть компьютеры, принтеры, маршрутизаторы, коммутаторы, шлюзы или другие сетевые устройства. Устройства, имеющие глобальные IP-адреса, могут непосредственно упоминаться как источники или адресаты в Интернете. Протокол связи TCP/IP, однако, не ограничен только Интернетом, но может использоваться и в частных ЛВС. Частные ЛВС, использующие протокол TCP/IP, часто используют “локальные” IP-адреса для сетевых устройств. Хотя любые два устройства в частной ЛВС не могут иметь один и тот же локальный IP-адрес, частные ЛВС изолированы от Интернета, и локальные устройства в ЛВС не видимы из Интернета. IP-адресам для локальных устройств поэтому не нужно быть “глобально” уникальными. ЛВС, использующая локальные IP-адреса, будет соединяться с Интернетом через шлюз, являющийся устройством, которое может отфильтровывать сообщения или назначать для них маршрут между ЛВС и Интернетом. Так как шлюз прямо связан с Интернетом, Интернет его видит, шлюз должен иметь глобально уникальный IP-адрес для связи через Интернет. Однако, так как ЛВС прямо не видима из Интернета, локальные машины в ЛВС не требуют IP-адресов, которые глобально уникальны.
TCP/IP является протоколом связи, который используется в Интернете. Информация, которая будет сообщаться с использованием TCP/IP, содержится в “дейтаграммах”. Дейтаграмма состоит из дискретного “пакета” информации, к которому присоединены одна или несколько головных меток. Головные метки содержат информацию, необходимую для того, чтобы TCP/IP направил этот пакет в определенное для него место назначения и обеспечил его надлежащую обработку во время передачи. Каждая дейтаграмма адресуется индивидуально и может быть ориентированной на связь дейтаграммой TCP или “не ориентированной на связь” дейтаграммой UDP (протокол передачи дейтаграмм пользователя). Каждая дейтаграмма UDP включает в себя головную метку IP и головную метку UDP. Головная метка IP содержит по меньшей мере IP-адрес “источника” и IP-адрес назначения, тогда как головная метка UDP включает в себя служебный адрес источника и служебный адрес назначения (адреса портов, выражаемые цифрами). IP-адреса в IPv4 32-битные и ассоциируются с хорошо известным сейчас форматом ххх.ххх.ххх.ххх. В этом формате каждый сегмент из трех цифр является бинарным октетом, представляющим число от 0 до 255. Полный IP-адрес объединяет адрес логической сети или сегмента сети с адресом “узла” (устройства) в сети. Адрес сети или сегмента сети может занимать первые 3, 6 или 9 цифр из IP-адреса. Устройство в сети или в сегменте сети идентифицируется адресом узла, который состоит из тех остальных цифр, которые не используются в адресе сети или сегмента сети.
Служебный адрес источника и служебный адрес назначения, содержащиеся в головной метке UDP, представляют собой 16-битные числа, известные как “порты” или “сокеты”, которые используются для направления пакета на предназначенный процесс, который активен на посылающем или принимающем устройстве. Термин “порт” или “Адрес порта”, который используется в настоящем документе, относится к полю служебного адреса в головной метке UDP. Хотя теоретически существует столько портов, сколько имеется адресов в 16-битном числе, по условию многие адреса портов были зарезервированы для определенных процессов. Так, например, порт 80 зарезервирован для HTTP, a порты 20 и 21 зарезервированы для FTP. Посредством использования адресов портов данные, приходящие на локальную машину, на которой идет более одного процесса, будут направляться на процесс, для которого они предназначены. Если процесс, выполняющийся на локальном хосте, не является одним из зарезервированных процессов, такой локальный хост может выбрать любой номер порта из пула незарезервированных номеров портов для идентификации процесса “источника”. Ответный пакет, ссылающийся на тот номер порта в поле “назначения”, будет направлен на этот процесс.
С учетом того, что наблюдается взрывной рост использования Интернета в последнее десятилетие, и с учетом его планируемого роста в будущем глобально уникальные IP-адреса стали очень редкими. Кроме того, многие предприятия, имеющие частные ЛВС, не нуждаются в том, чтобы каждый компьютер и устройство в ЛВС имели уникальный глобальный IP-адрес. Многие из таких предприятий, в любом случае, предпочли бы сохранить IP-адреса своих компьютеров в тайне. Вместо того, чтобы тратить впустую ограниченные глобальные ресурсы путем назначения каждому локальному устройству уникального глобального IP-адреса, многие частные ЛВС используют локальные IP-адреса для устройств в ЛВС. Для того, чтобы обеспечить возможность соединения с Интернетом, такие ЛВС будут использовать один глобально уникальный адрес, который будет использоваться в Интернете шлюзом, отделяющим ЛВС от Интернета.
Посредством использования методов трансляции сетевых адресов (ТСА) шлюзовое устройство, отделяющее ЛВС от Интернета, может обеспечивать безопасность как брандмауэр, в то же время разрешая машинам с локальными IP-адресами доступ в Интернет через уникальный глобальный адрес шлюза. Любое устройство в ЛВС может иметь статический локальный IP-адрес или может иметь локальный IP-адрес, динамически присваиваемый ему при подключении к сети. Шлюз содержит таблицу перевода с локальными IP-адресами для каждого устройства в ЛВС. Пакет UDP, посланный локальной машиной и предназначенный для Интернета, будет иметь свой локальный IP-адрес и адрес порта, идентифицированный в полях источника головных меток IP и UDP соответственно. Шлюз будет получать этот пакет от локальной машины, подставлять свой внешний и глобально уникальный IP-адрес и новый адрес порта (взятый из пула неиспользуемых и незарезервированных адресов портов) в поля источника в головных метках IP и UDP. Далее он модернизирует CRC (циклический контрольный код) и произведет все остальные необходимые изменения для обеспечения целостности данных, после чего он направит пакет в Интернет. Как часть этого процесса шлюз обновит свою внутреннюю таблицу перевода, чтобы связать IP-адрес этой локальной машины с адресом порта источника, первоначально сообщенным этой машиной, с новым адресом порта источника, присвоенным отправляемому в Интернет пакету, и с IP-адресом назначения. По получении ответа из Интернета шлюз распознает свой собственный IP-адрес в головной метке пакета и исследует адрес порта назначения входящего пакета. Если он обнаружит, что адрес порта назначения находится в его внутренней таблице, шлюз вставит соответствующий IP-адрес локальной машины и первоначальный адрес порта в поля назначения этого пакета, обновит CRC и любые другие необходимые параметры и затем направит пакет в ЛВС, где он будет получен локальной машиной и направлен на соответствующий процесс. Таким образом некоторое число компьютеров в ЛВС, имеющих только локальные IP-адреса, могут сообщаться через Интернет посредством одного глобально уникального IP-адреса.
Хотя шлюзы ТСА как брандмауэры обеспечивают безопасность от прямого доступа в ЛВС из Интернета, они не обеспечивают безопасность от перехвата или изменения пакета, предназначенного для ЛВС, когда этот пакет проходит по Интернету, они также не обеспечивают “надежность” от проблем, возникающих в ЛВС. Так, безопасность, обеспечиваемая протоколом IPSec, является необходимой защитой для тех ЛВС, которые должны поддерживать безопасность при связи с Интернетом.
Обычной задачей IPSec является обеспечение безопасности для ВЧС, состоящих по меньшей мере из одного главного вычислительного сайта и одной или нескольких удаленных ЛВС. Главный сайт и удаленные ЛВС связаны через Интернет, используя эту скоростную среду для сообщения между сайтами вместе значительно более дорогостоящих арендуемых частных линий. Недостатком использования Интернета в качестве передающей среды является, однако, то, что Интернет небезопасен по своей сути и обеспечивает лишь небольшую защиту или вообще не обеспечивает ее от вмешательства в чужие дела, обнаружения информации, получения доступа путем обмана или, в конечном итоге, кражи, видоизменения или искажения сообщений хакерами. Таким образом, существует необходимость в мерах всеобъемлющей безопасности, когда требуется безопасно передать данные. Протокол IPSec обеспечивает меры безопасности для обеспечения подтверждения данных и целостности данных.
Программы протокола IPSec обеспечивают безопасность на сетевом уровне многослойной сетевой контрольной модели OSI (взаимодействия открытых систем). Эти программы включают несколько отдельных протоколов, которые используются в сочетании один с другим для обеспечения безопасности дейтаграмм UDP, которые переносят информацию по Интернету. Базовая архитектура систем, соответствующих IPSec, объяснена в RFC2401 “Архитектура безопасности для Интернет-протокола”, С. Кент и Р. Аткинсон (ноябрь 1998 г.). Протокол АН (головная метка подлинности) обеспечивает целостность данных, подтверждение источника и включает в себя меры “против повторов” для отражения атак отказа в обслуживании. Протокол ESP (инкапсулированная полезная нагрузка безопасности) обеспечивает защиту, аналогичную обеспечиваемой протоколом АН, но добавляет дополнительное средство шифрования полезной нагрузки. Головные метки и АН и ESP имеют поле для индекса параметров безопасности (ИПБ). ИПБ - это 32-битное псевдослучайное значение, которое используется для идентификации соединения безопасности (SA) для дейтаграммы. Более подробную информацию по этим протоколам можно найти в RFC1826 “Головная метка аутентификации IP”, P. Аткинсон (август 1995 г.) и в RFC2406 “Инкапсулированная полезная нагрузка безопасности (ESP)”, С. Кент и Р. Аткинсон (ноябрь 1998 г.). ISAKMP/Oakley (Соединение безопасности в Интернете и протокол распределения ключей, также широко известный как обмен ключами в Интернете - IKE) является протоколом с подтверждением связи, который устанавливает параметры безопасного сеанса связи между двумя хостами и обеспечивает обмен информацией о работе на клавиатуре и другой информации о безопасности, которая используется для проведения безопасного сеанса связи и допускает передачу шифрованных данных. Протокол ISAKMP/Oakley (именуемый ниже просто ISAKMP) включает начальный обмен нешифрованными сообщениями для предоставления обеим машинам данных инициализации, из которых можно установить аутентификацию и генерировать безопасные ключи для шифрования данных. Объяснение этих процессов можно найти в RFC2409 “Обмен ключами в Интернете”, Д. Харкинс и Д. Каррел (ноябрь 1998 г.). После того как произошел обмен параметрами безопасности, достаточными для установления связей безопасности между хостами, все последующие передачи будут шифроваться и полностью подтверждаться в соответствии с согласованными протоколами. В этот момент протокол ISAKMP прекращается. Последующая адресация основана на IP-адресе каждой машины и ИПБ этой машины для этого сеанса связи. Индекс параметров безопасности (ИПБ) уникален для каждой машины во время сеанса связи. Шлюз частной ЛВС будет использовать внутреннюю таблицу, в которой входной ИПБ является значением, соотнесенным с IP-адресом локальной машины, а выходной ИПБ соотнесен с IP-адресом машины в Интернете, которая связывается с этой локальной машиной. ИПБ для каждой машины вычисляется из информации, являющейся предметом обмена во время передач по протоколу ISAKMP, и содержится в головной метке АН или ESP, которая прилагается к пакетам UDP. Поскольку протоколы IPSec могут быть представлены в форме вложений для обеспечения безопасности в различных средах, одна дейтаграмма может содержать и головную метку АН и головную метку ESP и может шифровать какую-то информацию головной метки.
Каждый из вышеупомянутых протоколов безопасности модифицирует пакет UDP путем помещения на пакет новой информации головной метки, модифицируя определенные поля в пакете для соответствия используемому протоколу и, в некоторых случаях, кодируя полезную нагрузку и все или части остальных головных меток пакета. Так, согласно IPSec, когда дейтаграмма UDP покидает “безопасный” домен для перехода через ненадежную сеть, она обычно состоит из головной метки IP, головной метки АН или ESP (или обеих) и инкапсулированной полезной нагрузки. Информация головной метки может включать в себя адрес назначения, ИПБ и достаточно информации о связи безопасности для обеспечения того, что дейтаграмма достигнет своего назначения и сможет быть подтверждена хосту назначения. Инкапсуляция полезной нагрузки обеспечивает отказ в получении информации, содержащейся в полезной нагрузке, нежелательным операторам перехвата сообщений и хакерам. Первоначальным хостом назначения для дейтаграммы может быть маршрутизатор, шлюз или брандмауэр между ЛВС и Интернетом. После прибытия на устройство на границе между ЛВС и Интернетом дейтаграмма может быть открыта, изучена или дешифрована полностью или частично, проанализирована на предмет получения информации о дальнейшем адресе и направлена в локальный IP-адрес в ЛВС.
Протокол подтверждения связи ISAKMP, используемый в IPSec, требует, чтобы оба хоста, намеревающиеся установить безопасный сеанс связи между ними, использовали адрес порта для специфического процесса (порт 500) для первоначального обмена сообщениями. По этой причине порт 500 был отведен для исключительного использования с протоколом ISAKMP. По условию компьютеры, пытающиеся обговорить параметры безопасной связи путем использования протокола ISAKMP, должны сообщаться между собой строго через порт 500 каждого компьютера. То есть, сообщения ISAKMP от любого компьютера должны идентифицировать порт 500 как адреса порта источника и порта назначения. Если любой компьютер получит пакет, в котором порт 500 не определен как являющийся и источником и назначением, пакет будет сброшен.
Хотя этот протокол предоставляет гарантию, что два хоста сообщаются между собой, это не действует, когда один хост находится в ЛВС, которая использует локальные IP-адреса и шлюз ТСА. Например, хост А, имеющий локальный IP-адрес в удаленной ЛВС, защищенной шлюзом ТСА, хочет установить надежный сеанс связи с хостом Б, находящимся в компьютерном центре главного офиса. Хост А будет инициировать протокол путем направления нешифрованной дейтаграммы UDP хосту Б, указывая “назначение” как IP-адрес хоста Б и адрес порта назначения как “порт 500”. Однако, когда дейтаграмма поступит в шлюз ТСА, соединяющий удаленную ЛВС с Интернетом, этот шлюз транслирует адрес порта назначения в произвольный номер порта. После прибытия дейтаграммы в хост Б протокол ISAKMP не будет распознан, и хост Б не ответит. Компьютеры не смогут установить безопасный сеанс связи. Из-за этой трудности до настоящего времени считалось, что протокол ISAKMP нельзя использовать для создания ВЧС, использующей шлюз ТСА, где каждый компьютер в удаленной ЛВС использует локальный, а не глобальный IP-адрес.
Поэтому одной из целей настоящего изобретение является создание шлюза, который будет допускать использование протокола ISAKMP для аутентификации и обменов ключами между компьютером, имеющим не глобальный IP-адрес, и хостом, использующим Интернет в качестве среды для передачи.
Еще одной целью настоящего изобретения является создание шлюза, который будет разрешать любому количеству компьютеров в частной ЛВС, использующей локальные IP-адреса, инициировать или получать сообщения через Интернет, используя протокол ISAKMP.
Еще одной целью настоящего изобретения является создание способа использования виртуальных частных сетей между двумя и более сайтами ЛВС в Интернете, используя протокол ISAKMP для инициации безопасной связи.
Эти и другие цели настоящего изобретения станут более понятными посредством следующего описания.
РАСКРЫТИЕ ИЗОБРЕТЕНИЯ
В соответствии с настоящим изобретением компьютер, использующий локальный IP-адрес в удаленной ЛВС, соединенной с внешней сетью, такой как Интернет через шлюз ТСА, будет использовать протокол ISAKMP для обмена ключами и установления соединений безопасности, которые будут поддерживать безопасный сеанс связи по протоколу IPSec. При трафике не по ISAKMP шлюз выполняет трансляцию адреса в нормальном режиме. Однако, когда машина в ЛВС направляет сообщение по протоколу ISAKMP, шлюз идентифицирует дейтаграмму, содержащую адреса портов порта 500. После выявления такой дейтаграммы шлюз будет транслировать IP-адрес источника, но не будет транслировать адрес порта источника, оставляя его на порте 500, и будет направлять пакет в Интернет, указав порт 500 в качестве адресов порта источника и порта назначения. Шлюз также обновит свою внутреннюю таблицу, чтобы “связать” порт 500 с локальным IP-адресом и ассоциировать эту связь с внешним IP-адресом машины назначения на предопределенный промежуток времени. В том случае, если действительный ответ не будет получен в течение предопределенного отрезка времени, “связь” между портом 500 и локальным IP-адресом будет выключена. Эта операция необходима для того, чтобы обеспечить, что порт 500 не связан на неопределенное время, как, например, в ситуации, когда передача протокола ISAKMP была инициирована по неправильному IP-адресу назначения. В этих условиях шлюз никогда не получит действительный ответ. Если бы не было таймера для выключения порта 500 после периода времени, в течение которого не получен действительный ответ, порт оставался бы связанным с локальным IP-адресом до установки шлюза в исходное состояние. Для большинства условий период времени в две секунды должен быть достаточным отрезком времени для поддержания связи между портом 500 и локальным IP-адресом при ожидании действительного ответа.
В течение времени, когда порт 500 связан с локальным IP-адресом, шлюз будет продолжать нормальную обработку дейтаграмм, не имеющих адреса порта 500, ожидая действительного ответа. Действительный ответ будет представлять собой дейтаграмму, имеющую IP-адрес источника, который аналогичен внешнему IP-адресу, который ассоциируется с портом 500, и будет иметь адреса источника и назначения как порт 500. Ожидая действительного ответа, шлюз не будет принимать во внимание другие дейтаграммы UDP из внешней сети, которые имеют в качестве адресов источника и назначения порт 500, но не надлежащий IP-адрес источника. Также, пока порт 500 связан с локальным IP-адресом, дейтаграммы, полученные из ЛВС адресом порта 500 в качестве адресов источника и назначения, будут проходить “нормальную” трансляцию адреса, при которой адрес порта 500 в качестве адреса порта источника будет транслироваться в произвольный, неиспользуемый адрес порта перед направлением во внешнюю сеть. Поскольку такая дейтаграмма не имеет адрес порта 500 в качестве адресов портов источника и назначения, она не является действительной дейтаграммой ISAKMP и будет игнорироваться при поступлении в ее IP-адрес назначения. Если период связи порта 500 с локальным IP-адресом истечет, и в этот период шлюз не получит действительную дейтаграмму, связь будет разорвана, и порт 500 станет доступен для использования следующей дейтаграммой, имеющей адрес порта 500 в качестве адресов портов источника и назначения.
Пока порт 500 связан, при получении действительной ответной дейтаграммы, имеющей адрес порта 500 в качестве адресов портов источника и назначения и правильный IP-адрес источника, шлюз будет обрабатывать эту дейтаграмму путем подставления IP-адреса локальной машины в поле IP-адреса назначения в головной метке дейтаграммы и затем перешлет эту дейтаграмму по ЛВС для доставки на эту локальную машину. Когда дейтаграмма выходит из шлюза, шлюз разрывает связь между локальным IP-адресом и портом 500 и возобновляет нормальную обработку дейтаграмм.
Если ответ, имеющий правильный IP-адрес источника и адрес порта 500 в качестве адресов портов, не будет получен из внешней сети, шлюз завершает время ожидания после короткого предопределенного промежутка времени. Если шлюз должен завершить время ожидания до получения действительного ответа, то обмен сообщениями ISAKMP не может быть завершен, но должен быть повторно инициирован.
После завершения протокола ISAKMP и во время сеанса безопасной шифрованной связи шлюз будет выполнять трансляцию локальных адресов по ссылке на индекс параметров безопасности в головной метке ESP входящих и исходящих дейтаграмм. Шлюз будет также обеспечивать, чтобы каждый тип пакета (тип 50 для пакета ESP) был правильным и дейтаграмма могла пройти через шлюз. В отдельных случаях безопасный сеанс связи через ВЧС будет прерван или будет начат новый сеанс. Первым указанием шлюза на это будет получение им дейтаграммы типа 50, в которой IP-адреса распознаются, но индекс параметров безопасности, ассоциируемый с адресом назначения, отсутствует во внутренней таблице. Когда это случается, шлюз будет направлять дейтаграмму в IP-адрес назначения, используя новый индекс параметров безопасности, а также будет устанавливать значение индекса параметров безопасности адреса назначения (SPI-in (входной ИПБ) или SPI-out (выходной ИПБ) в зависимости от направления передачи). После получения ответа на передачу шлюз будет заменять нуль в таблице полей индекса параметров безопасности новым индексом параметров безопасности для IP-адреса назначения.
Поскольку шлюз по настоящему изобретению не шифрует или дешифрует сообщения, а просто пересылает полезную нагрузку (которая может быть шифрованной или нешифрованной) в ЛВС или в Интернет для обработки на получающей машине, он не требует функции интенсивной обработки и может быть использован для частных ЛВС, для которых расходы и простота настройки и технического обслуживания являются важными аспектами.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Дальнейшие цели и преимущества настоящего изобретения могут быть поняты из подробного описания предпочтительного варианта его осуществления, взятого вместе с прилагаемыми чертежами, на которых:
Фиг.1 представляет виртуальную частную сеть, в которой удаленная ЛВС, использующая локальные IP-адреса, связана по сети с основным компьютерным сайтом через внешнюю сеть, которой может являться Интернет. ЛВС соединена с внешней сетью через шлюз ТСА.
На Фиг.2 показана карта принятия решений, используемая шлюзом по настоящему изобретению для обработки дейтаграмм UDP, полученных из ЛВС для передачи в Интернет.
На Фиг.3 показана карта принятия решений по операциям, используемым шлюзом по настоящему изобретению для обработки дейтаграмм UDP, полученных из Интернета для передачи на устройство в ЛВС.
Фиг.4 приведена для ссылки на следующие карты, показанные на Фиг.5, 6 и 7. Фиг.4 представляет собой таблицу, содержащую IP-адреса локальных машин в ЛВС (LI-L3), внутренний и внешний адреса шлюза и IP-адреса внешних устройств (“целей” Т1–Т3) во внешней сети.
На Фиг.5а-5с показаны типовые поля внутренней таблицы шлюза с перекрестными ссылками на локальные адреса машин в ЛВС (L-1, L-2,... L-x) и внешние IP-адреса внешних устройств (Т-1-Т-3) с индексами параметров безопасности (ИПБ), используемыми для аутентификации шифрованных дейтаграмм. Выходной ИПБ (SPI-out) представляет собой индекс параметров безопасности шифрованной дейтаграммы, выходящей из шлюза к устройству в Интернете, тогда как входной ИПБ (SPI-in) представляет собой индекс параметров безопасности шифрованной дейтаграммы, предназначенной для локальной машины в ЛВС. Каждое изображение таблицы (a, b и с) содержит значения головной метки для источника, назначения и ИПБ в разные моменты времени. Изменяющиеся значения указывают на начало нового сеанса связи одной локальной машиной с целевой машиной.
На Фиг.6 показаны типовые поля в головных метках дейтаграмм, которыми обменивается одна локальная машина с одним устройством во внешней сети. Значения головной метки изменяются посредством обработки шлюзом по настоящему изобретению.
На Фиг.7 показаны типовые поля в головных метках дейтаграмм, которыми обмениваются три локальные машины (L-1-L-3) в ЛВС с тремя целевыми машинами (Т-1-Т-3) во внешней сети после того, как они изменены посредством обработки шлюзом по настоящему изобретению.
Фиг.8 представляет собой схематическое изображение сигналов, проходящих между устройством обработки дейтаграмм и таймером.
ПРЕДПОЧТИТЕЛЬНЫЙ ВАРИАНТ ОСУЩЕСТВЛЕНИЯ ИЗОБРЕТЕНИЯ
На Фиг.1 показана виртуальная частная сеть (ВЧС), в которой частная локальная вычислительная сеть (ЛВС) 10 соединена с сайтом 30, находящимся в Интернете 50. ЛВС 10 использует локальные IP-адреса и соединена с Интернетом через шлюз 20 трансляции сетевых адресов (ТСА) по настоящему изобретению. Сайт 30 может находиться в правлении предприятия или может являться одной или любого числа частных ЛВС, используемых многонациональной корпорацией, общеобразовательным учреждением или любым другим сайтом, который часто посещается пользователями из удаленных мест. Такие сайты обычно имеют брандмауэр или шлюз 35, способный осуществлять шифрование и другие защитные меры. Такой шлюз будет способен открывать пакет, дешифровать или иным образом получать доступ к его содержимому, а также выполнять трансляцию адреса, маршрутизацию, деинкапсуляцию и управление данными. Поскольку такие устройства способны поддерживать ISAKMP и другие протоколы IPSec, они делают это путем открытия и дешифрования пакетов и управления данными, а в общем они очень дорогостоящие и мощные, чтобы эффективно применяться в удаленных сайтах ЛВС, нуждающихся в создании ВЧС с основным сайтом.
Сервер 40 в основном сайте использует программное обеспечение для сервера ВЧС. Компьютеры 15 в удаленных сайтах используют соответствующее клиентское программное обеспечение ВЧС, которое выполняет протоколы безопасности IPSec на каждом компьютере.
Компьютер 15 в ЛВС 10 будет сообщаться с устройствами в Интернете через шлюз 20 путем направления дейтаграммы IP на сервер 40 в сайте 30.
Дейтаграммы, полученные шлюзом 20, обрабатываются в соответствии с картами принятия решений, показанными на Фиг.2 и 3. Хотя схемы последовательности операций на Фиг.2 и 3 показывают операции обработки и последовательность этих операций, порядок выполнения некоторых функций особого значения не имеет, и некоторые из операций могут быть выполнены в ином порядке, чем показанный на схемах без воздействия на конечный результат. Например, на Фиг.2 и 3 показано, что первой операцией после получения дейтаграммы шлюзом является определение типа дейтаграммы, тогда как последней операцией является выполнение трансляции IP-адреса, которая необходима до пересылки дейтаграммы через шлюз. В некоторых вариантах осуществления изобретения операция трансляции адреса может быть помещена на какой-то более ранний этап этого процесса, и это не повлияет на результат процесса. Так как очередность трансляции IP-адреса не имеет особого значения для общего процесса, определение того, когда должна производиться такая трансляция, является вопросом технического выбора.
Как показано на Фиг.2, после получения дейтаграммы из ЛВС шлюз проверит ее на предмет шифрования. Он осуществит это путем проверки поля “Следующая головная метка” в головной метке IP для определения типа данной дейтаграммы и того, шифрована ли она. Тип 50 (ESP) дейтаграммы указывает, что дейтаграмма шифрованная, и информация об адресе порта может быть недоступной.
Продолжая следовать дереву решений согласно Фиг.2, если дейтаграмма шифрованная, шлюз проверит ИПБ дейтаграммы, чтобы проверить, есть ли она в поле выходного ИПБ во внутренней таблице шлюза. Типовые поля из такой таблицы показаны на Фиг.5а-5с. Если ИПБ дейтаграммы обнаружен в поле выходного ИПБ внутренней таблицы, шлюз модифицирует IP-адрес источника дейтаграммы так, чтобы он являлся внешним IP-адресом шлюза, и направит дейтаграмму во внешнюю сеть для доставки внешнему устройству.
Если дейтаграмма шифрованная, но ИПБ не присутствует во внутренней таблице шлюза, то согласно дереву решений по Фиг.2 шлюз предположит, что эта дейтаграмма инициирует новый сеанс связи. В этом случае шлюз установит поле входного ИПБ своей внутренней таблицы на нуль (0) и установит выходной ИПБ в соответствии с новым ИПБ из дейтаграммы. Эти изменения во внутренней таблице показаны на Фиг.5а и 5b, на которых “новый” ИПБ (“14662”), которого не было в поле выходного ИПБ внутренней таблицы шлюза на Фиг.5а, показан как введенный в поле выходного ИПБ, а входной ИПБ был установлен на нуль (0) на Фиг.5b. Шифрованная дейтаграмма затем будет направлена на внешний шлюз после трансляции IP-адреса источника из IP-адреса локального устройства во внешний IP-адрес шлюза. Эти операции показаны на Фиг.5b и 5с.
Продолжая следовать карте принятия решений, показанной на Фиг.2, если дейтаграмма нешифрованная, шлюз далее проверит адрес порта назначения дейтаграммы. Если адрес порта назначения любой кроме порта 500, шлюз внесет адрес порта источника в свою внутреннюю таблицу, соотнесет его с IP-адресом (локальным) источника и затем подставит произвольный, не используемый адрес порта в поле адреса порта источника в головной метке IP. Он также внесет новый адрес порта в свою внутреннюю таблицу, снова соотнеся его с IP-адресом (локальным) источника. Этот процесс, когда он используется для нешифрованных дейтаграмм, не имеющих порта 500 в качестве адреса порта, называется “нормальной трансляцией адреса” для дейтаграмм, исходящих из ЛВС. Эти операции трансляции показаны на Фиг.6, строки 1 и 2. Дейтаграмма затем будет направлена в Интернет для маршрутизации в IP-адрес назначения.
На Фиг.2 показано, что, если адреса портов источника и назначения дейтаграммы являются портом 500, шлюз должен далее проверить свои таблицы, чтобы убедиться в том, что порт 500 уже связан с IP-адресом. Если порт 500 свободен, то шлюз “свяжет” порт 500 с (локальным) IP-адресом источника дейтаграммы, создаст ассоциацию между портом и (внешним) IP-адресом назначения и пошлет сигнал пуска внутреннего таймера. Шлюз также будет обрабатывать такую дейтаграмму, поставляя внешний IP-адрес шлюза вместо локального IP-адреса в поле IP-адреса источника. Однако он не будет транслировать адрес порта источника. Приостанавливая “нормальную” трансляцию адреса порта источника, шлюз обеспечивает целевой машине возможность распознать дейтаграмму как дейтаграмму ISAKMP. Эти операции также показаны на Фиг.6, строки 5 и 6.
На Фиг.2, если дейтаграмма, поступающая из ЛВС, имеет порт 500 в качестве адресов портов источника и назначения, но порт 500 уже связан с каким-то другим локальным IP-адресом, то шлюз не сможет связать порт 500 по отношению к обрабатываемой дейтаграмме. В этом случае шлюз будет обрабатывать такую дейтаграмму “в нормальном режиме”, как если бы она не являлась дейтаграммой ISAKMP. To есть, он будет транслировать адрес порта источника дейтаграммы в произвольное число и будет транслировать IP-адрес источника во внешний IP-адрес шлюза. Затем шлюз пошлет эту дейтаграмму в Интернет, где она будет сброшена целевой машиной, поскольку она не соответствует дейтаграмме ISAKMP. Это событие показано на Фиг.7 в строках 15 и 16.
На Фиг.3 показана карта принятия решений с указанием операций, которые будет выполнять шлюз при обработке дейтаграмм, полученных из Интернета. После получения дейтаграммы шлюз сначала проверит ее тип и, если дейтаграмма шифрованная, проверит, имеется ли ИПБ в его внутренней таблице. Если ИПБ будет распознан, IP-адрес назначения будет транслирован в IP-адрес локального устройства, и дейтаграмма будет пропущена в ЛВС для доставки на локальное устройство. В том случае, если ИПБ не будет распознан, шлюз далее проверит, равно ли его поле входного ИПБ, соответствующее IP-адресу источника дейтаграммы, нулю (0). Если входной ИПБ равен нулю, шлюз предположит, что эта дейтаграмма является первым ответом нового сеанса связи, и заменит нуль в поле входного ИПБ на ИПБ дейтаграммы. Затем шлюз транслирует IP-адрес назначения так, чтобы он являлся локальным IP-адресом устройства в ЛВС, и направит эту дейтаграмму в ЛВС для доставки. Это событие показано на Фиг.5b и 5с. На Фиг.5b входной ИПБ для локальной машины L-1 был установлен на нуль. После получения шлюзом дейтаграммы из Интернета, которая имеет ИПБ 3288, шлюз не обнаружит этот ИПБ в поле входного ИПБ. Далее шлюз проверит, сохраняет ли поле входного ИПБ нулевое значение. После определения того, что входной ИПБ для локальной машины L-1 равен нулю, шлюз заменит нуль на ИПБ дейтаграммы (“3288”) и направит дейтаграмму в ЛВС. Это показано на Фиг.5с.
На Фиг.3, если дейтаграмма из Интернета нешифрованная, шлюз проверит, имеет ли она адрес порта 500. Если нет, дейтаграмма пройдет “нормальную” трансляцию адреса для дейтаграмм из внешней сети, означающую, что локальный адрес порта и локальный IP-адрес устройства в ЛВС будут подставлены в поля назначения дейтаграммы, и дейтаграмма будет направлена в ЛВС для доставки. Эта “нормальная” трансляция адреса для дейтаграмм из Интернета показана на Фиг.6 в строках 3 и 4.
Снова обращаясь к Фиг.3, если же дейтаграмма имеет адрес порта 500, шлюз должен далее проверить, связан ли порт 500 с локальным IP-адресом и ассоциируется ли он с IP-адресом источника (внешнего) дейтаграммы. Если да, то дейтаграмма действительная и будет пропущена в ЛВС после трансляции IP-адреса назначения из внешнего IP-адреса шлюза в IP-адрес локального устройства. После пересылки дейтаграммы в ЛВС шлюз освободит порт 500. Это событие показано на Фиг.6 в строках 7 и 8.
Если, на Фиг.3, порт 500 связан с локальным IP-адресом и ассоциируется с другим внешним IP-адресом чем тот, который обнаружен в IP-адресе источника дейтаграммы, то дейтаграмма не действительная и не будет далее обрабатываться шлюзом. Это событие можно видеть на Фиг.7 в строках 25-31. В строках 25 и 26 показано, что локальная машина L-1 посылает дейтаграмму ISAKMP на целевую машину Т-1. В этот момент порт 500 связан с IP-адресом локальной машины L-1 и ассоциируется с IP-адресом целевой машины Т-1. Однако, как показано на Фиг.7, таймер выключается до получения ответа от Т-1 шлюзом, и в строке 27 показано, что порт 500 освобождается. В строках 28 и 29 показано, что локальная машина L-3 посылает дейтаграмму ISAKMP на целевую машину Т-3, связывая порт 500 с IP-адресом L-3 и создавая ассоциацию с IP-адресом Т-3. Пока порт 500 связан, от Т-1 поступает ответ. Однако, поскольку порт 500 связан и ассоциируется с IP-адресом Т-3, ответ от Т-1 сбрасывается. Это показано в строках 30 и 31 на Фиг.7.
На Фиг.5а-5с показана внутренняя таблица шлюза, в которой сохраняются IP-адреса и числа ИПБ для шифрованных сообщений между локальными компьютерами и целевыми машинами в Интернете. Поля для L-1, L-2, L-x и Т1-Т3 включены для удобства ссылок и не находятся во внутренних таблицах шлюза. На Фиг.5 поле выходного ИПБ сохраняет ИПБ для каждой целевой машины в течение безопасного сеанса связи с отдельным компьютером в ЛВС. Поле входного ИПБ содержит соответствующий ИПБ, который будет распознаваться локальным компьютером как обозначающий действительную дейтаграмму, предназначенную для него. На Фиг.5а показана начальная таблица. Восемь (8) локальных компьютеров участвуют в сеансах шифрованной связи с тремя целевыми машинами, Т1-Т3, в течение времени существования данных в таблице. На это указывает тот факт, что каждая локальная машина имеет входной ИПБ, ассоциируемый с ее IP-адресом. Хотя в таблице показаны только три целевые машины, можно сказать, что каждая целевая машина использует отличный от других выходной ИПБ для связи с каждой локальной машиной. Таким образом, целевая машина знает, какой источник генерировал шифрованную дейтаграмму.
На Фиг.5b показаны те же локальные и целевые компьютеры, что и на Фиг.5а. Здесь, однако, выходной ИПБ для сеанса связи между L-1 и Т-1 новый, что указывает на новый сеанс связи между компьютерами. Первым указанием для шлюза на то, что происходит новый сеанс связи, является получение им из ЛВС шифрованной дейтаграммы, имеющей ИПБ “14662”, которого нет в таблице. Шлюз направляет дейтаграмму в Интернет, но также модифицирует свою таблицу, чтобы поместить новый ИПБ в поле выходного ИПБ, ассоциируемое с IP-адресами источника и назначения для этой дейтаграммы. Шлюз также ставит нуль в поле входного ИПБ в качестве метки, указывающей, что также ожидается новый входной ИПБ. На Фиг.5с показано, что новый ИПБ “3288” был включен в дейтаграмму, полученную от Т-1. Этот ИПБ был внесен в поле входного ИПБ шлюза, и дальнейшие сообщения между L-1 и Т-1 во время этого сеанса связи будут использовать эти ИПБ для аутентификации своих сообщений.
На Фиг.6 показан поток типовых дейтаграмм через шлюз по настоящему изобретению, направляемых одним компьютером в ЛВС на удаленную целевую машину в Интернете. Каждая строка таблицы представляет информацию дейтаграммы либо на интерфейсе ЛВС со шлюзом, либо на интерфейсе Интернета со шлюзом. Последовательные строки представляют данные, поступающие в шлюз с одной стороны и выходящие из шлюза на другой стороне. Шлюз имеет один IP-адрес, который может быть локальным IP-адресом на интерфейсе шлюза с ЛВС и глобальным IP-адресом на интерфейсе шлюза с Интернетом. Колонки на Фиг.6 указывают сторону шлюза, которую проходит дейтаграмма, тип дейтаграммы, IP-адрес источника и адрес порта дейтаграммы, IP-адрес назначения и адрес порта дейтаграммы и индекс параметров безопасности (ИПБ) для шифрованных дейтаграмм типа 50, использующих протокол ESP (инкапсулированная полезная нагрузка безопасности).
В строке 1 Фиг.6 показана дейтаграмма UDP, поступающая на локальный интерфейс шлюза и имеющая IP-адрес источника, соответствующий локальному компьютеру L-1, и IP-адрес назначения для целевой машины в Интернете, Т-1. Для облегчения восприятия на Фиг.4 представлена таблица IP-адресов с перекрестными ссылками на локальные устройства L-1-L-3 и целевые машины назначения Т-1-Т-3. Адресом порта источника для L-1 является порт 6404, а портом назначения целевой машины является порт 80. Так как дейтаграмма нешифрованная и не несет номер порта 500, она подвергается нормальной трансляции, при которой “произвольный” адрес порта, порт 10425, подставляется в поле адреса порта источника, и внешний IP-адрес шлюза подставляется вместо IP-адреса источника дейтаграммы. Хотя транслированный адрес порта источника назван “произвольным”, он обычно будет следующим в последовательности, взятой из ведущегося шлюзом пула не зарезервированных и в настоящее время не используемых адресов портов.
Когда дейтаграмма выходит из шлюза, как показано на Фиг.6 в строке 2, функция трансляции адреса шлюза заменяет в головной метке дейтаграммы IP-адрес источника внешним IP-адресом шлюза и указывает произвольное число как порт источника. В строках 3 и 4 показана ответная дейтаграмма от целевой машины. В строке 3 дейтаграмма UDP от целевой машины указывает внешний IP-адрес шлюза в качестве IP-адреса назначения и адрес порта, произвольно присвоенный шлюзом в качестве порта назначения. Так как дейтаграмма не шифрованная и не имеет порт 500 в качестве адреса порта, эта дейтаграмма подвергается нормальной трансляции адреса порта назначения и IP-адреса, после чего она направляется в ЛВС. В строке 4 шлюз подставил локальный IP-адрес локального компьютера и адрес порта в поля назначения головной метки перед отправкой дейтаграммы в ЛВС.
В строке 5 Фиг.6 локальный компьютер инициирует протокол ISAKMP с целевой машиной. Тип дейтаграммы указан как ISAKMP, адресами порта источника и назначения является порт 500. Когда шлюз определит, что адресом порта назначения является порт 500, он проверяет, связан ли порт 500 в настоящее время с каким-либо IP-адресом. Поскольку это не так, шлюз пересылает дейтаграмму, транслируя только поле IP-адреса источника во внешний IP-адрес шлюза, но не изменяя адрес порта источника.
На Фиг.6 строки 5-16 показывают шесть стандартных обменов дейтаграммами по протоколу подтверждения связи ISAKMP, необходимых для создания ассоциаций безопасности для поддержки полностью шифрованных и аутентифицированных дейтаграмм. Хотя некоторые режимы ISAKMP используют меньшее количество обменов, на Фиг.6 показан основной режим. После установления ассоциации безопасности локальный компьютер и целевая машина начинают связь, используя шифрованные дейтаграммы по протоколу ESP. Здесь действительность дейтаграмм поддерживается посредством использования чисел индекса параметров безопасности (ИПБ) в поле ИПБ головной метки дейтаграммы.
Каждый хост распознает дейтаграмму, “адресованную” его ИПБ, который может быть модифицирован в течение сеанса связи по взаимному согласию хостов при необходимости обеспечить постоянную безопасность. Когда шифрованная дейтаграмма проходит через шлюз, как показано на Фиг.6, строки 17 и 18, шлюз не модифицирует ни ИПБ источника, ни ИПБ назначения, хотя IP-адрес источника дейтаграммы транслируется во внешний IP-адрес шлюза.
Таким образом, когда шлюз получает шифрованную дейтаграмму, она будет указана как дейтаграмма типа 50 (ESP). Получив дейтаграмму этого типа, шлюз проверит индекс параметров безопасности (ИПБ), чтобы убедиться, занесен ли этот ИПБ в его внутреннюю таблицу. Если да, то шлюз будет транслировать IP-адрес источника или назначения дейтаграммы, в зависимости от конкретного случая, и направит эту дейтаграмму в ЛВС или Интернет в зависимости от направления передачи. Однако, если ИПБ дейтаграммы из ЛВС не присутствует во внутренней таблице шлюза, а источник и назначение являются распознанными IP-адресами, шлюз предположит, что начался новый сеанс связи. В этом случае он пропустит дейтаграмму во внешнюю сеть, оставив новый ИПБ без изменений, но записав этот новый ИПБ в поле выходных ИПБ своей внутренней таблицы и поместив нуль в поле входного ИПБ. В строках 25 и 26 можно видеть, что появился новый ИПБ, указывая на новый сеанс связи. Это событие соответствует Фиг.5b, где “0” в поле входного ИПБ соответствует новому выходному ИПБ “14662”. В строках 27 и 28 ответный пакет из внешней сети показывает, что старый ИПБ “9802” был заменен новым ИПБ “3288”.
Фиг.7 аналогична Фиг.6, за тем исключением, что она иллюстрирует прохождение через шлюз по настоящему изобретению дейтаграмм между тремя компьютерами в ЛВС, обозначенными L-1, L-2 и L-3, и тремя целевыми машинами в Интернете, Т-1, Т-2 и Т-3, имеющими уникальные глобальные IP-адреса. На Фиг.4, для облегчения понимания, приведена таблица, содержащая IP-адреса этих устройств. Как показано на Фиг.7, передача, обозначенная "L-1 Out", представляет собой передачу от локального компьютера L-1 в шлюз. "Т-1 In" обозначает передачу из шлюза на целевую машину Т-1. "Т-1 Out" представляет собой передачу от целевой машины Т-1 в шлюз, тогда как "L-1 In" представляет передачу от шлюза на компьютер L-1.
Как показано в строках 1-8 на Фиг.7, компьютеры L-1 и L-2 проводят “чистый” сеанс связи с целевыми машинами Т-1 и Т-2. В строке 9 компьютер L-1 начинает сеанс связи по протоколу ISAKMP с машиной Т-1. В строках 9-14 показаны первые три сообщения, обмен которыми произошел между машинами L-1 и Т-1 во время протокола ISAKMP. В строке 15 компьютер L-3 начинает обмен сообщениями по протоколу ISAKMP-1 с машиной Т-3. Однако в это время порт 500 связан с L-1 и ассоциируется с IP-адресом Т-1, ожидая ответа ISAKMP-4 от Т-1. В этой ситуации дейтаграмма от L-3 не может связать порт 500, и ее адрес порта источника будет транслирован. Как таковой, компьютер L-3 не сможет завершить передачу, которая была начата в строке 15.
После этого в строках 17-18 ответ Т-1 (ISAKMP-4) получен шлюзом и направлен компьютеру L-1, и порт 500 сразу же становится доступным. Таким образом, когда компьютер L-3 повторно пытается осуществить передачу ISAKMP-1 в строке 19, передача проходит успешно.
В строках 19-20 на Фиг.7 передача ISAKMP-1 с компьютера L-1 связывает порт 500 с IP-адресом компьютера L-3. Таким образом, когда L-1 пытается осуществить передачу ISAKMP-5, что показано в строках 21-22, порт 500 не доступен, и шлюз просто транслирует адрес порта назначения с порта 500 в “произвольный” номер порта - в данном случае “9063” - и направляет дейтаграмму в Интернет, где целевая машина Т-1 не распознает ее в качестве дейтаграммы ISAKMP. Однако после того, как L-3 освободит порт 500, что показано в строках 23-24, следующая попытка компьютера L-1 осуществить передачу ISAKMP-5 заканчивается успешным приемом машиной Т-1. Однако машина Т-1 задерживает ответ, и, как показано в строке 27, порт 500 освобождается от связи с компьютером L-1 и, как показано в строках 28-29, немедленно захватывается компьютером L-3 для передачи ISAKMP-3. Таким образом, когда ответ ISAKMP-6 поступает с машины Т-1 в шлюз, как показано в строках 30 и 31, порт 500 блокирован, и дейтаграмма игнорируется. После этого компьютер L-1, не получивший ответа на свое сообщение ISAKMP-5, повторно передает его в строках 34-35, и ответ от целевой машины Т-1 получен в строках 36-37. После этого обмена подтверждениями ISAKMP компьютеры L-1 и Т-1 могут осуществлять безопасный сеанс связи, используя протокол ESP, как показано в строках 38-39 и 42-43.
В строках 38-57 на Фиг.7 показана работа шлюза с несколькими дейтаграммами, которыми обмениваются несколько локальных компьютеров и целевых машин. Дейтаграммы UDP показаны в строках 40-41, дейтаграммы ESP - в строках 42-43 и 52-53, а дейтаграммы ISAKMP - в строках 44-45. Хотя в таблице на Фиг.7 показаны разные IP-адреса для устройств, на практике может произойти так, что ряд процессов будет проходить на одном и том же устройстве. Замена уникальных адресов портов источника шлюзом и использование ИПБ для различения шифрованных передач обеспечивает, что дейтаграммы, исходящие из многочисленных процессов, выполняемых на одной машине, будут направлены по правильному назначению.
На Фиг.8 показаны инициация и передача сигналов между схемой 100 обработки дейтаграмм и таймером 110. При возникновении события, требующего связать адрес порта с IP-адресом, сигнал 120 будет послан на таймер для начала отсчета времени. После истечения соответствующего интервала времени таймер пошлет сигнал 140, указывающий на то, что время истекло, и в этом случае любой связанный порт будет освобожден. В течение этого интервала времени, если поступит ожидаемая дейтаграмма и ранее связанный порт должен быть освобожден, сигнал выключения 130 будет послан на таймер, указывая, что таймер должен быть установлен в исходное состояние для ожидания следующего сигнала о начале отсчета времени. Очевидно, что в данной области техники известны многочисленные схемы отсчета времени, и конкретная конфигурация, показанная на Фиг.8, является только одним из многих возможных вариантов осуществления такой схемы.
Из вышеизложенного специалисты в данной области техники поймут, что описанный здесь предпочтительный вариант осуществления настоящего изобретения не является единственным средством осуществления изобретения на практике и что для практического осуществления могут быть выбраны другие варианты без отхода от смысла и объема настоящего изобретения. Например, хотя предпочтительный вариант осуществления настоящего изобретения описан со ссылкой на порт 500, который был зарезервирован исключительно для использования с протоколом ISAKMP, настоящее изобретение может быть осуществлено в том же порядке для обработки дейтаграмм, направленных по адресам других портов, которые могут быть в будущем присвоены другим процессам или протоколам. В частности, многие игры, в которые играют по Интернету, требуют использования определенных портов на локальных и внешних машинах, которые не могут выдерживать нормальную трансляцию адреса. Кроме того, хотя настоящее изобретение было описано главным образом в отношении связей между частной ЛВС и Интернетом, очевидно, что шлюз согласно настоящему изобретению может быть использован в любом интерфейсе между двумя сетями и будет функционировать точно так же, как было описано.
Прилагаемая формула изобретения предназначена для того, чтобы охватить модификации и изменения в рамках смысла и объема настоящего изобретения.
ПРОМЫШЛЕННАЯ ПРИМЕНИМОСТЬ
Наиболее успешно заявленное техническое решение промышленно применимо в вычислительной технике при создании шлюза, допускающего использование протокола ISAKMP для аутентификации и обменов ключами между компьютером, имеющим не глобальный IP-адрес, и хостом, использующим Интернет в качестве среды для передачи, а также при создании шлюза, разрешающего любому количеству компьютеров в частной ЛВС, использующей локальные IP-адреса, инициировать или получать сообщения через Интернет, используя протокол ISAKMP.
Изобретение относится к вычислительным сетям. Его использование позволяет получить в качестве технического результата возможность использовать протокол ISAKMP для аутентификации и обменов ключами между компьютером, не имеющим глобального IP-адреса, и ресурсами Интернета. Шлюз трансляции сетевых адресов обеспечивает нормальную трансляцию IP-дейтаграмм, проходящих из локальной вычислительной сети, использующей локальные IP-адреса, во внешнюю сеть, но приостанавливает трансляцию служебного адреса (порта) источника, когда порт зарезервирован для какого-то конкретного протокола, такого как протокол ISAKMP с подтверждением связи, который является частью модели протокола IPSec. Обмены протоколами ISAKMP требуют, чтобы и передающий и целевой компьютеры использовали один и тот же служебный адрес (порт). Путем предоставления сетевого интерфейса, который не транслирует служебный адрес (порт) источника, этот шлюз позволяет инициировать и вести защищенные шифрованные передачи с использованием протокола IPSec между локальной вычислительной сетью, использующей локальные IP-адреса, и серверами в Интернете. 4 с. и 14 з.п.ф-лы, 8 ил.
| СПОСОБ ПЕРЕДАЧИ СООБЩЕНИЙ ЭЛЕКТРОННОЙ ПОЧТЫ В ЛОКАЛЬНОЙ СЕТИ И УСТРОЙСТВО ДЛЯ ОСУЩЕСТВЛЕНИЯ СПОСОБА | 1996 |
|
RU2144270C1 |
