9.1.1. Introdução

O presente capítulo do guia é dedicado às redes, das quais explica os elementos fundamentais para os leitores que não têm uma grande familiaridade com o assunto. O capítulo seguinte, por sua vez, contém uma introdução prática às configurações de rede do NetBSD. Quem deseja configurar rapidamente a rede pode iniciar com o próximo capítulo e depois voltar vom calma à leitura do capítulo atual.

Da parte do leitor é pressuposto o conhecimento de elementos de base da administração do sistema: como tornar-se "root", como editar arquivos, como mudar as permissões dos arquivos, como encerrar processos, etc. Ver por exemplo [AeleenFrisch] para aprofundar estas questões. Além disso, é necessário saber utilizar alguns programas utilitários como telnet, ftp, etc. Tais programas não serão descritos aqui e, portanto, para informações adicionais remete-se às páginas de manual, à bibliografia e aos outros capítulos desse guia.

Esta introdução às redes TCP/IP não tem a pretensão de ser completa. Quem deseja aprofundar os assuntos tratados, para ter um quadro mais completo pode fazer referência a [CraigHunt]. Este livro, além de descrever os elementos de base, explica todos os conceitos e detalhes necessários para a configuração de todos os serviços. É um ótimo livro.

9.1.2. Protocolos de rede suportados

O NetBSD suporta vários protocolos de rede, a maior parte dos quais herdados de seu predecessor, o 4.4BSD, e posteriormente estendidos e melhorados. O primeiro protocolo implementado é o que hoje tem maior importância, o Transmission Control Protocol/Internet Protocol (TCP/IP) do DARPA. Outros protocolos disponíveis no NetBSD são o Xerox Network System (XNS), implementado para a UCB para coligar em rede máquinas isoladas, o AppleTalk da Apple, o ISO, o CCITT X.25 e o ARGO TP. Estes últimos protocolos são usados hoje apenas para algumas aplicações especiais.

Hoje o TCP/IP é o protocolo mais difundido entre os mencionados no parágrafo precedente. Além de ser implementado para todo sistema operacional e em todo tipo de hardware, é também o protocolo mais usado em ambientes heterogêneos. Portanto, o TCP/IP é a escolha mais justa para conectar seu próprio computador a outras máquinas domésticas ou a redes empresariais ou universitárias.

A versão corrente do protocolo TCP/IP é a 4 (IPv4). A versão 6 (IPv6) está em fase de desenvolvimento e o código IPv6 do projeto KAME está integrado nas edições do NetBSD já a partir da 1.5.

Também existem protocolos que não são suportados pelo NetBSD, como DECNET, IPX/SPX da Novell e NetBIOS da Microsoft. Estes protocolos, diferentemente dos precedentes, são proprietários e, portanto, não são definidos por algum RFC público como os outros padrões abertos.

9.1.3. Interfaces suportadas

O protocolo TCP/IP pode ser utilizado com uma ampla gama de interfaces. Entre as suportadas pelo NetBSD recordemos a Ethernet (10/100/1000MBd), a linha serial Arcnet, ATM, Fiber Channel, USB, HIPPI, FireWire (IEEE 1394), Token Ring, linhas seriais e ainda outras.

9.1.4. O formato dos endereços TCP/IP

A atual implementação do protocolo TCP/IP (IPv4) usa os identificadores de 4 bytes (32 bits) (chamados também endereços de IP) para endereçar os hosts.

Estes endereços IP são únicos em nível mundial. Para atingir esse objetivo, sua administração é delegada a um organismo central, o InterNIC, que designa grupos de endereços diretamente aos sites que queiram ligar-se à Internet ou aos provedores que os redistribuirão aos próprios clientes.

As universidades e empresas ligadas à Internet têm pelo menos um desses endereços, geralmente não atribuído diretamente pelo InterNIC, mas obtido de um Provedor de Serviço de Internet (Internet Service Provider ISP).

