Uma solução de autenticação centralizada para dispositivos de rede usando os recursos do Windows Server 2012.

Cisco - AAA usando RADIUS Windows Server 2012

Fazer o gerenciamento de acesso à equipamentos de rede como routers, switches em redes de pequeno porte, pode ser feito diretamente no dispositivo, porém, a medida que a rede começa a crescer fica difícil de manter a consistência.

O ideal é desde o início provisionar um servidor de autenticação para dispositivos de rede. Atualmente temos dois protocolos disponíveis para alcançar este objetivo: RADIUS e TACACS+. Ambos tem características diferentes e são mais assertivos para diferentes cenários.

Neste post vamos focar apenas na configuração do Radius em um Windows Server 2012.

Dada a topologia acima, onde temos a rede onde está localizado o Windows Server e outras duas redes, a rede NOC que representa os usuários que tem apenas acesso de leitura e a rede Engineer, que possui usuário com acesso mais privilegiado. O dispositivo alvo é o roteador que está configurado com a arquitetura Router-on-a-Stick, onde ele é o gateway de todas as redes e faz o roteamento inter-vlan. É nele que faremos a configuração para que os usuários se autentiquem no Radius Server. Temos as seguintes interfaces no router:

• WAN: 192.168.77.11
• VLAN10: 172.16.10.1
• VLAN20: 172.16.20.1
• VLAN30: 172.16.30.1

Para este exemplo, cada rede de origem terá um tipo de permissão diferente. Mas a granularidade de configuração no RADIUS permite que essa definição seja feita baseada em grupos de usuários, como veremos mais à frente.

Vamos para o Windows Server 2012, onde iremos instalar o Network Policy Server (NPS) que permitirá usar o RADIUS. Basta ir até o Server Manager DashBoard, clicar em Add Roles and Features e em Server Roles selecionar a opção Network Policy and Access Services e clicar em Next até finalizar todas as opções. Feito isso já temos disponível nosso Radius Server.

Para este Lab é necessário criar dois grupos de usuários no Windows: GRP-N3 para privilege 15 e GRP-N1 para privilege 1. Para o GRP-N3 temos o usuário engineer e para GRP-N1 o usuário noc.

Agora é o momento de criar as policies que serão os níveis de permissão de acesso. Para simplificar teremos apenas dois tipos de acesso: privilege=1 para o NOC e privilege=15 para os engineers. Para iniciar vamos abrir o Dashboard do Network Policy Server e em Policies, clicar com botão direto e depois em New.

Com a nova janela aberta, em Overview, vamos dar o nome à policy (PRIV-15_policy) e marcar a opcão Policy enabled e Grant Access, para que a política seja criada e seja habilitada.

Na aba Conditions vamos clicar em Add e depois e selecionar Windows Groups, para nosso Lab teremos dois grupos, neste momento vamos adicionar somente o GRP-N3, que terá privilégio total ao router.

Na aba Constraints, neste momento é interessante alterar apenas o campo de Authentication Methods e deixar marcado apenas a opcão Unecrypted authentication (PAP, SPAP).

Na aba Settings teremos as configuracões de RADIUS, em Standard vamos usar o Attribute Service-Type Login.

Em Vendor Specific vamos deixar os atributos como mostrados abaixo, que dará ao grupo GRP-N3 o acesso ao roteador com privilégio level 15. Feito isso a configuracão no Radius está pronta.

Para adicionar o grupo GRP-N1 basta seguir os mesmo passos alterando apenas o grupo adicionado e o shell privilege que será lelvel 1.

Criadas as políticas de acesso é hora de adicionar os Radius clientes, que serão os dispositivos que faram as solicitacões de validacão de credenciais. Neste caso o nosso router.

Para isto, basta expandir o menu RADIUS Clients and Server e em RADIUS Clients clicar com botão direito em New, aqui teremos que marcar a checkbox “Enable this RADIUS client”, dar um nome ao dispositivo e depois adicionar o IP abaixo. Aqui o item mais importante é “Shared secret” que é a chave compartilhada entre o RADIUS Server e o client, essa mesma chave será configurada no router. Na aba Advanced, em Vendor name vamos alterar para Cisco. Aqui a configuracão do Radius Server está pronta.

A configuração no switch é a seguinte:

!
aaa group server radius GRP-RADIUS
 server name NPS-01
 ip radius source-interface Ethernet0/1
!
aaa authentication login VTY_ACCESS group GRP-RADIUS local
aaa authorization exec default group GRP-RADIUS local if-authenticated
!
username admin.local privilege 15 password 7 133112011F5D5679
!
radius server NPS-01
 address ipv4 172.16.10.2 auth-port 1812 acct-port 1813
 key 7 0812494D1B1C11464058
!
line vty 0 4
 login authentication VTY_ACCESS
 transport input ssh
!

O aaa authorization exec default group GRP-RADIUS local if-authenticated garante que o nível de privilégio criado na política do NPS será aplicado e também à conta local admin.local (em caso de perda de conectividade com servidor Radius), caso contrário, o usuário autenticado teria o privilégio 1.

Para um usuário linux sem muita experiência em Linux criar um pen drive bootável pode ser um problema e para facilitar essa tarefa trago este post que de maneira simples resolve esta questão.

1. Overview

2. Listando as unidades disponíveis

3. Criando o Pen Drive Bootável

4. Usando o PV

5. Resumo

1. Overview

Vamos realizar esta tarefa via terminal, ou seja, usando linhas de comando. Isto porque a partir de qualquer distribuição Linux será possível criar o pen drive bootável.

A ferramenta aqui usada será o dd que é um ferramenta de linha de comando que por padrão vem em todas as distribuições GNU/Linux e faz parte do pacote coreutils.

Usando o comando man temos a seguinte saída para descrever o dd:

DD(1) 

NOME
       dd - converte e copia um arquivo

SINOPSE
       dd [--help] [--version] [if=arquivo] [of=arquivo] [ibs=bytes] [obs=bytes] [bs=bytes] [cbs=bytes] [skip=blocos] [seek=blocos] [count=blocos] [conv={ascii, ebcdic, ibm, block, unblock, lcase, ucase, swab, noerror, notrunc, sync}]

