Fernando Lozano

No primeiro tutorial sobre TCP/IP tivemos uma introdução à toda a teoria que governa a arquitetura de uma rede TCP/IP. Como vocês puderam ver, não é pouca teoria. Na verdade as provas sobre TCP/IP são consideradas as mais difícies das certificações CNE da Novell ou MCSE da Microsoft. Mas para montar uma rede local utilizando o TCP/IP, seja para simples compartilhamento de arquivos e impressoras entre estações Windows 95, ou para a construção de uma intranet completa, você não precisa ser um Ph.D. em teoria da ciência da computação. Juntando os conhecimentos teóricos do primeiro tutorial sobre TCP/IP com os as dicas de projeto que forneceremos agora, você poderá criar redes TCP/IP de tamanho pequeno a médio sem problemas. O projeto de uma rede TCP/IP está intimamente relacionado com a sua topologia lógica. Muitas vezes nao é fácil entender a topologia lógica de uma rede, devido em parte à confusão criada pelos fornecedores de produtos (software ou hardware) para redes na divulgação dos seus produtos. Por isso vamos apresentar alguns tipos de topologias físicas mais comuns para redes locais e as topologias lógicas correspondentes, para depois apresentar uma "receita de bolo" para orientar o projeto da rede TCP/IP para essas topologias. Ethernet em cabo coaxial Dispositivos conectados em um mesmo cabo Ethernet possuem conectividade no nível de Enlace (vide o primeiro tutorial sobre TCP/IP). Fisicamente e logicamente eles estão em uma topologia de barramento, o que no TCP/IP corresponde a uma única rede local. Mesmo que adicionemos repetidores ou pontes (bridges) interligando diversos cabos Ethernet. Logicamente continuamos com um único barramento, o que corresponde a uma subnet do TCP/IP. Ethernet em par-trançado Quando utilizamos par-trançado para conectar dispositivos em uma rede ethernet estamos utilizando uma topologia física de estrela. Entretanto, a topologia lógica continua sendo de barramento, pois o hub nada faz além de ecoar o sinal recebido em uma porta para todas as outroas. Assim sendo, o funcionamento lógico do hub é igual ao do cabo coaxial. Se ligarmos vários bubs em cascata, criando uma topologia física de "árvore", continuamos com uma topologia lógica de barramento, equivalente à vários cabos coaxiais interligados por repetidores. Ethernet com switch Um switch Ethernet padrão é uma bridge multiporta. Embora fisicamente ele seja capaz de aumentar bastante o desempenho da rede, por permitir que diversos pares dispositivos se comuniquem simultaneamente, logicamente ele opera somente no nível dois do modelo OSI, que corresponde ao nível de Enlace apresentado no primeiro tutorial sobre TCP/IP. A topologia lógica gerada por um switch ainda é um simples barramento Ethernet, mesmo que tenhamos switches em cascata com outros swtiches ou hubs. Algums switches do mercado incorporam na mesma caixa um roteador. Os fabricantes chamam este projeto de "swtch de nível 3", em referência ao nível 3 do modelo OSI, que corresponde ao nível de rede apresentado no primeiro tutorial sobre TCP/IP. Neste caso, temos que saber qual a configuração específica do switch para determinar qual a topologia lógica implementada por ele. Em linhas gerais esta topologia será um grupo de barramentos Ethernet interconectados por um roteador, que veremos no próximo item: Roteador dedicado Caso a sua rede possua um roteador dedicado, cada porta do roteador gera uma rede local lógica, ou seja, cada porta do roteador corresponde a uma subnet do TCP/P. Não importa que tipo de conexão seja feita por estas portas; pode ser Ethernet, WAN, X.25, etc. Cada porta corresponderá a uma rede lógica independente das outras, e o roteador será capaz de realizar, no nível de rede (IP), a interligação destas redes locais. Dois roteadores em cascata geram redes lógicas diferentes, ao contrário dos hubs e switches Ethernet, que geram uma mesma rede lógica (barramento). Servidor "multihomed" Um servidor multihomed é um computador que possui várias interfaces de rede. Cada interface de rede gera a sua própria rede local lógica, ou subnet para o TCP/IP. Um roteador dedicado é nada mais do que um servidor multihomed especializado. A maioria dos sistemas operacionais para servidor, e alguns sistemas operacionais de estação (como o Warp 4) são capazes de atuar como roteadores para o TCP/IP. Colocar várias placas de rede em um mesmo servidor é uma forma barata e popular de se expandir a capacidade ou aumentar o desempenho de uma rede local Ethernet. A maiora dos PCs, mesmo 486, é capaz de sustentar sem problemas o tráfego de 4 placas Ethernet de 10Mb/s, a um preço bastante inferior a um switch ou roteador dedicado. Redes locais TCP/IP que estejam conectadas na Internet devem utilizar endereços oficiais, atribuídos pelo InternNIC ou por entidades locais autorizadas por este (como a FAPESP para o Brasil). Entretanto a maioria das empresas não necessita nem deve utilizar endereços oficiais, pois isto deixaria a rede inteira vulnerável aos hackers. A partir do momento em que se coloca um firewall protegendo a rede, somente os servidores que serão visíveis publicamente na Internet necessitam de um endereço oficial. Para as redes internas das empresas, que se conectam à Internet por intermédio de um firewall mas não fornecem serviços visíveis para a Internet pública, o InterNIC reservou algumas faixas de endereço a que chamamos de "redes privativas". São muito raros os caos em que uma empresa não deve utilizar uma dessas faixas para a sua rede local, portanto vamos utilizar como primeira regra de projeto de redes TCP/IP a utilização de uma faixa privativa. A faixa escolhida é 172.16.0.0. Vamos utilizar como network mask (netmask ou subnetmask) o valor 255.255.255.0, pois assim o terceiro octedo do endereço TCP/IP pode ser utilizado para diferenciar diversas redes locais lógicas (barramentos Ethernetnet) que a rede local da empresa utilize. Assim a primeria rede local terá como endereço de rede 172.16.1.0, a segunda 172.16.2.0, e assim em diante. O quarto octeto indica o endereço da estação, servidor ou dispositivo nesta rede. Uma rede pequena terá somente endereços IP fixos, configurados manualmente em cada máquina. Já uma rede maior necessitará de um servidor DHCP para aliviar a sobrecarga administrativa. Entretanto, mesmo em uma rede que utilize DHCP teremos alguns endereços IP fixos, configurados manualmente, porque o DNS não sabe trabalhar em conjunto com DHCP. Isto implica em que os servidores da intranet da empresa necessitam ter um endereço IP fixo, para que eles possam ser identificados via DNS. Então vamos separar os endereços de host em três faixas: uma para os servidores (IP fixo), uma para as estações configuradas via DHCP e outra para as estações e outros dispositivos que necessitem de um endereço IP pré-fixado. Nossas faixas serão: Faixa 1 (servidores): 10..99 Faixa 2 (DHCP): 100..199 Faixa 3 (outros dispositivos com IP fixo): 200..250 Outra convenção útil é colocar o default gateway sempre com endereço de host igual a 1. Não há necessidade de se utilizar os endereços IP sequencialmente. Você pode deixar "buracos" na numeração dos endereços de hosts, o que pode ser conveniente se a sua rede já adotar algum padrão de numeração para os equipamentos. Caso a sua rede não utilize DHCP, você irá configurar as estações manualmente com endereços de host da faixa 3 e deixar a faixa 2 reservada para uma futura expansão da rede que venha a necessitar do DHCP. Vamos iniciar por uma rede simples, que consiste em um único barramento Ethernet. Esta rede contém um único servidor, que desempenha todas as funções de servidor da rede, e 15 estações, que receberão os endereços IP manualmente. Os parâmetros gerais de nossa rede são: Então vamos separar os endereços de host em três faixas: uma para os servidores (IP fixo), uma para as estações configuradas via DHCP e outra para as estações e outros dispositivos que necessitem de um endereço IP pré-fixado. Nossas faixas serão: Endereço de Rede: 172.16.1.0 Network Mask: 255.255.255.0 Default Gateway: vazio (não temos necessidade) Servidor DNS: vazio (não estamos utilizando) Configurar via DHCP: não E os enderços IP dos computadoes, segundo a Figura 1, são: WWW: 172.16.1.10 M01: 172.16.1.201 M02: 172.16.1.202 e assim por diante, até o M15: 172.16.1.215 Como não temos um servidor DNS nesta rede, cada estação deve ter um arquivo de hosts para que o servidor Web possa ser localizado. O nome e diretório do arquivo de hosts varia de plataforma para plataforma, mas o seu conteúdo será: 127.0.0.1 localhost 172.16.1.10 www Observe o nome "localhost", que é padrão para o loopback do TCP/IP (vide primeiro tutorial sobre TCP/IP, tópico "Como Testar uma Rede TCP/IP"). Este exemplo difere do primeiro apenas no tamanho da rede. Agora temos 50 estações e dois servidores, um para arquivos e impressão e outro para a intranet, que abrigará os servidores Web, DNS e DHCP. Os parâmetros gerais para esta rede são: Endereço de Rede: 172.16.1.0 Network Mask: 255.255.255.0 Default Gateway: vazio (não temos necessidade) Servidor DNS: 172.16.1.10 (é o servidor da Intranet) Configurar via DHCP: sim (somente para as estações) E os enderços IP dos computadoes, segundo a Figura 2, são: WWW: 172.16.1.10 SERV1: 172.16.1.20 M01..M50: 172.16.1.100..172.16.1.150 (configurados via DHCP) Notem que, no TCP/IP, podemos ter vários servidores com o mesmo endereço IP, pois cada servidor corresponde a um programa diferente, que utiliza o seu próprio número de porta para receber as coenxões dos clientes. No caso, temos um servidor Web e um servidor DNS no endereço 172.16.1.10. Como desta vez temos um servidor DNS, não precisamos criar um arquivo de hosts em cada estação. OBS 1: Nesta série de aulas, não iremos apresentar como é a configuração dos servidores DNS e DHCP. São topicos mais demorados, que exigiriam aulas específicas. Entretanto, caso a sua rede possua esses servidores ou caso você esteja trabalhando junto com outro profissional que saiba configurar esses servidores, estamos incluindo exemplos para mostrar como seria a configuração das estações com os servidores DNS e DHCP presentes. Note que ambos os servidores podem ser utilizados independentemente um do outro, ou seja, eu posso ter um servidor DHCP nas não ter um servidor DNS, e vice-versa. OBS 2: Também não iremos apresentar as configurações do servidor Web, mas consideramos que existe um presente na intranet. A maioria dos servidores web, quando instalados em uma rede TCP/IP corretamente configurada, não necessita de configurações extras: os seus defaults já fornecem uma intranet perfeitamente funcional, basta verificar no manual do servidor web utilizado em qual diretório devem ser instaladas as páginas HTML. Agora temos dois segmentos (barramentos) Ethernet, cada um com 20 estações, interligados por um servidor multihomed. Este servidor deve estar com o roteamento IP habilitado (IP forwarding = on) para que os dois barramentos possam se comunicar. O servidor web está no primeiro barramento, e não temos servidores DNS ou DHCP presentes. Os parâmetros gerais para esta rede são: Endereço da Rede 1: 172.16.1.0 Endereço da Rede 2: 172.16.2.0 Network Mask: 255.255.255.0 Default Gateway da Rede 1: 172.16.1.1 Default Gateway da Rede 1: 172.16.2.1 Servidor DNS: não temos Configurar via DHCP: não E os endereços IP dos computadoes, segundo a Figura 3, são: WWW: 172.16.1.10 GATEWAY: 172.16.1.1 e 172.16.2.1 M101: 172.16.1.201 M102: 172.16.1.202 e assim por diante, até o M120: 172.16.1.220 M201: 172.16.2.201 M202: 172.16.2.202 e assim por diante, até o M220: 172.16.2.220. Observem que um servidor multihomed possui vários endereços IP, um para cada interface de rede presente. Considerando que o servidor multihomed não roda nenhum serviço para a intranet, ele não precisa ser listado no arquivo de hosts, que teria o seguinte conteúdo: 127.0.0.1 localhost 172.16.1.10 www Você poderia, por economia, colocar todos os serviços de rede em uma única máquina, mas ainda assim ter dois segmentos. Digamos que temos poucas estações, porém muito distantes, por isso fomos obrigados a instalar dois segmentos Ethernet. O único servidor fornecerá serviços de arquivos, web e roteamento para a rede inteira. Não temos servidores DNS ou DHCP presentes. Os parâmetros gerais para esta rede são: Endereço da Rede 1: 172.16.1.0 Endereço da Rede 2: 172.16.2.0 Network Mask: 255.255.255.0 Default Gateway da Rede 1: 172.16.1.1 Default Gateway da Rede 1: 172.16.2.1 Servidor DNS: não temos Configurar via DHCP: não E os enderços IP dos computadoes, segundo a Figura 4, são: WWW: 172.16.1.1 GATEWAY: 172.16.1.1 e 172.16.2.1 M101: 172.16.1.201 M102: 172.16.1.202 e assim por diante, até o M110: 172.16.1.210 M201: 172.16.2.201 M202: 172.16.2.202 e assim por diante, até o M205: 172.16.2.205 Quando eu tenho um servidor multihomed que deve ser listado no arquivo de hosts, podemos usar qualquer um dos endereços, mas somente um deles poderá estar no arquivo de hosts: 127.0.0.1 localhost 172.16.1.1 www Digamos que você queira prever o crescimento futuro da rede e a consequente instalação de uma nova máquina para o servidor web. O arquivo de hosts pode listar vários nomes, ou alias, para um mesmo endereço IP, por exemplo: 127.0.0.1 localhost 172.16.1.1 servidor1, www E quando a nova máquina para o servidor web for instalada, você poderia alterar os arquivos de host (em todas as estações) para: 127.0.0.1 localhost 172.16.1.1 servidor1 172.16.1.10 www É claro, a entrada para o "servidor1" só será necessário caso haja algum outro serviço intranet sendo oferecido pela máquina, por exemplo um servidor FTP. Os nomes de hosts fornecidos pelo DNS ou definidos no arquivo de hosts não tem significado para as redes Microsoft e Novell, pelo menos no que diz respeito ao compartilhamento de arquivos e impressoras. Caso eu decida incluir um servidor DHCP nesta rede, eu tenho duas opções: ou eu instalo o servidor DHCP no servidor multihomed, ou eu instalo dois servidores DHCP, um para cada subnet. Como o DHCP opera na fronteira entre o nível de rede e o nivel de enlace, as estações não podem utilizar o roteador para se conectar ao servidor DHCP. Este tutorial poderia ser extendida indefinidamente, demonstrando diversas possibilidades de topologias de rede, servidores presentes e etc. Entretanto acreditamos que as configurações apresentadas como exemplo serão suficientes para a maioria dos casos. Redes maiores nada mais são do que combinações dos casos simples apresentados acima. Caso a sua rede inclua estações ou servidores rodando Windows (3.x, 95, 98 ou NT) você deve tomar cuidado com alguns detalhes. Primeiro, o nome de domínio do DNS não tem nenhuma relação com o nome de domínio do NT, assim como os nomes de host definidos pelo DNS ou pelo arquivo de hosts não tem relação com os nomes dos computadores para a rede Microsoft. Você pode até configura-los para que sejam iguais, mas deve se lembrar que eles estão relacionados com componentes de software diferentes. Segundo, a correta operação de uma rede Microsoft com TCP/IP em uma rede composta por varias subnets exige que seja instalado e configurado um servidor WINS ou NBNS. Muitas pessoas pensam que o WINS e o DNS são equivalentes, ou que um pode substituir o outro, o que não é verdade. O WINS fornece o endereço IP correspondente a um endereço da rede Microsoft (que é um nome NetBIOS), que é uma única palavra de até 14 letras, enquanto que o DNS fornece o endereço IP correspondente a um endereço da Internet ou da intranet, que é um conjunto de palavras separadas por pontos e de compimento virtualmente ilimitado. O DNS não tem conhecimento dos nomes de "workgroups" da rede Microsoft, e a rede Microsoft não tem conhecimento de que o domínio "microsoft" está dentro do domínio ".com". A apresentação de todos os detalhes para a configuração ótima de uma rede Microsoft com TCP/IP seria assunto para uma série de tutoriais à parte, mas o material fornecido nesta série de tutoriais será suficiente para as situações mais corriqueiras de configuração de uma intranet. * Fernando Lozano é analista de sistemas especialista em redes locais e consultor do Clube do Hardware. Seu site pessoal, com várias informações sobre Linux, pode ser acessado em http://www.lozano.eti.br.

