1

O objetivo deste módulo é apresentar o conceito de endereçamento IP privado, e como este

pode ser utilizado em redes IP corporativas ou residenciais. Este módulo discute também

como os mecanismos de proxy e NAT são utilizados para permitir que computadores com

endereços IP privado tenham acesso a recursos na Internet.

2

Originalmente, o endereçamento IP na Internet utilizava apenas o conceito de endereçamento

IP público. Neste modo de endereçamento, cada "host" conectado a Internet precisa ter um

endereço IP único em toda a rede.

No modelo original, não havia uma distinção clara entre computadores "clientes" e

"servidores". Na prática, todo computador conectado a Internet era potencialmente um

servidor, no sentido em que ele poderia ser endereçado por qualquer outro computador da

rede.

Como mostra a curva ilustrada na figura, a quantidade de hosts conectadas a Internet passou

a ter um crescimento exponencial a partir da década de 1990. Esse crescimento colocou em

cheque a arquitetura de endereçamento inicialmente concebida para a Internet, de forma que

no início dos anos 90, o IETF propôs duas soluções emergenciais para suportar a crescente

expansão do uso da Internet:

A primeira, foi o CIDR (Classless Inter Domain Routing), que permitiu a definição de sub-

redes com blocos de endereços menores, reduzindo o desperdício no processo de atribuição

de endereços IPv4.

A segunda, foi a introdução do conceito de endereçamento privado, que permitia utilizar

endereços não únicos na Internet. Esse conceito também passou a diferenciar computadores

com a função de cliente e servidor.

3

O controle global da atribuição de endereços IP é feito pelo IANA (Internet Assigned

Numbers Authority). A IANA é responsável por designar quantos blocos de endereço estão

disponíveis para cada região do planeta, evitando duplicação ou má distribuição dos

endereços. A IANA utiliza 5 autoridades de abrangência regional para agilizar o processo de

atribuição dos endereços em todo o mundo.

Essas autoridades são:

AfriNIC: responsável pela região da África

APNIC: responsável pela região Ásia e Pacífico

ARIN: responsável pela região da América do Norte

LACNIC: responsável pela região da América Latina e algumas ilhas do Caribe

RIPE NCC: responsável pela Europa, Oriente Médio e Ásia Central

A IANA também foi a responsável por definir os prefixos de rede que foram designados para

uso como endereçamento IP privado. O endereçamento privado foi definido originalmente

pela RFC 1918 datada de fevereiro de 1996.

4

Os prefixos de rede que foram definidos como endereçamento privado estão mostrados pela

tabela acima. Esses prefixos foram escolhidos entre os blocos de endereços disponíveis na

época em que a RFC 1918 foi elaborada.

Atualmente, a quantidade de endereços atribuídas para endereçamento privada pode ser

considerada exagerada. Somente o prefixo de classe A representa um total de 16 milhões de

endereços. Então, por que foram reservados também endereços nas classes B e C?

A justificativa para isso é que na época em que o conceito de endereçamento privado foi

introduzido, o CIDR não estava muito difundido. Isso significa que uma grande quantidade

de equipamentos não era capaz de trabalhar com máscaras de sub-rede de tamanho variável,

de forma que a rede 10 não podia ser livremente dividida. Dessa forma, uma faixa de IPs

privados foi escolhido em cada uma das classes.

De acordo com a RFC 1918, qualquer endereço IP da faixa privada pode ser utilizado

livremente, sem necessidade de solicitar registro a IANA ou a uma autoridade regional de

distribuição de endereços.

Contudo, a RFC 1918 define também que os roteadores da Internet não devem possuir rotas

para endereços privados. Isto é, pacotes que tenham endereços de destino privado não são

encaminhados pelos roteadores da Internet, sendo roteados apenas por roteadores privados,

que conectam sub-redes de uma mesma corporação.

5

Conforme dito anteriormente, a concepção inicial de endereçamento da Internet presumia

que qualquer host na Internet poderia ser acessado diretamente por qualquer outro host. Pelo

termo "acessado" entenda-se um host capaz de receber conexões, isto é, um host capaz de se

comportar como "servidor". Um host cliente, por outro lado, é capaz de iniciar conexões com

outros hosts, mas não é capaz de recebê-las.

A RFC 1918 introduz uma diferenciação de tipos de hosts, indicando que nem todos os hosts

precisam ter a habilidade de receber conexões. De acordo com essa RFC, os hosts foram

