Endereçamento Privado Proxy e NAT

Apresentação em tema: "Endereçamento Privado Proxy e NAT"— Transcrição da apresentação:

1 Endereçamento Privado Proxy e NAT
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 Motivação para o Endereçamento IP Privado
Crescimento do IPv4 07/ milhões de hosts 01/ milhões de hosts IPv4 permite endereçar 4 bilhões de hosts. PREVISÃO INICIAL = 1994 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 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 Autoridades de Registro de Endereço
IANA ARIN RIPE NCC AfriNIC LACNIC APNIC 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. América do Norte Europa, Oriente e Asia Central Africa América Latina e Caribe Ásia e Pacífico

4 Endereços Privados: RFC 1918
Prefixo Faixa de Endereços Descrição /8 a Uma rede de endereços classe A. /12 a 16 redes contíguas de endereços classe B. /16 a 256 redes contíguas de endereços classe C. 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 Tipos de Hosts (RFC 1918) categoria III categoria I categoria II
IPv4 categoria II 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". tradutor de IP IPv4 NAT

6 Roteador Interno e Gateway Default
(não roteia IP privado) ip publico ip publico ip publico IPv4 2 ip publico ip privado ip privado 1 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, , 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. ip privado (roteador interno) roteia IP privado

7 Endereços e Roteamento
IPv4 2 1 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 /24 e a sub-rede privada recebeu o prefixo /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. /24 via direta /24 via direta /0 via provedor /24 via direta

8 se ip_origem = 192.168.0.0/24 traduzir para 200.1.0.1
Hosts Categoria 2 roteador com NAT se ip_origem = /24 traduzir para IPv4 2 1 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. /24 via direta /24 via direta /0 via provedor /24 via direta

9 NAT e NAPT NAT IPprivado1 IPpúblico1 IPprivado2 IPpúblico2 IPprivado3
O NAT é um mecanismo que permite traduzir endereços privados em endereços públicos registrados. Seu funcionamento foi originalmente definido pela RFC 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. IPprivado1 NAPT IPpúblico1:Porta1 IPprivado2 IPpúblico1:Porta2 IPprivado3 IPpúblico1:Porta3

10 decisão sobre o encaminhamento do pacote
SNAT e DNAT Interface de Entrada Interface de Saída Pré-Roteamento [DNAT] Pós-Roteamento [SNAT] roteamento 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.             decisão sobre o encaminhamento do pacote

11 SNAT: Network Address Translation
1 checksum1 2 checksum2 4 checksum4 3 checksum3 tabela de mapeamento = = 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 /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 /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 iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to # Altera o endereço de origem usando IPs do range até iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to até 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 IPv4 Privado IPv4 Network to

12 SNAT no Linux Altera qualquer endereço de origem para 210.0.0.1
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to Altera o endereço de origem usando IPs do range até iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to até Aplica a ação de MASQUERADE iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

13 SNAPT (Network Address and Port Translation)
IP Privado:Porta Origem :1024 :1026 :1024 :1025 IP Público:Porta Origem :1024 :1026 :1025 :1027 request reply clientes 1024 1026 1024 1025 IPv4 1024 1026 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 envia um pacote para Internet utilizando a porta de origem 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 , a porta 1024 poderá ser mantida. Observe que cada conexão feita pelo cliente gera um mapeamento distinto. Por exemplo, se o cliente enviar um pacote por uma outra porta de origem (1026), um novo mapeamento será criado. Quando o cliente 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 envia um pacote usando a porta de origem 1025, o mapeamento é feito para porta O objetivo do NAPT é que cada mapeamento seja feito para uma porta distinta. Usando essa estratégia é possível gerar até 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 , usando as portas iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to            1027 Endereço IP Público servidor 1025

14 SNAPT no Linux O Linux implementa SNAPT sempre que necessário de forma automática, mas mantém a troca das portas no interior de classes: Portas abaixo de 512 Portas entre 512 and 1023 Portas acima de 1024 Altera o endereço de origem para , usando as portas iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to

