Configuração de Redes TCP/IP

CURSO LINUX
Módulo Configuração
de Redes TCP/IP
por
Celso Kopp Webber
Curso Linux Básico
SUMÁRIO
1
INTRODUÇÃO
1
2
INTERFACE DE COMUNICAÇÃO
3
3
2.1
Reconhecimento das Interfaces de Rede
3
2.2
Configuração as Interfaces
4
2.3
Tabela ARP
6
ROTEAMENTO DE DATAGRAMAS IP
3.1
Tabela de Roteamento Mínimo
3.2
Verificação de Conectividade
10
3.3
Roteamento Dinâmico
11
3.3.1
4
5
6
7
8
8
RIP - Routing Information Protocol
12
DOMAIN NAME SERVICE (DNS)
15
4.1
Configuração do Resolver
16
4.2
Configuração do BIND
17
NETWORK FILE SYSTEM (NFS)
25
5.1
Exportando Arquivos
25
5.2
Montando Diretórios Remotos
27
SESSION MESSAGE BLOCK (SMB) – SAMBA
28
6.1
Resolução de Nomes NetBIOS
28
6.2
Samba – Servidor e Cliente SMB
29
6.2.1
Iniciando o Samba
30
6.2.2
Configuração do arquivo smb.conf
30
NETWORK INFORMATION SERVICE (NIS)
Módulo Configuração de Redes TCP/IP
35
i
Curso Linux Básico
ii
Módulo Configuração de Redes TCP/IP
Curso Linux Básico
1 INTRODUÇÃO
Configurar uma rede TCP/IP envolve conhecer os sistemas operacionais dos computadores
envolvidos, bem como dominar os aspectos teóricos da arquitetura de redes TCP/IP.
Dessa forma, este texto assume que o leitor possui prévio conhecimento de redes TCP/IP,
incluindo:
• Conceitos básicos de redes de computadores, incluindo a arquitetura IEEE 802 para
LANs e MANs;
• camadas, protocolos, e funcionamento da arquitetura TCP/IP;
• endereçamento IP;
• roteamento IP, sendo obrigatórios os conceitos de roteamento mínimo e roteamento
estático;
• noções sobre os serviços mais comuns sobre TCP/IP, como e-mail, WWW, FTP, e DNS;
• conhecimentos sólidos do sistema operacional UNIX, a nível de usuário.
O material descrito a seguir está voltado para o sistema operacional UNIX, tanto a nível de
comandos de configuração, como arquivos de configuração.
Assim, o objetivo final do texto é apresentar ao leitor um resumo dos pontos chave da
configuração de redes TCP/IP utilizando o sistema operacional UNIX, tanto como cliente, como
servidor.
Já que qualquer teoria sem prática tem seu utilidade reduzida, as explicações a seguir tentam,
sempre que possível, apresentar os comandos de forma geral. Quando necessário, diferenças entre
sistemas operacionais UNIX diferentes são mostradas. Porém, o sistema operacional Linux é
tomado como base durante o texto. A razão do Linux ter sido adotado como exemplo principal é a
sua crescente popularidade, o fato de ser gratuito, a grande gama de hardware suportado (desde PCs
até processadors RISC de alto desempenho), e sua fácil instalação em relação a alguns UNIX
comerciais.
Pode-se dizer hoje que é possível que qualquer pessoa com conhecimentos razoáveis de
informática consiga instalar o Linux em sua máquina.
No decorrer do texto, as seguintes notações são utilizadas:
• negrito: as palavras em negrito constituem o próprio comando e devem ser digitadas
exatamente como estão escritas;
• normal: o texto normal é usado para opções dos comandos, e também deve ser digitado tal
qual está escrito;
• sublinhado: o texto em sublinhado representa os parâmetros que o usuário especifica, como
por exemplo uma opção de um comando;
• [colchetes]: todo o texto entre colchetes é opcional, e pode ser omitido. Os colchetes não
devem ser digitados;
• ...: as reticências indicam que o item apresentado pode ser repetido uma ou mais vezes.
• opção1 | opção2: quando opções separadas por uma barra vertical são apresentadas, uma
delas deve ser escolhida somente.
A figura 1.1 ilustra as notações acima, descrevendo o formato geral de um comando UNIX:
Módulo Configuração de Redes TCP/IP
1
Curso Linux Básico
$ comando [ -opções ... ] [ argumentos ... ]
mais argumentos podem vir em
seguida.
geralmente são nomes de arquivos
ou caminhos.
outras opções de uma ou mais
letras precedidas de hífen.
opções de uma ou mais letras são
precedidas de hífen.
nome do comando. Para comandos
também há distinção entre letras
minúsculas e maiúsculas.
prompt do shell ($ para Bourne
Shell, % para C-Shell e # para
usuário root)
Figura 1.1 - Formato de comandos UNIX
2
Módulo Configuração de Redes TCP/IP
Curso Linux Básico
2 INTERFACE DE COMUNICAÇÃO
Configurar máquinas UNIX para operar em uma rede TCP/IP é uma tarefa relativamente
fácil. Entretanto, diferentemente de outros sistemas operacionais voltados para uso individual, o
UNIX precisa ser configurado por um administrador de sistemas para que seus usuários possam
utilizá-los adequadamente.
O primeiro passo que um administrador de sistemas deve realizar ao conectar uma máquina
UNIX a uma rede TCP/IP é configurar suas interfaces de rede. Para isso é necessário primeiro
informar ao sistema operacional as interfaces de rede existentes.
2.1 Reconhecimento das Interfaces de Rede
Este tópico é bastante disperso. Um problema grave com o UNIX atualmente é que existem
diversos fornecedores. Cada um dá seus próprios nomes para placas de rede, terminais, impressoras,
etc. Da mesma forma, cada um implementa um método próprio para operar com o hardware
existente, isto é, a implementação dos drivers para dispositivos, incluindo as placas de rede, não é
padronizada.
Por isso, fazer o sistema operacional (SO) reconhecer todos os dispositivos em uma máquina
muitas vezes não é tarefa simples.
No caso de interfaces de rede, muitas vezes o fabricante da placa fornece o próprio driver em
um disquete que acompanha a placa. Em outros casos, o SO possui suporte nativo para
determinadas marcas e modelos de interfaces de rede.
A recomendação mais sensata é que antes de decidir por qual computador adquirir para
determinada tarefa, conferir qual é o hardware suportado pelo SO. O Linux, apesar de ser de
domínio público, possui grande suporte a hardware de diversos fabricantes. Raramente um
fabricante de hardware fornece drivers para Linux (apesar que isto está começando a mudar), mas
em geral, o sistema suporta as marcas mais comuns de placas diversas.
Fazer o SO reconhecer uma placa de rede envolve basicamente três etapas:
1. Configurar a placa através de jumpers, dip switches, etc;
2. instalar fisicamente a placa no computador (e configurá-la via software quando for o
caso);
3. instalar o driver correspondente no sistema operacional, informando os parâmetros
configurados nos passos anteriores.
Em alguns casos, o sistema operacional será capaz de reconhercer automaticamente o
hardware do computador. Infelizmente, tecnologias mais antigas como o barramento ISA em PCs
não ajuda muito nesta tarefa. Placas que utilizam o barramento PCI resolvem este problema fazendo
com que o sistema operacional consiga obter a configuração necessária de todos os dispositivos
instalados no barramento.
Genericamente, o sistema operacional reconhece as placas de rede de duas maneiras:
1. O driver faz parte do kernel do sistema operacional. Esta abordagem é antiga, estando em
desuso pela maioria dos UNIX modernos. Entretanto, pode ser necessário recompilar o
kernel de algum sistema mais antigo para incluir o driver do dispositivo que se deseja
reconhecer;
Módulo Configuração de Redes TCP/IP
3
Curso Linux Básico
2. O driver pode ser carregado separadamente pelo kernel do SO. Assim, o kernel é
especializado nas suas funções, e somente os drivers necessários são carregados em
memória. Isto reduz seu tamanho e aumenta sua eficiência. A maioria dos UNIX atuais
utiliza esta abordagem.
Como exemplos, no Linux os comandos:
insmod nome-do-driver [ parâmetros ]
e
modprobe nome-do-driver
são usados para inserir um driver (chamado de módulo no Linux) em memória. Os parâmetros
podem ser especificados com o comando insmod, ou podem ser “adivinhados” com o comando
modprobe . No Solaris da Sun, o comando equivalente é o modload. As páginas de manual on-line
(comando man) devem ser consultadas para maiores detalhes.
Uma vez que o SO tenha reconhecido as interfaces de rede, sejam elas Ethernet, Token Ring,
FDDI, etc., resta-nos saber que nome o SO utiliza para fazer referência a elas sob o diretório /dev.
A tabela a seguir mostra como algumas versões de UNIX chamam as interfaces Ethernet (as mais
usadas):
Sistema Operacional
SCO UNIX
Linux
Digital UNIX
Solaris
SunOS
AIX
HP-UX
Nome adotado para a primeira interface Ethernet
depende do fabricante (ex: e3B0)
eth0
ln0, tu0
le0
le0, ie0, ec0
en0 (Ethernet), et0 (802.3)
lan0
Outros tipos de interfaces possuem outros nomes sob o diretório /dev, como por exemplo fi0
para interfaces FDDI. A interface loopback, implementada em software, é chamada de lo0 em todos
os UNIX, exceto no Linux, que simplesmente a denomina lo.
2.2 Configuração as Interfaces
O comando ifconfig é usado para informar ao sistema operacional o endereço IP, a máscara
de subrede (netmask), e o endereço de broadcast para cada interface de comunicação.
SINOPSE:
ifconfig [ interface ]
ifconfig interface [ addr_family ] [ address ] [ netmask mask ] [ broadcast address ]
[ up | down ] [ [-]arp ] [ metric n ] [ mtu n ]
ARGUMENTOS:
interface:
addr_family:
address:
4
nome da interface de rede a ser configurada (eth0, lo, etc);
parâmetro opcional que informa o tipo de endereço sendo
configurado. Para endereços IP, este parâmetro deve ser inet;
especifica address como o endereço IP associado à interface;
Módulo Configuração de Redes TCP/IP
Curso Linux Básico
netmask mask:
associa a máscara de rede mask à interface;
broadcast address: informa o endereço de broadcast da interface para address.
EXPLICAÇÃO:
Na primeira forma, o comando apenas mostra a situação da interface especificada,
ou de todas as interfaces, caso este parâmetro seja omitido.
Na segunda forma, especifica uma interface e seus parâmetros a serem
configurados.
root@frajola# ifconfig eth0
eth0
Link encap:Ethernet HWaddr 00:60:52:00:EF:F5
inet addr:10.0.0.254 Bcast:10.0.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:307 errors:0 dropped:0 overruns:0
TX packets:260 errors:0 dropped:0 overruns:0
Interrupt:10 Base address:0x320
EXEMPLO:
Na terceira linha aparece uma lista de opções:
up:
a interface está habilitada para o uso;
down:
a interface está desabilitada para o uso;
broadcast:
a interface suporta broadcast;
notrailers:
a interface não suporta trailers;
running:
a interface está operacional.
Pode-se usar um hostname em vez do endereço IP. Neste caso, o arquivo /etc/hosts deve
conter a entrada correspondente ao nome utilizado.
venus# cat /etc/hosts
127.0.0.1
localhost loghost
#
# inf.ufsc.br Subnet
#
150.162.60.1
venus loghost
150.162.60.2
apolo
150.162.60.3
vesta
150.162.60.4
atlas
150.162.60.5
ceres
150.162.60.6
baco
Usando um hostname, então, o comando poderia ser:
venus# ifconfig le0 venus
O ifconfig é normalmente executado na hora de inicialização da máquina por um arquivo de
boot. Nos sistemas BSD, os comandos do ifconfig geralmente estão localizados nos arquivos
/etc/rc.boot e /etc/rc.local. Nos sistemas System V, os comandos do ifconfig geralmente estão
Módulo Configuração de Redes TCP/IP
5
Curso Linux Básico
localizados em arquivos como /etc/tcp e /etc/init.d/tcp.
Os parâmetros adicionais do ifconfig mais utilizados são descritos abaixo:
down:
desabilita a interface;
up:
habilita a interface;
metric n:
define a métrica como sendo n;
arp:
habilita o uso do protocolo ARP no mapeamento entre os
endereços do nível de rede e os endereços do nível de
interface de rede;
-arp:
desabilita o uso do protocolo ARP;
mtu n:
define o MTU como sendo n.
root@frajola# ifconfig eth0 10.3.2.1 netmask 255.255.0.0 broadcast
10.3.255.255 up
root@frajola# ifconfig eth0
eth0
Link encap:Ethernet HWaddr 00:60:52:00:EF:F5
inet addr:10.3.2.1
Bcast:10.3.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:307 errors:0 dropped:0 overruns:0
TX packets:260 errors:0 dropped:0 overruns:0
Interrupt:10 Base address:0x320
As páginas de manual sobre o comando ifconfig dão maiores detalhes das opções de
configuração.
2.3 Tabela ARP
A tabela ARP (Address Resolution Protocol) descreve, para cada interface de uma máquina
que roda a protocolo IP, a relação entre endereços lógicos (endereços IP) e endereços físicos
(endereços da placa de rede, por exemplo, um endereço MAC Ethernet).
Toda vez que uma máquina precisa comunicar-se via protocolo IP com outra, ela precisa
descobrir o endereço físico da placa de rede da máquina destino. O protocolo ARP cuida desta
função. Como cada tecnologia de rede (Ethernet, FDDI, Token Ring, ATM) possui seu próprio
formato de endereço, bem como diferentes métodos de acesso ao meio, o ARP é diferente para cada
tipo de placa de rede.
No ambiente UNIX, é possível manipular diretamente a tabela ARP, através do comando arp.
Em apenas casos muito específicos é necessário adicionar manualmente entradas na tabela ARP,
pois durante o funcionamento normal da rede, o próprio protocolo se encarrega da descoberta
dinâmica dos endereços físicos associados com os endereços lógicos que a máquina está tentando
acessar.
arp [ -v ] [ -n ] [ -i interface ] -a [ máquina ]
arp [ -v ] [ -i interface ] -s máquina endereço físico [ temp ]
arp [ -v ] [ -i interface ] -d máquina
6
Módulo Configuração de Redes TCP/IP
Curso Linux Básico
ARGUMENTOS:
-v
-n
fornece mensagens detalhadas (verbose)
modo numérico, mostra apenas endereços, isto é, não tenta
converter um endereço para o nome de uma máquina
-i interface
especifica o nome da interface de rede cuja table ARP será
manipulada;
-a máquina
a opção “-a” mostra a tabela ARP. Se um nome ou endereço
de máquina é especificado, mostra somente as entradas
daquela máquina
-s máquina end.fís. adiciona uma entrada manualmente à tabela, associando o
endereço lógico de uma máquina ao seu endereço físico. Se a
opção “temp” é especificada, a entrada é temporária, sendo
eliminada após um tempo padrão, caso contrário a entrada é
estática (permanente)
-d máquina
remove a entrada correspondente ao nome ou endereço de
uma máquina
Módulo Configuração de Redes TCP/IP
7
Curso Linux Básico
3 ROTEAMENTO DE DATAGRAMAS IP
Existem 3 tipos básicos de configurações de roteamento:
• Roteamento mínimo: uma rede completamente isolada de todas as demais redes TCP/IP
necessita somente de um roteamento mínimo;
• Roteamento estático: uma rede com um número limitado de gateways para outras redes
TCP/IP pode ser configurada com roteamento estático;
• Roteamento dinâmico: uma rede com mais de uma possível rota para o mesmo destino
deve usar o roteamento dinâmico.
Rotas são construídas pelo próprio processo de boot do sistema, baseando-se nas informações
usadas para o comando ifconfig, manualmente pelo administrador (através do comando route) ou
dinamicamente pelos protocolos de roteamento.
As rotas estão sempre organizadas numa tabela própria.
3.1 Tabela de Roteamento Mínimo
Uma tabela de roteamento mínimo é construída pelos scripts de boot do sistema operacional
após a configuração da interface com o comando ifconfig. O roteamento mínimo é composto de
uma rota para cada rede a que pertence cada interface (incluindo a interface loopback), e uma rota
default.
Com exceção do Linux, todos os UNIX constroem a tabela de roteamento mínimo
automaticamente a partir do comando ifconfig. Entretanto, é ainda necessário estabelecer uma rota
default. Cada versão de UNIX obtém o roteador default a partir de localizações diferentes. Por
exemplo, o Solaris da Sun obtém esta informação do arquivo /etc/defaulroute, enquanto o RedHat
Linux obtém do arquivo /etc/sysconfig/network.
O comando netstat pode ser usado para mostrar informações sobre conexões da máquina, e
também para mostrar a tabela de rotas.
SINOPSE:
netstat [ -n ] [ -r ] [ -i interface ]
ARGUMENTOS:
interface:
-n:
-r:
-i interface:
nome da interface de rede da qual se deseja obter informações
sobre conexões;
mostra endereços e portas em modo numérico, isto é, não faz
tradução para nomes;
mostra a tabela de rotas corrente;
mostra somente informações relacionadas à interface
especificada;
EXPLICAÇÃO:
8
Módulo Configuração de Redes TCP/IP
Curso Linux Básico
Em geral, o comando netstat é utilizado com as opções –rn para mostrar a tabela
de rotas. Adicionalmente, pode ser usado para verificar quais conexões estão
atualmente abertas com a máquina.
EXEMPLO:
apolo# netstat -rn
Kernel IP routing table
Destination
Gateway
255.255.255.255 0.0.0.0
10.0.0.0
0.0.0.0
127.0.0.0
0.0.0.0
0.0.0.0
192.1.2.3
Genmask
255.255.255.255
255.255.255.0
255.0.0.0
0.0.0.0
Flags
UH
U
U
UG
MSS
1500
1500
3584
1500
Window
0
0
0
0
irtt
0
0
0
0
Iface
eth0
eth0
lo
ppp0
No campo Flags da saída do comando netstat, temos os significados:
U:
A rota está no ar (Up);
H:
A rota é para um host (máquina);
G:
A rota é estabelecida passando por um gateway;
D:
Rota aprendida dinamicamente, ou por um daemon de roteamento
dinâmico, ou pelo recebimento de um ICMP Redirect.
O comando route é usado para a criação de uma tabela estática, adicionando ou removendo
rotas manualmente. Rotas adicionadas com o comando route só podem ser removidas com outro
comando route. Quando uma máquina não está atuando como um gateway, o roteamento mínimo
provido com o comando route é suficiente. Quando um determinado gateway está configurado para
um esquema de roteamento simples, também é suficiente estabelecer algumas rotas estáticas com o
comando route. Os rotadores principais de uma rede maior são em geral candidatos a utilizar
roteamento dinâmico.
SINOPSE:
route add [ -host | -net ] destination [ netmask mask ] [ gateway router ] [ metric M ]
[ mss M ] [ window W ] [ device ]
route del [ -host | -net ] destination [ netmask mask ] [ gateway router ] [ device ]
ARGUMENTOS:
-host ou –net:
destination:
netmask mask:
gateway router:
device:
metric M:
mss M:
window W:
determina se a rota é para um máquina ou para uma rede. Se
este parâmetro for omitido, é assumido o valor “-host”;
informa destino da rota;
utiliza mask como máscara de subrede para esta rota;
utiliza router como o gateway para esta rota. Se for utilizado
como gateway um endereço de uma das interfaces da
máquina, a rota será estabelecida enviando diretamente por
aquela interface;
nome da interface de rede que esta rota utilizará como saída;
estabelece a métrica para a rota sendo estabelecida;
estabelece o MSS – Maximum Segment Size (tamanho máximo
do segmento) TCP a usar com esta rota;
informa o tamanho da janela TCP a ser usada nessa rota.
Módulo Configuração de Redes TCP/IP
9
Curso Linux Básico
EXPLICAÇÃO:
Algumas versões do comando route entendem que se destination for uma rede à
qual uma das interfaces da máquina pertence, uma rota do roteamento mínimo está
sendo feita, e por isso os outros parâmetros não precisam ser especificados. É
recomendável sempre o uso do parâmetro netmask, caso contrário geralmente o
comando assume a máscara padrão (conforme a classe) do endereço destino
especificado.
EXEMPLO:
root@frajola# route add -net 10.3.0.0 netmask 255.255.0.0
root@frajola# route add –net 10.2.1.0 netmask 255.255.255.0 gateway
10.3.0.254 eth0
root@frajola# netstat –rn
Kernel IP routing table
Destination
Gateway
Genmask
Flags
MSS Window irtt
10.3.0.0
0.0.0.0
255.255.0.0
U
1500 0
0
10.2.1.0
10.3.0.254 255.255.255.0
UG
1500 0
0
127.0.0.0
0.0.0.0
255.0.0.0
U
3584 0
0
Iface
eth0
eth0
lo
Se a palavra chave default for utilizada como destination, route cria uma rota default. Esta
rota default é utilizada quando não há uma rota específica para o destino desejado. É possível
especificar a rota default estabelecendo uma rota para a rede 0.0.0.0.
root@frajola# route add default gateway 10.3.0.252
root@frajola# route add –net 0.0.0.0 gateway 10.3.0.252
root@frajola# netstat -rn
Kernel IP routing table
Destination
Gateway
10.3.0.0
0.0.0.0
10.2.1.0
10.3.0.254
127.0.0.0
0.0.0.0
0.0.0.0
10.3.0.252
Genmask
255.255.0.0
255.255.255.0
255.0.0.0
0.0.0.0
Flags
U
UG
U
UG
MSS
1500
1500
3584
1500
Window
0
0
0
0
irtt
0
0
0
0
Iface
eth0
eth0
lo
eth0
Para se colocar as informações de roteamento estático nos arquivos de boot duas modificações
são necessárias:
• Adicionar a rota desejada ao arquivo de boot;
• Remover (ou comentar) do arquivo de boot comandos que chamem algum protocolo de
roteamento.
Os arquivos a serem modificados variam conforme a plataforma. Nos UNIX baseados em
BSD, geralmente os comandos de adição de rotas estáticas e/ou de execução de protocolo de
roteamento estão nos arquivos /etc/rc.*. No System V, geralmente estão sob o diretório /etc/init.d,
no arquivo boot, tcp ou inet.
3.2 Verificação de Conectividade
Freqüentemente em uma rede é necessário saber se uma máquina “enxerga” outra. A
10
Módulo Configuração de Redes TCP/IP
Curso Linux Básico
ferramenta de diagnóstico mais popular entre os usuários e administradores de rede é o “ping”. ping
é um utilitário onde a máquina origem envia uma mensagem ICMP “echo request” (solicitação de
eco) para a máquina destino. Se esta estiver no ar, ao receber o “echo request” ela responde com
outra mensagem ICMP “echo reply” (resposta de eco).
SINOPSE:
ping [ -f ] [ -i tempo espera ] [ -count quantidade ] destino
ARGUMENTOS:
-f
-i tempo espera
-count quantidade
destino:
`
envia um novo “ping” assim que receber a resposta do
anteriormente enviado. A comportamento default é enviar uma
requisição a cada segundo;
informa o tempo entre cada envio de um novo “ping”;
informa quantos “pings” devem ser enviados. O comportamento
default é enviar “pings” eternamente, até o comando ser
cancelado;
informa o endereço ou nome da máquina destino.
3.3 Roteamento Dinâmico
Todos os protocolos de roteamento possuem a mesma função básica: determinar a melhor rota
para cada destino e distribuir informações de roteamento entre os sistemas em uma rede.
Protocolos de roteamento são divididos em dois grupos principais:
• Internos: São protocolos utilizados internamente em uma rede independente. Na
terminologia TCP/IP, estes sistemas de redes são chamados de “sistemas autônomos”
(AS). Dentro de um AS, as informações de roteamento são trocadas utilizando um
protocolo interno escolhido pelo administrador local. Exemplos de protocolos de
roteamento internos incluem o RIP (Routing Information Protocol), o IGRP (Internet
Gateway Routing Protocol) e o EIGRP (Enhanced IGRP), e o OSPF (Open Shortest Path
First);
• Externos : São protocolos utilizados para trocar informações de roteamento entre
sistemas autônomos. As informações de roteamento trocadas entre os AS são chamadas
de informações de alcançabilidade. Informação de alcançabilidade é simplesmente a
informação sobre quais redes podem ser alcançadas através de um AS. Exemplos destes
protocolos são o antigo EGP (Exterior Gateway Protocol), que está em desuso, e o mais
recente BGP (Border Gateway Protocol).
Módulo Configuração de Redes TCP/IP
11
Curso Linux Básico
O figura a seguir mostra um exemplo de vários AS interconectados pelo protocolo BGP. Note
que as empresas conectadas aos provedores não utilizam nenhum protocolo de roteamento dinâmico
entre elas e os provedores. Isto é bastante fácil de compreender, afinal a empresa possui apenas um
canal de saída, que é o provedor, bastando portanto configurar seu roteador para apontar a rota
default para o roteador do provedor. Internamente, as empresas utilizam seus próprios protocolos de
roteamento.
ABC Ltda
Cia. das
Índias
IGRP
RIP
Provedor
Baía Norte
BGP
EIGRP
Provedor
Bananal Sul
EIGRP
BGP
Serralheria
Metal Sul
EIGRP
BGP
Provedor
Manezinho
OnLine
OSPF
BGP
Provedor
Bananal Sul
EIGRP
A definição de um AS, de acordo com a RFC 1930, é a seguinte:
“Um AS é um grupo conectado de um ou mais prefixos de endereços IP,
administrados por um ou mais operadores de rede que possuem uma
ÚNICA e CLARAMENTE DEFINIDA política de roteamento.”
Assim, um AS é visto como um conjunto de redes cujos endereços IP “começam” com o
mesmo prefixo, por exemplo, todas as redes classe C que começam com “200.135”.
O protocolo IP, ao decidir por onde enviar um datagrama, consulta uma tabela de roteamento.
Com os protocolos de roteamento dinâmicos, esta tabela é constantemente atualizada, de forma
automática. Caso mais de uma rota exista para um determinado destino, o campo métrica das rotas
é comparado. A rota com a menor métrica é então escolhida.
O significado da métrica depende de cada protocolo de roteamento em uso. O protocolo IP
simplesmente escolhe a rota com menor métrica.
Vejamos a seguir um exemplo de protocolo de roteamento dinâmico, incluindo seu
funcionamento básico e suas considerações sobre métricas.
3.3.1 RIP - Routing Information Protocol
É o protocolo interno mais utilizado, pois é disponibilizado como parte da maioria dos
12
Módulo Configuração de Redes TCP/IP
Curso Linux Básico
sistemas UNIX. RIP seleciona a rota com o menor hop count como sendo a melhor. O hop count
representa o número de gateways que o pacote passa até chegar ao seu destino final. A melhor rota
é aquela que usa o menor número de gateways. Assim, a métrica utilizada pelo RIP é “o número de
roteadores” até o destino final. No UNIX, o protocolo RIP é executado através do servidor de
roteamento routed.
Quando um sistema configurado para prover informação RIP escuta uma requisição, ele
responde com um pacote de atualização baseado na sua tabela de roteamento. Este pacote de
atualização contém o endereço destino retirado da tabela de roteamento e a métrica associada a cada
destino.
Pacotes de atualização não são apenas enviados em resposta a solicitações, mas são também
enviados periodicamente para manter as informações de roteamento atualizadas. O routed envia
periodicamente, a cada 30 segundos, todas as rotas que possui para todas as interfaces configuradas.
Quando um pacote de atualização é recebido pelo routed, ele obtém estas informações e atualiza
suas tabelas de roteamento. Se a rota recebida não consta da tabela ela é adicionada. Se a rota
recebida descreve uma rota para um endereço que já existe, ela somente é usada se possuir um custo
(métrica) menor.
O protocolo RIP também remove rotas da tabela de roteamento. Existem duas razões para isto
acontecer:
1. O gateway para o destino diz que o custo da rota é maior que 15 hops;
2. gateways por onde passam certas rotas não enviaram pacotes de atualização por um dado
período, portanto foram considerados fora de serviço. As rotas que passam por eles são
consideradas inválidas.
O routed vem geralmente incluído nos arquivos de boot. A maioria dos sistemas usa
/etc/routed para rodar o servidor, mas os sistemas SunOS usam /usr/etc/in.routed. No Linux,
normalmente é encontrado em /usr/sbin/in.routed.
Nos UNIX que seguem a linha BSD, o routed é geralmente executado a partir do script de
inicialização /etc/rc.local. No System V, normalmente existe um script próprio chamado
/etc/init.d/routed para executar este daemon.
O routed pode construir uma tabela de roteamento só com as informações recebidas dos
pacotes de atualização, mas algumas vezes é necessário alguma forma de complemento, como uma
rota default inicial. O arquivo /etc/gateways contém estas informações adicionais de roteamento.
routed lê o arquivo /etc/gateways quando é inicializado. O uso mais comum do arquivo
/etc/gateways é definir uma rota default ativa, como no exemplo a seguir:
# net 0.0.0.0 gateway 150.162.1.1 metric 1 active
Todas as entradas do arquivo /etc/gateways começam com a palavra net ou host para indicar
quando o endereço que segue é de uma rede ou de um host. No comando route o parâmetro default
é utilizado para indicar a rota default, mas no arquivo /etc/gateways a rota default é indicada pelo
endereço 0.0.0.0. O parâmetro gateway vem seguido do seu endereço IP e a métrica pelo seu valor.
Todas as entradas do arquivo /etc/gateways terminam com o parâmetro passive ou active.
SINOPSE:
routed [ -q ] [ -g ] [ -s ]
ARGUMENTOS:
Módulo Configuração de Redes TCP/IP
13
Curso Linux Básico
-q:
Instrui o routed a apenas “escutar” rotas, sem anunciar as suas
próprias rotas (quiet);
Anuncia aos demais roteadores uma rota default apontando
para si. Geralmente isto é usado em um gateway padrão de
uma rede, para que os outros roteadores apontem suas rotas
default para ele;
Força o routed a anunciar suas rotas. Normalmente, routed
apenas anuncia suas rotas a cada 30 segundos se a máquina
possuir mais de uma interface de rede configurada
(excetuando-se a interface loopback).
-g:
-s:
EXPLICAÇÃO:
Normalmente, o backbone de uma rede conterá vários roteadores para redes
menores. Um dos roteadores no backbone será o roteador padrão, que fará o
roteamento para o mundo externo. Assim, o roteador padrão deveria executar
routed com as opções –s e –g, enquanto os demais apenas com a opção –s.
EXEMPLOS:
NO GATEWAY PADRÃO
root@frajola# routed –s –g
NOS DEMAIS GATEWAYS
root@frajola# routed –s
EM GATEWAYS PARA UMA ÚNICA REDE
root@frajola# routed -q
14
Módulo Configuração de Redes TCP/IP
Curso Linux Básico
4 DOMAIN NAME SERVICE (DNS)
Freqüentemente os usuários de uma rede sabem o nome da máquina à qual desejam se
conectar na Internet, mas raramente conhecem o endereço IP correspondente. Entretanto, o
protocolo IP trabalha com endereços.
Assim, uma forma de traduzir nomes em endereços faz-se necessária. No início da utilização
do TCP/IP na ARPANET, uma tabela estática com todos os nomes de máquinas e seus endereços
era mantida de forma centralizada pelo DOD NIC (Departmento Of Defense Network Information
Center). Quando uma máquina era adicionada à rede, as atualizações eram enviadas por e-mail ao
DOD NIC, que regularmente atualizava a tabela de hosts.
Regularmente, as demais máquinas da ARPANET copiavam através da rede esta tabela, o que
com o passar do tempo passou a ser uma tarefa dispendiosa e demorada.
A solução rapidamente adotada foi a concepção de um sistema de resolução de nomes com as
seguintes características principais:
• provê um serviço de tradução de nomes para endereços (e endereços para nomes)
automatizado;
• utiliza uma base de dados distribuída hierarquicamente, evitando centralizar informações
em um único ponto;
• cada organização que registra um nome no sistema é responsável pelo gerenciamento dos
nomes abaixo de seu domínio;
• é mantido um cache atualizável das informações obtidas, desta forma eliminando-se a
necessidade de se obter a mesma informação repetidamente.
Este sistema foi batizado de DNS (Domain Name Services) e divide o espaço de nomes em
domínios. Cada domínio deve possuir um servidor primário, e no mínimo um servidor secundário
para fins de redundância. A implementação do DNS usada na maioria dos sistemas UNIX é a
Berkeley Internet Name Domain (BIND).
O software do DNS é conceitualmente dividido em duas partes: um resolver e um servidor de
nomes. O resolver formula a consulta e solicita uma resposta. O servidor de nomes é o processo
que responde às consultas.
O servidor de nomes do BIND executa como um processo distinto chamado named.
Servidores de nomes são classificados conforme a sua configuração:
• primary: servidores de onde todos os dados sobre o domínio são derivados. São ditos
authoritatives, por terem autoridade para responder a solicitações envolvendo máquinas
do seu domínio com informações próprias;
• secondary: servidores que guardam consigo uma cópia das informações mantidas pelo
servidor primary. Também são authoritatives para o domínio;
• caching-only: servidores caching-only recebem as respostas de todas as consultas de
outros servidores de nomes, e guardam em cache para usarem em futuras respostas a
solicitações. São chamados de servidores non-authoritatives. Servidores primários e
secundários também fazem caching para melhoria de desempenho.
Um servidor pode ser enquadrado em mais de uma categoria. Ele pode ser primary para um
domínio e secondary para outro, por exemplo.
Módulo Configuração de Redes TCP/IP
15
Curso Linux Básico
Os nomes do DNS têm uma organização hierárquica, constituindo de domínios aninhados
dentro de domínios. Os nomes são escritos da base para o topo, com pontos separando os níveis.
www.cade.com.br
www.mit.edu
mail.hp.com
raiz “.”
br
com
edu
mit
www
com
arpa
hp
in-addr
mail
200
cade
135
www
250
1
2
Os nós imediatamente abaixo da raiz da árvore (br, edu, com, …) são chamados de domínios
top-level. Um desses domínios, chamado arpa possui significado especial. Para que seja possível
fazer a tradução reversa de nomes, isto é, traduzir endereços para nomes, o nó arpa contém o nó
in-addr, que contém todos os endereços Internet (endereços IP). Na verdade, não existem outros
tipos de endereços alocados na árvore, mas o sistema inicialmente previu esta possibilidade.
Da mesma forma que um nome como www.cade.com.br é organizado na árvore no sentido
inverso, do mais geral (br), até o mais específico (www), os endereços IP também são organizados
no sentido inverso, como por exemplo, 1.250.135.200.in-addr.arpa, que representará o nome
correspondente ao endereço IP 200.135.250.1.
4.1 Configuração do Resolver
Toda máquina que utiliza o sistema DNS, independente de ser servidor DNS ou não, precisa
utilizar um resolver para traduzir consultas de nomes em endereços e endereços em nomes. O
resolver normalmente é uma biblioteca de funções ligada aos programas executáveis, como telnet,
ftp, etc.
No UNIX, a configuração do resolver é feita no arquivo /etc/resolv.conf .As cláusulas
permitidas no arquivo resolv.conf são:
16
Módulo Configuração de Redes TCP/IP
Curso Linux Básico
nameserver address: identifica o servidor do qual o resolver pode solicitar
informações sobre domínios. Mais de uma linha (normalmente
até 3) podem aparecer com a cláusula nameserver. Os
servidores são consultados na ordem em que eles aparecem
no arquivo. Se nenhuma reposta é obtida do primeiro, o
próximo é tentado e assim por diante;
domain domínio:
define o nome do domínio default. O resolver adiciona o
domínio default a todo nome de host que não contenha um
ponto no final. Após isto, ele usa este nome de host
expandido para fazer a consulta ao servidor de nomes;
search lista:
especifica uma lista de domínios que o resolver deve tentar
adicionar a nomes que não contenham um ponto no final.
Cada entrada da lista é tentada até que uma delas seja
encontrada, ou até que tenha sido esgotada.
O exemplo a seguir define o domínio minha.rede.com.br, com dois servidores de nomes, e
configura o resolver para tentar adicionar os domínios minha.rede.com.br e rede.com.br caso o
nome especificado nao termine com um ponto.
# cat /etc/resolv.conf
domain minha.rede.com.br
nameserver 200.135.250.1
nameserver 200.135.250.2
search minha.rede.com.br rede.com.br
4.2 Configuração do BIND
Um servidor DNS pode servir vários domínios. Quando necessário, um domínio pode ser
subdividido em subdomínios. A parte de um domínio pela qual um servidor é responsável é
chamada de zona. Considere o domínio a seguir, subdividido em três zonas:
raiz “.”
br
domínio “rede”
com
zona “rede”
rede
zona “minha”
minha
jurere
mole
joaca
Módulo Configuração de Redes TCP/IP
sua
fusca
www
bmw
zona “sua”
17
Curso Linux Básico
Neste exemplo, toda a Internet enxerga que o servidor responsável pelo domínio rede.com.br
é também responsável pelos subdomínios, pois terminam em rede.com.br. Entretanto, o servidor
deste domínio pode “delegar” um ramo da árvore de rede.com.br, como por exemplo,
minha.com.br a um outro servidor.
Assim, um servidor é na verdade responsável por uma ou mais zonas de um domínio. Às
vezes um servidor é responsável por todo o domínio, mas ainda assim é importante diferenciar o
conceito de domínio de zona.
Existem duas versões atualmente em uso do BIND: 4.x e 8.x. Os arquivos com as
informações sobre as zonas são idênticos em ambas as versões, mas o arquivo principal de
configuração que define quais as zonas de responsabilidade de um servidor possuem formato
diferente em cada versão, conforme a tabela a seguir:
/etc/named.boot (BIND 4.x)
directory caminho
cache . arquivo
primary zona arquivo
secondary zona servidor arquivo
forwarders servidor1 servidor2 …
slave
; Um comentário é precedido por
; um ponto-e-vírgula
18
/etc/named.conf
(BIND 8.x)
options {
directory “caminho”;
};
zone “.” {
type hint;
file “arquivo”;
};
zone “zona” {
type master;
file “arquivo”;
};
zone “zona” {
type slave;
file arquivo ;
masters {
servidor;
};
};
options {
forwarders {
servidor1;
servidor2;
…
};
};
options {
forward only;
};
// Um comentário é
// precedido por duas
// barras
Significado
Define um caminho de diretório onde os
demais arquivos serão armazenados
Especifica o arquivo de cache contendo a
lista de servidores do domínio “.” (raiz)
Configura o servidor como primário da zona
especificada, sendo que a base de dados está
armazenada em arquivo
Configura o servidor como secundário da
zona especificada, sendo especificado o
servidor primário de onde pegar a base de
dados, e gravando-a localmente no arquivo
especificado
Especifica uma lista de servidores
(servidor1, servidor2, …) para repassar o
pedido caso não consiga resolver o nome
com sua própria base de dados
Força o servidor a usar somente os
forwarders, sem tentar atender a nenhuma
solicitação
Comentários devem ser precedidos de
caracteres especiais. Deve-se evitar linhas
em branco, especialmente com o BIND 4.x
Módulo Configuração de Redes TCP/IP
Curso Linux Básico
Configuração exemplo de um servidor (named.boot):
# cat /etc/named.boot
; named.boot – BIND 4.x
directory
/var/named
cache
.
primary
0.0.127.in-addr.arpa
;
primary
rede.com.br
primary
250.135.200.in-addr.arpa
secondary
minha.rede.com.br
secondary
251.135.200.in-addr.arpa
;
forwarders
200.135.15.3 150.162.1.3
named.ca
named.local
rede.zone
rede.revzone
200.135.251.1
200.135.251.1
minha.zone
minha.revzone
Configuração exemplo de um servidor (named.conf):
# cat /etc/named.conf
// named.conf – BIND 8.x
options {
directory
“/var/named”;
forwarders {
200.135.15.3;
150.162.1.3;
};
};
zone “.” {
type hint;
file “named.ca”;
};
zone “0.0.127.in-addr.arpa” {
type master;
file “named.local”;
};
zone “rede.com.br” {
type master;
file “rede.zone”;
};
zone “250.135.200.in-addr.arpa” {
type master;
file “rede.revzone”;
};
zone “minha.rede.com.br” {
type slave;
file “minha.zone”;
masters {
200.135.251.1;
};
};
zone “251.135.200.in-addr.arpa” {
type slave;
file “minha.revzone”;
masters {
200.135.251.1;
};
};
Módulo Configuração de Redes TCP/IP
19
Curso Linux Básico
Os demais arquivos, que especificam as zonas, estão num formado padronizado. Cada arquivo
é na verdade um conjunto de Resource Records (RR), onde cada RR possui o seguinte formato:
[name] [ttl] [class] type data [;comment]
DESCRIÇÃO:
Os Resource Records são definidos na RFC 1033. Estes registros possuem a
seguinte estrutura:
name:
este é o nome do objeto do domínio que o Resource Record
referencia. Pode ser um host ou um domínio;
time-to-live. Define o tempo em segundos que a informação
contida neste Resource Record deve ser mantida em cache;
identifica o registro como sendo da classe INternet. Na
realidade, até hoje não foram criadas outras classes de
registros DNS;
identifica qual tipo de Resource o registro indica;
contém a informação específica para o tipo de Resource
Record declarado acima.
ttl:
IN:
type:
data:
A tabela a seguir mostra os registros padrões disponíveis no BIND:
Nome do RR
Tipo do Registro
Função
Start of Authority
SOA
Marca o início dos dados de uma zona, e define os
parâmetros que afetam a zona inteira.
Name Server
NS
Identifica o servidor de nome do domínio.
Address
A
Converte um nome de host em um endereço.
Pointer
PTR
Converte um endereço para um nome de host.
Mail Exchanger
MX
Identifica onde entregar o mail para um nome de
domínio dado.
Canonical Name
CNAME
Define um nome alternativo para o host.
Host Information
HINFO
Geralmente descreve o hardware e o sistema
operacional de um host.
Well Known Service
WKS
Anuncia os serviços de rede.
Text Information
TXT
Serve para o administrador inserir informações
adicionais sobre cada máquina
Um arquivo básico named.ca contém registros do tipo NS que nomeiam os servidores raiz.
Um exemplo é mostrado a seguir:
20
Módulo Configuração de Redes TCP/IP
Curso Linux Básico
# cat /var/named/named.ca
;
This file is made available by InterNIC registration services
;
under anonymous FTP as
;
file
/domain/named.root
;
on server
FTP.RS.INTERNIC.NET
.
3600000 IN NS
A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.
3600000
A
198.41.0.4
.
3600000
NS
B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.
3600000
A
128.9.0.107
.
3600000
NS
C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.
3600000
A
192.33.4.12
.
3600000
NS
D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.
3600000
A
128.8.10.90
.
3600000
NS
E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.
3600000
A
192.203.230.10
.
3600000
NS
F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.
3600000
A
192.5.5.241
.
3600000
NS
G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.
3600000
A
192.112.36.4
.
3600000
NS
H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.
3600000
A
128.63.2.53
.
3600000
NS
I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.
3600000
A
192.36.148.17
.
3600000
NS
J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.
3600000
A
198.41.0.10
.
3600000
NS
K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.
3600000
A
193.0.14.129
.
3600000
NS
L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.
3600000
A
198.32.64.12
.
3600000
NS
M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.
3600000
A
202.12.27.33
O arquivo named.local é utilizado para converter o endereço 127.0.0.1 (loopback) no nome
do localhost. Basicamente, o arquivo named.local é sempre o mesmo em qualquer servidor DNS,
apesar de ser possível expressar a mesma coisa de formas diferentes:
@
;
1
IN
SOA
IN
NS
localhost. root.localhost.
1997022700 ;
86400
;
7200
;
2592000
;
345600 )
;
localhost.
IN
PTR
localhost.
(
Serial
Refresh after 24 hours
Retry after 2 hours
Expire after 30 days
Minimum ttl of 4 days
Observe o caractere “@” no início do arquivo. Se olharmos para o formato de um RR, o
primeiro item define um nome de domínio ou host sobre o qual queremos definir um RR. O
caractere “@” especifica para utilizar o próprio domínio definido como “zona” no arquivo
/etc/named.boot ou /etc/named.conf. Quando o item “name” do RR não é definido em uma linha,
é assumido o valor definido no registro SOA.
O registro SOA define um conjunto de valores da zona sendo especificada:
• Na primeira linha temos o domínio específico desta zona, seguido do endereço de e-mail
Módulo Configuração de Redes TCP/IP
21
Curso Linux Básico
•
•
•
•
•
da pessoa responsável, apenas trocando o caractere especial “@” por um ponto “.”;
Serial: número de série do arquivo de zona. É importante incrementar este número
sempre que o arquivo for modificado, pois dessa forma os servidores secundários da zona
saberão que o arquivo foi alterado. A convenção AAAAMMDDNN, onde AAAA=ano,
MM=mês, DD=dia, e NN=número da alteração no dia, garante que o número de série
sempre será maior do que o anterior quando for modificado;
Refresh: intervalo em segundos que os servidores secundários devem verificar por
modificações no servidor primário;
Retry: intervalo em segundos que os servidores secundários devem esperar para tentar
novamente caso não tenham conseguida conexão para um Refresh;
Expire: tempo máximo de validade dos registros no servidor secundário, após não ter
conseguido atualizar sua cópia. Após este tempo decorrido sem atualização, o servidor
secundário deve parar de responder requisições para a zona;
Minimum: tempo default de ttl para os demais registros, quando especificado.
O arquivo de inicialização rede.revzone é similar ao arquivo named.local. Ambos os
arquivos traduzem endereços IP em nomes de hosts através de registros PTR, como pode-se ver no
exemplo:
@
IN
SOA
IN
;
1
2
3
4
IN
IN
IN
IN
250.135.200.in-addr.arpa. root.250.135.200.in-addr.arpa. (
1998072400 ; Serial
86400
; Refresh after 24 hours
7200
; Retry after 2 hours
2592000
; Expire after 30 days
345600 )
; Minimum ttl of 4 days
NS
ns.rede.com.br.
PTR
PTR
PTR
PTR
ns.rede.com.br.
www.rede.com.br.
ftp.rede.com.br.
mail.rede.com.br.
O arquivo de inicialização rede.zone contém a maioria das informações de domínio. Este
arquivo converte nomes de hosts em endereços IP, mas também contém registros dos tipos MX,
CNAME e outros.
22
Módulo Configuração de Redes TCP/IP
Curso Linux Básico
@
;
ns
IN
SOA
IN
IN
NS
MX
rede.com.br. root.rede.com.br. (
1998072400 ; Serial
86400
; Refresh after 24 hours
7200
; Retry after 2 hours
2592000
; Expire after 30 days
345600 )
; Minimum ttl of 4 days
ns.rede.com.br.
1 mail.rede.com.br.
IN
A
200.135.250.1
MX
1 mail.rede.com.br.
; Subdominios - delegation
minha
IN
NS
ns.minha.rede.com.br.
ns.minha IN
A
200.135.251.1
;
www
IN
A
200.135.250.2
MX
1 mail.rede.com.br.
ftp
IN
A
200.135.250.3
MX
1 mail.rede.com.br.
mail
IN
A
200.135.250.4
MX
1 mail.rede.com.br.
O comando nslookup é uma ótima ferramenta para localização de erros no servidor, pois
permite que qualquer um realize consultas diretamente ao servidor de nomes e recupere qualquer
$ nslookup www.rede.com.br
Server: ns.rede.com.br
Address: 200.135.250.1
Non-authoritative answer:
Name:
www.rede.com.br
Address: 200.135.250.2
uma das informações conhecidas pelo DNS. Ele pode ser usado diretamente na linha de comando
ou através do modo interativo. No modo direto, procede-se como no exemplo:
E no modo interativo:
Comandos úteis no modo interativo:
server server name muda o servidor DNS a ser questionado;
set type = type
muda o tipo (A, PTR, MX, NS, Any, etc) do registro pesquisado;
set domain=domain muda o nome do domínio pesquisado;
ls domain
recupera o arquivo de zonas do domínio;
exit
sai do modo interativo.
Módulo Configuração de Redes TCP/IP
23
Curso Linux Básico
$ nslookup
Default Server: ns.rede.com.br
Address: 200.135.250.1
> www.rede.com.br
Server: ns.rede.com.br
Address: 200.135.250.1
Non-authoritative answer:
Name:
www.rede.com.br
Address: 200.135.250.2
> set type=mx
> rede.com.br
Server: ns.rede.com.br
Address: 200.135.250.1
rede.com.br
preference = 1, mail exchanger = mail.rede.com.br
rede.com.br
nameserver = ns.rede.com.br
mail.rede.com.br
internet address = 200.135.250.4
ns.rede.com.br
internet address = 200.135.250.1
24
Módulo Configuração de Redes TCP/IP
Curso Linux Básico
5 NETWORK FILE SYSTEM (NFS)
O Network File System (NFS) permite o compartilhamento de arquivos através de uma rede.
Ele foi desenvolvido pela Sun Microsystems e hoje se encontra disponível em muitas plataformas,
sendo o padrão para compartilhamento de arquivos no ambiente UNIX. Existem soluções NFS para
ambientes como o MS-DOS e o MS-Windows, o que permite uma integração destes ambientes com
o UNIX.
Através do NFS, usuários e aplicações podem acessar arquivos remotos como se fossem
locais, de forma transparente.
As principais vantagens de se usar o NFS são:
• A possibilidade de se ter estações sem disco;
• Racionalização do uso dos discos, pois muitos softwares passam a residir exclusivamente
em um servidor;
• Manutenção centralizada dos arquivos do domínio;
• Transparência perante os usuários.
O NFS é constituído de processos servidores e clientes. Um host executando os processos
clientes do NFS acessa arquivos remotos como se fizessem parte do sistema de arquivos local. Um
host executando os processos servidores do NFS disponibiliza seus arquivos para uso pelos clientes.
Um cliente acessa arquivos remotos fazendo um “mount”, da mesma forma que acessa um
filesystem local em um disco, por exemplo. Um servidor disponibiliza seus arquivos através de um
“export”. Freqüentemente um host executa tanto os processos servidores quanto os clientes.
Os principais daemons envolvidos com o NFS são:
• nfsd: executado pelos servidores para atender às requisições de acesso aos arquivos feitas
pelos clientes;
• biod: executado pelos clientes (Block I/O Daemon);
• rpc.lockd: executado por clientes e servidores a fim de negociar o fornecimento de locks
para arquivos;
• rpc.statd: executado por clientes e servidores para monitorar o NFS; é utilizado para
reestabelecer a comunicação entre clientes e servidores após uma falha de rede;
• rpc.mountd: executado pelos servidores para atender as requisições de mount feitas
pelos clientes;
• rpc.rquotad: executado pelos servidores para fornecer informações sobre quotas de
usuários aos clientes que montam o filesystem exportado.
5.1 Exportando Arquivos
O primeiro passo na configuração de um servidor NFS é decidir quais arquivos serão
exportados. Exporte apenas os arquivos que realmente serão utilizados pelos clientes.
O controle de acesso remoto aos arquivos locais está associado aos diretórios e não aos
arquivos em particular. Portanto, não podemos exportar um arquivo de um diretório sem exportar os
demais.
O arquivo /etc/exports especifica quais diretórios são exportados pelo servidor, quais
clientes poderão acessá-los o que poderão fazer com os arquivos.
Módulo Configuração de Redes TCP/IP
25
Curso Linux Básico
Cada entrada no arquivo /etc/exports segue o formato:
diretório
[-opção] [,opção]
As principais opções são:
ro
os clientes não podem escrever nos arquivos (read-only);
rw = host [:host]:
permite que os usuários do(s) host(s) citado(s) escrevam no
arquivo;
root = host [: host]:
dá acesso de root aos usuários root de determinado(s)
host(s);
access = host [:host]: permite acesso somente a partir do(s) host(s) listado(s).
# cat /etc/exports
/usr
/usr/local
/usr/local/tmp
/usr/local/www
/var/spool/mail
/home/venus
-access=servidor1:servidor2
-access=servidor1:servidor2
-access=servidor1:servidor2
-access=servidor1:servidor2
-access=servidor1:servidor2
-access=servidor1:servidor2
|No Linux, um novo formato de arquivo é utilizado, que permite mais flexibilidade. Cada
entrada do arquivo /etc/exports no Linux segue o formato:
diretório
[host][(opção, [opção])] …
host:
um host pode ser especificado por seu endereço IP, pelo seu
nome
DNS,
por
uma
faixa
de
IPs
(ex:
200.30.40.0/255.255.255.0), ou por uma faixa de domínio (ex:
*.rede.com.br). Quando o campo host é vazio, o diretório é
exportado para qualquer host;
As principais opções são:
ro:
o diretório é exportado como read-only;
rw:
o diretório é exportado como read-write (isto é default);
noaccess:
informa que o diretório não deve ser exportado (útil para
exportar um diretório e não permitir acesso a um subdiretório
deste diretório);
no_root_squash: permite que o usuário root da máquina cliente acesse o
diretório montado remotamente com permissão de root.
/projects
/usr
/home/server2
/pub
/pub/private
proj*.rede.com.br(rw)
*.rede.com.br(ro) 10.1.2.0/255.255.255.0(rw)
server1(rw,no_root_squash)
(ro)
(noaccess)
O comando exportfs lê o arquivo /etc/exports a fim de exportar um diretório:
venus# exportfs /usr
venus# exportfs -a
26
Módulo Configuração de Redes TCP/IP
Curso Linux Básico
5.2 Montando Diretórios Remotos
Um cliente NFS pode acessar apenas os diretórios que lhe foram exportados. O comando
showmount verifica quais diretórios estão disponíveis ao cliente em um determinado servidor.
apolo$ showmount -e venus
export list for venus:
/pub/private
(everyone)
/pub
<anon clnt>
/home/server2
server1
/usr
10.1.2.3/255.255.255.0,*.rede.com.br
/projects
proj*.rede.com.br
O comando mount é utilizado pelos clientes para montar um diretório remoto:
mount - monta um sistema de arquivos.
SINOPSE:
mount [ -o options ] hostname:filesystem mount-point
ARGUMENTOS:
hostname:
filesystem:
mount-point:
nome do host servidor;
nome do diretório ou sub-diretório exportado pelo servidor;
nome do diretório local onde o diretório remoto será montado.
DESCRIÇÃO:
O comando mount permite que diretórios exportados por um servidor NFS sejam montados
localmente. Subdiretórios dos diretórios exportados também podem ser montados. Por exemplo, se
um servidor exporta o diretório /usr, um cliente pode decidir montar apenas o diretório /usr/man.
venus# mount apolo:/home/apolo /home/apolo
Quando se monta um diretório sobre um diretório não vazio, o conteúdo deste, apesar de não
ser visível, continua inalterado. Assim que o mount for desfeito o conteúdo original do diretório
volta a ser visível. O comando umount desmonta um diretório.
venus# umount /home/apolo
O arquivo /etc/fstab provê informações sobre os sistemas de arquivos a serem montados na
inicialização do sistema.
Módulo Configuração de Redes TCP/IP
27
Curso Linux Básico
6 SESSION MESSAGE BLOCK (SMB) – SAMBA
O protocolo SMB é um dos protocolos mais “populares” de compartilhamento de arquivos e
impressoras atualmente, principalmente no ambiente de microcomputadores. Com o sucesso do
sistema operacional Microsoft Windows, o uso do protocolo se tornou praticamente obrigatório nos
ambientes onde máquinas com este sistema operacional estão interligadas em rede.
O SMB é na verdade o protocolo utilizada pelo NetBIOS, um conjunto de serviços sobre o
protocolo SMB que foi padronizada por ocasião das primeiras experiências de ligar PCs em rede.
Assim, quanto o termo NetBIOS é usado, na verdade o protocolo que transporta os serviços de
compartilhamento de arquivos e impressoras é o SMB. Por isso os dois termos podem ser usados de
forma intercambiável.
O NetBIOS é um protocolo da camada de aplicação, e define que cada nó da rede possui um
nome de até 15 caracteres. Os dois serviços do NetBIOS, serviço de datagrama e serviço de nomes,
estão padronizados no RFC 1001 e RFC 1002, respectivamente.
O NetBIOS pode operar sobre os seguintes protocolos de transporte (de nível inferior à
aplicação): TCP/IP, NetBEUI, e SPX/IPX (da Novell). Enquanto o NetBEUI é apenas uma
implementação de NetBIOS direta sobre a subcamada LLC (padrão IEEE), os outros dois (TCP/IP e
SPX/IPX) são realmente protocolos de transporte/rede, em relação ao modelo OSI. A desvantagem
de utilizar NetBEUI é o que o protocolo exige que todas as máquinas estejam na mesma rede física
(porque não utiliza como transporte um protocolo que permita roteamento, como o IP).
Dessa forma, quando uma máquina utiliza NetBIOS sobre TCP/IP (NBT) ou NetBIOS sobre
IPX, é preciso uma forma de traduzir os nomes NetBIOS para os endereços IP ou IPX, conforme o
protocolo utilizado.
Os nomes NetBIOS podem ser de dois tipos: UNIQUE e GROUP. Toda máquina rodando
NetBIOS em uma rede deve possuir um nome único (UNIQUE), que não pertença a outra máquina
na rede. Se necessário, a máquina pode solicitar na rede um nome GROUP, ao qual várias máquinas
podem pertencer.
6.1 Resolução de Nomes NetBIOS
Como o NetBIOS utiliza nomes para identificar as máquinas, e os protocolos inferiores
utilizam endereços numéricos, uma forma de resolução de nomes é necessária. No caso de
NetBEUI, a tradução de nomes será diretamente para endereços físicos 802.3 (Ethernet). No caso de
IP, a tradução será de nomes para endereços IP (semelhante ao DNS), assim como no caso de IPX a
tradução será de nomes para endereços IPX (que são constituídos do endereço 802.3 mais um
prefixo que identifica a rede a que pertence a máquina).
A resolução de nomes NetBIOS pode ser feita de duas formas: por difusão (broadcast) ou por
requisição direta a um servidor de nomes (point-to-point).
Na resolução por broadcast, uma máquina simplesmente envia por difusão na rede um
anúncio do nome que deseja utilizar. Se não houver objeção por parte de outra máquina que já
esteja utilizando o nome, ela então o adota como sendo seu.
Quando a máquina deseja transmitir para outra, ela também envia por difusão uma pergunta
pelo nome destino. A máquina destino, escutando a requisição, responde com seu endereço, de
maneira muito semelhante ao protocolo ARP usado na camada de acesso à rede da arquitetura
TCP/IP.
28
Módulo Configuração de Redes TCP/IP
Curso Linux Básico
A implementação de um servidor de nomes, de acordo com a RFC 1001, é apenas possível
quando se utiliza NetBIOS sobre TCP/IP. A implementação de um servidor de nomes point-to-point
da Microsoft foi denominada WINS (Windows Internet Name Service).
A resolução de nomes NetBIOS através de um servidor WINS resolve o problema de excesso
de broadcasts na rede em decorrência da resolução de nomes. Quando uma máquina deseja registrar
seu nome, ela contacta o servidor WINS para isso. Desta forma, as máquinas da rede que não se
registrarem ao servidor WINS ficarão “invisíveis” pelas demais, quando consultarem o servidor
WINS.
O processo de registro de nomes das máquinas é feito assim que o protocolo entra no ar.
Quando a máquina é desligada, a máquina solicita a retirada do nome do servidor. Caso a máquina
seja desligada abruptamente, sem ter a oportunidade de retirar seu nome do registro, o servidor
WINS não terá como saber que o nome não está mais associado a uma máquina ativa.
Como o protocolo de transporte para o servidor WINS é o TCP/IP, máquinas espalhadas por
várias redes, inclusive interconectadas por uma WAN, conseguem se registrar e consultar o servidor
de nomes. É possível assim ter um único servidor de nomes na rede, onde todos podem obter
informações sobre os endereços das máquinas que rodam NetBIOS, de forma muito semelhante ao
DNS.
É possível existir mais de um servidor WINS na rede, de forma que a base de dados fique
replicada, e caso o servidor principal saia do ar, o servidor secundário assume a responsabilidade.
Além disso, o administrador da rede pode incluir entradas estáticas no servidor WINS, por exmeplo,
para máquinas servidoras da rede, já que estas normalmente não mudam de endereço IP e de nome.
6.2 Samba – Servidor e Cliente SMB
Atualmente, o protocolo nativo de compartilhamento de arquivos e impressoras na família de
sistemas operacionais Windows, da Microsoft, é o SMB. Isto abriu várias oportunidade de mercado
para desenvolvedores de soluções de conectividade entre plataformas. Por exemplo, vários
fornecedores comercializam implementações de NFS para Windows, de forma que os clientes
Windows de uma rede enxerguem os diretórios exportados via NFS em servidores UNIX.
Para integrar sistemas Windows e UNIX, uma outra abordagem é implementar o protocolo
SMB no lado UNIX. Diversos fornecedores independentes, bem como os próprios fornecedores de
UNIX possuem suas próprias soluções SMB para integração com máquinas Windows, sem
necessidade de adicionar software a elas. Esta solução talvez seja a melhor para integrar sistemas
UNIX e sistemas Windows, pois em geral as máquinas Windows existem em maior quantidade do
que as máquinas UNIX, e o fato de não ser necessária a instalação de software adicional no lado
Windows é uma grande vantagem.
Boa parte das implementações dos fornecedores de UNIX é simplesmente um acordo com a
Microsoft para licenciarem o código nativo do LanManager, que era antigamente a implementação
SMB da Microsoft para UNIX (por ocasião da Microsoft comercializar seu próprio UNIX, o
Xenix).
Entretanto, existe uma solução de domínio público (freeware), chamada Samba, que foi
desenvolvida incialmente por Andrew Tridgell em 1992 quando era um estudante de PhD na
Universidade Nacional Australiana, em Canberra, Austrália.
Apesar dos primeiros testes e início do desenvolvimento do Samba terem sido no SunOS, da
Sun Microsystems, o início de seu desenvolvimento mais sério foi sobre a plataforma Linux, sendo
Módulo Configuração de Redes TCP/IP
29
Curso Linux Básico
que atualmente já existem versões para diversas plataformas, inclusive não-UNIX, como: Linux,
SunOS, Solaris, SVR4, Ultrix, OSF1, AIX, BSDI, NetBSD, Sequent, HP-UX, SGI, FreeBSD,
NeXT, ISC, A/UX, SCO, Intergraph, Domain/OS, DGUX, QNX, NetWare, VMS, OS/2, Amiga, e
outros que eventualmente são incluídos na lista.
Todas as informações sobre o produto, downloads, FAQs, entre outros, está disponível no site
http://www.samba.org, além dos mirrors espalhados pelo globo. O primeiro passo é obter o
software, preferencialmente pré-compilado para o sistema operacional do servidor a ser utilizado.
Após instalado, sua configuração é limitada a apenas um arquivo de configuração, chamado
smb.conf, e geralmente encontrado sob o diretório /etc ou sob o diretório /usr/local/samba/lib.
Conforme a utilização dada ao servidor Samba, configurações adicionais incluirão criação de
diretórios de arquivos compartilhados, ajustes de permissões, etc.
6.2.1 Iniciando o Samba
O samba é composto de dois processos: smbd e nmbd. O primeiro é o servidor propriamente
dito, enquanto o segundo é responsável pela resolução de nomes (ou via broadcast ou via protocolo
WINS).
Preferencialmente, o samba deve ser inciado durante o boot do sistema, ficando disponível
para conexões assim que a máquina servidora estiver no ar. Este modo coloca os dois processos
para rodar como daemons. Entretanto, pode ser que em algumas situações não seja adequado o
samba estar todo o tempo rodando, pois é usado raramente, e a máquina possui pouca memória e
CPU disponível. Neste caso pode-se iniciar o samba via inetd, que escuta as requisições na rede
para vários serviços (telnet, ftp, talk) e dispara o servidor adequado assim que uma requisição
chegar pela rede.
SINOPSE:
smbd [ -D ] [ -d nível ]
nmbd [ -D ] [ -d nível ]
ARGUMENTOS:
-D:
-d nível:
inicia o processo como daemon. Caso esta opção não seja
especificada, o processo somente inicia se tiver sido chamado
pelo inetd;
especifica o nível de detalhes a ser armazenado no arquivo de
logs do sistema. O valor default é 3, a não ser que outro seja
especificado no arquivo de configuração smb.conf.
6.2.2 Configuração do arquivo smb.conf
A único arquivo de configuração necessário para o Samba é o smb.conf. A localização padrão
do arquivo depende dos parâmetros especificados no momento da compilação do programa.
O arquivo de configuração é orientado a linhas, sendo composto de seções, e dentro de cada
seção, parâmetros. Cada seção especifica um item compartilhado, normalmente chamado de
compartilhamento (share). Os parâmetros para cada share podem ser então especificados
individualmente. Caso seja necessário que uma linha de configuração continue na linha seguinte,
deve-se colocar o caractere “\” (barra invertida) no final da linha a ser continuada. Além disso, toda
30
Módulo Configuração de Redes TCP/IP
Curso Linux Básico
linha que começa com o caractere “#” ou “;” é considerada um comentário.
Dentro do arquivo, as seções são especificados por um nome entre colchetes. Não existe
limite no tamanho do nome do compartilhamento, que pode inclusive conter espaços, mas a
recomendação é que sejam utilizados no máximo 8 caracteres, sem espaços, para evitar problemas
futuros com alguns clientes de rede mais antigos (DOS, Windows for Workgroups, e até mesmo
Windows 95).
Existem também três seções especiais:
• [global]: parâmetros nesta seção aplicam-se ao servidor em si, ou definem valores default
para os outros compartilhamentos;
• [homes]: esta seção permite que usuários conectem-se diretamente a seus diretórios
home. O Samba automaticamente mapeia o compartilhamento [homes] para o login do
usuário que está conectando ao servidor;
• [printers]: a seção [printers] é um serviço automático, que lê o arquivo /etc/printcap (se
impressão estilo BSD estiver em uso), e apresenta todas as impressoras encontradas
automaticamente.
Os parâmetros são normalmente compostos de uma ou mais palavras, e são especificados no
formato:
• nome-do-parâmetro = valor
O valor de cada parâmetro pode ser de um dos seguintes tipos:
• string: uma seqüência qualquer de caracteres, como por exemplo o parâmetro que
especifica o nome do servidor: netbios name = Server1
• numérico: um número qualquer decimal, como por exemplo o parâmetro que especifica o
tamanho máximo do arquivo de logs, em Kbytes: max log size = 250
• booleano: um opção que especifica os valores verdadeiro ou falso. Estes valores podem
ser especificados como yes/no, true/false, ou 1/0. Como exemplo, a opção que informa se
o nmbd atuará com servidor WINS ou não: wins support = yes
Os principais parâmetros são especificados a seguir. À frente de cada nome de parâmetro
listado, é mostrado entre parênteses se o parâmetro se aplica à seção global (G), a
compartilhamentos (C) específicos. Quando um parâmetro que se aplica a compartilhamentos (C)
for encontrado na seção global, ele será interpretado como o valor default para este parâmetro
quando ele não for especificado em um determinado compartilhamento.
PARÂMETROS:
workgroup (G):
server string (G):
status (G):
wins support (G):
security (G):
parâmetro do tipo string que informa ao servidor a qual
workgroup / domínio pertence;
string que será mostrada como “comentário” ao lado do nome
do servidor em um cliente SMB;
parâmetro booleano que configura o servidor para fornecer
informações sobre seu status ou não;
parâmetro booleano que instrui o nmbd para atuar ou não
como um servidor WINS;
string que especifica o modelo de autenticação a ser utilizado
pelo servidor. No modo “share” a autenticação é como no
Windows 3.x/9x, ou seja, um compartilhamento possui uma
Módulo Configuração de Redes TCP/IP
31
Curso Linux Básico
senha simples para leitura e/ou escrita. No modo “user” a
autenticação é feita localmente no arquivo de usuários do UNIX
(passwd). No modo “server” a autenticação é feita repassada
para um servidor de autenticação Windows NT ou Samba;
password server (G): nome da máquina responsável por autenticação. Este
parâmetro só é válido se “security = server”;
share modes (G):
parâmetro booleano que habilita ou não locking em arquivos;
comment string (C): string de comentário para um compartilhamento;
path (C):
string que especifica o diretório que está sendo compartilhado;
browseable (C):
parâmetro booleano que especifica se o compartilhamento será
visível para o cliente (por exemplo, no Ambiente de Rede do
Win95);
public (C):
especifica se o compartilhamento requer que o usuário se
identifique e autentique;
writable (C):
se este parâmetro é true, compartilha em modo read-write;
read only (C):
se este parâmetro é true, compartilha em modo read-only. Este
parâmetro é um sinônimo para “writable”, apenas com o
significado invertido;
create mode (C):
modo numérico (usado pelo comando chmod) com o qual
novos arquivos serão criados;
valid users (C):
lista de usuários separados por vírgula que possuem direito de
conexão
ao
compartilhamento.
Grupos
podem
ser
especificados colocando-se um caractere “@” em frente ao
nome do grupo na lista;
invalid users (C):
lista de usuários separados por vírgula que NÃO possuem
direito de conexão ao compartilhamento. Grupos podem ser
especificados colocando-se um caractere “@” em frente ao
nome do grupo na lista;
write list (C):
lista de usuários separados por vírgula que possuem direto de
escrita no compartilhamento. Grupos podem ser especificados
colocando-se um caractere “@” em frente ao nome do grupo na
lista.
32
Módulo Configuração de Redes TCP/IP
Curso Linux Básico
EXEMPLO:
#==== Opcoes Globais ====
#
# Ultima alteracao: 24/07/98, Celso
[global]
# Opcoes gerais
workgroup = CURSO
server string = Samba Server
# Opcoes de impressao
printcap name = /etc/printcap
print command = lpr -h -r -P %p %s
lprm command = lprm -P %p %j; /usr/local/bin/lpreset /dev/lp1
load printers = yes
printing = bsd
# Opcoes de log
log file = /var/log/samba/log.%m
max log size = 50
# Opcoes de seguranca
hosts allow = 127. 10.0.0.
security = user
encrypt passwords = yes
smb passwd file = /etc/smbpasswd
guest ok = no
# Opcoes de rede / desempenho
socket options = TCP_NODELAY
;
interfaces = 192.168.12.2/24 192.168.13.2/24
# Controle de listas. Este servidor possuira’ a lista de maquinas da rede
os level = 33
domain master = yes
preferred master = yes
# Opcoes de controle de dominio. Este servidor atuara’ como um PDC
domain logons = yes
domain admin group = @celso
logon drive = x:
logon script = local.bat
logon path = \\%L\profiles\%U
# Suporte a WINS
wins support = yes
dns proxy = no
Módulo Configuração de Redes TCP/IP
33
Curso Linux Básico
# Convencoes de nomes de arquivos
preserve case = yes
short preserve case = yes
veto files = /lost+found/quota.user/quota.group/
#==== Definicoes de Compartilhamentos ====
[homes]
comment = Directorios dos Usuarios
browseable = no
writable = yes
[printers]
comment = Todas as impressoras
path = /var/spool/samba
browseable = no
guest ok = yes
writable = no
printable = yes
[FloppyA]
comment = Unidade de disquete
path = /misc/fd
browseable = yes
public = yes
writable = yes
guest ok = yes
[Temp]
comment = Espaco temporario
path = /tmp
browseable = yes
public = yes
writable = yes
guest ok = yes
Neste exemplo, os parâmetros em negrito são os parâmetros usuais em um arquivo de
configuração, que devem ser adaptados para cada caso específico (por ex,: parâmetro workgroup).
34
Módulo Configuração de Redes TCP/IP
Curso Linux Básico
7 NETWORK INFORMATION SERVICE (NIS)
Freqüentemente, em uma rede de computadores, é desejável que a autenticação de usuários
seja centralizada em servidores centrais de autenticação. Este modelo de segurança em redes é
adotado por vários produtos, por exemplo, a família Mirosoft Windows. Em UNIX, normalmente a
autenticação é feita localmente, consultando o arquivo /etc/passwd.
Entretanto, a Sun Microsystems definiu um padrão que serve, entre outras coisas, para este
propósito. Inicialmente o produto foi chamado de YP – Yellow Pages (Páginas Amarelas), pois
tratava-se de um mecanismo de distribuição centralizada de informações pelas estações da rede.
Entretanto YP era já uma marca registrada na Inglaterra, e a Sun rebatizou o produto de NIS –
Network Information Service (Serviço de Informações de Rede).
O NIS é um banco de dados administrativo utilizado para disseminar informações por todo o
domínio (note-se que o conceito de domínio aqui é diferente daquele do DNS. Um domínio NIS
está restrito a um conjunto de máquinas sob a mesma administração, e não se enquadra em uma
estrutura hierárquica, nem aceita subdivisões). O NIS converte uma série de arquivos
administrativos do UNIX em mapas disponíveis pela rede.
Os principais arquivos convertidos em mapas pelo NIS são:
• /etc/passwd : contém informações sobre usuários;
• /etc/group : contém informações sobre grupos de usuários;
• /etct/ethers: associa endereços IP a endereços físicos (usado pelo RARP);
• /etc/hosts: associa nomes de hosts a endereços IP;
• /etc/networks: associa nomes de redes a endereços IP;
• /etc/netmasks: associa netmasks às redes;
• /etc/protocols: contém protocolos suportados pelo host;
• /etc/services: contém serviços suportados pelo host;
• /etc/aliases: contém mail aliases;
• /etc/netgroup : define grupos de hosts e de usuários.
O principal motivo para se utilizar NIS é a facilidade administrativa. Com NIS, os arquivos de
configuração podem ser mantidos de forma centralizada em um servidor e disponibilizados
automaticamente pelo domínio.
Um conjunto de máquinas que compartilham os mesmos mapas do NIS formam um domínio
NIS. É recomendável que o nome de um domínio NIS coincida com o nome do domínio Internet. O
servidor NIS cria um sub-diretório para cada domínio que ele serve no diretório /var/yp.
O comando domainname define ou mostra o nome do domínio NIS corrente.
venus% domainname inf.ufsc.br
venus% domainname
inf.ufsc.br
O nome do domínio NIS é normalmente configurado na inicialização do sistema a partir do
arquivo /etc/defaultdomain. Este é o arquivo utilizado no SunOS e no Solaris durante o boot do
sistema para descobrir qual o domínio NIS em uso. Outros UNIX provavelmente irão armazenar o
nome do domínio NIS em outros locais.
Módulo Configuração de Redes TCP/IP
35
Curso Linux Básico
Os principais programas envolvidos com o NIS são:
• ypserv : daemon servidor do NIS, responsável pelo atendimento às requisições dos
clientes;
• ypbind: daemon cliente do NIS, responsável por encaminhar as requisições ao servidor;
• ypinit: programa de inicialização do NIS; lê os arquivos de /etc e cria os mapas
correspondentes. Este programa normalmente está no diretório /usr/lib/yp;
• ypxfrd: daemon responsável por transferir os mapas do servidor mestre para os
servidores escravos;
• yppasswdd: daemon responsável por receber notificações de alteração de senha de um
usuário em uma máquina cliente.
O NIS cria um mapa equivalente ao arquivo /etc/hosts. Logo, ele pode dispensar o uso do
DNS para domínios pequenos e isolados da Internet. Entretanto, alguns resolvers, quando
configurados para utilizar NIS, ignoram completamente a configuração DNS (/etc/resolv.conf) e
passam somente a consultar nomes no mapa hosts do domínio NIS. A solução é fazer com que o
servidor NIS, quando receba a consulta por um nome que não está em seu mapa hosts, consulte um
servidor DNS. Isto pode ser feito incluindo a cláusula “B=-b” no arquivo de construção dos mapas
NIS, localizado em /var/yp/Makefile.
venus# vi /var/yp/Makefile
# Set the following variable to "-b" to have NIS servers use the domain
# name resolver for hosts not in the current domain.
B=-b
Para garantir o funcionamento do serviço, o NIS define duas classes de servidores: master e
slave. Um domínio NIS deve possuir pelo menos um servidor master (mestre), e opcionamente
vários servidores slave (escravos), que obterão cópias dos mapas NIS a partir do servidor master.
Para inicializar o servidor mestre do domínio e criar os mapas iniciais, os seguintes passos
devem ser feitos:
• Configurar o domínio NIS com o comando domainname;
• Executar o comando ypinit –m. Este comando lerá os arquivos do diretório /etc e criará
os mapas correspondentes no diretório /var/yp/domainname, onde domainname é o
nome do domínio ajustado no passo anterior;
• Dispare os daemons necessários. O daemon ypserv é o servidor em si, portanto deve
sempre estar rodando no servidor. Se existem servidores slave que irão se conectar ao
servidor master, ele deve rodar também o daemon ypxfrd. Se os clientes precisarem
alterar senhas de usuários no servidor NIS, então o daemon yppasswdd também deve
ser executado. Por fim, a máquina servidora precisa também ser configurada como cliente
NIS, executando o ypbind.
babbage#
babbage#
babbage#
babbage#
babbage#
babbage#
domainname servers
/usr/lib/yp/ypinit –m
ypserv
ypxfrd
yppasswdd
ypbind
Para disparar um servidor slave os seguintes passos devem ser seguidos:
• Configurar o domínio NIS com o comando domainname;
36
Módulo Configuração de Redes TCP/IP
Curso Linux Básico
•
•
Executar o comando ypinit –s master. Este comando fará com que o servidor master
seja contactado, e seus mapas copiados;
Dispare os daemons necessários. O daemon ypserv é o servidor em si, portanto deve
sempre estar rodando no servidor. Por fim, a máquina servidora precisa também ser
configurada como cliente NIS, executando o ypbind.
pascal#
pascal#
pascal#
pascal#
domainname servers
/usr/lib/yp/ypinit –s babbage
ypserv
ypbind
Para disparar um cliente NIS, basta configurar o domínio NIS e disparar o daemon cliente:
hollerith# domainname servers
hollerith# ypbind
No servidor NIS mestre, toda vez que um dos arquivos exportados for alterado, é necessário
reconstruir o mapa correspondente. Para isso, é necessário executar o comando make dentro do
diretório /var/yp. O comando make irá reconstruir os mapas de acordo com as regras do arquivo
/var/yp/Makefile existente, deixando-os sincronizados com os arquivos originais. O exemplo a
seguir ilustra a situação.
babbage# cd /var/yp
babbage# make
gmake[1]: Entering directory `/var/yp/servers'
Updating passwd.byname...
Updating passwd.byuid...
Updating group.byname...
Updating group.bygid...
Updating hosts.byname...
Updating hosts.byaddr...
gmake[1]: Leaving directory `/var/yp/servers'
babbage#
Módulo Configuração de Redes TCP/IP
37
Curso Linux Básico
BIBLIOGRAFIA
1.
2.
3.
4.
5.
ALBITZ, Paul; LIU, Cricket. DNS and BIND. O’Reilly & Associates, 1992.
FEIT, Sidnie. TCP/IP – Architecture, Protocols, and Implementation with IP v6 and IP
Security. 2nd. ed. McGraw-Hill, 1996.
FRISCH, Ællen. Essential System Administration. 2nd. ed. O’Reilly & Associates, 1996.
HUNT, Craig. TCP/IP Network Administration. 2nd. ed. O’Reilly & Associates, 1997.
STERN, Hal. Managing NFS and NIS. O’Reilly & Associates, 1991.
Dúvidas, críticas e sugestões sobre esta apostila: mailto:[email protected]
38
Módulo Configuração de Redes TCP/IP