Para configurar uma rede privada doméstica basta "inventar" os próprios endereços privados, como se explica à frente. Para conectar a própria máquina à Internet, todavia, é necessário obter um "verdadeiro" endereço de IP do próprio administrador de rede ou do provedor.

Para a escrita dos endereços IP é usada particularmente uma notação chamada dotted quad (quadripontuada), na qual os quatro bytes do endereço são escritos um de cada vez (a partir do mais significativo), separando-os com um ponto. Por exemplo 132.199.15.99 é um endereço válido. Um endereço pode também ser escrito utilizando-se uma palavra de 32 bits em hexadecimal, por exemplo: 0x84c70f63. Este formato não é tão intuitivo como o precedente, mas às vezes pode-se revelar útil como será visto nas seções seguintes.

Atribuir uma rede a um host significa simplesmente estabelecer valores determinados para alguns dos 32 bits do endereço do host. Estes bits, usados para identificar a rede, são chamados "bits de rede". Os bits restantes servem para identificar o host no interior da rede, e são portanto denominados "bits de host".

No exemplo precedente o endereço de rede é 132.199.0.0 (em um endereço de rede os bits de host são definidos como zero), enquanto o endereço do host na rede é 15.99.

Como se faz para saber que o endereço do host ocupa 16 bits? Simples: é indicado pelo provedor do qual se obtém o próprio endereço. No estradamento inter-domínios sem classificação (Classless Inter-Domain Routing,CIDR) utilizado hoje, o número de bits reservados ao host vai de 2 a 16 e o número de bits reservado à rede é escrito depois do endereço IP, separado por uma "/". Por exemplo, 132.199.0.0/16 indica que a rede em questão tem 16 bits. Quando nos referimos à "dimensão" de uma rede, o fazemos em geral simplesmente com "/16", "/24", etc.

Antes do advento do CIDR as redes eram divididas em quatro classes. Cada classe iniciava-se com uma bem precisa seqüência de bits que a identificava. Em detalhe:

• A Classe A inicia-se com "0" como o bit mais significativo. Os próximos 7 bits de um endereço de Classe A identificam a rede e os restantes 24 bits são usados para endereçar o host. Portanto, em uma rede de Classe A pode haver um host 2²⁴. Não é fácil, todavia, para uma firma ou para uma universidade obter um endereço de Classe A completo.

  A notação CIDR para uma rede de Classe A com os seus 8 bits de rede é "/8".

• A Classe B inicia-se com "10" como os bits mais significativos. Os próximos 14 bits identificam a rede e os restantes 16 bits servem para endereçar os hosts (mais de 65000). Os endereços de Classe B, que já foram muito comuns para firmas e universidades, são hoje muito difíceis de se obter, por causa da atual escassez de endereços IPv4 disponíveis.

  A notação CIDR para uma rede de Classe A com os seus 16 bits de rede é "/16".

  Retornando ao exemplo precedente, pode-se ver que o host 132.199.15.99 (ou o equivalente hexadecimal 0x84c70f63, que aqui é mais cômodo) encontra-se em uma rede de Classe B, já que 0x84 = 1000... (em binário).

  Portanto, o endereço 132.199.15.99 pode ser dividido na parte de rede que é 132.199.0.0 e na parte do host que é 15.99.

• A Classe C é identificada pelos bits mais significativos (chamados também MSB, Most Significant Bits) iguais a "110", permitindo apenas 256 hosts em cada uma das 2²¹ possíveis redes de Classe C (na realidade, como será visto depois, o número de hosts possíveis é 254). Os endereços de Classe C são mais comumente encontrados em pequenas empresas.

  A notação CIDR para uma rede de classe C com os seus 24 bits de rede é "/24".

• Existe também uma ulterior série de endereços que se iniciam com "111", e que são muito usados para outros fins (por exemplo, multicast) e que não nos interessam aqui.

Note-se que os bits utilizados para identificar a rede fazem, não obstante, parte do próprio endereço de rede.

Quando se separa a parte de rede da parte de host é cômodo utilizar a assim chamada netmask (máscara de rede). Trata-se de um valor a ser usado como "mascára", em que todos os bits de rede são assentados em "1" e todos os bits de host em "0". Pondo juntos com um AND lógico o endereço com a netmask obtém-se o endereço da rede.

