Resumo sobre a configuração de redes

Resumo sobre a configuração de redes

Hoje em dia, praticamente todas as placas-mãe e notebooks trazem placas de rede onboard, o que torna a tarefa de montar a rede bastante simples. Existe a opção de montar a rede usando um switch, ou simplesmente usar um cabo cross-over para ligar diretamente os dois micros. Um cabo cross-over é um cabo de rede crimpado com uma sequência diferente nas duas pontas, que permite a comunicação direta entre os dois micros.

O switch ou o cabo cross-over resolvem o problema da ligação física entre os micros, o que equivale aos níveis 1 e 2 do modelo OSI. Falta agora configurar o TCP (níveis 3 e 4), de forma que eles possam efetivamente se comunicar.

Falando assim pode parecer difícil, mas na prática tudo o que você precisa fazer é usar dois endereços sequenciais (ou simplesmente escolher dois endereços diferentes dentro da mesma faixa de endereços) como “192.168.1.1” e “192.168.1.2” ou “10.0.0.1” e “10.0.0.2” e usar a mesma máscara de sub-rede em ambos:

index_html_m3731e1

index_html_34e59dbe

Pense nas placas, hubs e cabos como o sistema telefônico e no TCP/IP como a língua falada, que você realmente usa para se comunicar. Não adianta ligar para alguém na China que não saiba falar português. Sua voz vai chegar até lá, mas a pessoa do outro lado não vai entender nada. Além da língua em si, existe a necessidade de ter assuntos em comum para poder manter a conversa.

Ligar os cabos e ver se os leds do switch e das placas estão acesos é o primeiro passo. O segundo é configurar os endereços da rede para que os micros possam conversar entre si e o terceiro é finalmente compartilhar a conexão, arquivos, impressoras e o que mais você quer que os outros micros da rede local tenham acesso, ou mesmo configurar seu próprio servidor e disponibilizar serviços diversos para a Internet.

Graças ao TCP/IP, tanto o Linux quanto o Windows e outros sistemas operacionais em uso são intercompatíveis. Não existe problema para as máquinas com o Windows acessarem a Internet através da conexão compartilhada no Linux, por exemplo. O TCP/IP é a língua mãe que permite que todos se comuniquem.

Atualmente, o TPC/IP é suportado por todos os principais sistemas operacionais, não apenas os destinados a PCs, mas a praticamente todas as arquiteturas, incluindo até mesmo celulares e handhelds. Qualquer sistema com um mínimo de poder de processamento pode conectar-se à Internet, desde que alguém desenvolva uma implementação do TCP/IP para ele, juntamente com alguns aplicativos.

Até mesmo o MSX já ganhou um sistema operacional com suporte a TCP/IP e um navegador que, embora de forma bastante limitada, permite que um jurássico MSX com 128k de memória (ligado na TV e equipado com um modem serial) acesse a web. Se duvida, veja com seus próprios olhos no: http://uzix.sourceforge.net/uzix2.0/.

index_html_m8bfcc93

index_html_m6fc47edf

Endereços, máscaras e DHCP

Independentemente do sistema operacional usado, os parâmetros necessários para configurar a rede e acessar a web através de uma conexão compartilhada são os mesmos, muda apenas a ferramenta de configuração usada. Vamos então a uma explicação básica dos parâmetros de configuração da rede:

Endereço IP

Os endereços IP identificam cada host (ou seja, cada estação) na rede. A regra básica é que cada host deve ter um endereço IP diferente e devem ser utilizados endereços dentro da mesma faixa.

Um endereço IP é composto de uma seqüência de 32 bits, divididos em 4 grupos de 8 bits cada, chamados de octetos e cada octeto permite o uso de 256 combinações diferentes (dois elevado à oitava potência).

Para facilitar a configuração dos endereços, usamos números de 0 a 255 para representar cada octeto, formando endereços como 220.45.100.222 ou 131.175.34.7. Isso torna a tarefa de configurar e memorizar os endereços bem mais fácil do que seria se precisássemos decorar seqüências de números binários.