divididos em três categorias:

Hosts categoria 1: Hosts que se comunicam APENAS INTERNAMENTE em uma rede

corporativa. Isto é, hosts que não possuem nenhum tipo de conectividade com a rede Internet

pública. Essa categoria de host deve utilizar apenas endereços IP privados.

Hosts categoria 2: Hosts que se comunicam INDIRETAMENTE com a Internet pública. O

termo indiretamente significa que este host precisa sempre de um tradutor de endereços que

intermedie sua comunicação com a Internet. Os dois tipos de tradutores de endereços mais

comuns são o NAT (Network Address Translation) e o Proxy. Nessa categoria, hosts se

comportam basicamente como "clientes", e devem utilizar endereços privados.

Hosts categoria 3: Hosts que se comunicam DIRETAMENTE com o mundo externo. Isto é,

eles podem receber conexões de outros hosts da Internet. Essa categoria de host se tem a

habilidade de se comportar como "servidor".

6

A figura ilustra como hosts com endereçamento IP privado e público são tratados de forma

diferenciada em uma rede IP. A figura mostra uma rede corporativa dividida em duas sub-

redes: uma com endereços privados e outra com endereços públicos. A rede com endereços

privados é basicamente constituída por computadores clientes, enquanto que a rede com

endereços públicos é constituída por computadores que atuam como servidores (por

exemplo, servidores www, email, DNS, etc.)

O roteador 1 que conecta a rede pública com a rede privada está configurado para rotear

endereços privados. Isto é, ele possui rotas para encaminhar pacotes destinados a rede

privada. Já o roteador 2, não deve possuir rotas que permitam que computadores com

endereços IP privado se comuniquem com a Internet.

Dessa forma, hosts externos (vindos da Internet) podem abrir conexões com os servidores

através do roteador 2. Mas eles não podem abrir conexões com os clientes através do

roteador 1. De fato, os pacotes endereçados para os hosts privados nem sequer chegariam ao

roteador 2, pois nenhum roteador da Internet saberia para onde encaminhar esses pacotes.

Muitos administradores de redes costuma chamar endereços IP privados de não roteáveis.

Contudo, essa definição não é muito precisa. Endereços IP não são roteáveis na Internet, mas

são roteáveis por roteadores que conectam duas redes internas.

Nesse cenário, os hosts com IP privado são categoria I e os com IP público são categoria

III. Note que, sem o auxílio de um conversor de endereços, os hosts com IP privado não tem

nenhum acesso a Internet (nem como clientes), simplesmente porque são incapazes de

receber respostas vindas da Internet.

7

A figura ilustra como os endereços IP e as tabelas de roteamento podem ser configuradas

para o exemplo anterior.

A sub-rede pública recebeu a o prefixo 200.0.0.0/24 e a sub-rede privada recebeu o prefixo

192.168.0.0/24. Observe que o roteador 1 possui um endereço IP público e outro privado. O

roteador 2 possui apenas endereços públicos.

O roteador 1 possui apenas duas rotas, permitindo a conexão entre as redes pública e privada.

Contudo, ele não possui rota default, não podendo encaminhar pacotes para Internet.

Já o roteador 2 possui uma rota para Internet e outra para sub-rede com endereços IP

públicos. Dessa forma, o roteador 2 não pode enviar pacotes para sub-rede com endereços

privados.

Observe que esta é a configuração recomendada pela RFC 1918, contudo, o que aconteceria

se uma rota default fosse incluída no roteador 1? Nesse caso, os hosts com IP privados

poderiam enviar pacotes para Internet, mas eles não poderiam receber a resposta. Esse tipo

de configuração não é bem vista, pois hosts com IP privado poderiam fazer ataques do tipo

DOS (Deny Of Service), dificultando a identificação dos hosts atacantes.

Observe também que incluir uma rota para rede privada no roteador 1 não irá fazer

diferença, pois os roteadores da Internet não tem rotas para redes privadas, de forma que os

pacotes de resposta jamais chegariam ao roteador 1.

8

Como vimos, os roteadores da Internet são incapazes de encaminhar pacotes cujo endereços

de destino seja um IP privado. A fim de permitir que hosts com IP privados tenham acesso a

Internet, é necessário utilizar um tradutor de endereços.

Os tradutores podem ser implementados de duas formas: ao nível de rede ou ao nível de

transporte.

Os tradutores ao nível de rede são embutidos nas funções de roteamento do sistema