Reportando-se ao exemplo precedente, 255.255.0.0 é uma possível netmask de 132.199.15.99. Quando se aplica a netmask ao endereço, permanece a parte de rede 132.199.0.0.

Para os endereços em notação CIDR, o número indicado de bits de rede especifica também quais dos bits mais significativos devem ser postos em "1" para se obter a netmask da rede correspondente. Para os endereços de rede Classe A/B/C existe uma netmask default:

• Class A (/8): netmask default: 255.0.0.0, primeiro byte do endereço: 1-127

• Class B (/16): netmask default: 255.255.0.0, primeiro byte do endereço: 128-191

• Class C (/24): netmask default: 255.255.255.0, primeiro byte do endereço: 192-223

Um tipo particular de endereço que é bom conhecer é o "endereço de broadcast". As mensagens enviadas a este endereço são recebidas por todos os hosts da rede correspondente. O endereço de broadcast é caracterizado pelo fato de ter todos os bits de host colocados em "1".

Por exemplo, dado o endereço 132.199.15.99 com a máscara de rede 255.255.0.0, o endereço de broadcast é 132.199.255.255.

Nesse ponto podem-nos perguntar se podemos utilizar um endereço de host com todos os bits em "0" ou em "1". A resposta é não, porque o primeiro é o endereço da rede e o segundo o endereço de broadcast, e esses dois endereços devem estar sempre presentes. Agora se pode compreender porque uma rede de Classe B pode conter no máximo 2¹⁶-2 hosts e uma rede de Classe C pode conter 2⁸-2 = 254.

Além dos vários tipos de endereço já citados, há um outro que é especial. Trata-se do endereço 127.0.0.1, que se refere sempre ao host local (localhost). Isso significa que quando se "fala" com o 127.0.0.1, comunica-se na realidade consigo mesmo, sem dar lugar a nenhuma atividade de rede, o que pode ser útil para utilizar os serviços instalados na própria máquina ou para fazer simulações e testes quando não há outro host na rede.

Resumindo o que se discutiu até agora:

9.1.5. Sub-rede e estradamento (routing)

A seção precedente descreveu em detalhe as máscaras de rede e os endereços de host e de rede. O discurso sobre redes, entretanto, está longe de terminar.

Consideremos a situação de uma típica universidade, com um endereço de Classe B (/16) que lhe permite ter até 2¹⁶ ~= 65534 hosts na rede. Mesmo que fôsse cômodo pensarmos em ter todos estes hosts em uma mesma rede, isto não pode ser realizado por causa das limitações físicas do hardware em uso atualmente.

Por exemplo, o comprimento máximo de um cabo Ethernet thinwire é de 185 metros. Ainda que se ponham repetidores que amplifiquem o sinal entre os pontos de rede, isto não basta para se atingir todos os pontos de rede em que se encontram as máquinas. Além disso, o número máximo de hosts em um cabo Ethernet thinwire é de 1024 e, avizinhando-se desse limite, tem-se uma perda de eficiência.

Portanto, encontramo-nos em uma situação em que temos um endereço que permitiria ter 60000 hosts mas estamos limitados pelo cabeamento, que nos permite atingir um número muito menor de pontos de rede.

Naturalmente existe a solução, e consiste em subdividir a "rede" de Classe B em redes menores, usualmente denominadas sub-redes. Estas sub-redes podem hospedar, por exemplo, até 254 hosts cada (isto é, subdividimos a grande rede de Classe B em várias sub-redes de Classe C).

Para se obter esse resultado, é necessário modificar a máscara de rede para se ter mais bits de rede e menos bits de host. Isto geralmente se faz trabalhando sobre os bytes da máscara (mesmo que seja possível descer ao nível de um único bit). Portanto, a coisa mais simples é transformar a máscara de rede de 255.255.0.0 (Classe B) em 255.255.255.0 (Classe C).