O endereço IP é dividido em duas partes. A primeira identifica a rede à qual o host está conectado (necessário, pois, em uma rede TCP/IP, podemos ter várias redes conectadas entre si, como no caso da Internet) e a segunda identifica o host propriamente dito dentro da rede.

Obrigatoriamente, os primeiros bits do endereço servirão para identificar a rede e os últimos servirão para identificar o computador em si. Como temos apenas 4 octetos, qualquer divisão fixa limitaria bastante o número de endereços possíveis, o que seria uma grande limitação no caso da Internet, onde existe um número muito grande de redes diferentes, muitas delas com um número muito grande de micros conectados, como no caso dos grandes provedores de acesso.

Se fosse reservado apenas o primeiro octeto do endereço, teríamos um grande número de hosts (micros conectados a cada rede), mas em compensação poderíamos ter apenas 256 redes diferentes, o que seria muito complicado, considerando o tamanho do mundo.

Mesmo se reservássemos dois octetos para a identificação da rede e dois para a identificação do host, os endereços possíveis seriam insuficientes, pois existem muito mais de 65 mil redes diferentes no mundo, conectadas entre si através da Internet, e existem muitas redes com mais de 65 mil hosts.

A primeira solução para o impasse foi a divisão dos endereços em três classes, onde cada classe reserva um número diferente de octetos para o endereçamento da rede. Atualmente, esta designação não é inteiramente válida, pois é cada vez mais usado o sistema CIDR, onde são usadas máscaras variáveis para criar faixas de endereços de diversos tamanhos (como você pode ver no meu tutorial sobre o CIDR: https://www.hardware.com.br/tutoriais/endereco-ip-cidr/). Mas, como este é um tutorial introdutório, vamos entender a divisão tradicional:

Na classe A, apenas o primeiro octeto identifica a rede, na classe B são usados os dois primeiros octetos e na classe C (a mais comum) temos os três primeiros octetos reservados para a rede e apenas o último reservado para a identificação dos hosts.

O que diferencia uma classe de endereços da outra é o valor do primeiro octeto. Se for um número entre 1 e 126 (como em 113.221.34.57), temos um endereço de classe A. Se o valor do primeiro octeto for um número entre 128 e 191, então temos um endereço de classe B (como em 167.27.135.203) e, finalmente, caso o primeiro octeto seja um número entre 192 e 223, teremos um endereço de classe C, como em 212.23.187.98.

Isso permite que existam ao mesmo tempo redes pequenas, com até 254 micros, usadas, por exemplo, por pequenas empresas e provedores de acesso, e redes muito grandes, usadas por grandes empresas, datacenters ou grandes provedores de acesso.

Todos os endereços IP válidos na Internet possuem dono. Seja alguma empresa ou alguma entidade certificadora que os fornece junto com novos links. Por isso, não podemos utilizar nenhum deles a esmo. Quando você se conecta na Internet, você recebe um único endereço IP válido, emprestado pelo provedor de acesso como, por exemplo, “200.220.231.34”. É através dele que outros hosts na Internet podem enviar informações e arquivos para o seu.

Ao configurar uma rede local, você deve usar uma das faixas de endereços reservados, endereços que não existem na Internet e que, por isso, podem ser usados livremente em redes particulares. As faixas reservadas de endereços são:

10.x.x.x, com máscara de sub-rede 255.0.0.0
172.16.x.x até 172.31.x.x, com máscara de sub-rede 255.255.0.0
192.168.0.x até 192.168.255.x, com máscara de sub-rede 255.255.255.0

Você pode usar qualquer uma dessas faixas de endereços na sua rede. Uma das faixas de endereços mais usadas é a 192.168.0.x, onde o “192.168.0.” vai ser igual em todos os micros da rede e muda apenas o último número, que pode ser de 1 até 254 (o 0 e o 255 são reservados para o endereço da rede e o sinal de broadcast). Se você tiver 4 micros na rede, os endereços deles podem ser, por exemplo, 192.168.0.1, 192.168.0.2, 192.168.0.3 e 192.168.0.4.

Micros configurados para usar faixas de endereços diferentes entendem que fazem parte de redes diferentes e não conseguem se enxergar mutuamente. Uma configuração muito comum em grandes redes é dividir os micros em diversas faixas de IPs diferentes, como 192.168.0.x, 192.168.1.x e 192.168.2.x, e usar um roteador (que pode ser um servidor com várias placas de rede) para interligá-las.

Máscara de sub-rede

A máscara de sub-rede indica qual parte do endereço é usada para endereçar a rede e qual parte é usada para endereçar o host dentro dela.

Na designação tradicional, com as três classes de endereços, a máscara acompanha a classe do endereço IP. Em um endereço de classe A, a máscara será 255.0.0.0, indicando que o primeiro octeto se refere à rede e os três últimos ao host; em um endereço classe B, a máscara padrão será 255.255.0.0, onde os dois primeiros octetos referem-se à rede e os dois últimos ao host, enquanto em um endereço classe C, a máscara padrão será 255.255.255.0, onde apenas o último octeto refere-se ao host.

Se converter o número “255” para binário, você verá que ele corresponde ao binário “11111111”, enquanto o número 0 corresponde ao binário “00000000”. Eles são usados na composição das máscaras justamente porque indicam que todos, ou que nenhum dos bits do octeto correspondente são usados para endereçar a rede.

Se as máscaras simplesmente acompanham a classe do endereço, você poderia se perguntar qual é a real necessidade delas. A resposta é que apesar das máscaras padrão acompanharem a classe do endereço IP, é possível “mascarar” um endereço IP, mudando as faixas do endereço que serão usadas para endereçar a rede e o host.

Veja, por exemplo, o endereço “192.168.0.1”. Por ser um endereço de classe C, sua máscara padrão seria 255.255.255.0, indicando que o último octeto se refere ao host, e os demais à rede. Porém, se mantivéssemos o mesmo endereço, mas alterássemos a máscara para 255.255.0.0, apenas os dois primeiros octetos (192.168) continuariam representando a rede, enquanto o host passaria a ser representado pelos dois últimos (e não apenas pelo último).

O endereço “192.168.0.1” com máscara 255.255.255.0 é diferente de “192.168.0.1” com máscara 255.255.0.0. Enquanto no primeiro caso temos o host “1” dentro da rede “192.168.0”, no segundo caso temos o host “0.1” dentro da rede “192.168”.

A moral da história é que dentro da rede você deve configurar sempre todos os micros para usarem a mesma máscara de sub-rede, seguindo a faixa de endereços escolhida. Se você está usando a faixa 192.168.0.x, então a máscara de sub-rede vai ser 255.255.255.0 para todos os micros.

Default gateway

O default gateway, ou gateway padrão é a porta de entrada e de saída da rede. Ele é o roteador que possui o link de Internet e é o responsável por roteador o tráfego dos demais hosts da rede para a Internet e vice-versa. A menos que exista outra rota definida manualmente, todo o tráfego destinado a endereços fora da rede serão encaminhados ao default gateway.

Quando você compartilha a conexão entre vários micros, apenas o servidor que está compartilhando a conexão possui um endereço IP válido, só ele “existe” na Internet. Todos os demais acessam através dele, encaminhando para ele os pacotes destinados à Internet.

Se o endereço de rede local do servidor que está compartilhando a conexão é “192.168.1.1”, então este é o endereço que todos os demais usarão como gateway padrão.

DNS

O DNS (domain name system) permite usar nomes amigáveis em vez de endereços IP para acessar servidores. Quando você se conecta à Internet e acessa o endereço https://www.hardware.com.br/, é um servidor DNS que converte o “nome fantasia” no endereço IP real do servidor, permitindo que seu micro possa acessá-lo.

Para tanto, o servidor DNS mantém uma tabela com todos os nomes fantasia, relacionados com os respectivos endereços IP. A maior dificuldade em manter um servidor DNS é justamente manter esta tabela atualizada, pois o serviço precisa ser feito manualmente.

Faz parte da configuração da rede informar os endereços DNS do provedor (ou qualquer outro servidor que você tenha acesso), que é para quem seu micro irá perguntar sempre que você tentar acessar qualquer coisa usando um nome de domínio e não um endereço IP. Servidores DNS também são muito usados em intranets, para tornar os endereços mais amigáveis e fáceis de guardar.

Por padrão são usados dois endereços. Assim, se o primeiro estiver fora do ar, o sistema envia a solicitação para o segundo. Também funciona com um endereço só, mas você perde a redundância.

Tipicamente, acessamos usando os endereços de DNS fornecidos pelo provedor de acesso, mas é possível também instalar um servidor DNS dentro da sua rede local, usando o pacote “bind” em um servidor Linux, ou utilizar um servidor de DNS público, como os servidores do http://opendns.com, que respondem pelos endereços 208.67.222.222 e 208.67.220.220.

Apesar de não parecer, a resolução de um domínio, ou seja o processo de descobrir qual é o endereço IP do servidor relacionado a ele é um processo relativamente demorado, que exige consultas a diversos servidores diferentes. Isso faz com que muitas vezes você fique vendo a célebre mensagem “localizando …” durante vários segundos ao tentar acessar um endereço.

index_html_m5ddd66aa

Na Internet, os servidores DNS formam uma gigantesca base de dados distribuída, que possui uma função crítica no funcionamento da rede. No topo da cadeia, temos os root servers, 14 servidores espalhados pelo mundo que têm como função responder a todas as requisições de resolução de domínio. Na verdade, eles não respondem nada, apenas delegam o trabalho para servidores menores, responsáveis individuais dos domínios.

Um nome de domínio é lido da direita para a esquerda. Temos os domínios primários, como .com, .net, .info, .cc, .biz, etc., e em seguida os domínios secundários, que recebem o prefixo de cada país, como .com.br ou .net.br. Nesse caso, o “com” é um subdomínio do domínio “br”.

Dentro da Internet, temos várias instituições que cuidam desta tarefa. No Brasil, por exemplo, temos o registro.br, responsável pelos domínios “.br”. Para registrar um domínio, é preciso fornecer dois endereços de DNS, que podem ser obtidos usando dois servidores dedicados, ou um único servidor com dois endereços IPs válidos. Depois que o domínio é ativado, é necessário pagar uma taxa de manutenção anual.

Quando você acessa o domínio “gdhn.com.br”, por exemplo, seu PC envia a requisição para o servidor DNS especificado na configuração da rede. Ele repassa a requisição para um dos 14 root servers da Internet. Como trata-se de um domínio “br”, a requisição é encaminhada para um dos servidores primários do registro.br, que encaminha a requisição para um dos servidores secundários, responsáveis pelo “com”, que por sua vez encaminha a requisição para o servidor responsável pelo domínio (que é geralmente uma instância do bind, rodando na própria máquina que hospeda o site), que finalmente responde a requisição. Só depois de tudo isso é que a resposta chega à sua máquina.

Como o processo é demorado, os servidores DNS mantém um cache dos endereços conhecidos, que passam a ser checados apenas esporadicamente. Com isso, servidores DNS compartilhados entre vários usuários, como no caso dos servidores DNS dos grandes provedores são geralmente mais rápidos do que servidores DNS locais, que são usados apenas pelos usuários da rede local, embora sempre existam exceções.

DHCP

O DHCP (“Dynamic Host Configuration Protocol” ou “protocolo de configuração dinâmica de endereços de rede”) permite que todos os micros da rede recebam suas configurações de rede automaticamente a partir de um servidor central, sem que você precise ficar configurando os endereços manualmente em cada um.

O protocolo DHCP trabalha de uma forma bastante interessante. Inicialmente, a estação não sabe quem é, não possui um endereço IP e não sabe sequer qual é o endereço do servidor DHCP da rede. Ela manda, então, um pacote de broadcast endereçado ao IP “255.255.255.255”, que é transmitido pelo switch para todos os micros da rede. O servidor DHCP recebe este pacote e responde com um pacote endereçado ao endereço IP “0.0.0.0”, que também é transmitido para todas as estações.

Apesar disso, apenas a estação que enviou a solicitação lerá o pacote, pois ele é endereçado ao endereço MAC da placa de rede. Quando uma estação recebe um pacote destinado a um endereço MAC diferente do seu, ela ignora a transmissão.

Dentro do pacote enviado pelo servidor DHCP estão especificados o endereço IP, máscara, gateway e servidores DNS que serão usados pela estação. Este endereço é temporário, não é da estação, simplesmente é “emprestado” pelo servidor DHCP para que seja usado durante um certo tempo (lease time), definido na configuração do servidor.

Depois de decorrido metade do tempo de empréstimo, a estação tentará contatar o servidor DHCP para renovar o empréstimo. Se o servidor DHCP estiver fora do ar, ou não puder ser contatado por qualquer outro motivo, a estação esperará até que tenha se passado 87.5% do tempo total, tentando várias vezes em seguida. Se, terminado o tempo do empréstimo, o servidor DHCP ainda não estiver disponível, a estação abandonará o endereço e ficará tentando contatar qualquer servidor DHCP disponível, repetindo a tentativa a cada 5 minutos. Porém, por não ter mais um endereço IP, a estação ficará fora da rede até que o servidor DHPC volte a responder.

Veja que uma vez instalado, o servidor DHCP passa a ser essencial para o funcionamento da rede. Se ele estiver travado ou desligado, as estações não terão como obter seus endereços IP e não conseguirão entrar na rede.

Além de serem usados dentro da rede local, os servidores DHCP são utilizados pelas operadores e pelos provedores de acesso para fornecer endereços aos clientes. Além de facilitar a configuração, isso permite que o provedor tenha um volume de assinantes maior do que o número de IPs válidos, jogando com a perspectiva de que nem todos acessarão ao mesmo tempo.

Não é necessário ter um servidor DHCP dedicado. Muito pelo contrário, o DHCP é um serviço que consome poucos recursos do sistema, por isso o mais comum é deixá-lo ativo no próprio servidor (ou modem ADSL) que compartilha a conexão. Freqüentemente, o mesmo servidor incorpora também recursos extras, como um firewall e um proxy transparente. Embora não ofereçam os mesmos recursos que um servidor Linux, os modems ADSL que podem ser configurados como roteadores quase sempre incluem a opção de ativar o servidor DHCP.

Uma observação é que na maioria dos sistemas operacionais atuais, o sistema utiliza o APIPA (Automatic Private IP Address) para configurar um endereço IP temporário caso tudo mais falhe, ou seja, se não existe configuração de rede manual e não foi possível obter a configuração via DHCP.

Com o APIPA, o host utiliza um endereço aleatório dentro da faixa 169.254.x.x (com máscara 255.255.0.0), que é uma nova faixa de endereços reservada e não roteável, que foi atribuída pela IANA em 2001.

Este endereço temporário permite que ele converse com outros micros da rede configurados da mesma forma, mas naturalmente não permite que ele acesse a web ou participe da rede local até que a rede seja realmente configurada.

Sempre que você instalar o sistema em um novo micro e ele se configurar com um endereço nessa faixa, muito provavelmente (presumindo que você tenha um servidor DHCP na rede) o sistema não conseguiu detectar corretamente a placa de rede, ou existe algum problema com o cabeamento (ou com a configuração da rede wireless, se for o caso) que está impedindo que ele acesse a rede e receba a resposta do servidor DHCP.

NAT

O NAT é uma técnica avançada de roteamento que permite que vários micros acessem a Internet usando uma única conexão e um único endereço IP válido. Não importa se você acessa via ADSL, cabo, wireless, GPRS, satélite, acesso discado ou via sinais de fumaça; usando o NAT você pode compartilhar a conexão entre os diversos micros da rede local, permitindo que todos compartilhem o link de acesso. A sigla NAT é abreviação de “Network Address Translation” (tradução de endereços de rede), o que dá uma boa dica de como o sistema funciona.

Ao receber um pacote de um dos micros da rede local endereçado à Internet, o servidor substitui o endereço da estação (192.168.0.2, por exemplo) pelo seu endereço de Internet e o envia ao destinatário. Ao receber resposta, o servidor novamente troca o endereço de Internet do destinatário pelo seu (do servidor) IP de rede local. A estação acha que está conversando diretamente com o servidor e não enxerga os demais hosts da Internet, enquanto eles (os demais hosts) enxergam apenas o servidor e não os demais micros da rede local, que permanecem invisíveis.

Este processo de tradução é feito em tempo real, sem adicionar um volume considerável de latência na conexão (ou seja, sem aumentar o ping de forma perceptível) nem reduzir a velocidade da conexão, de forma que ele se tornou largamente utilizado.

Usando o NAT, o link não é dividido entre os micros, mas sim compartilhado entre eles. Desde que um único PC esteja baixando arquivos em um dado momento, ele dispõe de toda a banda da conexão, como se estivesse acessando diretamente. Se dois PCs baixam arquivos simultaneamente, cada um fica com metade da banda e assim por diante. Desde que nem todos os usuários da rede resolvam baixar arquivos simultaneamente, você pode compartilhar uma conexão ADSL de 1 ou 2 megabits entre 10 ou 20 micros tranquilamente.

O exemplo mais comum de roteador NAT é um servidor com duas placas de rede, uma para a rede local e outra para a Internet. Depois de configuradas ambas as conexões e ativado o compartilhamento, falta apenas configurar os demais micros da rede local para utilizarem endereços dentro da mesma faixa do servidor e utilizarem seu endereço de rede local como gateway padrão.

Um exemplo de configuração de rede completa para um dos micros da rede, que vai acessar a Internet através do servidor seria:

IP: 192.168.0.2
Máscara: 255.255.255.0
Gateway: 192.168.0.1 (o endereço do servidor)
DNS: 208.67.222.222 e 208.67.220.220

Neste exemplo, estou usando dois endereços de servidores DNS externos na configuração do cliente, mas é possível também instalar um servidor DNS local no servidor. Em uma máquina Linux você só precisaria instalar o pacote “bind”, como em:

# apt-get install bind

Com isso, as máquinas da rede local poderiam usar o endereço do gateway também como DNS. Usar um DNS local não é uma grande vantagem do ponto de vista da velocidade já que um servidor de DNS compartilhado entre vários usuários pode responder a uma percentagem maior das requisições a partir do cache, mas ter um DNS local é a garantia de que você nunca ficará sem acesso por causa de problemas nos servidores DNS do provedor.

Temos aqui um exemplo de como ficaria a configuração dos endereços em uma pequena rede, com 2 micros. Note que, neste caso, os micros da rede local utilizam uma faixa de endereços privada (192.168.0.x no exemplo), uma faixa de endereços que não existe na Internet. O único que possui um endereço IP válido na Internet é o servidor, que por isso é o único que pode ser acessado diretamente de fora. Ele fica responsável por interligar as duas redes, permitindo que o outro PC acesse a Internet:

index_html_m1a298c59

Hoje em dia, o compartilhamento via NAT é oferecido por diversos dispositivos, entre eles modems ADSL e roteadores wireless, o que permite que você compartilhe a conexão entre os diversos micros da rede usando apenas o modem e o switch da rede.

É possível ainda “recompartilhar” uma conexão já compartilhada via NAT, o que pode ser usado para adicionar serviços adicionais, como um proxy transparente ou filtros de conteúdo. Você poderia ter então o modem ADSL compartilhando a conexão e um servidor Linux com duas placas de rede instalado entre ele e a rede local.

Sobre o Autor

Redes Sociais:

Deixe seu comentário

X