Ganhe R$80 por Dia. SEM INDICAR NEM VENDER


Dicas TCP IP

Precisando de Dinheiro?

Ganhe R$80 por Dia
Sem Indicar nem Vender
Apenas Visualizando Anuncios
Forneça seus Dados para Começar

atO protocolo TCP/IP e os seus aspectos básicos de utilização em redes baseadas no Windows 2000 (Server e Professional) ou Windows Server 2003 e no Windows XP e Windows Vista. Nesta primeira parte faremos uma apresentação do protocolo TCP/IP, de tal maneira que o leitor possa entender exatamente o que é o conjunto de protocolos genericamente conhecido como TCP/IP e como é configurada uma rede baseada neste protocolo. Nas demais partes deste tutorial abordaremos uma série de assuntos, tais como:
• O Sistema Binário de Numeração
• Conversão de Binário para Decimal
• Endereços IP e Máscara de sub-rede
• Configurações do TCP/IP no Windows 2000 e no Windows XP
• Endereçamento no protocolo IP
• Roteamento
• DNS
• DHCP
• WINS
• RRAS
• IPSec
• Firewall
• NAT
• O conceito de sub-redes e exemplos práticos
• Comandos disponíveis no Windows 2000
• Comandos disponíveis no Windows XP
Um visão geral do protocolo TCP/IP
Para que os computadores de uma rede possam trocar informações entre si é necessário que todos os computadores adotem as mesmas regras para o envio e o recebimento de informações. Este conjunto de regras é conhecido como Protocolo de comunicação. Falando de outra maneira podemos afirmar: “Para que os computadores de uma rede possam trocar informações entre si é necessário que todos estejam utilizando o mesmo protocolo de comunicação”. No protocolo de comunicação estão definidas todas as regras necessárias para que o computador de destino, “entenda” as informações no formato que foram enviadas pelo computador de origem. Dois computadores com diferentes protocolos instalados, não serão capazes de estabelecer uma comunicação e nem serão capazes de trocar informações.
Antes da popularização da Internet existiam diferentes protocolos sendo utilizados nas redes das empresas. Os mais utilizados eram os seguintes:
• TCP/IP
• NETBEUI
• IPX/SPX
• Apple Talk
Se colocarmos dois computadores ligados em rede, um com um protocolo, por exemplo o TCP/IP e o outro com um protocolo diferente, por exemplo NETBEUI, estes dois computadores não serão capazes de estabelecer comunicação e trocar informações entre si. Por exemplo, o computador com o protocolo NETBEUI instalado, não será capaz de acessar uma pasta ou uma Impressora compartilhada no computador com o protocolo TCP/IP instalado.
À medida que a Internet começou, a cada dia, tornar-se mais popular, com o aumento exponencial do número de usuários, o protocolo TCP/IP passou a tornar-se um padrão de fato, utilizando não só na Internet, como também nas redes internas das empresas, redes estas que começavam a ser conectadas à Internet. Como as redes internas precisavam conectar-se à Internet, tinham que usar o mesmo protocolo da Internet, ou seja: TCP/IP.
Dos principais Sistemas Operacionais do mercado, o UNIX sempre utilizou o protocolo TCP/IP como padrão. O Windows dá suporte ao protocolo TCP/IP desde as primeiras versões, porém, para o Windows, o TCP/IP somente tornou-se o protocolo padrão a partir do Windows 2000. Ser o protocolo padrão significa que o TCP/IP será instalado, automaticamente, durante a instalação do Sistema Operacional, se for detectada a presença de uma placa de rede. Até mesmo o Sistema Operacional Novell, que sempre foi baseado no protocolo IPX/SPX como protocolo padrão, passou a adotar o TCP/IP como padrão a partir da versão 5.0.
O que temos hoje, na prática, é a utilização do protocolo TCP/IP na esmagadora maioria das redes. Sendo a sua adoção cada vez maior. Como não poderia deixar de ser, o TCP/IP é o protocolo padrão do Windows 2000, Windows Server 2003, Windows XP e também do Windows Vista (a ser lançado em Fevereiro de 2007) e do Windows Longhorn Server (com lançamento previsto para o final de 2007). Se durante a instalação, o Windows detectar a presença de uma placa de rede, automaticamente será sugerida a instalação do protocolo TCP/IP.
Nota: Para pequenas redes, não conectadas à Internet, é recomendada a adoção do protocolo NETBEUI, devido a sua simplicidade de configuração. Porém esta é uma situação muito rara, pois dificilmente teremos uma rede isolada, sem conexão com a Internet ou com parceiros de negócios, como clientes e fornecedores.
Agora passaremos a estudar algumas características do protocolo TCP/IP. Veremos que cada equipamento que faz parte de uma rede baseada no TCP/IP tem alguns parâmetros de configuração que devem ser definidos, para que o equipamento possa comunicar-se com sucesso na rede e trocar informações com os demais equipamentos da rede.
Configurações do protocolo TCP/IP para um computador em rede
Quando utilizamos o protocolo TCP/IP como protocolo de comunicação em uma rede de computadores, temos alguns parâmetros que devem ser configurados em todos os equipamentos que fazem parte da rede (computadores, servidores, hubs, switchs, impressoras de rede, etc). Na Figura a seguir temos uma visão geral de uma pequena rede baseada no protocolo TCP/IP:

Figura – Uma rede baseada no protocolo TCP/IP.
No exemplo da Figura 1 temos uma rede local para uma pequena empresa. Esta rede local não está conectada a outras redes ou à Internet. Neste caso cada computador da rede precisa de, pelo menos, dois parâmetros configurados:
• Número IP
• Máscara de sub-rede
O Número IP é um número no seguinte formato:
x.y.z.w

ou seja, são quatro números separados por ponto. Não podem existir duas máquinas, com o mesmo número IP, dentro da mesma rede. Caso eu configure um novo equipamento com o mesmo número IP de uma máquina já existente, será gerado um conflito de Número IP e um dos equipamentos, muito provavelmente o novo equipamento que está sendo configurado, não conseguirá se comunicar com a rede. O valor máximo para cada um dos números (x, y, z ou w) é 255.
Uma parte do Número IP (1, 2 ou 3 dos 4 números) é a identificação da rede, a outra parte é a identificação da máquina dentro da rede. O que define quantos dos quatro números fazem parte da identificação da rede e quantos fazem parte da identificação da máquina é a máscara de sub-rede (subnet mask). Vamos considerar o exemplo de um dos computadores da rede da Figura 1:
• Número IP: 10.200.150.1
• Máscara de Sub-rede: 255.255.255.0
As três primeiras partes da máscara de sub-rede (subnet) iguais a 255 indicam que os três primeiros números representam a identificação da rede e o último número é a identificação do equipamento dentro da rede. Para o nosso exemplo teríamos a rede: 10.200.150, ou seja, todos os equipamentos do nosso exemplo fazem parte da rede 10.200.150 ou, em outras palavras, o número IP de todos os equipamentos da rede começam com 10.200.150.
Neste exemplo, onde estamos utilizando os três primeiros números para identificar a rede e somente o quarto número para identificar o equipamento, temos um limite de 254 equipamentos que podem ser ligados neste rede. Observe que são 254 e não 256, pois o primeiro número – 10.200.150.0 e o último número – 10.200.250.255 não podem ser utilizados como números IP de equipamentos de rede. O primeiro é o próprio número da rede: 10.200.150.0 e o último é o endereço de Broadcast: 10.200.150.255. Ao enviar uma mensagem para o endereço de Broadcast, todas as máquinas da rede receberão a mensagem. Nas próximas partes deste tutorial, falaremos um pouco mais sobre Broadcast.
Com base no exposto podemos apresentar a seguinte definição:
“Para se comunicar em uma rede baseada no protocolo TCP/IP, todo equipamento deve ter, pelo menos, um número IP e uma máscara de sub-rede, sendo que todos os equipamentos da rede devem ter a mesma máscara de sub-rede”.
Nota: Existem configurações mais avançadas onde podemos subdividir uma rede TCP/IP em sub-redes menores. O conceito de sub-redes será tratado, em detalhes, na Parte 7 deste tutorial.
No exemplo da figura anterior observe que o computador com o IP 10.200.150.7 está com uma máscara de sub-rede diferente da máscara de sub-rede dos demais computadores da rede. Este computador está com a máscara: 255.255.0.0 e os demais computadores da rede estão com a máscara de sub-rede 255.255.255.0. Neste caso é como se o computador com o IP 10.200.150.7 pertencesse a outra rede. Na prática o que irá acontecer é que este computador não conseguirá se comunicar com os demais computadores da rede, por ter uma máscara de sub-rede diferente dos demais. Este é um dos erros de configuração mais comuns. Se a máscara de sub-rede estiver incorreta, ou seja, diferente da máscara dos demais computadores da rede, o computador com a máscara de sub-rede incorreta não conseguirá comunicar-se na rede.
Na Tabela a seguir temos alguns exemplos de máscaras de sub-rede e do número máximo de equipamentos em cada uma das respectivas redes.
Tabela: Exemplos de máscara de sub-rede.
MáscaraNúmero de equipamentos na rede
255.255.255.0
254
255.255.0.0
65.534
255.0.0.0
16.777.214

Quando a rede está isolada, ou seja, não está conectada à Internet ou a outras redes externas, através de links de comunicação de dados, apenas o número IP e a máscara de sub-rede são suficientes para que os computadores possam se comunicar e trocar informações.
A conexão da rede local com outras redes é feita através de links de comunicação de dados. Para que essa comunicação seja possível é necessário um equipamento capaz de enviar informações para outras redes e receber informações destas redes. O equipamento utilizado para este fim é o Roteador. Todo pacote de informações que deve ser enviado para outras redes deve, obrigatoriamente, passar pelo Roteador. Todo pacote de informação que vem de outras redes também deve, obrigatoriamente, passar pelo Roteador. Como o Roteador é um equipamento de rede, este também terá um número IP. O número IP do roteador deve ser informado em todos os demais equipamentos que fazem parte da rede, para que estes equipamentos possam se comunicar com os redes externas. O número IP do Roteador é informado no parâmetro conhecido como Default Gateway. Na prática quando configuramos o parâmetro Default Gateway, estamos informando o número IP do Roteador.
Quando um computador da rede tenta se comunicar com outros computadores/servidores, o protocolo TCP/IP faz alguns cálculos utilizando o número IP do computador de origem, a máscara de sub-rede e o número IP do computador de destino (veremos estes cálculos em detalhes nas próximas lições deste curso). Se, após feitas as contas, for concluído que os dois computadores fazem parte da mesma rede, os pacotes de informação são enviados para o barramento da rede local e o computador de destino captura e processa as informações que lhe foram enviadas. Se, após feitas as contas, for concluído que o computador de origem e o computador de destino, fazem parte de redes diferentes, os pacotes de informação são enviados para o Roteador (número IP configurado como Default Gateway) e o Roteador é o responsável por achar o caminho (a rota) para a rede de destino.
Com isso, para equipamentos que fazem parte de uma rede, baseada no protocolo TCP/IP e conectada a outras redes ou a Internet, devemos configurar, no mínimo, os seguintes parâmetros:
• Número IP
• Máscara de sub-rede
• Default Gateway
Em redes empresarias existem outros parâmetros que precisam ser configurados. Um dos parâmetros que deve ser informado é o número IP de um ou mais servidores DNS – Domain Name System. O DNS é o serviço responsável pela resolução de nomes. Toda a comunicação, em redes baseadas no protocolo TCP/IP é feita através do número IP. Por exemplo, quando vamos acessar o meu site: http://www.juliobattisti.com.br/, tem que haver uma maneira de encontrar o número IP do servidor onde fica hospedado o site. O serviço que localiza o número IP associado a um nome é conhecido como Servidor DNS. Por isso a necessidade de informarmos o número IP de pelo menos um servidor DNS, pois sem este serviço de resolução de nomes, muitos recursos da rede estarão indisponíveis, inclusive o acesso à Internet.
Existem aplicativos antigos que são baseados em um outro serviço de resolução de nomes conhecido como WINS – Windows Internet Name System. O Windows NT Server 4.0 utilizava intensamente o serviço WINS para a resolução de nomes. Com o Windows 2000 o serviço utilizado é o DNS, porém podem existir aplicações que ainda dependam do WINS. Nestes casos você terá que instalar e configurar um servidor WINS na sua rede e configurar o IP deste servidor em todos os equipamentos da rede.
Dica Importante: Em redes baseadas onde ainda existem clientes baseados em versões antigas do Windows, tais como o Windows 95, Windows 98 ou Windows Me, o WINS ainda é necessário. Sem o WINS, poderá haver erro no acesso a aos principais recursos da rede, tais como pastas e impressoras compartilhadas.
As configurações do protocolo TCP/IP podem ser definidas manualmente, isto é, configurando cada um dos equipamentos necessários com as informações do protocolo, como por exemplo o Número IP, Máscara de sub-rede, número IP do Default Gateway, número IP de um ou mais servidores DNS e assim por diante. Esta é uma solução razoável para pequenas redes, porém pode ser um problema para redes maiores, com um grande número de equipamentos conectados. Para redes maiores é recomendado o uso do serviço DHCP – Dynamic Host Configuration Protocol. O serviço DHCP pode ser instalado em um servidor com o Windows NT Server 4.0, Windows 2000 Server, Windows Server 2003 ou Windows Longhorn Server. Uma vez disponível e configurado, o serviço DHCP fornece, automaticamente, todos os parâmetros de configuração do protocolo TCP/IP para os equipamentos conectados à rede. Os parâmetros são fornecidos quando o equipamento é inicializado e podem ser renovados em períodos definidos pelo Administrador. Com o uso do DHCP uma série de procedimentos de configuração podem ser automatizados, o que facilita a vida do Administrador e elimina uma série de erros.
Dica Importante: Serviços tais como um Servidor DNS e um Servidor DHCP, só podem ser instalados em computadores com uma versão de Servidor do Windows, tais como o Windows NT Server 4.0, Windows 2000 Server, Windows Server 2003 ou Windows Longhorn Server. Estes serviços não estão disponíveis em versões Clientes do Windows, tais como o Windows 95/98/Me, Windows 2000 Professional, Windows XP Professional ou Windows Vista.
O uso do DHCP também é muito vantajoso quando são necessárias alterações no número IP dos servidores DNS ou WINS. Vamos imaginar uma rede com 1000 computadores e que não utiliza o DHCP, ou seja, os diversos parâmetros do protocolo TCP/IP são configurados manualmente em cada computador. Agora vamos imaginar que o número IP do servidor DNS foi alterado. Neste caso o Administrador e a sua equipe técnica terão que fazer a alteração do número IP do servidor DNS em todas as estações de trabalho da rede. Um serviço e tanto. Se esta mesma rede estiver utilizando o serviço DHCP, bastará alterar o número do servidor DNS, nas configurações do servidor DHCP. O novo número será fornecido para todas as estações da rede, automaticamente, na próxima vez que a estação for reinicializada. Muito mais simples e prático e, principalmente, com menor probabilidade de erros.
Você pode verificar, facilmente, as configurações do protocolo TCP/IP que estão definidas para o seu computador (Windows 2000, Windows XP ou Windows Vista). Para isso siga os seguintes passos:
1. Faça o logon com uma conta com permissão de Administrador.
2. Abra o Prompt de comando: Iniciar -> Programas -> Acessórios -> Prompt de comando.
3. Na janela do Prompt de comando digite o seguinte comando:
ipconfig/all
e pressione Enter.

4. Serão exibidas as diversas configurações do protocolo TCP/IP, conforme indicado a seguir, no exemplo obtido a partir de um dos meus computadores que eu uso na rede da minha casa:

Sabia que o Autor deste Post Ganha Dinheiro até Hoje por te-lo Escrito?
Ganhe Dinheiro Escrevendo Artigos

O comando ipconfig exibe informações para as diversas interfaces de rede instaladas – placa de rede, modem, etc. No exemplo anterior temos uma única interface de rede instalada, a qual é relacionada com uma placa de rede Realtek RTL8139 Family PCI Fast Ethernet NIC. Observe que temos o número IP para dois servidores DNS e para um servidor WINS. Outra informação importante é o Endereço físico, mais conhecido como MAC-Address ou endereço da placa. O MAC-Address é um número que identifica a placa de rede. Os seis primeiros números/letras são uma identificação do fabricante da placa e os seis últimos uma identificação da placa. Não existem duas placas com o mesmo MAC-Address, ou seja, este endereço é único para cada placa de rede.
No exemplo da listagem a seguir, temos um computador com duas interfaces de rede. Uma das interfaces é ligada a placa de rede (Realtek RTL8029(AS) PCI Ethernet Adapter), a qual conecta o computador a rede local. A outra interface é ligada ao fax-modem (WAN (PPP/SLIP) Interface), o qual conecta o computador à Internet. Para o protocolo TCP/IP a conexão via Fax modem aparece como se fosse mais uma interface de rede, conforme pode ser conferido na listagem a seguir:

Bem, estes são os aspectos básicos do protocolo TCP/IP. Nos endereços a seguir, você encontra tutoriais, em português, onde você poderá aprofundar os seus estudos sobre o protocolo TCP/IP:
• http://www.juliobattisti.com.br/tcpip.asp
• http://www.guiadohardware.info/tutoriais/enderecamento_ip/index.asp
• http://www.guiadohardware.info/curso/redes_guia_completo/22.asp
• http://www.guiadohardware.info/curso/redes_guia_completo/23.asp
• http://www.guiadohardware.info/curso/redes_guia_completo/28.asp
• http://www.vanquish.com.br/site/020608
• http://unsekurity.virtualave.net/texto1/texto_tcpip_basico.txt
• http://unsekurity.virtualave.net/texto1/tcpipI.txt
• http://www.rota67.hpg.ig.com.br/tutorial/protocolos/amfhp_tcpip_basico001.htm
• http://www.rota67.hpg.ig.com.br/tutorial/protocolos/amfhp_tcpip_av001.htm
• http://www.geocities.com/ResearchTriangle/Thinktank/4203/doc/tcpip.zip
Questão de exemplo para os exames de Certificação
A seguir coloco um exemplo de questão, relacionada ao TCP/IP, que pode aparecer nos exames de Certificação da Microsoft, onde são cobrados conhecimentos básicos do protocolo TCP/IP. Esta questão faz parte dos simulados gratuitos, disponíveis aqui no site.

Questão 01 A seguir estão as configurações básicos do TCP/IP de três estações de trabalho: micro01, micro02 e micro03.
Configurações do micro01:
Número IP: 100.100.100.3
Máscara de sub-rede: 255.255.255.0
Gateway: 100.100.100.1
Configurações do micro02:
Número IP: 100.100.100.4
Máscara de sub-rede: 255.255.240.0
Gateway: 100.100.100.1
Configurações do micro03:
Número IP: 100.100.100.5
Máscara de sub-rede: 255.255.255.0
Gateway: 100.100.100.2
O micro 02 não está conseguindo comunicar com os demais computadores da rede. Já o micro03 consegue comunicar-se na rede local, porém não consegue se comunicar com nenhum recurso de outras redes, como por exemplo a Internet. Quais alterações você deve fazer para que todos os computadores possam se comunicar normalmente, tanto na rede local quanto com as redes externas?
a)
Altere a máscara de sub-rede do micro02 para 255.255.255.0
Altere o Gateway do micro03 para 100.100.100.1
b)
Altere a máscara de sub-rede do micro01 para 255.255.240.0
Altere a máscara de sub-rede do micro03 para 255.255.240.0
c)
Altere o Gateway do micro01 para 100.100.100.2
Altere o Gateway do micro02 para 100.100.100.2
d)
Altere o Gateway do micro03 para 100.100.100.1
e)
Altere a máscara de sub-rede do micro02 para 255.255.255.0

Resposta certa: a
Comentários:
Pelo enunciado o computador micro02 não consegue comunicar com nenhum outro computador da rede. Este é um sintoma típico de problema na máscara de sub-rede. É exatamente o caso, o micro02 está com uma máscara de sub-rede 255.255.240.0, diferente da máscara dos demais computadores. Por isso ele está isolado e não consegue se comunicar com os demais computadores da rede. Já o micro03 não consegue comunicar-se com outras redes, mas consegue comunicar-se na rede local. Este é um sintoma de que a configuração do Gateway está incorreta. Por isso a necessidade de alterar a configuração do Gateway do micro03, para que este utilize a mesma configuração dos demais computadores da rede. Observe como esta questão testa apenas conhecimentos básicos do TCP/IP, tais como Máscara de sub-rede e Default Gateway.

Conclusão
Na próxima lição falarei sobre o sistema de numeração binário, sobre como converter de decimal para binário e vice-versa e como o protocolo TCP/IP usa cálculos binários, com base na máscara de sub-rede, para definir se dois computadores pertencem a mesma rede ou a redes diferentes.

quem quiser mais e fonte:
TCP/IP

O endereçamento IP é sempre um tema importante, já que é ele que permite que o brutal número de redes e hosts que formam a Internet sejam capazes de se comunicar entre si.
Existem duas versões do protocolo IP: o IPV4 é a versão atual, que utilizamos na grande maioria das situações, enquanto o IPV6 é a versão atualizada, que prevê um número brutalmente maior de endereços e deve se popularizar a partir de 2012 ou 2014, quando os endereços IPV4 começarem a se esgotar.
No IPV4, os endereços IP são compostos por 4 blocos de 8 bits (32 bits no total), que são representados através de números de 0 a 255 (cobrindo as 256 possibilidades permitidas por 8 bits), como “200.156.23.43” ou “64.245.32.11”. Os grupos de 8 bits que formam o endereço são chamados de “octetos”, o que dá origem a expressões como “o primeiro octeto do endereço”. De qualquer forma, a divisão dos endereços em octetos e o uso de números decimais serve apenas para facilitar a configuração para nós, seres humanos. Quando processados, os endereços são transformados em binários, como “11001000100110010001011100101011”.
As faixas de endereços começadas com “10”, “192.168” ou de “172.16” até “172.31” são reservadas para uso em redes locais e por isso não são usadas na Internet. Os roteadores que compõe a grande rede são configurados para ignorar pacotes provenientes destas faixas de endereços, de forma que as inúmeras redes locais que utilizam endereços na faixa “192.168.0.x” (por exemplo) podem conviver pacificamente, sem entrar em conflito.
No caso dos endereços válidos na Internet, as regras são mais estritas. A entidade global responsável pelo registro e atribuição dos endereços é a IANA (http://www.iana.org/), que delega faixas de endereços às RIRs (Regional Internet Registries), entidades menores, que ficam responsáveis por delegar os endereços regionalmente. Nos EUA, por exemplo, a entidade responsável é a ARIN (http://www.arin.net/) e no Brasil é a LACNIC (http://www.lacnic.net/pt/). Estas entidades são diferentes das responsáveis pelo registro de domínios, como o Registro.br.
As operadoras, carriers e provedores de acesso pagam uma taxa anual à RIR responsável, que varia de US$ 1.250 a US$ 18.000 (de acordo com o volume de endereços requisitados) e embutem o custo nos links revendidos aos clientes. Note que estes valores são apenas as taxas pelo uso dos endereços, não incluem o custo dos links, naturalmente.
Ao conectar via ADSL ou outra modalidade de acesso doméstico, você recebe um único IP válido. Ao alugar um servidor dedicado você recebe uma faixa com 5 ou mais endereços e, ao alugar um link empresarial você pode conseguir uma faixa de classe C inteira. Mas, de qualquer forma, os endereços são definidos “de cima para baixo” de acordo com o plano ou serviço contratado e você não pode escolher quais endereços utilizar.
Embora aparentem ser uma coisa só, os endereços IP incluem duas informações: o endereço da rede e o endereço do host dentro dela. Em uma rede doméstica, por exemplo, você poderia utilizar os endereços “192.168.1.1”, “192.168.1.2” e “192.168.1.3”, onde o “192.168.1.” é o endereço da rede (e por isso não muda) e o último número (1, 2 e 3) identifica os três micros que fazem parte dela.
Os micros da rede local podem acessar a Internet através de um roteador, que pode ser tanto um servidor com duas placas de rede quando um modem ADSL ou outro dispositivo que ofereça a opção de compartilhar a conexão. Nesse caso, o roteador passa a ser o gateway da rede e utiliza seu endereço IP válido para encaminhar as requisições feitas pelos micros da rede interna. Esse recurso é chamado de NAT (Network Address Translation).
Um dos micros da rede local, neste caso, poderia usar esta configuração de rede:
Endereço IP: 192.168.1.2
Máscara: 255.255.255.0
Gateway: 192.168.1.1 (o servidor compartilhando a conexão)
DNS: 200.169.126.15 (o DNS do provedor)
O servidor, por sua vez, utilizaria uma configuração similar a esta:
Placa de rede 1 (rede local):
Endereço IP: 192.168.1.1
Máscara: 255.255.255.0
Placa de rede 2 (Internet):
Endereço IP: 200.213.34.21
Máscara: 255.255.255.0
Gateway: 200.213.34.1 (o gateway do provedor)
DNS: 200.169.126.15 (o DNS do provedor)
A configuração da segunda placa de rede seria obtida automaticamente, via DHCP, de forma que você só precisaria realmente se preocupar com a configuração da sua rede local. Normalmente, você primeiro configuraria a rede local, depois conectaria o servidor à Internet e, depois de checar as duas coisas, ativaria o compartilhamento da conexão via NAT.
O servidor DHCP incluído no ICS do Windows utiliza uma configuração fixa, fornecendo endereços dentro da faixa “192.168.0.x”, mas ao utilizar um servidor Linux, ou qualquer outro dispositivo de rede que ofereça um servidor DHCP com mais recursos, você pode escolher qualquer faixa de endereços e também configurar uma “zona” para os endereços do servidor DHCP, permitindo que você tenha micros com IPs fixos e IPs dinâmicos (fornecidos pelo servidor DHCP) na mesma rede. Nesse caso, você poderia ter uma configuração como a seguinte:
192.168.0.1: Gateway da rede
192.168.0.2: Ponto de acesso wireless
192.168.0.3: Servidor de arquivos para a rede interna
192.168.0.4 até 192.168.0.99: Micros da rede configurados com IP fixo
192.168.0.100 até 192.168.0.254: Faixa de endereços atribuída pelo servidor DHCP
Veja que usar uma das faixas de endereços reservadas não impede que os PCs da sua rede possam acessar a Internet. Embora eles não acessem diretamente, por não possuírem IPs válidos, eles podem acessar através de uma conexão compartilhada via NAT ou de um servidor proxy. É possível inclusive configurar o firewall, ativo no gateway da rede para redirecionar portas (port forwarding) para micros dentro da rede local, de forma que eles possam ser acessados remotamente. O servidor nesse caso “empresta” uma porta, ou uma determinada faixa de portas para o endereço especificado dentro da rede local. Quando alguém da Internet acessa uma das portas encaminhadas no servidor, é automaticamente redirecionado para a porta correspondente no micro da rede interna, de forma transparente.
O uso dos endereços de rede local tem aliviado muito o problema da falta de endereços IP válidos, pois uma quantidade enorme de empresas e usuários domésticos, que originalmente precisariam de uma faixa de endereços completa para colocar todos os seus micros na Internet, pode sobreviver com um único IP válido (compartilhado via NAT entre todos os micros da rede). Em muitos casos, mesmo provedores de acesso chegam a vender conexões com endereços de rede interna nos planos mais baratos, como, por exemplo, alguns planos de acesso via rádio, onde um roteador com um IP válido distribui endereços de rede interna (conexão compartilhada) para os assinantes.
Embora seja possível, pelo menos em teoria, ter redes com até 24 milhões de PCs, usando a faixa de endereços de rede local 10.x.x.x, na prática é raro encontrar segmentos de rede com mais de 100 ou 200 micros. Conforme a rede cresce, o desempenho acaba caindo, pois, mesmo ao utilizar um switch, sempre são transmitidos alguns pacotes de broadcast (que são retransmitidos a todos os micros do segmento). A solução nesse caso é dividir a rede em segmentos separados, interligados por um roteador.
Em uma empresa, poderíamos (por exemplo) ter três segmentos diferentes, um para a rede cabeada (e a maior parte dos micros), outro para a rede wireless e outro para os servidores, que ficariam isolados em uma sala trancada.
O roteador nesse caso teria 4 interfaces de rede (uma para cada um dos três segmentos e outra para a Internet). A vantagem de dividir a rede desta maneira é que você poderia criar regras de firewall no roteador, especificando regras diferentes para cada segmento. Os micros conectados à rede wireless (menos segura), poderiam não ter acesso aos servidores, por exemplo. Quando falo em “roteador”, tenha em mente que você pode perfeitamente usar um servidor Linux com diversas placas de rede.
Com relação à proteção da rede contra acessos provenientes da Internet, você poderia tanto configurar o próprio firewall ativo no roteador, de forma a proteger os micros da rede local, quanto instalar um firewall dedicado (que pode ser um PC com duas placas de rede, configurado adequadamente) entre ele e a Internet:

Voltando à questão dos endereços: inicialmente os endereços IP foram divididos em classes, denominadas A, B, C, D e E. Destas, apenas as classe A, B e C são realmente usadas, já que as classes D e E são reservadas para recursos experimentais e expansões futuras.
Cada classe reserva um número diferente de octetos para o endereçamento da rede. Na classe A, apenas o primeiro octeto identifica a rede, na classe B são usados os dois primeiros octetos e na classe C temos os três primeiros octetos reservados para a rede e apenas o último reservado para a identificação dos hosts dentro dela.
O que diferencia uma classe de endereços da outra é o valor do primeiro octeto. Se for um número entre 1 e 126 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 e, finalmente, caso o primeiro octeto seja um número entre 192 e 223, temos um endereço de classe C.

Ao configurar uma rede local, você pode escolher a classe de endereços mais adequada. Para uma pequena rede, uma faixa de endereços de classe C (como a tradicional 192.168.0.x com máscara 255.255.255.0) é mais apropriada, pois você precisa se preocupar em configurar apenas o último octeto do endereço ao atribuir os endereços. Em uma rede de maior porte, com mais de 254 micros, passa a ser necessário usar um endereço de classe B (com máscara 255.255.0.0), onde podemos usar diferentes combinações de números nos dois últimos octetos, permitindo um total de 65.534 endereços.
Continuando, temos a configuração das máscaras de sub-rede, que servem para indicar em que ponto termina a identificação da rede e começa a identificação do host. Ao usar a máscara “255.255.255.0”, por exemplo, indicamos que os três primeiros números (ou octetos) do endereço servem para identificar a rede e apenas o último indica o endereço do host dentro dela.
Como vimos, na divisão original (que não é mais usada hoje em dia, como veremos a seguir) os endereços das três faixas eram diferenciados pelo número usado no primeiro octeto. Os endereços de classe A começavam com números de 1 a 126 (como, por exemplo, “62.34.32.1”), com máscara 255.0.0.0. Cada faixa de endereços classe A era composta de mais de 16 milhões de endereços mas, como existiam apenas 126 delas, elas eram reservadas para o uso de grandes empresas e órgãos governamentais.
Em seguida tínhamos os endereços de classe B, que englobavam os endereços iniciados com de 128 a 191, com máscara 255.255.0.0 (criando faixas compostas por 65 mil endereços) e o “terceiro mundo”, que eram as faixas de endereços classe C. Elas abrangiam os endereços que começam com números de 192 a 223. As faixas de endereços de classe C eram mais numerosas, pois utilizavam máscara 255.255.255.0, mas, em compensação, cada faixa de classe C era composta por apenas 254 endereços. Veja alguns exemplos:
Ex. de endereço IP Classe do endereço Parte referente à rede Parte referente ao host Máscara de sub-rede padrão
98.158.201.128 Classe A 98. 158.201.128 255.0.0.0 (rede.host.host.host)
158.208.189.45 Classe B 158.208. 189.45 255.255.0.0 (rede.rede.host.host)
208.183.34.89 Classe C 208.183.34. 89 255.255.255.0
(rede.rede.rede.host)

Ao alugar um backbone vinculado a uma faixa de endereços classe C, por exemplo, você receberia uma faixa de endereços como “203.107.171.x”, onde o “203.107.171” é o endereço de sua rede dentro da Internet, e o “x” é a faixa de 254 endereços que você pode usar para identificar seus servidores e os hosts dentro da rede. Na ilustração temos um resumo das regras para endereços TCP/IP válidos:

Como você pode notar no diagrama, nem todas as combinações de endereços são permitidas, pois o primeiro endereço (0) é reservado à identificação da rede, enquanto o último (255) é reservado ao endereço de broadcast, que é usado quando alguma estação precisa enviar um pacote simultaneamente para todos os micros dentro do segmento de rede.
Os pacotes de broadcast são usados para, por exemplo, configurar a rede via DHCP e localizar os compartilhamentos de arquivos dentro de uma rede Windows (usando o antigo protocolo NetBIOS). Mesmo os switches e hub-switches detectam os pacotes de broadcast e os transmitem simultaneamente para todas as portas. A desvantagem é que, se usados extensivamente, eles prejudicam o desempenho da rede.
Veja alguns exemplos de endereços inválidos:
0.xxx.xxx.xxx: Nenhum endereço IP pode começar com zero, pois ele é usado para o endereço da rede. A única situação em que um endereço começado com zero é usado, é quando um servidor DHCP responde à requisição da estação. Como ela ainda não possui um endereço definido, o pacote do servidor é endereçado ao endereço MAC da estação e ao endereço IP “0.0.0.0”, o que faz com que o switch o envie para todos os micros da rede.
127.xxx.xxx.xxx: Nenhum endereço IP pode começar com o número 127, pois este número é reservado para testes e para a interface de loopback. Se por exemplo você tiver um servidor de SMTP e configurar seu programa de e-mail para usar o servidor 127.0.0.1, ele acabará usando o servidor instalado na sua própria máquina. O mesmo acontece ao tentar acessar o endereço 127.0.0.1 no navegador: você vai cair em um servidor web habilitado na sua máquina. Além de testes em geral, a interface de loopback é usada para comunicação entre diversos programas, sobretudo no Linux e outros sistemas Unix.
255.xxx.xxx.xxx, xxx.255.255.255, xxx.xxx.255.255: Nenhum identificador de rede pode ser 255 e nenhum identificador de host pode ser composto apenas de endereços 255, seja qual for a classe do endereço, pois estes endereços são usados para enviar pacotes de broadcast. Outras combinações são permitidas, como em 65.34.255.197 (em um endereço de classe A) ou em 165.32.255.78 (endereço de classe B).
xxx.0.0.0, xxx.xxx.0.0: Nenhum identificador de host pode ser composto apenas de zeros, seja qual for a classe do endereço, pois estes endereços são reservados para o endereço da rede. Como no exemplo anterior, são permitidas outras combinações como 69.89.0.129 (classe A) ou 149.34.0.95 (classe B).
xxx.xxx.xxx.255, xxx.xxx.xxx.0: Nenhum endereço de classe C pode terminar com 0 ou com 255, pois, como já vimos, um host não pode ser representado apenas por valores 0 ou 255, já que eles são usados para o envio de pacotes de broadcast.
Dentro de redes locais, é possível usar máscaras diferentes para utilizar os endereços IP disponíveis de formas diferentes das padrão. O importante neste caso é que todos os micros da rede sejam configurados com a mesma máscara, caso contrário você terá problemas de conectividade, já que tecnicamente os micros estarão em redes diferentes.
Um exemplo comum é o uso da faixa de endereços 192.168.0.x para redes locais. Originalmente, esta é uma faixa de endereços classe C e por isso a máscara padrão é 255.255.255.0. Mesmo assim, muita gente prefere usar a máscara 255.255.0.0, o que permite mudar os dois últimos octetos (192.168.x.x). Neste caso, você poderia ter dois micros, um com o IP “192.168.2.45” e o outro com o IP “192.168.34.65” e ambos se enxergariam perfeitamente, pois entenderiam que fazem parte da mesma rede. Não existe problema em fazer isso, desde que você use a mesma máscara em todos os micros da rede.
O desenvolvimento das diferentes arquiteturas de redes começou bem antes do que se imagina e, como a maioria das grandes invenções, o propósito inicial era o uso militar, ainda na época da Guerra Fria. Uma das principais prioridades dentro de uma força militar é a comunicação, certo? No final da década de 60, esta era uma grande preocupação do DOD, Departamento de Defesa do Exército Americano: como interligar computadores de arquiteturas completamente diferentes, e que ainda por cima estavam muito distantes um do outro, ou mesmo em alto-mar, dentro de um porta aviões ou submarino? Após alguns anos de pesquisa, surgiu o TCP/IP, abreviação de “Transmission Control Protocol/Internet Protocol”, ou protocolo de controle de transmissão/protocolo internet. O TPC/IP permitiu que as várias pequenas redes de computadores do exército Americano fossem interligadas, formando uma grande rede, embrião do que hoje conhecemos como Internet. Como vimos, o TCP/IP é composto de dois protocolos, o IP cuida do endereçamento, enquanto o TCP cuida da transmissão dos dados e correção de erros. O segredo do TCP/IP é dividir a grande rede em pequenas redes independentes, interligadas por roteadores. Como (apesar de interligadas) cada rede é independente da outra, caso uma das redes pare, apenas aquele segmento fica fora do ar, sem afetar a rede como um todo. No caso do DOD, este era um recurso fundamental, pois durante uma guerra ou durante um ataque nuclear, vários dos segmentos da rede seriam destruídos, junto com suas respectivas bases, navios, submarinos, etc. Era crucial que o que sobrasse da rede continuasse no ar, permitindo ao comando coordenar um contra-ataque. Veja que mesmo atualmente este recurso continua sendo fundamental na Internet: se os roteadores de um provedor de acesso ficam fora do ar, apenas os clientes dele são prejudicados. Apesar de inicialmente o uso do TPC/IP ter sido restrito a aplicações militares, com o passar do tempo o protocolo acabou tornando-se de domínio público, o que permitiu aos fabricantes de software adicionar suporte ao TCP/IP aos seus sistemas operacionais de rede. 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 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/ ;). Voltando à história da Internet, pouco depois de conseguir interligar seus computadores com sucesso, o DOD interligou alguns de seus computadores às redes de algumas universidades e centros de pesquisa, formando uma inter-rede, ou Internet. Logo a seguir, no início dos anos 80, a NSF (National Science Foundation) construiu uma rede de fibra óptica de alta velocidade, conectando centros de supercomputação localizados em pontos-chave nos EUA e interligando-os também à rede do DOD. Essa rede da NSF teve um papel fundamental no desenvolvimento da Internet, por reduzir substancialmente o custo da comunicação de dados para as redes de computadores existentes, que foram amplamente estimuladas a se conectar ao backbone da NSF e, conseqüentemente, à Internet. A partir de abril de 1995, o controle do backbone (que já havia se tornado muito maior, abrangendo quase todo o planeta através de cabos submarinos e satélites) foi passado para o controle privado. Além do uso acadêmico, o interesse comercial pela Internet impulsionou seu crescimento, chegando ao que temos hoje. Tudo o que vimos até agora, sobre placas e cabos, representa a parte física da rede, os componentes necessários para fazer os uns e zeros enviados por um computador chegarem ao outro. O protocolo de rede é o conjunto de regras e padrões que permite que eles realmente falem a mesma língua. 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 hub 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 internet, arquivos, impressoras e o que mais você quer que os outros micros da rede tenham acesso (dentro da rede interna), ou mesmo alugar seu próprio servidor dedicado, hospedado em um datacenter. Graças ao TCP/IP, tanto o Linux quanto o Windows e outros sistemas operacionais em uso são intercompatíveis dentro da rede. 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.
omo já vimos, dentro de uma rede TCP/IP, cada micro recebe um endereço IP único que o identifica na rede. Um endereço IP é composto de uma seqüência de 32 bits, divididos em 4 grupos de 8 bits cada. Cada grupo de 8 bits recebe o nome de octeto.
O endereço IP é dividido em duas partes. A primeira identifica a rede à qual o computador está conectado e a segunda identifica o host dentro da rede. Para melhorar o aproveitamento dos endereços disponíveis, os desenvolvedores do TPC/IP dividiram o endereçamento IP em cinco classes, denominadas A, B, C, D, e E, sendo as três primeiras são usadas para fins de endereçamento e as duas últimas são reservadas para expansões futuras. Cada classe reserva um número diferente de octetos para o endereçamento da rede.
Na classe A, apenas o primeiro octeto identifica a rede, na classe B são usados os dois primeiros octetos e na classe C temos os três primeiros octetos reservados para a rede e apenas o último reservado para a identificação dos hosts dentro da rede.
O que diferencia uma classe de endereços da outra é o valor do primeiro octeto. Se for um número entre 1 e 126 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 e, finalmente, caso o primeiro octeto seja um número entre 192 e 223, teremos um endereço de classe C.