operacional, sendo mais comumente implementados como módulos de software adicionais

em roteadores. Essa implementação é transparente aos clientes, pois a tradução é feita

diretamente pelo roteador que está no caminho entre o cliente e a Internet. Esse tradutores

são denominados de NAT (Network Address Translation) ou NAPT (Network Address and

Port Translation).

Os tradutores ao nível de transporte são implementados como servidores. Isto é, as

aplicações clientes precisam se conectar diretamente a esses servidores a fim de ter acesso a

Internet. Essa implementação não é transparente para os clientes, pois esses precisam enviar

seus pacotes para um servidor específico, para que este, posteriormente, reenvie o pacote

para Internet. Esse tipo de tradutor é denominado Proxy, havendo duas variantes: Proxy de

Aplicação e Proxy Socks.

Na figura, o roteador 2 está desempenhando a função de tradução de endereços (NAT).

Observe nesse caso, que o roteador possui uma regra indicando que o endereço dos pacotes

enviados pelos clientes deverá ser substituído por um endereço público antes de encaminhá-

los para Internet.

9

O NAT é um mecanismo que permite traduzir endereços privados em endereços públicos

registrados. Seu funcionamento foi originalmente definido pela RFC 1631. As funções de

NAT estão bastante relacionadas as funções de roteamento, e por isso são implementadas

pelas camadas de rede dos sistemas operacionais de roteadores ou mesmo de desktops, como

o Linux ou o Windows. Por estar relacionada ao roteamento, a função de NAT é

normalmente implementada em roteadores ou firewalls. A função de NAT também é bastante

comum em roteadores ADSL e WiFi.

Apesar do termo NAT ser usado universalmente, existe de fato duas variantes de tradução de

endereços: NAT e NAPT.

Como seu próprio nome diz, o NAT (Network Address Translation) converte apenas

endereços IP, e permite efetuar apenas mapeamentos de um-para-um, conforme ilustrado na

figura. Nesse modo de mapeamento, cada endereço IP privado é mapeado em um endereço

IP público distinto. O NAPT (Network Address and Port Translation) utiliza informações

das porta de transporte (TCP ou UDP), o que permite efetuar mapeamentos de um-para-

muitos. Nesse modo de mapeamento, múltiplos endereços privados podem ser mapeados em

um único endereço IP público, pois as informações de porta são utilizadas como extensões

do endereço IP.

O mapeamento feito pelo NAT pode ser também estático ou dinâmico. No mapeamento

estático, as regras de mapeamento são configuradas previamente, de maneira que um dado

endereço IP privado está sempre mapeado em um mesmo IP público (e também a uma

mesma porta, no caso do NAPT). No mapeamento dinâmico, as regras de mapeamento são

configuradas dinamicamente, criando mapeamentos temporários que são automaticamente

desfeitos quando o IP privado deixa de ser utilizado por muito tempo.

10

Em suas implantações mais comuns, como no Linux, o NAT suporta duas funcionalidades:

Source NAT (SNAT) e Destination NAT (DNAT). Essas funcionalidades são definidas da

seguinte forma:

Source NAT: altera o endereço de origem do pacote, e é implementado após a ação de

roteamento (pós-roteamento).

- Masquerading é uma forma especializada de SNAT.

Destination NAT: altera o endereço de destino do pacote, e é implementado antes do

roteamento (pré-roteamento).

- Redirecionamento de Portas, Balanceamento de Carga e Proxies transparentes são

exemplos de DNAT.

O SNAT é a funcionalidade mais comum, uma vez que ela permite que clientes com

endereços IP privados tenham acesso a Internet. Quando um cliente com IP privado envia um

pacote para Internet, o software de roteamento leva em conta apenas o endereço IP de

destino (que é público) para decidir para onde enviar o pacote. Após essa decisão ter sido

tomada, mas antes do pacote ser enviado para interface de saída, o endereço IP de origem do

cliente é substituído pelo endereço IP do roteador (ou dispositivo que implementa o NAT).

O DNAT é usado em situações mais especiais, quando é necessário, por exemplo, criar um

servidor com endereço IP privado. Nesse caso, é necessário redirecionar pacotes enviados

para o roteador para um computador interno da rede, para que este possa receber conexões

oriundas da Internet. Como nesse caso o computador com IP privado é o destinatário do

pacote, a função de DNAT precisa ser feita antes do roteamento.

11

