BR0109033B1 - Porta de tradução de endereço de rede e método de processamento de datagramas ip - Google Patents

Description

"PORTA DE TRADUÇÃO DE ENDEREÇO DE REDE E MÉTODO DE PROCESSAMENTO DE DATAGRAMAS IP" A rede privada virtual VPN que utiliza TCP/IP permite comunicações seguras de alta velocidade entre sites remotos de computação que utilizam a internet como um meio de comunicação. A informação que passa entre os sites pela internet pode ser protegida contra a intercepção por pessoas indesejadas ou hackers maliciosos através de uma variedade de medidas de segurança. As medidas eficazes de segurança devem, no mínimo, incorporar funções que garantam quaisquer ou todas as seguintes proteções: Integridade de dados contra a modificação maliciosa ou inadvertida de dados durante o trânsito; prevenção contra ataques de negação de serviço ao empregar medidas anti- repetição; autenticação de origem; confidencialidade de endereço de origem e outra informação de registro inicial durante o trânsito e proteção de carga útil de pacote contra a intercepção indesejada. Um modelo padrão para fornecimento da segurança na internet é o conjunto de Segurança de Protocolo da Internet, IPSec. 0 IPSec funciona com o protocolo de comunicações TCP/IP a fim de fornecer comunicações seguras entre os dispositivos conectados à internet ou conectados a LANs privadas (Redes de Área Local) que estão, por si próprias, conectadas à internet. 0 conjunto de protocolo (Protocolo de Controle de Transmissão/Protocolo Internet) TCP/IP utiliza endereços IP para identificar cada dispositivo em uma rede. Um endereço IP global identifica exclusivamente um dispositivo na internet. Tais dispositivos podem ser compu- tadores, impressoras, routers, chaves, portas ou outros dis- positivos de rede. Os dispositivos que possuem endereços IP globais podem ser diretamente referidos como uma origem ou destino na Internet. O protocolo de comunicações TCP/IP, en- tretanto, não está limitado exclusivamente à internet, mas pode ser utilizado também como LANs privadas. As LANs priva- das, que utilizam TCP/IP, utilizam frequentemente endereços IP "locais" para dispositivos de rede. Embora nenhum dos dois dispositivos em uma LAN privada possa dividir o mesmo endereço IP local, as LANs privadas são isoladas da internet e os dispositivos locais na LAN não são visíveis a partir da internet. Os endereços IP para os dispositivos locais, por- tanto, não precisam ser "globalmente" únicos. Uma LAN que utiliza endereços IP locais estará conectada à internet a- través de uma porta, que é um dispositivo que pode filtrar ou encaminhar as mensagens entre a LAN e a internet. Tal porta está diretamente ligada à internet, e é visível a ela, a porta deve ter um endereço IP globalmente único para comu- nicação pela internet. Entretanto, uma vez que a LAN não é diretamente visível a partir da internet, as máquinas locais na LAN não requerem endereços IP que são globalmente únicos. 0 TCP/IP é o protocolo de co- municação que é utilizado na internet. A informação a ser transmitida ao se usar o TCP/IP está contida nos "datagra- mas" . Um datagrama consiste de um "pacote" discreto de in- formação em que um ou mais registros iniciais estão anexa- dos. Os registros iniciais contêm informação necessária ao TCP/IP para direcionar o pacote ao seu destino pretendido e para garantir o seu apropriado manusearaento durante o trân- sito. Cada datagrama é endereçável individualmente e pode ser um datagrama TCP orientado por conexão ou um datagrama UDP (Protocolo de Datagrama de Usuário) "sem conexão". Cada datagrama UDP inclui um registro inicial IP e um registro inicial UDP. O registro inicial IP contém, pelo menos, um endereço IP de "origem" e um endereço IP de "destino", en- quanto o registro inicial UDP inclui endereços de serviço de origem e destino (endereços de porta, dados como números).

Em Ipv4, os endereços IP possuem 32 bits em comprimento e estão associados com o formato agora familiar xxx.xxx.xxx.xxx. Nesse formato, cada segmento de três dígi- tos é um octeto binário que representa um número entre 0 e 255. Um endereço IP completo combina o endereço de uma rede lógica ou segmento de rede com o endereço de um "nó" (dispo- sitivo) na rede. O endereço da rede ou segmento de rede pode incluir os primeiros 3, 6 ou 9 dígitos do endereço IP. Um dispositivo na rede ou segmento de rede ê identificado atra- vés de um endereço de nó que consiste daqueles dígitos rema- nescentes que não são utilizados no endereço de segmento de rede ou rede.

Os endereços de serviço de destino e origem contidos em um registro inicial UDP são nú- meros de 16-bit, conhecidos, diversamente como "portas" ou "soquetes" que são utilizados para direcionarem o pacote a um processo pretendido que é ativo no envio ou recebimento do dispositivo. 0 termo "porta" ou "endereço de porta", con- forme utilizado aqui, refere-se a um campo de endereço de serviço em um registro inicial UDP. Embora em teoria, hã tantas portas quanto endereços em um número de 16-bit, por convenção muitos endereços de porta foram reservados para processos estabelecidos. Portanto, por exemplo, a porta 80 é reservada para HTTP, e as portas 20 e 21 são reservadas para FTP. Através da utilização de endereços de porta, os dados que chegam em uma máquina local percorrendo mais de um pro- cesso serão direcionados ao processo pretendido. Aonde um processo que percorre um host local não é um dos processos reservados, o host local pode selecionar qualquer número de porta a partir de uma série de números de porta não reserva- dos para identificar o processo de "origem". Um pacote de resposta que se refere ao número de porta no campo de "des- tino" será direcionado ao processo.

Com o explosivo crescimento do uso da internet durante a última década, e seu crescimento projetado para o futuro, os endereços IP globalmente únicos tornaram-se um recurso escasso. Além disso, muitas empresas que mantêm as LANs privadas possuem pouca ou nenhuma neces- sidade para que cada computador e dispositivo na LAN possuam um endereço IP global único. Muitas dessas empresas preferi- ríam, em qualquer caso, manter a confidencialidade de seus endereços IP nos computadores. Ao contrário de gastar recur- sos globais limitados ao fornecer a cada dispositivo local um endereço IP global único, muitas LANs privadas utilizam os endereços IP locais para dispositivos na LAN. A fim de fornecer conectividade â internet, tais LANs empregarão um endereço globalmente único singular a ser utilizado na in- ternet através da porta que separa a LAN da internet.

Através da utilização de téc- nicas de Tradução de Endereço de Rede NAT, um dispositivo de porta que separa uma LAN da internet pode fornecer seguran- ça, assim como um firewall, enquanto permite que as máquinas com endereços IP locais acessem à internet através do ende- reço global único da porta. Um dispositivo em uma LAN pode possuir um endereço IP local estático, ou pode possuir um endereço IP local nomeado dinamicamente a ela na entrada do sistema. A porta mantém uma tabela de tradução com os ende- reços IP locais para cada dispositivo na LAN. Um pacote UDP enviado de uma máquina local e destinado para internet terá seu endereço IP local e o endereço de porta identificados nos campos de origem dos registros iniciais UDP e IP, res- pectivamente. A porta receberá o pacote da máquina local e substituirá seu endereço IP globalmente único externo e um novo endereço de porta (extraído de um grupo de endereços de porta não utilizados e não reservados) em campos de origem dos registros iniciais IP e UDP. A seguir, atualizará o CRC (Verificação por Redundância Cíclica) e fará quaisquer ou- tras mudanças necessárias para garantirem a integridade dos dados, depois então enviará o pacote à internet. Como parte do processo, a porta atualizará sua tabela de tradução in- terna à referência cruzada do endereço IP da máquina local com o endereço de porta de origem registrado originalmente por aquela máquina, com o novo endereço de porta de origem designado ao pacote de limite da internet e com o endereço IP de destino.