DESCRIÇÃO
       dd copia um arquivo (da entrada padrão para a saída padrão, por padrão) usando tamanhos de blocos de entrada e saída especificados, enquanto está fazendo opcionalmente conversões nele.

2. Listando as unidades disponíveis

Formatar uma unidade não desejada pode ser uma dor de cabeça e tanto, por isso é importante prestar atenção nesse item. O comando lsblk vai nos mostrar as unidade.

user@dragon:~/Documents/blog$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 223,6G  0 disk 
├─sda1   8:1    0   487M  0 part /boot/efi
├─sda2   8:2    0   3,8G  0 part [SWAP]
└─sda3   8:3    0 219,3G  0 part /
sdb      8:16   1   7,3G  0 disk 
├─sdb1   8:17   1   415M  0 part /media/user/flashdrive
└─sdb2   8:18   1   6,4M  0 part 

A saída do comando lsblk nos mostra duas unidades de disponíveis, sda e sdb, sendo que sda é onde está nosso sistema operacional com as respectivas partições /boot, /swap e /. sdb que é a unidade que vamos montar pen drive bootável está identificado e tem volume de 7,3G.

3. Criando o Pen Drive Bootável

Agora que identificamos /dev/sdb como a unidade que vamos montar a imagem, vamos de fato montar botar a mão na massa.

O comando será sudo dd if=~/Downloads/debian-10.8.0-amd64-netinst.iso of=/dev/sdb, onde if= é o arquivo de origem, ou seja, a ISO que baixamos, neste caso temos um debian netinst. of= é o caminho da unidade onde a imagem será montada, neste caso /dev/sdb. Caso esteja logado com usuário root não é necessário o sudo no início do comando.

Após dar Enter no comando acima a tarefa seja executada e o prompt ficará ocupado e com o cursor piscando até que seja finalizado, caso nada de errado ocorra temos o pen drive bootável pronto para uso.

4. Usando o PV

Caso deseje acompanhar de forma dinâmica, o pv é uma solução que mostra uma barra de progresso da nossa tarefa. Ele não vem instalado por padrão na maioria das distribuições então pode ser necessário instalar com o comando apt install pv para distribuições debian-based.

Com o PV o comando fica um pouco diferente, use@dragon$ pv ~/Downloads/debian-10.8.0-amd64-netinst.iso | sudo dd of=/dev/sdb.

Ao final da barra de progresso temos o pen drive pronto!

use@dragon$ pv ~/Downloads/debian-10.8.0-amd64-netinst.iso | sudo dd of=/dev/sdb

 336MiB 0:00:01 [ 242MiB/s] [============================================================>] 100%            
688128+0 registros de entrada
688128+0 registros de saída
352321536 bytes (352 MB, 336 MiB) copiados, 1,38123 s, 255 MB/s

5. Resumo

É bem simples a criação de um pen drive bootável usando este método, aqui um resumo:

1. Identificar a unidade com lsblk
2. Usar o comando `sudo dd if=~/Downloads/debian-10.8.0-amd64-netinst.iso of=/dev/sdb
3. Caso deseje usar a barra de progresso deve ser instalado o pv e o comando use@dragon$ pv ~/Downloads/debian-10.8.0-amd64-netinst.iso | sudo dd of=/dev/sdb

Vale lembrar que esta tarefa apagará todos os itens da unidade apontada para montagem do pen drive bootável, então faça um backup dos seus arquivos.

É de grande importância saber trabalhar com o sistema de arquivos no Cisco IOS, tanto para implantação de novos equipamento, backup de arquivos e configuração e até mesmo recuperação de um equipamento venha a ser danificado.

Antes de verificar o sistema de arquivos no Cisco IOS, precisamos conhecer os tipos de memórias que é onde serão armazenados os arquivos, configuração, IOS e etc.

Todos os exemplos aqui demonstrados foram feitos utilizando o Cisco C1900 Series com IOS versão 15.

Tipos de memórias memórias:

DRAM - Dynamic Random-Access Memory: é uma memória volátil, ou seja as informações são carregadas no momento do boot mas quando o equipamento é desligado a informação não fica gravada, comparável à memória RAM nos Computadores.

EPROM - Erasable Programmable Read-Only Memory: Também chamada de memória ROM, é do tipo não volátil. É utilizada para armazenar o ROM Monitor Software (ROMMOM), e o bootloader que permite acessar o equipamento mesmo se estiver sem o IOS.

NVRAM - Non-Volatile Rando-Access Memory: Responsável por armazenar a startup-config e também o configuration-register.

Flash: É usada para armazenar o IOS e outros arquivos, podemos comparar aos HDs ou SSDs dos computadores.

Comandos

show file system: comando usado para mostrar o sistema de arquivos da caixa além de informações da nvram,flash e sua capacidade de armazenamento.

No exemplo abaixo o asterisco ( * ) nos mostra qual unidade de armazenamento padrão, que é usbflash0 e tem aproximadamente 256mb, a nvram possui armazenamento de 255k além de uma unidade removível usb que foi inserida e tem aproximadamente 3.5gb.

As Flags ro, rw e wo descrevem as permissões para o sistema de arquivos.

Router#show file systems 
File Systems:

       Size(b)       Free(b)      Type  Flags  Prefixes
             -             -    opaque     rw   archive:
             -             -    opaque     rw   system:
             -             -    opaque     rw   tmpsys:
             -             -    opaque     rw   null:
             -             -   network     rw   tftp:
        262136        255065     nvram     rw   nvram:
             -             -    opaque     wo   syslog:
             -             -    opaque     rw   xmodem:
             -             -    opaque     rw   ymodem:
             -             -   network     rw   rcp:
             -             -   network     rw   http:
             -             -   network     rw   ftp:
             -             -   network     rw   scp:
             -             -    opaque     ro   tar:
             -             -   network     rw   https:
             -             -    opaque     ro   cns:
*    255537152     209698816  usbflash     rw   usbflash0: flash:
    3505545216    3505541120  usbflash     rw   usbflash1:

pwd: print working directory, para se localizar a qualquer momento em qual diretório estamos trabalhando este é o comando.

Router#pwd
usbflash0:

cd: change directory, este é o comando que nos permite passar de um diretório para outro apontando o caminho do diretório que se deseja alcançar.

Router#cd usbflash0:backup

dir: mostra uma lista de arquivos e diretórios em um diretório específico.

Router#dir
Directory of usbflash0:/

    4  drw-           0   Nov 5 2020 00:21:56 +00:00  backup
    1  drw-           0   Nov 3 2020 15:46:24 +00:00  back
    3  -rw-    45832792   Jul 2 2015 22:03:42 +00:00  c1900-universalk9-mz.SPA.150-1.M8.bin

mkdir permite criar um novo diretório.

Router#mkdir backup 
Create directory filename [backup]? 
Created dir usbflash0:backup

rmdir: permite remover um diretório, um detalhe é que caso o diretório contenha algum arquivo ou até mesmo outro diretório o comando não vai funcionar, tendo efeito somente em diretórios vazios. No exemplo abaixo não é possível remover o diretório back pois não é um diretório vazio.

Router#rmdir usbflash0:back
Remove directory filename [back]? 
Delete usbflash0:back? [confirm]
%Error Removing dir usbflash0:back (Can't delete a directory that has files in it)

delete: permite deletar arquivos dentro file system, um detalhe que ele pode ser forçado e apagar até mesmo um diretório com vários arquivos dentro usando a opção delete /recursive /force /pasta.

Router#delete usbflash0:/back/bkpp
Delete filename [/back/bkpp]? 
Delete usbflash0:/back/bkpp? [confirm]	

format: permite formatar um file system, pode ser usado até mesmo para particionar um pen drive inserido por exemplo.

Router#format ?
  flash:      Filesystem to be formatted
  usbflash0:  Filesystem to be formatted

erase: permite apagar os arquivos na nvram, o startup-config por exemplo.

Router#erase ?
  /all                       Erase all files(in NVRAM)
  /no-squeeze-reserve-space  Do not reserve space for squeeze operation
  nvram:                     Filesystem to be erased
  startup-config             Erase contents of configuration memory

verify : verifica a integridade dos arquivos, ai disponibilizar um IOS a Cisco disponibiliza juntamente o MD5 para checar que não foi alterado do servidor da Cisco até o usuário que está fazendo o Download.

Router#verify flash:c1900-universalk9-mz.SPA.150-1.M8.bin
Starting image verification
Hash Computation:    100% Done!
Computed Hash   SHA2: 006062C86B23F1186BF72FB628D8C63C
                      92787CF94FDD436BC88BE77BBE373B14
                      E6021DAD66E1D25ABA676B0A7B95F9D2
                      8A0778E8F70C6D3A48353F7C2566CCF1
                      
Embedded Hash   SHA2: 006062C86B23F1186BF72FB628D8C63C
                      92787CF94FDD436BC88BE77BBE373B14
                      E6021DAD66E1D25ABA676B0A7B95F9D2
                      8A0778E8F70C6D3A48353F7C2566CCF1
                      
CCO Hash        MD5 : 6DCA357446C1E6ED204F0C578CC465DC
Digital signature successfully verified in file usbflash0:c1900-universalk9-mz.SPA.150-1.M8.bin

Router#verify /md5 usbflash0:c1900-universalk9-mz.SPA.150-1.M8.bin
..................................................................
Done!
verify /md5 (usbflash0:c1900-universalk9-mz.SPA.150-1.M8.bin) = 6dca357446c1e6ed204f0c578cc465dc

Pode ser checado também arquivos de configuração como o startup-config que pode ter sido baixado de um servidor FTP, para garantir que não houve alteração rodamos o comando:

Router#verify /md5 nvram:startup-config
.Done!
verify /md5 (nvram:startup-config) = d65faaba055e3c829420dadddd808c6f

Este md5 tem que ser igual ao que está no servidor e este por sua vez pode também ter sido verificado anteriormente.

fsck: Faz a checagem do sistema de arquivos para verificar se há alguma falha na unidade flash por exemplo.

Router#fsck ?
  /all        Check all partitions of this disk
  /force      Force fsck of disk
  flash:      Filesystem to be checked
  usbflash0:  Filesystem to be checked
  <cr>

copy: permite copiar arquivos ou diretórios de várias origens, por exemplo de um servidor FTP ou TFTP para a unidade flash. É um comando bem versátil.

Router#copy startup-config ftp
Address or name of remote host []? 192.168.1.1
Destination filename [router-confg]? 
Writing router-confg 

rename: renomear arquivos ou diretorios.

Router#rename usbflash0:/back/startup-config config-old
Destination filename [/back/config-old]? 

show version: um comando que mostra várias informações do equipamento Cisco.

Router#show version 
Cisco IOS Software, C1900 Software (C1900-UNIVERSALK9-M), Version 15.0(1)M8, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2012 by Cisco Systems, Inc.
Compiled Wed 15-Feb-12 21:27 by prod_rel_team

ROM: System Bootstrap, Version 15.0(1r)M15, RELEASE SOFTWARE (fc1)

Router uptime is 56 minutes
System returned to ROM by power-on
System restarted at 23:32:36 UTC Mon Nov 2 2020
System image file is "usbflash0:c1900-universalk9-mz.SPA.150-1.M8.bin"
Last reload type: Normal Reload


This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.
          
A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export@cisco.com.

Cisco CISCO1905/K9 (revision 1.0) with 225280K/36864K bytes of memory.
Processor board ID FTX16218269
2 Gigabit Ethernet interfaces
1 Serial(sync/async) interface
DRAM configuration is 64 bits wide with parity disabled.
255K bytes of non-volatile configuration memory.
249840K bytes of USB Flash usbflash0 (Read/Write)
3430096K bytes of USB Flash usbflash1 (Read/Write)


License Info:

License UDI:

-------------------------------------------------
Device#   PID                   SN
-------------------------------------------------
*0        CISCO1905/K9          FTX16218269     



Technology Package License Information for Module:'c1900' 

-----------------------------------------------------------------
Technology    Technology-package           Technology-package
              Current       Type           Next reboot  
------------------------------------------------------------------
ipbase        ipbasek9      Permanent      ipbasek9
security      None          None           None
data          None          None           None

Configuration register is 0x2102

Dentre outras podemos extrair as seguintes informações:

• 225MB de DRAM
• 255K de NVRAM
• 250MB de Flash
• ~3.5GB de Flash USB (Pen Drive)
• 2 Gigabit Ethernet interfaces
• 1 Serial(sync/async) interface
• Configuration register is 0x2102

show flash: descreve a memória flash e mostra os arquivos e tamanho dos mesmo.

Router#show flash: 
-#- --length-- -----date/time------ path
1     45832792 Jul 02 2015 22:03:42 c1900-universalk9-mz.SPA.150-1.M8.bin
2            0 Nov 03 2020 00:22:28 backup

209698816 bytes available (45838336 bytes used)

• Podemos notar que o IOS tem aproximadamente 45mb.

O protocolo OSPF (Open Shortest Path First) é um protocolo de roteamento de redes e foi desenvolvimento pelo IETF (Internet Engineering Task Force), trabalha diretamente sobre o IP com protocolo número 89. É um protocolo aberto sendo suportado pela maioria dos fabricantes e também por sistemas operacionais Linux, BSD’s e Unix e usa o algoritmo de Dijkstra para determinar o melhor caminho para cada rede.

Este é um breve resumo do OSPF e algumas de suas atribuições, cabendo ainda um estudo mais aprofundado para implantação em redes de grande porte e tem referência aos comandos dos roteadores Cisco.

O OSPF é um protocolo de roteamento que utiliza padrão aberto, classless, com convergência rápida e usa o custo como uma métrica.

Os domínios de roteamento do OSPF são divididos em áreas, e deve conter obrigatoriamente a área zero a qual todas as outras áreas devem estar conectadas, essa divisão em áreas traz alguns benefícios:

• Minizar o número de entradas na tabela de roteamento;
• Minizar a inundação de LSA’s a uma área específica;
• Minimizar o impacto de mudanças de topologia, uma vez que um link fica Down o SPF irá rodar novamente o algoritmo naquela área a qual pertence;
• Reforçar o conceito de um projeto de rede.

O cabeçalho do OSPF, traz algumas informaçoes como a versão sendo v2 para IPv4 e v3 para IPv6, o campo Type identifica o tipo de pacote a ser transportado que no total são 5, além de Router ID e Area ID e autenticação caso seja configurado.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Version     |     Type      |         Packet length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Router ID                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Area ID                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Checksum            |             AuType            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Authentication                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Authentication                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Os cindo pacotes transpostados pelo OSPF são:

Os roteadores rodando o OSPF possuem três tabelas para administração do protocolo de roteamento, são elas:

• Adjacency Database (Neighbor Table): Guarda as informações das vizinhanças descobertas pelo OSPF através do protocolo Hello.
• Link-State Database (Topology Table): Guarda a base de dados topológica do OSPF, ou seja, os LSA’s que foram recebidas pelo roteador e serão utilizadas pelo SPF para descobrir as melhores rotas.
• Fowarding Database (Routing Table): As melhores rotas serão inseridas na tabela de roteamento.

Os pacotes de roteamento OSPF (com exceção de Hellos) são enviados apenas por adjacências. Isso significa que todos os pacotes de protocolo OSPF percorrem um único salto de IP, exceto aqueles que são enviados por adjacências virtuais. O endereço IP de origem de um pacote de protocolo OSPF é uma extremidade de uma adjacência do roteador e o endereço IP de destino é a outra extremidade da adjacência ou um endereço IP multicast.

Formação de vizinhos ou Adjacências

Em um link ponto a ponto, para que dois roteadores tornem-se vizinhos ele precisam, além de estar na mesma sub-rede ou compartilharem um link virtual, que os seguintes parâmetros sejam iguais:

• temporizadores de Hello e Dead
• ID da área
• Tipo de autenticação e senha caso configurados

O processo de estabelecimento de adjacencia e troca de rota entre dois roteadores OSPF segue os seguintes passos:

• Passo 1 - Down State : O processo do OSPF ainda não começou e os pacotes Hello ainda não foram enviados.
• Passo 2 - Init State : O router envia pacotes Hello para todas as interfaces OSPF configuradas no comando network .
• Passo 3 - Two-way State : o roteador recebeu um Hello do outro roteador contendo seu próprio ID de roteador na lista de vizinhos. Nessa situação todos os requisitos para vizinhança foram cumpridos e os roteadores podem se tornar vizinhos.
• Passo 4 - Exstart State : se os roteadores se tornarem adjacentes (fazer troca de rotas), nesse passo eles determinam quem começa o processo de troca de informações.
• Passo 5 - Exchange State: as bases de dados dos roteadores são trocadas listando os LSA em seu LSDB pelo RID e número de sequencia.
• Passo 6 - Loading State : cada roteador compara a base de dados recebida com o conteúdo de seu banco de dados local. Em seguida, envia um LSR para LSAs faltantes ou desatualizadas. Cada roteador responde a LSR do seu vizinho com uma atualização do estado do enlace. Cada LSU é reconhecido como um LSAck.
• Passo 7 - Full State : A LSDB foi sincronizada com o vizinho e foi finalizado o processo de inicialização do OSPF.

Neste post farei uma breve explicação de como se conectar à dispositivos de rede via cabo USB-Serial, usado em vários dispositivos de Rede como roteadores e Switches.

Como usar USB-Serial no linux para conexão em via Terminal

A maioria dos dispositivos de Rede oferecem a conexão serial-usb como interface de manutenção e configuração, apesar de muitos já oferecerem uma interface gráfica, muitos administradores ainda preferem estar conectados via terminal, no caso do Windows basta instalar o drive do adaptador USB e conectar via cliente porém no Linux o módulo precisa ser carregado e neste exemplo iremos usar um cliente via Terminal.

Após conectar o dispositivo serial em alguma das entradas USB vamos usar o comando lsusb que identifica as conexões USB.

Neste exemplo o nosso dispositivo tem a seguinte identificação:

Bus 001 Device 024: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port

Agora é necessário carregar o módulo do dispositivo, de acordo com as informações obtidas no comando anterior:

Para verificar se realmente o módulo foi carregado e está pronto para conexão vamos usar o dmesg:

Basta agora dar as permissões de leitura e escrita ao nosso dispositivo que está identificado como ttyUSB0.

Nosso dispositivo está pronto, podemos ainda tornar esta configuração persistente editando o arquivo /etc/modules e inserindo ao final do arquivo a seguinte linha usbserial vendor=0x067b product=0x2303.

Agora é necessário um cliente para conectar ao dispositivos, as opções são várias como: putty, teraterm, secureCRT, etc. para este exemplo vamos continuar no terminal e usar o cu que é extremamente leve e está disponível na maioria dos repositórios. No caso Debian e derivados pode ser instalado com o comando apt install cu.

Para conectar vamos usar o comando cu -l /dev/ttyUSB0 -s 9600, onde a opção -l nos permite apontar o dispositvo USB e a opção -s permiteinformar o baud rate(taxa de transmissão), para dispositivos Cisco o padrão é 9600, em dispositivos Nokia por exemplo, esse valor é 155200.

Para encerrar a sessão é simples, ainda com a sessão aberta no terminal basta digitar o comando ~. que a sessão será encerrada.

Neste post tentarei explicar como funciona o Link Aggregation, que é bastante comum em Uplinks entre switches e routers mas que também pode ser aplicado em hosts, em nosso caso aplicaremos em um servidor GNU/Linux Debian Buster.

Como funciona o Link Aggregation?

O Link Aggregation está descrito na norma IEEE 802.3ad, e possibilita vincular dois ou mais links ethernet através de um único link virtual.

Esta funcionalidade nos permite prover alta disponibilidade para rescursos importantes em uma rede, neste exemplo será usado um servidor Linux com duas interfaces Ethernet e um módulo que está no kernel chamado bonding.

O módulo bonding tem 7 modos de operação e cada oferece recursos diferentes. Neste cenário vamos usar Mode=0 (balance round-robin) o qual provê tolerancia à falhas dos links e também faz o balanceamento de cargas. Outros parametros também podem ser utilizados, como o miimom que define o tempo de espera para monitoramento da interface bounding, downdelay que define o tempo de espera para desabilitar uma interface escrava em caso de falha e deve ser usada em conjunto com miimom e também o parametro updelay o qual define o tempo de espera para ativar uma interface escrava após detecção de normalização do link principal.

Para configuração vamos utilizar duas interfaces físicas sendo elas enp1s0 e enp7s0 como escravas e criaremos uma interface virtual bond0 no modo round-robin:

miimom=100    -> o link será monitorado a cada 100 ms
downdelay=200 -> a interface só será desabilitada em caso de falha após 200 ms
updelay=220   -> tempo em ms que o link irá retomar após falha

O Debian Buster temos que instalar o ifenslave que irá ativar/desativar as interfaces, como usuário root vamos às configurações:

root@server~# apt install ifenslave

Em seguida ativamos o módulo bonding no Kernel:

root@server~# modprobe bonding

Verificando se o módulo foi ativado:

root@server~# lsmod | grep bonding
bonding               180224  0

O próximo passo é configurar as interfaces, aqui será criado o link virtual bond0 e as interfaces que farão parte do Link Aggregation serão declaradas dentro desta. No Debian Buster todas interfaces são configuradas em um único arquivo que fica em /etc/network/interfaces.

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
#allow-hotplug enp1s0
#iface enp1s0 inet dhcp
#

# Interface bonding
# Static IP address
auto bond0
iface bond0 inet static
        bond-slaves enp1s0 enp7s0
        bond-mode  balance-rr
        bond-miimon 100
	bond-updelay 220
	bond-downdelay 220
        bond-primary enp1s0 enp7s0

        address 192.168.122.188
        netmask 255.255.255.0
        network 192.168.122.0
        broadcast 192.168.122.255
        gateway 192.168.122.1

Feito isso nossa configuração está pronta, basta reiniciar os serviços de rede:

root@server:~# /etc/init.d/networking restart

Para verificar se tudo está funcionando corretamente vamos rodar o comando ip addr show

root@server:~$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP group default qlen 1000
    link/ether 52:54:00:82:9d:48 brd ff:ff:ff:ff:ff:ff
3: enp7s0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP group default qlen 1000
    link/ether 52:54:00:82:9d:48 brd ff:ff:ff:ff:ff:ff
4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 52:54:00:82:9d:48 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.188/24 brd 192.168.122.255 scope global bond0
       valid_lft forever preferred_lft forever

Podemos perceber que as interfaces enp1s0 e enp7s0 não receberam enderaçamento IP e a interface virtual bond0 está endereçada, podemos ainda ver o processo rodando em /proc com o comando cat /proc/net/bonding/bond0 :

Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: load balancing (round-robin)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 200
Down Delay (ms): 200

Slave Interface: enp1s0
MII Status: up
Speed: Unknown
Duplex: Unknown
Link Failure Count: 0
Permanent HW addr: 52:54:00:82:9d:48
Slave queue ID: 0

Slave Interface: enp7s0
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 52:54:00:3e:74:69
Slave queue ID: 0

Nosso servidor já está rodando com balanceamento de carga e tem tolerancia à falhas, qualquer interface física que vier a cair, a segunda continuará rodando.

Referência: https://servidordebian.org/pt/squeeze/config/network/bonding

Este procedimento é necessário quando, temos um arquivo .pcf que é usado para conectar em uma VPN Cisco via Client do Windows e precisamos conectar em SO Linux ou Unix-like e não sabemos a chave pré-compartilhada.

Vamos ao primeiro passo:

• Baixar o pcf2vpnc

$ wget http://svn.unix-ag.uni-kl.de/vpnc/trunk/pcf2vpnc

• Torná-lo executável

$ chmod +x pcf2vpnc

• Mover para o $PATH - opcionalmente /usr/bin

$ vm pcf2vpnv /usr/local/bin/

Segundo, cisco decrypt, esse fará a decriptografia:

• Baixar o decrypt

$ wget http://www.unix-ag.uni-kl.de/~massar/soft/cisco-decrypt.c

• Instalar as dependencias necessários, no caso debian…

$ sudo apt install libgcrypt-dev libgpg-error-dev

• Compilar os binários

$ gcc -Wall -o cisco-decrypt cisco-decrypt.c $(libgcrypt-config --libs --cflags)

• Mover para o $PATH

$ sudo mv cisco-decrypt /usr/local/bin

Agora é hora de gerar o .conf

$ pcf2vpnc cisco.pcf > client.conf

Feito isso basta editar o arquivo client.conf caso necessário, exemplo user e mover para o diretório do VPNC.

$ mv client.cong /etc/vpnc/default.conf

O comando acima vai sobrescrever o arquivo default.conf existente. Já estamos prontos para conectar a VPN, caso tudo tenha ocorrido corretamente, será necessário digitar a senha autenticação.

$ vpnc

O protocolo IPv4 possui 32 bits de largura (de 0 a 31). Como cada byte tem 8 bits, podemos dizer que o cabeçalho IPv4 possui 4 bytes de largura, e cada espaço existente em cada linha no cabeçalho deverá receber um algarismo binário.

Análise de Tráfego em Redes TCP/IP

Cabeçalho IPv4

| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|
|    1 byte      |    2 byte     |   3 byte      |   4 byte      |
| 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7|
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|
|version |  IHL  |Type of service|       Total Lenght            |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|
|      Identification            |Flag | Fragment Offset         |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|
| Time to Live   | Protocol      |    Header Checksum            |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|
|                     Source Address                             |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|
|                     Destination Address                        |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|
|              Options                           | Padding       |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|

• Campo Version

  O campo version possui largura de 4 bits e é responsável por informar qual é a versão do IP, sendo assim no IPv4 sempre teremos o conteúdo binário 0100 que representa 4 em números binários.

• Campo IHL ( Internet Header Lenght)

  Este campo pode ser traduzido para tamanho do cabeçalho internet, também possui 4 bits e é responsável por informar quantas linhas há no cabeçalho. Todos os elementos das 5 primeiras linhas do cabeçalho IPv4 são de existência obrigatórios, isso significa dizer que o mínimo de linhas de um cabeçalho IP será cinco. Em outras palavras o cabeçalho IP terá no mínimo 20 bytes (5 linhas x 5 bytes por linhas). Em resumo o campo IHL deve ter no mínimo 20 bytes e no máximo 60 bytes, essa variação se dará devido ao campo options.

• Campo Type of Service

O campo ToS, que significa tipo de serviço, possui 8 bits (1 byte) de tamanho e é responsável por determinar algumas características para o tráfego de dados. com vista a melhorar a qualidade do serviço (QoS). Este campo basicamente indica para os roteadores que estarão no caminho do pacote como tal deverá ser tratado, se o roteador suportar ToS ele obedererá às indicações. É fato que a maioria dos roteadores ignora o conteúdo deste campo, pois o QoS é comumente tratado por outros protocolos, este campo não é relevante para a análise de tráfego.

• Campo Total Lenght É o campo que contém o tamanho total do pacote IP (Cabeçalho + Payload), pode ser formado por 16 bits, teoricamente, admite valores de 0 a 65535 em decimal, porém deve ser subtraído desse valor o cabeçalho IP que não pode ser menor que 20 bytes e o payload que deve ter no mínimo 1 byte de dados, então o menor valor para esse campo será 21 em decimal. Em resumo, um pacote IP poderá ter até 65535 bytes de tamanho, isso equivale a, aproximadamente 64KB.

• Campo Identification Este é o primeiro campo da segunda linha do cabeçalho IPv4, a qual trata da fragmentação de pacotes. Este campo identifica os pacotes IP, cada pacote deverá ter um número de identificação diferente que vai de 0 a 65535 em decimal e seu valor é criado a cada nova conexão, com base em algoritmos no kernel do SO, dentro da mesma conexão os pacotes terão números seriais. Apenas para entender o porque da fragmentação, as redes mais comuns são do tipo ethernet, que, normalmente só conseguem transmitir 1500 bytes de cada vez, Caso o IP a ser transmitido tenha, por exemplo, 3500 bytes será necessário quebrá-lo em pedaços.

• Campo Flag: Como dito anteriormente a segunda linha do cabeçalho IPv4 é destinada a controlar a fragmengação, o campo flags é responsável por ajudar a controlar o fluxo de fragmentos IP, quando ocorre a fragmentação. Quando fragmentados, os pacotes possuem o mesmo cabeçalho e por consequencia o mesmo número de identificação (Identification), daí surge a próxima medida de controle: as flags. Flag é um campo que possui 3 bits, e são eles:

• none: esse bit é reservado para uso futuro e, por enquanto, sempre terá valor zero.
• DF : Significa Don’t Fragment. Esse bit é utilizado para expressar se poderá ou não haver fragmentação do pacote IP. Caso o bit seja marcado com valor 1, o pacote não poderá sofrer fragmentação por roteadores que estejam no caminho. Assim, se o pacote for maior do que capacidade de um determinado roteador, este enviará uma solicitação de retransmissão em partes menores. Tal solicitação será feita pelo protocolo ICMP. Caso o bit DF esteja marcado como 0, os roteadores existentes no caminho poderão realizar a quebra do pacote, então os valores possíveis são 0 (pode fragmentar) e 1 (não pode fragmentar).
• MF : Significa More Fragment. Caso seja necessário fragmentar um pacote, o bit MF indicará, no destino, a cada fragmento recebido, se haverá mais fragmentos que chegarão ou não. O bit 1 representa mais fragmentos. Exemplo: ao dividir um pacote em 3 partes, as duas primeiras terão o bit MF marcado com 1, enquanto a última será marcada com MF 0.

A flag MF só poderá receber o bit 1 se DF for igual a 0.

• Campo Fragment Offset: É o último elemento de controle na fragmentação. O Fragment Offset é um campo de 13 bits que se refere ao byte inicial de cada fragmento do pacote dividido por 8. O Cálculo sempre irá considerar apenas o payload. * Como exemplo, vamos manipular um pacote de 3000 bytes. Se cada fragmento estiver limitado a 1500 bytes de tamanho total e o cabeçalho tiver 20 bytes, o payload só poderá ter, no máximo, 1480 bytes. Portanto, o payload do primeiro fragmento irá de 0 a 1479. Então considerando o primeiro byte do payload do primeiro fragmento, que estará na posição 0, teremos Fragment Offset será 0 / 8= 0. A segunda parte dp payload irá de 1480 a 2959. Então Fragment Offset será 1480 /8 = 185. O terceiro e último pedaço irá de 2960 a 2979, ou seja, Fragment Offset será 2969 / 8 = 370. Com isso, será possível remontar o pacote na ordem certa, bastando colocar os fragmentos em ordem crescente relativa ao Fragment Offset, a ordem final de montagem será 0, 185, 375.

  ---

• Análise de uma fragmentação IP Vamos realizar uma análise com auxílio do tcpdump. Será enviado um pacote gerado com o comando ping, mostrado a seguir.

		keilon@ubuntu:~$ ping -c 1 -s 3500 192.168.1.1

Este comando gerou um pacote com 3500 bytes de payload. Em uma rede ethernet com taxa de transmissão de 1500 bytes, esse pacote terá que ser fragmentado em três pedaços. Para fazer a anãlise vamos analisar a saída do tcpdump:

		keilon@ubuntu:~$ sudo tcpdump -n icmp and host 192.168.1.1 -v
		tcpdump: listening on enp6s0, link-type EN10MB (Ethernet), capture size 262144 bytes

		➊	00:41:17.773004 IP (tos 0x0, ttl 64, id 3581, offset 0, flags [+], proto ICMP (1), length 1500)
				192.168.1.10 > 192.168.1.1: ICMP echo request, id 3, seq 1, length 1480

		➋	00:41:17.773016 IP (tos 0x0, ttl 64, id 3581, offset 1480, flags [+], proto ICMP (1), length 1500)
				192.168.1.10 > 192.168.1.1: ip-proto-1

		➌	00:41:17.773018 IP (tos 0x0, ttl 64, id 3581, offset 2960, flags [none], proto ICMP (1), length 568)
				192.168.1.10 > 192.168.1.1: ip-proto-1

		➍	00:41:17.773986 IP (tos 0x0, ttl 64, id 25582, offset 0, flags [+], proto ICMP (1), length 1500)
				192.168.1.1 > 192.168.1.10: ICMP echo reply, id 3, seq 1, length 1480

		➎	00:41:17.774106 IP (tos 0x0, ttl 64, id 25582, offset 1480, flags [+], proto ICMP (1), length 1500)
				192.168.1.1 > 192.168.1.10: ip-proto-1

		➏	00:41:17.774141 IP (tos 0x0, ttl 64, id 25582, offset 2960, flags [none], proto ICMP (1), length 568)
				192.168.1.1 > 192.168.1.10: ip-proto-1

Temos duas linhas por pacote, a primeira se refere ao IP e a segunda ao ICMP. As linhas de 1 a 3 estão mostrando o envio do ping, conhecido como ICMP echo request, enquanto 4 a 6 mostram a responsta a este, ou seja um ICMP echo replay. Na linha 1, vemos que a máquina 192.168.1.10 enviando um ping para 192.168.1.1, o campo identification tem como valor 3581 e Fragment Offset é 0. > O tcpdump mostra o valor de Fragment Offset multiplicado por 8, com isso não vemos o offset puro, e sim o byte real que o gerou.

Ainda na linha 1, flags [+] represente que MF é igual a 1. Então, teremos mais fragmentos depois deste, isto é a prova de que o pacote foi fragmentado. O tamanho total o do fragmento atual (cabeçalho + payload) é igual a 1500 bytes. O tamanho do payload, que é o protocolo ICMP, é 1480 bytes. Os ICMP echo replay e echo request tem seus próprios campos de identificação. A linha 2 mostra que o identification do IP é 3581, já sabemos que todos os fragmentos de um pacote IP possuem o mesmo número de identificação, o mesmo campo Protocol, que, no caso corresponde ao ICMP, mesmo endereço de origem e destino. Se observarmos todos os campos são iguais nas linhas 1, 2 e 3. Isso confirma que temos três fragmentos de um mesmo pacote IP. Ainda na linha 2 é possível ver o Fragment Offset 1480 e a flag MF marcada com 1 novamente, na linha 3 o offset é 2960 e MF está desabilitado, indicando que não há mais fragmentos a serem recebidos. As linhas de 4 a 6 mostram a responta do ping.

• Campo Time to Live (TTL) Este campo se refere ao tempo de vida de um pacote, inicialmente os pacotes tem um valor de TTL pré-determinado geralmente pelo kernel do SO, a cada roteador (HOP) que o pacote passa é decrementado o valor 1 do TTL que quando chega a 0 é descartado pelo roteador, evitando deste modo que o pacote circulasse eternamente na rede de computadores.

O comando que mostra explicitamente o TTL é o ping, que serve para tester a conectividade entre hosts.

keilon@ubuntu:~$ ping -c 4 www.google.com
PING www.google.com (172.217.30.164) 56(84) bytes of data.
64 bytes from 172.217.30.164: icmp_seq=1 ttl=115 time=19.5 ms
64 bytes from 172.217.30.164: icmp_seq=2 ttl=115 time=19.9 ms
64 bytes from 172.217.30.164: icmp_seq=3 ttl=115 time=19.9 ms
64 bytes from 172.217.30.164: icmp_seq=4 ttl=115 time=20.0 ms

--- www.google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 12033ms
rtt min/avg/max/mdev = 19.471/19.812/19.959/0.199 ms

• O resultado do comando acima é a respota do Google, ou seja, o echo reply. Muito provavelmente este servidor web tem o TTL 128 e foi decrementando até chegar em 115, passando por 13 roteadores. O campo TTL possui 8 bits e pode ir de 0 a 25, cada sistema operacional tem um TTL padrão que pode ser alterado.

keilon@ubuntu:~$ traceroute www.google.com
traceroute to www.google.com (172.217.172.132), 64 hops max
  1   192.168.1.1  0,397ms  0,326ms  0,351ms
  2   177.66.167.170  1,340ms  0,899ms  0,907ms
  3   172.16.167.5  1,274ms  1,745ms  1,052ms
  4   189.125.215.253  2,902ms  1,878ms  2,151ms
  5   64.209.11.186  18,873ms  18,946ms  19,048ms
  6   72.14.212.213  21,351ms  22,012ms  22,109ms
  7   *  *  *
  8   209.85.242.198  19,827ms  20,025ms  19,926ms
  9   172.253.66.25  22,137ms  21,859ms  21,961ms
 10   74.125.243.65  21,093ms  20,964ms  20,779ms
 11   172.253.66.23  20,192ms  19,913ms  19,960ms
 12   172.217.172.132  19,810ms  19,969ms  19,916ms

Acima um exemplo usando o traceroute, que mostra a rota do pacote até o host de destino. Quando uma linha mostrar mais de um roteador, significa que temos roteadores trabalhando em paralelo fazendo balanceamento de carga.

• Campo Protocol Este campo é responsável por dizer qual será o conteúdo encontrado no payload do IP. No payload do IP só poderá existir um tipo de elemento: outro protocolo, em outras palavras o IP sempre irá carregar outro protocolo no seu payload, os protocolos que podem ser encapsulados pelo IP são conhecidos como protocolos IP.

|------------------------|
|     Cabeçalho IP       |
|------------------------|
| |--------------------| |
| |   Cabeçalho TCP    | |
| |                    | |
| |--------------------| |
| |    Payload TCP     | |
| |                    | |
| |                    | |
| |                    | |
| |--------------------| |
|------------------------|

A figura acima representa o funcionamento do protocolo IP, sempre encontraremos dentro dele, outro protocolo como payload. O campo Protocol possui 8 bits, e por isso admite valores de 0 a 255, o protocolo ICMP é o número 1, enquanto o TCP é o número 7 e o UDP o número 17.

• Campo Header Checksum

  O campo header checksum é responsável por garantir que o pacote IP transite integro. Esse campo pode nos dizer por exemplo, se durante o tráfego algum equipamento truncou bits. O Header Checksum contém 16 bits e vai de 0 a 65535 e é calculado com base nos campos existentes em todo cabeçalho IP, em resumo é feito um cálculo de todos os campos do cabeçalho IP e este valor fica registrado dentro do campo header checksum.

• Campo Source Address O Source Address é o campo que se refere ao endereço do host que está enviando o pacote IP, o campo contém 32 bits de largura, ou seja 4 bytes. Os campos Source Address e Destination Address são os maiores campos do cabeçalho IP, e o motivo pelo qual foi escolhido 32 bits de largura para o cabeçalho.

• Campo Destination Address

  É similar ao Source Address, porém contém o endereço de destino e é o último campo obrigatório do cabeçalho IP, tendo até aqui 20 bytes de cabeçalho.

• Campo Options

  Este campo não é de existência obrigatória no pacote IP, seu tamanho irá variar de acordo com a quantidade de informações que ele terá, podendo ir de 0 a 40 bytes, o que corresponde de 0 a 10 linhas de cabeçalho.

  Este campo não é tão importante para a análise de tráfego, ele só é relevante em análises muito avançadas. Apenas por curiosidade este campo pode trazer as seguintes informações: - Informações de segurança e restrições de acesso e manipulação do pacote; - Relação de roteadores transpostos para chegar a um destino (Record Route); - data e hora (time stamp) - Loose source routing - Strict source routing

• Campo Padding

  Este campo funciona como uma “rolha”, e só existirá caso o campo options também exista, a função dele é muito simples, como o campo options tem tamanho variados, seu término geralmente não irá coincidir com o fim da linha do cabeçalho. Em outras palavras, cada linha do cabeçalho deve ter obrigatoriamente 4 bytes, assim o padding entra para completar, caso necessário, a linha options.

• Payload

  O campo payload de um pacote IP nada mais é do que a área de dados. É nessa área que serão colocados os dados que trafegarão dentro dele na rede. O tamanho do payload irá variar de acordo com a quantidade de informações que nele será colocada. É importante ressaltar que o menor cabeçalho IP contém 20 bytes de tamanho e que o maior IP possível incluindo o cabeaçalho tem 65535 bytes. Assim o maior payload IP possível terá 65535 - 20 = 65515 bytes. Considerando que um pacote Ip deverá conter outro protocolo dentro de seu payload, este nunca estará vazio. Com isso, podemos dizer que o menor tamanho possível para um payload IP é 1 byte.

  Onde está a máscara de rede e o CIDR? Ambos fazem parte de procedimentos internos e não trafegam na rede. Note que eles nem aparecem nos campos do protocolo IP.

• Características do IPv4

  • Não garantia de entrega - O protocolo IP é do tipo best effort, ou seja,não garante, por si só, que os dados serão entregues ao destinatário. Para o caso de garantia de entrega é necessário outro protocolo, o TCP por exemplo.
  • Não garantia de payload - A única verificação que o protocolo IP faz é a do cabeçalho, por intermédio do header checksum, então o IP não é capaz de garantir os dados dentro de seu payload, outros protocolos farão essa garantia.
  • Endereço Organizado - Trata-se do endereçamento IP, possui um método extremamente flexível e organizado.
  • Fragmentação de Pacote - Os pacotes podem ser fragmentados sempre que necessário, o que facilita seu tráfego por diversos tipos de topologias, há um mecanismo de controle para remontagem.
  • QoS não garantido - O IP pode utilizar o “Quality of service”, provido pelo campo Type of Service ou Differentiated Services, com isso é possível priorizar tráfego e atribuir graus de importância aos pacotes, todavia, geralmente os roteadores ignoram esse campo, com isso não é possível garantir que haja QoS.
  • Tempo de Vida - Esta característica é provida pelo campo TTL, é essencial para que um pacote não trafegue eternamente pelas redes.
  • Container de protocolos - O IP, carrega dentro de si outros protocolos.
  • Roteamento - O pacote IP contém as informações necessárias para chegar a seu destino, campo Destinarion Address já é suficiente para isso.

• Considerações gerais sobre o IPv4

  Cada protocolo IP tem uma importância e executa alguma função especial: transportar outros protocolos. São eles o TCP e UDP. Em outras palavras, o TCP e o UDP recebem outros protocolos no seu payload, como o HTTP.

|---------------------|
|   Cabeçalho IP      |
|---------------------|   
| |-----------------| |      
| | Cabeçalho TCP   | |  
| |-----------------| |
| | |-------------| | |
| | |             | | |
| | |  Protocolo  | | |
| | |    HTTP     | | |
| | |             | | |
| | |             | | |
| | |             | | |
| | |-------------| | |
| |-----------------| |
|---------------------|

• Conclusão O protocolo IP funciona como um grande caminhão, a boléia representa o cabeçalho, onde está todo o controle de tráfego. A corroceria é análoga ao payload, onde estão os dados que serão carregados. O protocolo IP sempre terá outro protocolo em seu payload. A todos os protocolos que podem ser transportados pelo IP damos o nome de Protocolos IP.