Usando a notação CIDR, escreve-se agora "/24" ao invés do precedente "/16" para indicar que são usados 24 bits do endereço para identificar a rede e a sub-rede,em vez dos 16 usados antes.

Esta modificação permite-nos ter um byte de rede a mais para cada uma das redes físicas. Todos os 254 hosts de cada rede podem comunicar-se diretamente e podem ser criadas 256 redes desse tipo (Classe C). Esta nova configuração deveria ser adequada às exigências da nossa universidade hipotética.

Para esclarecer melhor o conceito, continuemos com o exemplo precedente. Suponhamos que o nosso host seja 132.199.15.99, que se chame dusk e que tenha a netmask 255.255.255.0, o que significa que se encontra na sub-rede 132.199.15.0/24. Naturalmente há outros hosts,como se vê pela Figura 9-1.

Na rede do exemplo,dusk pode falar diretamente com dawn, já que ambos encontram-se na mesma sub-rede. Existem ainda outros hosts na sub-rede 132.199.15.0/24, mas por ora não os consideraremos.

O que acontece se dusk quer falar com um host que se encontra em uma outra sub-rede? Nesse caso, o tráfego ocorrerá através de um ou mais gateways (routers) anexados às duas sub-redes. Por esse motivo um gateway tem sempre dois endereços diferentes: um para cada uma das subredes a que está conectado. Do ponto de vista funcional, o router (estradador) é totalmente transparente para os hosts. Ou seja, não é necessário conhecer-lhe o endereço para atingir os hosts que estão do "outro lado". É suficiente endereçar diretamente aos hosts e os pacotes alcançarão o destino correto.

Suponhamos por exemplo que dusk queira fazer o download de arquivos do servidor FTP local. Já que dusk não pode alcançar ftp diretamente (porque se encontra em uma sub-rede diferente) todos os seus pacotes serão encaminhados ao seu "router por default" rzi (132.199.15.1), que sabe para onde deve enviá-los para que atinjam a destinação.

dusk conhece o endereço do router por default da sua rede (rzi, 132.199.15.1), e lhe encaminha todos os pacotes que não são destinados à mesma sub-rede. Isto é, neste caso, todos os pacotes IP que têm o terceiro byte do endereço diferente de 15.

O router por default (defaultrouter) envia os pacotes ao host apropriado, visto que se encontra na sub-rede do servidor de FTP.

Neste exemplo todos os pacotes são enviados à rede 132.199.1.0/24 simplesmente porque se trata do backbone da rede, a parte mais importante da rede, que transporta todo o tráfego de passagem entre as várias sub-redes. Quase todas as sub-redes além de 132.199.1.0/24 estão conectadas ao backbone de modo similar.

Que acontece se conectássemos uma outra sub-rede a 132.199.15.0/24 ao invés de 132.199.1.0/24? Provavelmente algumas coisa parecida à situação descrita na Figura 9-2.

Agora, para dusk atingir um host que se encontra na sub-rede 132.199.16.0/24, os pacotes não podem ser encaminhados a rzi. É necessário enviá-los diretamente a route2 (132.199.15.2). dusk deve saber que deve encaminhar estes pacotes para route2 e enviar todos os outros para rzi.

Quando se configura dusk, dizemos a ele para enviar todos os pacotes para a sub-rede 132.199.16.0/24, a route2, e todos os outros a rzi. Ao invés de explicitar este default com 132.199.1.0/24, 132.199.2.0/24, etc., pode-se usar o valor 0.0.0.0 para definir a rota default.

Retornando à Figura 9-1, verifica-se um problema parecido quando dawn quer enviar a noon, que está ligado a dusk via cabo serial. Do exame de seu endereço IP,noon pareceria estar conectado à rede 132.199.15.0. Esse realmente não é o caso. Ao contrário, dusk é usado como gateway e dawn deve enviar seus pacotes a dusk que, por sua vez, os encaminhará a noon. O sistema graças ao qual dusk é forçado a aceitar pacotes que não são destinados a ele, mas a um outro host (noon), é definido "proxy arp".