Além do recebimento de uma resposta da internet, a porta reconhecerá seu próprio ende- reço IP no registro inicial do pacote e examinará o endereço da porta de destino do pacote de entrada. Se ela reconhecer o endereço de porta de destino em sua tabela interna, a por- ta substituirá o endereço IP da máquina local de referência cruzada e o endereço de porta original nos campos de destino do pacote, atualizará o CRC e quaisquer outros parâmetros necessários, e então enviará o pacote à LAN, aonde ele será recebido pela máquina local e direcionado ao processo apro- priado. Dessa maneira, um número de computadores em uma LAN que possui apenas endereços IP locais pode se comunicar pela internet através de um endereço IP globalmente único singu- lar .

Embora as portas NAT apresen- tem segurança de firewall contra o acesso direto da LAN a partir da internet, elas não podem fornecer segurança contra a intercepção ou modificação de um pacote encaminhado à LAN, enquanto em trânsito na internet, e não garantem a "integri- dade" das objeções que se criam dentro da LAN. Portanto, a segurança apresentada pelo IPSec é uma proteção necessária para as LANs que devem manter a segurança enquanto realizam a interface com a internet.

Uma implementação comum do IP-Sec consiste em fornecer a segurança para as VPNs que consistem de, pelo menos, um site principal de computação e uma ou mais LANs remotas. 0 site principal e as LANs remotas estão conectados pela internet, utilizando o meio de mais alta ve- locidade para se comunicar entre os sites, apesar de linhas privadas alugadas significativamente mais caras. A desvanta- gem ao utilizar a internet como um meio de transmissão, en- tretanto, é que a internet é inerentemente insegura, e apre- senta pouca ou nenhuma proteção inerente contra a espiona- gem, detecção, "imitação" ou em último caso roubo, modifica- ção ou desvio de mensagens pelos hackers. Portanto, hã a ne- cessidade de medidas abrangentes de segurança aonde trans- missões de dados seguras são exigidas. O protocolo IPSec im- plementa medidas de segurança para garantir a autenticação dos dados e a integridade dos mesmos. O conjunto de protocolo IPSec implementa a segurança na camada da rede do modelo de refe- rência de rede (Interconexão de Sistemas Abertos) OSI de múltiplas camadas. O conjunto inclui um número de protocolos separados que é utilizado em conjunção entre si para garan- tir a segurança dos datagramas UDP que conduzem informação através da internet. A arquitetura base dos sistemas concor- dantes do IPSec é explicada em RFC2401, "Security Architec- ture for the Internet Protocol", S.Kent e R.Atkisnon (Novem- bro de 1998). O protocolo AH (Registro Inicial de Autentica- ção) garante a integridade dos dados, autenticação de ori- gem, e incorpora medidas "anti-repetição" a fim de impedir os ataques de negação de serviço. O protocolo ESP (Carga de Segurança de Encapsulação) apresenta proteções similares ao AH, porém adiciona a característica adicional da criptogra- fia da carga útil. Tanto os registros iniciais AH como ESP possuem um campo para o índice de Parâmetros de Segurança (SPI). O SPI é um valor pseudoaleatório de 32-bit que ê uti- lizado para identificar uma Associação de Segurança SA para o datagrama. Outras informações referentes a esses protoco- los podem ser encontradas em RFC1826, "IP Authentication Header", por R.Atkinson (Agosto de 1995) e RFC2406, "IP En- capsulating Security Payload (ESP)", S.Kent e R.Atkinson (Novembro de 1998}. O ISAKMP/Oakley (Associação de Segurança da Internet e Protocolo Chave de Administração, também, ge- ralmente, referidos como Troca de Chave da Internet - IKE) é um protocolo de sinais de estabelecimento de comunicação que estabelece os parâmetros para uma sessão segura entre dois hosts e apresenta a troca de chave e outra informação de se- gurança que é utilizada para implementar a sessão segura e permitir a transmissão dos dados criptografados. O protocolo ISAKMP/Oakley (a seguir referido simplesmente como ISAKMP) envolve as trocas inicias de mensagens não criptografadas para fornecimento de ambas máquinas com dados de inicializa- ção dos quais a autenticação pode ser estabelecida e as cha- ves seguras para a criptografia dos dados podem ser criadas.

Uma explicação desses processos pode ser encontrada em RFC2409, "The Internet Key Exchange," D.Harkins e D.Carrel (Novembro de 1998). Uma vez que os suficientes parâmetros de segurança que estabelecem as Associações de Segurança SAs entre os hosts foram trocados, todas as subseqüentes trans- missões serão criptografadas e totalmente autenticadas de acordo com os protocolos de concordância. Naquele ponto, o protocolo ISAKMP termina. O endereçamento subsequente é ba- seado no endereço IP para cada máquina e no SPI da máquina para aquela sessão. O SPI é único para cada máquina durante uma sessão. A porta para uma LAN privada manterá uma tabela interna, em que o "SPI-in" em um valor é referido de modo cruzado ao endereço IP da máquina local, e o "SPI-out" é re- ferido de modo cruzado ao endereço IP da máquina na internet que está se comunicando com a máquina local. O SPI para cada máquina é computado a partir da informação trocada durante as transmissões ISAKMP, e é conduzido no registro inicial AH ou ESP que está anexado aos pacotes UDP. Uma vez que os pro- tocolos IPSec podem ser embutidos para fornecer segurança em uma variedade de ambientes, um único datagrama pode incluir tanto um registro inicial AH como ESP, e pode criptografar alguma informação do registro inicial.

Cada um dos protocolos de se- gurança anteriormente mencionados modifica o pacote UDP ao dispor nova informação de registro inicial ao pacote, modi- ficando certos campos dentro do pacote para se adaptarem ao protocolo utilizado e, em alguns casos, criptografando a carga útil e todos ou partes de outros registros iniciais do pacote. Portanto, sob o IPSec, quando um datagrama UDP deixa um domínio "seguro" transitar por uma rede não confiável, ele normalmente consistirá de um registro inicial IP, um re- gistro inicial AH ou ESP (ou ambos) e uma carga útil encap- sulada. A informação de registro inicial incluirá um endere- ço de destino, um SPI, e a informação SA suficiente para ga- rantir que o datagrama alcance seu destino e possa ser au- tenticado ao host de destino. A encapsulação da carga útil garante que a informação contida dentro da carga útil seja recusada para as pessoas indesejadas e os hackers. O host de destino inicial para o datagrama pode ser um router, porta ou firewall entre uma LAN e a internet. Além da entrada no dispositivo no limite entre a LAN e a internet, o datagrama pode ser aberto, examinado ou descriptografado em sua tota- lidade ou em parte, analisado para outras informações de en- dereço e encaminhado para um endereço IP local na LAN. O protocolo ISAKMP de sinais de estabelecimento de comunicação utilizado no IPSec exige que ambos hosts que pretendem estabelecer uma sessão segura entre os mesmos utilizem um endereço de porta específica do processo (Porta 500) para as trocas inicias de mensagem. Por essa razão, a Porta 500 foi designada para uso exclusivo com o protocolo ISAKMP. Por convenção, os computadores que ten- tarem negociar os parâmetros de comunicações seguras ao em- pregarem o protocolo ISAKMP devem se comunicar estritamente através da Porta 50 0 de cada computador. Isto é, as mensa- gens do ISAKMP de cada computador devem identificar a Porta 500 tanto como endereços de porta de origem como de destino.