O NAT efetua apenas mapeamentos de endereços IP, não utilizando informações de porta. Esse método não é muito utilizado para permitir o acesso de clientes com IP privado a Internet, pois ele realiza apenas mapeamentos de um-para-um (isto é, o número de endereços públicos necessários é igual ao número de clientes simultâneos acessando a Internet). O NAT pode ser utilizado em situações residenciais (para mapear, por exemplo, o endereço público do roteador ADSL ao endereço de um único computador). Ele também é usado para permitir que duas redes com endereços IP superpostos se comuniquem sem haver conflito. Imagine, por exemplo, que duas sub-redes, A e B, utilizam o prefixo privado 192.168.0.0/24. O administrador de rede pode utilizar o NAT em um roteador entre as redes A e B para traduzir os endereços dos pacotes enviados pela rede A para outro prefixo (digamos 192.168.1.0/24), a fim de permitir que as duas redes se comuniquem. Além da troca dos IPs, o checksum do cabeçalho IP é recalculado, uma vez que um dos endereços IP do pacote originalmente enviado para o roteador NAT será alterado. Essa operação pode diminuir (muito pouco) a velocidade do roteador.

No NAT dinâmico, pode-se utilizar um “range” de endereços IP públicos em uma quantidade menor que a quantidade de clientes com IP privado. Nesse caso, as entradas da tabela de mapeamento tem um tempo de vida pré-determinado. Se uma dada entrada ficar sem ser utilizada por um dado tempo, ela é liberada, e o endereço IP público pode ser usado por outro cliente. Contudo, o número de conexões simultâneas de clientes é igual ao número de endereços IP públicos disponíveis. No Linux, as funcionalidades do NAT são configuradas através do iptables, conforme os exemplos a seguir:

# Altera qualquer endereço de origem para 210.0.0.1

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 210.0.0.1

# Altera o endereço de origem usando IPs do range 210.0.0.1 até 210.0.0.10

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 210.0.0.1 até 210.0.0.10

O Masquerading é uma forma especializada de Source NAT, usado principalmente para endereços atribuídos dinamicamente. Esse comando simplificado efetua o mapeamento ao IP atribuído a interface definida por -o, sem que o endereço seja mencionado explicitamente.

# aplicando a ação de MASQUERADE (-j MASQUERADE).

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

12

13

O NAPT utiliza informações de porta para permitir que um único endereço IP público seja compartilhado por uma grande quantidade computadores com IP privados. Nesse mecanismo, cada cliente é associado a uma porta de origem TCP ou UDP única.

A figura ilustra esse conceito. Imagine que o cliente 192.168.0.2 envia um pacote para Internet utilizando a porta de origem 1024. Quando esse pacote chega ao roteador, o NAPT verifica se já existe um mapeamento ativo para esse cliente. Se não existir, ele cria um mapeamento associando o IP e Porta do origem do cliente ao seu próprio IP público e uma outra porta de origem. A porta de origem escolhida para mapeamento pelo roteador dependerá das portas já utilizadas.

Em geral, o algoritmo de mapeamento tentará manter a porta utilizada pelo cliente inalterada, substituindo-a apenas caso haja um outro mapeamento ativo usando a mesma porta. No caso do cliente 192.168.0.2, a porta 1024 poderá ser mantida. Observe que cada conexão feita pelo cliente gera um mapeamento distinto. Por exemplo, se o cliente 192.168.0.2 enviar um pacote por uma outra porta de origem (1026), um novo mapeamento será criado.

Quando o cliente 192.168.0.3 envia um pacote, usando a porta 1024, o roteador NAT efetua uma substituição para a porta 1025, já que a porta 1024 já está sendo usada. Similarmente, quando o cliente 192.168.0.4 envia um pacote usando a porta de origem 1025, o mapeamento é feito para porta 1027. O objetivo do NAPT é que cada mapeamento seja feito para uma porta distinta.

Usando essa estratégia é possível gerar até 65535 mapeamentos simultâneos para um único endereço IP (se bem que é recomendável não usar as portas reservadas abaixo de 1024 para esse mapeamentos). Na prática, devido ao consumo de memória e processamento causado pelo NAPT, esse número raramente pode ser alcançado em roteadores convencionais. No Linux, o mapeamento por NAPT é configurado através do IP tables, conforme o exemplo a seguir.

# Altera o endereço de origem para 210.0.0.1, usando as portas 1024-65535

iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to 1024-65535

