Roteamento estático entre redes#

Objetivos#

  • Interligar diferentes redes (LAN) usando um servidor central que pode ser um VPS ou, em meu caso, IP dinâmico.

  • Utilizando o SSH para contornos de bloqueios de portas em determinada instituição, onde somente permite tráfego em “portas conhecidas” TCP, como: 8080, 9090, 443, etc.

Mapeando as portas liberadas, supondo uma simples regra de#

firewall de bloqueio de porta.#

function testa_portas(){
    PORTA=$1
    traceroute --max-hops=5 -n -T google.com -p $PORTA \
        | grep <IP_KNOWN_VALID> && echo "porta: $PORTA livre!" \
        >> lista_portas.log

    # Com isso, se a PORTA estiver livre, completará o caminho até 
    # o destino, mas antes, verifique quantos saltos para sair
    # "para internet".
}

# Cuidado, de forma simultânea, o ADM pode achar que é um scan,
# mas é kkkk. Recomendo executar de forma sequencial.
for i in {1..9999}; do testa_portas $i; done

Criando a VPN sobre o SSH (TCP) - ponto-a-ponto (somente#

cliente e servidor)#

  • No servidor/roteador principal, é necessária a modificação do arquivo /etc/ssh/sshd_config, adicionando ou modificando o valor de PermitTunnel para yes.

No servidor, é recomendado, caso múltiplos dispositivos, criar uma nova bridge. Comando exemplo:

# Criação da bridge **Só aceita TAP!
brctl addbr vpn_bridge0
ip addr add 192.168.0.1/24 dev vpn_bridge0
ip link set dev vpn_bridge0 up

Cada cliente deve ter uma interface tuntap própria no SERVER como:

# Exemplo
ip tuntap add dev tap55 mode tap
ip link set tap55 up

# Add interfaces TAP:
DEV_TYPE=tap
TAP_INDEX=<INDICE PARA O CLIENTE>
TAP_INDEX=33
brctl addif vpn_bridge0 ${DEV_TYPE}${TAP_INDEX}

No lado do cliente, é a mesma lógica da interface TAP, mas tem de ser definido o IP e rota, caso haja diferentes redes – trataremos sobre abaixo.

# Exemplo
ip tuntap add dev tap55 mode tap
ip address add 192.168.0.66 dev tap55
ip link set tap55 up

Lan sobre o SSH:#

Adiantamos o processo quando foi criada a bridge, agora, precisamos repetir o processo para os demais clientes. Caso um determinado cliente A (172.20.1.0/24) precise chegar na mesma rede do cliente B (192.168.10.0/24), podemos definir rotas estáticas.

O cliente A precisa chegar no dispositivo (192.168.10.47)#

através do B.#

  • IP do cliente A na perspectiva do servidor: 192.168.0.5.
  • IP do cliente B na perspectiva do servidor: 192.168.0.10.

Definimos a rota no cliente A como ip route add 192.168.10.0/24 via 192.168.0.1, onde o 192.168.0.1 é o servidor! No servidor, precisamos definir a rota da subnet que o cliente B pertence com: ip route add 192.168.10.0/24 via 192.168.0.10.

Se for um simples dispositivo na rede, como um laptop ou celular, a requisição ocorrerá. Se tratando de dois dispositivos inerentes aos clientes A e B, mas que pertencem às suas respectivas subnets, é necessário que o roteamento ocorra nos clientes. Exemplo:

  • O cliente C pertence à mesma subnet que A.
  • O cliente D pertence à mesma subnet que B.
  • C precisa se comunicar com D.

O cliente C precisa ter uma rota que A (172.20.1.88) intermedia: ip route add 192.168.10.0/24 via 172.20.1.88. Da mesma forma, o cliente D com relação ao B (192.168.10.230): ip route add 172.20.1.0/24 via 192.168.10.230.

Mas isso é caótico! Inviável fazer para todos os 255-2 dispositivos que podem pertencer e querer se comunicarem, como uma única LAN.

Exemplo de Conexão SSH com Tunnel Ethernet#

Para conectar cliente e servidor usando SSH com túnel ethernet, execute no cliente:

# Conexão SSH com túnel ethernet
ssh -i /path/to/private_key -o Tunnel=ethernet -w 55:55 user@server

Parâmetros:

  • -i /path/to/private_key: Chave SSH para autenticação (opcional se usar senha).
  • -o Tunnel=ethernet: Túnel em camada 2 (ethernet), para TAP.
  • -w 55:55: Índices das interfaces TAP (cliente e servidor).
  • user@server: Usuário e endereço do servidor.

Após a conexão, as interfaces tap55 estarão ativas, permitindo tráfego na rede 192.168.0.0/24.