Se cada computador recebe um pacote em que a Porta 50 0 não está especificada como sendo tanto de origem como destino, o pacote será descartado.

Enquanto esse protocolo apre- senta garantia que aqueles dois hosts estão se comunicando entre si, ele torna-se incontrolãvel, quando um host está localizado em uma LAN que utiliza os endereços IP locais e uma porta NAT. Por exemplo, o Host A, que possui um endereço IP local em uma LAN remota protegido por uma porta NAT, de- seja estabelecer uma sessão segura com o Host B, localizado em um site de computação do escritório principal. O Host A

iniciaria o protocolo através do envio de um datagrama UDP descriptografado ao Host B, dando o "destino" como endereço IP do Host B, e o endereço de porta de destino como "Porta 500". Entretanto, quando o datagrama alcança a porta NAT que conecta a LAN remota a internet, a porta traduzirá o endere- ço de porta de destino em um número de porta arbitrário. A- lém da entrada do datagrama no Host B, o protocolo ΙΞΑΚΜΡ não será reconhecido, e o Host B não responderá. Os computa- dores falharão ao estabelecer uma sessão segura. Por causa dessa dificuldade, acreditou-se que o protocolo ISAKMP não pode ser utilizado para estabelecer uma VPN que utiliza uma porta NAT, aonde cada computador na LAN remota utiliza um local ao invés de um endereço IP global.

Portanto, é um objetivo dessa invenção fornecer uma porta que permitirá a utilização da autenticação do protocolo ISAKMP e as trocas de chave entre um computador que possui um endereço IP não global e um com- putador central que utiliza a internet como um meio de transmissão.

Ainda é um outro objetivo des- sa invenção fornecer uma porta que permitirá qualquer número de computadores em uma LAN privada que utiliza endereços IP locais a iniciar ou receber mensagens via internet utilizan- do o protocolo ISAKMP. É um outro objetivo dessa in- venção apresentar um método para o emprego de uma rede pri- vada virtual entre dois ou mais sites de LAN na internet, utilizando o protocolo ISAKMP para iniciar as comunicações seguras.

Esses e outros objetivos da invenção serão claros através da seguinte descrição.

De acordo com a presente in- venção, um computador que utiliza um endereço IP local em uma LAN remota ligada a uma rede externa, como por exemplo, a internet através de uma porta NAT usará o protocolo ISAKMP para trocar chaves e estabelecer SAs que suportarão uma ses- são segura sob IPSec. Para o trânsito de não ISAKMP, a porta efetua a tradução do endereço como normal. Entretanto, quan- do uma máquina na LAN origina uma mensagem de protocolo I- ΞΑΚΜΡ, a porta identificará o datagrama que contém os ende- reços de porta da Porta 500. Após encontrar tal datagrama, a porta traduzirá o endereço IP de origem, porém não traduzirá o endereço de porta de origem, deixando o mesmo na Porta 500, e enviará o pacote à internet com a Porta 500 designada como endereços de porta tanto de destino como origem. A por- ta atualizará também sua tabela interna para "ligar" a Porta 500 ao endereço IP local e associará aquela ligação ao ende- reço IP externo da máquina de destino por uma duração de tempo pré-determinada. Se uma reposta válida não for recebi- da dentro do período de tempo pré-determinado, a "ligação" entre a Porta 500 e o endereço IP local será liberada. Essa característica é necessária para garantir que a Porta 500 não seja presa indefinitivamente, como por exemplo, em uma situação em que uma transmissão de protocolo ISAKMP foi ini- ciada em um incorreto endereço IP de destino. Sob essas con- dições, a porta nunca recebería uma resposta válida. Se não houvesse um cronômetro para liberar a Porta 500 após um pe- ríodo durante o qual uma resposta válida não é recebida, a porta permanecería ligada ao endereço IP local até que a porta fosse restaurada. Para maiores condições, um período de dois segundos deveria ser um período de tempo suficiente para manter a ligação entre a Porta 500 e o endereço IP lo- cal, enquanto uma resposta válida é esperada.

Durante o tempo em que a Porta 500 está ligada a um endereço IP local, a porta continuará o processamento de datagrama normal de datagramas que não pos- suem os endereços de porta da Porta 500, enquanto é esperada uma resposta válida. Uma resposta válida será um datagrama que possui um endereço IP de origem que é o mesmo que o en- dereço IP externo que está associado com a Porta 500 e terá tanto os endereços de porta de destino como de origem como Porta 500. Enquanto se espera uma resposta válida, a porta ignorará outros datagramas UDP da rede externa que possui os endereços de porta de destino e origem da Porta 500, mas não o próprio endereço IP de origem. Além disso, enquanto a Por- ta 500 está ligada a um endereço IP local, os datagramas re- cebidos da LAN que possuem endereços de porta de destino e origem da Porta 500 passarão pela tradução de endereço "nor- mal", em que o endereço de porta de origem da Porta 500 será traduzido em um endereço de porta arbitrário e não utiliza- do, antes de ser enviado à rede externa. Uma vez que tal da- tagrama não possui tanto o endereço de porta de destino como de origem da Porta 500, ele não é um datagrama ISAKMP váli- do, e será ignorado ao alcançar seu destino IP. Se o período de ligação da Porta 500 em um endereço IP local deveria ex- pirar sem que um datagrama válido fosse recebido pela porta, a ligação seria liberada, e a Porta 500 se tornaria disponí- vel para a utilização através do próximo datagrama que pos- sui um endereço de porta de destino e origem de Porta 500.

Enquanto a Porta 500 está li- gada, após receber um datagrama de resposta válida que pos- sui os endereços de porta de destino e origem da Porta 500 e o correto endereço IP de origem, a porta processará o data- grama ao substituir o endereço IP na máquina local no campo de endereço IP de destino do registro inicial do datagrama então passará o datagrama através da LAN para a entrega na máquina local. Quando o datagrama deixa a porta, a porta li- berará a ligação entre o endereço IP local e a Porta 500 e resumirá o processamento normal do datagrama.

Se uma resposta que possui o próprio endereço IP de origem e os endereços de porta da Porta 500 não for recebida da rede externa, a porta esgotará o tempo após um curto período de tempo pré-determinado. Se a porta deve esgotar o tempo antes de uma resposta válida ser recebida, a troca de mensagem de ISAKMP não pode ser comple- tada, porém deve ser reiniciada.

Uma vez que o protocolo ISAKMP foi completado, e uma sessão segura criptografada está a ca- minho, a porta efetuará as traduções de endereço local ao se referir ao SPI no registro inicial ESP de datagramas de en- trada e saída. A porta garantirá que cada tipo de pacote (tipo 50 para um pacote ESP) seja correto para o datagrama a ser passado através da porta. Ocasionalmente, uma sessão se- gura através de uma VPN será interrompida ou uma nova sessão iniciada. A primeira indicação da porta dessa sessão será o seu recebimento de um datagrama de tipo 50, em que os ende- reços IP são reconhecidos, porém o SPI associado com o des- tino não aparece na sua tabela interna. Quando isso aconte- ce, a porta enviará o datagrama ao endereço IP de destino que utiliza o novo SPI, e também estabelecerá o valor SPI de destino (SPI-in ou SPI-out, dependendo da direção da trans- missão) na sua tabela no novo valor, e o valor SPI de origem a zero. Ao receber uma resposta para a transmissão, a porta substituirá o zero na tabela de campo SPI com o novo SPI pa- ra o endereço IP de destino. Já que a porta dessa invenção não criptografa nem descriptografa mensagens, mas simples- mente passa a carga útil (que pode ser criptografada ou des- criptografa) através da LAN ou na internet para o processa- mento na máquina de recebimento, ela não exige a funcionali- dade de processamento intensivo e pode ser utilizada para as LANs privadas, em que a despesa e simplicidade da configura- ção e manutenção são consideradas.