15 Mapeamentos Reversos: DNAT
servidores IP Privado:Porta Destino :80 :25 :80 :22 IP Público:Porta Destino :80 :25 :8080 :8081 reply request 80 25 80 25 IPv4 80 8080 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 nas mesmas portas. Pacotes recebidos na porta 8080 do roteador, são redirecionados para porta 80 do servidor 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 e porta 80. iptables -t nat -A PREROUTING -p tcp --dport i eth0 -j DNAT --to :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 até , através de um processo de balanceamento de carga. iptables -t nat -A PREROUTING -i eth0 -j DNAT --to 8081 Endereço IP Público espec.ppgia.pucpr.br cliente 22

16 DNAT no Linux Redireciona pacotes recebidos na porta 8080 para o IP e porta 80. iptables -t nat -A PREROUTING -p tcp --dport i eth0 -j DNAT --to :80  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 Altera os endereços de destino para até , através de um processo de balanceamento de carga. iptables -t nat -A PREROUTING -i eth0 -j DNAT --to

17 Problemas com o NAT PORT 192.168.0.2: 1025 PORT 192.168.0.2: 1025 1
2 3 payload tabela de mapeamento = 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. IPv4 Privado IPv4 Network

18 Servidor Proxy 1024 80 NAT 1024 3128 1025 80 Proxy 192.168.0.2
1024 80 IPv4 Privado IPv4 Network NAT 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. 1024 3128 1025 80 IPv4 Privado IPv4 Network Proxy

19 Funcionamento do Proxy
1024 3128 GET /~jamhour/natproxy.tar.gz HTTP/1.1\r\n Host: espec.ppgia.pucpr.br\r\n 1024 3128 1025 80 IPv4 Privado IPv4 Network Proxy 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 ) 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. 1025 80 GET /~jamhour/natproxy.tar.gz HTTP/1.1\r\n Host: espec.ppgia.pucpr.br\r\n

20 Proxy depende da Aplicação
Seqüência de empacotamento aplicação Protocolo de Aplicação HTTP, FTP, SMTP, etc segmento TCP datagrama UDP TCP, UDP IP pacote Ethernet quadro http 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, " ", " ") || isInNet(host, " ", " ") || url.substring(0, 4) == "ftp:") { return "DIRECT"; } else{ return "PROXY :3128"; } } O proxy de aplicação precisa interpretar as informações do protocolo de aplicação (dispositivo de camada 7) ftp ssl

21 Mapeamento de Conexões pelo Proxy
IP Privado:Porta Origem :1024 :1026 :1024 :1025 IP Público:Porta Origem :1024 :1026 :1025 :1027 request reply clientes 1024 1026 1024 1026 3128 IPv4 1024 1025 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. 1027 servidor 1025

22 Outras Funções do Proxy de Aplicação
Controle de acesso por login Filtragem de endereços e conteúdo. Cache de objetos Web Filtragem de Virus e Malware Proxy de Aplicação GET Cache HTTP/ OK\r\n 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: 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. Autenticação: o proxy permite controlar o acesso a Internet através de um pedido de autenticação para usuário. 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. 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. 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. GET GET HTTP/ Not Modified\r\n HTTP/ OK\r\n

23 Proxy Socks user jamhour want connect to 60.1.2.3:80 request granted
user jamhour want bind to :80 bind on :4000 Proxy Socks IPv4 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. 1024 4000 1080 cliente servidor

24 TCP ou UDP não modificado
Proxy Socks aplicação configuração global para todos os aplicativos biblioteca sockets modificada S.O. proxy SOCKS TCP UDP IP servidor A versão corrente do protocolo SOCKs é 5.0 definido nas RFCs 1928 e 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. IPv4 cliente protocolo SOCKS TCP ou UDP não modificado

25 Conclusão 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.