Bloqueando FACEBOOK e outras redes sociais no RouterOS – Mikrotik

 Clusterweb, ClusterWeb, Firewall, Leitura Recomendada, Mikrotik, Profissional de TI, Redes, Segurança  Comentários desativados em Bloqueando FACEBOOK e outras redes sociais no RouterOS – Mikrotik
jun 032018
 

O bloqueio apesar de simples pode ser usando para qualquer site, já que é feito usado uma determinada string e portas de conexão.

O que fazemos é criar um regra de Layer7, contendo a string (REGEXP) com o nome que desejamos bloquear.

Após criar as regra de Layer7, crie uma regra de FORWARD bloqueando todos os pacotes que satisfazerem essa L7 nas portas 80(http) e 443(https).

Caso queira bloquear o próprio facebook, basta copiar e colar as regras no terminal do Mikrotik, lembrando que pode ser alterado a string (regexp) para “twitter” por exemplo.

1
/ip firewall layer7-protocol add name=facebook regexp=facebook
1
2
/ip firewall filter add action=drop chain=forward comment="facebook" \
disabled=no dst-port=80,443 layer7-protocol=facebook protocol=tcp

MySQL Workbench no Slackware 14.0

 Clusterweb, Linux, Redes  Comentários desativados em MySQL Workbench no Slackware 14.0
fev 262013
 

Introdução

O MySQL Workbench é uma ferramenta visual unificada para arquitetos de banco de dados, desenvolvedores e DBAs. Ela oferece recursos para modelagem de dados, desenvolvimento de Scripts SQL, administração do servidor, entre outros.

Neste artigo, passarei um pouco da experiência e problemas que tive ao instalar e executar esta ferramenta no Slackware 14.0 (64 bits).

A instalação do MySQL Workbench no Slackware é totalmente manual, portanto, vamos ter que começar pelas suas dependências.

As dependências necessárias são:

  1. libsigc++-2.2.10;
  2. glibmm-2.32.1;
  3. cairomm-1.10.0;
  4. pangomm-2.28.4;
  5. atkmm-2.22.6;
  6. gtkmm-2.24.2;
  7. lua-5.1.5;
  8. ctemplate-2.2.

Todas as dependências acima foram baixadas do SlackBuilds, facilitando bastante o processo de instalação.

A instalação de um pacote do SlackBuilds é bastante simples, sendo necessário apenas baixar os scripts de instalação (SlackBuild) e o respectivo código fonte. Para exemplificar, vamos instalar, passo a passo, a primeira dependência da lista (libsigc++-2.2.10):

Passo 1: Baixar o SlackBuild “libsigc++.tar.gz” e o código fonte “libsigc++-2.2.10.tar.xz” em um diretório de sua preferência. No meu caso, os salvei em /usr/local/src.

Passo 2: Descompactar o pacote do SlackBuild:

# tar -zxvf libsigc++.tar.gz

Passo 3: Mover o código fonte do “libsigc++” para a pasta descompactada do SlackBuild:

# mv libsigc++-2.2.10.tar.xz libsigc++

Passo 4: Entrar na pasta do SlackBuild:

# cd libsigc++

Passo 5: Executar o script: “libsigc++.SlackBuild”

# ./libsigc++.SlackBuild

Ao final deste processo, o “libsigc++.SlackBuild” irá gerar um arquivo “.tgz” no diretório /tmp.

Passo 6: Entrar no diretório /tmp e instalar o pacote “.tgz” gerado:

# cd /tmp
# installpkg libsigc++-2.2.10-x86_64-1_SBo.tgz

* É importante ressaltar: O SlackBuild não resolve dependências, portanto, será necessário instalar as dependências na ordem nas quais foram colocadas acima, para evitarmos este tipo de problema.

Instalação do MySQL Workbench

Após instalar todas as dependências, vamos baixar e instalar o MySQL Workbench. Para baixá-lo, acesse:

Selecione a opção “Source Code” em “Select Platform”, e em seguida, a opção “Generic Linux“.

Salve o arquivo “mysql-workbench-gpl-5.2.46-src.tar.gz” em um diretório de sua preferência. No meu caso, o salvei em /usr/local/src.

A instalação do MySQL Workbench é muito simples, basta seguir o roteiro padrão (./configure, make, make install e make clean):

# tar -zxvf mysql-workbench-gpl-5.2.46-src.tar.gz
# cd mysql-workbench-gpl-5.2.46-src
# ./configure
# make

Neste momento, tive o primeiro problema ao compilar. Estava gerando um erro do tipo:

libtool: compile: cannot determine name of library object from `’: command not found

Caso você tenha este problema, basta executar o comando autoreconf e, em seguida, o comando de compilação novamente:

# autoreconf -fi
# make
# make install

O comando autoreconf -fi irá refazer todos os scripts de configuração, incluindo qualquer arquivo que esteja faltando no pacote.

Por padrão, o comando make install instala os pacotes de comando em /usr/local/bin, arquivos include em /usr/local/include etc.

Você poderá especificar outro local de instalação usando a opção –prefix=PREFIX na hora de executar o ./configure.

Por fim, para executar o MySQL Workbench:

# usr/local/bin/mysql-workbench

Com o MySQL Workbench aberto, selecione a opção “New Connection”, entre com o usuário e senha do MySQL e execute a opção “Test Connection”.

Aqui, tive um novo problema: Não conseguia estabelecer uma conexão SSH com o MySQL e no log do Workbench dizia que ele não conseguia importar o módulo paramiko.

Para resolver este problema, basta baixar e instalar os módulos “pycrypto-2.6” e “paramiko-1.7.7.1”, nesta ordem. Ambos podem ser baixados no SlackBuilds e instalados conforme orientação das dependências no começo deste artigo.

O “paramiko” é um módulo Python que implementa o protocolo SSH2 com o objetivo de garantir a segurança nas autenticações com máquinas remotas.

Instalação automática do OCS Client usando GPO…

 Clusterweb, Linux, Redes  Comentários desativados em Instalação automática do OCS Client usando GPO…
ago 162012
 

Instalação automática do OCS Client usando GPO

Você que administra um rede com mais de 50 computadores sabe como é complicado fazer o controle do parque no que diz respeito as configurações e a localização dessas máquinas nos setores e seus usuários, para isso temos o OCS Inventory e o GLPI para ajudar com esse trabalho. Mas como tudo que é bom as vezes tras um pouco de trabalho, e o OCS não foge a regra. O OCS Inventory para coletar as informações, necessita que um aplicativo cliente seja instalado na máquina monitorada, para isso existem duas maneiras:

  1. Indo na máquina e instalando
  2. Fazendo isso automáticamente

Nesse artigo mostro como fazer uma das várias maneiras de instalação automatizada do aplicativo cliente do OCS Inventory. Vamos fazer este procedimento usando GPO do Active Diretory, mãos a obra.

 

1 – Criando um instalador personalizado

Para iniciarmos nosso processo, precisamos de um palicativo que encontra-se no site do OCS Inventory chamado OCS Packger, que pode ser baixado no seguinte link:

http://launchpad.net/ocsinventory-windows-packager/ocs-agent-v4061-compatible/1.02/+download/OCSNG_WINDOWS_PACKAGER_1.02.zip

Outro programa que vai ser necessário para que este tutorial seja possivel é o executável do OCS Client, este pode ser baixado no link a seguir:

http://launchpad.net/ocsinventory-windows-agent/1.x/win32-agent-release-4061/+download/OCSNG_WINDOWS_AGENT_4061.1.zip

de posse desses dois aplicativos, vamos ao que interessa.

1.1 – Criando executável de auto instalação

Para iniciar o processo, vamos abrir o aplicativo OCS Packger, sua interface é bem simples e intuítiva, onde apenas dois campos vão ser preenchidos. A tela inicial e ela preenchida podem ser vista abaixo:

Os dois campos que vão usar para configurar o executável para a instalação automática, será o Exe file onde vai ser adicionado o caminho para o executável do OSC Client e o campo Command line options onde vai ser adicionado a seguinte linha de comando:

/S /NOW /SERVER:IP-DO-SERVIDOR-OCS /PNUM:80 /NP /INSTALL /DEBUG

por fim é preciso adicionar o usuário com poderes administrativos para instalar a apalicação, nos dois ultimos campos desta tela. Caso queira usar um usuário do dominio adicione da seguinte maneira: DOMINIO\Administrador

Clique no botão Next, na proxima tela, adicione o local onde vai ser colocado o executável final.

Depois de escolher o local, clique no botão OK, neste momento vai ser iniciado o processo de criação do executável para ser adicionado no controlador de dominio, ao final do processo, uma tela será mostrada informando da criação com sucesso, clique em OK

Procure no local pelo arquivo gerado pela aplicação, neste processo demonstrado acima, ao encontra-lo, renomeie o mesmo para o ip do servidor onde esta instalado o OCS Inventory, como podemos ver no exemplo abaixo:

Com isso termina o primeiro passo, agora vamos configurar este aplicativo no controlador de dominio.

1.2 – Configurando GPO no Controlador de Dominio

Iniciando a configuração do controlador de dominio, primeiramente acesse seu controlador de dominio, abra o editor de GPO, neste exemplo está sendo usando o aplicativo Group Police Manager.

Agora, na pasta Group Police Objects, crie uma nova GPO clicando com o botão direito do mouse e coloque com um nome a sua escolha, neste exemplo dei o nome de OCS Cliente.

Com a GPO criada, clique com o botão direito e em seguida escolha a opção editar

A tela de configurações da GPO será aberta, como vista abaixo

Agora, vamos entrar em Configuração do computador, em seguida Configurações do Windows e por fim Scripts (inicialização/encerramento). No lado esquerdo existem duas opções, escolha a opção Inicializar, clique com o botão direito e escolha Propriedades.

A tela de propriedades vai ser aberta como vista abaixo, e nela vamos adicionar o arquivo de configuramos no primeiro passo desse artigo.

Nesta tela, clique em Adicionar…, vai ser mostrado uma nova tela, onde no primeiro campo vamos adicionar o caminho para o executável do aplicativo. Para isso clique no botão Procurar…

A tela abaixo mostra um diretório onde devemos colocar o arquivo criado, então, caso tenha criado o arquivo em um outro computador que não tenha sido o controlador de dominio, transfira o arquivo para o computador servidor, em seguida localize este arquivo e copie ele para dentro desta pasta, ficando como mostra a figura:

depois é só clicar em Abrir e voltaremos a telaanterior. Para finalizar vamos adicionar a seguinte linha de comando descrita abaixo no segundo campo disponível.

/S /NOW /SERVER:192.168.11.251 /PNUM:80 /NP /INSTALL /DEBUG

então esta tela ficará com a seguinte configuração:

Agora é só clicar em OK e confirmar as telas seguintes e lincar a gpo criada as OU’s que vão recebe-la. Espeque que as diretivas sejam atualizadas nas máquinas cliente e quando estas logarem novamente no servidor, o OCS Cliente sera instalado antes mesmo de aparecer a tela para inserir usuário e senha.

3 – Considerações finais

  1. A linha de comando descrita neste exemplo, pode ser alterada a seu gosto;
  2. Todo procedimento foi executando no Windows Server 2003 R2, então não sei se este mesmo passo a passo se aplica a versão Server 2008, mas acredito que sim;
  3. Se já existir alguma instalação anterior do OCS Cliente na máquina adiciono o string /FORCE na linha de comando para que ele force a sincronização
  4. Após instalado o OCS Cliente automaticamente já inicia a varredura dos componentes da máquina e as envia para o servidor, caso isso não ocorra, pode ter acontecido duas coisas:
    1. A versão do cliente não esta compativel com a versão servidor ( A versão mais nova não estável do cliente não funcionou corretamente comigo)
    2. A linha de comando não esta feita para a realidade do seu servidor, então reveja a linha e altere para sua realidade.

Bom pessoal acho que é isso, espore que este artigo ajude vocês a diminuirem um pouco do trabalho no deploy desse aplicativo que sem sombra de dúvidas é uma maravilha e ajuda bastante a equipe de suporte.

TUTORIAL DE INSTALAÇÃO DO GLPI + OCS NO UBUNTU SERVER 9.04 E INTEGRAÇÃO ENTRE O GLPI, OCSINVENTORY E O ACTIVE DIRECTORY.

 Clusterweb, Linux, Redes  Comentários desativados em TUTORIAL DE INSTALAÇÃO DO GLPI + OCS NO UBUNTU SERVER 9.04 E INTEGRAÇÃO ENTRE O GLPI, OCSINVENTORY E O ACTIVE DIRECTORY.
ago 162012
 

TUTORIAL DE INSTALAÇÃO DO GLPI + OCS NO UBUNTU
SERVER 9.04 E INTEGRAÇÃO ENTRE O GLPI,
OCSINVENTORY E O ACTIVE DIRECTORY.
Sumário
Sumário ………………………………………………………………………………………………………… 2
Considerações Iniciais………………………………………………………………………………………3
Procedimentos Iniciais ……………………………………………………………………………………..3
Acessando com usuário root……………………………………………………………………………… 3
Configurando proxy…………………………………………………………………………………………3
Atualizando repositório…………………………………………………………………………………….4
Instalando Apache, PHP5, Mysql e php5-ldap……………………………………………………… 4
Testando PHP …………………………………………………………………………………………………6
Testando Mysql ………………………………………………………………………………………………6
Alterações Importantes……………………………………………………………………………………..7
Baixando o GLPI …………………………………………………………………………………………….8
Pré-instalação do GLPI …………………………………………………………………………………….8
Instalação do GLPI via browser …………………………………………………………………………9
Autenticação pelo AD (ldap)…………………………………………………………………………… 13
Configuração do LDAP………………………………………………………………………………….. 13
Instalação do OCSInventory……………………………………………………………………………. 15
Procedimentos Iniciais …………………………………………………………………………………… 15
Instalando o OCS………………………………………………………………………………………….. 16
Concluindo a instalação do OCS ……………………………………………………………………… 18
Tela Inicial…………………………………………………………………………………………………… 20
Anexo I – Mapeando um diretório do SO Windows…………………………………………….. 20
Anexo II – Restauração de base de dados já existente (GLPI) ……………………………….. 21
Anexo III – Restauração de base de dados já existente (OCS) ……………………………….. 21
Anexo IV – Recuperando a senha do administrador do GLPI………………………………… 22
Anexo V – Sincronizando usuários do AD com o GLPI……………………………………….. 23
Anexo VI – Habilitando Modo OCS no GLPI (Sincronização)……………………………… 24
Considerações Iniciais
1. Um servidor Controlador de Domínios AD que já esteja instalado e
Funcionando;
2. Um computador com SO Ubuntu server 8.04 ou superior e acesso Root;
3. Que o técnico responsável tenha um mínimo de conhecimento em Linux;
4. Acesso a internet.
Procedimentos Iniciais
Antes de iniciarmos o processo de instalação e configuração do GLPI precisamos
verificar se algumas dependências já foram solucionadas, (isso imaginando que o GLPI
e o OCSInventory serão instalados no mesmo servidor), as dependências seriam as
seguintes:
 Um servidor Apache2
 Suporte a PHP4 ou superior no servidor web (Neste caso, usaremos o PHP5)
 Servidor de banco de dados MySQL
 Integração PHP LDAP
 SSH se caso, seja necessária alguma configuração remota ao servidor.
Acessando com usuário root
É necessário acesso root para todas as instalações, para isso no console do Ubuntu
Server digite:
sudo su (ENTER) e logo após digite a senha de acesso root (ENTER)
OBS. Verifique se o prompt está com # que indica acesso root.
Configurando proxy
Se necessário autenticação em algum servidor proxy, é imprescindível o seguinte
comando para futuras instalações e download’s.
Digite: export http_proxy=“http://usuário:senha@domínio:8080” (ENTER)
Logo após, deve ser editado o arquivo hosts da seguinte forma:
Digite: nano /etc/hosts
Acrescente a linha: ip_servidor nome_servidor (EX. 192.168.1.1 ServerProxy).
Salve as alterações (CTRL + X, Y)
Atualizando repositório
Digite: apt-get update (ENTER)
Instalando Apache, PHP5, Mysql e php5-ldap
Digite: apt-get install apache2 php5 mysql-server-5.1 php5-mysql php5-ldap php5-dev
php5-gd php5-mcrypt libapache2-mod-php5 (ENTER)
Obs: verificar se não existem versões superiores no repositório. Você pode usar o
comando EX: apt-cache policy php5, para verificar as versões instaladas e atuais do
repositório, ou apt-cache search nome_programa para busca por nome no repositório.
Na tela de configuração do Mysql que abrirá automaticamente, digite a senha “root” do
Mysql:
Redigite a senha
Escolha a opção Site Internet
(ENTER)
Testando PHP
Verifique se contém em /home/viaza132/www o arquivo index.php (O acesso pode ser via browser,
digitando o ip_servidor).
Testando Mysql
Verifique se o Mysql foi instalado digitando: mysql –u root –p (senha root configurada
anteriormente)
Utilize o comando exit; para sair
Alterações Importantes
Para evitar que a mensagem “Allocated memory: 16777216 octets A minimum of
32MB is commonly required for GLPI. Try increasing the memory_limit
parameter in the php.ini file.” seja mostrada no momento da instalação do GLPI, vai
ser necessário alterar no arquivo “php.ini” que está localizado no diretório
“/etc/php5/apache2/” o campo “memory_limit“.
Digite: nano /etc/php5/apache2/php.ini (ENTER)
Altera o campo memory_limit = 64M
OBS. Você pode buscar a linha utilizando o Pesquisa do nano (CTRL + W) = 16m
Salve as alterações (CTRL + X, Y)
É necessário o restart do apache para que as alterações sejam efetuadas, para isso
Digite: /etc/init.d/apache2 restart
Solucionado os pontos acima, vamos iniciar o download e a instalação do GLPI
Baixando o GLPI
A versão estável atual (agosto/2009) é GLPI 0.72.1 e está disponível em:
http://www.glpi-project.org/spip.php?lang=en
Pré-instalação do GLPI
Copie a pasta do glpi para /home/viaza132/www com o seguinte comando:
Digite: cp /local_da_pasta_glpi /home/viaza132/www –r (ENTER)
Obs. Você pode utilizar o comando tar caso queira descompactar o arquivo baixado
diretamente no local desejado. (Ex. tar -xzvf /mnt/suporte/glpi. –C /home/viaza132/www )
Confira se o conteúdo glpi foi copiado corretamente.
Digite: cd /home/viaza132/www/glpi (ENTER)
ls
É indispensável dar permissões em algumas pastas e arquivos, para isso, você
pode dar permissão na pastas inteiras utilizando o comando chmod 777
/home/viaza132/www/glpi/files/ -r e chmod 777 /home/viaza132/www/glpi/config/ -r
Ou somente nos arquivos relacionados à abaixo (recomendado):
Digite: chmod 777 /home/viaza132/www/glpi/files/
chmod 777 /home/viaza132/www/glpi/config/
chmod 777 /home/viaza132/www/glpi/files/_dumps
chmod 777 /home/viaza132/www/glpi/files/_sessions
chmod 777 /home/viaza132/www/glpi/files/_cron
chmod 777 /home/viaza132/www/glpi/files/_cache
chmod 777 /home/viaza132/www/glpi/files/_log
Instalação do GLPI via browser
No Browser de qualquer Desktop da rede, acesse a URL: ip_servidor/glpi (caso não
saiba o ip_servidor, utilize o comando ifconfig para obtê-lo)
Neste Exemplo, o ip_servidor é 192.168.1.199
Configure conforme figuras a seguir:
Escolha a opção Português do Brasil (pt_BR) e clique em OK
Marque a opção ACEITO e clique em Continuar
Escolha a opção Instalar
Verifique se todas as permissões estão OK (bolinha verde), caso não esteja (bolinha
vermelha), será necessário alterar as permissões do arquivo/pasta que estiverem
faltando. Tudo OK, clique em Continuar.
Identifique o servidor Mysql juntamente com o usuário e senha root do Mysql. Neste
caso, o nome do servidor será localhost. Clique em Continuar
Vamos criar um novo database com o nome glpi (minúsculo). Clique em Continuar
Clique em Continuar
Clique em Use GLPI
O primeiro login será glpi e a primeira senha de acesso administrador também será glpi.
(ENTER)
(ENTER)
Pronto! O glpi foi instalado corretamente.
Autenticação pelo AD (ldap)
Novamente no Browser de qualquer Desktop da rede, acesse a URL: ip_servidor/glpi,
no menu Configurar, clique em Autenticação.
Selecione a opção Diretório LDAP
Clique sobre o botão + para adicionar um link a um AD já existente, e configure,
conforme informações do AD utilizado por você.
Configuração do LDAP
Clique sobre o Hiperlink Active Directory para ele preencher alguns campos
automaticamente.
Nome: Nome do domínio (Pode ser colocado o nome de sua empresa)
Servidor: xxx.xx.xx.xx (Ip do servidor windows com AD)
Basedn: dc=dominio;dc=com;dc=br (enderço no formato ldap)
Pass(para conexão não anonima): ***** (senha administrador ou usuário do AD)
Filtro de Conexão: (objectClass=user)
Porta LDAP (default=389): 389
rootdn (para conexão não anônima): cn=user;ou=infra,dc=dominio;dc=com;dc=br
(você pode usar também seu usuário e senha do AD domínio\usuário)
Campo de Login: samaccountname
Usa TLS: Não
Fuso horário: GMT-3 hora(s)
Como os alias do LDAP devem ser manipulados: Nunca dês-referenciado (Por
Padrão)
Tipo de busca: Em usuários
Filtro para pesquisa em grupos: (objectclass=users)
usar DN na pesquisa: Sim
Usuários contendo seus grupos: memberof
Sobrenome: cn
Comentários: info
Telefones: telephonenumber
Celular: mobile
Nome: givenname
E-mail: mail
Telefones 2: otherstelephone
Os demais campos podem permanecer como estão.
Exemplo de configuração na figura a seguir (Detalhes de importação de usuários do AD
em anexo V).
Exemplo de AD configurado
Pronto! O GLPI já foi instalado com sucesso, e já está comunicando com o AD de rede.
Veja detalhes de Integração do GLPI e OCS-NG no anexo VI deste tutorial.
Instalação do OCSInventory
Procedimentos Iniciais
Antes de iniciarmos o processo de instalação e configuração do OCS precisamos
verificar se algumas dependências já foram solucionadas. O OCS necessita do módulo
PERL instalado para seu pleno funcionamento, para instalá-lo execute os seguintes
procedimentos:
Digite:
apt-get install build-essential libxml-simple-perl libcompress-zlib-perl libdbiperl
libdbd-mysql-perl libapache-dbi-perl libnet-ip-perl libsoap-lite-perl libphp-pclzip
aptitude install libxml-parser-perl
Também é necessário instalar o pacote CPAN manualmente, se você utiliza um
servidor proxy é preciso antes configurá-lo utilizando o comando
export http_proxy=“http://usuário:senha@domínio:8080” (ENTER).
Digite: perl -e shell -MCPAN
CPAN> install XML::Entities
Utilize o comando exit para sair da aplicação.
É necessário o restart do apache para que as alterações sejam efetuadas, para isso
Digite: /etc/init.d/apache2 restart
Instalando o OCS
Localize a pasta onde contém os arquivos de instalação e execute o instalador do OCS,
neste exemplo, o OCS já foi descompactado diretamente na pasta /root:
Digite: tar -xzvf /mnt/linux/…/ -C /root/
Digite: cd OCSNG_UNIX_SERVER-1.02.1
ls
./setup.sh
Siga os passos a seguir?
Do you wish to continue ([y]/n)? (ENTER)
Which host is running database server [localhost] ? (ENTER)
Do which port is running database server [3306] ? (ENTER)
Where is Apache daemon binary [/usr/sbin/apache2] ? (ENTER)
Where is Apache main configuration file [/etc/apache2/apache2.conf] ? (ENTER)
Which user account is running Apache web server [www-data] ? www-data
Which user group is running Apache web server [www-data] ? www-data
Where is Apache Include configuration directory [/etc/apache2/conf.d] ? (ENTER)
Where is PERL Intrepreter binary [/usr/bin/perl] ? (ENTER)
Do you wish to setup Communication server on this computer ([y]/n) ? (ENTER)
Where to put Communicarion server log directory [/var/log/ocsinventory-server] ?
(ENTER)
Do you wish to continue ([y]/n) ? (ENTER)
Do you allow Setup renaming Communicarion Server Apache configuration file to ‘zocsinventory-
server.conf’ ([y]/n) ? (ENTER)
Do you wish to setup Administration Server (Web Administration Console) on this
computer ([y]/n) ? (ENTER)
Do you wish to continue ([y]/n) ? (ENTER)
Where to copy Administration Server static files for PHP Web Console
[/usr/share/ocsinventory-reports] ? (ENTER)
Where to create writable/cache directories for deployment packages and IPDiscover
[/var/lib/ocsinventory-reports] ? (ENTER)
Crie um database com o nome oscweb para receber as tabelas do banco de dados, para
isso:
Digite: mysql –u root –p (Digite a senha root do mysql) (ENTER)
Create database ocsweb;
Para verificar se foi criado utilize o comando show databases;
Utilize o comando exit para sair.
Concluindo a instalação do OCS
No Browser de qualquer Desktop da rede, acesse a URL:
ip_servidor/ocsreports/install.php (caso não saiba o ip_servidor, utilize o comando
ifconfig para obtê-lo e se necessário for “restartar” o sistema, utilize o comando reboot).
Neste caso, o ip_servidor é
Digite: http://192.168.1.199/ocsreports/install.php.
Configure conforme figuras a seguir:
Utilize a senha root do mysql, criada no momento de sua instalação.
Clique em Enviar Consulta
Clique em Click here to enter OCS-NG GUI
Utilize login: admin e senha: admin para entrar. Caso tenha sido utilizado um backup do
database, utilize a senha administrador do database restaurado.
Tela Inicial
Pronto! O OCSInvetory já foi instalado com sucesso.
Anexo I – Mapeando um diretório do SO Windows
Caso seja necessário acesso a um diretório em um sistema operacional Windows é
preciso o pacote para comunicação (smbfs), que torna possível o acesso a arquivos em
diretórios Microsoft Windows.
Digite: apt-get install smbfs
Para mapear a pasta desejada:
Digite: smbmount //ip_do_compuador/nome_da_pasta /mnt/ -o username=usuário
(ENTER)
(Talvez seja necessário digitar a senha do AD ou usuário local) (ENTER)
A pasta mapeada ficará em /mnt, para acessá-la:
Digite: cd /mnt/nome_da_pasta/ (ENTER)
ls (ENTER)
Anexo II – Restauração de base de dados já existente (GLPI)
Se você já tem uma base de dados “alimentada” do glpi, é possível restaurar/substituir a
base de dados em branco pela sua base de dados.
No console do Ubuntu Server:
Digite: mysql –u root –p glpi < /local_database/database.sql
(Digite a senha root do mysql) (ENTER)
Obs: Lembre-se que para isso, as versões do GLPI devem ser similares, tendo
em vista que pode haver mudança na estrutura das tabelas do banco utilizado por
versões diferentes.
Anexo III – Restauração de base de dados já existente (OCS)
Se você já tem uma base de dados “alimentada” do OCS, é possível restaurar/substituir
a base de dados em branco pela sua base de dados.
No console do Ubuntu Server:
Digite: mysql –u root –p ocsweb < /local_database/database.sql
(Digite a senha root do mysql) (ENTER)
Exemplo:
Anexo IV – Recuperando a senha do administrador do GLPI
É possível substituir a senha admin da base de dados (database.sql), caso você não tenha
a senha administrador atual, para isso:
Digite: mysql –u root –p(Digite a senha root do mysql)
use glpi;
update glpi_users set password_md5=MD5 ( ‘glpi’ ) where name=’admin’;
Neste caso, o login foi restaurado para admin e a senha para glpi.
Utilize o comando exit; para sair.
É necessário o restart do apache para que as alterações sejam efetuadas, para isso
Digite: /etc/init.d/apache2 restart
Anexo V – Sincronizando usuários do AD com o GLPI
No usuário administrador do GLPI, na aba ADMINISTRAÇÃO, clique em
USUÁRIOS.
Clique na aba LINK LDAP.
Logo a seguir, clique em IMPORTAR USUÁRIOS EM MASSA DO DIRETÓRIO
LDAP.
Selecione o usuários que deseja importar do AD.
Clique em IMPORTAR.
Pronto! Os usuários já foram importados com sucesso.
Anexo VI – Habilitando Modo OCS no GLPI (Sincronização)
Na aba CONFIGURAR, clique em GERAL.
Na aba RESTRIÇÕES, coloque SIM para “Ativar modo OCS-NG”.
Configure conforme seu servidor OCS, exemplo a seguir:
Na aba FERRAMENTAS, clique em OCS-NG.
Utilize a opção “Importação de novos computadores” para sincronizar base de dados
com o OCSInventory.
Pronto! O modo OCS-NG já foi implantado com sucesso no GLPI.

O que é uma rede

 Clusterweb, Linux, Redes  Comentários desativados em O que é uma rede
ago 092012
 

Rede é a conexão de duas ou mais máquinas com o objetivo de compartilhar recursos entre uma
máquina e outra. Os recursos podem ser:
• Compartilhamento do conteúdo de seu disco rígido (ou parte dele) com outros usuários. Os
outros usuários poderão acessar o disco como se estivesse instalado na própria máquina).
Também chamado de servidor de arquivos.
• Compartilhamento de uma impressora com outros usuários. Os outros usuários poderão
enviar seus trabalhos para uma impressora da rede. Também chamado de servidor de
impressão.
• Compartilhamento de acesso a Internet. Outros usuários poderão navegar na Internet, pegar
seus e-mails, ler noticias, bate-papo no IRC, ICQ através do servidor de acesso Internet.
Também chamado de servidor Proxy.
• Servidor de Internet/Intranet. Outros usuários poderão navegar nas páginas Internet
localizadas em seu computador, pegar e-mails, usar um servidor de IRC para chat na rede,
servidor de ICQ, etc
Com os ítens acima funcionando é possível criar permissões de acesso da rede, definindo quem terá
ou não permissão para acessar cada compartilhamento ou serviço existente na máquina (www, ftp,
irc, icq, etc), e registrando/avisando sobre eventuais tentativas de violar a segurança do sistema,
firewalls, pontes, etc.
Entre outras ilimitadas possibilidades que dependem do conhecimento do indivíduo no ambiente
GNU/Linux, já que ele permite muita flexibilidade para fazer qualquer coisa funcionar em rede.
A comunicação entre computadores em uma rede é feita através do Protocolo de Rede.
4.2 Protocolo de Rede
O protocolo de rede é a linguagem usada para a comunicação entre um computador e outro.
Existem vários tipos de protocolos usados para a comunicação de dados, alguns são projetados para
pequenas redes (como é o caso do NetBios) outros para redes mundiais (TCP/IP que possui
características de roteamento).
Dentre os protocolos, o que mais se destaca atualmente é o TCP/IP devido ao seu projeto,
velocidade e capacidade de roteamento.
4.3 Endereço IP
O endereço IP são números que identificam seu computador em uma rede. Inicialmente você pode
imaginar o IP como um número de telefone. O IP é compostos por quatro bytes e a convenção de
escrita dos números é chamada de “notação decimal pontuada”. Por convenção, cada interface
(placa usada p/ rede) do computador ou roteador tem um endereço IP. Também é permitido que o
mesmo endereço IP seja usado em mais de uma interface de uma mesma máquina mas normalmente
cada interface tem seu próprio endereço IP.
As Redes do Protocolo Internet são seqüências contínuas de endereços IP’s. Todos os endereços
dentro da rede tem um número de dígitos dentro dos endereços em comum. A porção dos endereços
que são comuns entre todos os endereços de uma rede são chamados de porção da rede. Os dígitos
restantes são chamados de porção dos hosts. O número de bits que são compartilhados por todos os
endereços dentro da rede são chamados de netmask (máscara da rede) e o papel da netmask é
determinar quais endereços pertencem ou não a rede. Por exemplo, considere o seguinte:
—————– —————
Endereço do Host 192.168.110.23
Máscara da Rede 255.255.255.0
Porção da Rede 192.168.110.
Porção do Host .23
—————– —————
Endereço da Rede 192.168.110.0
Endereço Broadcast 192.168.110.255
—————– —————
Qualquer endereço que é finalizado em zero em sua netmask, revelará o endereço da rede que
pertence. O endereço e rede é então sempre o menor endereço numérico dentro da escalas de
endereços da rede e sempre possui a porção host dos endereços codificada como zeros.
O endereço de broadcast é um endereço especial que cada computador em uma rede “escuta” em
adição a seu próprio endereço. Este é um endereço onde os datagramas enviados são recebidos por
todos os computadores da rede. Certos tipos de dados como informações de roteamento e
mensagens de alerta são transmitidos para o endereço broadcast, assim todo computador na rede
pode recebe-las simultaneamente.
Existe dois padrões normalmente usados para especificar o endereço de broadcast. O mais
amplamente aceito é para usar o endereço mais alto da rede como endereço broadcast. No
exemplo acima este seria 192.168.110.255. Por algumas razões outros sites tem adotado a
convenção de usar o endereço de rede como o endereço broadcast. Na prática não importa
muito se usar este endereço, mas você deve ter certeza que todo computador na rede esteja
configurado para escutar o mesmo endereço broadcast.
4.3.1 Classes de Rede IP
Por razões administrativas após algum pouco tempo no desenvolvimento do protocolo IP alguns
grupos arbitrários de endereços foram formados em redes e estas redes foram agrupadas no que
foram chamadas de classes. Estas classes armazenam um tamanho padrão de redes que podem ser
usadas. As faixas alocadas são:
+——————————————————–+
| Classe | Máscara de | Endereço da Rede |
| | Rede | |
+——————————————————–+
| A | 255.0.0.0 | 0.0.0.0 – 127.255.255.255 |
| B | 255.255.0.0 | 128.0.0.0 – 191.255.255.255 |
| C | 255.255.255.0 | 192.0.0.0 – 223.255.255.255 |
|Multicast| 240.0.0.0 | 224.0.0.0 – 239.255.255.255 |
+——————————————————–+
O tipo de endereço que você deve utilizar depende exatamente do que estiver fazendo.
4.3.2 Referência rápida de máscara de redes
A tabela abaixo faz referência as máscaras de rede mais comuns e a quantidade de máquinas
máximas que ela atinge. Note que a especificação da máscara tem influência direta na classe de rede
usada:
Máscara Máscara Número
(Forma (Forma Máximo de
octal) 32 bits) Máquinas
Classe A:
/8 /255.0.0.0 16,777,215
Classe B:
/16 /255.255.0.0 65,535
/17 /255.255.128.0 32,767
/18 /255.255.192.0 16,383
/19 /255.255.224.0 8,191
/20 /255.255.240.0 4,095
/21 /255.255.248.0 2,047
/22 /255.255.252.0 1,023
/23 /255.255.254.0 511
Classe C
/24 /255.255.255.0 255
/25 /255.255.255.128 127
/26 /255.255.255.192 63
/27 /255.255.255.224 31
/28 /255.255.255.240 15
/29 /255.255.255.248 7
/30 /255.255.255.252 3
/32 /255.255.255.255 1
Qualquer outra máscara fora desta tabela (principalmente para a classe A), deverá ser
redimensionada com uma calculadora de IP para chegar a um número aproximado de
redes/máquinas aproximados que deseja.
4.3.3 Para instalar uma máquina usando o Linux em uma rede existente
Se você quiser instalar uma máquina GNU/Linux em uma rede TCP/IP existente então você deve
contactar qualquer um dos administradores da sua rede e perguntar o seguinte:
• Endereço IP de sua máquina
• Endereço IP da rede
• Endereço IP de broadcast
• Máscara da Rede IP
• Endereço do Roteador
• Endereço do Servidor de Nomes (DNS)
Você deve então configurar seu dispositivo de rede GNU/Linux com estes detalhes. Você não pode
simplesmente escolhe-los e esperar que sua configuração funcione.
4.3.4 Endereços reservados para uso em uma rede Privada
Se você estiver construindo uma rede privada que nunca será conectada a Internet, então você pode
escolher qualquer endereço que quiser. No entanto, para sua segurança e padronização, existem
alguns endereços IP’s que foram reservados especificamente para este propósito. Eles estão
especificados no RFC1597 e são os seguintes:
+———————————————————+
| ENDEREÇOS RESERVADOS PARA REDES PRIVADAS |
+———————————————————+
| Classe | Máscara de | Endereço da Rede |
| de Rede | Rede | |
+———+—————+——————————-+
| A | 255.0.0.0 | 10.0.0.0 – 10.255.255.255 |
| B | 255.255.0.0 | 172.16.0.0 – 172.31.255.255 |
| C | 255.255.255.0 | 192.168.0.0 – 192.168.255.255 |
+———————————————————+
Você deve decidir primeiro qual será a largura de sua rede e então escolher a classe de rede que será
usada.
4.4 Interface de rede
As interfaces de rede no GNU/Linux estão localizadas no diretório /dev e a maioria é criada
dinamicamente pelos softwares quando são requisitadas. Este é o caso das interfaces ppp e plip
que são criadas dinamicamente pelos softwares.
Abaixo a identificação de algumas interfaces de rede no Linux (a ? significa um número que
identifica as interfaces seqüencialmente, iniciando em 0):
• eth? – Placa de rede Ethernet e WaveLan.
• ppp? – Interface de rede PPP (protocolo ponto a ponto).
• slip? – Interface de rede serial
• eql – Balanceador de tráfego para múltiplas linhas
• plip? – Interface de porta paralela
• arc?e, arc?s – Interfaces Arcnet
• sl?, ax? – Interfaces de rede AX25 (respectivamente para kernels 2.0.xx e 2.2.xx.
• fddi? – Interfaces de rede FDDI.
• dlci??, sdla? – Interfaces Frame Relay, respectivamente para para dispositivos de
encapsulamento DLCI e FRAD.
• nr? – Interface Net Rom
• rs? – Interfaces Rose
• st? – Interfaces Strip (Starmode Radio IP)
• tr? – Token Ring
Para maiores detalhes sobre as interfaces acima, consulte o documento NET3-4-HOWTO.
4.4.1 A interface loopback
A interface loopback é um tipo especial de interface que permite fazer conexões com você mesmo.
Todos os computadores que usam o protocolo TCP/IP utilizam esta interface e existem várias razões
porque precisa fazer isto, por exemplo, você pode testar vários programas de rede sem interferir
com ninguém em sua rede. Por convenção, o endereço IP 127.0.0.1 foi escolhido especificamente
para a loopback, assim se abrir uma conexão telnet para 127.0.0.1, abrirá uma conexão para o
próprio computador local.
A configuração da interface loopback é simples e você deve ter certeza que fez isto (mas note que
esta tarefa é normalmente feita pelos scripts padrões de inicialização existentes em sua
distribuição).
ifconfig lo 127.0.0.1
Caso a interface loopback não esteja configurada, você poderá ter problemas quando tentar qualquer
tipo de conexão com as interfaces locais, tendo problemas até mesmo com o comando ping.
4.4.2 Atribuindo um endereço de rede a uma interface (ifconfig)
Após configurada fisicamente, a interface precisa receber um endereço IP para ser identificada na
rede e se comunicar com outros computadores, além de outros parâmetros como o endereço de
broadcast e a máscara de rede. O comando usado para fazer isso é o ifconfig (interface
configure).
Para configurar a interface de rede Ethernet (eth0) com o endereço 192.168.1.1, máscara de rede
255.255.255.0, podemos usar o comando:
ifconfig eth0 192.168.1.1 netmask 255.255.255.0 up
O comando acima ativa a interface de rede. A palavra up pode ser omitida, pois a ativação da
interface de rede é o padrão. Para desativar a mesma interface de rede, basta usar usar o comando:
ifconfig eth0 down
Digitando ifconfig são mostradas todas as interfaces ativas no momento, pacotes enviados,
recebidos e colisões de datagramas. Para mostrar a configuração somente da interface eth0, use o
comando: ifconfig eth0 Em sistemas Debian, o arquivo correto para especificar os dados
das interfaces é o /etc/network/interfaces .
Para mais detalhes, veja a página de manual do ifconfig ou o NET3-4-HOWTO.
4.5 Roteamento
Roteamento é quando uma máquina com múltiplas conexões de rede decide onde entregar os
pacotes IP que recebeu, para que cheguem ao seu destino.
Pode ser útil ilustrar isto com um exemplo. Imagine um simples roteador de escritório, ele pode ter
um link intermitente com a Internet, um número de segmentos ethernet alimentando as estações de
trabalho e outro link PPP intermitente fora de outro escritório. Quando o roteador recebe um
datagrama de qualquer de suas conexões de rede, o mecanismo que usa determina qual a próxima
interface deve enviar o datagrama. Computadores simples também precisam rotear, todos os
computadores na Internet tem dois dispositivos de rede, um é a interface loopback (explicada
acima) o outro é um usado para falar com o resto da rede, talvez uma ethernet, talvez uma interface
serial PPP ou SLIP.
OK, viu como o roteamento funciona? cada computador mantém uma lista de regras especiais de
roteamento, chamada tabela de roteamento. Esta tabela contém colunas que tipicamente contém no
mínimo três campos, o primeiro é o endereço de destino, o segundo é o nome da interface que o
datagrama deve ser roteado e o terceiro é opcionalmente o endereço IP da outra máquina que levará
o datagrama em seu próximo passo através da rede. No GNU/Linux você pode ver a tabela de
roteamento usando um dos seguintes comandos:
cat /proc/net/route
route -n
netstat -r
O processo de roteamento é muito simples: um datagrama (pacote IP) é recebido, o endereço de
destino (para quem ele é) é examinado e comparado com cada item da tabela de roteamento. O item
que mais corresponder com o endereço é selecionado e o datagrama é direcionado a interface
especificada.
Se o campo gateway estiver preenchido, então o datagrama é direcionado para aquele computador
pela interface especificada, caso contrário o endereço de destino é assumido sendo uma rede
suportada pela interface.
4.5.1 Configurando uma rota no Linux
A configuração da rota é feita através da ferramenta route. Para adicionar uma rota para a rede
192.168.1.0 acessível através da interface eth0 basta digitar o comando:
route add -net 192.168.1.0 eth0
Para apagar a rota acima da tabela de roteamento, basta substituir a palavra add por del. A palavra
net quer dizer que 192.168.1.0 é um endereço de rede (lembra-se das explicações em Endereço IP,
Seção 4.3?)) para especificar uma máquina de destino, basta usar a palavra -host. Endereços de
máquina de destino são muito usadas em conexões de rede apenas entre dois pontos (como ppp,
plip, slip). Por padrão, a interface é especificada como último argumento. Caso a interface precise
especifica-la em outro lugar, ela deverá ser precedida da opção -dev.
Para adicionar uma rota padrão para um endereço que não se encontre na tabela de roteamento,
utiliza-se o gateway padrão da rede. Através do gateway padrão é possível especificar um
computador (normalmente outro gateway) que os pacotes de rede serão enviados caso o endereço
não confira com os da tabela de roteamento. Para especificar o computador 192.168.1.1 como
gateway padrão usamos:
route add default gw 192.168.1.1 eth0
O gateway padrão pode ser visualizado através do comando route -n e verificando o campo
gateway. A opção gw acima, especifica que o próximo argumento é um endereço IP (de uma rede
já acessível através das tabelas de roteamento).
O computador gateway está conectado a duas ou mais redes ao mesmo tempo. Quando seus dados
precisam ser enviados para computadores fora da rede, eles são enviados através do computador
gateway e o gateway os encaminham ao endereço de destino. Desta forma, a resposta do servidor
também é enviada através do gateway para seu computador (é o caso de uma típica conexão com a
Internet).
A nossa configuração ficaria assim:
route add -net 192.168.1.0 eth0
route add default gw 192.168.1.1 eth0
Para mais detalhes, veja a página de manual do route ou o NET3-4-HOWTO.
4.6 Resolvedor de nomes (DNS)
DNS significa Domain Name System (sistema de nomes de domínio). O DNS converte os nomes de
máquinas para endereços IPs que todas as máquinas da Internet possuem. Ele faz o mapeamento do
nome para o endereço e do endereço para o nome e algumas outras coisas. Um mapeamento é
simplesmente uma associação entre duas coisas, neste caso um nome de computador, como
www.cipsga.org.br, e o endereço IP desta máquina (ou endereços) como 200.245.157.9.
O DNS foi criado com o objetivo de tornar as coisas mais fáceis para o usuário, permitindo assim, a
identificação de computadores na Internet ou redes locais através de nomes (é como se tivéssemos
apenas que decorar o nome da pessoa ao invés de um número de telefone). A parte responsável por
traduzir os nomes como www.nome.com.br em um endereço IP é chamada de resolvedor de
nomes.
O resolvedor de nomes pode ser um banco de dados local (controlador por um arquivo ou
programa) que converte automaticamente os nomes em endereços IP ou através de servidores DNS
que fazem a busca em um banco de dados na Internet e retornam o endereço IP do computador
desejado. Um servidor DNS mais difundido na Internet é o bind.
Através do DNS é necessário apenas decorar o endereço sem precisar se preocupar com o endereço
IP (alguns usuários simplesmente não sabem que isto existe…). Se desejar mais detalhes sobre DNS,
veja o documento DNS-HOWTO.
4.6.1 O que é um nome?
Você deve estar acostumado com o uso dos nomes de computadores na Internet, mas pode não
entender como eles são organizados. Os nomes de domínio na Internet são uma estrutura
hierárquica, ou seja, eles tem uma estrutura semelhante aos diretórios de seu sistema.
Um domínio é uma família ou grupo de nomes. Um domínio pode ser colocado em um subdomínio.
Um domínio principal é um domínio que não é um sub-domínio. Os domínios principais
são especificados na RFC-920. Alguns exemplos de domínios principais comuns são:
• COM – Organizações Comerciais
• EDU – Organizações Educacionais
• GOV – Organizações Governamentais
• MIL – Organizações Militares
• ORG – Outras Organizações
• NET – Organizações relacionadas com a Internet
• Identificador do País – São duas letras que representam um país em particular.
Cada um dos domínios principais tem sub-domínios. Os domínios principais baseados no nome do
país são freqüentemente divididos em sub-domínios baseado nos domínios .com, .edu, .gov,
.mil e .org. Assim, por exemplo, você pode finaliza-lo com: com.au e gov.au para
organizações comerciais e governamentais na Austrália; note que isto não é uma regra geral, as
organizações de domínio atuais dependem da autoridade na escolha de nomes de cada domínio.
Quando o endereço não especifica o domínio principal, como o endereço www.unicamp.br, isto
quer dizer que é uma organização acadêmica.
O próximo nível da divisão representa o nome da organização. Subdomínios futuros variam em
natureza, freqüentemente o próximo nível do sub-domínio é baseado na estrutura departamental da
organização mas ela pode ser baseada em qualquer critério considerado razoável e significantes
pelos administradores de rede para a organização.
A porção mais a esquerda do nome é sempre o nome único da máquina chamado hostname, a
porção do nome a direita do hostname é chamado nome de domínio e o nome completo é chamado
nome do domínio completamente qualificado (Fully Qualified Domain Name).
Usando o computador www.debian.org.br como exemplo:
• br – País onde o computador se encontra
• org – Domínio principal
• debian – Nome de Domínio
• www – Nome do computador
A localização do computador www.debian.org.br através de servidores DNS na Internet
obedece exatamente a seqüência de procura acima. Os administradores do domínio
debian.org.br podem cadastrar quantos sub-domínios e computadores quiserem (como
www.non-us.debian.org.br ou cvs.debian.org.br).
4.6.2 Arquivos de configuração usados na resolução de nomes
Abaixo a descrição dos arquivos usados no processo de resolver um nome no sistema GNU/Linux.
4.6.2.1 /etc/resolv.conf
O /etc/resolv.conf é o arquivo de configuração principal do código do resolvedor de nomes.
Seu formato é um arquivo texto simples com um parâmetro por linha e o endereço de servidores
DNS externos são especificados nele. Existem três palavras chaves normalmente usadas que são:
domain
Especifica o nome do domínio local.
search
Especifica uma lista de nomes de domínio alternativos ao procurar por um computador,
separados por espaços. A linha search pode conter no máximo 6 domínios ou 256 caracteres.
nameserver
Especifica o endereço IP de um servidor de nomes de domínio para resolução de nomes. Pode
ser usado várias vezes.
Como exemplo, o /etc/resolv.conf se parece com isto:
domain maths.wu.edu.au
search maths.wu.edu.au wu.edu.au
nameserver 192.168.10.1
nameserver 192.168.12.1
Este exemplo especifica que o nome de domínio a adicionar ao nome não qualificado (i.e.
hostnames sem o domínio) é maths.wu.edu.au e que se o computador não for encontrado
naquele domínio então a procura segue para o domínio wu.edu.au diretamente. Duas linhas de
nomes de servidores foram especificadas, cada uma pode ser chamada pelo código resolvedor de
nomes para resolver o nome.
4.6.2.2 /etc/host.conf
O arquivo /etc/host.conf é o local onde é possível configurar alguns ítens que gerenciam o
código do resolvedor de nomes. O formato deste arquivo é descrito em detalhes na página de
manual resolv+. Em quase todas as situações, o exemplo seguinte funcionará:
order hosts,bind
multi on
Este arquivo de configuração diz ao resolvedor de nomes para checar o arquivo /etc/hosts
(parâmetro hosts) antes de tentar verificar um servidor de nomes (parâmetro bind) e retornar um
endereço IP válido para o computador procurado e multi on retornará todos os endereços IP
resolvidos no arquivo /etc/hosts ao invés do primeiro.
Os seguintes parâmetros podem ser adicionados para evitar ataques de IP spoofing:
nospoof on
spoofalert on
O parâmetro nospoof on ativa a resolução reversa do nome da biblioteca resolv (para checar se o
endereço pertence realmente àquele nome) e o spoofalert on registra falhas desta operação no
syslog.
4.6.2.3 /etc/hosts
O arquivo /etc/hosts faz o relacionamento entre um nome de computador e endereço IP local.
Recomendado para IPs constantemente acessados e para colocação de endereços de virtual hosts
(quando deseja referir pelo nome ao invés de IP). A inclusão de um computador neste arquivo
dispenda a consulta de um servidor de nomes para obter um endereço IP, sendo muito útil para
máquinas que são acessadas frequentemente. A desvantagem de fazer isto é que você mesmo
precisará manter este arquivo atualizado e se o endereço IP de algum computador for modificado,
esta alteração deverá ser feita em cada um dos arquivos hosts das máquinas da rede. Em um
sistema bem gerenciado, os únicos endereços de computadores que aparecerão neste arquivo serão
da interface loopback e os nomes de computadores.
# /etc/hosts
127.0.0.1 localhost loopback
192.168.0.1 maquina.dominio.com.br
Você pode especificar mais que um nome de computador por linha como demonstrada pela primeira
linha, a que identifica a interface loopback. Certifique-se de que a entrada do nome de domínio
neste arquivo aponta para a interface de rede e não para a interface loopback, ou terá problema com
o comportamento de alguns serviços.
OBS: Caso encontre problemas de lentidão para resolver nomes e até para executar os aplicativos
(como o mc, etc), verifique se existem erros neste arquivo de configuração.
Estes sintomas se confundem com erros de memória ou outro erro qualquer de configuração de
hardware, e somem quando a interface de rede é desativada (a com o IP não loopback). Isto é
causados somente pela má configuração do arquivo /etc/hosts. O bom funcionamento do
Unix depende da boa atenção do administrador de sistemas para configurar os detalhes de seu
servidor.
4.6.2.4 /etc/networks
O arquivo /etc/networks tem uma função similar ao arquivo /etc/hosts. Ele contém um
banco de dados simples de nomes de redes contra endereços de redes. Seu formato se difere por
dois campos por linha e seus campos são identificados como:
Nome_da_Rede Endereço_da_Rede
Abaixo um exemplo de como se parece este arquivo:
loopnet 127.0.0.0
localnet 192.168.1.0
amprnet 44.0.0.0
Quando usar comandos como route, se um destino é uma rede e esta rede se encontra no arquivo
/etc/networks, então o comando route mostrará o nome da rede ao invés de seu endereço.
4.6.3 Executando um servidor de nomes
Se você planeja executar um servidor de nomes, você pode fazer isto facilmente. Por favor veja o
documento DNS-HOWTO e quaisquer documentos incluídos em sua versão do BIND (Berkeley
Internet Name Domain).
4.7 Serviços de Rede
Serviços de rede é o que está disponível para ser acessado pelo usuário. No TCP/IP, cada serviço é
associado a um número chamado porta que é onde o servidor espera pelas conexões dos
computadores clientes. Uma porta de rede pode se referenciada tanto pelo número como pelo nome
do serviço.
Abaixo, alguns exemplos de portas padrões usadas em serviços TCP/IP:
• 21 – FTP (transferência de arquivos)
• 23 – Telnet (terminal virtual remoto)
• 25 – Smtp (envio de e-mails)
• 53 – DNS (resolvedor de nomes)
• 79 – Finger (detalhes sobre usuários do sistema)
• 80 – http (protocolo www – transferência de páginas Internet)
• 110 – Pop-3 (recebimento de mensagens)
• 119 – NNTP (usado por programas de noticias)
O arquivo padrão responsável pelo mapeamento do nome dos serviços e das portas mais utilizadas é
o /etc/services (para detalhes sobre o seu formato, veja a /etc/services, Seção 4.9.1).
4.7.1 Serviços iniciados como Daemons de rede
Serviços de rede iniciados como daemons ficam residente o tempo todo na memória esperando
que alguém se conecte (também chamado de modo standalone). Um exemplo de daemon é o
servidor proxy squid e o servidor web Apache operando no modo daemon.
Alguns programas servidores oferecem a opção de serem executados como daemons ou através do
inetd. É recomendável escolher daemon se o serviço for solicitado freqüentemente (como é o caso
dos servidores web ou proxy).
Para verificar se um programa está rodando como daemon, basta digitar ps ax e procurar o nome
do programa, em caso positivo ele é um daemon.
Normalmente os programas que são iniciados como daemons possuem seus próprios recursos de
segurança/autenticação para decidir quem tem ou não permissão de se conectar.
4.7.2 Serviços iniciados através do inetd
Serviços iniciados pelo inetd são carregados para a memória somente quando são solicitados. O
controle de quais serviços podem ser carregados e seus parâmetros, são feitos através do arquivo
/etc/inetd.conf.
Um daemon chamado inetd lê as configurações deste arquivo e permanece residente na memória,
esperando pela conexão dos clientes. Quando uma conexão é solicitada, o daemon inetd verifica as
permissões de acesso nos arquivos /etc/hosts.allow e /etc/hosts.deny e carrega o
programa servidor correspondente no arquivo /etc/inetd.conf. Um arquivo também
importante neste processo é o /etc/services que faz o mapeamento das portas e nomes dos
serviços.
Alguns programas servidores oferecem a opção de serem executados como daemons ou através do
inetd. É recomendável escolher inetd se o serviço não for solicitado freqüentemente (como é o caso
de servidores ftp, telnet, talk, etc).
4.7.2.1 /etc/inetd.conf
O arquivo /etc/inetd.conf é um arquivo de configuração para o daemon servidor inetd. Sua
função é dizer ao inetd o que fazer quando receber uma requisição de conexão para um serviço
em particular. Para cada serviço que deseja aceitar conexões, você precisa dizer ao inetd qual
daemon servidor executar e como executa-lo.
Seu formato é também muito simples. É um arquivo texto com cada linha descrevendo um serviço
que deseja oferecer. Qualquer texto em uma linha seguindo uma “#” é ignorada e considerada um
comentário. Cada linha contém sete campos separados por qualquer número de espaços em branco
(tab ou espaços). O formato geral é o seguinte:
serviço tipo_soquete proto opções.num usuário caminho_serv.
opções_serv.
serviço
É o serviço relevante a este arquivo de configuração pego do arquivo /etc/services.
tipo_soquete
Este campo descreve o tipo do soquete que este item utilizará, valores permitidos são:
stream, dgram, raw, rdm, ou seqpacket. Isto é um pouco técnico de natureza, mas
como uma regra geral, todos os serviços baseados em tcp usam stream e todos os
protocolos baseados em udp usam dgram. Somente alguns tipos de daemons especiais de
servidores usam os outros valores.
protocolo
O protocolo é considerado válido para esta item. Isto deve bater com um item apropriado no
arquivo /etc/services e tipicamente será tcp ou udp. Servidores baseados no Sun RPC
(Remote Procedure Call), utilizam rpc/tcp ou rpc/udp.
opções
Existem somente duas configurações para este campo. A configuração deste campo diz ao
inetd se o programa servidor de rede libera o soquete após ele ser iniciado e então se inetd
pode iniciar outra cópia na próxima requisição de conexão, ou se o inetd deve aguardar e
assumir que qualquer servidor já em execução pegará a nova requisição de conexão.
Este é um pequeno truque de trabalho, mas como uma regra, todos os servidores tcp devem
ter este parâmetro ajustado para nowait e a maior parte dos servidores udp deve tê-lo ajustado
para wait. Foi alertado que existem algumas excessões a isto, assim deixo isto como exemplo
se não estiver seguro.
O número especificado após o “.” é opcional e define a quantidade máxima de vezes que o
serviço poderá ser executado durante 1 minuto. Se o serviço for executado mais vezes do que
este valor, ele será automaticamente desativado pelo inetd e uma mensagem será mostrada no
log do sistema avisando sobre o fato.
Para reativar o serviço interrompido, reinicie o inetd com: killall -HUP inetd. O
valor padrão é 40.
usuário
Este campo descreve que conta de usuário usuário no arquivo /etc/passwd será escolhida
como dono do daemon de rede quando este for iniciado. Isto é muito útil se você deseja
diminuir os riscos de segurança. Você pode ajustar o usuário de qualquer item para o usuário
nobody, assim se a segurança do servidor de redes é quebrada, a possibilidade de problemas é
minimizada. Normalmente este campo é ajustado para root, porque muitos servidores
requerem privilégios de usuário root para funcionarem corretamente.
caminho_servidor
Este campo é o caminho para o programa servidor atual que será executado.
argumentos_servidor
Este campo inclui o resto da linha e é opcional. Você pode colocar neste campo qualquer
argumento da linha de comando que deseje passar para o daemon servidor quando for
iniciado.
Uma dica que pode aumentar significativamente a segurança de seu sistema é comentar (colocar
uma #no inicio da linha) os serviços que não serão utilizados.
Abaixo um modelo de arquivo /etc/inetd.conf usado em sistemas Debian:
# /etc/inetd.conf: veja inetd(8) para mais detalhes.
#
# Banco de Dados de configurações do servidor Internet
#
#
# Linhas iniciando com “#:LABEL:” ou “#<off>#” não devem
# ser alteradas a não ser que saiba o que está fazendo!
#
#
# Os pacotes devem modificar este arquivo usando update-inetd(8)
#
# <nome_serviço> <tipo_soquete> <proto> <opções> <usuário>
<caminho_servidor> <args>
#
#:INTERNO: Serviços internos
#echo stream tcp nowait root internal
#echo dgram udp wait root internal
#chargen stream tcp nowait root internal
#chargen dgram udp wait root internal
#discard stream tcp nowait root internal
#discard dgram udp wait root internal
#daytime stream tcp nowait root internal
#daytime dgram udp wait root internal
time stream tcp nowait root internal
#time dgram udp wait root internal
#:PADRÕES: Estes são serviços padrões.
#:BSD: Shell, login, exec e talk são protocolos BSD.
#shell stream tcp nowait root /usr/sbin/tcpd
/usr/sbin/in.rshd
#login stream tcp nowait root /usr/sbin/tcpd
/usr/sbin/in.rlogind
#exec stream tcp nowait root /usr/sbin/tcpd
/usr/sbin/in.rexecd
talk dgram udp wait.10 nobody.tty /usr/sbin/tcpd
/usr/sbin/in.talkd
ntalk dgram udp wait.10 nobody.tty /usr/sbin/tcpd
/usr/sbin/in.ntalkd
#:MAIL: Mail, news e serviços uucp.
smtp stream tcp nowait.60 mail /usr/sbin/exim
exim -bs
#:INFO: Serviços informativos
#:BOOT: O serviço Tftp é oferecido primariamente para a inicialização.
Alguns sites
# o executam somente em máquinas atuando como “servidores de
inicialização”.
#:RPC: Serviços baseados em RPC
#:HAM-RADIO: serviços de rádio amador
#:OTHER: Outros serviços
4.8 Segurança da Rede e controle de Acesso
Deixe-me iniciar esta seção lhe alertando que a segurança da rede em sua máquina e ataques
maliciosos são uma arte complexa. Uma regra importante é: “Não ofereça serviços de rede que não
deseja utilizar”.
Muitas distribuições vem configuradas com vários tipos de serviços que são iniciados
automaticamente. Para melhorar, mesmo que insignificantemente, o nível de segurança em seu
sistema você deve editar se arquivo /etc/inetd.conf e comentar (colocar uma “#”) as linhas
que contém serviços que não utiliza.
Bons candidatos são serviços tais como: shell, login, exec, uucp, ftp e serviços de
informação tais como finger, netstat e sysstat.
Existem todos os tipos de mecanismos de segurança e controle de acesso, eu descreverei os mais
importantes deles.
4.8.1 /etc/ftpusers
O arquivo /etc/ftpusers é um mecanismo simples que lhe permite bloquear a conexão de
certos usuários via ftp. O arquivo /etc/ftpusers é lido pelo programa daemon ftp (ftpd)
quando um pedido de conexão é recebido. O arquivo é uma lista simples de usuários que não tem
permissão de se conectar. Ele se parece com:
# /etc/ftpusers – login de usuários bloqueados via ftp
root
uucp
bin
mail
4.8.2 /etc/securetty
O arquivo /etc/securetty lhe permite especificar que dispositivos tty que o usuário root
pode se conectar. O arquivo /etc/securetty é lido pelo programa login (normalmente
/bin/login). Seu formato é uma lista de dispositivos tty onde a conexão é permitida, em todos
os outros, a entrada do usuário root é bloqueada.
# /etc/securetty – terminais que o usuário root pode se conectar
tty1
tty2
tty3
tty4
4.8.3 O mecanismo de controle de acessos tcpd
O programa tcpd que você deve ter visto listado no mesmo arquivo /etc/inetd.conf,
oferece mecanismos de registro e controle de acesso para os serviços que esta configurado para
proteger. Ele é um tipo de firewall simples e fácil de configurar que pode evitar tipos indesejados de
ataques e registrar possíveis tentativas de invasão.
Quando é executado pelo programa inetd, ele lê dos arquivos contendo regras de acesso e permite
ou bloqueia o acesso ao servidor protegendo adequadamente.
Ele procura nos arquivos de regras até que uma regra confira. Se nenhuma regra conferir, então ele
assume que o acesso deve ser permitido a qualquer um. Os arquivos que ele procura em seqüência
são: /etc/hosts.allow e /etc/hosts.deny. Eu descreverei cada um destes arquivos
separadamente.
Para uma descrição completa desta facilidade, você deve verificar a página de manual apropriada
(hosts_access (5) é um bom ponto de partida).
4.8.3.1 /etc/hosts.allow
O arquivo /etc/hosts.allow é um arquivo de configuração do programa
/usr/sbin/tcpd. O arquivo hosts.allow contém regras descrevendo que hosts tem
permissão de acessar um serviço em sua máquina.
O formato do arquivo é muito simples:
# /etc/hosts.allow
#
# lista de serviços: lista de hosts : comando
lista de serviços
É uma lista de nomes de serviços separados por vírgula que esta regra se aplica. Exemplos de
nomes de serviços são: ftpd, telnetd e fingerd.
lista de hosts
É uma lista de nomes de hosts separada por vírgula. Você também pode usar endereços IP’s
aqui. Adicionalmente, você pode especificar nomes de computadores ou endereço IP usando
caracteres coringas para atingir grupos de hosts.
Exemplos incluem: gw.vk2ktj.ampr.org para conferir com um endereço de
computador específico, .uts.edu.au para atingir qualquer endereço de computador
finalizando com aquele string. Use 200.200.200. para conferir com qualquer endereço IP
iniciando com estes dígitos. Existem alguns parâmetros especiais para simplificar a
configuração, alguns destes são: ALL atinge todos endereços, LOCAL atinge qualquer
computador que não contém um “.” (ie. está no mesmo domínio de sua máquina) e
PARANOID atinge qualquer computador que o nome não confere com seu endereço
(falsificação de nome). Existe também um último parâmetro que é também útil: o parâmetro
EXCEPT lhe permite fazer uma lista de exceções. Isto será coberto em um exemplo adiante.
comando
É um parâmetro opcional. Este parâmetro é o caminho completo de um comando que deverá
ser executado toda a vez que esta regra conferir. Ele pode executar um comando para tentar
identificar quem esta conectado pelo host remoto, ou gerar uma mensagem via E-Mail ou
algum outro alerta para um administrador de rede que alguém está tentando se conectar.
Existem um número de expansões que podem ser incluídas, alguns exemplos comuns são: %h
expande o endereço do computador que está conectado ou endereço se ele não possuir um
nome, %d o nome do daemon sendo chamado.
Se o computador tiver permissão de acessar um serviço através do /etc/hosts.allow, então o
/etc/hosts.deny não será consultado e o acesso será permitido.
Como exemplo:
# /etc/hosts.allow
#
# Permite que qualquer um envie e-mails
in.smtpd: ALL
# Permitir telnet e ftp somente para hosts locais e myhost.athome.org.au
in.telnetd, in.ftpd: LOCAL, myhost.athome.org.au
# Permitir finger para qualquer um mas manter um registro de quem é
in.fingerd: ALL: (finger @%h | mail -s “finger from %h” root)
Qualquer modificação no arquivo /etc/hosts.allow entrará em ação após reiniciar o daemon
inetd. Isto pode ser feito com o comando kill -HUP [pid do inetd], o pid do inetd pode
ser obtido com o comando ps ax|grep inetd.
4.8.3.2 /etc/hosts.deny
O arquivo /etc/hosts.deny é um arquivo de configuração das regras descrevendo quais
computadores não tem a permissão de acessar um serviço em sua máquina.
Um modelo simples deste arquivo se parece com isto:
# /etc/hosts.deny
#
# Bloqueia o acesso de computadores com endereços suspeitos
ALL: PARANOID
#
# Bloqueia todos os computadores
ALL: ALL
A entrada PARANOID é realmente redundante porque a outra entrada nega tudo. Qualquer uma
destas linhas pode fazer uma segurança padrão dependendo de seu requerimento em particular.
Tendo um padrão ALL: ALL no arquivo /etc/hosts.deny e então ativando especificamente os serviços
e permitindo computadores que você deseja no arquivo /etc/hosts.allow é a configuração
mais segura.
Qualquer modificação no arquivo /etc/hosts.deny entrará em ação após reiniciar o daemon
inetd. Isto pode ser feito com o comando kill -HUP [pid do inetd], o pid do inetd pode
ser obtido com o comando ps ax|grep inetd.
4.8.3.3 /etc/hosts.equiv e /etc/shosts.equiv
O arquivo /etc/hosts.equiv é usado para garantir/bloquear certos computadores e usuários o
direito de acesso aos serviços “r*” (rsh, rexec, rcp, etc) sem precisar fornecer uma senha. O
/etc/shosts.equiv é equivalente mas é lido somente pelo serviço ssh. Esta função é útil em
um ambiente seguro onde você controla todas as máquinas, mesmo assim isto é um perigo de
segurança (veja nas observações). O formato deste arquivo é o seguinte:
#Acesso Máquina Usuário
– maquina2.dominio.com.br usuario2
– maquina4.dominio.com.br usuario2
+ maquina1.dominio.com.br +@usuarios
O primeiro campo especifica se o acesso será permitido ou negado caso o segundo e terceiro campo
confiram. Por razões de segurança deve ser especificado o FQDN no caso de nomes de máquinas.
Grupos de rede podem ser especificados usando a sintaxe “+@grupo”.
Para aumentar a segurança, não use este mecanismo e encoraje seus usuários a também não usar o
arquivo .rhosts.
ATENÇÃO O uso do sinal “+” sozinho significa permitir acesso livre a qualquer pessoa de
qualquer lugar. Se este mecanismo for mesmo necessário, tenha muita atenção na especificação de
seus campos.
Evita também A TODO CUSTO uso de nomes de usuários (a não ser para negar o acesso), pois é
fácil forjar o login, entrar no sistema tomar conta de processos (como por exemplo do servidor
Apache rodando sob o usuário www-data ou até mesmo o root), causando enormes estragos.
4.8.3.4 Verificando a segurança do TCPD e a sintaxe dos arquivos
O utilitário tcpdchk é útil para verificar problemas nos arquivos hosts.allow e
hosts.deny. Quando é executado ele verifica a sintaxe destes arquivos e relata problemas, caso
eles existam.
Outro utilitário útil é o tcpdmatch, o que ele faz é permitir que você simule a tentativa de
conexões ao seu sistema e observar ser ela será permitida ou bloqueada pelos arquivos
hosts.allow e hosts.deny.
É importante mostrar na prática como o tcpdmatch funciona através de um exemplo simulando
um teste simples em um sistema com a configuração padrão de acesso restrito:
• O arquivo hosts.allow contém as seguintes linhas:
ALL: 127.0.0.1
in.talkd, in.ntalkd: ALL
in.fingerd: 192.168.1. EXCEPT 192.168.1.30
A primeira linha permite o loopback (127.0.0.1) acessar qualquer serviço TCP/UDP em
nosso computador, a segunda linha permite qualquer um acessar os servidor TALK (nós
desejamos que o sistema nos avise quando alguém desejar conversar) e a terceira somente
permite enviar dados do finger para computadores dentro de nossa rede privada (exceto
para 192.168.1.30).
• O arquivo hosts.deny contém a seguinte linha:
ALL: ALL
Qualquer outra conexão será explicitamente derrubada.
Vamos aos testes, digitando: “tcpdmatch in.fingerd 127.0.0.1” (verificar se o endereço 127.0.0.1 tem
acesso ao finger):
client: address 127.0.0.1
server: process in.fingerd
matched: /etc/hosts.allow line 1
access: granted
Ok, temos acesso garantido com especificado pela linha 1 do hosts.allow (a primeira linha que
confere é usada). Agora “tcpdmatch in.fingerd 192.168.1.29”:
client: address 192.168.1.29
server: process in.fingerd
matched: /etc/hosts.allow line 3
access: granted
O acesso foi permitido através da linha 3 do hosts.allow. Agora “tcpdmatch in.fingerd
192.168.1.29”:
client: address 192.168.1.30
server: process in.fingerd
matched: /etc/hosts.deny line 1
access: denied
O que aconteceu? como a linha 2 do hosts.allow permite o acesso a todos os computadores
192.168.1.* exceto 192.168.1.30, ela não bateu, então o processamento partiu para o hosts.deny
que nega todos os serviços para qualquer endereço. Agora um último exemplo: “tcpdmatch in.talkd
www.debian.org”
client: address www.debian.org
server: process in.talkd
matched: /etc/hosts.allow line 2
access: granted
Ok, na linha 2 qualquer computador pode te chamar para conversar via talk na rede, mas para o
endereço DNS conferir com um IP especificado, o GNU/Linux faz a resolução DNS, convertendo
o endereço para IP e verificando se ele possui acesso.
No lugar do endereço também pode ser usado a forma daemon@computador ou
cliente@computador para verificar respectivamente o acesso de daemons e cliente de
determinados computadores aos serviços da rede.
Como pode ver o TCPD ajuda a aumentar a segurança do seu sistema, mas não confie nele além do
uso em um sistema simples, é necessário o uso de um firewall verdadeiro para controlar
minuciosamente a segurança do seu sistema e dos pacotes que atravessam os protocolos, roteamento
e as interfaces de rede. Se este for o caso aprenda a trabalhar a fundo com firewalls e implemente a
segurança da sua rede da forma que melhor planejar.
4.8.4 Firewall
Dentre todos os métodos de segurança, o Firewall é o mais seguro. A função do Firewall é bloquear
determinados tipos de tráfego de um endereço ou para uma porta local ou permitir o acesso de
determinados usuários mas bloquear outros, bloquear a falsificação de endereços, redirecionar
tráfego da rede, ping da morte, etc.
A implementação de um bom firewall dependerá da experiência, conhecimentos de rede
(protocolos, roteamento, interfaces, endereçamento, masquerade, etc), da rede local, e sistema em
geral do Administrador de redes, a segurança de sua rede e seus dados dependem da escolha do
profissional correto, que entenda a fundo o TCP/IP, roteamento, protocolos, serviços e outros
assuntos ligados a rede.
Freqüentemente tem se ouvido falar de empresas que tiveram seus sistemas invadidos, em parte isto
é devido a escolha do sistema operacional indevido mas na maioria das vezes o motivo é a falta de
investimento da empresa em políticas de segurança, que algumas simplesmente consideram a
segurança de seus dados e sigilo interno como uma despesa a mais.
Um bom firewall que recomendo é o ipchains, Sinus e o TIS. Particularmente gosto muito de
usar o ipchains e o Sinus e é possível fazer coisas inimagináveis programando scripts para
interagirem com estes programas…
4.9 Outros arquivos de configuração relacionados com a rede
4.9.1 /etc/services
O arquivo /etc/services é um banco de dados simples que associa um nome amigável a
humanos a uma porta de serviço amigável a máquinas. É um arquivo texto de formato muito
simples, cada linha representa um item no banco de dados. Cada item é dividido em três campos
separados por qualquer número de espaços em branco (tab ou espaços). Os campos são:
nome porta/protocolo apelido # comentário
name
Uma palavra simples que representa o nome do serviço sendo descrito.
porta/protocolo
Este campo é dividido em dois sub-campos.
• porta – Um número que especifica o número da porta em que o serviço estará
disponível. Muitos dos serviços comuns tem designados um número de serviço. Estes
estão descritos no RFC-1340.
• protocolo – Este sub-campo pode ser ajustado para tcp ou udp. É importante notar
que o item 18/tcp é muito diferente do item 18/udp e que não existe razão técnica
porque o mesmo serviço precisa existir em ambos. Normalmente o senso comum
prevalece e que somente se um serviço esta disponível em ambos os protocolos tcp e
udp, você precisará especificar ambos.
apelidos
Outros nomes podem ser usados para se referir a entrada deste serviço.
comentário
Qualquer texto aparecendo em uma linha após um caracter “#” é ignorado e tratado como
comentário.
4.9.2 /etc/protocols
O arquivo /etc/protocols é um banco de dados que mapeia números de identificação de
protocolos novamente em nomes de protocolos. Isto é usado por programadores para permiti-los
especificar protocolos por nomes em seus programas e também por alguns programas tal como
tcpdump permitindo-os mostrar nomes ao invés de números em sua saída. A sintaxe geral deste
arquivo é:
nomeprotocolo número apelidos
4.10 Camadas de Rede
São organizações do protocolo TCP/IP que visam organizar e simplificar seu padrão e
implementação pelos desenvolvedores.
• Um padrão TCP é o conjunto de regras que devem ser seguidas para garantir a
homogeneidade da comunicação entre diversos sistemas de diversos fabricantes (por
exemplo, Mac com Windows, Windows com Linux, etc.).
• A implementação é o código escrito por cada desenvolvedor para integração ao sistema
operacional seguindo as regras do padrão para garantir a comunicação entre as máquinas,
portanto, a implementação do protocolo TCP varia de fabricante para fabricante.
Existem dois tipos de padrões TCP: Darpa e OSI. O padrão Darpa é dividido em 4 camadas e ainda
é o padrão atualmente utilizado. O padrão OSI é mais recente, dividido em 7 camadas, mas ainda
não se tornou um padrão como o Darpa.
Segue abaixo os padrões e a descrição de cada uma das camadas:
Darpa
• Aplicação – www, ftp, dns, etc. Fazem interface com as aplicações do sistema.
• Transporte – Protocolo tcp e udp. Cuidam da parte de transporte dos dados do
sistema.
• Rede – IP, icmp, igmp, arp. Cuida de levar o pacote para seu destino (rotas) e
condições de transmissão.
• Interface de Rede – Ethernet, FDDI, Token Ring. Define qual o método que a
mensagem transmitida será encapsulada para envio ao seu destino.
Apesar dos padrões Darpa e OSI, o protocolo TCP/IP é oficialmente independente destas camadas.
4.11 RFCs de referência sobre protocolos de rede
Como referência de pesquisa, segue abaixo a listagem de números de RFCs para protocolos de rede
mais utilizados:
IP
http://www.rfc-editor.org/rfc/rfc791.txt
ICMP
http://www.rfc-editor.org/rfc/rfc792.txt
TCP
http://www.rfc-editor.org/rfc/rfc793.txt
UDP
http://www.rfc-editor.org/rfc/rfc768.txt

Arquitetura de Core Centralizada x Core Distribuída

 Clusterweb, Linux, Redes  Comentários desativados em Arquitetura de Core Centralizada x Core Distribuída
jul 182012
 

Tradicionalmente, as redes ethernet (tanto para Data Center como para campus LAN), respeitam um modelo hierárquico de arquitetura chamado “three tier layer”, onde há uma camada de core (núcleo), distribution (distribuição) e access (acesso). Cada uma dessas camadas define uma função específica.

Via de regra, a camada de acesso é utilizada para prover a conexão dos dispositivos de rede dos usuários finais (desktops, laptops, impressoras, pontos de acesso wireless, etc.) à rede propriamente dita.

A camada de distribuição, é utilizada no sentido de prover o roteamento e a agregração entre as VLANs dos usuários nas camadas de acesso. É nesse camada onde se definem listas de acesso, regras de segurança, políticas de roteamento entre VLANs, etc.

Por fim, a camada de núcleo (core) é a cada responsável por agregar tudo isso e fazer o “hand off” da rede para o mundo externo. Via de regra, nessa camada se conectam os roteadores, firewalls e todos os dispositivos responsáveis pela interconexão do mundo LAN para o mundo WAN (ou outras redes fora de uma determinada rede LAN). A figura abaixo, ilustra o conceito da arquitetura “three tier”:

Notem que por uma questão de redundância e alta disponibilidade da rede, todos os switches (ilustrados pelos quadrados) possuem duas conexões para a camada vizinha: se uma conexão falhar, a outra pode assumir todo o tráfego sem problemas.

Além da arquitetura “three tier”, há uma adaptação desse desenho, chamado de “two tier”. A idéia é similar à da primeira. Porém justifica-se utilizá-la em redes menores (até 500 pontos na camada de acesso). Nesse caso, a camada de core e distribution serão “colapsadas” em uma única camada. Assim:

Mesmo nesse desenho, a idéia da redundância para alta disponibilidade continua presente: tenho dois links para a camada de cima. Se um falhar, o outro assume o tráfego.

Alguém nessa altura do texto (espero que sim) poderia se perguntar: se a idéia é prover redundância de conectividade, porque não aumentar o número de links entre as camadas? Porque manter só dois links entre um elemento de uma camada e o outro de outra, sendo que eu poderia fazer 3, 4, ou 5 links?

Antes de responder o porquê, vale uma observação: mesmo que não houvesse restrição tecnológica para usarmos mais de dois links, valeria a pena financeiramente falando? Em redes de data Center, estou certo que sim. Em redes campus LAN (para usuário final), a resposta pode não ser tão óbvia…

Mas, voltando à tecnologia: lembram-se do Spanning Tree Protocol? O protocolo que limitava a utilização dos meus links entre as camadas da rede hierárquica, com o intuito de evitar as “broadcast storms”? A resposta do porquê não fazer mais de dois links entre as camadas está aí.

Lembrem-se que o Spanning Tree é um protocolo que deixava um link habilitado (funcionando) e o outro em “stand by” (aguardando uma possível falha no primeiro). Essa é uma limitação do protocolo. Dessa forma, um switch que está na camada de acesso conectado por dois links a dois switches de distribuição (ou core) distintos, estará de fato utilizando apenas um link. O outro está esperando a falha do primeiro para entrar em ação. Na figura abaixo, a linha inteira representa o link ativo. A linha pontilhada, o link bloqueado. A mesma idéia se multiplica por todos os “n” dispositivos conectados às camadas da rede (não importa qual).

Se fizéssemos 3, 4 ou 5 links, a mesma coisa aconteceria: apenas um link estaria ativo. Todos os outros ficariam parados. Dessa forma, não faria sentido adicionar tantos links quanto fossem possíveis, já que você só continuaria utilizando apenas um de fato.

Até aqui falamos do desenho tradicional de redes Ethernet hierárquicas (em três em duas camadas). Em resumo, podemos relacionar algumas das suas características principais:

  • Links entre as camadas sempre feito em dois uplinks: um ativo, um bloqueado (em stand by, aguardando a falha do primeiro link).
  • Protocolo Spanning Tree presente: previne os loops de broadcast na rede, porém reduz sua capacidade instalada de utilização simultânea de uplinks (em fibra óptica ou pares metálicos)  em 50%. Além disso, num ambiente com múltiplos domínios de broadcast (VLANs), configurar spanning tree pode ser algo desafiador… (usa-se nesse caso o PVSTP – per VLAN Spanning Tree Protocol)
  • Switches de core e/ou distribuição do tipo “chassis”: dada a necessidade de alta concentração de portas nessas camadas, switches de configuração de portas fixas podem não oferecer um número de portas suficientes para conectar todo mundo que está logo abaixo. Além disso, essas equipamentos oferecem um nível de redundância intrínseca à sua própria arquitetura de hardware. Via de regra, é possível configurá-los com duas placas de processamento (Supervisor como gostam de chamar os Cisco Guys, Management Module como gostam de chamar os Brocade Guys, Route Engine como gostam de chamar os Juniper Guys…), várias fontes de energia redundantes, coolers redundantes e por aí vai…

Mas… e se fosse criado um protocolo que endereçasse todas as ineficiências do Spanning Tree protocol. Onde fosse possível fazer plena utilização dos meus recursos de uplink (inclusive se eu quisesse utilizar mais de dois), tudo funcionando na camada 2 (Ethernet mesmo) sem ter que apelar para uma segmentação através de endereçamento IP (o que pode ser trabalhoso também) e sem correr o risco de ver minha rede com loops infinitos de broadcast “comendo” os meus uplinks e processadores dos switches?

A boa notícia: esse protocolo já existe! Trata-se do TRILL – Transparent Interconnect of Lots of Links. Esse protocolo permite o conceito de core distribuído (onde é possível colocarmos mais de dois switches na camada de core com utilização de todos os uplinks entre as camadas que compõe a rede).

O TRILL reúne em um único protocolo as vantagens da comutação (feita em camada 2) com as vantagens do roteamento (feito em camada 3). Além disso, para evitar eventuais loops de broadcast, utiliza um conceito extremamente simples que já é utilizado hoje pelo protocolo IP – o conceito de hop count – cada vez que um quadro de dados passa por um switch, um campo de hop count é decrementado. Quando esse valor chega a zero, o switch descarta o pacote (no IP esse campo é chamado de TTL – time to live)

Por conta de incorporar conceitos de comutação e roteamento em um único dispositivo, os switches são comumente referenciados como RBridges (Route-Bridges) na terminologia do protocolo TRILL.

E já que estamos falando em terminologia, nas redes de core distribuído as camadas são chamadas de camadas de SPIN e LEAF.

Além disso, o TRILL utiliza um protocolo do tipo “link state” para fazer o roteamento entre os nós da rede. Trata- se do IS-IS (Intermediate System to Intemediate System). Porém, ao invés de roteamento de endereços IP, ele faz o roteamento de endereços físicos, ou seja: roteamento de MAC ADDRESS!!!

Portanto, podemos dizer que o TRILL é um protocolo da camada 2,5: ele opera na camada 2, porém utiliza recursos de camada 3 para funcionar!

Além disso, o TRILL possibilita o que era impensável em redes hierárquicas tradicionais usando Spanning Tree protocol – a utilização do conceito de ECPM – Equal Cost Multi Path – que nada mais é do poder encaminhar as informações entre as camadas e nós através de diversos links simultaneamente  – fazendo assim, load balance entre os diversos links que interligam as camadas da topologia.

Em resumo, com TRILL, é possível criar redes com topologias assim:

Note que cada switch da camda de leaf (a de baixo), possui uma conexão para cada elemento da camada de spin (a de cima). Isso cria o conceito da rede ethernet full fabric. E note que, se eventualmente um dos switches da camada de spin falhar, os demais continuam suportando o tráfego que vem dos equipamentos da camada de leaf, sem comprometer o funcionamento da rede. Além disso, todos os links estão em pleno funcionamento: sem bloqueios!

Em resumo, nas redes TRILL encontraremos as seguintes características:

  • utilização plena de todos os recursos de links entre as camadas de SPIN e LEAF
  • pode-se utilizar switches “mais simples” no que diz respeito ao nível de redundância de hardware – já que todos os switches participam no processo de composição do core distribuído, restam vários outros que podem assumir a função daquele que falhar.
  • interoperabilidade com as redes hierárquicas legadas (que ainda estão rodando Spanning Tree).

O assunto é extenso e há muitos outros detalhes envolvidos. A idéia aqui é mostrar como está evoluindo o desenho de soluções de rede Ethernet e quais são as alternativas aos desenhos tradicionais. Há ainda muitos paradigmas a serem quebrados (principalmente quando falamos em aposentar os grandes switches chassis de rede, que passam uma sensação de segurança muito grande dada a sua alta redundância de hardware). Mas, definitivamente, é uma tendência para os próximos Data Centers que vem por aí.

Tipos de emendas Fibra Óptica

 Clusterweb  Comentários desativados em Tipos de emendas Fibra Óptica
jan 202012
 

Emenda óptica consiste em uma junção permanente ou temporária de duas ou mais segmentos de fibras.  Serve para aumentar a extensão de um cabo óptico, fazer a mudança de tipo de cabo, conectar um equipamento ativo ou fazer manobras em um sistema de cabeamento estruturado.

Existem três tipos de emendas:

Emenda ótica por Fusão

 

Emenda por Fusão

Este processo não é exatamente simples ou rápido, e como o próprio nome diz, consiste em “fundir” uma fibra óptica à outra.

Neste tipo de emenda a fibra é introduzida limpa e clivada na máquina de fusão, para após o alinhamento apropriado, ser submetida à um arco voltáico que eleva a temperatura nas faces das fibras, o que provoca o derretimento das fibras e a sua soldagem. O arco voltáico é obtido a partir de uma diferença de potencial aplicada sobre dois eletrodos de metal. Após a fusão a fibra é revestida por resinas que tem a função de oferecer resistência mecânica à emenda, protegendo-a contra quebras e fraturas.

Após a proteção a fibra emendada é acomodada em recipientes chamados caixa de emendas. As caixas de emendas podem ser de vários tipos de acordo com a aplicação e o número de fibras. Umas são pressurizáveis ou impermeáveis, outras resistentes ao sol, para instalação aérea.

O custo de todo o material necessário para este tipo de emenda é alto, pois o processo de “Emenda Óptica por Fusão” exige um custo alto de investimento nos equipamentos para a sua operação. Entretanto, este processo agiliza as instalações e garante uma grande confiabilidade no sistema.

A clivagem, acima citada, é o processo de corte da ponta da fibra óptica. É efetuada a partir de um pequeno ferimento na casca da fibra óptica (risco), a fibra é tracionada e curvada sob o risco, assim o ferimento se propaga pela estrutura cristalina da fibra. A qualidade de uma clivagem deve ser observada com microscópio.

Emenda Mecânica

Emenda óptica Mecânica

Este tipo de emenda é baseado no alinhamento das fibras através de estruturas mecânicas (desenvolvidas para tal finalidade), que mantém estas fibras posicionadas frente a frente, sem uni-las definitivamente. Neste tipo de emenda as fibras também devem ser limpas e clivadas. Este tipo de emenda é recomendado para um número reduzido de emendas a realizar, pois o custo desses dispositivos é relativamente barato, além de serem reaproveitáveis, porém não é aconselhável utilizá-los em sistemas que exijam uma grande confiabilidade.

 

Emenda óptica por Conectorização

Emenda por Conectorização

Este processo é bem semelhante ao processo de Emenda Mecânica, onde duas fibras devem ser alinhadas e não unidas. Entretanto, em cada fibra é colocado um conector óptico e estes dois conectores são encaixados em um acoplador óptico de modo a tornar possível o alinhamento entre as fibras, sem uni-las definitivamente.

Isto é conseguido através do uso de outro tipo de conector chamado de Adaptador Óptico, esta emenda é executada de forma rápida, desde que os conectores já estejam instalados nos cordões ópticos.

Ele é também muito usado em acessórios ópticos chamados de Distribuidores Ópticos, onde fazem a interface entre um cabo vindo de uma sala de equipamentos e os equipamentos ativos instalados no andar, no Armário de Telecomunicações.

Veja os tipos de conectores para esta emenda clicando aqui.

Topologia de Rede.

 Redes  Comentários desativados em Topologia de Rede.
jan 122012
 

Projeto da Topologia da Rede

  • Uma topologia é um mapa de uma rede que indica segmentos de rede (redes de camada 2), pontos de interconexão e comunidades de usuários
  • Queremos projetar a rede logicamente e não fisicamente
    • Identificam-se redes, pontos de interconexão, o tamanho e alcance de redes e o tipo de dispositivos de interconexão
    • Não lidamos (ainda) com tecnologias específicas, dispositivos específicos, nem considerações de cabeamento
  • Nosso objetivo é projetar uma rede segura, redundante e escalável

Projeto hierárquico de uma rede

  • Antigamente, usava-se muito uma rede com estrutura chamada Collapsed Backbone
    • Toda a fiação vai das pontas para um lugar central (conexão estrela)
    • O número de fios não era problemático quando as pontas usavam “shared bandwidth” com cabo coaxial em vez de hubs ou switches
    • Oferece facilidade de manutenção
    • Ainda é bastante usado
  • Hoje, com rede maiores, usa-se cada vez mais uma estrutura hierárquica
  • Um modelo hierárquico ajuda a desenvolver uma rede em pedaços, cada pedaço focado num objetivo diferente
  • Um exemplo de uma rede hierárquica aparece abaixo
  • As 3 camadas mostradas:
    • Camada core: roteadores e switches de alto desempenho e disponibilidade
    • Camada de distribuição: roteadores e switches que implementam políticas
    • Camada de acesso: conecta usuários com hubs e switches

redehierarquica.gif (20045 bytes)

Por que usar um modelo hierárquico?

  • Uma rede não estruturada (espaguete) cria muitas adjacências entre equipamentos
    • Ruim para propagação de rotas
  • Uma rede achatada (camada 2) não é escalável devido ao broadcast
  • Minimiza custos, já que os equipamentos de cada camada serão especializados para uma determinada função
    • Exemplo: Usa switches rápidos no core block, sem features adicionais
  • Mais simples de entender, testar e consertar
  • Facilita  mudanças, já que as interconexões são mais simples
  • A replicação de elementos de torna mais simples
  • Permite usar protocolos de roteamento com “sumarização de rotas”
  • Comparação de estrutura hierárquica com a plana para a WAN
    • Pode-se usar um loop de roteadores
      • OK para redes pequenas
      • Para redes grandes, o tráfego cruza muitos hops (atraso mais alto)
      • Qualquer quebra é fatal

flatloop.gif (6928 bytes)

  • Roteadores redundantes numa hierarquia dão:
    • Mais escalabilidade
    • Mais disponibilidade
    • Atraso mais baixo

wanhierarquica.gif (9802 bytes)

  • Comparação de estrutura hierárquica com plana para a LAN
    • O problema básico é que um domínio de broadcast grande reduz significativamente o desempenho
    • Com uma rede hierárquica, os equipamentos apropriados são usados em cada lugar
      • Roteadores (ou VLANs e switches de camada 3) são usados para delimitar domínios de broadcast
      • Switches de alto desempenho são usados para maximizar banda passante
      • Hubs são usados onde o acesso barato é necessário
  • Topologias de full-mesh e mesh hierárquica
    • A full-mesh oferece excelente atraso e disponibilidade mas é muito cara
    • Uma alternativa mais barata é uma mesh parcial
    • Um tipo de mesh parcial é a mesh hierárquica, que tem escalabilidade mas limita as adjacências de roteadores
    • Para pequenas e médias empresas, usa-se muito a topologia hub-and-spokefullmesh.gif (9134 bytes)

Topologia Full Mesh

meshparcial.gif (8854 bytes)

Topologia Mesh Parcial

hubandspoke.gif (7506 bytes)

Topologia Hub-and-Spoke

O modelo hierárquico clássico em 3 camadas

  • Permite a agregação (junção) de tráfego em três níveis diferentes
  • É um modelo mais escalável para grandes redes corporativas
  • Cada camada tem um papel específico
    • Camada core: provê transporte rápido entre sites
    • Camada de distribuição: conecta as folhas ao core e implementa políticas
      • Segurança
      • Roteamento
      • Agregação de tráfego
    • Camada de acesso
      • Numa WAN, são os roteadores na borda do campus network
      • Numa LAN, provê acesso aos usuários finais
  • A camada core
    • Backbone de alta velocidade
    • A camada deve ser projetada para minimizar o atraso
    • Dispositivos de alta vazão devem ser escolhidos, sacrificando outros features (filtros de pacotes, etc.)
    • Deve possuir componentes redundantes devida à sua criticalidade para a interconexão
    • O diâmetro deve ser pequeno (para ter baixo atraso)
      • LANs se conectam ao core sem aumentar o diâmetro
    • A conexão à Internet é feita na camada core
  • A camada de distribuição
    • Tem muito papeis
      • Controla o acesso aos recursos (segurança)
      • Controla o tráfego que cruza o core (desempenho)
      • Delimita domínios de broadcast
        • Isso pode ser feito na camada de acesso também
      • Com VLANs, a camada de distribuição roteia entre VLANs
      • Interfaceia entre protocolos de roteamento que consomem muita banda passante na camada de acesso e protocolos de roteamento otimizados na camada core
        • Exemplo: sumariza rotas da camada de acesso e as distribui para o core
        • Exemplo: Para o core, a camada de distribuição é a rota default para a camada de acesso
      • Pode fazer tradução de endereços, se a camada de acesso usar endereçamento privativo
        • Embora o core também possa usar endereçamento privativo
  • A camada de acesso
    • Provê acesso à rede para usuários nos segmentos locais
      • Frequentemente usa apenas hubs e switches

Guia para o projeto hierárquico de uma rede

  • Controle o diâmetro da topologia inteira, para ter atraso pequeno
  • Mantenha controle rígido na camada de acesso
    • É aqui que departamentos com alguma independência implementam suas próprias redes e dificultam a operação da rede inteira
    • Em particular, deve-se evitar:
      • Chains(adicionando uma quarta camada abaixo da camada de acesso)
        • Causam atrasos maiores e dependências maiores de tráfego
        • Chains podem fazer sentido para conectar mais um pais numa rede corporativa
      • Portas-dos-fundos(conexões entre dispositivos para mesma camada)
        • Causam problemas inesperados de roteamento

chainsbackdoors.gif (24049 bytes)

  • Projete a camada de acesso primeiro, depois a camada de distribuição, depois o core
    • Facilita o planejamento de capacidade

Topologias redundantes no projeto de uma rede

  • A disponibilidade é obtida com a redundância de enlaces e dispositivos de interconexão
  • O objetivo é eliminar pontos únicos de falha, duplicando qualquer recurso cuja falha desabilitaria aplicações de missão crítica
  • Pode duplicar enlaces, roteadores importantes, uma fonte de alimentação
    • Em passos anteriores, você deve ter identificado aplicações, sistemas, dispositivos e enlaces críticos
  • Para dispositivos muito importantes, pode-se considerar o uso de componentes “hot-swappable”
  • A redundância pode ser implementada tanto na WAN quanto na LAN
  • Há obviamente um tradeoff com o custo da solução

Caminhos alternativos

  • Para backupear enlaces primários
  • Três aspectos são importantes
    • Qual deve ser a capacidade do enlace redundante?
      • É frequentemente menor que o enlace primário, oferecendo menos desempenho
      • Pode ser uma linha discada, por exemplo
    • Em quanto tempo a rede passa a usar o caminho alternativo
      • Se precisar de reconfiguração manual, os usuários vão sofrer uma interrupção de serviço
      • Failover automático pode ser mais indicado
      • Lembre que protocolos de roteamento descobrem rotas alternativas e switches também (através do protocolo de spanning tree)
    • O caminho alternativo deve ser testado!
      • Não espere que uma catástrofe para descobrir que o caminho alternativo nunca foi testado de não funciona!
      • Usar o caminho alternativa para balanceamento de carga evita isso

Considerações especiais para o projeto de uma topologia de rede de campus

  • Os pontos principais a observar são:
    • Manter domínios de broadcast pequenos
    • Incluir segmentos redundantes na camada de distribuição
    • Usar redundância para servidores importantes
    • Incluir formas alternativas de uma estação achar um roteador para se comunicar fora da rede de camada 2

LANs virtuais

  • Uma LAN virtual (VLAN) nada mais é do que um domínio de broadcast configurável
  • VLANs são criadas em uma ou mais switches
  • Usuários de uma mesma comunidade são agrupados num domínio de broadcast independentemente da cabeação física
    • Isto é, mesmo que estejam em segmentos físicos diferentes
  • Esta flexibilidade é importante em empresas que crescem rapidamente e que não podem garantir que quem participa de um mesmo projeto esteja localizado junto
  • Uma função de roteamento (noemalmente localizada dentro dos switches) é usada para passar de uma VLAN para outra
    • Lembre que cada VLAN é uma “rede de camada 2” e que precisamos passar para a camada 3 (rotear) para cruzar redes de camada 2
  • Há várias formas de agrupar os usuários em VLANs, dependendo das switches usadas
    • Baseadas em portas do switches
    • Baseadas em endereços MAC
    • Baseadas em subnet IP
    • Baseadas em protocolos (IP, NETBEUI, IPX, …)
    • VLAN para multicast
      • VLAN criada dinamicamente pela escuta de pacotes IGMP (Internet Group Management Protocol)
    • VLANs baseadas em políticas gerais (com base em qualquer informação que aparece num quadro)
    • Baseadas no nome dos usuários
      • Com ajuda de um servidor de autenticação

Segmentos redundantes de LAN

  • Enlaces redundantes entre switches sõ desejáveis para aumentar a disponibilidade
  • Laços são evitados usando o protocolo Spanning Tree (IEEE 802.1d)
  • Isso fornece redundância mas não balanceamento de carga
    • O protocolo Spanning Tree corta enlaces redundantes (até que sejam necessários)

Redundância de servidores

  • Servidor DHCP
    • Se usar DHCP, o servidor DHCP se torna crítico e pode ser duplicado
    • Em redes pequenas, o servidor DHCP é colocado na camada de distribuição onde pode ser alcançado por todos
    • Em redes grandes, vários servidores DHCP são colocados na camada de acesso, cada um servindo a uma fração da população
      • Evita sobrecarga de um único servidor
    • DHCP funciona com broadcast
      • Somos obrigados a colocar um servidor DHCP para cada domínio de broadcast?
        • Não, se utilizar uma função do roteador de encaminhar broadcast DHCP para o servidor de broadcast (cujo endereço foi configurado no servidor)
  • Servidor DNS
    • O servidor DNS é crítico para mapear nomes de máquinas a endereços IP
    • Por isso, é frequentemente duplicado

Redundância estação-roteador

  • Para obter comunicação fora da rede de camada 2 imediata, uma estação precisa conhecer um roteador
  • Como implementar redundância aqui?
  • O problema básico é que o IP do roteador que a estação conhece é frequentemente configurado manualmente (“parafusado”) em cada estação
  • Há algumas alternativas
  • Alternativa 1: Proxy ARP
    • A estação não precisa conhecer roteadore nenhum
    • Para se comunicar com qualquermáquina (mesmo remota), a estação usa ARP
      • O roteador responde com seu próprio endereço MAC
    • Proxy ARP é pouco usado porque nunca foi padronizado
  • Alternativa 2: DHCP
    • DHCP pode infromar mais coisas do que apenas o endereço IP da estação
    • Pode informar o roteador a usar (ou até mais de um roteador)
    • Alternativa muito usada
  • Alternativa 3: Hot Standby Router Protocol (HSRP) da Cisco
    • É uma alternativa proprietária, mas a IETF está padronizando algo semelhante chamado Virtual Router Redundancy Protocol (VRRP)
    • HSRP cria um roteador fantasma (que não existe de verdade) e vários roteadores reais, um dos quais está ativo, os outros em standby
    • Os roteadores reais conversam entre si para saber qual é o roteador ativo
    • O roteadore fantasma tem um endereço MAC e os roteadores reais podem aceitar quadros de um bloco de endereços MAC, incluindo o endereço MAC do fantasma
    • O roteador fantasma (que nunca quebra!) é o roteador default das estações
    • Quando uma estação usa ARP para descobrir o MAC do fantasma, o roteador ativa, responde (com o MAC do fantasma)
    • Mas quem realmente atende a este endereço MAC é o roteador ativo
    • Se o roteador ativo mudar, nada muda para a estação (continua conversando com o roteador fantasma)

Considerações especiais para o projeto de uma topologia de rede corporativa

  • Considerações especiais sobre:
    • Segmentos redundantes de WAN
    • Conexões múltiplas à Internet
    • Redes Privativas Virtuais (VPN) para montar redes corporativas baratas

Segmentos redundantes de WAN

  • Uso de uma mesh parcial é normalmente suficiente
  • Cuidados especiais para ter diversidade de circuito
    • Se os enlaces redundantes usam a mesma tecnologia, são fornecidos pelo mesmo provedor, passam pelo mesmo lugar, qual a probabilidade da queda de um implicar na queda de outro?
    • Discutir essa questão com o provedor é importante

Conexões múltiplas à Internet

  • Há 4 alternativas básicas para ter acesso múltiplo à Internet

multiinternet.gif (24227 bytes)

  • Opção A
    • Vantagens
      • Backup na WAN
      • Baixo custo
      • Trabalhar com um ISP pode ser mais fácil do que trabalhar com ISPs múltiplos
    • Desvantagens
      • Não há redundância de ISPs
      • Roteador é um ponto único de falha
      • Supõe que o ISP tem dois pontos de acesso perto da empresa
  • Opção B
    • Vantagens
      • Backup na WAN
      • Baixo custo
      • Redundância de ISPs
    • Desvantagens
      • Roteador é um ponto único de falha
      • Pode ser difícil trabalhar com políticas e procedimentos de dois ISPs diferentes
  • Opção C
    • Vantagens
      • Backup na WAN
      • Bom para uma empresa geograficamente dispersa
      • Custo médio
      • Trabalhar com um ISP pode ser mais fácil do que trabalhar com ISPs múltiplos
    • Desvantagens
      • Não há redundância de ISPs
  • Opção D
    • Vantagens
      • Backup na WAN
      • Bom para uma empresa geograficamente dispersa
      • Redundância de ISPs
    • Desvantagens
      • Alto custo
      • Pode ser difícil trabalhar com políticas e procedimentos de dois ISPs diferentes
  • As opções C e D merecem mais atenção
    • O desempenho pode frequentemente ser melhor se o tráfego ficar na rede corporativa mais tempo antes de entrar na Internet
    • Exemplo: pode-se querer que sites europeus da empresa acessem a Internet pelo roteador de Paris mas acessem sites norte-americanos da empresa pelo roteador de New York
      • A configuração de rotas default nas estações (para acessar a Internet) pode ser feita para implementar essa política
    • Exemplo mais complexo: Queremos que sites europeus da empresa acessem sites norte-americanos da Internet pelo roteador de New York (idem para o roteador de Paris sendo usado para acessar a Internet européia pelos sites norte-americanos da empresa)
      • Fazer isso é mais complexo, pois os roteadores da empresa deverão receber rotas do ISP
    • Exemplo mais complexo ainda: tráfego que vem da Internet para sites norte-americanos da empresa devem entrar na empresa por New York (idem para Paris)
      • Neste caso, a empresa deverá anunciar rotas para a Internet
      • Observe que, para evitar que a empresa se torne um transit network, apenas rotas da própria empresa devem ser anunciados!

Redes privativas virtuais

  • Redes privativas virtuais (VPN) permitem que um cliente utilize uma rede pública (a Internet, por exemplo) para acessar a rede corporativa de forma segura
    • Toda a informação é criptografada
  • Muito útil para montar uma extranet (abrir a intranet para parceiros, clientes, fornecedores, …)
  • Muito útil para dar acesso a usuários móveis da empresa
  • Solução muito usada quando a empresa é pequena e tem restrições de orçamento para montar a rede corporativa
  • A técnica básica é o tunelamento
  • O protocolo básico é Point-to-Point Tunneling Protocol (PPTP)

Topologias de rede para a segurança

  • Falaremos mais de segurança adiante
  • Por enquanto, queremos ver os aspectos topológicos da questão

Planejamento da segurança física

  • Verificar onde os equipamentos serão instalados
  • Prevenção contra acesso não autorizado, roubo físico, vandalismo, etc.

Topologias de firewalls para alcançar requisitos de segurança

  • Um firewall é um sistema que estabelece um limite entre duas ou mais redes
  • Pode ser implementado de várias formas
    • Simples: um roteador com filtro de pacote
    • Mais complexo: software especializado executando numa máquina UNIX ou Windows NT
  • Serve para separar a rede corporativa da Internet
  • A topologia mais básica usa um roteador com filtro de pacote
    • Só é suficiente para uma empresa com política de segurança muito simples

firewall1.gif (3471 bytes)

  • A tabela de filtragem de pacotes poderia ser como segue
    • A primeira regra que casa com cada pacote examinado é aplicada
Ação Host local Porta local Host remoto Porta remota
Nega * * mau.ladrao.com *
Permite mailserver 25 * *
Permite * * * 25
Nega * * * *
  • Para melhorar as coisas, pode-se usar endereçamento privativo na rede corporativa
    • Uso de Network Address Translation (NAT) implementada no roteador para acessar a Internet; ou
    • Uso de um proxy para certos serviços (web, ftp, …)
  • Para empresas que precisam publicar informação na Internet (Web, DNS, FTP, …), pode-se ter algumas máquinas na Internet, numa área chamada Demilitarized Zone (DMZ)
    • Os hosts têm que ser muito bem protegidos contra invasões (Bastion Hosts)
    • Um firewall especializado pode ser incluído
      • Fornece uma boa GUI e ações especiais para implementar a política de segurança
    • Há duas topologias básicas
      • Com um roteador
      • Com dois roteadores

firewall2.gif (7701 bytes)

Topologia com 1 roteador e firewall dedicado

firewall3.gif (7372 bytes)

Topologia com 2 roteadores filtrando pacotes

Configurando rede no Debian

 Clusterweb, Linux  Comentários desativados em Configurando rede no Debian
jan 062012
 

Aqui vai  um exemplo de configuração do arquivo  /etc/network/interfaces.

auto eth0 #arranca automaticamente com a interface de rede.
allow-hotplug eth0 #Faz com que o Debian detecte e aplique as configurações logo que o cabo é ligado ou desligado.
iface eth0 inet static #inicia a configuração estática da rede
address 192.168.0.1 # Define o IP que fica configurado
netmask 255.255.255.0 # Define a Mascara de rede, neste caso de 24Bits
broadcast 192.168.0.255 # Define o Broadcast de Rede
network 192.168.0.0 # Define o Segmento de rede em que está o IP acima indicado.
gateway 192.168.0.254 #Define o Gateway de rede.

Rotas
Instalar o software necessário:
apt-get install iproute
Criação do roteamentos:
ip route add 10.0.0.0/24 via 192.168.0.200
O comando acima indicado cria um roteamento para a rede 10.0.0.0/24 através do Gateway 192.168.0.200.
Para activar este roteamento como estático, basta adicionar ao

/etc/network/interfaces a seguinte linha: up ip route add 10.0.0.0/24 via 192.168.0.200

 

Arquitetura de Redes TCP/IP

 Clusterweb  Comentários desativados em Arquitetura de Redes TCP/IP
jan 052012
 

Introdução

No mundo de hoje, não se pode falar de redes sem falar do TCP/IP. O conjunto de protocolos originalmente desenvolvido pela Universidade da Califórnia em Berkeley, sob contrato para o Departamento de Defesa dos EUA, se tornou o conjunto de protocolos padrão das redes locais e remotas, suplantando conjuntos de protocolos bancados por pesos pesados da indústria, como a IBM (SNA), Microsoft (NetBIOS/NetBEUI) e Novell (IPX/SPX).

O grande motivo de todo este sucesso foi justamente o fato do TCP/IP não ter nenhuma grande empresa associada ao seu desenvolvimento. Isto possibilitou a sua implementação e utilização por diversas aplicações em praticamente todos os tipos de hardware e sistemas operacionais existentes.

Mesmo antes do boom da Internet o TCP/IP já era o protocolo obrigatório para grandes redes, formadas por produtos de muitos fornecedores diferentes, e havia sido escolhido pela Microsoft como o protocolo preferencial para o Windows NT, devido às limitações técnicas do seu próprio conjunto de protocolos, o NetBEUI.

Entretanto, ao contrário dos procolos proprietários para redes locais da Microsoft e da Novell, que foram desenhados para serem praticamente “plug and play”, as necessidades que orientaram o desenvolvimento do TCP/IP obrigaram ao estabelecimento de uma série de parametrizações e configurações que devem ser conhecidas pelo profissional envolvido com instalação, administração e suporte de redes.

Esta primeira aula tem por objetivo passar os conhecimentos teóricos necessários para tornar os alunos aptos a seguirem as aulas seguintes, que explicarão como implementar redes TCP/IP no Windows 95, Windows NT, Netware e outros sistemas populares no mercado. Ao contrário da maioria dos livros “introdutórios” sobre TCP/IP que vemos nas livrarias e universidades, não vamos nos preocupar com os detalhes sobre formatos de pacotes e algoritmos empregados na implementação do protocolo. Vamos nos preocupar sim com os conhecimentos realmente necessários para se trabalhar corretamente com os vários produtos existentes no mercado.

As Pilhas de Protocolos

Quem já estudou mais a fundo a documentação de produtos de redes ou participou de cursos mais específicos certamente se deparou com o “Modelo OSI de 7 Camadas”. Todos os softwares de redes são baseados em alguma arquitetura de camadas, e normalmente nos referimos a um grupo de protocolos criado para funcionar em conjunto como uma pilha de protocolos (em inglês, protocol stack, por exemplo the TCP/IP stack). O termo “pilha” é utilizado porque os protocolos de uma dada camada normalmente interagem somente com os protocolos das camadas imediatamente superior e inferior.

O modelo de pilha traz a vantagem de modularizar naturalmente o software de redes, permitindo a sua expansão com novos recursos, novas tecnologias ou aperfeiçoamentos sobre a estrutura existente, de forma gradual.

Entretanto, o Modelo OSI é uma modelo conceitual, e não a arquitetura de uma implementação real de protocolos de rede. Mesmo os protocolos definidos como padrão oficial pelo ISO – International Standards Organization – a entidade criadora do modelo OSI, não foram projetados e construídos segundo este modelo.

Por isso, vamos utilizar nesta aula uma simplificação do modelo OSI. O importante é entender o conceito de pilhas de protocolos, pelo qual cada camada realiza uma das funções necessárias para a comunicação em rede, tornando possível a comunicação em redes de computadores utilizando várias tecnologias diferentes.

O Modelo de Pilha de 4 camadas do TCP/IP

O TCP/IP foi desenhado segundo uma arquitetura de pilha, onde diversas camadas de software interagem somente com as camadas acima e abaixo. Há diversas semelhanças com o modelo conceitual OSI da ISO, mas o TCP/IP é anterior à formalização deste modelo e portanto possui algumas diferenças.

O nome TCP/IP vem dos nomes dos protocolos mais utilizados desta pilha, o IP (Internet Protocol) e o TCP (Transmission Control Protocol). Mas a pilha TCP/IP possui ainda muitos outros protocolos, dos quais veremos apenas os mais importantes, vários deles necessários para que o TCP e o IP desempenhem corretamente as suas funções.

Visto superficialmente, o TCP/IP possui 4 camadas, desde as aplicações de rede até o meio físico que carrega os sinais elétricos até o seu destino:

4. Aplicação (Serviço) FTP, TELNET, LPD, HTTP, SMTP/POP3, NFS, etc.
3. Transporte TCP, UDP
2. Rede IP
1. Enlace Ethernet, PPP, SLIP

Além das camadas propriamente ditas, temos uma série de componentes, que realizam a interface entre as camadas:

Aplicação / Transporte DNS, Sockets
Rede / Enlace ARP, DHCP

Vamos apresentar agora uma descrição da função de cada camada do TCP/IP:

1. Os protocolos de enlace tem a função de fazer com que informações sejam transmitidas de um computador para outro em uma mesma mídia de acesso compartilhado (também chamada de rede local) ou em uma ligação ponto-a-ponto (ex: modem). Nada mais do que isso. A preocupação destes protocolos é permitir o uso do meio físico que conecta os computadores na rede e fazer com que os bytes enviados por um computador cheguem a um outro computador diretamente desde que haja uma conexão direta entre eles.

2. Já o protocolo de rede, o Internet Protocol (IP), é responsável por fazer com que as informações enviadas por um computador cheguem a outros computadores mesmo que eles estejam em redes fisicamente distintas, ou seja, não existe conexão direta entre eles. Como o próprio nome (Inter-net) diz, o IP realiza a conexão entre redes. E é ele quem traz a capacidade da rede TCP/IP se “reconfigurar” quando uma parte da rede está fora do ar, procurando um caminho (rota) alternativo para a comunicação.

3. Os protocolos de transporte mudam o objetivo, que era conectar dois equipamentos, para’ conectar dois programas. Você pode ter em um mesmo computador vários programas trabalhando com a rede simultaneamente, por exemplo um browser Web e um leitor de e-mail. Da mesma forma, um mesmo computador pode estar rodando ao mesmo tempo um servidor Web e um servidor POP3. Os protocolos de transporte (UDP e TCP) atribuem a cada programa um número de porta, que é anexado a cada pacote de modo que o TCP/IP saiba para qual programa entregar cada mensagem recebida pela rede.

4. Finalmente os protocolos de aplicação são específicos para cada programa que faz uso da rede. Desta forma existe um protocolo para a conversação entre um servidor web e um browser web (HTTP), um protocolo para a conversação entre um cliente Telnet e um servidor (daemon) Telnet, e assim em diante. Cada aplicação de rede tem o seu próprio protocolo de comunicação, que utiliza os protocolos das camadas mais baixas para poder atingir o seu destino.

Pela figura acima vemos que existem dois protocolos de transporte no TCP/IP. O primeiro é o UDP, um protocolo que trabalha com datagramas, que são mensagens com um comprimento máximo pré-fixado e cuja entrega não é garantida. Caso a rede esteja congestionada, um datagrama pode ser perdido e o UDP não informa as aplicações desta ocorrência. Outra possibilidade é que o congestionamento em uma rota da rede possa fazer com que os pacotes cheguem ao seu destino em uma ordem diferente daquela em que foram enviados. O UDP é um protocolo que trabalha sem estabelecer conexões entre os softwares que estão se comunicando.

Já o TCP é um protocolo orientado a conexão. Ele permite que sejam enviadas mensagens de qualquer tamanho e cuida de quebrar as mensagens em pacotes que possam ser enviados pela rede. Ele também cuida de rearrumar os pacotes no destino e de retransmitir qualquer pacote que seja perdido pela rede, de modo que o destino receba a mensagem original, da maneira como foi enviada.

Agora, vamos aos componentes que ficam na interface entre os níveis 3 e 4 e entre os níveis 1 e 2.

O Sockets é uma API para a escrita de programas que trocam mensagens utilizando o TCP/IP. Ele fornece funções para testar um endereço de rede, abrir uma conexão TCP, enviar datagramas UDP e esperar por mensagens da rede. O Winsockets, utilizado para aplicações Internet em Windows é nada mais do que uma pequena variação desta API para acomodar limitações do Windows 3.1. No Windows NT e Win95 pode ser usada a API original sem problemas.

O Domain Name Service (DNS), que será visto com maiores detalhes mais adiante, fornece os nomes lógicos da Internet como um todo ou de qualquer rede TCP/IP isolada.

Temos ainda o ARP realiza o mapeamento entre os endereços TCP/IP e os endereços Ethernet, de modo que os pacotes possam atingir o seu destino em uma rede local (lembrem-se, no final das contas quem entrega o pacote na rede local é o Ethernet, não o TCP ou o IP).

Por fim, o DHCP permite a configuração automática de um computador ou outro dispositivo conectado a uma rede TCP/IP, em vez de configurarmos cada computador manualmente. Mas, para entender o porque da necessidade do DHCP, temos que entender um pouco mais do funcionamento e da configuração de uma rede TCP/IP.

Endereçamento e Roteamento

Em uma rede TCP/IP, cada computador (ou melhor, cada placa de rede, caso o computador possua mais do que uma) possui um endereço numérico formado por 4 octetos (4 bytes), geralmente escritos na forma w.x.y.z. Além deste Endereço IP, cada computador possui uma máscara de rede (network mask ou subnet mask), que é um número do mesmo tipo mas com a restrição de que ele deve começar por uma seqüência contínua de bits em 1, seguida por uma seqüência contínua de bits em zero. Ou seja, a máscara de rede pode ser um número como 11111111.11111111.00000000.00000000 (255.255.0.0), mas nunca um número como 11111111.11111111.00000111.00000000 (255.255.7.0).

A máscara de rede serve para quebrar um endereço IP em um endereço de rede e um endereço de host. Todos os computadores em uma mesma rede local (fisicamente falando, por exemplo, um mesmo barramento Ethernet) devem ter o mesmo endereço de rede, e cada um deve ter um endereço de host diferente. Tomando-se o endereço IP como um todo, cada computador em uma rede TCP/IP (inclusive em toda a Internet) possui um endereço IP único e exclusivo.

O InterNIC controla todos os endereços IP em uso ou livres na Internet, para evitar duplicações, e reserva certas faixas de endereços chamadas de endereços privativos para serem usados em redes que não irão se conectar diretamente na Internet.

Quando o IP recebe um pacote para ser enviado pela rede, ele quebra o endereço destino utilizado a máscara de rede do computador e compara o endereço de rede do destino com o endereço de rede dele mesmo. Se os endereços de rede forem iguais, isto significa que a mensagem será enviada para um outro computador na mesma rede local, então o pacote é repassado para o protocolo de enlace apropriado (em geral o Ethernet). Se os endereços forem diferentes, o IP envia o pacote para o default gateway, que é nada mais do que o equipamento que fornece a conexão da rede local com outras redes. Este equipamento pode ser um roteador dedicado ou pode ser um servidor com múltiplas placas de rede, e se encarrega de encaminhar o pacote para a rede local onde está o endereço IP do destino.

É importante que o endereço IP do default gateway esteja na mesma subnet que o a máquina sendo configurada, caso contrário ela não terá como enviar pacotes para o default gateway e assim só poderá se comunicar com outros hosts na mesma subnet.

Resumindo um computador qualquer em uma rede TCP/IP deve ser configurado com pelo menos estes três parâmetros: o seu endereço IP exclusivo, a sua máscara de rede (que deve ser a mesma utilizada pelos demais computadores na mesma LAN) e o endereço IP do default gateway.

Como se Processa a Comunicação em uma Rede

Digamos que o host com o endereço IP é 172.16.1.101 deseje enviar um pacote para o endereço 172.16.2.102. Caso a máscara de rede seja 255.255.0.0, o AND binário do enredeço fonte será 172.16.0.0, e o AND do endereço destino será 172.16.0.0, indicando que ambos possuem o mesmo endereço de rede e portanto estão diretamente conectados no nível de enlace.

Neste caso, o nível IP envia um pacote ARP pela rede Ethernet para identificar qual o endereço Ethernet do host cujo IP é 172.16.2.2. Este pacote é enviado como um broadcast, de modo que todos os hosts conectados no mesmo segmento Ethernet receberão o pacote, e o host configurado para o endereço desejado irá responder ao pacote ARP indicando qual o seu endereço Ethernet. Assim o IP pode montar o pacote Ethernet corretamente endereçado e enviar o pacote para o seu destino.

Agora digamos que a máscara de rede não fosse 255.255.0.0, mas sim 255.255.255.0. Neste caso, os endereços de rede da origem e destino seriam respectivamente 172.16.1.0 e 172.16.2.0. Como os endereços de rede são diferentes, isto significa que não temos conectividade direta (no nível de enlace) entre os dois hosts, portanto o pacote deverá ser entregue por intermédio de um roteador, que é o default gateway.

Digamos que o default gateway seja 172.16.1.1 (observe que o endereço de rede do default gateway é 172.16.1.0, o mesmo do nosso host de origem). Então o host irá enviar um pacote ARP pela rede para descobrir o endereço Ethernet do default gateway, e enviará o pacote para este.

Ao receber o pacote, o default gateway irá verificar que o endereço IP de destino é o IP de outro host que não ele, e irá verificar qual o endereço de rede do destino. Pode ser que o pacote esteja endereçado para uma rede local na qual o default gateway tenha uma conexão direta, ou pode ser que o default gateway tenha que direcionar o pacote para um outro roteador mais próximo do destino final. De qualquer forma, o default gateway segue o mesmo processo de gerar o endereço de rede utilizando a netmask, e em seguida enviar um pacote ARP pedindo o endereço Ethernet do próximo host a receber o pacote. A diferença é que um roteador não tem um default gateway, mas sim uma tabela de roteamento, que diz quais endereços de rede podem ser alcançados por quais roteadores.

Notem que este exemplo considerou apenas a comunicação entre dois equipamentos, não entre dois programas. O nosso exemplo ficou apenas no nível de rede da pilha TCP/IP, mas acima dela o processo é simples: o IP verifica que tipo de pacote foi recebido (TCP, UDP ou outro) e repassa o pacote para o protocolo apropriado.

O protocolo de transporte irá então verificar o número de porta contido no pacote e qual programa está associado aquela porta. Este programa será notificado da chegada de um pacote, e será responsabilidade dele decodificar e utilizar de alguma forma as informações contidas no pacote.

Como Testar uma Rede TCP/IP

Caso você venha a ter problemas de comunicação, todas as pilhas TCP/IP, independente de qual sistema operacional, trazem o utilitário ping para testar a conectividade entre dois hosts TCP/IP. Siga o seguinte procedimento:

1. ping 127.0.0.1. Este endereço IP é um loopback, ou seja, não vai para a rede, fica no computador que originou a mensagem. Se o ping acusar o recebimento da resposta, significa que a pilha TCP/IP está instalada e ativa no computador onde foi realizado o teste. (Somente a título de curiosidade, você pode usar o loopback do TCP/IP para desenvolver aplicações de rede em uma máquina stand-alone, sem nenhum tipo de conexão de rede disponível.)

2. ping meu_ip. Tendo comprovado que o TCP/IP está ativo na máquina origem, vamos enviar uma mensagem para ela mesmo, para verificar se a placa de rede (ou modem) estão ativos no que diz respeito ao TCP/IP. Aqui você testa apenas o driver da sua placa de rede, não a placa em si nem os cabos da rede.

3. ping ip_na_minha_rede. Agora vamos testar a comunicação dentro da rede local onde o computador de origem está localizado. Garanta que o computador dono do ip_na_minha_rede está com o TCP/IP e a sua placa de rede ativos, segundo os dois testes acima. Se não funcionar, você tem um problema de cabos ou em uma placa de rede, ou simplesmente as suas máscaras de rede e endereços IP estão incorretos.

4. ping ip_do_default_gateway. Se a comunicação dentro da minha rede local está OK, temos que verificar se o default gateway da minha rede está no ar, pois todos os pacotes que saem da minha rede local passam por ele.

5. ping ip_do_outro_lado. Digamos que o meu default gateway esteja diretamente conectado na rede destino. Eu tenho que testar se a interface de rede que liga o default gateway a esta rede está no ar. Então eu dou um ping no endereço IP desta placa. Se o default gateway não estiver diretamente conectado na rede destino, eu repito os passos (4) e (5) para cada equipamento que esteja no caminho entre origem e destino.

6. ping ip_do_destino. Sabendo que a outra rede pode ser alcançada via TCP/IP, resta saber se eu consigo me comunicar com o computador desejado.

Serviços de Nomeação

Até agora nós estamos vendo a comunicação em rede utilizando apenas os endereços IP. Imagine o seu cartão de visitas, indicando a sua home-page como: “164.85.31.230”. Imagine-se ainda com uma lista contendo dezenas de números como esse pendurada na parede junto ao seu computador, para quando você precisar se conectar a um dos servidores da sua empresa.

No início do desenvolvimento do TCP/IP, cada computador tinha um arquivo de hosts que listava os nomes dos computadores e os endereços IP correspondentes. Na Internet, certamente seria inviável manter estes arquivos, não só pelo tamanho que eles teriam mas também pela dificuldade em se manter milhões de cópias atualizadas. Logo foi desenvolvido o DNS, pelo qual diversos servidores mantém um banco de dados distribuído com este mapeamento de nomes lógicos para endereços IP.

O DNS funciona de forma hierárquica. Vejam um endereço Internet típico, como www.petrobras.com.br. Inicialmente, separamos o primeiro nome (até o primeiro ponto), “www”, que é o nome de um computador ou host, e o restante do endereço, “petrobras.com.br”, que é o nome da organização, ou o nome do domínio. Por favor, não confundam o conceito de domínios em endereços Internet com o conceito de domínios em uma Rede Microsoft. Não existe nenhuma relação entre eles.

O domínio petrobras.com.br possui o seu servidor DNS, que contém os nomes dos computadores (e endereços IP correspondentes) sob a sua autoridade. E ele sabe o endereço IP do servidor DNS do domínio que está acima dele, .com.br. Os computadores na Petrobras fazem todas as consultas por endereços IP ao servidor do seu domínio, e ele repassa as consultas a outros servidores DNS quando necessário. Os clientes necessitam saber apenas sobre o servidor do seu domínio, e mais nada.

Já o servidor DNS do domínio .com.br sabe os endereços IP de todos os servidores dos domínios a ele subordinados (por exemplo, texaco.com.br, mantel.com.br, etc) e o endereço IP do servidor acima dele (domínio .br, o domínio que engloba todo o Brasil). Por fim, o servidor DNS do domínio br sabe os endereços de todos os servidores dos domínios a ele subordinados (.com.br, .gov.br, etc) e o endereço do servidor DNS do InterNIC, que é o servidor DNS raiz de toda a Internet.

Uma consulta de uma aplicação por um endereço IP sobe por toda a hierarquia de servidores DNS, até o domínio comum de nível mais baixo que seja comum a origem e destino, ou até chegar ao servidor do InterNIC, e depois desce na hierarquia até o domínio onde está o computador destino. A resposta volta pelo caminho inverso, porém cada servidor DNS mantém um cache das respostas recebidas, de modo que uma nova requisição pelo mesmo nome não necessitará percorrer novamente todos os servidores DNS.

Pode parecer que é realizado um trabalho muito grande somente para obter um endereço IP, mas o processo como um todo é rápido (quem navega na Web sabe bem disso), e ele possibilita que milhares de organizações integrem suas redes a um custo aceitável e com grande autonomia. Quando você acrescenta uma máquina no seu domínio, você não precisa comunicar ao InterNIC e às redes vizinhas, basta registrar o novo computador no seu servidor DNS.

O protocolo DHCP

Recapitulando, cada estação ou servidor em uma rede TCP/IP típica deverá ser configurada com os seguintes parâmetros:

Endereço IP
Máscara de Rede
Default Gateway

Além disso, caso a sua rede utilize um servidor DNS o seu endereço IP também deve ser configurado em cada host.

Em uma rede com dezenas ou mesmo centenas de computadores, manter o controle dos endereços IP já utilizados pelas máquinas pode ser um pesadelo. É muito fácil errar o endereço IP de uma máquina, ou errar a máscara de rede ou endereço do default gateway, e geralmente é muito difícil identificar qual a máquina onde existe um erro de configuração do TCP/IP.

Para resolver esses problemas você poderá instalar um servidor DHCP na sua rede local (ou melhor, um servidor DHCP para cada subnet, logo veremos porque) e deixar que ele forneça estes parâmetros para as estações da rede.

Se você tem uma pilha TCP/IP instalada que suporta o protocolo DHCP, você pode configurar cada estação para usar o DHCP e ignorar todos esses parâmetros. Na inicialização da pilha TCP/IP, a estação irá enviar um pacote de broadcast para a rede (um broadcast é um pacote que é recebido por toda a rede) e o servidor DHCP, ao receber este pacote, enviará os parâmetros de configuração para a estação.

Aqui temos comunicação apenas no nível de enlace (pois o TCP/IP ainda não foi completamente inicializado), e portanto não temos a função de roteamento habilitada. Por isso o servidor DHCP deve estar na mesma LAN física onde está a estação que será inicializada. Normalmente os servidores tem sua configuração realizada manualmente, pois o endereço IP deve concordar com o endereço IP cadastrado no servidor DNS.

O servidor DHCP é configurado com uma faixa de endereços IP que ele pode fornecer aos clientes. Inicialmente, todos os endereços estão disponíveis. Quando uma estação é inicializada, ela envia o broadcast pedindo pela sua configuração, e o servidor DHCP reserva um endereço para ela (que deixa de estar disponível) e registra o endereço Ethernet para o qual o endereço foi reservado. Então ele envia uma resposta contendo este endereço e os demais parâmetros listados acima.

O endereço é apenas “emprestado” pelo servidor DHCP, que registra também o momento do empréstimo e a validade deste empréstimo. No próximo boot, a estação verifica se o empréstimo ainda é válido e se não pede um novo endereço (que pode até ser o mesmo, por coincidência). Se o empréstimo estiver em metade da sua validade, o cliente pede uma renovação do empréstimo, o que aumenta a sua validade. E a cada inicialização, o cliente verifica se o endereço emprestado ainda é dela, pois ela pode ter sido deslocada para uma outra LAN, onde a configuração do TCP/IP é diferente, ou por qualquer motivo o Administrador da Rede pode ter forçado a liberação do endereço que havia sido emprestado.

O servidor verifica periodicamente se o empréstimo não expirou, e caso afirmativo coloca o endereço novamente em disponibilidade. Desta forma, a não ser que você tenha um número de estações muito próximo ao número de endereços IP reservados para o servidor DHCP, você pode acrescentar, retirar ou mover estações pela sua rede sem se preocupar em configurar manualmente as pilhas TCP/IP a cada mudança.

Geralmente o DHCP é utilizado somente para configurar estações cliente da rede, enquanto que os servidores são configurados manualmente. Isso porque o endereço IP do servidor deve ser conhecido previamente (para configuração do default gateway, para configuração do arquivo de hosts, para configuração de DNS, configuração de firewall, etc). Se fosse utilizado o DHCP, o endereço do servidor poderia ser diferente em cada boot, obrigando a uma série de mudanças de configuração em diversos nós da rede.

Você também pode configurar o servidor DHCP para entregar aos clientes outras informações de configuração, como o endereço do servidor DNS da rede. O Linux pode operar tanto como cliente quanto como servidor DHCP, entretanto não veremos estas configurações no nosso curso.

Clusterweb® – Internet Data Center.

 ClusterWeb  Comentários desativados em Clusterweb® – Internet Data Center.
jan 022012
 

O Blog da Clusterweb® – Internet Data Center tem como objetivo principal divulgar assuntos relacionados ao sistema Gnu/Linux e administração de redes, e outros sistemas operacionais.
No site teremos assuntos, scripts e facilidades para erros comuns e incomuns ocorridos no dia a dia de um administrador de redes.
Artigos coletados nas diversas buscas na internet em buscas de conhecimento ou de soluções para problemas já passados por todos.
Agradecemos a todos a contribuição, pois não há nenhum tipo de lucro, a ideia aqui é deixar um amplo acervo de soluções.
Caso queira participar seja bem-vindo, faça seu cadastro e comece agora a interagir com a nossa equipe.
Convidamos todos a fazer parte da nossa comunidade.

 



Seja bem-vindo a Clusterweb® – Internet Data Center.