Outros objetivos e vantagens da presente invenção podem ser encontrados na descrição de- talhada da realização preferida, quando considerada em con- junção com os desenhos em anexo, nos quais: a figura 1 descreve uma rede privada virtual em que uma LAN remota que utiliza os endereços IP locais é es- tabelecida em rede com um site principal de com- putador através de uma rede externa que pode ser a internet. A LAN estã conectada com a rede ex- terna através de uma rede NAT; a figura 2 descreve um gráfico de decisão utilizado pela porta dessa invenção para processar os datagra- mas UDP recebidos da LAN para transmissão na in- ternet ; a figura 3 descreve um gráfico de decisão de etapas utili- zadas pela porta dessa invenção para processar os datagramas UDP recebidos da internet para en- trega em um dispositivo na LAN; a figura 4 é apresentada para referência na sequência dos gráficos mostrados nas Figuras 5, 6 e 7. A Figu- ra 4 é uma tabela que contém endereços IP de má- quinas locais em uma LAN (L-l até L-3) , os ende- reços IP externos e internos de uma porta e os endereços IP dos dispositivos externos ("alvos" T-l até T-3) em uma rede externa; as figuras 5a-5c mostram campos representativos de uma ta- bela interna da porta que se refere de modo cru- zado aos endereços IP locais das máquinas em uma LAN (L-l, L-2,...L-x) e endereços IP externos de dispositivos externos (T-l até T-3) com SPIs (índices de parâmetro de segurança) utilizados para autenticar os datagramas criptografados. O SPI-out representa o SPI de um datagrama cripto- grafado que deixa a porta para um dispositivo na internet, enquanto o SPI-in representa o SPI de um datagrama criptografado destinado para uma máquina local na LAN. Cada visão da tabela, a, b e c reflete os valores de registro inicial para a origem, destino e SPI em diferentes pontos de tempo. Os valores de mudança significam o início de uma nova sessão através de uma máquina local com uma máquina alvo; a figura 6 mostra campos representativos nos registros ini- ciais do datagrama que são trocados entre uma única máquina local e um único dispositivo na rede externa. Os valores de registro inicial são modificados através do processamento pela porta dessa invenção; a figura 7 mostra os campos representativos nos registros iniciais do datagrama que são trocados entre as três máquinas locais (L-l até L-3) em uma LAN, e três alvos (T-l até T-3) em uma rede externa, conforme eles são modificados através do proces- samento pela porta dessa invenção; e a figura 8 é um diagrama esquemãtico de sinais que passam entre a função de processamento do datagrama e o cronômetro.

Na figura 1, uma rede privada virtual VPN é mostrada, sendo que uma rede de área local privada LAN 10 está conectada a um site de computação 30 lo- calizado na internet 50. A LAN 10 utiliza endereços IP lo- cais e está conectada à internet através da porta de tradu- ção de endereço de rede NAT dessa invenção 20. O site de computação 30 pode ser uma sede de negócios, ou uma de qual- quer número de LANs privadas utilizadas por uma sociedade multinacional, uma dependência educacional, ou qualquer ou- t tro site que seja acessado freqüentemente a partir de locais remotos. Tais sites normalmente terão um firewall ou porta 35 capaz de percorrer a criptografia e outras aplicações de segurança. Tal porta terá a capacidade de abrir um pacote, descriptografã-lo ou de qualquer outra formar acessar seus conteúdos, e realizar a tradução de endereço, encaminhamen- to, desencapsulação, e também funções de manipulação de da- dos. Enquanto tais dispositivos são capazes de suportar o ISAKMP e outros protocolos IPSec, eles realizam isso ao a- brirem e descriptografarem pacotes, e manipularem dados, e são, muito caros e poderosos para serem empregados eficien- temente em sites de LAN remotos que precisam estabelecer uma VPN com o site principal de computação.

Um servidor 40, no site prin- cipal, percorre o software de servidor VPN. Os computadores 15 nos sites remotos percorrem o software do cliente VPN apropriado que executa os protocolos de segurança IPSec em cada computador.

Um computador 15 na LAN 10 se comunicará com dispositivos em ou através da internet pela porta 20 ao enviar um datagrama IP a um servidor 40 no site de computação 30.

Os datagramas recebidos na porta 20 são processados, de acordo com os gráficos de deci- são mostrados nas Figuras 2 e 3. Embora os fluxogramas das Figuras 2 e 3 mostrem ambas etapas de processamento e uma seqüência para as etapas, a ordem para efetuação de alguma das funções não é decisiva, e algumas das etapas podem ser realizadas em uma ordem diferentemente do que é mostrado nos fluxogramas sem produzir efeito no resultado final. Por exem- plo, as figuras 2 e 3 mostram que a primeira etapa após um datagrama ser recebido pela porta é determinar o tipo de da- tagrama, enquanto a última etapa consiste em efetuar a tra- dução do endereço IP que é necessária antes do datagrama ser passado pela porta. Algumas realizações, entretanto, poderí- am ocupar a etapa de tradução de endereço em algum ponto adiante no processo, e isso não afetaria o surgimento do processo. Uma vez que a ordem de tradução do endereço IP não é decisiva para o processo todo, a determinação de quando essa tradução deve ser feita é uma questão de escolha de en- genharia .

Conforme mostrado na figura 2, ao receber um datagrama da LAN, a porta verificará se o da- tagrama está criptografado. Fará isso ao verificar o campo "Próximo Registro Inicial" no registro inicial IP para de- terminar qual o tipo de datagrama que se está conduzindo, e para ver se o datagrama foi criptografado. Um tipo de data- grama de 50 ESP indica que o datagrama é criptografado, e a informação de endereço da porta pode não estar disponível.

Continuando através da árvore de decisão da figura 2, se o datagrama for criptografado, a porta verificará o SPI do datagrama para ver se ele aparece no campo SPI-out da tabela interna da porta. Os campos re- presentativos de tal tabela são mostrados nas figuras 5a-5c.

Se o SPI do datagrama for encontrado no campo SPI-out da ta- bela interna, a porta modificará o endereço IP de origem do datagrama para o endereço IP externo da porta, e enviará o datagrama â rede externa para entrega em um dispositivo ex- terno .

Se o datagrama for criptogra- fado, porém o SPI não aparece na tabela interna da porta, então de acordo com o gráfico de decisão da figura 2, a por- ta admitirá que o datagrama está iniciando uma nova sessão.

Nesse caso, a porta identificará o campo SPI-in de sua tabe- la interna como zero 0 e estabelecerá o SPI-out no novo SPI do datagrama. Essas modificações à tabela interna são refle- tidas nas figuras 5a e 5b, em que um "novo" SPI "14662" que não apareceu no campo SPI-out da tabela interna da porta na figura 5a é mostrado como sendo introduzido no campo SPI- out, e o SPI-in foi identificado como zero 0 na figura 5b. O datagrama criptografado será então enviado à porta externa após o endereço IP de origem ter sido traduzido a partir da- quele dispositivo local ao endereço IP externo da porta. Es- sas etapas são mostradas nas figuras 5b e 5c.