Ao configurar uma rede local, você pode escolher a classe de endereços mais adequada. Para uma pequena rede, uma faixa de endereços de classe C é a mais apropriada, pois você precisa se preocupar em configurar apenas o último octeto do endereço ao atribuir os endereços. Em uma rede de maior porte, com mais de 254 micros, passa a ser necessário usar um endereço de classe B, onde podemos usar diferentes combinações de números nos dois últimos octetos, permitindo um total de 65.534 endereços.
É muito difícil encontrar uma situação onde seja necessário usar uma faixa de endereços de classe A, pois redes muito grandes acabam sendo divididas em vários segmentos diferentes, interligados por roteadores. Neste caso, cada segmento é endereçado como se fosse uma rede separada, usando faixas de classe C ou B.
Na internet, todos os endereços IP disponíveis já possuem dono. Ao contratar algum tipo de conexão você recebe um único endereço (como numa linha ADSL) ou uma faixa de classe C inteira (ao alugar um backbone por exemplo). Os endereços de classe B são reservados às grandes empresas e provedores de acesso, enquanto os endereços de classe A são praticamente impossíveis de se conseguir, mesmo para grandes corporações.
Ao alugar um backbone vinculado a uma faixa de endereços classe C, por exemplo, você recebe uma faixa de endereços como “203.107.171.x”, onde o “203.107.171” é o endereço de sua rede dentro da internet, e o “x” é a faixa de 254 endereços que você pode usar para identificar seus servidores. Na ilustração temos um resumo das regras para endereços TCP/IP válidos:

Como você pode notar no diagrama, nem todas as combinações de endereços são permitidas, pois o primeiro endereço (0) é reservado à identificação da rede, enquanto o último (255) é reservado ao endereço de broadcast, que é usado quando alguma estação precisa enviar um pacote simultaneamente para todos os demais micros da rede.
Os pacotes de broadcast são usados para, por exemplo, configurar a rede via DHCP e localizar os compartilhamentos de arquivos dentro de uma rede Windows. Mesmo os switches e hub-switches detectam os pacotes de broadcast e os transmitem simultaneamente para todas as portas. A desvantagem é que, se usados extensivamente, eles prejudicam a velocidade da rede.
Veja alguns exemplos de endereços inválidos:
0.xxx.xxx.xxx: Nenhum endereço IP pode começar com zero, pois ele é usado para o endereço da rede. A única situação em que um endereço começado com zero é usado, é quando um servidor DHCP responde à requisição da estação. Como ela ainda não possui um endereço definido, o pacote do servidor é endereçado ao endereço MAC da estação e ao endereço IP “0.0.0.0”, o que faz com que o switch o envie para todos os micros da rede.
127.xxx.xxx.xxx: Nenhum endereço IP pode começar com o número 127, pois este número é reservado para a interface de loopback, ou seja, são destinados à própria máquina que enviou o pacote. Se por exemplo você tiver um servidor de SMTP e configurar seu programa de e-mail para usar o servidor 127.0.0.1, ele acabará usando o servidor instalado na sua própria máquina. O mesmo acontece ao tentar acessar o endereço 127.0.0.1 no navegador: você vai cair em um servidor web habilitado na sua máquina. Além de testes em geral, a interface de loopback é usada para comunicação entre diversos programas, sobretudo no Linux e outros sistemas Unix.
255.xxx.xxx.xxx, xxx.255.255.255, xxx.xxx.255.255: Nenhum identificador de rede pode ser 255 e nenhum identificador de host pode ser composto apenas de endereços 255, seja qual for a classe do endereço, pois estes endereços são usados para enviar pacotes de broadcast.
Outras combinações são permitidas, como em 65.34.255.197 (em um endereço de classe A) ou em 165.32.255.78 (endereço de classe B).
xxx.0.0.0, xxx.xxx.0.0: Nenhum identificador de host pode ser composto apenas de zeros, seja qual for a classe do endereço, pois estes endereços são reservados para o endereço da rede. Como no exemplo anterior, são permitidas outras combinações como 69.89.0.129 (classe A) ou 149.34.0.95 (classe B).
xxx.xxx.xxx.255, xxx.xxx.xxx.0: Nenhum endereço de classe C pode terminar com 0 ou com 255, pois, como já vimos, um host não pode ser representado apenas por valores 0 ou 255, já que eles são usados para o envio de pacotes de broadcast.
Se você não pretende conectar sua rede à internet, pode utilizar qualquer faixa de endereços IP válidos e tudo irá funcionar sem problemas. Mas, a partir do momento em que você resolver conectá-los à web, os endereços da sua rede poderão entrar em conflito com endereços já usados na web.
Na prática isto não acontece, pois os roteadores do provedor de acesso perceberão que estão sendo usados endereços inválidos e se recusarão a rotear pacotes provenientes da sua rede, mas, de qualquer forma, não é elegante depender dos outros para corrigir seus erros de configuração.
Para resolver este problema, basta utilizar uma das faixas de endereços reservados que vimos no capítulo 2. Estas faixas são reservadas justamente ao uso em redes internas, por isso não são roteadas na internet. As faixas de endereços reservados mais comuns são 10.x.x.x e 192.168.x.x, onde respectivamente o 10 e o 192.168 indicam o endereço da rede e o endereço do host pode ser configurado da forma que você desejar.
O ICS (o recurso de compartilhamento de conexão, presente no Windows 98 SE em diante) usa a faixa de endereços 192.168.0.x. Ao compartilhar a conexão com a web utilizando este recurso, você simplesmente não terá escolha. O servidor de conexão passa a usar o endereço 192.168.0.1, e todos os demais micros que forem ter acesso à web devem usar endereços de 192.168.0.2 a 192.168.0.254, já que o ICS permite compartilhar a conexão entre apenas 254 PCs.
Ao compartilhar a conexão usando um servidor Linux (como veremos no capítulo 5), você pode escolher qualquer faixa de endereços e também configurar uma “zona” para os endereços do servidor DHCP, permitindo que você tenha micros com IPs fixos e IPs dinâmicos, fornecidos pelo servidor DHCP, na mesma rede.
Veja que usar uma destas faixas de endereços reservados não impede que os PCs da sua rede possam acessar a internet, todos podem acessar através de uma conexão compartilhada via NAT ou de um servidor proxy.
O uso dos endereços de rede local tem aliviado muito o problema da falta de endereços IP válidos, pois uma quantidade enorme de empresas e usuários domésticos, que originalmente precisariam de uma faixa de endereços de classe C para colocar todos os seus micros na internet, pode sobreviver com um único IP válido, compartilhado via NAT entre todos. Em muitos casos, mesmo provedores de acesso chegam a vender conexões com endereços de rede interna nos planos mais baratos, como, por exemplo, alguns planos de acesso via rádio, onde um roteador com um IP válido distribui endereço de rede interna (conexão compartilhada) para os assinantes.
Embora seja possível, pelo menos em teoria, ter redes com até 24 milhões de PCs, usando a faixa de endereços 10.x.x.x, na prática é raro encontrar segmentos de rede com mais de 100 ou 200 micros. Conforme a rede cresce, o desempenho acaba caindo, pois, mesmo ao utilizar um switch, sempre são transmitidos alguns pacotes de broadcast (que são retransmitidos a todos os micros da rede), sem falar nas colisões.
A solução nesse caso é dividir a rede em diversos segmentos, interligados entre si por um roteador. Imagine o caso de uma escola com 5 laboratórios, cada um com 40 micros. Não seria muito prático, nem eficiente, tentar interligar todos os micros diretamente. Ao invés disso, você poderia dividir a rede em pequenos segmentos, onde os 40 micros de cada laboratório são ligados a um pequeno servidor e estes são ligados a um roteador central, que compartilha a conexão com a web e pode acumular funções de firewall, proxy, servidor de arquivos, etc.
Quando falo em “roteador”, tenha em mente que você pode perfeitamente usar um servidor Linux com diversas placas de rede, configurado com as dicas do restante do livro.
Entendendo as máscaras de sub-rede