Por que usar TAP em vez de TUN?#

  • Camada de Operação:
    • TAP: Camada 2 (Data Link), suporta broadcasts e não-IP (ex.: ARP).
    • TUN: Camada 3 (Network), limitado a pacotes IP.
  • Suporte à Bridge:
    • TAP: Compatível com bridges (ex.: vpn_bridge0), ideal para LAN.
    • TUN: Não suporta bridges, usado em túneis ponto-a-ponto.
  • Flexibilidade de Rede:
    • TAP: Simula uma LAN completa, para comunicação como rede física.
    • TUN: Mais leve, mas menos versátil, sem tráfego de camada 2.
  • Requisito do SSH Tunnel:
    • TAP: Requerido por Tunnel=ethernet para frames ethernet.
    • TUN: Usado com Tunnel=point-to-point, limita a bridge.

Conclusão: TAP é usado devido à bridge (vpn_bridge0) e necessidade de LAN virtual com tráfego de camada 2.

Configuração com um intermediário roteador OpenWRT:#

É NECESSÁRIA REVISÃO NESSE PONTO, TALVEZ NÃO FUNCIONE, TESTEI EM SOMENTE UM CASO!

O processo é o mesmo, mas é necessário o pacote openssh opkg update && opkg install openssh-client, que traz todos os recursos que não estão inclusos no pacote dropbear, padrão.

As rotas e configuração da interface tap são as mesmas, mas algumas etapas quanto ao firewall são necessárias.

Iniciaremos criando um daemon de inicialização e auto conexão com o servidor.

  • Será configurado um par de chaves SEM senha. Mas, no servidor, o usuário para este caso será criado sem um shell: useradd ROTEADOR -N -m -s /bin/false. Com isso, não será permitido comandos remotos.

  • Crie uma chave com ssh-keygen e copie o conteúdo da chave pública no arquivo no home do usuário em /home/ROTEADOR/.ssh/authorized_keys.

# Script init (SysV init)
#!/bin/sh /etc/rc.common

START=99
STOP=10

start() {
    ip tuntap add dev tap55 mode tap
    ip addr add 192.168.0.22/24 dev tap55
    ip link set tap55 up

    # Add as rotas necessárias
    ip route add 192.168.10.0/24 via 192.168.0.1

    ssh -i <Chave privada> -o Tunnel=ethernet \
        user@server -Nn -w 55:55 &

    echo $! > /var/run/ssh_tunnel.pid
}

stop() {
    # Verificar se o PID do SSH existe e matar o processo
    if [ -f /var/run/ssh_tunnel.pid ]; then
        PID=$(cat /var/run/ssh_tunnel.pid)
        kill $PID
        rm /var/run/ssh_tunnel.pid
    fi

    # Remover a interface TAP e as rotas
    ip link set tap55 down
    ip tuntap del dev tap55 mode tap

    # Remover as rotas adicionadas
}

Configuração de Interface e Firewall#

Para configurar o roteamento, você precisará criar uma nova interface via GUI. Essa interface deve ter um IP estático, mapeando o IP local do tap55 (com o mesmo endereço). O gateway para essa configuração será o servidor 192.168.0.1.

Após a criação da interface, será necessário criar uma nova zona no firewall, associando-a a essa interface.

Configurações de Firewall#

Siga os passos abaixo para ajustar as regras do firewall:

  • Crie uma zona “SSH”: Crie uma nova zona de firewall chamada “SSH”. Ela deve ser similar à regra padrão da LAN. É incerto se essa configuração específica terá alguma influência, mas é um passo inicial.

  • Ajuste a zona LAN: Na configuração da zona “LAN”, adicione as permissões de encaminhamento:

    • Allow forward to destination zones: Defina como WAN.
    • Allow forward from source zones: Adicione a zona “SSH” aqui, pois ela provavelmente estará vazia.

  • Regras de firewall (UFW no servidor):

# Permitir tráfego de vpn_bridge0 para eth0:
ufw allow in on vpn_bridge0 to any
ufw allow out on eth0 from 192.168.0.0/24
ufw allow in on eth0 to 192.168.0.0/24

# Permitir tráfego entre vpn_bridge0 e br_lan0:
ufw allow in on vpn_bridge0 to 192.168.10.0/24
ufw allow out on vpn_bridge0 from 192.168.10.0/24
ufw allow in on br_lan0 to 192.168.0.0/24
ufw allow out on br_lan0 from 192.168.0.0/24

ATENÇÃO: NÃO UTILIZE AS OPÇÕES DE DHCP ABAIXO#

As informações a seguir não devem ser utilizadas. Estão aqui apenas para referência, mas não são o método recomendado para a configuração atual:

Existe a possibilidade de configurar roteamento estático no servidor DHCP, especificamente no OpenWRT, através do caminho Network (Rede) > Interfaces > servidor DHCP > Avançado > DHCP-Options. As opções que não devem ser adicionadas são:

  • 121,192.168.10.0/24,192.168.0.1
  • 121,192.168.10.0/24,192.168.0.1
  • 121,192.168.0.0/24,192.168.0.1

Para mais informações sobre a lista de opções DHCP (121), você pode consultar a documentação: https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Setting_Custom_DHCP_Options

Edit Edit this page
Backward mouse Rsyslog - Servidor de Logs Remotos Forward