Continuando com o gráfico de decisão da figura 2, se o datagrama não for criptografado, a porta verificará a seguir o endereço de porta de destino do datagrama. Se o endereço de porta não for nada além da Porta 500, a porta introduzira o endereço de porta de origem na sua tabela interna, irá cruzar sua referência com o endereço IP de origem (local), e então substituira um endereço de porta não utilizado e arbitrário no campo de endereço de porta de origem do registro inicial IP. Também introduzirá o novo endereço de porta em sua tabela interna, novamente cru- zará a referência ao endereço IP da origem (local). Esse processo, que é utilizado para os datagramas descriptografa- dos que não possuem a Porta 500 como um endereço de porta, deve ser referido como "tradução de endereço normal" para datagramas que se originam na LAN. Essas traduções são mos- tradas na figura 6, linhas 1 e 2. O datagrama será então en- viado à internet para o encaminhamento no endereço IP de destino.

Na figura 2, aonde os endere- ços de porta de destino e de origem do datagrama de entrada são a Porta 500, a porta deve verificar suas tabelas para ver se a Porta 5 00 jã está ligada a um endereço IP. Se a Porta 500 está livre, então a porta "ligará" a Porta 500 ao endereço IP de origem (local) do datagrama, criará uma asso- ciação entre a porta e o endereço IP de destino (externo), e enviará um sinal para acionar o cronômetro interno. A porta processará também o datagrama ao substituir o endereço IP externo da porta para o endereço IP local no campo de ende- reço IP de origem. Entretanto, não traduzirá o endereço de porta de origem. Ao suspender a tradução "normal" do endere- ço de porta de origem, a porta garante que a máquina alvo será capaz de reconhecer o datagrama como sendo um datagrama ISAKMP. Essas etapas são também mostradas na figura 6, li- nhas 5 e 6.

Na figura 2, se um datagrama de entrada da LAN possui um endereço de porta de destino e de origem da Porta 50 0, porém a Porta 500 jã está ligada a algum outro endereço IP local, então a porta não pode ligar a Porta 500 à mensagem que está sendo processada. Naquele momento, a porta processará o datagrama "normalmente", como se ele não fosse um datagrama ISAKMP. Isto é, traduzirá o endereço da porta de origem do datagrama em um número arbi- trário e traduzirá o endereço IP de origem para aquele ende- reço IP externo da porta. A porta enviará, então, o datagra- ma â internet, aonde ele será rejeitado pelo alvo, porque ele não se adapta a um datagrama ISAKMP. Esse caso é descri- to na figura 7, nas linhas 15 e 16.

Na figura 3, um gráfico de de- cisão é mostrado, resumindo as etapas da porta que seguirão nos datagramas de processamento recebidos da internet. Após o recebimento de um datagrama, a porta verificará, primeira- mente, seu tipo e, se o datagrama for criptografado, verifi- cará se o SPI aparece em sua tabela interna. Se o SPI for reconhecido, seu endereço IP de destino será traduzido para ser o endereço IP do dispositivo local, e o datagrama será passado à LAN para a entrega no dispositivo local. Se o SPI não for reconhecido, a porta verificará, a seguir, se o seu campo SPI-in que corresponde ao endereço IP de origem do da- tagrama é zero 0. Se o SPI-in for zero, a porta admitirá que o datagrama é a primeira resposta de uma nova sessão e subs- tituirá o zero no campo SPI-in com o SPI do datagrama. A porta então traduzirá o endereço IP de destino para o ende- reço IP local do dispositivo na LAN, e enviará o datagrama à LAN para envio. Esse evento é mostrado nas figuras 5b e 5c.

Na figura 5b, o SPI-in para a máquina local L-l foi indicado como zero. Após o recebimento da porta de um datagrama da internet que tem um SPI de 3288, a porta não encontrará a- quele SPI em seu campo SPI-in. A porta verificará, a seguir, se o campo SPI-in está mantido a um valor zero. Após a de- terminação de que o SPI-in para a máquina local L-l é zero, a porta substituirá o zero com o SPI do datagrama "3288" e enviará o datagrama à LAN. Isso é mostrado na figura 5c.

Na figura 3, se o datagrama da internet não for criptografado, a porta verificará se ele possui um endereço de porta de 500. Se ele não possuir, o datagrama passará pela tradução de endereço "normal" para datagramas da rede externa, indicando que o endereço de por- ta local e o endereço IP local do dispositivo na LAN sejam substituídos nos campos de destino do datagrama, e o data- grama será enviado à LAN para envio. Essa tradução de ende- reço "normal" para datagramas da internet é mostrada na fi- gura 6, nas linhas 3 e 4.

Novamente, referindo-se à fi- gura 3, se o datagrama não possui um endereço de porta de 500, a porta deve verificar se a Porta 500 está ligada a um endereço IP local e está associada com o endereço IP da ori- gem (externa) do datagrama. Se estiver, então o datagrama é válido, e ele será passado à LAN após o endereço IP de des- tino ter sido traduzido a partir daquela porta externa ao endereço IP do dispositivo local. Ao passar o datagrama na LAN, a porta liberará a Porta 500. Esse evento é ilustrado na Figura 6, nas linhas 7 e 8.

Se, na figura 3, a Porta 500 for ligada a um endereço IP local, e está associada com um endereço IP externo, ao invés do que encontrado no endereço IP de origem do datagrama, então o datagrama não é válido e não será também processado pela porta. Esse evento pode ser visto na figura 7, nas linhas 25-31. Nas linhas 25 e 26, a máquina local L-l envia um datagrama ISAKMP ao alvo T-l.

Nesse ponto, a Porta 500 é ligada ao endereço IP da máquina local L-l e está associada ao endereço IP de alvo T-l. En- tretanto, conforme mostrado na figura 7, o cronômetro "con- ta" antes que uma resposta seja recebida na porta de T-l, e, na linha 27. A porta 500 é liberada. Nas linhas 28 e 29, a máquina local L-3 envia um datagrama ISAKMP no alvo T-3, li- gando a Porta 500 ao endereço IP da L-3' e criando uma asso- ciação com o endereço IP do T-3. Enquanto a Porta 500 está ligada, uma resposta é recebida do T-l. Entretanto, uma vez que a Porta 500 é ligada, e está associada ao endereço IP do T-3, a resposta do T-l é descartada. Isso é mostrado nas li- nhas 30 e 31 da figura 7.