14

15

A funcionalidade DNAT (destination NAT) permite redirecionar pacotes recebidos pelo roteador para

servidores específicos. Ele é utilizado para permitir que hosts com endereços privados recebam conexões de

clientes da Internet. Essa funcionalidade também é conhecida como redirecionamento.

Essa funcionalidade pode ser implementada tanto para o NAT quanto para o NAPT. A figura ilustra esse

conceito para o caso mais genérico do DNAPT. Observe, nesse caso, que clientes externos devem endereçar os

servidores internos utilizando o IP do roteador NAT. De fato, o nome de domínio dos servidores deve ser

registrado usando o endereço público do roteador. Nesse caso, o mapeamento é feito de forma estática. O

administrador de rede configura previamente o mapeamento, redirecionando pacotes enviados para portas

específicas do roteador para outros endereços privados com ou sem tradução de porta. Por exemplo, pacotes

recebidos pelo roteador na porta 80 ou 25, são redirecionados para o servidor 192.168.0.2 nas mesmas portas.

Pacotes recebidos na porta 8080 do roteador, são redirecionados para porta 80 do servidor 192.168.0.3. E assim

por diante.

No linux, o DNAT é configurado utilizando-se o iptables. Os comandos a seguir fornecem alguns exemplos de

configuração.

# Redireciona pacotes recebidos na porta 8080 para o IP 192.168.0.3 e porta 80.

iptables -t nat -A PREROUTING -p tcp --dport 8080 -i eth0 -j DNAT --to 192.168.0.2:80

O redirect é um tipo especial de DNAT. Essa ação especial implica em alterar o endereço de destino para o

próprio endereço da interface que recebeu o pacote. Ele é util quando o proxy está sendo executado na mesma

máquina em que o roteador.

# Envia pacotes web (port-80) para a porta do squid (proxy transparente)

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128

O DNAT pode ser usando também para prover balanceamento de carga entre múltiplos servidores, efetuado

mapeamentos distintos para cada conexão recebida. Esse conceito é ilustrado pelo comando a seguir:

# Altera os endereços de destino para 192.168.0.2 até 192.168.0.5, através de um processo de balanceamento de

carga.

iptables -t nat -A PREROUTING -i eth0 -j DNAT --to 192.168.0.2-192.168.0.5

16

17

De modo geral, o NAT não funcionará em situações onde o IP apareça em um campo do protocolo de

aplicação. Esse é tipicamente o caso de protocolos de aplicação que utilizam o conceito de call-back.

Por exemplo, um servidor FTP utiliza geralmente duas portas de operação: 21 para controle da

conexão e 20 para transferência de dados. O cliente sempre inicia sua conexão na porta 21 do servidor

FTP. A conexão para transferência de dados, contudo, pode ser feita de duas formas: PORT (Ativo) e

PASV (Passivo).

No modo PORT (Ativo), o cliente efetua uma conexão na porta 21 do servidor FTP, utilizando uma

porta de cliente aleatória N (>1023) e abre uma porta para receber conexões de dados na porta N+1. O

cliente informa ao servidor que deverá receber uma conexão de dados na porta N+1 através do

comando PORT inserido no campo de payload do pacote IP. Nesse caso, o servidor FTP deverá

efetuar uma conexão na porta N+1 do cliente utilizando sua porta 20. Esse processo, traz inúmeros

problemas quando feito através do NAT.

Primeiro, não existe mapeamento para o cliente através da porta N+1, apenas para porta N. Segundo,

quando o NAT efetua a tradução do endereço IP de origem do cliente pelo seu próprio IP, ele não

traduz as informações contidas no payload do pacote IP. Dessa forma, o servidor FTP tenta efetuar a

conexão no endereço IP privado do cliente, e não no endereço público, causando falha de conexão.

Esse modo de operação causa problemas se o cliente estiver atrás de um SNAT.

No modo PASV (Passivo) a porta 20 não é utilizada. Nesse caso, o cliente envia um comando PASV

indicado que deseja efetuar a conexão de dados com os servidor FTP ao invés de recebê-la. Nesse

caso, o servidor abre uma porta aleatória para receber a conexão de dados, e informa essa porta para o

cliente através da conexão de comando. O cliente então efetua a conexão. Esse modo de operação irá

apresentar problemas ser o servidor FTP estiver atrás de um DNAT.

18

Os proxies permitem que computadores com endereços IP privados tenham acesso a Internet,