Além do endereço IP propriamente dito, é necessário fornecer também a máscara de sub-rede, ou “subnet mask” na configuração da rede. Ao contrário do endereço IP, que é formado por valores entre 0 e 255, a máscara de sub-rede é normalmente formada por apenas dois valores: 0 e 255, como em 255.255.0.0 ou 255.0.0.0, onde o valor 255 indica a parte endereço IP referente à rede, e o valor 0 indica a parte endereço IP referente ao host.
A máscara de rede padrão 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 e, 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.
Ex. de endereço IP Classe do endereço Parte referente à rede Parte referente ao host Máscara de sub-rede padrão
98.158.201.128 Classe A 98. 158.201.128 255.0.0.0 (rede.host.host.host)
158.208.189.45 Classe B 158.208. 189.45 255.255.0.0 (rede.rede.host.host)
208.183.34.89 Classe C 208.183.34. 89 255.255.255.0
(rede.rede.rede.host)
Mas, é possível usar máscaras diferentes para utilizar os endereços IP disponíveis de formas diferentes das padrão. O importante, neste caso, é que todos os micros da rede sejam configurados com a mesma máscara, caso contrário poderão não conseguir comunicar-se, pois pensarão estar conectados a redes diferentes.
Um exemplo comum é o uso da faixa de endereços 192.168.0.x para redes locais. Originalmente, esta é uma faixa de endereços classe C e por isso a máscara padrão é 255.255.255.0. Mesmo assim, muita gente prefere usar a máscara 255.255.0.0, o que permite mudar os dois últimos octetos (192.168.x.x). Neste caso, você poderia ter dois micros, um com o IP “192.168.2.45” e o outro com o IP “192.168.34.65” e ambos se enxergariam perfeitamente, pois entenderiam que fazem parte da mesma rede. Não existe problema em fazer isso, desde que você use a mesma máscara em todos os micros da rede.
Até agora vimos apenas máscaras de sub-rede simples. Porém, o recurso mais refinado das máscaras de sub-rede é quebrar um octeto do endereço IP em duas partes, fazendo com que tenhamos dentro de um mesmo octeto uma parte que representa a rede e outra que representa o host. Chegamos às máscaras de tamanho variável (VLSM).
Este conceito é um pouco complicado, mas, em compensação, pouca gente sabe usar este recurso, por isso vale à pena fazer um certo esforço para aprender.
Configurando uma máscara complexa, precisaremos configurar o endereço IP usando números binários e não decimais. Para converter um número decimal em um número binário, você pode usar a calculadora do Windows ou o Kcalc no Linux. Configure a calculadora para o modo científico (exibir/científica) e verá que do lado esquerdo aparecerá um menu de seleção permitindo (entre outros) escolher entre decimal (dec) e binário (bin).

Configure a calculadora para binário e digite o número 11111111, mude a opção da calculadora para decimal (dec) e a calculadora mostrará o número 255, que é o seu correspondente em decimal. Tente de novo agora com o binário 00000000 e terá o número decimal 0.

Veja que 0 e 255 são exatamente os números que usamos nas máscaras de sub-rede simples. O número decimal 255 (equivalente a 11111111) indica que todos os 8 números binários do octeto se referem ao host, enquanto o decimal 0 (correspondente a 00000000) indica que todos os 8 binários do octeto se referem ao host. Numa rede com máscara 255.255.255.0 temos:
Decimal: 255 255 255 0
Binário: 11111111 11111111 11111111 00000000
rede rede rede host
As máscaras de tamanho variável permitem dividir uma única faixa de endereços (seja de classe A, B ou C) em duas ou mais redes distintas, cada uma recebendo parte dos endereços disponíveis. Imagine o caso de um pequeno provedor de acesso, que possui um backbone com uma faixa de endereços de classe C e precisa dividi-lo entre dois clientes, onde cada um deles deve ter uma faixa completa de endereços.
O backbone do provedor utiliza a faixa de endereços 203.107.171.x onde o 203.107.171 é o endereço da rede e o “x” é a faixa de endereços de que eles dispõem para endereçar os micros das duas empresas. Como endereçar ambas as redes, se não é possível alterar o “203.107.171” que é a parte do seu endereço que se refere à rede?
Este problema poderia ser resolvido usando uma máscara de sub-rede complexa. Veja que podemos alterar apenas dos últimos 8 bits do endereço IP:
Decimal: 203 107 171 x
Binário: 11001011 11010110 10101011 ????????
Usando uma máscara 255.255.255.0, são reservados todos os 8 bits para o endereçamento dos hosts, e não sobra nada para diferenciar as duas redes. Usando uma máscara complexa, é possível “quebrar” os 8 bits do octeto em duas partes, usando a primeira para diferenciar as duas redes e a segunda para endereçar os hosts:
Decimal: 203 107 171 x
Binário: 11001011 11010110 10101011 ???? ????
rede rede rede rede host
Para tanto, ao invés de usar a máscara de sub-rede 255.255.255.0 que, como vimos, reservaria todos os 8 bits para o endereçamento do host, usaremos uma máscara 255.255.255.240 (corresponde ao binário 11111111.111111.11111111.11110000). Veja que numa máscara de sub-rede os números binários “1” referem-se à rede e os números “0” referem-se ao host. Na máscara 255.255.255.240 temos exatamente esta divisão: os 4 primeiros binários do último octeto são positivos e os quatro últimos são negativos:
Decimal: 255 255 255 240
Binário: 11111111 11111111 11111111 1111 0000
rede rede rede rede host
Temos agora o último octeto dividido em dois endereços binários de 4 bits cada. Cada um dos dois grupos representa agora um endereço distinto, e deve ser configurado independentemente. Como fazer isso? Veja que 4 bits permitem 16 combinações diferentes. Se você converter o número 15 em binário terá “1111” e, se converter o decimal 0, terá “0000”. Se converter o decimal 11 terá “1011” e assim por diante.
Neste caso, é possível usar endereços de 1 a 14 para identificar os hosts e as redes separadas. Note que os endereços 0 e 15 não podem ser usados, pois assim como os endereços 0 e 255, eles são reservados para pacotes de broadcast:
Decimal: 203 107 171 12 _ 14
Binário: 11111111 11111111 11111111 1100 1110
rede rede rede rede host
Estabeleça um endereço de rede para cada uma das duas sub-redes disponíveis e um endereço diferente para cada micro da rede, mantendo a formatação do exemplo anterior. Por enquanto, apenas anote em um papel os endereços escolhidos, junto como seu correspondente em binários.
Na hora de configurar o endereço IP nas estações, configure primeiro a máscara de sub-rede como 255.255.255.240 e, em seguida, converta os endereços binários em decimais, para ter o endereço IP de cada estação. No exemplo da ilustração anterior, havíamos estabelecido o endereço 12 para a rede e o endereço 14 para a estação; 12 corresponde a “1100” e 14 corresponde a “1110”. Juntando os dois temos “11001110”, que corresponde ao decimal “206”. O endereço IP da estação será então 203.107.171.206, com máscara 255.255.255.240.
Se tivesse escolhido o endereço 10 para a rede e o endereço 8 para a estação, teríamos “10101000” que corresponde ao decimal 168. Neste caso, o endereço IP da estação seria 203.107.171.168.
Neste primeiro exemplo dividimos a faixa de endereços em 14 redes distintas, cada uma com 14 endereços. Isso permitiria que o provedor de acesso do exemplo fornecesse links para até 14 empresas diferentes, desde que cada uma não precisasse de mais de 14 endereços. É possível criar diferentes combinações, reservando números diferentes de bits para a rede e o host:
Máscara Bits da rede Bits do host Número de redes Número de hosts
255.255.255.240 1111 0000 14 endereços
(de 1 a 14) 14 endereços
(de 1 a 14)
255.255.255.192 11 000000 2 endereços
(2 e 3) 62 endereços
(de 1 a 62)
255.255.255.224 111 00000 6 endereços
(de 1 a 6) 30 endereços
(de 1 a 30)
255.255.255.248 11111 000 30 endereços
(de 1 a 30) 6 endereços
(de 1 a 6)
255.255.255.252 111111 00 62 endereços
(de 1 a 62) 2 endereços
(de 2 e 3)
Em qualquer um dos casos, para obter o endereço IP basta converter os dois endereços (rede e estação) para binário, “juntar” os bits e converter o octeto para decimal.
Usando uma máscara de sub-rede 192, por exemplo, e estabelecendo o endereço 2 (ou “10” em binário) para a rede e 47 (ou “101111” em binário) para o host, juntaríamos ambos os binários obtendo o octeto “10101111” que corresponde ao decimal “175”.
Se usássemos a máscara de sub-rede 248, estabelecendo o endereço 17 (binário “10001”) para a rede e o endereço 5 (binário “101”) para o host, obteríamos o octeto “10001101” que corresponde ao decimal “141”.
Claro que as instruções acima valem apenas para quando você quiser conectar vários micros à web, usando uma faixa de endereços válidos, como no caso de uma empresa que precisa colocar no ar vários servidores, ou de uma empresa de hospedagem que aluga servidores dedicados. Caso você queira apenas compartilhar a conexão entre vários PCs, você precisará de apenas um endereço IP válido.

ortas TCP e UDP

Ao conectar na internet, seu micro recebe um endereço IP válido. Mas, normalmente mantemos vários programas ou serviços abertos simultaneamente. Em um desktop é normal ter um programa de e-mail, um cliente de FTP ou SSH, o navegador, um cliente de ICQ ou MSN, dois ou três downloads via bittorrent e vários outros programas que enviam e recebem informações, enquanto um único servidor pode manter ativos servidores web, FTP, SSH, DNS, LDAP e muitos outros serviços.
Se temos apenas um endereço IP, como todos estes serviços podem funcionar ao mesmo tempo sem entrar em conflito?
Imagine que as duas partes do endereço IP (a parte referente à rede e a parte referente ao host) correspondem ao CEP da rua e ao número do prédio. Um carteiro só precisa destas duas informações para entregar uma carta. Mas, dentro do prédio moram várias pessoas. O CEP e número do prédio só vão fazer a carta chegar até a portaria. Daí em diante é preciso saber o número do apartamento. É aqui que entram as famosas portas TCP.
Existem 65.536 portas TCP, numeradas de 0 a 65535. Cada porta pode ser usada por um programa ou serviço diferente, de forma que em teoria poderíamos ter até 65536 serviços diferentes ativos simultaneamente em um mesmo servidor, com um único endereço IP válido. O endereço IP contém o CEP da rua e o número do prédio, enquanto a porta TCP determina a que sala dentro do prédio a carta se destina.