As figuras 5a-5c descrevem uma tabela interna da porta em que os endereços IP e os números SPI para as comunicações criptografadas entre os computado- res locais e alvos na internet são mantidos. Os campos para "L-1", "L-2", "L-x" e "T-l" até "T-3" são incluídos para re- ferência e não aparecem nas tabelas internas da porta. Na figura 5, o campo "SPI-out" mantém o SPI para cada máquina alvo durante uma sessão segura com um computador específico na LAN. O campo "SPI-in" fornece o SPI correspondente que serã reconhecido pelo computador local, como representando um datagrama válido submetido a ele. A figura 5a mostra a tabela em um tempo inicial. Oito 8 computadores locais par- ticiparam das sessões criptografadas com três alvos, T-l até T-3, durante a duração dos dados da tabela. Isso é mostrado pelo fato de que cada máquina local mostra um SPI-in associ- ado com seu endereço IP. Embora apenas três alvos sejam mos- trados na tabela, pode ser verificado que cada alvo está u- sando um SPI-out diferente para comunicações com cada máqui- na local. Dessa maneira, um alvo identificará de qual fonte um datagrama criptografado foi criado. A figura 5b mostra o mesmo lo- cal e computadores alvos, conforme a figura 5a. Aqui, entre- tanto, o SPI-out para a sessão entre L-l e T-l é um novo SPI, indicando uma nova sessão entre os computadores. A pri- meira indicação da porta de que está ocorrendo uma nova ses- são é o seu recebimento de um datagrama criptografado a par- tir da LAN que possui um SPI-"14662"- que não está nessa ta- bela. A porta envia o datagrama â internet, mas também modi- fica sua tabela, para colocar o novo SPI no campo SPI-out associado com os endereços IP de destino e de origem para aquele datagrama. Ela também atribui um zero no campo SPI-in como um marcador para indicar que um novo SPI-in ê também esperado. A figura 5c mostra que um novo SPI -"32 88" - foi incluindo em um datagrama recebido do T-l. Aquele SPI foi introduzido no campo SPI-in da porta, e também as comunica- ções entre L-l e T-l durante essa sessão utilizarão aqueles SPI-s para autenticarem suas mensagens. A figura 6 demonstra grafica- mente o fluxo dos datagramas representativos através da por- ta dessa invenção por um único computador em uma LAN que se comunica com um alvo remoto na internet. Cada linha do grá- fico representa informação em um datagrama tanto na interfa- ce da LAN com a porta como a interface da internet com a porta. As linhas consecutivas representam os dados que en- tram na porta de um lado e que deixam a porta no outro. A porta possui um endereço IP, que pode ser um endereço IP lo- cal, em sua interface com a LAN, e um endereço IP global em sua interface com a internet. As colunas na figura 6 descre- vem o lado da porta que o datagrama é atravessado, o tipo de datagrama, o endereço IP de origem do datagrama e o endereço de porta, o endereço IP de destino do datagrama e o endereço de porta, e o índice de Parâmetro de Segurança SPI do data- grama para os datagramas criptografados do tipo 50 que uti- lizam o protocolo ESP (Carga de Segurança Encapsulada). A linha 1 da figura 6 mostra um datagrama UDP que entra na interface local da porta, e possui um endereço IP de origem que corresponde ao computa- dor local L-l e a um endereço IP de destino do alvo na in- ternet T-l. Para facilitar a leitura, a figura 4 apresenta uma tabela de endereços IP de referência cruzada com as de- signações locais L-l até L-3 e as designações alvo T-l até T-3. O endereço de porta de origem para L-l é a Porta 6404, e a porta de destino alvo é a Porta 80. Uma vez que o data- grama não é criptografado, e não apresenta um número de por- ta de 500, ele passa por uma tradução normal em que um ende- reço de porta "arbitrário", Porta 10425, é substituído no campo de endereço de porta de origem e o endereço IP externo I da porta é substituído pelo endereço IP de origem do data- grama. Embora o endereço de porta de origem traduzido seja considerado como "arbitrário", ele será, normalmente, o pró- ximo em uma seqüência de uma série de endereços de porta não utilizados atualmente e não reservados mantidos pela porta.

Conforme o datagrama sai da porta, como mostrado na figura 6, na linha 2, a função de tradução de endereço da porta substituiu o endereço IP ex- terno da porta no registro inicial do datagrama para o ende- reço IP de origem, e deu à porta de origem um número arbi- trário. As linhas 3 e 4 mostram o datagrama de resposta do alvo. Na linha 3, um datagrama UDP do alvo mostra o endereço IP de destino como sendo o endereço IP externo da porta, e uma porta de destino como sendo o endereço de porta arbitra- riamente nomeado pela porta. Uma vez que o datagrama não é criptografado e não possui um endereço de porta de 500, o datagrama passa pela tradução normal do endereço de porta de destino e o endereço IP, então, é enviado â LAN. Na linha 4, a porta substituiu o endereço IP local do computador local e o endereço de porta nos campos de destino do registro inici- al antes do envio do datagrama na LAN.

Na linha 5 da figura 6, o com- putador local inicia um protocolo ISAKMP com o alvo. O tipo de datagrama é mostrado como ISAKMP. Tanto os endereços de porta de destino como de origem são a Porta 500. Quando a porta determina que o endereço de porta de destino é a Porta 500, ela verifica se a Porta 500 estã atualmente ligada a qualquer endereço IP. Uma vez que não está, a porta passa o datagrama, traduzindo apenas o campo de endereço IP de ori- gem para mostrar o endereço IP externo da porta, mas sem al- terar o endereço de porta de origem.

Na figura 6, as linhas 5-16 mostram as seis trocas padrões de datagrama de "sinais de estabelecimento de comunicação" ISAKMP para estabelecer os SAs (Associações de Segurança) para suportar os datagramas completamente autenticados e criptografados. Embora alguns modos de ISAKMP utilizem poucas trocas, o modo principal é descrito na Figura 6. Após o estabelecimento dos SAs, o com- putador local e o alvo começam a ser comunicar utilizando os datagramas criptografados do protocolo ESP. Aqui, a validade do datagrama é mantida através da utilização dos números do índice de Parâmetro de Segurança - SPI - em um campo SPI do registro inicial do datagrama. Cada host reconhece um data- grama "endereçado" nesse SPI, que pode ser modificado duran- te uma sessão através da concordância mútua dos hosts, con- forme necessário para garantir a segurança contínua. Quando um datagrama criptografado passa através da porta, conforme descrito na figura 6, linhas 17 e 18, nem o SPI de origem nem o de destino é modificado pela porta, embora o endereço IP da origem do datagrama seja traduzido para ser o endereço IP externo da porta.

Portanto, quando um datagrama criptografado é recebido pela porta, ele será indicado atra- vés de um datagrama do tipo 50 ESP. Após o encontro do tipo do datagrama, a porta verificará o índice de Parâmetro de Segurança SPI do datagrama para ver ser aquele SPI está re- I , gistrado em sua tabela interna. Se ele estiver, a porta tra- duzirá o endereço IP de destino ou de origem do datagrama, conforme apropriado, e enviará o datagrama à LAN ou à inter- net, dependendo da direção da transmissão. Entretanto, se o SPI de um datagrama da LAN não aparece na tabela interna da porta, e a origem e destino são endereços IP reconhecidos, a porta admitirá que uma nova sessão tenha sido iniciada. Nes- se caso, passará o datagrama na rede externa que deixa o no- vo SPI intacto, mas registrando o novo SPI no campo "SPI- out" de sua tabela interna e atribuindo um zero no campo "SPI-in". Nas linhas 25 e 28, pode ser verificado que um no- vo SPI apareceu, o que significa uma nova sessão. Esse even- to corresponde à figura 5b, aonde o "0" no campo "SPI-in" corresponde ao novo SPI-out de "14662". Nas linhas 27 e 28, o pacote de resposta da rede externa mostra que o SPI "9802" "antigo" foi substituído pelo "novo" SPI "3288" . A figura 7 é similar à figura 6, exceto pelo fato de que ilustra a passagem através da porta dessa invenção de datagramas entre os três computado- res em uma LAN, indicados L-l, L-2 e L-3, e três alvos na internet que possuem endereços IP globais únicos, T-l,T-2 e T-3. Na Figura 4, para a facilidade de referência, uma tabe- la que contém os endereços IP desses dispositivos é forneci- da. Conforme mostrado na figura 7, uma transmissão indicada "L-l out" representa uma transmissão do computador local L-l na porta. O "T-l in" representa uma transmissão da porta no alvo T-l. O "T-l out" representa uma transmissão do alvo T-l na porta, enquanto o "L-l in" representa uma transmissão da porta no computador L-l.

Conforme mostrado nas linhas 1-8 da figura 7, os computadores L-l e L-2 conduzem comuni- cações "claras" com alvos T-l e T-2. Na linha 9, o L-l ini- cia uma sessão ISAKMP com o T-l. As linhas 9-14 mostram as primeiras três mensagens trocadas entre L-l e T-l durante o protocolo ISAKMP. Na linha 15, o computador L-3 inicia uma troca de mensagem de ISAKMP-1 com T-3. Entretanto, naquele momento, a Porta 500 está ligada ao L-l e está associada com o endereço IP de T-l, esperando uma resposta ISAKMP-4 do T-l.

