RoteamentoEstáticoIPv4
Créditos: O conteúdo e ilustrações totais ou parciais apresentados aqui, foram extraídos e/ou adaptados de experimentos e conteúdos de semestres anteriores da mesma disciplina, conduzida pelo professor Marcelo Maia Sobral, a quem fica registrado nossos agradecimentos.
Encaminhamento IP
Todo host é capaz de realizar uma função da camada de rede chamada de encaminhamento IP (IP forwarding). O encaminhamento é feito quando um host recebe um datagrama IP, e precisa decidir o que fazer com ele. O destino do datagrama depende do endereço de destino contido em seu cabeçalho IP.
- Se o endereço IP for o do próprio host: o conteúdo do datagrama é desencapsulado e entregue à camada superior.
- Se o endereço IP NÃO for o do próprio host: a tabela de rotas do host é consultada para buscar uma rota que satisfaça o endereço de destino. Caso ela exista, o datagrama é transmitido para o próximo roteador indicado nessa rota.
Uma rota serve para informar como se chega a um determinado destino. Um destino pode ser um único endereço IP, ou uma subrede (que contém um conjunto de endereços IP). Para que um pacote IP chegue a um destino, deve-se transmiti-lo para o próximo roteador em direção a esse destino. Esse próximo roteador também deve conhecer uma rota para tal destino, repetindo o mesmo procedimento. Ao menos duas informações compõem cada rota:
- O destino, que é expressado como uma subrede: Uma subrede é representada por um prefixo de rede e uma máscara.
- O próximo roteador, expressado por um endereço IP: o endereço IP do próximo roteador (também chamado de gateway, que significa portal em inglês), o qual deve pertencer à mesma subrede do equipamento que o especifica em uma rota.
No caso em que o endereço de destino não for o do próprio host, esse endereço é comparado com cada rota existente na tabela de rotas. Rotas com máscaras de rede maiores são testadas primeiro (o tamanho de uma máscara é definido pela quantidade de bits 1 que ela possui), pois são rotas para subredes menores e, portanto, mais específicas. Se nenhuma rota servir, o datagrama é silenciosamente descartado.
A tabela de rotas a seguir foi obtida em um computador com sistema operacional Linux.
aluno@M1:~$ route -n
Tabela de Roteamento IP do Kernel
Destino Roteador MáscaraGen. Opções Métrica Ref Uso Iface
0.0.0.0 191.36.9.254 0.0.0.0 UG 0 0 0 enp0s25
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 enp0s25
191.36.9.0 0.0.0.0 255.255.255.0 U 0 0 0 enp0s25
192.168.2.64 191.36.9.1 255.255.255.192 U 0 0 0 enp0s25
Supondo que esse host tenha que encaminhar um datagrama com endereço de destino 8.8.8.8, a busca por uma rota adequada seria esta:
- Rota para 192.168.2.64/26: ao aplicar a máscara /26 (255.255.255.192) ao endereço de destino 8.8.8.8, obtêm-se o prefixo 8.8.8.0. Como ele é diferente de 192.168.2.64, esta rota não serve.
- Rota para 191.36.9.0/24: ao aplicar a máscara /24 ao endereço de destino 8.8.8.8, obtêm-se o prefixo 8.8.8.0. Como ele é diferente de 191.36.9.0, esta rota não serve.
- Rota para 169.254.0.0/16: ao aplicar a máscara /16 ao endereço de destino 8.8.8.8, obtêm-se o prefixo 8.8.0.0. Como ele é diferente de 169.254.0.0, esta rota não serve.
- Rota para 0.0.0.0/0: ao aplicar a máscara /0 ao endereço de destino 8.8.8.8, obtêm-se o prefixo 0.0.0.0. Como ele é igual a 0.0.0.0 (prefixo da rota), esta rota será usada.
Se outro datagrama tiver endereço de destino 191.36.9.140, a busca pela rota seria:
- Rota para 192.168.2.64/26: ao aplicar a máscara /26 ao endereço de destino 191.36.9.140, obtêm-se o prefixo 191.36.9.128. Como ele é diferente de 192.168.2.64, esta rota não serve.
- Rota para 191.36.9.0/24: ao aplicar a máscara /24 ao endereço de destino 191.36.9.140, obtêm-se o prefixo 191.36.9.0. Como ele é igual a 191.36.9.0 (prefixo da rota), esta rota será usada.
Roteamento estático
Cada host ligado a Internet possui uma tabela de rotas. É pelo conteúdo dessa tabela que ele sabe como transmitir os pacotes para cada destino. Em seu computador, você pode visualizar essa tabela da seguinte forma:
# Isto funciona em qualquer *nix que se preze ...
netstat -rn
Ao se configurar uma interface de rede, cria-se uma rota automática para a subrede diretamente acessível via aquela interface. Isto se chama roteamento mínimo. Por exemplo, se uma interface de rede foi configurada com o endereço IP 192.168.10.1/24, sua tabela de rotas pode se apresentar assim:
aluno@M1:~> ifconfig eth1 192.168.10.1 netmask 255.255.255.0
aluno@M1::~> netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
Rotas arbitrárias podem ser adicionadas manualmente a essa tabela. Uma rota possui estas informações:
- Subrede de destino: isso se compõe de um prefixo de rede e uma máscara
- Próximo roteador: o endereço IP do próximo roteador (opcional)
- Interface de rede: a interface de rede por onde o datagrama deve ser transmitido (opcional)
- Métrica: um número que informa o custo da rota (opcional .. usado por protocolos de roteamento dinâmico)
Obs: ao menos próximo roteador ou interface de rede precisam ser especificados.
Em sistemas Linux, rotas estáticas podem ser criadas com o comando route. A seguir mostram-se alguns exemplos de criação de rotas:
- Rota para uma subrede de destino através de um próximo roteador:
# route add -net prefixo/mascara gw IP_roteador route add -net 192.168.10.0/24 gw 191.36.9.254
- Rota para um host específico através de um próximo roteador:
# route add -host IP_host gw IP_roteador route add -host 192.168.10.5 gw 191.36.9.100
- Rota para um host específico através de uma interface de rede: nesse caso, imagine que exista uma subrede que contém o IP do host, porém esse host específico está conectado a outra interface de rede.
# route add -host IP_host gw IP_roteador route add -host 192.168.10.5 dev eth1
A rota default, por ser corriqueira, pode ser criada com uma palavra-chave especial no comando route. Essa rota tem o seguinte significado: se o destino não estiver em minha própria subrede, e nenhuma outra rota específica existir para a subrede onde se encontra, então repasse o datagrama para o roteador indicado. O comando route pode ser usado assim:
# adiciona a rota default, que passa pelo roteador 192.168.10.100
route add default gw 192.168.10.100
Outra forma de adicionar essa rota é:
# este comando tem o mesmo efeito que o anterior ...
route add -net 0.0.0.0/0 gw 192.168.10.100
Em roteadores Cisco, os exemplos sobre rotas estáticas implicariam estes comandos:
- Rota para uma subrede de destino através de um próximo roteador:
ip route 192.0.10.0/24 191.36.9.254
- Rota para um host específico através de um próximo roteador:
ip route 192.168.10.5/32 191.36.9.100
- Rota para um host específico através de uma interface de rede: nesse caso, imagine que exista uma subrede que contém o IP do host, porém esse host específico está conectado a outra interface de rede.
ip route 192.168.10.5/32 ethernet 1
Finalmente, se for usado o roteador sem-fio TP-Link WDR4300, rotas estáticas podem ser adicionadas no menu Advanced Routing -> Static Routing List em sua interface de gerenciamento:
Criação de uma rota estática na interface de gerenciamento do roteador TP-Link WDR4300
Protocolo e serviço SSH
SSH, ou Secure Shell, é um protocolo de rede que permite a comunicação segura e a execução de comandos remotamente em sistemas Unix-like, como o Linux. Ele oferece uma maneira segura de acessar e controlar um sistema remotamente, permitindo que você faça login em um servidor ou computador a partir de outro local, como se estivesse fisicamente presente na máquina.
O SSH é amplamente utilizado para administração de servidores, transferência de arquivos e execução remota de comandos. Ele substituiu os métodos mais antigos e inseguros, como o Telnet e o rlogin, que transmitiam informações, incluindo senhas, de maneira não criptografada, tornando-os vulneráveis a ataques de interceptação.
O SSH utiliza criptografia para proteger as informações transmitidas entre o cliente (a máquina que está fazendo o acesso remoto) e o servidor (a máquina que está sendo acessada remotamente). Isso inclui a criptografia das credenciais de login, bem como dos dados transmitidos durante a sessão, garantindo que mesmo se alguém interceptar o tráfego, não será capaz de entender o conteúdo.
No Ubuntu e em outras distribuições Linux, o servidor SSH é geralmente fornecido pelo pacote "OpenSSH". Os usuários podem se conectar a um servidor SSH usando um cliente SSH, como o "ssh" na linha de comando ou várias ferramentas gráficas disponíveis. Para ativar o serviço SSH no Ubuntu, você pode instalar o pacote OpenSSH Server e, em seguida, iniciar e habilitar o serviço usando comandos como:
Instalação (caso ainda não esteja instalado)
sudo apt-get update
sudo apt-get install openssh-server
- Iniciar o serviço
sudo systemctl start ssh
- Habilitar o serviço para iniciar automaticamente na inicialização
sudo systemctl enable ssh
Após configurar o servidor SSH, você pode se conectar a ele usando o comando ssh seguido pelo nome de usuário e endereço IP do servidor:
ssh nome_de_usuario@endereco_ip_do_servidor
O SSH é uma ferramenta poderosa e essencial para administradores de sistemas e desenvolvedores que precisam gerenciar servidores e sistemas remotos de forma segura e eficiente.
para acessar um computador remoto via SSH, é necessário que o nome de usuário tenha uma conta válida no computador remoto. Isso significa que o nome de usuário deve estar cadastrado como um usuário do sistema no servidor SSH que você está tentando acessar.
Quando você configura um servidor SSH, ele normalmente utiliza os usuários do sistema operacional subjacente. Isso significa que os usuários precisam existir no sistema e ter permissões para se conectar remotamente. Cada usuário terá um diretório home e as devidas permissões associadas.
Ao tentar se conectar a um computador remoto via SSH, você geralmente usará o seguinte formato de comando:
ssh nome_de_usuario@endereco_ip_do_servidor
O SSH autenticará o nome de usuário e a senha (ou chave de autenticação, se configurada) no servidor remoto. Se o nome de usuário não existir no sistema remoto ou se as credenciais estiverem incorretas, o acesso será negado.
Em ambientes corporativos ou em servidores públicos, é uma boa prática restringir o acesso apenas a usuários autorizados. Isso pode ser feito por meio da administração cuidadosa das contas de usuário no sistema e pela configuração das políticas de autenticação do SSH para garantir que apenas usuários válidos tenham permissão para se conectar remotamente.
Isso significa que os usuários precisam estar cadastrados como usuários do sistema operacional, não necessariamente limitados aos usuários da pasta /home ou aos usuários "users".
Para acessar um computador remoto via SSH, você precisa ter uma conta válida no sistema operacional desse computador. Essa conta pode ser um usuário que você cria para um indivíduo específico, ou pode ser uma conta de sistema que é usada para fins específicos, como acesso automatizado ou administração.
Em resumo, quando você usa o SSH para acessar um computador remoto, está usando uma conta de usuário do sistema operacional desse computador para autenticação. Isso pode ser uma conta de usuário ou uma conta de sistema, dependendo do que você precisa realizar ao se conectar ao servidor SSH.
Em um sistema Linux, é possível obter informações sobre acessos locais e remotos consultando os logs do sistema. Os logs registram várias atividades do sistema, incluindo logins e tentativas de acesso remoto. Os logs relevantes podem incluir:
- Arquivo /var/log/auth.log ou /var/log/secure (dependendo da distribuição): Esses arquivos de log registram informações sobre autenticações e atividades de segurança. Eles incluem informações sobre logins, tentativas de logins bem-sucedidas e malsucedidas, bem como outras atividades relacionadas à autenticação.
- Arquivo /var/log/syslog: Este arquivo de log contém uma variedade de informações do sistema, incluindo informações relacionadas a logins e atividades do sistema.
- Arquivos de log do servidor SSH: O servidor SSH (geralmente o OpenSSH) também registra atividades de login e autenticação em seus próprios arquivos de log. A localização e o nome desses arquivos podem variar de acordo com a distribuição e a configuração do servidor SSH.
- Comandos como last e lastlog: O comando last pode ser usado para mostrar uma lista de logins recentes no sistema, incluindo logins locais e remotos. O comando lastlog fornece informações específicas sobre os últimos logins de cada usuário.
Lembrando que as localizações exatas e os nomes dos arquivos de log podem variar dependendo da distribuição Linux que você está usando. Além disso, para visualizar os logs, geralmente é necessário ter privilégios de administrador (root) ou usar o comando sudo.
É importante observar que as informações de log podem variar em detalhes dependendo das configurações do sistema. Para uma análise mais profunda e precisa, é recomendável consultar a documentação da sua distribuição Linux ou dos aplicativos relevantes (como o OpenSSH) para obter informações específicas sobre onde os logs são armazenados e como interpretá-los.
É possível fazer uma sessão SSH usando o nome de domínio em vez do endereço IP do computador remoto. Isso é especialmente útil quando você tem um domínio configurado para apontar para um determinado servidor e deseja se conectar usando esse nome de domínio em vez de lembrar o endereço IP.
Para fazer isso, você precisa ter uma configuração DNS correta para o nome de domínio que aponta para o endereço IP do servidor remoto. Depois de ter isso configurado, você pode usar o nome de domínio ao invés do endereço IP ao executar o comando SSH.
Por exemplo, se o nome de domínio é "meuservidor.com" e ele aponta para o endereço IP "123.456.789.123", você pode se conectar ao servidor usando:
ssh nome_de_usuario@meuservidor.com
O SSH usará a resolução DNS para converter o nome de domínio em um endereço IP e, em seguida, estabelecerá a conexão com o servidor remoto. Certifique-se de que o servidor SSH esteja configurado para aceitar conexões com o nome de domínio que você está usando.
Tenha em mente que, para usar nomes de domínio, é necessário que a resolução DNS esteja funcionando corretamente em seu sistema e que o servidor SSH esteja configurado para aceitar conexões usando nomes de domínio.