Como acessar as duas sub-redes (dual NIC) no servidor Ubuntu a partir da terceira sub-rede?

0

Esta é a minha rede doméstica na qual estou aprendendo.

Por favor, veja os detalhes relevantes da VLAN e as regras de firewall de zona relevantes na parte inferior da postagem como sendo longas

Designei com êxito 2 NICs (Gerenciamento / DMZ) para cada um dos 6 servidores windows com sucesso e uso meu laptop Windows na LAN para acessar as coisas por trás do gerenciamento de acesso RDP / Web para switch / roteador etc. da minha máquina Windows LAN ao seu DMZ e Management IP's e obter um retorno.

Então eu adicionei um servidor Ubuntu 16 LTS alguns dias atrás com a mesma configuração, mas não consigo pingar ambos os IPs do laptop Windows.

Aqui está o meu arquivo / 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
auto eth0
iface eth0 inet static
        address 192.168.67.100
        netmask 255.255.255.0
#       network 192.168.67.0
#       broadcast 192.168.67.255
        gateway 192.168.67.253
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 192.168.67.253
        dns-search on.fake.network

# Management network interface
auto eth1
iface eth1 inet static
        address 192.168.7.100
        netmask 255.255.255.0
#       network 192.168.7.0
        broadcast 192.168.7.255

#persistent static routes
up route add -net 192.168.1.0/24 gw 192.168.7.253 dev eth1

Minha tabela de rotas IP

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.67.253  0.0.0.0         UG    0      0        0 eth0
192.168.1.0     192.168.7.253   255.255.255.0   UG    0      0        0 eth1
192.168.7.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
192.168.67.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0

Portanto, com esta configuração eu posso pingar 192.168.7.100 mas não 192.168.67.100 Eu tiro a rota estática persistente e seu oposto: /

Como posso ganhar, isso é bastante fácil no Windows, mas meu ficou perdido no Ubuntu

* DETALHES ADICIONAIS *

O roteador Ubiqiti ERL3 cria VLANs

VLAN 7 - Management (192.168.7.0) - Router interface (GW) IP is 192.168.7.253
VLAN 13 - LAN (192.168.1.0) - Router interface (GW) IP is 192.168.1.253
VLAN 67 - DMZ (192.168.67.0) - Router interface (GW) IP is 192.168.67.253

Laptop Windows na conexão LAN

VLAN 13 - LAN (192.168.1.15)

O servidor Ubuntu (por meio do host do Hyper-V) tem 2 NICs

eth0 - VLAN 67 - DMZ (192.168.67.100)
eth1 - VLAN 7 - Management (192.168.7.100)

O ping é iniciado a partir da LAN 192.168.1.15 para ambos DMZ / MGMT 192.168.67.100/192.168.7.100

Aqui estão as minhas regras de firewall condensadas que são relevantes para este cenário, extras removidos como o acesso SSH / HTTP, etc, etc.

A observação de "address-group mgmtfromlan" contém vários IP's da LAN, incluindo 192.168.1.15 (O laptop na LAN VLAN)

name lan-dmz {
    default-action drop
    enable-default-log
    rule 1 {
        action accept
        state {
            established enable
            related enable
        }
    }
    rule 2 {
        action drop
        log enable
        state {
            invalid enable
        }
    }
    rule 100 {
        action accept
        description "Allow ICMP"
        log enable
        protocol icmp
    }
}
name lan-mgmt {
    default-action drop
    enable-default-log
    rule 1 {
        action accept
        state {
            established enable
            related enable
        }
    }
    rule 2 {
        action drop
        log enable
        state {
            invalid enable
        }
    }
    rule 100 {
        action accept
        description "Allow ICMP"
        log enable
        protocol icmp
        source {
            group {
                address-group mgmtfromlan
            }
        }
    }
}
name dmz-lan {
    default-action drop
    enable-default-log
    rule 1 {
        action accept
        state {
            established enable
            related enable
        }
    }
    rule 2 {
        action drop
        log enable
        state {
            invalid enable
        }
    }
}
name mgmt-lan {
    default-action drop
    enable-default-log
    rule 1 {
        action accept
        state {
            established enable
            related enable
        }
    }
    rule 2 {
        action drop
        log enable
        state {
            invalid enable
        }
    }
    rule 100 {
        action accept
        description "Allow ICMP"
        log enable
        protocol icmp
    }
}

* TABELA DE ROTEAMENTO DO WINDOWS LAPTOP 192.168.1.15 *

===========================================================================
Interface List
 15...b8 ca 3a d4 bb bc ......Intel(R) 82579LM Gigabit Network Connection #2
  5...3c a9 f4 03 73 ed ......Microsoft Wi-Fi Direct Virtual Adapter #2
 19...00 ff d4 0e 47 e9 ......TAP-Windows Adapter V9
  7...3c a9 f4 03 73 ec ......Intel(R) Centrino(R) Ultimate-N 6300 AGN #2
  1...........................Software Loopback Interface 1
 12...00 00 00 00 00 00 00 e0 Microsoft Teredo Tunneling Adapter
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0    192.168.1.253     192.168.1.15    291
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
      192.168.1.0    255.255.255.0         On-link      192.168.1.15    291
     192.168.1.15  255.255.255.255         On-link      192.168.1.15    291
    192.168.1.255  255.255.255.255         On-link      192.168.1.15    291
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link      192.168.1.15    291
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link      192.168.1.15    291
===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
          0.0.0.0          0.0.0.0    192.168.1.253  Default
          0.0.0.0          0.0.0.0    192.168.1.253  Default