As portas TCP mais usadas são as portas de 1 a 1024, que são reservadas para serviços mais conhecidos e utilizados, como servidores web, FTP, servidores de e-mail, compartilhamento de arquivos, etc. A porta 80, por exemplo, é reservada para uso de servidores web, enquanto a porta 21 é a porta padrão para servidores FTP.
Além do endereço IP, qualquer pacote que circula na internet precisa conter também a porta TCP a que se destina. É isso que faz com que um pacote chegue até o servidor web e não ao servidor FTP instalado na mesma máquina.
Além das 65.536 portas TCP, temos o mesmo número de portas UDP, seu protocolo irmão. Embora seja um protocolo menos usado que o TCP, o UDP continua presente nas redes atuais pois oferece uma forma alternativa de envio de dados, onde ao invés da confiabilidade é privilegiada velocidade e simplicidade. Vale lembrar que, tanto o TCP, quanto o UDP, trabalham na camada 4 do modelo OSI. Ambos trabalham em conjunto com o IP, que cuida do endereçamento.
No TCP, os dados são transmitidos através de conexões. Tudo começa com o cliente enviando o pacote “SYN”, que solicita a abertura da conexão. Caso a porta esteja fechada, o servidor responde com um pacote “RST” e a conversa para por aí. Caso, por outro lado, exista algum servidor disponível na porta solicitada (um servidor apache, por exemplo), então ele responde com outro pacote “SYN”, seguido de um um pacote “ACK”, avisando que a porta está disponível e prosseguindo com a abertura da conexão.
O cliente responde então com outro pacote “ACK”, o que abre oficialmente a conexão. Começa então a transferência dos dados, que são organizados em pacotes com até 1550 bytes cada um. Para cada pacote recebido, a estação envia um pacote de confirmação e, caso algum pacote se perca, ela solicita a retransmissão. Cada pacote inclui 4 bytes adicionais com um código de CRC, que permite verificar a integridade do pacote. É através dele que o cliente sabe quais pacotes chegaram danificados.
Depois que todos os dados são transmitidos, o servidor envia um pacote “FYN” que avisa que não tem mais nada a transmitir. O cliente responde com outro pacote “FYN” e a conexão é oficialmente encerrada.
Graças a tudo isso, a confiabilidade é muito boa. Quando a conexão está ruim, é normal ocorrerem mais perdas de pacotes e retransmissões, mas as corrupções são geralmente causadas pelo próprio programa que está baixando o arquivo e não pelo protocolo. O problema é que toda esta formalidade torna as transferências um pouco mais lentas. Imagine que, para transmitir uma mensagem de texto com 300 bytes, via TCP, seria necessário transmitir um total de 9 pacotes!
Veja um exemplo de como a transmissão funcionaria:
Estação: SYN (solicita a abertura da conexão)
Servidor: SYN (confirma o recebimento e avisa que a porta está disponível)
Servidor: ACK (inicia a conexão)
Estação: ACK (confirma)
Estação: DATA (é enviado o pacote com a mensagem de texto)
Servidor: OK (a confirmação, depois de verificar a integridade do pacote)
Estação: FYN (solicita o fechamento da conexão)
Servidor: FYN (confirma)
Estação: FYN (confirma que recebeu a confirmação)
No UDP, as coisas são mais simples. Nele não existe abertura de conexão, os pacotes são transmitidos diretamente. A estação solicita alguma informação e o servidor envia a resposta. Assim como no TCP, são usados pacotes de até 1550 bytes, contendo os bits adicionais de verificação. A estação pode verificar a integridade dos pacotes, mas não tem como perceber se algum pacote se perdeu, ou solicitar a retransmissão de um pacote corrompido. Se um pacote se perde, fica por isso mesmo.
Um exemplo típico do uso do UDP é o streaming de vídeo e audio via web, uma situação onde o que vale é a velocidade e não a confiabilidade. Você não gostaria nada se o navegador parasse a exibição do vídeo para solicitar uma retransmissão cada vez que um pacote se perdesse ou chegasse corrompido. É preferível que ele pule o quadro e continue exibindo o restante do vídeo.
Outra aplicação comum são os servidores DNS. Sempre que você acessa um site, a solicitação do endereço IP referente ao domínio do site e a resposta do servidor são enviadas via UDP, para ganhar tempo.
Na prática, é bem raro encontrar algum programa que utilize unicamente pacotes UDP para qualquer coisa além do envio de mensagens curtas. Mesmo no caso do streaming de vídeo, é quase sempre usada uma porta TCP para estabelecer a conexão e enviar informações de controle, deixando o UDP apenas para o envio dos dados.
As portas TCP mais usadas são:
21: FTP – O FTP é um dos protocolos de transferência de arquivos mais antigos e ainda assim um dos mais usados. O ponto fraco do FTP é a questão da segurança: todas as informações, incluindo as senhas trafegam em texto puro e podem ser capturadas por qualquer um que tenha acesso à transmissão.
O FTP possui dois modos de operação: passivo e ativo. No modo ativo, o cliente contata o servidor usando uma porta vaga aleatória, como, por exemplo, a porta 1026, endereçando o pacote à porta 21 do servidor. O servidor imediatamente contata o cliente de volta, usando a porta seguinte (do cliente) para enviar os dados. Se o cliente usou a porta 1026 para abrir a conexão, então o servidor enviará os dados na porta 1027. O problema é que o modo ativo não funciona quando o cliente acessa através de uma conexão compartilhada. Ao tentar responder, o servidor cairia na porta 1027 do gateway da rede, sem conseguir chegar ao cliente.
No modo passivo, o cliente também abre a conexão contatando a porta 21 do servidor; entretanto, ao invés de iniciar a conexão imediatamente, o servidor responde avisando que o cliente pode contatá-lo numa segunda porta, escolhida aleatoriamente (a 2026, por exemplo). O cliente inicia, então, uma nova conexão na porta especificada e o servidor responde enviando os dados. Esta porta fica reservada ao cliente durante o tempo que durar a transferência. Em teoria, isto seria um limite ao número de clientes que poderiam se conectar simultaneamente, mas, na prática, seriam necessárias mais de 64.000 conexões simultâneas ao mesmo servidor FTP para esgotar as portas disponíveis.
Praticamente todos os clientes de FTP atuais utilizam o modo passivo por padrão, mas isso pode ser modificado dentro da configuração. Alguns poucos servidores de FTP não podem ser acessados em modo passivo, pois para isso é necessário que o administrador faça uma configuração de firewall mais cuidadosa, mantendo abertas um conjunto de portas altas.

Em resumo, no modo ativo o servidor precisa ter aberta apenas a porta 21, mas em compensação o cliente precisa acessar a web diretamente e ter um conjunto de portas altas abertas no firewall. No modo passivo, os papéis se invertem: o cliente não precisa ter portas abertas, mas o servidor sim.
22: SSH – O SSH é o canivete suíço da administração remota em servidores Linux. Inicialmente o SSH permitia executar apenas comandos de texto remotamente; depois passou a permitir executar também aplicativos gráficos e, em seguida, ganhou também um módulo para transferência de arquivos, o SFTP. A vantagem do SSH sobre o Telnet e o FTP é que tudo é feito através de um canal encriptado, com uma excelente segurança.
O SSH pode ser usado também para encapsular outros protocolos, criando um túnel seguro para a passagem dos dados. Criando túneis, é possível acessar servidores de FTP, proxy, e-mail, rsync, etc. de forma segura. Graças a isso, o SSH é usado como meio de transporte por diversos programas, como o FreeNX. Veremos tudo isso em detalhes no capítulo sobre acesso remoto.
O sistema de encriptação utilizado pelo SSH, assim como os túneis encriptados trabalham no nível 6 do modelo OSI, acima da camada de sessão, do protocolo TCP/IP e de toda a parte física da rede. Ao contrário do FTP, o SSH não precisa de portas adicionais: tudo é feito através da porta 22, que é a única que precisa ficar aberta no firewall do servidor. O cliente não precisa ter porta alguma aberta e pode acessar através de uma conexão compartilhada.
23: Telnet – O Telnet é provavelmente o protocolo de acesso remoto mais antigo. A primeira demonstração foi feita em 1969, com o acesso de um servidor Unix remoto, ainda através da antiga Arpanet, muito antes de ser inventado o padrão Ethernet e, antes mesmo da primeira versão do TCP/IP. O Telnet foi muito usado durante a década de 80 e 90, mas depois caiu em desuso, sendo rapidamente substituído pelo SSH. Além de não possuir nenhum dos recursos mais sofisticados suportados pelo SSH, o Telnet é um protocolo completamente aberto (no sentido pejorativo), que transmite login, senha e todos os comandos em texto puro. Isso torna ridiculamente simples capturar a transmissão (usando, por exemplo, o Ethereal, que veremos no capítulo 4) e assim “invadir” o servidor, usando a senha roubada.
Uma curiosidade, é que o sistema usado pelo Telnet para a transmissão de comandos é usado como base para diversos outros protocolos, como o SMTP e o HTTP. De fato, você pode usar um cliente Telnet para mandar um e-mail (como veremos no capítulo 10), ou mesmo acessar um servidor web, desde que consiga simular uma conexão HTTP válida, como faria um navegador.
25: SMTP – O SMTP é o protocolo padrão para o envio de e-mails. Ele é usado tanto para o envio da mensagem original, do seu micro até o servidor SMTP do provedor, quanto para transferir a mensagem para outros servidores, até que ela chegue ao servidor destino. Tradicionalmente, o Sendmail é o servidor de e-mails mais usado, mas, devido aos problemas de segurança, ele vem perdendo espaço para o Qmail e o Postfix, que abordo no capítulo 10.
53 (UDP): DNS – Os servidores DNS são contatados pelos clientes através da porta 53, UDP. Eles são responsáveis por converter nomes de domínios como “guiadohardware.net” nos endereços IP reais dos servidores.
Existem no mundo 13 servidores DNS principais, chamados “root servers”. Cada um deles armazena uma cópia completa de toda a base de endereços. Estes servidores estão instalados em países diferentes e ligados a links independentes. A maior parte deles roda o Bind, mas pelo menos um deles roda um servidor diferente, de forma que, mesmo no caso de um gigantesco cyberataque, pelo menos um dos servidores continue no ar, mantendo a internet operacional.
Para acessar qualquer endereço, é preciso primeiro consultar um servidor DNS e obter o endereço IP real do servidor. Em geral, uma consulta a um dos root servers demora alguns segundos, por isso os provedores de acesso e responsáveis por grandes redes sempre configuram servidores DNS locais, que criam um cache das consultas anteriores, de forma a agilizar o acesso. Você mesmo pode configurar um servidor DNS para a sua rede usando o Bind, que aprenderemos a configurar mais adiante.
67: Bootps, 68: Bootpc – Estes dois protocolos são usados em sistemas de boot remoto (como no LTSP, que aprenderemos a configurar mais adiante), onde os clientes não possuem HD nem CD-ROM e acessam todos os arquivos de que precisam a partir do servidor.
69 (UDP): TFTP – O TFTP é uma versão simplificada do FTP, que utiliza portas UDP para a transferência dos dados e não inclui suporte à correção de erros. Ele pode ser usado para transferência de arquivos em geral, mas é mais freqüentemente usado em sistemas de boot remoto.
80: HTTP – O HTTP é o principal protocolo da internet, por onde acessamos as páginas. Embora a porta 80 seja a porta padrão dos servidores web, é possível configurar um servidor web para usar qualquer outra porta TCP. Neste caso, você precisa especificar a porta ao acessar o site, como em: http://200.234.34.12:8080.
110: POP3 – Servidores de e-mail, como o Postfix, armazenam os e-mails recebidos numa pasta local. Se você tiver acesso ao servidor via SSH, pode ler estes e-mails localmente, usando Mutt. Entretanto, para transferir os e-mails par a sua máquina, é necessário um servidor adicional. É aí que entra o protocolo POP3, representado pelo courier-pop e outros servidores.
Programas como o Thunderbird e o Outlook contatam o servidor POP3 através da porta 110 e baixam as mensagens utilizando um conjunto de comandos de texto, derivados do Telnet. Originalmente, o POP3 é um protocolo tão inseguro quanto o Telnet, mas os servidores atuais suportam encriptação via SSL (o mesmo sistema de encriptação usado para acessar páginas seguras, via HTTPs), o que garante um bom nível de segurança.
137, 138 e 139: Netbios – Estas três portas são usadas pelo protocolo de compartilhamento de arquivos em redes Microsoft. Cada uma das portas tem uma função específica (nome, datagrama e sessão), mas é necessário que as três estejam abertas no firewall para que a visualização dos compartilhamentos e acesso aos arquivos funcione corretamente.
143: IMAP – O IMAP é mais um protocolo para recebimento de e-mails, assim como o POP3. A diferença entre os dois é que, ao receber os e-mails via POP3, eles são apagados do servidor assim que baixados, liberando o espaço usado na caixa postal. No IMAP, os e-mails continuam no servidor até serem deletados manualmente.
Embora oferecer contas de e-mail com acesso via IMAP seja muito mais oneroso do que via POP3 (já que o número de requisições é maior, e os usuários podem conservar mensagens antigas por muito tempo), ele vem “roubando a cena” com a popularização dos webmails, que são justamente clientes IMAP, que rodam no próprio servidor (através do Apache ou outro servidor web), e são acessados no cliente usando o navegador. No capítulo 10 veremos um exemplo de instalação, com o Squirrelmail.
177: XDMCP – O XDMCP é um protocolo de acesso remoto, suportado nativamente pelo X. Ele permite rodar aplicativos remotamente e é a base para o LTSP e outros sistemas onde é usado um servidor central e terminais leves. Pode ser também usado no dia-a-dia, para simplesmente rodar programas instalados em outra máquina da rede.
A vantagem do XDMCP é que ele é um protocolo bastante simples e rápido, que oferece um bom desempenho via rede local e consome poucos recursos, tanto no servidor, quanto no cliente. Ele é também um recurso nativo do X, de forma que você não precisa instalar nenhum software adicional, basta ativar o recurso na configuração do KDM ou GDM (os gerenciadores de login usados nas distribuições atuais).
A desvantagem é que o XDMCP é um protocolo “da velha guarda”, que não utiliza encriptação, e utiliza um conjunto de portas altas para enviar dados aos clientes. Além da porta 177, onde o servidor recebe conexões, é necessário que estejam abertas as portas de 6010 à 6099 (no servidor) e as portas de 5000 a 5200 nos clientes, o que complica um pouco as coisas ao manter um firewall ativo.
389: LDAP – O LDAP é muito usado atualmente para criar servidores de autenticação e definir permissões de acesso para os diferentes usuários da rede. Existem vários padrões de LDAP, um dos mais usados é o OpenLDAP, suportado pela maioria das distribuições Linux atualmente em uso.
443: HTTPS – O HTTPS permite transmitir dados de forma segura, encriptados em SSL. Ele é usado por bancos e todo tipo de site de comércio eletrônico ou que armazene informações confidenciais. No capítulo 7 aprenderemos a configurar um servidor Apache com suporte a SSL.

Naturalmente, esta é uma lista rápida, contendo apenas as portas mais usadas. Você pode ver uma lista longa e completa, com todos os serviços conhecidos e as portas utilizadas por cada um no: http://www.iana.org/assignments/port-numbers.

ortas TCP e UDP

Ao conectar na internet, seu micro recebe um endereço IP válido. Mas, normalmente mantemos vários programas ou serviços abertos simultaneamente. Em um desktop é normal ter um programa de e-mail, um cliente de FTP ou SSH, o navegador, um cliente de ICQ ou MSN, dois ou três downloads via bittorrent e vários outros programas que enviam e recebem informações, enquanto um único servidor pode manter ativos servidores web, FTP, SSH, DNS, LDAP e muitos outros serviços.
Se temos apenas um endereço IP, como todos estes serviços podem funcionar ao mesmo tempo sem entrar em conflito?
Imagine que as duas partes do endereço IP (a parte referente à rede e a parte referente ao host) correspondem ao CEP da rua e ao número do prédio. Um carteiro só precisa destas duas informações para entregar uma carta. Mas, dentro do prédio moram várias pessoas.
ICMP