Nessa situação, o datagrama do L-3 não pode ligar a Porta 500, e seu endereço de porta de origem serã traduzido. Como tal, o L-3 não pode completar a transmissão que foi iniciada na linha 15.

Portanto, nas linhas 17-18, a resposta T-l ISAKMP-4 é recebida na porta e enviada ao L-l, e a Porta 500 torna-se imediatamente disponível. Portanto, quando o L-3 tenta novamente sua transmissão ISAKMP-1 na li- nha 19, a transmissão é realizada com êxito.

Nas linhas 19-20 da figura 7, a transmissão ISAKMP-1 do L-3 liga a Porta 500 ao endereço IPnoL-3. Portanto, quando o L-l tenta sua transmissão ISAKMP-5, nas linhas 21-22, a Porta 500 não está disponível, e a porta simplesmente traduz o endereço de porta de destino da Porta 500 em um número de porta "arbitrário" - nesse caso, "9063" - e envia o datagrama para a internet, aonde o alvo T-l não reconhecerá isso como um datagrama ISAKMP. Entretanto, após o L-3 liberar a Porta 500, nas linhas 23-24, a próxima ten- tativa do L-l para enviar sua transmissão ISAKMP-5 é recebida com o êxito pelo T-l. Entretanto, a resposta do T-l é lenta, na linha 27. A porta 500 é liberada de sua ligação em L-l,e, nas linhas 28-29, é imediatamente presa pelo L-3 para uma transmissão ISAKMP-3. Portanto, quando a resposta ISAKMP-6 do T-l chega na porta, conforme é mostrado nas linhas 30 e 31, a Porta 500 é bloqueada, e o datagrama é ignorado. Por- tanto, o L-l, não recebeu uma resposta para sua mensagem ISAKMP-5 , isso é retransmitido às linhas 34-35, e uma resposta do T-l é recebida nas linhas 36-37. Após os sinais de estabeleci- mento de comunicação do ISAKMP, o L-l e o T-l podem se comu- nicar de modo seguro, utilizando o protocolo ESP nas linhas 38-39 e 42-43.

As linhas 38-57 da figura 7 demonstram o manuseamento da porta de uma variedade de data- gramas entre um número de computadores locais e alvos. Os datagramas UDP são mostrados nas linhas 40-41, os datagramas ESP são mostrados nas linhas 42-43 e 52-53 e os datagramas ISAKMP são mostrados nas linhas 44-45. Enquanto o gráfico da figura 7 mostra diferentes endereços IP para cada dispositi- vo, na prática, pode ocorrer que um número de processos pas- sarã pelo mesmo dispositivo. A substituição das portas de origem únicas pela porta e a utilização do SPI's para dife- renciar as transmissões criptografadas garantem que os data- gramas que procedem de múltiplos processos que percorrem uma única máquina não serão direcionados erroneamente. A figura 8 descreve o início e transferência dos sinais entre o circuito de processamento de datagrama 100 e o cronômetro 110. Além da ocorrência de um evento que requer que um endereço de porta seja ligado a um endereço IP, um sinal 120 será enviado ao cronômetro para iniciar a contagem. Na expiração do intervalo apropriado, o cronômetro enviará um sinal 140 que indica que o tempo expi- rou, em tal caso qualquer porta que estã ligada será libera- da. No intervalo, se um datagrama esperado chegar, e uma porta previamente ligada for liberada, um sinal de inabili- tação 130 será enviado ao cronômetro que indica que o conta- dor deveria ser restaurado para esperar o próximo sinal a ser contado. Obviamente, há inúmeros circuitos de tempo co- nhecidos na técnica, e a configuração específica mostrada na Figura 8 é apenas uma de muitas realizações possíveis. A partir do anteriormente men- cionado, será entendido por aqueles especializados na técni- ca que a realização preferida descrita aqui não ê o único meio para a prática da invenção, e que outras realizações podem ser escolhidas na prática da invenção sem se desviar do seu âmbito e caráter. Por exemplo, embora a realização preferida seja descrita com referência à Porta 500, que foi re- servada exclusivamente para utilização com o protocolo ISAKMP, a invenção pode ser empregada da mesma maneira para o pro- cessamento dos datagramas destinados a outros endereços de porta que podem no futuro ser designados a outros processos ou protocolos. Em particular, muitos jogos na internet re- querem a utilização de portas específicas nas máquinas lo- cais e externas que não se opõem à tradução de endereço nor- mal. Adicionalmente, embora a invenção tenha sido descrita, principalmente, de acordo com as comunicações entre uma LAN privada e a internet, serã claro que a porta dessa invenção pode ser utilizada em qualquer interface entre duas redes e terá a mesma funcionalidade, conforme foi descrito.

As reivindicações anexadas aqui são para abranger as modificações e mudanças dentro do âmbi- to e caráter da presente invenção.

Claims (9)

1. "PORTA DE TRADUÇÃO DE ENDEREÇO DE REDE", conectando uma LAN (10) a uma rede externa, a referida LAN (10) utilizando endereços IP locais, a referida porta com um endereço que pode ser visto por dispositivos na referida LAN (10) e tendo um endereço IP externo que pode ser visto por dispositivos na referida rede externa, a referida porta compreendendo: uma pluralidade de tabelas internas, associando as combinações de endereços IP locais de dispositivos locais na referida LAN (10), endereços de IP externos de dispositivos externos na referida rede externa, valores de SPI - Internos e SPI - Externos, endereços de porta de origem, endereços de porta de destino, endereços de porta reservada e mantendo uma lista de endereços de portas reservadas, caracterizada por: meios para a realização de tradução normal do endereço sobre datagramas, passando da referida LAN (10) para a referida rede externa e datagramas passando da referida rede externa para a referida LAN (10), meios para a entrega de um datagrama de um dispositivo local na referida LAN (10) para um dispositivo externo na referida rede externa ao receber um datagrama de um dispositivo local na referida LAN (10) destinada a entregar um dispositivo externo na referida rede externa e determinar se o endereço de porta de destino para o referido datagrama está incluído na referida lista de endereços de portas reservadas e, se o referido endereço da porta de destino não estiver incluído na lista de endereços de portas reservadas, realizar tradução normal do endereço sobre o referido datagrama e passar o referido datagrama para a referida rede externa para roteamento e entrega ao referido dispositivo externo, e se o referido endereço da porta de destino estiver incluído na referida lista de endereços de portas reservadas, determinar se o endereço da porta de destino está vinculado ao referido endereço IP local do referido dispositivo local e, se o referido endereço de porta de destino estiver vinculado ao referido endereço IP local, realizar tradução normal do referido endereço sobre o referido datagrama e passar o referido datagrama para a referida rede externa para roteamento e entrega ao referido dispositivo externo, e se o referido endereço da porta de destino não estiver ligado ao referido endereço IP local do referido dispositivo local, modificar o referido endereço IP de origem do referido datagrama para ser o referido endereço IP externo da referida porta, vincular o referido endereço da porta de destino ao referido endereço IP local do referido dispositivo local,criar uma associação entre o referido endereço da porta de destino e o referido endereço IP externo do referido dispositivo externo e,passar o referido datagrama para a referida rede externa para roteamento e entrega ao referido dispositivo externo.