No mundo de hoje, não se pode falar de redes sem falar do TCP/IP. O conjunto de protocolos originalmente desenvolvido pela Universidade da Califórnia em Berkeley, sob contrato para o Departamento de Defesa dos EUA, se tornou o conjunto de protocolos padrão das redes locais e remotas, suplantando conjuntos de protocolos bancados por pesos pesados da indústria, como a IBM (SNA), Microsoft (NetBIOS/NetBEUI) e Novell (IPX/SPX). O grande motivo de todo este sucesso foi justamente o fato do TCP/IP não ter nenhuma grande empresa associada ao seu desenvolvimento. Isto possibilitou a sua implementação e utilização por diversas aplicações em praticamente todos os tipos de hardware e sistemas operacionais existentes. Mesmo antes do boom da Internet o TCP/IP já era o protocolo obrigatório para grandes redes, formadas por produtos de muitos fornecedores diferentes, e havia sido escolhido pela Microsoft como o protocolo preferencial para o Windows NT, devido às limitações técnicas do seu próprio conjunto de protocolos, o NetBEUI. Entretanto, ao contrário dos procolos proprietários para redes locais da Microsoft e da Novell, que foram desenhados para serem praticamente "plug and play", as necessidades que orientaram o desenvolvimento do TCP/IP obrigaram ao estabelecimento de uma série de parametrizações e configurações que devem ser conhecidas pelo profissional envolvido com instalação, administração e suporte de redes. Esta primeira aula tem por objetivo passar os conhecimentos teóricos necessários para tornar os alunos aptos a seguirem as aulas seguintes, que explicarão como implementar redes TCP/IP no Windows 95, Windows NT, Netware e outros sistemas populares no mercado. Ao contrário da maioria dos livros "introdutórios" sobre TCP/IP que vemos nas livrarias e universidades, não vamos nos preocupar com os detalhes sobre formatos de pacotes e algoritmos empregados na implementação do protocolo. Vamos nos preocupar sim com os conhecimentos realmente necessários para se trabalhar corretamente com os vários produtos existentes no mercado. Quem já estudou mais a fundo a documentação de produtos de redes ou participou de cursos mais específicos certamente se deparou com o "Modelo OSI de 7 Camadas". Todos os softwares de redes são baseados em alguma arquitetura de camadas, e normalmente nos referimos a um grupo de protocolos criado para funcionar em conjunto como uma pilha de protocolos (em inglês, protocol stack, por exemplo the TCP/IP stack). O termo "pilha" é utilizado porque os protocolos de uma dada camada normalmente interagem somente com os protocolos das camadas imediatamente superior e inferior. O modelo de pilha traz a vantagem de modularizar naturalmente o software de redes, permitindo a sua expansão com novos recursos, novas tecnologias ou aperfeiçoamentos sobre a estrutura existente, de forma gradual. Entretanto, o Modelo OSI é uma modelo conceitual, e não a arquitetura de uma implementação real de protocolos de rede. Mesmo os protocolos definidos como padrão oficial pelo ISO - International Standards Organization - a entidade criadora do modelo OSI, não foram projetados e construídos segundo este modelo. Por isso, vamos utilizar nesta aula uma simplificação do modelo OSI. O importante é entender o conceito de pilhas de protocolos, pelo qual cada camada realiza uma das funções necessárias para a comunicação em rede, tornando possível a comunicação em redes de computadores utilizando várias tecnologias diferentes. O TCP/IP foi desenhado segundo uma arquitetura de pilha, onde diversas camadas de software interagem somente com as camadas acima e abaixo. Há diversas semelhanças com o modelo conceitual OSI da ISO, mas o TCP/IP é anterior à formalização deste modelo e portanto possui algumas diferenças. O nome TCP/IP vem dos nomes dos protocolos mais utilizados desta pilha, o IP (Internet Protocol) e o TCP (Transmission Control Protocol). Mas a pilha TCP/IP possui ainda muitos outros protocolos, dos quais veremos apenas os mais importantes, vários deles necessários para que o TCP e o IP desempenhem corretamente as suas funções. Visto superficialmente, o TCP/IP possui 4 camadas, desde as aplicações de rede até o meio físico que carrega os sinais elétricos até o seu destino: 4. Aplicação (Serviço) FTP, TELNET, LPD, HTTP, SMTP/POP3, NFS, etc. 3. Transporte TCP, UDP 2. Rede IP 1. Enlace Ethernet, PPP, SLIP Além das camadas propriamente ditas, temos uma série de componentes, que realizam a interface entre as camadas: Aplicação / Transporte DNS, Sockets Rede / Enlace ARP, DHCP Vamos apresentar agora uma descrição da função de cada camada do TCP/IP: 1. Os protocolos de enlace tem a função de fazer com que informações sejam transmitidas de um computador para outro em uma mesma mídia de acesso compartilhado (também chamada de rede local) ou em uma ligação ponto-a-ponto (ex: modem). Nada mais do que isso. A preocupação destes protocolos é permitir o uso do meio físico que conecta os computadores na rede e fazer com que os bytes enviados por um computador cheguem a um outro computador diretamente desde que haja uma conexão direta entre eles. 2. Já o protocolo de rede, o Internet Protocol (IP), é responsável por fazer com que as informações enviadas por um computador cheguem a outros computadores mesmo que eles estejam em redes fisicamente distintas, ou seja, não existe conexão direta entre eles. Como o próprio nome (Inter-net) diz, o IP realiza a conexão entre redes. E é ele quem traz a capacidade da rede TCP/IP se "reconfigurar" quando uma parte da rede está fora do ar, procurando um caminho (rota) alternativo para a comunicação. 3. Os protocolos de transporte mudam o objetivo, que era conectar dois equipamentos, para' conectar dois programas. Você pode ter em um mesmo computador vários programas trabalhando com a rede simultaneamente, por exemplo um browser Web e um leitor de e-mail. Da mesma forma, um mesmo computador pode estar rodando ao mesmo tempo um servidor Web e um servidor POP3. Os protocolos de transporte (UDP e TCP) atribuem a cada programa um número de porta, que é anexado a cada pacote de modo que o TCP/IP saiba para qual programa entregar cada mensagem recebida pela rede. 4. Finalmente os protocolos de aplicação são específicos para cada programa que faz uso da rede. Desta forma existe um protocolo para a conversação entre um servidor web e um browser web (HTTP), um protocolo para a conversação entre um cliente Telnet e um servidor (daemon) Telnet, e assim em diante. Cada aplicação de rede tem o seu próprio protocolo de comunicação, que utiliza os protocolos das camadas mais baixas para poder atingir o seu destino. Pela figura acima vemos que existem dois protocolos de transporte no TCP/IP. O primeiro é o UDP, um protocolo que trabalha com datagramas, que são mensagens com um comprimento máximo pré-fixado e cuja entrega não é garantida. Caso a rede esteja congestionada, um datagrama pode ser perdido e o UDP não informa as aplicações desta ocorrência. Outra possibilidade é que o congestionamento em uma rota da rede possa fazer com que os pacotes cheguem ao seu destino em uma ordem diferente daquela em que foram enviados. O UDP é um protocolo que trabalha sem estabelecer conexões entre os softwares que estão se comunicando. Já o TCP é um protocolo orientado a conexão. Ele permite que sejam enviadas mensagens de qualquer tamanho e cuida de quebrar as mensagens em pacotes que possam ser enviados pela rede. Ele também cuida de rearrumar os pacotes no destino e de retransmitir qualquer pacote que seja perdido pela rede, de modo que o destino receba a mensagem original, da maneira como foi enviada. Agora, vamos aos componentes que ficam na interface entre os níveis 3 e 4 e entre os níveis 1 e 2. O Sockets é uma API para a escrita de programas que trocam mensagens utilizando o TCP/IP. Ele fornece funções para testar um endereço de rede, abrir uma conexão TCP, enviar datagramas UDP e esperar por mensagens da rede. O Winsockets, utilizado para aplicações Internet em Windows é nada mais do que uma pequena variação desta API para acomodar limitações do Windows 3.1. No Windows NT e Win95 pode ser usada a API original sem problemas. O Domain Name Service (DNS), que será visto com maiores detalhes mais adiante, fornece os nomes lógicos da Internet como um todo ou de qualquer rede TCP/IP isolada. Temos ainda o ARP realiza o mapeamento entre os endereços TCP/IP e os endereços Ethernet, de modo que os pacotes possam atingir o seu destino em uma rede local (lembrem-se, no final das contas quem entrega o pacote na rede local é o Ethernet, não o TCP ou o IP). Por fim, o DHCP permite a configuração automática de um computador ou outro dispositivo conectado a uma rede TCP/IP, em vez de configurarmos cada computador manualmente. Mas, para entender o porque da necessidade do DHCP, temos que entender um pouco mais do funcionamento e da configuração de uma rede TCP/IP. Em uma rede TCP/IP, cada computador (ou melhor, cada placa de rede, caso o computador possua mais do que uma) possui um endereço numérico formado por 4 octetos (4 bytes), geralmente escritos na forma w.x.y.z. Além deste Endereço IP, cada computador possui uma máscara de rede (network mask ou subnet mask), que é um número do mesmo tipo mas com a restrição de que ele deve começar por uma seqüência contínua de bits em 1, seguida por uma seqüência contínua de bits em zero. Ou seja, a máscara de rede pode ser um número como 11111111.11111111.00000000.00000000 (255.255.0.0), mas nunca um número como 11111111.11111111.00000111.00000000 (255.255.7.0). A máscara de rede serve para quebrar um endereço IP em um endereço de rede e um endereço de host. Todos os computadores em uma mesma rede local (fisicamente falando, por exemplo, um mesmo barramento Ethernet) devem ter o mesmo endereço de rede, e cada um deve ter um endereço de host diferente. Tomando-se o endereço IP como um todo, cada computador em uma rede TCP/IP (inclusive em toda a Internet) possui um endereço IP único e exclusivo. O InterNIC controla todos os endereços IP em uso ou livres na Internet, para evitar duplicações, e reserva certas faixas de endereços chamadas de endereços privativos para serem usados em redes que não irão se conectar diretamente na Internet. Quando o IP recebe um pacote para ser enviado pela rede, ele quebra o endereço destino utilizado a máscara de rede do computador e compara o endereço de rede do destino com o endereço de rede dele mesmo. Se os endereços de rede forem iguais, isto significa que a mensagem será enviada para um outro computador na mesma rede local, então o pacote é repassado para o protocolo de enlace apropriado (em geral o Ethernet). Se os endereços forem diferentes, o IP envia o pacote para o default gateway, que é nada mais do que o equipamento que fornece a conexão da rede local com outras redes. Este equipamento pode ser um roteador dedicado ou pode ser um servidor com múltiplas placas de rede, e se encarrega de encaminhar o pacote para a rede local onde está o endereço IP do destino. É importante que o endereço IP do default gateway esteja na mesma subnet que o a máquina sendo configurada, caso contrário ela não terá como enviar pacotes para o default gateway e assim só poderá se comunicar com outros hosts na mesma subnet. Resumindo um computador qualquer em uma rede TCP/IP deve ser configurado com pelo menos estes três parâmetros: o seu endereço IP exclusivo, a sua máscara de rede (que deve ser a mesma utilizada pelos demais computadores na mesma LAN) e o endereço IP do default gateway. Digamos que o host com o endereço IP é 172.16.1.101 deseje enviar um pacote para o endereço 172.16.2.102. Caso a máscara de rede seja 255.255.0.0, o AND binário do enredeço fonte será 172.16.0.0, e o AND do endereço destino será 172.16.0.0, indicando que ambos possuem o mesmo endereço de rede e portanto estão diretamente conectados no nível de enlace. Neste caso, o nível IP envia um pacote ARP pela rede Ethernet para identificar qual o endereço Ethernet do host cujo IP é 172.16.2.2. Este pacote é enviado como um broadcast, de modo que todos os hosts conectados no mesmo segmento Ethernet receberão o pacote, e o host configurado para o endereço desejado irá responder ao pacote ARP indicando qual o seu endereço Ethernet. Assim o IP pode montar o pacote Ethernet corretamente endereçado e enviar o pacote para o seu destino. Agora digamos que a máscara de rede não fosse 255.255.0.0, mas sim 255.255.255.0. Neste caso, os endereços de rede da origem e destino seriam respectivamente 172.16.1.0 e 172.16.2.0. Como os endereços de rede são diferentes, isto significa que não temos conectividade direta (no nível de enlace) entre os dois hosts, portanto o pacote deverá ser entregue por intermédio de um roteador, que é o default gateway. Digamos que o default gateway seja 172.16.1.1 (observe que o endereço de rede do default gateway é 172.16.1.0, o mesmo do nosso host de origem). Então o host irá enviar um pacote ARP pela rede para descobrir o endereço Ethernet do default gateway, e enviará o pacote para este. Ao receber o pacote, o default gateway irá verificar que o endereço IP de destino é o IP de outro host que não ele, e irá verificar qual o endereço de rede do destino. Pode ser que o pacote esteja endereçado para uma rede local na qual o default gateway tenha uma conexão direta, ou pode ser que o default gateway tenha que direcionar o pacote para um outro roteador mais próximo do destino final. De qualquer forma, o default gateway segue o mesmo processo de gerar o endereço de rede utilizando a netmask, e em seguida enviar um pacote ARP pedindo o endereço Ethernet do próximo host a receber o pacote. A diferença é que um roteador não tem um default gateway, mas sim uma tabela de roteamento, que diz quais endereços de rede podem ser alcançados por quais roteadores. Notem que este exemplo considerou apenas a comunicação entre dois equipamentos, não entre dois programas. O nosso exemplo ficou apenas no nível de rede da pilha TCP/IP, mas acima dela o processo é simples: o IP verifica que tipo de pacote foi recebido (TCP, UDP ou outro) e repassa o pacote para o protocolo apropriado. O protocolo de transporte irá então verificar o número de porta contido no pacote e qual programa está associado aquela porta. Este programa será notificado da chegada de um pacote, e será responsabilidade dele decodificar e utilizar de alguma forma as informações contidas no pacote. Caso você venha a ter problemas de comunicação, todas as pilhas TCP/IP, independente de qual sistema operacional, trazem o utilitário ping para testar a conectividade entre dois hosts TCP/IP. Siga o seguinte procedimento: 1. ping 127.0.0.1. Este endereço IP é um loopback, ou seja, não vai para a rede, fica no computador que originou a mensagem. Se o ping acusar o recebimento da resposta, significa que a pilha TCP/IP está instalada e ativa no computador onde foi realizado o teste. (Somente a título de curiosidade, você pode usar o loopback do TCP/IP para desenvolver aplicações de rede em uma máquina stand-alone, sem nenhum tipo de conexão de rede disponível.) 2. ping meu_ip. Tendo comprovado que o TCP/IP está ativo na máquina origem, vamos enviar uma mensagem para ela mesmo, para verificar se a placa de rede (ou modem) estão ativos no que diz respeito ao TCP/IP. Aqui você testa apenas o driver da sua placa de rede, não a placa em si nem os cabos da rede. 3. ping ip_na_minha_rede. Agora vamos testar a comunicação dentro da rede local onde o computador de origem está localizado. Garanta que o computador dono do ip_na_minha_rede está com o TCP/IP e a sua placa de rede ativos, segundo os dois testes acima. Se não funcionar, você tem um problema de cabos ou em uma placa de rede, ou simplesmente as suas máscaras de rede e endereços IP estão incorretos. 4. ping ip_do_default_gateway. Se a comunicação dentro da minha rede local está OK, temos que verificar se o default gateway da minha rede está no ar, pois todos os pacotes que saem da minha rede local passam por ele. 5. ping ip_do_outro_lado. Digamos que o meu default gateway esteja diretamente conectado na rede destino. Eu tenho que testar se a interface de rede que liga o default gateway a esta rede está no ar. Então eu dou um ping no endereço IP desta placa. Se o default gateway não estiver diretamente conectado na rede destino, eu repito os passos (4) e (5) para cada equipamento que esteja no caminho entre origem e destino. 6. ping ip_do_destino. Sabendo que a outra rede pode ser alcançada via TCP/IP, resta saber se eu consigo me comunicar com o computador desejado. Até agora nós estamos vendo a comunicação em rede utilizando apenas os endereços IP. Imagine o seu cartão de visitas, indicando a sua home-page como: "164.85.31.230". Imagine-se ainda com uma lista contendo dezenas de números como esse pendurada na parede junto ao seu computador, para quando você precisar se conectar a um dos servidores da sua empresa. No início do desenvolvimento do TCP/IP, cada computador tinha um arquivo de hosts que listava os nomes dos computadores e os endereços IP correspondentes. Na Internet, certamente seria inviável manter estes arquivos, não só pelo tamanho que eles teriam mas também pela dificuldade em se manter milhões de cópias atualizadas. Logo foi desenvolvido o DNS, pelo qual diversos servidores mantém um banco de dados distribuído com este mapeamento de nomes lógicos para endereços IP. O DNS funciona de forma hierárquica. Vejam um endereço Internet típico, como www.petrobras.com.br. Inicialmente, separamos o primeiro nome (até o primeiro ponto), "www", que é o nome de um computador ou host, e o restante do endereço, "petrobras.com.br", que é o nome da organização, ou o nome do domínio. Por favor, não confundam o conceito de domínios em endereços Internet com o conceito de domínios em uma Rede Microsoft. Não existe nenhuma relação entre eles. O domínio petrobras.com.br possui o seu servidor DNS, que contém os nomes dos computadores (e endereços IP correspondentes) sob a sua autoridade. E ele sabe o endereço IP do servidor DNS do domínio que está acima dele, .com.br. Os computadores na Petrobras fazem todas as consultas por endereços IP ao servidor do seu domínio, e ele repassa as consultas a outros servidores DNS quando necessário. Os clientes necessitam saber apenas sobre o servidor do seu domínio, e mais nada. Já o servidor DNS do domínio .com.br sabe os endereços IP de todos os servidores dos domínios a ele subordinados (por exemplo, texaco.com.br, mantel.com.br, etc) e o endereço IP do servidor acima dele (domínio .br, o domínio que engloba todo o Brasil). Por fim, o servidor DNS do domínio br sabe os endereços de todos os servidores dos domínios a ele subordinados (.com.br, .gov.br, etc) e o endereço do servidor DNS do InterNIC, que é o servidor DNS raiz de toda a Internet. Uma consulta de uma aplicação por um endereço IP sobe por toda a hierarquia de servidores DNS, até o domínio comum de nível mais baixo que seja comum a origem e destino, ou até chegar ao servidor do InterNIC, e depois desce na hierarquia até o domínio onde está o computador destino. A resposta volta pelo caminho inverso, porém cada servidor DNS mantém um cache das respostas recebidas, de modo que uma nova requisição pelo mesmo nome não necessitará percorrer novamente todos os servidores DNS. Pode parecer que é realizado um trabalho muito grande somente para obter um endereço IP, mas o processo como um todo é rápido (quem navega na Web sabe bem disso), e ele possibilita que milhares de organizações integrem suas redes a um custo aceitável e com grande autonomia. Quando você acrescenta uma máquina no seu domínio, você não precisa comunicar ao InterNIC e às redes vizinhas, basta registrar o novo computador no seu servidor DNS. O protocolo DHCP Recapitulando, cada estação ou servidor em uma rede TCP/IP típica deverá ser configurada com os seguintes parâmetros: Endereço IP Máscara de Rede Default Gateway Além disso, caso a sua rede utilize um servidor DNS o seu endereço IP também deve ser configurado em cada host. Em uma rede com dezenas ou mesmo centenas de computadores, manter o controle dos endereços IP já utilizados pelas máquinas pode ser um pesadelo. É muito fácil errar o endereço IP de uma máquina, ou errar a máscara de rede ou endereço do default gateway, e geralmente é muito difícil identificar qual a máquina onde existe um erro de configuração do TCP/IP. Para resolver esses problemas você poderá instalar um servidor DHCP na sua rede local (ou melhor, um servidor DHCP para cada subnet, logo veremos porque) e deixar que ele forneça estes parâmetros para as estações da rede. Se você tem uma pilha TCP/IP instalada que suporta o protocolo DHCP, você pode configurar cada estação para usar o DHCP e ignorar todos esses parâmetros. Na inicialização da pilha TCP/IP, a estação irá enviar um pacote de broadcast para a rede (um broadcast é um pacote que é recebido por toda a rede) e o servidor DHCP, ao receber este pacote, enviará os parâmetros de configuração para a estação. Aqui temos comunicação apenas no nível de enlace (pois o TCP/IP ainda não foi completamente inicializado), e portanto não temos a função de roteamento habilitada. Por isso o servidor DHCP deve estar na mesma LAN física onde está a estação que será inicializada. Normalmente os servidores tem sua configuração realizada manualmente, pois o endereço IP deve concordar com o endereço IP cadastrado no servidor DNS. O servidor DHCP é configurado com uma faixa de endereços IP que ele pode fornecer aos clientes. Inicialmente, todos os endereços estão disponíveis. Quando uma estação é inicializada, ela envia o broadcast pedindo pela sua configuração, e o servidor DHCP reserva um endereço para ela (que deixa de estar disponível) e registra o endereço Ethernet para o qual o endereço foi reservado. Então ele envia uma resposta contendo este endereço e os demais parâmetros listados acima. O endereço é apenas "emprestado" pelo servidor DHCP, que registra também o momento do empréstimo e a validade deste empréstimo. No próximo boot, a estação verifica se o empréstimo ainda é válido e se não pede um novo endereço (que pode até ser o mesmo, por coincidência). Se o empréstimo estiver em metade da sua validade, o cliente pede uma renovação do empréstimo, o que aumenta a sua validade. E a cada inicialização, o cliente verifica se o endereço emprestado ainda é dela, pois ela pode ter sido deslocada para uma outra LAN, onde a configuração do TCP/IP é diferente, ou por qualquer motivo o Administrador da Rede pode ter forçado a liberação do endereço que havia sido emprestado. O servidor verifica periodicamente se o empréstimo não expirou, e caso afirmativo coloca o endereço novamente em disponibilidade. Desta forma, a não ser que você tenha um número de estações muito próximo ao número de endereços IP reservados para o servidor DHCP, você pode acrescentar, retirar ou mover estações pela sua rede sem se preocupar em configurar manualmente as pilhas TCP/IP a cada mudança. Geralmente o DHCP é utilizado somente para configurar estações cliente da rede, enquanto que os servidores são configurados manualmente. Isso porque o endereço IP do servidor deve ser conhecido previamente (para configuração do default gateway, para configuração do arquivo de hosts, para configuração de DNS, configuração de firewall, etc). Se fosse utilizado o DHCP, o endereço do servidor poderia ser diferente em cada boot, obrigando a uma série de mudanças de configuração em diversos nós da rede. Você também pode configurar o servidor DHCP para entregar aos clientes outras informações de configuração, como o endereço do servidor DNS da rede. O Linux pode operar tanto como cliente quanto como servidor DHCP, entretanto não veremos estas configurações no nosso curso. * Fernando Lozano é analista de sistemas especialista em redes locais e consultor do Clube do Hardware. Seu site pessoal, com várias informações sobre Linux, pode ser acessado em http://www.lozano.eti.br.