Além do TCP e do UDP, temos o ICMP (Internet Control Message Protocol), um protocolo de controle, que opera no nível 3 do modelo OSI (junto com o protocolo IP). Ao contrário do TCP e UDP, o ICMP não é usado para a transmissão de dados, mas nem por isso deixa de desempenhar diversas funções importantes. A mais trivial delas é o ping, que usamos para verificar se uma determinada máquina está online, como em:
$ ping -c 3 guiadohardware.net
PING guiadohardware.net (64.246.6.25) 56(84) bytes of data.
64 bytes from gdhs.guiadohardware.net (64.246.6.25): icmp_seq=1 ttl=53 time=8.72 ms
64 bytes from gdhs.guiadohardware.net (64.246.6.25): icmp_seq=2 ttl=53 time=8.62 ms
64 bytes from gdhs.guiadohardware.net (64.246.6.25): icmp_seq=3 ttl=53 time=8.37 ms
— guiadohardware.net ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 8.373/8.576/8.728/0.183 ms
O “-c” indica o número de repetições, neste caso 3. Sem ele, o ping fica enviando pacotes indefinidamente (no Linux), até que você aborte o programa pressionando Ctrl+C. Assim como outros comandos básicos, o ping também está disponível no Windows, através do prompt do MS-DOS.
Normalmente, os pings para qualquer servidor na Internet (com exceção dos servidores do seu provedor de acesso, ou outros servidores muito próximos), voltam com pelo menos 100 milessegundos de atraso. Quanto mais distante geograficamente estiver o servidor, ou quanto mais saturado estiverem os roteadores e links até ele, maior será o tempo de resposta. Um ping muito alto faz com que o carregamento de páginas seja mais demorado (pois o ping determina o tempo necessário para cada requisição do navegador chegar até o servidor) e atrapalha principalmente quem joga online, ou usa programas de administração remota, como o SSH.
No meu caso, consegui pings de apenas 8 ms até o servidor do Guia do Hardware, pois “trapaceei”, acessando via SSH um outro servidor ligado ao mesmo backbone que ele e rodando o ping a partir dele :).
A resposta a pings pode ser desativada na configuração do sistema. No Linux, você pode usar o comando abaixo:
# echo “1” > /proc/sys/net/ipv4/icmp_echo_ignore_all
É possível também desativar a resposta a pings na configuração do firewall, de forma que, o fato de um micro da internet, ou mesmo dentro da sua rede local não responder a pings não significa muita coisa. Se ele responder, significa que está online; se não responder, significa que pode estar online também, porém configurado para não responder aos seus chamados :P.
Outra função importante do ICMP é o controle do TTL (time to live) de cada pacote TCP ou UDP. Os pacotes tem vida curta e sua única função é carregar os dados até o destino. Eles são transmitidos de um roteador a outro e, uma vez que chegam ao destino, são desmontados e destruídos. Mas, o que acontece em casos onde não existe uma rota possível até o destino, seja por que a máquina está desligada, por erro no endereçamento, ou por um problema em algum dos links?
Existem duas possibilidades. A primeira é um roteador próximo perceber que a máquina está fora do ar e destruir o pacote. Neste caso, ele responde ao emissor com um pacote ICMP “Destination Unreachable”, avisando do ocorrido. Caso isso não aconteça, o pacote fica circulando pela rede, passando de um roteador a outro, sem que consiga chegar ao destino final.
O TTL existe para evitar que estes pacotes fiquem em loop eterno, sendo retransmitidos indefinidamente e assim consumindo banda de forma desnecessária. Graças a ele, os pacotes têm “vida útil”.
O pacote é criado com um TTL de 64 hops (o default nas versões atuais do Linux). Cada vez que o pacote passa por um roteador, o número é reduzido em um. Se o número chegar a zero, o roteador destrói o pacote e avisa o emissor enviando um pacote ICMP “Time Exceeded”.
No Linux, o TTL padrão é configurável através do arquivo “/proc/sys/net/ipv4/ip_default_ttl”. Você pode brincar com isso alterando o valor padrão por um número mais baixo, como em:
# echo 8 > /proc/sys/net/ipv4/ip_default_ttl
Com um valor tão baixo, os pacotes gerados pela sua máquina terão vida curta, e não conseguirão atingir hosts muito distantes. Você vai continuar conseguindo acessar a página do seu provedor, por exemplo, mas não conseguirá acessar servidores geograficamente distantes. Para retornar o valor padrão, use o comando:
# echo 64 > /proc/sys/net/ipv4/ip_default_ttl
Os pacotes ICMP “Time Exceeded” são usados pelo comando “traceroute” (no Linux) para criar um mapa dos caminho percorrido pelos pacotes até chegarem a um determinado endereço. Ele começa enviando um pacote com um TTL de apenas 1 hop, o que faz com que ele seja descartado logo pelo primeiro roteador. Ao receber a mensagem de erro, o traceroute envia um segundo pacote, desta vez com TTL de 2 hops, que é descartado no roteador seguinte. Ele continua, enviando vários pacotes, aumentando o TTL em 1 hop a cada tentativa. Isso permite mapear cada roteador por onde o pacote passa até chegar ao destino, como em:
$ traceroute kurumin.com.br
1 10.62.0.1 (10.62.0.1) 7.812 ms 6.262 ms 9.966 ms
2 poaguswh01.poa.virtua.com.br (200.213.50.90) 9.738 ms 8.206 ms 7.761 ms
3 poagu-ebt-01.poa.virtua.com.br (200.213.50.31) 7.893 ms 7.318 ms 8.033 ms
4 embratel-F3-7-gacc07.rjo.embratel.net.br (200.248.95.253) 8.590 ms 8.315 ms 7.960 ms
5 embratel-G2-3-gacc01.pae.embratel.net.br (200.248.175.1) 7.788 ms 8.602 ms 7.934 ms
6 ebt-G1-0-dist04.pae.embratel.net.br (200.230.221.8) 31.656 ms 31.444 ms 31.783 ms
7 ebt-P12-2-core01.spo.embratel.net.br (200.244.40.162) 32.034 ms 30.805 ms 32.053 ms
8 ebt-P6-0-intl03.spo.embratel.net.br (200.230.0.13) 32.061 ms 32.436 ms 34.022 ms
9 ebt-SO-2-0-1-intl02.mia6.embratel.net.br (200.230.3.10) 298.051 ms 151.195 ms 306.732 ms 10 peer-SO-2-1-0-intl02.mia6.embratel.net.br (200.167.0.22) 269.818 ms peer-SO-1-1-0-intl02.mia6.embratel.net.br (200.167.0.18) 144.997 ms *
11 0.so-1-0-0.XL1.MIA4.ALTER.NET (152.63.7.190) 240.564 ms 147.723 ms 150.322 ms
12 0.so-1-3-0.XL1.ATL5.ALTER.NET (152.63.86.190) 438.603 ms 162.790 ms 172.188 ms
13 POS6-0.BR2.ATL5.ALTER.NET (152.63.82.197) 164.539 ms 337.959 ms 162.612 ms
14 204.255.168.106 (204.255.168.106) 337.589 ms 337.358 ms 164.038 ms
15 dcr2-so-2-0-0.dallas.savvis.net (204.70.192.70) 212.376 ms 366.212 ms 211.948 ms
16 dcr1-so-6-0-0.dallas.savvis.net (204.70.192.49) 396.090 ms bhr2-pos-4-0.fortworthda1.savvis.net (208.172.131.86) 189.068 ms dcr1-so-6-0-0.dallas.savvis.net (204.70.192.49) 186.161 ms
17 216.39.64.26 (216.39.64.26) 185.749 ms 191.218 ms bhr1-pos-12-0.fortworthda1.savvis.net (208.172.131.82) 361.970 ms
18 216.39.81.34 (216.39.81.34) 186.453 ms 216.39.64.3 (216.39.64.3) 245.389 ms 216.39.81.34 (216.39.81.34) 184.444 ms
19 216.39.81.34 (216.39.81.34) 182.473 ms * 182.424 ms
20 * kurumin.com.br (72.232.35.167) 185.689 ms *
Neste exemplo, o pacote começa passando pelos links da Net (Virtua), passa em seguida por vários roteadores da Embratel, passando por São Paulo e Miami (já nos EUA), para então passar por roteadores da Alter.net e Savvis, até chegar ao destino final.
O Windows inclui o comando “tracert”, que atua de forma similar, porém enviando um ping para cada host. O resultado acaba sendo similar, com exceção de casos em que o servidor é configurado para não responder a pings. Existem ainda vários exemplos de programas gráficos, como o Neotrace (para Windows), que você encontra em qualquer site de downloads e o Xtraceroute (para Linux).
Eles exibem as mesmas informações, porém de uma forma bem mais agradável. Este é um exemplo do Neotrace mostrando uma conexão especialmente ruim com um servidor hospedado no exterior, a partir de um link ADSL da Brasil Telecom. Veja que o problema começa num roteador congestionado, da própria operadora (com tempo de resposta de mais de 1200 ms!) e continua numa seqüência de links lentos da wcg.net:

Na internet, os roteadores são espertos o suficiente para conhecerem os roteadores vizinhos e escolher a melhor rota para cada destino. Sempre que um roteador fica congestionado, os demais passam a evitá-lo, escolhendo rotas alternativas. Esta comunicação é feita através de pacotes ICMP “Redirect”, que avisam o emissor que uma rota mais rápida está disponível e os pacotes seguintes devem ser encaminhados através dela.
Durante as transferências de dados, os pacotes ICMP são usados também para regular a velocidade da transmissão, fazendo com que o servidor envie pacotes na maior velocidade possível permitida pelo link, sem entretanto sobrecarregar o link do cliente. Sempre que um dos roteadores pelo caminho, percebe que o link está saturado, envia um pacote ICMP “Source Quench”, que faz o servidor reduzir a velocidade da transmissão. Sem isso, os pacotes excedentes seriam descartados, causando um grande desperdício de banda.

ARP

Dentro da rede local, os pacotes são transformados em frames, onde são endereçados ao endereço MAC da placa de rede destino e não ao endereço IP. Acontece que, inicialmente, o sistema não sabe quais são os endereços MAC das placas dos outros micros da rede local, sabe apenas os endereços IP que deve acessar.
O ARP (Address Resolution Protocol) faz compania ao IP e ao ICMP na camada 3 do modelo OSI, oferecendo justamente uma forma simples de descobrir o endereço MAC de um determinado host, a partir do seu endereço IP. A estação manda um pacote de broadcast (chamado “ARP Request”), contendo o endereço IP do host destino e ele responde com seu endereço MAC. Como os pacotes de broadcast são custosos em termos de banda da rede, cada estação mantém um cache com os endereços conhecidos.
Naturalmente, isso é feito de forma transparente. É mais um detalhe técnico com o qual você não precisa se preocupar se quer apenas usar a rede, mas que é interessante estudar quando está interessado em entender seu funcionamento. Você pode verificar o cache de endereços ARP do seu micro (no Linux) usando o comando “arp”:
$ arp
Address HWtype HWaddress Flags Mask Iface
192.168.1.254 ether 00:30:CD:03:CD:D2 C eth0
192.168.1.23 ether 00:11:D8:56:62:76 C eth0
192.168.1.56 ether 00:11:D8:57:45:C3 C eth0
Existe também o “RARP” (reverse ARP), que tem a função oposta: contatar um host da rede quando o endereço MAC é conhecido, mas o endereço IP não. Embora menos usado, o RARP também é importante, pois ele é usado quando uma estação precisa obter sua configuração de rede via DHCP.
Ao receber o pacote de broadcast enviado pela estação, o servidor DHCP sabe apenas o endereço MAC da estação e não seu endereço IP (que afinal ainda não foi definido). Ele é capaz de responder à solicitação graças ao RARP. Sem ele, não teríamos DHCP :).
Muitas distribuições Linux incluem o “arping”, um pequeno utilitário que utiliza o ARP ao invés do ping para descobrir se outras máquinas da rede local estão online. A vantagem é que mesmo máquinas protegidas por firewall, ou configuradas para não responder pings respondem a pacotes ARP, fazendo com que ele seja mais uma ferramenta interessante na hora de diagnosticar problemas na rede.
Nas distribuições derivadas do Debian, você pode instalá-lo via apt-get (apt-get install arping). Para usar, basta informar o endereço IP ou endereço MAC da máquina alvo, como em:
$ arping 192.168.1.110
ARPING 192.168.1.110
60 bytes from 00:11:d8:21:52:76 (192.168.1.110): index=0 time=112.057 usec
60 bytes from 00:11:d8:21:52:76 (192.168.1.110): index=1 time=101.089 usec
60 bytes from 00:11:d8:21:52:76 (192.168.1.110): index=2 time=99.897 usec
Uma observação importante é que o ARP é usado apenas dentro da rede local, o único local onde são usados endereços MAC. Quando o pacote passa pelo gateway e é encaminhado para a internet, os campos com os endereços MAC são removidos, o que faz com que o arping e outros utilitários baseados em pacotes ARP deixem de funcionar.
Se você tiver a curiosidade de disparar o arping contra um host da internet, vai perceber que, embora o comando seja executado sem erros, ele fica parado indefinidamente aguardando por uma resposta que nunca vem:
$ arping google.com
ARPING 64.233.167.99
(espera infinita…)
Isso acontece pois o pacote de broadcast enviado pelo arping não é encaminhado pelo gateway da rede, ele só seria respondido se, por acaso, existisse um micro dentro da rede local utilizando o endereço “64.233.167.99”. Mesmo que o pacote fosse incorretamente encaminhado para a internet, ele não iria muito longe, pois seria descartado no primeiro roteador por onde passasse.
Outros protocolos de rede

O TCP/IP tornou-se um protocolo onipresente. Ele é usado desde servidores de grande porte até palmtops e celulares, permitindo que dispositivos de plataformas completamente diferentes possam conversar entre si.
Mas, antes do TCP/IP, os protocolos mais usados eram o NetBEUI e o IPX/SPX. Eles ainda são utilizados em algumas redes, por isso é importante saber um pouco sobre eles:

NetBEUI: O NetBEUI é uma espécie de “vovô protocolo”, pois foi lançado pela IBM no início da década de 80 para ser usado junto com o IBM PC Network, um micro com configuração semelhante à do PC XT, mas que podia ser ligado em rede. Naquela época, o protocolo possuía bem menos recursos e era chamado de NetBIOS. O nome NetBEUI passou a ser usado quando a IBM estendeu os recursos do NetBIOS, formando a versão final do protocolo.
No jargão técnico atual, usamos o termo “NetBEUI” quando nos referimos ao protocolo de rede em si e o termo “NetBIOS” quando queremos nos referir aos comandos deste mesmo protocolo usado pelos programas para acessar a rede.
Ao contrário do IPX/SPX e do TPC/IP, o NetBEUI foi concebido para ser usado apenas em pequenas redes e por isso sempre foi um protocolo extremamente simples. Por um lado, isto fez que ele se tornasse bastante rápido e fosse considerado o mais rápido protocolo de rede durante muito tempo. Para você ter uma idéia, apenas as versões mais recentes do IPX/SPX e TCP/IP conseguiram superar o NetBEUI em velocidade.
Mas, esta simplicidade toda tem um custo: devido ao método simples de endereçamento usado pelo NetBEUI, podemos usá-lo em redes de no máximo 255 micros. Além disso, o NetBEUI não suporta enumeração de redes (para ele todos os micros estão ligados na mesma rede). Isto significa que, se você tiver uma grande Intranet, composta por várias redes interligadas por roteadores, os micros que usarem o NetBEUI simplesmente não serão capazes de enxergar micros conectados às outras redes, enxergarão apenas os micros a que estiverem conectados diretamente. Devido a esta limitação, dizemos que o NetBEUI é um protocolo “não-roteável”.
Apesar de suas limitações, o NetBEUI ainda é usado em algumas redes Windows, por ser rápido, fácil de instalar e usar. Você não pode usá-lo para acessar a internet, acessar outras máquinas da rede via SSH nem nenhum outro dos serviços que vimos até aqui, mas ele permite que as máquinas Windows compartilhem arquivos entre si.
De qualquer forma, para instalá-lo, no Windows XP, acesse o menu de configuração da rede e acesse a opção Adicionar > Protocolo > NWLink/IPX/SPX/NetBIOS Protocolo de transporte compatível.

Embora não seja recomendável utilizá-lo nos dias de hoje, não existe problema em mantê-lo ativo junto com o TCP/IP. No NetBEUI também não existe configuração de endereços, pois os micros conversam diretamente usando os endereços MAC.
Ao instalar uma estação de trabalho com o XP numa rede antiga, baseada em micros com o Windows 95/98, pode ser necessário ativar o NetBEUI para que ele consiga conversar com as outras máquinas, já que antigamente, antes da popularização do acesso à internet, era comum configurar redes locais usando apenas o NetBEUI, sem TCP/IP.