2. "PORTA DE TRADUÇÃO DE ENDEREÇO DE REDE", de acordo com a reivindicação 1, caracterizada por os meios para a entrega de um datagrama de um dispositivo local na referida LAN (10) a um dispositivo externo compreenderem, ainda, um meio para determinar se o referido datagrama é criptografado e, se o referido datagrama for criptografado, determinar se o SPI do referido datagrama é gravado no campo Externo - SPI, na referida tabela interna e, se o referido SPI for gravado no referido campo Externo - SPI, modificar o endereço IP de origem do referido datagrama para ser o referido endereço IP externo da referida porta e passar o referido datagrama para a referida rede externa para roteamento e entrega ao referido dispositivo externo.

3. "PORTA DE TRADUÇÃO DE ENDEREÇO DE REDE", de acordo com a reivindicação 2, caracterizada por compreender, ainda, se o referido SPI não estiver gravado no referido campo Interno - SPI da referida tabela interna, meios para a criação de um campo interno - SPI correspondente ao endereço IP local do referido dispositivo local igual a zero e configurar o referido campo Externo - SPI igual ao referido SPI, modificando o referido endereço IP de origem do referido datagrama para ser o referido endereço IP externo da referida porta e passar o referido datagrama para a referida rede externa para roteamento e entrega ao referido dispositivo externo.

4 . "PORTA DE TRADUÇÃO DE ENDEREÇO DE REDE", de acordo com a reivindicação 1, caracterizada por a porta de tradução de endereço de rede compreender, ainda, meios para a entrega de um datagrama de um referido dispositivo externo a um referido dispositivo local ao receber um datagrama de um referido dispositivo externo na referida rede externa prevista para entregar ao referido dispositivo local na referida LAN (10), meios para determinar se o referido datagrama é criptografado e, se o referido datagrama for criptografado, determinar se a SPI do datagrama é gravada no referido campo Interno - SPI da referida tabela interna e, se o referido SPI for gravado no referido campo Interno - SPI, modificar o endereço IP destino do referido datagrama para ser o referido endereço IP local do referido dispositivo local e passar o referido datagrama para a referida LAN (10) para roteamento e entrega do referido dispositivo local, e, se o referido SPI não for registrado no referido campo Interno - SPI da referida tabela interna, determinar se o referido campo Interno - SPI., correspondente ao referido endereço IP do referido dispositivo externo, é igual a zero e, se o referido campo Interno - SPI não for igual a zero, descartar o referido datagrama e , se o referido campo Interno - SPI for igual a zero, configurar o referido campo Interno - SPI igual o referido SPI, modificando o endereço IP de destino do referido datagrama para ser o referido endereço IP local do referido dispositivo local e passar o referido datagrama para a referida LAN (10) para entrega ao referido dispositivo local e, se o referido datagrama não estiver criptografado, determinar se o endereço da porta de destino para o referido datagrama está incluída na referida lista de endereços de portas reservadas e, se o referido endereço da porta de destino não estiver incluído na lista de endereços de portas reservadas, realizar tradução de endereço normal sobre o referido datagrama e passar o referido datagrama para a referida LAN (10) para entrega a um referido dispositivo local e, se o referido endereço da porta de destino estiver incluído na lista de endereços de portas reservadas, determinar se o referido endereço da porta de destino está vinculado ao endereço IP local do referido dispositivo local, se o referido endereço da porta de destino não estiver ligado ao referido endereço IP local, descartar o referido datagrama e, se o referido endereço da porta de destino estiver vinculado ao referido endereço IP local, modificar o referido endereço IP de destino do referido datagrama para ser o referido endereço IP local do referido dispositivo local, desvinculando o referido endereço IP local do referido endereço IP local, e passar o referido datagrama para uma referida LAN (10) para entrega ao referido dispositivo local.

5. "PORTA DE TRADUÇÃO DE ENDEREÇO DE REDE", de acordo com a reivindicação 1, compreendendo, ainda, um cronômetro (110), caracterizado por, após receber um sinal (120) de que um endereço de porta vinculou-se a um endereço IP, o referido cronômetro (110) começar a cronometrar por um período pré-determinado de tempo e, após a expiração do referido período pré- determinado de tempo, enviar um sinal (140) fazendo o referido endereço da porta desvincular-se do referido endereço IP e, ao receber um sinal (130) indicando que o referido endereço da porta desvinculou-se do referido endereço IP antes da expiração do referido período pré- determinado de tempo, o referido cronômetro (110) parar a cronometragem e reiniciar.

6. "PORTA DE TRADUÇÃO DE ENDEREÇO DE REDE", de acordo com a reivindicação 1, caracterizada por a referida rede externa ser a internet (50) .

7. "PORTA DE TRADUÇÃO DE ENDEREÇO DE REDE", de acordo com a reivindicação 6, caracterizada por a referida LAN (10) ser uma rede privada virtual.

8. "MÉTODO DE PROCESSAMENTO DE DATAGRAMAS IP", a partir de um dispositivo local em uma LAN (10), utilizando endereços IP locais através de um porta de tradução de rede para um dispositivo externo em uma rede externa, compreendendo as etapas de: manutenção de uma pluralidade de tabelas, associando endereços IP locais de dispositivos locais na referida LAN (10), endereços IP externos de dispositivos externos na referida rede externa, endereços das portas dos referidos dispositivos locais, endereços das portas dos referidos dispositivos externos, valores SPI - Internos, valores SPI - Externos e endereços das portas reservadas e uma lista de endereços de portas reservadas, caracterizado por: receber um datagrama da referida LAN (10), determinar se o endereço da porta de destino para o referido datagrama está incluído na referida tabela de endereços da porta reservada e, se o referido endereço da porta de destino não estiver incluído na referida tabela de endereços de portas reservadas, realizar a tradução normal de endereço sobre o referido datagrama e passar o referido datagrama para a referida rede externa, para roteamento e entrega ao referido dispositivo externo, e se o referido endereço de porta de destino estiver incluído na referida tabela de endereços de porta reservada, determinar se o referido endereço da porta de destino está vinculado a um endereço IP e se a referida porta de destino estiver vinculada a um endereço IP, realizar a tradução normal do endereço sobre o referido datagrama e passar o referido datagrama para a referida rede externa, para roteamento e entrega ao referido dispositivo externo, e se o referido endereço da porta de destino não estiver vinculado a um endereço IP, modificar o referido endereço IP da fonte para ser o referido endereço IP externo para o referido dispositivo externo, vinculando o referido endereço da porta de destino ao endereço IP local do referido dispositivo local e criando uma associação entre o referido endereço da porta de destino e o referido endereço IP externo do referido dispositivo externo, e passando o referido datagrama para a referida rede externa, para rot.eamento e entrega ao referido dispositivo externo.

9. "MÉTODO DE PROCESSAMENTO DE DATAGRAMAS IP", de acordo com a reivindicação 8, caracterizado por compreender, ainda, as etapas de: determinar se o referido datagrama está criptografado e se o referido datagrama estiver criptografado, determinar se o SPI no referido datagrama foi gravado no campo Externo - SPI de uma das referidas pluralidTades das tabelas internas e se o referido SPI foi gravado no referido campo Externo - SPI da .referida tabela interna, modificar o endereço IP de origem para ser o endereço IP externo da referida porta porta que passa o referido datagrama para a referida rede externa, para roteamento e entrega ao referido dispositivo externo, e se o referido SPI não foi registrado no referido campo Externo - SPI da referida tabela interna, configurar o referido campo Externo - SPI correspondente ao endereço IP do referido dispositivo externo igual ao referido SPI e definir o campo Interno - SPI da referida tabela interna para zero, modificando o referido endereço IP de origem para ser o referido endereço IP externo da referida porta, e passar o referido datagrama para a referida rede externa,para roteamento e entrega ao referido dispositivo externo".T