O mesmo discurso vale quando um host de uma outra sub-rede que enviar a noon. Deverá enviar os seus pacotes a dusk (eventualmente encaminhados por rzi).

9.1.6. Conceitos de Name Service

Nas seções precedentes, fazendo referência aos hosts utilizamos freqüentemente seus endereços IP. Isto era necessário para explicar as diferenças entre os vários tipos de endereços. Em geral, todavia, quando se fala de host é mais cômodo utilizar seu "nome", como fizemos na seção sobre routing.

Para a maior parte das aplicações não importa se os hosts são especificados usando o nome ou o endereço IP. Todavia, internamente elas usam endereços IP. Nesta seção serão introduzidos os conceitos que estão na base de cada um desses métodos. Sucessivamente será explicado como efetuar-lhes a configuração.

A conversão dos nomes dos hosts (e dos domínios) em endereços de IP é realizada por um módulo de software chamado resolver. Não se trata de um serviço complementar, mas de uma série de funções de biblioteca que são articuladas com cada aplicação que usa funções de rede. O resolver procura "resolver" (daí o nome) os nomes dos hosts em endereços IP. Veja-se [RFC1034] e [RFC1035] para maiores detalhes sobre o resolver.

Os nomes dos hosts têm geralmente um comprimento máximo de 10 caracteres e podem conter letras, números, hífens ("-") e traços de subscrito ("_"). Maiúsculas e minúsculas são consideradas equivalentes.

Assim como para as redes e sub-redes, é possível (mais que isso, desejável) reagrupar os hosts em domínios e subdomínios. Quando se obtém um endereço de rede do provedor, geralmente se obtém também um nome de domínio. Como para as sub-redes, é deixada ao usuário a tarefa de criar sub-domínios. Os sub-domínios não estão em relação direta com as sub-redes. Por exemplo, um domínio pode conter hosts conectados a diversas sub-redes.

Figura 9-1 mostra as sub-redes 132.199.1.0/24 e 132.199.15.0/24 (e as outras) que fazem parte do sub-domínio rz.uni-regensburg.de. O domínio que a Universidade de Regensburg obteve de seu provedor de IP é "uni-regensburg.de" (".de" indica a Alemanha, Deutschland); o sub-domínio "rz" indica Rechenzentrum (Centro de Cálculo).

Os nomes dos hosts, dos sub-domínios e dos domínios são separados por pontos (".". Também é possível, embora não seja comum, usar mais de um nível de sub-domínio. Por exemplo: fox_in.socs.uts.edu.au.

Um nome de host que compreende o (sub)domínio é denominado domínio completamente qualificado (FQDN, Fully Qualified Domain Name). Por exemplo, o endereço IP 132.199.15.99 pertence ao host cujo FQDN é dusk.rz.uni-regensburg.de.

Anteriormente foi dito que o endereço IP 127.0.0.1 pertence sempre ao host local, qualquer que seja o "verdadeiro" endereço IP do próprio host. Portanto, 127.0.0.1 é sempre mapeado pelo nome localhost.

Os três métodos diferentes de traduzir um nome de host em endereço IP são: /etc/hosts, o Domain Name Service (DNS) e o Network Information Service (NIS).

endereço IP        nome host [alias [...]]        

9.1.7. IPv6, o protocolo de última geração da Internet

127.0.0.1	  

fe80::2a0:d2ff:fea5:e9f5	  

10.0.0.0/24	  

2001:638:a01:2::/64	  

01:23:45:67:89:ab	  

03:23:45:ff:fe:67:89:ab	  

::0323:45ff:fe67:89ab	  

127.0.0.1               localhost
::1                     localhost          

noon            IN      AAAA    3ffe:400:430:2:240:95ff:fe40:4385          

zone "0.3.4.0.0.0.4.0.e.f.f.3.IP6.INT" {
        type master;
        file "db.reverse";}; 

5.8.3.4.0.4.e.f.f.f.5.9.0.4.2.0.2.0.0.0 IN   PTR   noon.ipv6.example.com.