IPX/SPX: Este protocolo foi desenvolvido pela Novell, para ser usado em seu Novell Netware. Como o Netware acabou tornando-se muito popular, outros sistemas operacionais de rede (incluindo o Windows), passaram a suportar este protocolo. O IPX/SPX é tão rápido quanto o TPC/IP (apesar de não ser tão versátil) e suporta roteamento, o que permite seu uso em redes de médio ou grande porte.
As versões recentes do Novell Netware oferecem a opção de usar o IPX/SPX ou o TCP/IP, sendo o uso do TCP/IP mais comum, já que é mais fácil interligar máquinas de várias plataformas à rede.
No Netware, além do módulo principal (instalado no servidor), é fornecido um módulo cliente, que deve ser instalado em todas as estações de trabalho. Além da versão principal do Netware, existe a versão Personal, um sistema de rede ponto a ponto, que novamente roda sobre o sistema operacional. Esta versão do Netware é bem fácil de usar, porém nunca foi muito popular, pois o Windows sozinho já permite a criação de redes ponto a ponto muito facilmente, desde o 3.11.
Atualmente é muito comum utilizar servidores Linux, rodando o Samba, substituindo servidores Windows NT, 2000 ou 2003 Server. No início de 2003, a Novell comprou a SuSE, uma das maiores distribuições Linux na Europa e, em seguida, a Ximian, que entre outras coisas desenvolve soluções de interoperabilidade entre servidores Linux e Windows. Isso mostra que as futuras soluções da Novell devem ser baseadas em Linux.
Mas, voltando ao assunto principal, é possível usar estações Windows e Linux como clientes de um servidor Novell. No caso do Windows, é necessário ter instalado o protocolo IPX/SPX e também um cliente para redes Netware. No Windows XP, a compatibilidade com o IPX é fornecida pelo protocolo ” NWLink/IPX/SPX/NetBIOS”, o mesmo que instalamos para ativar o suporte ao NetBEUI.
Para instalar o protocolo IPX/SPX no Windows 95/98, abra o ícone de configuração da rede e use a opção “Adicionar > Protocolo > Microsoft > Protocolo compatível com IPX/SPX”. Para instalar o cliente para redes Novell no Windows 98, clique em “Adicionar > Cliente > Microsoft > Cliente para redes NetWare”.
Apesar do cliente fornecido com o Windows 98 não ficar devendo muito em termos de recursos, é preferível usar o cliente da própria Novell, que traz alguns recursos únicos, além de ser mais rápido. O programa cliente da Novell acompanha o módulo servidor, mas você também pode baixá-lo gratuitamente (12 MB) do site da Novell: http://www.novell.com.br.
Após baixar o arquivo, execute-o para que ele se descompacte automaticamente e, em seguida, execute o arquivo “setup.exe” para instalar o cliente. O programa de instalação adicionará o “Cliente NetWare da Novell” e o “Protocolo IPX de 32 Bits para o NetWare Client da Novell”, que aparecerão na janela de configuração da rede.
O cliente ficará residente na forma de um ícone ao lado do relógio, já que você depende do programa para ter acesso ao servidor. Como no caso dos servidores NT, você deverá criar uma conta de usuário no servidor Novell e logar-se na rede informando o nome de usuário e senha estabelecidos.

Ao usar clientes Linux, você pode utilizar o NovelClient (com um L só), que pode ser baixado no:
http://novelclient.sourceforge.net/.

Capítulo 4: Segurança

A questão da segurança tem se tornado cada vez mais importante à medida que a internet torna-se um ambiente cada vez mais hostil e as ferramentas para capturar tráfego, quebrar sistemas de encriptação, capturar senhas e explorar vulnerabilidades diversas tornam-se cada vez mais sofisticadas.
Outra questão importante é que usamos cada vez mais tecnologias diferentes de acesso e transmissão de dados, o que torna manter sua rede segura uma tarefa mais complicada. Por exemplo, sua rede pode ser bastante segura contra invasões “diretas”, via internet, graças ao firewall ativado no gateway da rede, mas, ao mesmo tempo, ser muito fácil de invadir através da rede wireless sem encriptação que você utiliza.
Ao usar clientes Windows, existe ainda o problema dos vírus, trojans e worms. Os vírus se espalham através de arquivos infectados, páginas que exploram vulnerabilidades no navegador, e-mails e assim por diante, geralmente utilizando alguma técnica de engenharia social que leve o usuário a clicar em um link ou executar um arquivo.
Assim como na vida real, os vírus variam muito em termos de potencial nocivo. Existem desde vírus extremamente perigosos, que destroem os dados do HD, subscrevendo os arquivos com dados aleatórios (de forma que seja impossível recuperá-los) e, algumas vezes até mesmo danificando o BIOS da placa mãe; até vírus relativamente inofensivos, que não fazem muita coisa além de se replicarem por diversos meios, tentando infectar o maior número de PCs possíveis.
Os trojans são muito similares aos vírus, mas o objetivo principal é abrir portas e oferecer alguma forma de acesso remoto à máquina infectada. Ao invés de deletar arquivos ou mostrar pop-ups (como os vírus), os trojans são quase sempre muito discretos, de forma que o usuário não perceba que sua máquina está infectada. Isso permite que o invasor roube senhas, use a conexão para enviar spam, procure por informações valiosas nos arquivos do HD, ou mesmo use as máquinas sob seu controle para lançar ataques diversos contra outras máquinas.
Os worms se diferenciam dos vírus e trojans pela forma como infectam as máquinas. Ao invés de depender do usuário para executar o arquivo infectado, os worms se replicam diretamente, explorando vulnerabilidades de segurança nas máquinas da rede. Os mais complexos são capazes de explorar diversas brechas diferentes, de acordo com a situação. Um worm poderia começar invadindo um servidor web com uma versão vulnerável do IIS, infectar outras máquinas da rede local a partir dele, acessando compartilhamentos de rede com permissão de escrita e, a partir delas, se replicar via e-mail, enviando mensagens infectadas para e-mails encontrados no catálogo de endereços; tudo isso sem intervenção humana.
Os worms podem ser bloqueados por um firewall bem configurado, que bloqueie as portas de entrada (e, se possível, também portas de saída) usadas por ele. É possível também bloquear parte dos vírus e trojans adicionando restrições com base em extensão de arquivos no Squid, ou adicionando o Clamav no servidor de e-mails (como veremos ao longo do livro), mas, a principal linha de defesa acaba sempre sendo o antivírus ativo em cada máquina Windows.
No Linux, as coisas são um pouco mais tranqüilas neste ponto. Os vírus são quase que inexistentes e as vulnerabilidades em servidores muito utilizados, como o Apache, SSH, etc. são muito menos comuns. O problema é que todos estes prognósticos favoráveis dão uma falsa sensação de segurança, que acabam levando muitos usuários a assumirem um comportamento de risco, deixando vários serviços ativados, usando senhas fracas ou usando a conta de root no dia-a-dia.
Também é muito comum que os novos usuários fiquem impressionados com os recursos de conectividade disponíveis no Linux e acabem abrindo brechas de segurança ao deixar servidores XDMCP, NFS, Squid, etc. abertos para a internet. Muitos usuários do Windows sequer sabem que é possível manter um servidor FTP aberto no micro de casa, enquanto muitas distribuições Linux instalam servidores Apache ou SSH por default. Muitos usuários Linux mantém servidores diversos habilitados em suas máquinas, algo muito menos comum no mundo Windows.
No final das contas, a segurança do sistema depende muito mais do comportamento do usuário do que do sistema operacional em si. Um usuário iniciante que use o Windows XP, sem nenhum firewall ou qualquer cuidado especial, mas que tenha o cuidado de manter o sistema atualizado e não executar qualquer porcaria que chegue por mail provavelmente estará mais seguro do que um usuário Linux sem noções de segurança que use o sistema como root e mantém um batalhão de servidores desatualizados ativos na máquina.
Você poderia perguntar porque alguém teria interesse em invadir máquinas de usuários domésticos, que não possuem arquivos valiosos, ou mesmo estações de trabalho que são usadas apenas para editar textos e enviar e-mails.
A questão principal não é o que está armazenado do HD, mas sim a banda. Ter vários PCs sob seu controle, principalmente se eles possuírem conexões de alta velocidade, significa poder. É possível usá-los para alimentar redes P2P como o Kazaa e outros, fundar uma rede de distribuição de warez ou moviez, usá-los como servidores complementares para um site pornô qualquer, enviar spam, usá-los para rodar portscans e lançar ataques contra outras máquinas ou até mesmo usá-los em um ataque coordenado para tirar um grande portal do ar.

As dicas gerais

Segurança envolve mais do que simplesmente instalar um firewall ou substituir o Outlook por um leitor de e-mails mais seguro, envolve um conjunto de atitudes. A idéia básica é em primeiro lugar evitar que outras pessoas tenham acesso a dados pessoais, como senhas, versões dos servidores que você mantém abertos na sua máquina e se possível até mesmo restringir o acesso ao seu endereço de e-mail ou número de ICQ e dificultar a obtenção do endereço IP da sua máquina. A idéia é que, a partir de qualquer uma destas informações, alguém pode conseguir obter mais dados até conseguir acesso.
Nenhum programa é livre de bugs. Com o seu número de ICQ alguém poderia tentar se aproveitar de alguma brecha descoberta no protocolo ou no cliente que você utiliza. Com o seu e-mail é possível se aproveitar de uma vulnerabilidade recém-descoberta no leitor de e-mails, ou simplesmente tentar convencê-lo a abrir um arquivo anexado, que contenha um trojan.
A questão das senhas é um pouco mais delicada, pois envolve não só os logins e senhas de e-mail, mas também senhas de banco, números de cartão de crédito, etc. A forma mais comum de conseguir estes dados é através de um programa de keytrap que captura tudo que é digitado no teclado, gerando um arquivo de texto que pode ser recuperado depois ou enviado automaticamente por e-mail.
Existem várias formas de conseguir instalar um keytrap no PC de alguém: as possibilidades vão desde enviar um programa qualquer por e-mail (que, ao ser executado, instala o programa), invadir a máquina usando um trojan que dê acesso remoto e a partir daí instalar o keytrap, entre outras possibilidades.
Mesmo que o seu micro esteja limpo, ainda existe a possibilidade de que os seus dados sejam capturados ao utilizar o micro de alguém ou, principalmente, ao utilizar um Cybercafé. Evite digitar qualquer tipo de senha ou dados confidenciais em qualquer micro que não seja seu ou, se isso realmente for necessário, pelo menos tenha o cuidado de usar algum tipo de teclado virtual (como os que os sistemas de acesso online dos bancos oferecem, o teclado virtual incluído no Windows ou o Xvkbd no Linux). Outra boa solução é dar boot usando um CD do Kurumin ou outro live-cd, permitindo que você tenha um sistema “limpo”.
Os ambientes mais críticos são os Cybercafés, onde muitas pessoas utilizam os mesmos PCs. Não utilize nenhum serviço onde não exista uma boa política de segurança, baseada em logins separados para cada cliente e de preferência com estações Linux que oferecem um suporte multiusuário mais desenvolvido.
Com senhas em mãos, qualquer um poderá ler seus e-mails, acessar sua máquina remotamente caso você mantenha um servidor de FTP ou SSH ativo e, assim por diante. As senhas são o ponto fraco de qualquer sistema de segurança, por isso devem ser uma preocupação constante. Utilize sempre boas senhas, misturando letras e números e com pelo menos 8 (de preferência 12) caracteres, jamais utilize palavras como senha e troque suas senhas, sobretudo a senha de root constantemente.
O ideal é que ninguém além de você tenha acesso físico ao seu PC. Mesmo que você deixe o micro desligado, ou protegido por uma proteção de tela, é possível instalar programas dando boot através de um CD-ROM ou disquete. A partir do momento em que uma pessoa mal intencionada senta na frente do seu servidor e dá boot através de um live-CD, o servidor não é mais seu, e sim dele.
Se você administra um servidor ou permite que outros usuários acessem sua máquina remotamente, exija que todos utilizem boas senhas. Muitas brechas de segurança permitem obter acesso de root partindo de um simples login de usuário. Por isso, além de exigir o uso de boas senhas, você deve dar logins de usuário apenas à pessoas de confiança.
Outra boa idéia é “esconder” seus servidores, alterando suas portas default. Por exemplo, um servidor de FTP escutando na porta 21 (a default) seria facilmente descoberto pelo atacante, que, a partir daí, poderia tentar explorar algum tipo de vulnerabilidade no programa para obter acesso. Mas, se você configurá-lo para operar na porta 44756, por exemplo, já seria muito mais complicado que alguém o descobrisse. Seria preciso fazer uma varredura de portas completa, que demora várias horas para perceber que a porta 44756 está aberta e mais algum tempo para descobrir que ela está sendo usada por um servidor de FTP. Quanto mais dificuldade melhor, não é mesmo?
Caso você esteja usando um programa de detecção de intrusões, como o Snort, a varredura de portas iria disparar o alarme, fazendo com que você tivesse conhecimento do ataque antes mesmo do atacante descobrir quais portas estão abertas para tentar fazer qualquer coisa.
Mais um erro comum é deixar servidores de FTP, web, SSH, etc. disponíveis para toda a internet enquanto você só precisa deles dentro da sua rede interna. Se você tem duas placas de rede, ou mesmo uma placa de rede e um modem, é fácil filtrar o tráfego permitindo que apenas os acessos vindos dos clientes locais sejam aceitos. Isto pode ser feito na configuração do servidor (como no caso do Samba e do Apache) quanto na configuração do firewall (que abordo em detalhes no capítulo 11).
O ideal em termos de segurança é não acessar a web diretamente nos desktops. Sempre que possível, acesse por trás de uma conexão compartilhada, através de um servidor Linux com o firewall ativo, ou através de um modem ADSL configurado como roteador. Direcione apenas as portas realmente necessárias para os clientes.
Todas estas medidas representam a chamada segurança passiva. As brechas de segurança são como balas perdidas, ninguém pode dizer onde surgirá a próxima. Mesmo um sistema com um excelente histórico de segurança pode revelar um bug monstruoso a qualquer momento. A idéia é impedir ou pelo menos dificultar a exploração de qualquer eventual brecha.
Imagine que amanhã alguém descubra uma brecha grave no SSH, por exemplo. Se você deixa o serviço ativo no seu servidor e ainda por cima aberto ao mundo, você estaria com sérios problemas. Mas, se você mantém o serviço desativado, ou disponível apenas para a sua rede interna, a brecha não afetaria diretamente o seu sistema, pois seria preciso passar primeiro pelo firewall para ter acesso a ele.

Podemos dizer que a função de qualquer rede é simplesmente transportar informações de um ponto a outro. Pode ser entre dois micros ligados através de um simples cabo cross-over, ou pode ser entre dois servidores situados em dois continentes diferentes. Do ponto de vista do sistema operacional e dos aplicativos, não faz muita diferença.
No nível mais baixo, temos os cabos de rede, que são enquadrados no primeiro nível do modelo OSI (camada física) e se destinam unicamente a transportar os impulsos elétricos de um micro a outro. Ao utilizar uma rede wireless ou cabos de fibra óptica, os sinais são transmitidos (respectivamente) na forma de sinais de rádio ou luz, mas a função básica (transportar dados de um ponto a outro) continua a mesma, independentemente da mídia utilizada.

Existem basicamente 3 tipos diferentes de cabos de rede: os cabos de par trançado (que são, de longe, os mais comuns), os cabos de fibra óptica (usados principalmente em links de longa distância) e os cabos coaxiais, que são usados em cabos de antenas para redes wireless e em algumas redes antigas.
Entre os cabos de par trançado, existem cabos de cat 1 até cat 7. Como os cabos cat 5 são suficientes tanto para redes de 100 quanto de 1000 megabits, eles são os mais comuns e mais baratos, mas os cabos cat 6 e cat 6a estão se popularizando e devem substituí-los ao longo dos próximos anos. Os cabos são vendidos originalmente em caixas de 300 metros, ou 1000 pés (que equivale a 304.8 metros):