de forma semelhante aos NAPTs. Contudo, um proxy opera de forma não-transparente para

os clientes, uma vez que ele que quebra o modelo cliente-servidor. Esse conceito é ilustrado

pela figura.

Observe que apesar de efetuar uma tradução de endereços, um NAT não gera uma nova

conexão TCP entre o cliente e o servidor. De fato, apenas uma conexão é gerada, pois a ação

do NAT é transparente tanto para o cliente quanto para o servidor. O NAT não é endereçado

explicitamente pelo cliente, mas indiretamente, pois ele aparece como um roteador no

caminho entre o cliente e a Internet.

O proxy, por outro lado, aparece para o cliente como um servidor. Isto significa que o cliente

precisa estabelecer uma conexão com o proxy, para que este atue como um “procurador” em

nome do cliente perante os servidores na Internet. Como duas conexões de transporte são

estabelecidas (uma do cliente até o proxy e outra do proxy até o servidor), dizemos que o

proxy “quebra” o modelo cliente servidor. Isso tem várias conseqüências, entre elas

desempenho. A função proxy consome muito mais recursos para operar do que o NAT, uma

vez que é necessário arcar com os custos das inúmeras conexões estabelecidas pelos clientes

com o proxy e do proxy com os servidores de destino.

Existem basicamente 2 tipos de proxy: os de aplicação e os SOCKS. Apesar de

semelhantes, esses tipos de proxy possuem diferenças importantes. Como veremos, o

primeiro tipo precisa “conhecer” as aplicações usadas pelos clientes a fim de operar, pois

utiliza informações dos protocolos da camada de aplicação. Já o SOCKs atua apenas no nível

de transporte, e pode suportar virtualmente qualquer tipo de aplicação, de forma semelhante

ao NAT.

19

A figura ilustra o funcionamento de um proxy. No exemplo da figura, o cliente deseja

estabelecer uma conexão com o servidor HTTP espec.ppgia.pucpr.br (IP 60.1.2.3) na porta

80. Para utilizar um proxy, a aplicação cliente precisa abrir uma conexão TCP na porta de

serviço do proxy (no exemplo, 3128). Para encaminhar os pacotes do cliente, o servidor

proxy estabelece uma outra conexão TCP com o servidor de destino, utilizado uma porta

dinâmica (> 1023, no exemplo 1025), como se ele próprio fosse o cliente.

Conforme ilustrado pela figura, os pacotes são enviados para o endereço IP do proxy e para a

porta de serviço do proxy, e não para servidor HTTP destinatário. Os pacotes recebidos do

cliente são reenviados, utilizando o endereço IP público do proxy e a porta aleatória

escolhida para a conexão com o servidor de destino.

Observando a figura, uma questão importante deve ser respondida. Como o proxy determina

o endereço do destinatário? A resposta depende do tipo de proxy. No caso do proxy de

aplicação, o endereço e a porta do destinatário são descobertos analisando as informações

contidas no cabeçalho HTTP. Isso significa que é o próprio servidor proxy quem consulta o

servidor DNS, a fim de traduzir o nome do servidor HTTP de destino em um endereço IP.

Nesse modo de operação, o proxy precisa ser capaz de interpretar o protocolo de aplicação

para operar.

No caso do proxy SOCKS, como veremos mais adiante, informações adicionais são

incluídas pelo cliente, de forma a facilitar a localização do servidor de destino. Analisando

essas informações adicionais, o proxy não precisa interpretar o protocolo de aplicação.

20

O proxy de aplicação extrai as informações do servidor de destino analisando o protocolo de

aplicação. Infelizmente, cada protocolo de aplicação formata seu cabeçalho de maneira

diferente. O protocolo HTTP, por exemplo, identifica o servidor de destino através de um

campo do tipo string, denominado “Host”. Já o protocolo SMPT utiliza a mensagem “RCPT

TO”, e assim por diante.

Um proxy de aplicação é capaz de operar apenas com um conjunto limitado de protocolos

que ele conhece. Os mais comuns são “HTTP”, “FTP”, “SSL” e, por razões históricas,

“Gopher”. Dessa forma, numa rede conectada através de Proxy, os serviços disponibilizados

pelos usuários são limitados aos serviços que o Proxy é capaz de compreender. Muitos

aplicativos utilizam túneis HTTP a fim de superar essa limitação. Túneis HTTP nada mais

são do que um artifício de encapsular outros protocolos de aplicação em mensagens HTTP.

