Embora TCP/IP trabalhe transparentemente para o usuário, ocasionalmente as comunicações parecem ser lentas e TCP/IP suspeita-se como a causa. A maior parte de usuários estão impacientes e esperam coisas a acontecer imediatamente, portanto os atrasos por qualquer razão levam à frustração. Em vez de sentar-se e esperar, a maior parte de usuários gostam de ser capazes de verificar que uma conexão a uma máquina remota é ativa e um atraso causa-se pelo tráfego de rede em vez de um fracasso de sistema. No mínimo, a maior parte de usuários gostariam de entender porque uma sessão progride lentamente.
TCP/IP tem vários programas de serviço que fornecem a informação sobre posição e a estatística de realização. Também disponível são vários programas de depuração e opções de permitir a um desenvolvedor ou usuário informado traçar um problema. Este capítulo examina o jogo básico destes instrumentos. Embora TCP/IP seja um padrão, há muitas implementações diferentes da família de protocolo. A maior parte de versões mandam discutir o toolset básico hoje, embora alguns pudessem alterar nomes e produção ao seu próprio gosto.
Todos os endereços de rede e os nomes de máquina neste capítulo escolhem-se a esmo e não representam nenhuma determinada rede. Como os endereços de rede usados poderiam corresponder a uma verdadeira rede, não deve usá-los em nenhuma experimentação, ou poderia incorrer a ira de um administrador de sistema!
Não todas as ordens mostradas neste capítulo estão disponíveis para usuários regulares (ao contrário de administradores de sistema) em todos os sistemas, embora alguns administradores de sistema realmente permitam algum acesso à utilidade para verificar a conexão e a posição TCP/IP. As ordens apresentam-se aqui para mostrar a depuração e capacidades diagnósticas disponíveis para o usuário TCP/IP e administrador. As ordens não são cobertas no detalhe exaustivo mas destinam-se para concluir o quadro TCP/IP para você. Muitos destes programas e utilidade veem-se novamente depois neste livro quando fundei uma rede de TCP/IP de mostra.
Vários arquivos implicam-se na especificação completa de endereços de rede e configuração de TCP/IP. Com objetivos ilustrativos, um sistema UNIX usa-se como o padrão aqui, embora alguns outros sistemas operacionais se mencionem como apropriados. Outros sistemas operacionais usam nomes de arquivo diferentes, mas o objetivo dos arquivos é normalmente o mesmo. Deveria conferir com a sua documentação de sistema operacional para identificar os arquivos usados com cada objetivo.
UNIX permite comentários sobre cada linha destes arquivos de configuração, enquanto se prefaciam por um sinal de libra (#). Se vir este caráter em arquivos de configuração do seu próprio sistema, deve observar que não é parte de uma entrada. Com muitos sistemas operacionais, os arquivos de configuração à revelia têm muitas entradas, a maioria das quais se comentam fora até que o administrador de sistema retire os comentários.
Não poderia ser capaz de examinar os arquivos ou dirigir a utilidade mencionada neste capítulo por causa de restrições de segurança. Se editar os arquivos de configuração, assegure-se que não faz nenhuma modificação desintencional! Faça apoios de todos os arquivos antes que faça qualquer modificação dos seus sistemas.
Sempre que um nome simbólico se use como um endereço de objetivo por uma aplicação, deve haver algum método para resolver que o nome em uma rede se dirige. Um arquivo ASCII usa-se comumente com os nomes simbólicos combinados para transmitir endereços em rede. Isto não se aplica quando as Páginas amarelas (YP), Network Information Services (NIS) ou Domain Name Server (DNS) se usam; usam os seus próprios arquivos de configuração.
Em sistemas UNIX, o arquivo/etc/hosts usa-se para manter os endereços de rede, bem como uma conexão especial chamou o laço de retorno (que se examina depois neste capítulo na seção intitulada "O Motorista de Laço de retorno"). O endereço de conexão de laço de retorno enumera-se normalmente como o laço de retorno de nome de máquina ou localhost.
O arquivo/etc/hosts compõe-se do endereço de rede em uma coluna separada do nome simbólico no outro. Os endereços de rede podem especificar-se no formato decimal, octal, ou hexadecimal (embora o decimal seja o mais comum). Mais de um nome simbólico pode especificar-se em uma linha separando os nomes com carateres espaciais ou com etiquetas. O arquivo/etc/hosts pode ser tão longo segundo a necessidade para conter todos os nomes simbólicos usados na máquina local; não precisam de apresentar-se em nenhuma ordem. Uma amostra UNIX/etc/hosts arquivo é como se segue:
# network host addresses 127.0.0.1 localhost local tpci_server 157.40.40.1 tpci_sco1 157.40.40.2 tpci_sco2 157.40.40.3 tpci_hpws1 157.40.40.0 tpci_server tpci_main tpci 47.80.157.36 bnr.ca BNR bnr 191.13.123.4 kitty_cat 205.150.89.1 roy_maclean big_roy 210.24.47.128 bobs_machine
Como pode ver, o arquivo compõe-se de duas colunas. A primeira coluna dá o endereço IP de uma máquina, e o segundo (separado por um ou vários carateres whitespace) dá o nome da máquina. Se vários nomes puderem usar-se para identificar a máquina remota, enumeram-se na mesma linha, separada por whitespace. Por exemplo, a máquina remota com o endereço IP 205.150.89.1 pode dirigir-se como roy_maclean ou big_roy. Sempre que daqueles nomes se use em uma ordem (como um FTP ou aplicação de Telnet), este arquivo usa-se para combinar ao endereço IP próprio.
Um sistema ou o administrador de rede podem atualizar o arquivo/etc/hosts em qualquer momento, e as modificações são eficazes imediatamente (portanto a máquina não tem de reiniciar-se para efetuar as modificações). Sempre que um nome simbólico se especifique por um usuário ou uma aplicação, o arquivo/etc/hosts sempre se procura primeiro um nome que combina, e o endereço próprio lê-se na mesma linha.
A maior parte de implementações TCP/IP em outras plataformas têm um tipo semelhante do arquivo para resolver endereços IP de nomes simbólicos. NetManage ChameleonNFS que corre em uma máquina do Windows 3.x, por exemplo, usa uma Mesa de Anfitrião para combinar com nomes e endereços IP. A Mesa de Anfitrião, mostrada na Figura 7.1, é uma parte dianteira gráfica a um arquivo equivalente a/etc/hosts em uma máquina UNIX.
A figura 7.1. ChameleonNFS usa uma Mesa de Anfitrião para combinar com nomes simbólicos e endereços IP.
As redes podem dirigir-se por um nome simbólico, como as máquinas são. Para resolver os nomes de rede, outro arquivo usa-se que contém o endereço de rede correspondente. Tipicamente, este arquivo muitas vezes não se acessa, porque poucos usuários querem dirigir uma rede inteira dentro da sua aplicação. O arquivo de resolução de nome de rede a maior parte de uso comum deve especificar o nome da rede local.
Os sistemas de UNIX normalmente usam o arquivo/etc/networks para especificar nomes de rede simbólicos. O formato do arquivo fornece uma rede nome simbólico, o seu endereço de rede e qualquer pseudônimo que poderia usar-se, no formato quase o mesmo como a mesa/etc/hosts se usa para máquinas específicas. Uma amostra/etc/networks arquivo mostra-se aqui:
# local network names tpci 146.1 tpci_network tpci_local bnr 47.80 BNR bnr.ca tmn 123.2.21 unique 89.123.23 UNIQUE sco 132.147 SCO loopback 127 localhost
O leiaute de arquivo/etc/networks é um pouco diferente de/etc/hosts nisto o nome de rede habitual dá-se na primeira coluna, seguida do endereço de rede IP, então qualquer pseudônimo.
A entrada última neste arquivo de exemplo dá o nome de laço de retorno. A primeira entrada especifica o nome de máquina local, o seu endereço de rede e qualquer variante de nome. Usando este arquivo, uma aplicação que quis conseguir a rede chamada ÚNICA pode usar aquele nome e deixar o sistema operacional resolver que à rede IP se dirige 89.123.23.
Muitas implementações de TCP/IP em outras plataformas não se incomodam com um arquivo de resolução de nome de rede como isto. A parte da razão é que o arquivo/etc/networks tem um pouco de uso em uma plataforma UNIX, e muitos sistemas operacionais de usuário único não necessitam o tipo da versatilidade que um sistema operacional multiusuário como UNIX deve fornecer a uma rede inteira.
Os números de protocolo usam-se para identificar o protocolo de transporte à máquina de recepção para permitir a descodificação própria da informação dentro do datagrama. Com TCP/IP, o número de protocolo é introduzido na cabeçada de Protocolo de Internet. Um arquivo de configuração usa-se normalmente para identificar todos os protocolos de transporte disponíveis no sistema e os seus respetivos números de protocolo.
Os sistemas de UNIX usam o arquivo/etc/protocols com esta finalidade. Normalmente, este arquivo não se modifica pelo administrador mas mantém-se pelo sistema e atualiza-se automaticamente como parte do procedimento de instalação quando o novo software TCP/IP ou os serviços se acrescentam. O arquivo/etc/protocols contém o nome de protocolo, o seu número e qualquer pseudônimo que poderia usar-se para aquele protocolo. Uma amostra/etc/protocols arquivo mostra-se aqui:
# # Internet (IP) protocols # ip 0 IP # internet protocol, pseudo protocol number icmp 1 ICMP # internet control message protocol igmp 2 IGMP # internet group management protocol ggp 3 GGP # gateway-gateway protocol tcp 6 TCP # transmission control protocol egp 8 EGP # Exterior-Gateway Protocol pup 12 PUP # PARC universal packet protocol udp 17 UDP # user datagram protocol hello 63 HELLO # HELLO Routing Protocol ospf 89 OSPF # Open Shortest Path First Routing Protocol
Neste arquivo/etc/protocols, o protocolo IP é o protocolo 0 destinado, e TCP é o protocolo 6. Os valores nesta mesa não devem modificar-se dos seus valores à revelia menos quando as condições de rede especiais entreguem o mandato a uma modificação. Se novo os serviços de TCP/IP acrescentam-se ao sistema UNIX no qual este arquivo reside, as novas entradas fazem-se a este arquivo pela rotina de instalação aplicada.
Não há normalmente equivalentes do arquivo/etc/protocols em outros sistemas operacionais porque supõem que o número de transporte padrão se use para cada protocolo.
O arquivo de configuração comum final usado na maior parte de sistemas UNIX identifica os serviços de rede existentes. Como com o arquivo/etc/protocols, este arquivo não se modifica normalmente por um administrador mas mantém-se pelo software como se instala ou se configura.
O arquivo de serviços de rede UNIX é/etc/services. O arquivo está no formato de ASCII composto do nome de serviço, um número de porto e o tipo de protocolo. O número de porto e o tipo de protocolo separam-se por um golpe. Os números de porto de TCP/IP normalmente seguem as convenções mencionadas nos capítulos anteriores. Qualquer nome de pseudônimo de serviço opcional segue depois dos números de porto. Um extrato curto de uma amostra/etc/services arquivo (o arquivo é normalmente bastante longo) mostra-se aqui:
# network services echo 7/tcp echo 7/udp discard 9/tcp sink null discard 9/udp sink null ftp 21/tcp telnet 23/tcp smtp 25/tcp mail mailx tftp 69/udp # specific services login 513/tcp who 513/udp whod
TCP/IP precisa que cada máquina na rede tenha um endereço IP. Normalmente, cada máquina também tem um nome simbólico único; de outra maneira, o endereço IP deve usar-se para todas as conexões àquela máquina. A maior parte de sistemas operacionais têm um programa simples que identifica o nome da máquina local. Os sistemas de UNIX têm a utilidade hostname com esta finalidade, bem como o programa uname, que pode dar o nome do nó com a ordem uname-n. A utilidade uname apoia-se normalmente em Sistema V e sistemas operacionais compatíveis só.
O nome do host salva-se às vezes em um arquivo separado que se lê quando o sistema operacional lança, ou pode ler-se em um dos arquivos de configuração mencionados anteriormente. O hostname usa-se pela maior parte de protocolos no sistema e por muitas aplicações TCP/IP, portanto é importante para a operação de sistema própria. O nome do host pode modificar-se às vezes editando o arquivo de sistema que contém o nome e logo reinicialização da máquina, embora muitos sistemas operacionais forneçam um programa de serviço para assegurar que este processo se executa corretamente.
Em muitos sistemas UNIX, o hostname e uname ordena o eco atrás o nome de máquina local, como as seguintes demonstrações de sessão de mostra:
$ hostname tpci_sco4.tpci.com $ uname -n tpci_sco4
No SCO UNIX sistema usado neste exemplo, a ordem de hostname devolve o nome de domínio totalmente qualificado, ao passo que a ordem de uname provê a máquina local só denominam. Em um CV-UX de gerência de estação de trabalho de Hewlett-Packard, ambas as ordens só devolvem o nome de máquina local. O comportamento exato do hostname e ordens de uname é, por isso, bastante dependente da implementação.
Em um sistema de Linux, por exemplo, a ordem de hostname pode acostumar-se a não só mostram a colocação de nome do host atual mas também modificá-lo quando usado com o-S (para o jogo) opção. Por exemplo, a ordem
hostname -S willow.tree.com
modifica o nome de domínio local totalmente qualificado para willow.tree.com. Não todas as versões de Linux apoiam a opção-S da ordem de hostname.
A maior parte de suites TCP/IP de outros sistemas operacionais usam um método mais simples de estabelecer o nome do host. Por exemplo, em uma máquina do Windows 3.x o pacote NetManage ChameleonNFS usa o diálogo mostrado na Figura 7.2 estabelecer rapidamente o nome do host.
A figura 7.2. ChameleonNFS usa este diálogo para estabelecer o nome do host.
O Windows NT tem serviços TCP/IP incorporados na distribuição básica. Em um sistema de Windows NT, o nome do host especifica-se por meio do diálogo de Rede aberto do Painel de controle, como mostrado na Figura 7.3. Tanto o Windows NT como os sistemas do Windows 3.x permitem a uma modificação no nome do host fazer-se eficaz imediatamente, embora uma reiniciação de sistema se recomende a compensar toda a informação sobre configuração mantida na memória.
A figura 7.3. Estabelecer o nome do host pelo Painel de controle de Rede de Windows NT.
Um problema potencial pode ocorrer quando a máquina local é multihomed, ou baseado em várias redes com um nome diferente e endereço IP de cada rede. O nome único no arquivo de configuração em tal instalação não poderia fornecer bastante informação para permitir o encaminhamento próprio sobre todas as redes ligadas. Este problema encontra-se raramente, mas realmente necessita que ao administrador de sistema estabeleça o hostname de cada rede cuidadosamente.
Além da pergunta de nome de máquina simples mostrada, o sistema hostname é um protocolo cheio que permite a acesso às mesas de Network Information Center (NIC) verificar endereços e obter a informação sobre a rede, portões e anfitriões. Usa o porto TCP número 101 para unir-se ao NIC. Este tipo do acesso restringe-se normalmente ao administrador de rede.
O motorista de laço de retorno é provavelmente o mais fundamental e muitas vezes usado diagnóstico disponível para um administrador. Um motorista de laço de retorno atua como um circuito virtual, permitindo a informação de saída reencaminhar-se imediatamente atrás a uma entrada. Isto permite testar dos circuitos da máquina eliminando qualquer influência externa, como a própria rede, portões ou máquinas remotas. Pela convenção, cada máquina usa o endereço IP 127.0.0.1 para o motorista de laço de retorno (também chamou o endereço IP localhost).
Cada sistema deve ter um motorista de laço de retorno no lugar se a máquina está em uma rede ou não. Isto é porque algumas aplicações insistem ter um endereço IP que podem acessar à função propriamente. Muitos servidores de licença em uma máquina UNIX têm esta exigência, por exemplo. Embora a necessidade de um motorista de laço de retorno não seja importante para Windows não-em rede e máquinas de sistema operacional semelhantes, um motorista de laço de retorno sempre se instala com uma suite TCP/IP.
Usando um driver de laço de retorno, um administrador pode estar seguro que a máquina local funciona propriamente e que qualquer fracasso é de além disso fora. Também, algumas aplicações insistem ter um endereço IP de motorista de laço de retorno para funcionar propriamente.
Os motoristas de laço de retorno são normalmente introduzidos como parte do núcleo de sistema operacional, ou às vezes como um programa de serviço de addon. A maior parte de sistemas multiusuários empregam um motorista de laço de retorno introduzido. UNIX é um bom exemplo: dentro do núcleo é um driver de dispositivo especificamente projetado para atuar como um motorista de laço de retorno. O motorista de laço de retorno sempre se acrescenta quase automaticamente quando o sistema operacional se instala, mas alguns sistemas operacionais baseados em UNIX, inclusive várias versões de Linux, não executam esta função, e o motorista de laço de retorno deve acrescentar-se manualmente pelo administrador de sistema. Como anteriormente mencionado, vários arquivos de configuração no sistema contêm o endereço da conexão do laço de retorno, como/etc/hosts.
Usando o driver de laço de retorno para reencaminhar a corrente de produção, dão volta ao cartão de interface de rede (normalmente um cartão de Ethernet). O motorista de laço de retorno é útil para testar instalações de software TCP/IP, porque imediatamente mostra qualquer problema com a configuração local. Isto pode fazer-se antes que a máquina se una fisicamente à rede ou até antes que o hardware de ligação em rede e o software se instalem. Por exemplo, pode usar o driver de laço de retorno para testar a sua configuração TCP/IP antes que se una a uma rede usando a ordem de silvo com o nome de localhost ou endereço IP, como as seguintes demonstrações de exemplo:
# ping -c5 localhost PING localhost (127.0.0.1): 56 data bytes 64 bytes from localhost (127.0.0.1): icmp_seq=0 ttl=64 time=10 ms 64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0 ms 64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0 ms 64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0 ms 64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0 ms --- localhost ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 0/2/10 ms # ping -c5 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes 64 bytes from localhost (127.0.0.1): icmp_seq=0 ttl=64 time=0 ms 64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0 ms 64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0 ms 64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0 ms 64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0 ms --- 127.0.0.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 0/0/0 ms
No exemplo precedente usei a ordem de silvo com a opção-c de especificar cinco silva, primeiro com o nome de localhost (que/etc/hosts resolve ao endereço IP 127.0.0.1) e logo com o próprio endereço IP. Se qualquer ordem tinha falhado, indicaria um problema com qualquer o arquivo/etc/hosts (se o nome localhost não pode resolver-se) ou com a instalação TCP/IP (se ambas as ordens falharam).
O programa arp dirige entradas nas mesas de Address Resolution Protocol (ARP) do sistema. Pode lembrar que ARP fornece a conexão entre o endereço IP e o endereço físico subjacente. Para mais informação, ver o Dia 2, "TCP/IP e a Internet".
Usando arp (ou o seu equivalente em outros sistemas operacionais), o administrador pode criar, modificar ou eliminar entradas na mesa ARP. Tipicamente, isto tem de executar-se sempre que o endereço de rede de uma máquina se modifique (por causa de uma modificação no hardware de rede ou por causa de um movimento físico).
O programa arp diferencia-se consideravelmente entre implementações e usa-se raramente por usuários, portanto os exemplos do seu uso se deixam à configuração do sistema operacional e documentação de administração.
O programa ifconfig ou um como ele, permite a um administrador ativar e desativar interfaces de rede, bem como configurá-los. O acesso ao programa ifconfig restringe-se geralmente ao administrador de rede ou um superusuário. As modificações da configuração só podem fazer-se normalmente antes que o sistema seja totalmente operacional (tal como no modo de usuário único em um sistema UNIX). Quando emitido, ifconfig essencialmente instrui a camada de rede do núcleo para trabalhar com o interface de rede especificado destinando um endereço IP, logo emitindo uma ordem de fazer a interface ativa no sistema. Só quando a interface é ativa pode o núcleo de sistema operacional enviar e receber dados pela interface.
O programa ifconfig permite a um administrador de rede executar várias funções úteis na maior parte de sistemas operacionais:
Ative ou desative uma interface
Ative ou desative ARP em uma interface
Ative ou desative o modo de depuração em uma interface
Destine um endereço de transmissão
Destine uma máscara de subrede
Destine um método de encaminhamento
Examinar todas as opções disponíveis para ifconfig necessitaria várias dúzias de páginas. Como este material se usa raramente e dissente com cada implementação, os administradores entregam-se à sua documentação de sistema operacional. Como um exemplo, a versão de Linux da ordem de ifconfig usa este formato geral:
ifconfig interface_type IP_Address
o interface_type é o nome de driver de dispositivo da interface (como lo do laço de retorno, ppp para PPP e eth de Ethernet), e IP_Address é o endereço IP usado por aquela interface.
Quando usado com só o nome de uma interface, ifconfig normalmente devolve a informação sobre o estado atual da interface, como mostrado no seguinte exemplo. Neste exemplo, uma pergunta de ambos um cartão de Ethernet (chamou ec0) e o motorista de laço de retorno (chamou lo0) executam-se. As bandeiras de posição da interface seguem-se do endereço de Internet, o endereço de transmissão, e opcionalmente uma máscara de rede, que define o endereço de Internet usado para a comparação de endereço quando encaminhamento.
tpci_sco1-12> ifconfig ec0
ec0: flags=807<UP,BROADCAST,DEBUG,ARP>
inet 146.8.12.15 netmask fffff00 broadcast
146.8.12.15
tpci_sco1-13> ifconfig lo0
lo0: flags=49<UP,LOOPBACK,RUNNING>
inet 127.0.0.1 netmask ff000000
O exemplo precedente mostra que a conexão de Ethernet ec0 é ativa, capaz de transmitir transmissões (TRANSMISSÃO) e está na depuração de modo (AJUSTE). Também, o protocolo ARP é ativo (ARP). Pode lembrar que uma mensagem de transmissão se envia a todas as máquinas na rede local estabelecendo o endereço de carteira de identidade de anfitrião a todos 1s.
Uma vez que a ordem de ifconfig dirigiu-se e uma interface é ativa, muitos sistemas operacionais necessitam que a ordem de via se emita para acrescentar ou retire vias na tabela de roteamento do núcleo. Isto é necessário para permitir à máquina local encontrar outras máquinas. O formato geral da ordem de via em um sistema de Linux ou UNIX é isto:
route add|del IP_Address
Acrescente ou del especifica-se para acrescentar ou retirar a via da tabela de roteamento do núcleo, e IP_Address é a via remota que se afeta.
Os conteúdos atuais da tabela de roteamento do núcleo podem expor-se em alguns sistemas entrando na via de ordem por si mesmo na linha de comando. Por exemplo, em um sistema de Linux que só se funda com o motorista de laço de retorno, vê uma produção como isto:
$ route Kernel Routing Table Destination Gateway Genmask Flags MSS Window Use Iface loopback * 255.0.0.0 U 1936 0 16 lo
As colunas importantes são o nome de destino, que mostra o nome do objetivo configurado (neste caso só laço de retorno), a máscara a usar-se (Genmask), e a interface (Iface, neste caso/dev/lo). Pode forçar a via a expor os endereços IP em vez de nomes simbólicos usando a opção-n:
$ route -n Kernel Routing Table Destination Gateway Genmask Flags MSS Window Use Iface 127.0.0.1 * 255.0.0.0 U 1936 0 16 lo
Não todas as versões de Linux e UNIX mostram este tipo da produção da ordem de via.
O uso do ifconfig e programas de via pode mostrar-se na organização de um sistema de Slackware Linux a conexão de Ethernet. Para fazer a interface de Ethernet ativa, a ordem de ifconfig emite-se com o nome de dispositivo de Ethernet (eth0 em um sistema de Slackware Linux) e o endereço IP local. Por exemplo, a ordem
ifconfig eth0 147.123.20.1
funda a máquina local com o Endereço IP 147.123.20.1. A interface é o dispositivo Ethernet/dev/eth0. A interface então pode verificar-se com a ordem de ifconfig usando o nome de interface:
$ ifconfig eth0
eth0 Link encap 10Mps: Ethernet Hwaddr
inet addr 147.123.20.1 Bcast 147.123.1.255 Mask 255.255.255.0
UP BROADCAST RUNNING MTU 1500 Metric 1
RX packets:0 errors:0 dropped:0 overruns:0
TX packets:0 errors:0 dropped:0 overruns:0
Pode notar na produção que o endereço de transmissão se estabeleceu baseado no endereço IP da máquina local. Isto usa-se por TCP/IP para acessar todas as máquinas na rede local ao mesmo tempo. O tamanho de Message Transfer Unit (MTU) estabelece-se normalmente no valor máximo de 1500 (para redes de Ethernet).
Depois, uma entrada acrescenta-se às tabelas de roteamento centrais para avisar o núcleo sobre o endereço de rede da máquina local. O endereço IP que se usa com a ordem de via não é o endereço IP da sua máquina local, mas aquela da rede no conjunto sem o identificador local. Para estabelecer o habitante local inteiro são rede ao mesmo tempo, o - a opção líquida da ordem de via usa-se. Em caso dos endereços IP mostrados antes, a ordem seria isto:
route add -net 147.123.20.0
Isto acrescenta que todas as máquinas na rede identificada pela rede se dirigem 147.123.20 à lista do núcleo de máquinas acessíveis. Um método alternativo deve usar o arquivo/etc/networks. Uma vez que a via acrescentou-se às tabelas de roteamento centrais, pode testar-se com a ordem de silvo.
O programa inetd é um remanescente dos primeiros dias de TCP/IP UNIX desenvolvimento. Quando uma máquina UNIX se começou, ativaria TCP/IP e imediatamente aceitaria conexões nos seus portos, criando um processo de cada um. Isto pode resultar em muitos processos idênticos, um para cada porto disponível.
Para controlar os processos melhor, o programa inetd desenvolveu-se para tratar as conexões de porto ele mesmo, desfazendo-se daquela tarefa do servidor. A diferença primária é que inetd cria um processo de cada conexão que se estabelece, ao passo que o servidor cria um processo de cada porto (que leva a muitos processos não usados).
Em muitos sistemas, alguns programas de prova e utilidade de informação de posição examinam-se inetd. Tipicamente, os serviços como eco, descarte, e tempo usam inetd.
O programa inetd usa um arquivo de configuração normalmente chamava/etc/inetd.cfg,/etc/inetd.conf, ou/etc/inetd.cf em sistemas UNIX. Um extrato de uma amostra/etc/inetd.cfg arquivo mostra-se no seguinte código:
# @(#)inetd.conf 5.2 Lachman System V STREAMS TCP source # # System V STREAMS TCP - Release 4.0 ftp stream tcp nowait NOLUID /etc/ftpd ftpd telnet stream tcp nowait NOLUID /etc/telnetd telnetd shell stream tcp nowait NOLUID /etc/rshd rshd login stream tcp nowait NOLUID /etc/rlogind rlogind exec stream tcp nowait NOLUID /etc/rexecd rexecd finger stream tcp nowait nouser /etc/fingerd fingerd comsat dgram udp wait root /etc/comsat comsat ntalk dgram udp wait root /etc/talkd talkd echo stream tcp nowait root internal discard stream tcp nowait root internal chargen stream tcp nowait root internal daytime stream tcp nowait root internal time stream tcp nowait root internal echo dgram udp wait root internal discard dgram udp wait root internal chargen dgram udp wait root internal daytime dgram udp wait root internal time dgram udp wait root internal
As colunas mostram o nome de serviço (que corresponde a uma entrada no arquivo de serviços, como/etc/services), o tipo de tomada (corrente, ferida ou datagrama), o nome de protocolo, se inetd pode aceitar novas conexões no mesmo porto imediatamente (nowait) ou deve esperar pelo servidor para terminar (espera), a senha de entrada que possui o serviço, o nome do programa de servidor e qualquer parâmetro opcional necessário para o programa de servidor.
O arquivo de configuração lê-se quando o servidor se inicializa e cada vez quando um sinal de desconexão recebe-se de uma aplicação. Isto permite modificações dinâmicas do arquivo, porque qualquer modificação se leria e o registro no seguinte arquivo lê-se.
O programa netstat ou uma utilidade semelhante fornecem a informação completa sobre o sistema local e a sua implementação TCP/IP. Isto é o programa o mais comumente usado por administradores para diagnosticar rapidamente um problema com TCP/IP. A informação real e o seu formato fornecido pela utilidade netstat dissentem com a implementação de sistema operacional, mas normalmente fornece aos seguintes sumários importantes, cada um dos quais é coberto mais detalhadamente depois:
Pontos finais de comunicações
Estatística de interface de rede
Informação sobre os buffers de dados
Informação sobre tabela de roteamento
Estatística de protocolo
Em alguns sistemas, a informação sobre as comunicações de interprocesso e outras pilhas de protocolo poderia acrescentar-se. A informação a expor-se pode ser normalmente toggled com uma opção de linha de comando. A produção de uma instalação UNIX típica que usa a ordem de netstat mostra-se nas seguintes poucas seções, que discutem netstat e a sua produção mais detalhadamente. A produção e a significação poderiam ser diferentes com outros sistemas operacionais, mas o objetivo geral do instrumento diagnóstico permanece o mesmo.
A ordem de netstat sem opções fornece a informação sobre todos os pontos finais de comunicações ativos. Para expor todos os pontos finais (ativo e passivo), o netstat usa a opção-a.
A produção formata-se em colunas mostrando o protocolo (Proto), o montante de dados em receber e envie filas (Recv-Q e Envie-Q), os endereços locais e remotos e o estado atual da conexão. Uma produção de mostra truncada mostra-se aqui:
$ netstat -a Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) ip 0 0 *.* *.* tcp 0 2124 tpci.login merlin.1034 ESTABL. tcp 0 0 tpci.1034 prudie.login ESTABL. tcp 11212 0 tpci.1035 treijs.1036 ESTABL. tcp 0 0 tpci.1021 reboc.1024 TIME_WAIT tcp 0 0 *.1028 *.* LISTEN tcp 0 0 *.* *.* CLOSED tcp 0 0 *.6000 *.* LISTEN tcp 0 0 *.listen *.* LISTEN tcp 0 0 *.1024 *.* LISTEN tcp 0 0 *.sunrpc *.* LISTEN tcp 0 0 *.smtp *.* LISTEN tcp 0 0 *.time *.* LISTEN tcp 0 0 *.echo *.* LISTEN tcp 0 0 *.finger *.* LISTEN tcp 0 0 *.exec *.* LISTEN tcp 0 0 *.telnet *.* LISTEN tcp 0 0 *.ftp *.* LISTEN tcp 0 0 *.* *.* CLOSED udp 0 0 *.60000 *.* udp 0 0 *.177 *.* udp 0 0 *.1039 *.* udp 0 0 *.1038 *.* udp 0 0 localhost.1036 localhost.syslog udp 0 0 *.1034 *.* udp 0 0 *.* *.* udp 0 0 *.1027 *.* udp 0 0 *.1026 *.* udp 0 0 *.sunrpc *.* udp 0 0 *.1025 *.* udp 0 0 *.time *.* udp 0 0 *.daytime *.* udp 0 0 *.chargen *.* udp 0 0 *.route *.* udp 0 0 *.* *.*
A produção mostrada para as ordens de netstat nesta seção é de um SCO UNIX sistema. Cada implementação de netstat é ligeiramente diferente, portanto as colunas de produção poderiam modificar-se, e as opções diferentes poderiam ser necessárias para obter cada tipo do relatório. Confira com a sua documentação de sistema de mais detalhes sobre a sua implementação netstat.
No exemplo precedente, há três conexões TCP ativas, como identificado pelo ESTABL estatal. Cada um tem dados que se enviam (como mostrado na coluna Send-Q), e o outro tem dados de entrada na fila. Os nomes de rede e os números de porto dos fins de conexão mostram-se sempre que possível. Um asterisco (*) meios lá não é nenhum ponto final associado com aquele endereço ainda.
Uma conexão espera para pendurar-se, identificar-se por TIME_WAIT na coluna estatal. Depois de 30 segundos, estas sessões terminam-se e a conexão liberta-se. Qualquer linha com ESCUTA como o estado não tem conexão no momento atual e espera. Não há coluna estatal de sessões UDP porque não têm uma conexão de um extremo a outro (como discutido no Dia 5, "Portão e Protocolos de Encaminhamento"). Uma entrada FECHADA na produção mostra que a conexão se fecha mas não ligou ainda para ESCUTAR.
O comportamento do interface de rede (como o cartão de interface de rede) pode determinar-se com a opção-i à ordem de netstat. Esta informação rapidamente mostra a um administrador se há problemas principais com a conexão de rede.
O netstat-i ordem expõe o nome da interface, o número máximo de carateres um pacote pode conter (Mtu), a rede e apresentar endereços ou nomes, número de pacotes de entrada (Ipkts), introduzir erros (Ierrs), pacotes de produção (Opkts), erros de produção (Oerrs) e número de choques (Collis) experimentado na sessão de amostragem atual. A coluna de choques tem a relevância só de um sistema de ligação em rede que permite choques de pacote, como Ethernet. Uma produção de mostra de um netstat-i ordem mostra-se aqui:
$ netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Collis ec0 1500 tpci merlin 34 0 125 0 0 lan0 1497 47.80 tpci_hpws4 11625 0 11625 0 0 lo0 8232 loopback localhost 206 0 206 0 0
Um administrador pode obter a informação mais específica sobre uma interface usando a opção-I com um nome de dispositivo e um intervalo de tempo, especificado durante segundos, como netstat-I ec0 30 para obter a informação específica sobre o comportamento da interface de ec0 (Ethernet) durante 30 últimos segundos.
A informação sobre os buffers de dados pode obter-se com a opção-m da ordem netstat. Controlar o comportamento dos buffers é importante, porque diretamente comprimem a realização de TCP/IP. A produção do netstat-m ordem diferencia-se dependendo da versão de UNIX no uso, refletindo as implementações diferentes do código de TCP/IP.
O netstat-m produção de ordem de um Sistema versão UNIX baseada em V mostra-se no seguinte exemplo de código. As entradas fornecem-se para o streamhead, fila, mesa descritiva de mensagem (mblks), mesa descritiva de dados (dblks) e as classes diferentes de mesas descritivas de dados. As colunas mostram que o número de blocos configurou (config) e atualmente alocou (alloc), o número de colunas livres (livre), o número total de blocos no uso (total), o número máximo de blocos que estiveram no uso um dia (máximo) e o número de vezes um bloco não esteve disponível (falham).
$ netstat -m
streams allocation:
config alloc free total max fail
streams 292 79 213 233 80 0
queues 1424 362 1062 516 368 0
mblks 5067 196 4871 3957 206 0
dblks 4054 196 3858 3957 206 0
class 0, 4 bytes 652 50 602 489 53 0
class 1, 16 bytes 652 2 650 408 4 0
class 2, 64 bytes 768 6 762 2720 14 0
class 3, 128 bytes 872 105 767 226 107 0
class 4, 256 bytes 548 21 527 36 22 0
class 5, 512 bytes 324 12 312 32 13 0
class 6, 1024 bytes 107 0 107 1 1 0
class 7, 2048 bytes 90 0 90 7 1 0
class 8, 4096 bytes 41 0 41 38 1 0
total configured streams memory: 1166.73KB
streams memory in use: 44.78KB
maximum streams memory used: 58.57KB
Para o administrador, a coluna de fracasso é importante. Sempre deve mostrar 0s. Se um número maior aparecer, aquele recurso sobretaxou-se e o número de blocos destinados àquele recurso deve aumentar-se (seguido de um núcleo reedificam e uma reiniciação do sistema para efetuar as modificações).
As tabelas de roteamento atualizam-se constantemente para refletir conexões a outras máquinas. Para obter a informação sobre as tabelas de roteamento, o netstat-r e as opções-rs usam-se. (O último gera a estatística sobre as tabelas de roteamento.)
A produção de netstat-r e netstat-rs ordens mostra-se no seguinte exemplo de código. As colunas mostram a máquina de destino, o endereço do portão a usar-se, uma bandeira para mostrar se a via é ativa (U) e se leva a um portão ou uma máquina (H para o anfitrião), um balcão de referência (Refs) que especifica quantas conexões ativas podem usar aquela via simultaneamente, o número de pacotes que se enviaram sobre a via (Uso) e o nome de interface.
$ netstat -r
Routing tables
Destination Gateway Flags Refs Use Interface
localhost localhost UH 4 10 lo0
merlin localhost UH 2 2 ec0
treijs hoytgate UG 0 0 ec0
47.80 bcarh736 U 12 21029 lan0
tpci sco4-57> netstat -rs
routing:
0 bad routing redirects
0 dynamically created routes
0 new gateways found unreachable
2 destinations found unreachable
122 uses of a wildcard route
0 routes marked doutbful
0 routes cleared of being doubtful
0 routes deleted
A estatística sobre o comportamento total de protocolos de rede pode obter-se com o netstat-s ordem. Isto normalmente fornece sumários para IP, ICMP, TCP e UDP. A produção desta ordem é útil para determinar onde um erro em um pacote recebido se localizou, que então leva o usuário a isolar se aquele erro se causou pelo problema de rede ou um software.
Emitir o netstat-s ordem fornece uma produção verbosa. Uma produção de mostra mostra-se no seguinte código. As entradas são evidentes.
tpci_sco4-67> netstat -s
ip:
183309 total packets received
0 bad header checksums
0 with size smaller than minimum
0 with data size < data length
0 with header length < data size
0 with data length < header length
0 with unknown protocol
13477 fragments received
0 fragments dropped (dup or out of space)
0 fragments dropped after timeout
0 packets reassembled
0 packets forwarded
0 packets not forwardable
75 no routes
0 redirects sent
0 system errors during input
309 packets delivered
309 total packets sent
0 system errors during output
0 packets fragmented
0 packets not fragmentable
0 fragments created
icmp:
1768 calls to icmp_error
0 errors not generated because old message was icmp
Output histogram:
destination unreachable: 136
0 messages with bad code fields
0 messages < minimum length
0 bad checksums
0 messages with bad length
Input histogram:
destination unreachable: 68
0 message responses generated
68 messages received
68 messages sent
0 system errors during output
tcp:
9019 packets sent
6464 data packets (1137192 bytes)
4 data packets (4218 bytes) retransmitted
1670 ack-only packets (918 delayed)
0 URG only packets
0 window probe packets
163 window update packets
718 control packets
24 resets
9693 packets received
4927 acks (for 74637 bytes)
37 duplicate acks
0 acks for unsent data
5333 packets (1405271 bytes) received in-sequence
23 completely duplicate packets (28534 bytes)
0 packets with some dup. data (0 bytes duped)
38 out-of-order packets (5876 bytes)
0 packets (0 bytes) of data after window
0 window probes
134 window update packets
0 packets received after close
0 discarded for bad checksums
0 discarded for bad header offset fields
0 discarded because packet too short
0 system errors encountered during processing
224 connection requests
130 connection accepts
687 connections established (including accepts)
655 connections closed (including 0 drops)
24 embryonic connections dropped
0 failed connect and accept requests
0 resets received while established
5519 segments updated rtt (of 5624 attempts)
5 retransmit timeouts
0 connections dropped by rexmit timeout
0 persist timeouts
0 keepalive timeouts
0 keepalive probes sent
0 connections dropped by keepalive
0 connections lingered
0 linger timers expired
0 linger timers cancelled
0 linger timers aborted by signal
udp:
0 incomplete headers
0 bad data length fields
0 bad checksums
68 bad ports
125 input packets delivered
0 system errors during input
268 packets sent
O silvo (Internet de Pacote Groper) a utilidade usa-se para questionar outro sistema para assegurar que uma conexão ainda é ativa. (Pode lembrar a utilidade ruptime de ontem, que também faz isto. Contudo, o ruptime espera cinco minutos antes de tentar o remoto, e pode querer saber imediatamente se a conexão é ativa.) A ordem de silvo está disponível na maior parte de sistemas operacionais aquele instrumento TCP/IP.
O programa de silvo funciona distribuindo um pedido de eco de Internet Control Message Protocol (ICMP). Se o software IP de máquina de destino receber o pedido de ICMP, emite uma resposta de eco imediatamente. A máquina de envio continua enviando um pedido de eco até que o programa de silvo se termine com uma sequência de intervalo (Ctrl+C ou a chave Eliminar em UNIX). Depois da terminação, o silvo expõe o grupo de estatística. Uma sessão de silvo de mostra mostra-se aqui:
$ ping merlin PING merlin: 64 data bytes 64 bytes from 142.12.130.12: icmp_seq=0. time=20. ms 64 bytes from 142.12.130.12: icmp_seq=1. time=10. ms 64 bytes from 142.12.130.12: icmp_seq=2. time=10. ms 64 bytes from 142.12.130.12: icmp_seq=3. time=20. ms 64 bytes from 142.12.130.12: icmp_seq=4. time=10. ms 64 bytes from 142.12.130.12: icmp_seq=5. time=10. ms 64 bytes from 142.12.130.12: icmp_seq=6. time=10. ms --- merling PING Statistics --- 7 packets transmitted, 7 packets received, 0% packet loss round-trip (ms) min/avg/max = 10/12/20
Um método alternativo para invocar o silvo deve fornecer o número de vezes quer que ele questione o remoto. Também, pode fornecer um comprimento de pacote como um teste. O seguinte exemplo instrui o silvo para usar 256 pacotes de byte de dados e tentar cinco vezes. Usar silvo para enviar grandes pacotes é um método de determinar o comportamento da rede com grandes tamanhos de pacote, sobretudo quando a fragmentação deve ocorrer. O programa de silvo também é útil para controlar tempos de resposta da rede, observando o tempo de resposta sobre pacotes enviados como a carga de rede (ou a carga de máquina) modificações. Esta informação pode ser muito útil na otimização de TCP/IP.
$ ping merlin 256 5 PING merlin: 256 data bytes 256 bytes from 142.12.130.12: icmp_seq=0. time=20. ms 256 bytes from 142.12.130.12: icmp_seq=1. time=10. ms 256 bytes from 142.12.130.12: icmp_seq=2. time=10. ms 256 bytes from 142.12.130.12: icmp_seq=3. time=20. ms 256 bytes from 142.12.130.12: icmp_seq=4. time=10. ms --- merling PING Statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip (ms) min/avg/max = 10/13/20
Algumas mais velhas implementações do silvo simplesmente respondem com uma mensagem que o sistema em outro fim é ativo. (A mensagem é da forma X está vivo.) Para obter as mensagens verbosas mostradas anteriormente, a opção-s deve usar-se.
O programa de silvo é útil para a diagnóstica porque fornece quatro partes importantes da informação: se o software TCP/IP funciona corretamente; se um dispositivo de rede local pode dirigir-se (validação do seu endereço); se uma máquina remota pode acessar-se (novamente validação do endereço e prova do encaminhamento); e verificar o software na máquina remota.
A maior parte de non-UNIX TCP/IP implementações fornecem a utilidade de silvo como parte da sua suite. Por exemplo, a Figura 7.4 mostra a utilidade de silvo de NetManage ChameleonNFS. O silvo de Cameleão envia só um pacote ICMP único em vez de uma corrente contínua, mas é útil para verificar que uma máquina remota responde.
A figura 7.4. ChameleonNFS usa uma utilidade de silvo para enviar um pacote único.
O Windows 95 manda incorporar uma utilidade de silvo no software de distribuição, mas é baseado no DOS e não usa o Windows 95 GUI. A figura 7.5 mostra que a utilidade de silvo do Windows 95 costumou silvar outra máquina na rede.
A figura 7.5. A utilidade de silvo do Windows 95 é baseada no DOS.
Há uma opção de investigação incorporada em TCP/IP. Quando os métodos mais simples falharam, esta opção pode usar-se para traçar um problema. Para ativar o traço, uma chamada de sistema envia-se ao ponto final que acende uma bandeira. A maior parte de implementações TCP/IP permitem à opção de investigação acender-se da linha de comando usando o-d (ajuste) opção. Quando a investigação se acende, todas as atividades ecoam-se a um buffer ou à tela, dependendo da configuração de sistema.
A produção do TCP/IP investigação de opção examina-se usando o programa trpt (relatório de traço). Uma conexão específica pode especificar-se, ou todo o comportamento que passa por TCP/IP pode expor-se. A produção de trpt é verbosa e de um pouco de interesse à maior parte de usuários.
Este capítulo mostrou-lhe os programas de administração básicos usados com TCP/IP, bem como os arquivos de configuração que são necessários para usar nomes simbólicos. Embora esta informação provavelmente não se use pela maior parte de usuários, saber os instrumentos disponíveis e o tipo da diagnóstica que pode produzir-se é útil na melhor compreensão TCP/IP.
Todos os protocolos TCP/IP disponíveis para você enumeram-se em um arquivo de configuração de sistema. Que arquivo é isto?
Todos os protocolos TCP/IP enumeram-se em protocolos/etc/. O arquivo enumera o nome de protocolo e o número de protocolo correspondente.
Para que um driver de laço de retorno se usa?
O motorista de laço de retorno é um circuito virtual dentro da máquina de anfitrião, evitando todo o contato com a própria rede física. A maior parte de uso comum de um motorista de laço de retorno é como um diagnóstico. Enviando dados ao motorista de laço de retorno, pode assegurar-se que os protocolos trabalham corretamente na sua máquina. Sem esta capacidade, seria difícil separar problemas de rede e problemas de configuração de software.
O que o seguinte extrai de um netstat-a ordem dizem-lhe?
Proto Recv-Q Send-Q Local Address Foreign Address (state) ip 0 0 *.* *.* tcp 0 1024 tpci.login merlin.1034 ESTABL. tcp 8756 0 tpci.1035 treijs.1036 ESTABL. tcp 0 0 tpci.1021 reboc.1024 TIME_WAIT tcp 0 0 *.1028 *.* LISTEN tcp 0 0 *.6000 *.* LISTEN
Este extrato mostra que há dois estabeleceu conexões TCP (a merlin.1034 e treijs.1036), um dos quais envia a informação e outra recepção. A conexão a reboc.1024 espera para pendurar. Há dois portos que esperam por uma conexão.
Para que o silvo de serviço se usa?
A utilidade de silvo usa-se para questionar outro sistema. Envia uma mensagem ICMP ao remoto e espera por uma resposta. A ordem de silvo é muito útil para testar conexões.
Que ordem lhe dá em geral a estatística sobre os protocolos de rede que correm no seu sistema?
Um dos melhores sumários obtém-se com o netstat-s ordem.