No caso dos cabos cat 5e, cada caixa custa em torno de 200 reais aqui no Brasil, o que dá cerca 66 centavos o metro. Os cabos de categoria 6 e 6a ainda são mais caros, mas devem cair a um patamar de preço similar ao longo dos próximos anos.
Entre os cabos de fibra óptica, existem dois tipos: os cabos de fibra multimodo ou MMF (multimode fibre) e os monomodo ou SMF (singlemode fibre). As fibras monomodo possuem um núcleo muito mais fino, de 8 a 10 mícrons de diâmetro, enquanto as multimodo utilizam núcleos mais espessos, tipicamente com 62.5 microns.
As fibras multimodo são mais baratas e o núcleo mais espesso demanda uma precisão menor nas conexões, o que torna a instalação mais simples, mas, em compensação, a atenuação do sinal luminoso é muito maior.
Isso acontece porque o pequeno diâmetro do núcleo das fibras monomodo faz com que a luz se concentre em um único feixe, que percorre todo o cabo com um número relativamente pequeno de reflexões. O núcleo mais espesso das fibras multimodo, por sua vez, favorece a divisão do sinal em vários feixes separados, que ricocheteiam dentro do cabo em pontos diferentes, aumentando brutalmente a perda durante a transmissão, como você pode ver nos desenhos a seguir:

Para efeito de comparação, as fibras multimodo permitem um alcance de até 550 metros no Gigabit Ethernet e 300 metros no 10 Gigabit, enquanto as fibras monomodo podem atingir até 80 km no padrão 10 Gigabit. Esta brutal diferença faz com que as fibras multimodo sejam utilizadas apenas em conexões de curta distância, já que sairia muito mais caro usar cabos multimodo e repetidores do que usar um único cabo monomodo de um ponto ao outro.

Em seguida temos os switches ou hub-switches que utilizamos para interligar os micros da rede local. Na verdade, o termo “hub-switch” foi inventado pelos fabricantes para diferenciar os switchs mais baratos, que carecem de funções mais avançadas dos switchs “de verdade”, que possuem mais portas e incluem interfaces de administração elaboradas.
O termo “switch” está mais relacionado ao modo de funcionamento do aparelho e não ao seu custo ou suas funções. Um switch é capaz de encaminhar os frames Ethernet para o destinatário correto, fechando “circuitos” entre as duas portas envolvidas, enquanto um hub antigo simplesmente repete os sinais recebidos em todas as portas.

Assim como as placas de rede, os switchs trabalham no nível 2 do modelo OSI (link de dados), enviando frames Ethernet e endereçando os outros dispositivos da rede usando endereços MAC ao invés de endereços IP. Só para efeito de comparação, os hubs “burros” trabalham no nível 1, assim como os cabos de rede. Eles são meros dispositivos de transmissão, que não realizam processamento.
Um switch pode operar de quatro formas. No sistema cut-through o switch inicia a retransmissão dos frames imediatamente após receber os headers (que contém os endereços de origem e de destino). Nesse modo o switch não faz nenhum tipo de verificação no frame, simplesmente o retransmite da forma como os dados foram recebidos. No modo store-and-forward o switch armazena o pacote na memória, realiza algumas verificações básicas e só então envia o pacote ao destinatário, descartando pacotes inválidos e solicitando a retransmissão de pacotes corrompidos.
A vantagem do modo cut-through é a baixa latência, já que o switch executa muito pouco processamento e vai retransmitindo os dados do pacote conforme eles são recebidos. Entretanto, além da questão da estabilidade e melhor uso da banda da rede, o modo store-and-forward oferece uma vantagem importante, que é o fato de permitir que as portas do switch trabalhem a diferentes velocidades, sem precisar reduzir a taxa de transmissão da porta mais rápida, limitando-a à da porta mais lenta.
Uma terceira tecnologia é a adaptative cut-through, disponível em modelos mais recentes. Nesse modo, o switch opera inicialmente em modo cut-through (para minimizar a latência), mas passa automaticamente a operar em modo store-and-forward caso detecte um grande volume de frames inválidos ou corrompidos, ou caso precise transmitir frames entre duas portas operando a diferentes velocidades (100 e 1000, por exemplo). No caso dos switches adaptative cut-through gerenciáveis, é possível também forçar um dos dois modos de operação.
Hoje em dia, o modo de operação do switch é mais uma opção de design do que uma diferença prática, pois em redes de 100 e 1000 megabits o tempo de latência é sempre muito baixo, independentemente do modo de operação. A maioria dos switches gigabit atuais operam com tempos de latência inferiores a 20 microsegundos (0.02 ms), o que é uma necessidade, já que um switch lento não conseguiria encaminhar 1 gigabit de dados por segundo em primeiro lugar.
O quarto modo de operação, pouco relevante hoje em dia, é o fragment-free, onde o switch aguarda o recebimento dos primeiros 64 bytes do frame, certifica-se de que não ocorreu uma colisão e só então o retransmite. Este modo foi desenvolvido para minimizar a ocorrência de colisões, mas se tornou irrelevante com a popularização do modo full-duplex, onde é negociado um canal exclusivo de transmissão entre cada estação e o switch, eliminando o problema.
Os frames Ethernet são “envelopes” para os pacotes TCP/IP. O aplicativo (um navegador, um servidor web, ou qualquer outro aplicativo transmitindo dados pela rede) envia os dados ao sistema operacional, que divide o fluxo em pacotes TCP/IP e os envia à placa de rede. As placas de rede (que não entendem o protocolo TCP/IP) tratam os pacotes como um fluxo de dados qualquer e adicionam mais uma camada de endereçamento, desta vez baseada nos endereços MAC dos dispositivos da rede, gerando o frame Ethernet que é finalmente transmitido. Ao chegar do outro lado, o “envelope” é removido e o pacote TCP/IP é entregue.
O uso dos frames adiciona alguns bytes adicionais a cada pacote transmitido, reduzindo sutilmente o desempenho da rede. Veja o diagrama de um frame Ethernet:

A transmissão de cada frame começa com o envio de 8 bytes contendo um preâmbulo e uma sequência de inicialização. Ele serve para avisar outros micros da rede de que uma transmissão está prestes a começar. Estes 8 bytes iniciais não fazem parte do frame e são descartados pelas placas de rede depois de recebidos, por isso não aparecem no relatório mostrado por sniffers de rede, como o wireshark.
O pacote TCP/IP está contido dentro do campo de dados, que pode incluir até 1500 bytes por frame. Junto com os dados é transmitido o cabeçalho do frame (14 bytes no total), que inclui o endereço MAC de destino, endereço MAC de origem e um campo para o tipo de dados e mais 4 bytes finais, que contém códigos de CRC, usados (pelas placas de rede) para verificar a integridade do frame recebido. Caso o frame chegue incompleto ou corrompido, a placa de rede solicita a retransmissão.
Dentro do pacote TCP/IP temos novos headers, que contém o endereço IP de origem, endereço IP de destino, porta de origem, porta de destino, códigos de verificações, número do pacote, campo para inclusão de opções e assim por diante. No total, temos 20 bytes para os headers do protocolo TCP e mais 20 bytes para os headers do protocolo IP, totalizando 40 bytes de headers por pacote. Desta forma, temos 1460 bytes de dados em um pacote de 1500 bytes e 536 bytes de dados em um pacote de 576 bytes, por exemplo:

À primeira vista, pode parecer estranho que sejam incluídos headers separados para o TCP e o IP, mas a verdade é que os dois são complementares e por isso não podem ser dissociados. É por isso que usamos o termo “TCP/IP”, como se os dois protocolos fossem uma coisa só.
Os headers do protocolo IP incluem o endereço IP de origem e o endereço IP de destino, enquanto os headers do TCP incluem a porta de origem e de destino, por exemplo. Em resumo, podemos dizer que o IP se encarrega da entrega dos pacotes, enquanto o TCP se encarrega da verificação de erros, numeração de portas e tudo mais.
Como disse, os pacotes podem ter até 1500 bytes no total, onde temos até 1460 bytes de dados e 40 bytes dos headers. Arquivos e outros tipos de informações são transmitidas na forma de sequências de vários pacotes. Um arquivo de 15 KB, por exemplo, seria dividido em um total de 11 pacotes; os 10 primeiros contendo 1460 bytes cada um e o último contendo os últimos 760 bytes. É graças aos códigos de verificação e numeração dos pacotes que arquivos grandes podem ser transmitidos de forma íntegra mesmo através de conexões via modem ou links wireless, onde diversos pacotes são corrompidos ou perdidos. Basta retransmitir os pacotes extraviados ou danificados quantas vezes for necessário. :)
Embora os pacotes TCP/IP de 1500 bytes sejam os mais comuns, o tamanho pode variar de acordo com o meio de transmissão usado. No ADSL PPPoE (o ADSL com autenticação, usado na maioria das instalações atuais), por exemplo, são utilizados pacotes de 1492 bytes, enquanto que nas conexões discadas são geralmente utilizados pacotes de apenas 576 bytes. Existem ainda casos de pacotes maiores, utilizados em situações específicas.
Dentro da rede local, temos (incluindo o preâmbulo do frame Ethernet) um total de 1526 bytes transmitidos para cada pacote TCP/IP de 1500 bytes. Em uma rede local, que trabalha a 100 ou 1000 megabits, isso não faz muita diferença, mas na internet isso seria um grande desperdício. Por isso, os roteadores se encarregam de eliminar estas informações desnecessárias, retransmitindo apenas os pacotes TCP/IP propriamente ditos. É por isso disso que não é possível criar regras de firewall baseadas em endereços MAC para pacotes vindos da Internet: os endereços MAC fazem parte das informações incluídas no frame Ethernet, que são descartadas pelos roteadores.
trabalharem diretamente com endereços IP, os roteadores podem ser enquadrados na camada 3 do modelo OSI (camada de rede). Basicamente, são roteadores que cuidam de todo o trafego de dados na internet. Você pode utilizar um hub ou switch dentro da sua rede local, mas ao acessar a internet você sempre utiliza um roteador, seja um roteador Cisco de grande porte, seja um micro com duas placas de rede compartilhando a conexão, ou seja um roteador dentro da rede do provedor de acesso. Na internet, o mais comum é o uso de links de fibra óptica, mas os roteadores podem se interligados utilizando qualquer tipo de mídia.
Temos aqui um exemplo, que mostra Backbones de fibra óptica interligando países da Ásia:

Este é um exemplo do que você veria em pontos de interconexão: um roteador Cisco com diversos links de fibra óptica:

Quando você usa um PC com duas placas de rede para compartilhar a conexão com os micros da rede local, você está configurando-o para funcionar como um roteador simples, que liga uma rede (a Internet) a outra (a sua rede doméstica). O mesmo acontece ao configurar seu modem ADSL como roteador. Pense que a diferença entre os switches e os roteadores é justamente esta: os switches permitem que vários micros sejam ligados formando uma única rede, enquanto que os roteadores permitem interligar várias redes diferentes, criando redes ainda maiores, como a própria Internet.
Dentro de uma mesma rede é possível enviar pacotes de broadcast, que são endereçados a todos os integrantes da rede simultaneamente e, ao usar um hub burro, todos os micros recebem todas as transmissões. Um roteador filtra tudo isso, fazendo com que apenas os pacotes especificamente endereçados a endereços de outras redes trafeguem entre elas. Lembre-se de que, ao contrário das redes locais, os links de Internet são muito caros, por isso é essencial que sejam bem aproveitados.
endereçamento IP é um tema importante, já que é ele que permite que o brutal número de redes e hosts que formam a internet sejam capazes de se comunicar entre si.
Existem duas versões do protocolo IP: o IPV4 é a versão atual, que utilizamos na grande maioria das situações, enquanto o IPV6 é a versão atualizada, que prevê um número brutalmente maior de endereços e deve começar a se popularizar a partir de 2010 ou 2012, quando os endereços IPV4 começarem a se esgotar.
No IPV4, os endereços IP são compostos por 4 blocos de 8 bits (32 bits no total), que são representados através de números de 0 a 255, como “200.156.23.43” ou “64.245.32.11”.
As faixas de endereços começadas com “10”, com “192.168” ou com de “172.16” até “172.31” são reservadas para uso em redes locais e por isso não são usados na internet. Os roteadores que compõe a grande rede são configurados para ignorar estes pacotes, de forma que as inúmeras redes locais que utilizam endereços na faixa “192.168.0.x” (por exemplo) podem conviver pacificamente.
No caso dos endereços válidos na internet as regras são mais estritas. A entidade responsável pelo registro e atribuição dos endereços é a ARIN (http://www.arin.net/). As operadoras, carriers e provedores de acesso pagam uma taxa anual, que varia de US$ 1.250 a US$ 18.000 (de acordo com o volume de endereços requisitados) e embutem o custo nos links revendidos aos clientes.
Ao conectar via ADSL ou outra modalidade de acesso doméstico, você recebe um único IP válido. Ao alugar um servidor dedicado você recebe uma faixa com 5 ou mais endereços e, ao alugar um link empresarial você pode conseguir uma faixa de classe C inteira. Mas, de qualquer forma, os endereços são definidos “de cima para baixo”, de acordo com o plano ou serviço contratado, de forma que você não pode escolher quais endereços utilizar.
Embora aparentem ser uma coisa só, os endereços IP incluem duas informações. O endereço da rede e o endereço do host dentro dela. Em uma rede doméstica, por exemplo, você poderia utilizar os endereços “192.168.1.1”, “192.168.1.2” e “192.168.1.3”, onde o “192.168.1.” é o endereço da rede (e por isso não muda) e o último número (1, 2 e 3) identifica os três micros que fazem parte dela.
Os micros da rede local podem acessar a internet através de um roteador, que pode ser tanto um servidor com duas placas de rede, quando um modem ADSL ou outro dispositivo que ofereça a opção de compartilhar a conexão. Neste caso, o roteador passa a ser o gateway da rede e utiliza seu endereço IP válido para encaminhar as requisições feitas pelos micros da rede interna. Este recurso é chamado de NAT (Network Address Translation).
Um dos micros da rede local, neste caso, poderia usar esta configuração de rede:
Endereço IP: 192.168.1.2
Máscara: 255.255.255.0
Gateway: 192.168.1.1 (o servidor compartilhando a conexão)
DNS: 200.169.126.15 (o DNS do provedor)
O servidor, por sua vez, utilizaria uma configuração similar a esta:
Placa de rede 1 (rede local):
Endereço IP: 192.168.1.1
Máscara: 255.255.255.0
Placa de rede 2 (internet):
Endereço IP: 200.213.34.21
Máscara: 255.255.255.0
Gateway: 200.213.34.1 (o gateway do provedor)
DNS: 200.169.126.15 (o DNS do provedor)
A configuração da segunda placa de rede seria obtida automaticamente, via DHCP, de forma que você só precisaria realmente se preocupar com a configuração da sua rede local. Normalmente, você primeiro configuraria a rede local, depois conectaria o servidor à internet e, depois de checar as duas coisas, ativaria o compartilhamento da conexão via NAT.
É possível instalar mais placas de rede no roteador e dividir a rede em vários segmentos distintos, interligados através dele. Em uma empresa, poderíamos ter três segmentos diferentes, um para a rede cabeada e a maior parte dos micros, outro para a rede wireless e outro para os servidores, que ficariam isolados em uma sala trancada.
O roteador nesse caso teria 4 placas de rede (um para cada um dos três segmentos e outra para a internet). A vantagem de dividir a rede desta maneira é que você poderia criar regras de firewall no roteador, especificando regras diferentes para cada segmento. Os micros conectados à rede wireless (menos segura), poderiam não ter acesso aos servidores, por exemplo. O firewall, ativo no roteador, poderia também ser configurado para proteger os micros das redes internas de ataques provindos da internet:

Talvez você goste disso também:

DOBRE SEU INVESTIMENTO em 90 DIAS

Não precisa indicar ninguém para dobrar seu investimento em 90 dias.

Basta Acessar oTudo.com/GC e Cadastrar-se.



Sobre: wkrepke

Sou sempre tranquilo, alegre e adoro amizades

Deixar uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *

*

Solve : *
20 ⁄ 1 =


Pode usar estas etiquetas HTML e atributos: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>