===========================================================================

IPv6 Route Table
===========================================================================
Active Routes:
 If Metric Network Destination      Gateway
  1    331 ::1/128                  On-link
  1    331 ff00::/8                 On-link
===========================================================================
Persistent Routes:
  None

Obrigado antecipadamente

    
por Guy Incognito 21.10.2017 / 13:08

2 respostas

0

Com o conjunto de rotas padrão, a VM ubuntu recebe um pacote em eth1 (de 192.168.1.15: ping 192.168.7.100). Será:

  • descarta o pacote por causa da filtragem de caminho reverso: pacote recebido em uma interface onde não há rota para a origem deste pacote.
  • responda pela eth0 porque 192.168.1.15 corresponde à rota padrão via 192.168.1.253 em eth0

O comportamento depende dos valores de /proc/sys/net/ipv4/conf/{all,eth1}/rp_filter , mas a queda é o padrão: todos / rp_filter = 1 e eth1 / rp_filter = 1

No caso em que não é descartado: o roteador ERL3 vê um pacote de resposta de 192.168.1.7.100 que deve estar em lan-mgmt, mas transita de lan-dmz. Dependendo das configurações, talvez descritas na configuração do seu roteador, você escreveu, mas eu não sei:

  • irá diminuir, mais ou menos pela mesma razão que o ubuntu o soltar quando o rp_filter estiver ativado: a rota para ele é em outro lugar
  • aceitará mesmo assim.

Vamos considerar que o ERL3 o aceita. Então a "correção" é simples: menor segurança no Ubuntu, desabilitando a filtragem de caminho reverso:

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter

ref: link (rp_filter)

(a maneira como está funcionando, a eth0 permanece protegida, mas isso é irrelevante aqui)

Tente primeiro, se funcionar, problema resolvido. Considere substituir os dois echo 0 por echo 2 apenas pela eth1 (modo solto). Mas considere que isso ainda é um problema: o roteamento assimétrico pode criar outros problemas, especialmente com o firewall.

Se o roteador ERL3 estiver filtrando também (isto é: acima não funcionou): o ubuntu deve estar ciente da existência do 192.168.1.0/24 para ambas as interfaces e usar as configurações table e rule para uma correta roteamento. Isso é um pouco difícil de explicar por que, além de como, aqui está uma referência, que não é exatamente para este caso, mas pode ser baseada principalmente em (o que eu fiz aqui):

ref: link

Eu escolhi as tabelas arbitrárias 7 e 67 para corresponder a 192.168.7.0/24 e 192.168.67.0/24. Comece pelas rotas vazias (ao lado das rotas lan locais criadas automaticamente) e:

ip route add 192.168.67.0/24 dev eth0 src 192.168.67.100 table 67
ip route add default via 192.168.67.253 table 67
ip route add 192.168.7.0/24 dev eth1 src 192.168.7.100 table 7
ip route add 192.168.1.0/24 via 192.168.7.253 table 7 #enable only LAN to have a route to access MGMT. Feel free to replace 192.168.1.0/24 with default, you have a firewall too.

Eu não sei se isso é realmente necessário, mas isso está na documentação, então ...:

ip route add 192.168.7.0/24 dev eth1 src 192.168.7.100
ip route add 192.168.67.0/24 dev eth0 src 192.168.67.100

Sua rota padrão permanece a mesma, aqui novamente na sintaxe de ip route :

ip route add default via 192.168.67.253

E a parte realmente importante que conta para usar a interface certa:

ip rule add from 192.168.67.100 table 67
ip rule add from 192.168.7.100 table 7

Nota final: certifique-se de que o ubuntu não faz o roteamento, senão um host DMZ comprometido pode tentar gerenciar um outro através do Ubuntu:

echo 0 > /proc/sys/net/ipv4/conf/default/forwarding
echo 0 > /proc/sys/net/ipv4/conf/all/forwarding
    
por 21.10.2017 / 15:44
0

Sua rota estática substitui o gateway padrão.

Quando a rota existe, todo o tráfego para 192.168.1.x sai pela eth1 usando 192.168.7.253 como o gateway.

Quando a rota não existe, todo o tráfego para 192.168.1.x sai pela eth0 usando 192.168.67.253 como o gateway.

O caminho do seu computador para o servidor está correto, mas o caminho de retorno leva uma rota diferente de volta, dependendo de qual interface você fez o ping. Isso é chamado de roteamento assimétrico e normalmente não é permitido por dispositivos de segurança. Provavelmente está bloqueado no seu firewall. Em essência, o tráfego de retorno proveniente de uma rota diferente é "não relacionado" e o tráfego não reconhecido, por isso é descartado.

Acho que a maneira mais fácil de resolver esse problema é garantir que o tráfego tome a rota correta de volta, dependendo de qual interface recebeu os dados. Isso pode ser feito configurando um gateway padrão em ambas as interfaces.

Infelizmente, isso não é tão fácil quanto parece. Você precisará criar tabelas de roteamento e regras de roteamento alternativas.

Veja se esses comentários vão ajudar: link

link

    
por 21.10.2017 / 15:56