Outra limitação desse tipo de proxy, é que o software do cliente precisa estar preparado a fim

de poder utilizar o proxy. O código para conectar ao proxy de aplicação está embutido nos

navegadores Web, software de atualização de anti-virus, e aplicativos P2P, por exemplo.

Além dos aplicativos precisarem estar preparados, é necessário configurar cada um dos

aplicativos individualmente, informando para cada um deles o endereço do proxy e sua porta

correspondente. Essa tarefa pode, contudo, ser simplificada utilizando-se scripts de

configuração abaixo, como o exemplo abaixo:

function FindProxyForURL(url,host) {

if(isInNet(host, "127.0.0.0", "255.0.0.0") ||

isInNet(host, "192.168.0.0", "255.255.0.0") ||

url.substring(0, 4) == "ftp:") { return "DIRECT"; }

else{ return "PROXY 200.192.112.146:3128"; }

}

21

O mapeamento de conexões efetuadas pelo proxy é bastante semelhante ao NAPT. Para cada

conexão de cliente recebida, o proxy abre uma nova conexão com o servidor de destino

utilizando uma porta ainda não utilizada. Dessa foram, um proxy pode, teoricamente, atender

a aproximadamente 63K clientes (se descontarmos a faixa de portas abaixo de 1024) com um

único endereço IP.

A conexões criadas pelo proxy são dinâmicas. Geralmente, os proxies de aplicação oferecem

serviços apenas para aplicações implementadas sobre o protocolo de transporte TCP. Nesse

caso, o servidor proxy encerra a conexão com o servidor no momento que o cliente encerrar

a conexão correspondente com o proxy. Caso o cliente não encerre a conexão explicitamente,

e fique sem utilizar o mapeamento por um tempo excessivo (por exemplo, superior a 5

minutos), a conexão pode ser encerrada de por iniciativa do proxy para poupar recursos do

servidor.

O protocolo de aplicação HTTP é de longe o mais utilizado com os proxies de aplicação. No

caso mais genérico, esse protocolo não mantém conexões ativas. O protocolo HTTP encerra

a conexão com o servidor assim que as informações de uma página Web são recebidas por

completo. Dessa forma, a quantidade de recursos consumidos do proxy é reduzida.

22

Apesar das limitações impostas pelos proxies de aplicação ao usuários, seu uso é muito

difundido em ambientes corporativos. A razão para isso, é que esses proxies oferecem um

grande controle para os administradores de rede sobre os acessos dos usuários a Internet.

Por serem servidores capazes de interpretar o protocolo de aplicação, esse tipo de proxy pode

prestar inúmeros serviços tais como:

1. Cache de objetos HTTP: Os objetos coletados de servidores externos são armazenados

em cache pelo proxy. Caso um cliente solicite um objeto que esteja armazenado na cache, o

servidor consulta o servidor de destino para ver se seu objeto está atualizado. Se estiver, ele

responde ao cliente com o objeto da sua cache. Esse mecanismo é vantajoso para empresa,

pois permite reduzir a banda utilizada do link com a Internet.

2. Autenticação: o proxy permite controlar o acesso a Internet através de um pedido de

autenticação para usuário.

3. Filtragem de endereços URL: como o proxy consegue interpretar o cabeçalho HTTP, ele

pode proibir o acesso a certos endereços na Internet.

4. Filtragem de conteúdo: o proxy pode detectar a presença de certas palavras em páginas

HTML ou de objetos com certos tipos MIME (video, audio, executáveis, etc.) e proibir sua

transferência.

5. Bloqueio e remoção de virus e malware: antes de entregar o objeto solicitado para o

usuário, o servidor proxy pode executar aplicativos para verificação de potenciais riscos no

objeto, proibindo sua entrega caso encontre virus ou algum tipo de malware.

23

O protocolo SOCKS foi originalmente desenvolvido por David Koblas, e subsequentemente

modificado e entendido pelo IETF. Atualmente, existem duas versões do protocolo SOCKS:

versão 4 (v4) e versão 5 (v5). A versão 4 suporta apenas o transporte de protocolos baseados

em TCP. A versão 5 suporta ambos os protocolos de transporte: TCP e UDP.

O proxy SOCKS v4 funciona como um redirecionador de conexões TCP, permitindo que

usuários identificados tenham acesso a qualquer serviço implementado sobre TCP através de

