Pacote de resposta na mesma interface que chega na LAN

Question

Atualmente, estou lutando com o seguinte cenário:

• Eu tenho um servidor com 2 interfaces em 2 sub-redes LAN separadas. SE1, SE2
• Eu tenho um laptop que possui um endereço IP da primeira sub-rede
• Quando tento conectar-me deste laptop específico ao segundo endereço IP do servidor, não recebo nenhuma resposta.

Por exemplo, quando tento executar ping em 172.31.196.185 do laptop com IP 172.31.190.129, posso ver solicitações recebidas no tcpdump na interface ens224, mas não há solicitação de resposta em nenhuma outra interface depois disso.

Aqui está meu diagrama de rede:

       +-------------------------+
       |                         |
       |  Laptop 172.31.190.129  +---------+
       |                         |         |
       +-------------------------+         |
                                           |                 +-------------------------+
                                           |                 |                         |
                               +-----------+---------+       |       Linux Server      |
                          +----+                     |       |                         |
                          |    | LAN 172.31.190.0/23 +-------+ IF1  -  default gw      |
                   +------+--+ |                     |       | 172.31.190.63           |
    +----------+   |         | +---------------------+       |                         |
    | Internet +---+ Gateway |                               |                         |
    +----------+   |         | +---------------------+       |                         |
                   +------+--+ |                     |       |                         |
                          |    | LAN 172.31.196.0/23 +-------+ IF2                     |
                          +----+                     |       | 172.31.196.185          |
                               +---------------------+       |                         |
                                                             |                         |
                                                             |                         |
                                                             +-------------------------+

Além disso, tenho este script:

IF1=ens160
IF2=ens224

P1_NET=172.31.190.0/23
P2_NET=172.31.196.0/23

IP1=172.31.190.63
IP2=172.31.196.185

P1=172.31.190.1
P2=172.31.196.1

ip route add $P1_NET dev $IF1 src $IP1 table T1
ip route add default via $P1 table T1
ip route add $P2_NET dev $IF2 src $IP2 table T2
ip route add default via $P2 table T2

ip route add $P1_NET dev $IF1 src $IP1
ip route add $P2_NET dev $IF2 src $IP2

ip rule add from $P1_NET dev $IF1 table T1
ip rule add from $P2_NET dev $IF2 table T2

Que está escrito de acordo com este link:https://lartc.org/howto/lartc.rpdb.multiple-links.html

Eu tentei muitas maneiras diferentes de fazer um roteamento baseado em políticas no meu caso, mas ninguém conseguiu...

Answer 1

DR

Não há necessidade detabelas de ip, marcas, nem para relaxarEncaminhamento/filtro de caminho reverso. Em vez dos ip rules que você usou, que não correspondem aos pacotes de saída, use os comandos descritos noDocumentação do LARTClink que você forneceu:

ip rule add from $IP1 table T1
ip rule add from $IP2 table T2

então tudo funcionará bem.

---

Versão longa

Mesmo que seja sempre possível permitir que as coisas funcionem relaxandoEncaminhamento/filtro de caminho reversousando por exemplosysctl -w net.ipv4.conf.all.rp_filter=2etc., permitindo assim o roteamento assimétrico, o roteamento assimétrico deve sempre ser evitado. Especialmente considerando que oPorta de entrada(se estiver agindo como um firewall com estado estrito) ou oComputador portátiltambém pode não permitir isso por razões semelhantes. Usandotabelas de ipe marcas para corrigir um comportamento errado certamente não ajudarão a entender como se comportará a já complexa configuração de roteamento.

Embora a documentação vinculada use o IP do servidor como fonte (para $IF2/ens224: 172.31.196.185)sem interfacepara a regra ip, você está especificando a interface de entrada na regra ( devsignifica iifaqui). Essa é a questão: isto não tem o efeito que se espera que aconteça. Veja a descrição iifemip rule:

seNOME

selecione o dispositivo de entrada correspondente.Se a interface for loopback, a regra corresponderá apenas aos pacotes originados deste host. Isso significa que você pode criar tabelas de roteamento separadas para pacotes encaminhados e locais e, portanto, segregá-los completamente.

Embora não esteja escrito claramente, o inverso é verdadeiro: pacotesorigináriodeste host corresponderá apenas à interface de loopback: eles não corresponderão iif ens160a nem iif ens224, mas apenas iif lo(sim iifsignificaentradainterface e iif locorrespondências geradas localmenteextrovertidopacotes, considere isso como "entrada do sistema local [para onde quer que as regras de roteamento indiquem]"). Isso importa.

O que acontece depois:

1. Computador portátiltenta alcançar $IP2 (ele não sabe nem deveria saber que $IP2 poderia ser alcançado através de $IF1 e $IP1 do servidor na mesma LAN), envia pacotes atravésPorta de entrada,

2. Porta de entradaroteia o pacote para o $IP2 do servidor pertencente a $P2_NET, para sua interface $IF2,

3. Servidorrecebe um pacote pertencente a $P1_NET (de 172.31.190.129) na interface $IF2,

4. ServidorCaminho reverso estritorp_filter=1verifica a rota reversa,

5. Como visto acima, rota inversanão correspondequalquer iifdiferente de iif lo: as duas novas regras não correspondem, então a única regra correspondente restante é a regra para a tabela de roteamento principal: por meio de $IF1, conforme verificado em:

    # ip route get 172.31.190.129 from 172.31.196.185
    172.31.190.129 from 172.31.196.185 dev ens160 uid 0 
        cache 
   

6. O caminho reverso não está usando a interface de onde o pacote chegou: o pacote foi descartado.

Pelas mesmas razões, esta configuração actual não permitirá um acesso correcto à Internet a partir deServidorao usar $IP2: novamente não irá corresponder às novas regras e tente usar $IF1 para isso:

# ip route get 8.8.8.8 from 172.31.196.185
8.8.8.8 from 172.31.196.185 via 172.31.190.1 dev ens160 uid 0 
    cache 

Assim, uma vez que as duas regras sejam removidas e alteradas, conforme documentado no LARTC, para:

ip rule add from $IP1 table T1
ip rule add from $IP2 table T2

Aquilo é:

# ip rule add from 172.31.190.63 table T1
# ip rule add from 172.31.196.185 table T2

As coisas funcionarão corretamente, como uma pesquisa de rota dirá (agora usando table T2):

# ip route get 172.31.190.129 from 172.31.196.185
172.31.190.129 from 172.31.196.185 via 172.31.196.1 dev ens224 table T2 uid 0 
    cache 

# ip route get 8.8.8.8 from 172.31.196.185
8.8.8.8 from 172.31.196.185 via 172.31.196.1 dev ens224 table T2 uid 0 
    cache 

Essas 3 variantes também poderiam ter funcionado (apenas colocando a regra na tabela T2 por questões de brevidade):

ip rule add from 172.31.196.0/23 table T2
ip rule add from 172.31.196.185 iif lo table T2
ip rule add from 172.31.196.0/23 iif lo table T2

Observe que, conforme documentado na página de manual, iif loalterará o comportamento seServidortambém está roteando outros sistemas por trás dele (novamente, as regras não serão compatíveis com esses sistemas): é melhor não usá-lo, a menos que seja necessário.

Não há necessidade detabelas de ipe marcas para isso. Usar marcas para alterar a interface pode causar problemas adicionais com roteamento, solicitações ARP e filtragem de caminho reverso (usar marcas geralmente requer relaxamentofiltro_rp), então é melhor não usá-los se isso puder ser evitado.