firewalls. Quando o cliente cria uma conexão TCP com o proxy, o protocolo SOCKS permite

que o cliente se identifique e que informe os dados do servidor que deseja acessar. Dessa

forma, o proxy não precisa procurar o endereço do servidor de destino no protocolo de

aplicação. Como o proxy SOCKS é independente do protocolo de aplicação, ele funciona

para qualquer tipo de serviço: http, ftp, ssh, etc.

O SOCKv4 oferece dois serviços para os clientes: connect e bind.

O serviço connect é usado quando o cliente deseja fazer uma conexão com um servidor

externo. Nesse caso, o cliente fornece seu login, o IP e a porta do servidor que deseja acessar.

Se o login for aceito, e uma conexão TCP puder ser estabelecida com o servidor de destino,

o servidor proxy irá redirecionar todos os pacotes enviados pelo cliente para o servidor e do

servidor para o cliente, enquanto durar a conexão TCP.

O serviço bind é usado para que o cliente possa receber uma conexão de um host externo.

Através do comando bind, o cliente solicita ao Proxy que ele crie uma porta para receber

conexões de um determinado host externo. O proxy SOCKS cria a porta, e responde para o

cliente informando em qual porta e endereço IP (caso ele tenha múltiplas interfaces de rede)

o host externo poderá fazer a conexão.

24

A versão corrente do protocolo SOCKs é 5.0 definido nas RFCs 1928 e 1929. A versão 5.0

inclui duas importantes melhorias: o suporte a aplicações UDP e o suporte a vários métodos

de autenticação.

A fim de suportar o UDP, além do connect e bind, foi incluido o serviço UDP Associate.

Esse serviço funciona de forma semelhante ao connect. O cliente solicita ao servidor proxy

que seja criada uma associação UDP com um certo servidor de destino em um dada porta,

através de uma conexão TCP, usada também para autenticar o cliente. O transporte dos

pacotes UDP, contudo, não é feito via a conexão TCP. Ao invés disso, o cliente precisa enviar

datagramas UDP modificados, incluindo em cada datagrama, um pequeno cabeçalho que

contém o endereço IP e porta do servidor com quem deseja se conectar. O proxy SOCKs só

aceita encaminhar esses datagramas, caso uma conexão TCP com o UDP Associate para esse

destino tenha sido previamente criada.

Um cliente pode ser configurado para utilizar o proxy SOCKS de duas maneiras. A primeira

é similar ao proxy de Aplicação. Cada aplicativo deve trazer o código necessário para gerar

as mensagens SOCKS, e gerar as mensagens connect, bind e UDP Associate necessárias. De

fato, é possível encontrar a opção para utilizar o proxy SOCKS em muitos aplicativos, como

navegadores Web.

A segunda maneira consiste em instalar um cliente proxy SOCKS. Esse cliente modifica a

biblioteca de sockets do sistema operacional. Como todas as chamadas TCP e UDP passam

por essa biblioteca, é possível gerar as mensagens do protocolo SOCKS de maneira

transparente para as aplicações. A vantagem desse método é que ele permite que aplicativos

legados (sem suporte a SOCKS) possam usar o proxy. Outra vantagem, é que a configuração

para uso do proxy pode ser feita uma única vez, globalmente para todos os aplicativos do

cliente.

25

Neste módulo vimos o conceito de endereçamento privado. Essa forma de endereçamento foi

criada a fim de contornar os problemas de exaustão do espaço de endereçamento IPv4,

devido a rápida expansão da Internet, que começou no início dos anos 90.

Originalmente considerado uma solução paliativa e temporária (até que a versão IPv6 fosse

implantada), o endereçamento privado tornou-se um grande sucesso, sendo amplamente

utilizado atualmente. Muito desse sucesso se deve ao fato que essa forma de endereçamento

traz poucas limitações para computadores que atuam apenas como clientes. Apenas

aplicativos servidores (que necessitam receber conexões externas) sofrem limitações com

essa abordagem.

Um efeito secundário do uso do endereçamento privado é a segurança. Computadores com

endereços privados são anônimos do ponto de vista da Internet, isto é, eles não podem ser

endereçados. Isso faz com que o endereçamento privado seja uma opção importante para

obter-se uma conectividade seletiva com a Internet.

A criação de métodos eficientes de mapeamento de endereços públicos e privados, os Proxies

e os NAPTs, também contribui bastante para que essa abordagem pudesse ser amplamente

adotada em prática.