Roteamento de origem Linux, modelo de sistema de extremidade strong / modelo de host strong?

5

Uma máquina Linux multihomed pode implementar um verdadeiro Modelo ES strong ?

Caso de uso específico

Eu tenho um sistema com cinco interfaces diferentes, cada uma conectada à mesma sub-rede, portanto, o mesmo gateway para a Internet.

  • Eu gostaria de ouvir em cada interface separadamente na mesma porta e garantir que os pacotes sempre saiam da mesma interface em que vieram, e garantir que os pacotes que tentam entrar na interface "errada" sejam descartados.
  • Eu gostaria de poder vincular a cada interface e fazer conexões de saída para destinos da Internet que sempre se originam do mesmo IP de origem ao qual estou vinculado. Por exemplo,
    curl --interface interface_ip http://ipecho.net/plain
    deve sempre mostrar o mesmo endereço IP que eu limitei com --interface .
  • Rotas estáticas podem ser problemáticas devido ao uso do DHCP em uma dessas interfaces.

RFC 1122

De RFC 1122 - Requisitos para hosts da Internet - Camadas de comunicação, Section 3.3.4.2 - Requisitos multihoming :

Internet host implementors have used two different conceptual models for multihoming, briefly summarized in the following discussion.  This document takes no stand on which model is preferred; each seems to have a place.  This ambivalence is reflected in the issues (A) and (B) being optional.

  •   Strong ES Model

      The Strong ES (End System, i.e., host) model emphasizes the host/gateway (ES/IS) distinction, and would therefore substitute MUST for MAY in issues (A) and (B) above.  It tends to model a multihomed host as a set of logical hosts within the same physical host.

      With respect to (A), proponents of the Strong ES model note that automatic Internet routing mechanisms could not route a datagram to a physical interface that did not correspond to the destination address.

      Under the Strong ES model, the route computation for an outgoing datagram is the mapping:
         route(src IP addr, dest IP addr, TOS) -> gateway
    

    Here the source address is included as a parameter in order to select a gateway that is directly reachable on the corresponding physical interface.  Note that this model logically requires that in general there be at least one default gateway, and preferably multiple defaults, for each IP source address.


  •   Weak ES Model

      This view de-emphasizes the ES/IS distinction, and would therefore substitute MUST NOT for MAY in issues (A) and (B).  This model may be the more natural one for hosts that wiretap gateway routing protocols, and is necessary for hosts that have embedded gateway functionality.

      The Weak ES Model may cause the Redirect mechanism to fail.  If a datagram is sent out a physical interface that does not correspond to the destination address, the first-hop gateway will not realize when it needs to send a Redirect.  On the other hand, if the host has embedded gateway functionality, then it has routing information without listening to Redirects.

      In the Weak ES model, the route computation for an outgoing datagram is the mapping:
         route(dest IP addr, TOS) -> gateway, interface
    

  • O Linux é um modelo Weak ES por padrão, enquanto o FreeBSD e outras variedades Unix atuam como sistemas Strong ES. Existe alguma maneira de fazê-lo se comportar mais como um sistema ES strong?

    Qual sysctl ou configuração de tempo de compilação precisaria ser configurada para se comportar como um Strong ES por padrão, sem adicionar regras de roteamento específicas para nenhuma nova interface adicionada? Eu sei que podemos fazer uma filtragem de rota de origem estrita via net.ipv4.conf.default.rp_filter = 1 , mas parece haver muito mais do que isso. Como posso fazer roteamento baseado em origem por padrão?

        
    por Will 31.01.2016 / 03:13

    2 respostas

    4

    Apenas adicionar regras de firewall não será suficiente para este. Você quer que o sistema roteie o tráfego como se fossem dois sistemas independentes que compartilham o mesmo hardware e processos: é isso que o modelo Strong ES é efetivamente.

    Ao apontar para o Strong ES Model no Linux, primeiro você precisará destas configurações de sysctl:

    net.ipv4.conf.all.arp_filter=1 
    net.ipv4.conf.all.arp_ignore=1 # or even 2
    net.ipv4.conf.all.arp_announce=2
    

    Essas configurações farão o ARP se comportar apropriadamente com o Modelo Strong ES, ou seja, quando uma solicitação ARP for recebida, somente a interface com o endereço solicitado responderá e somente se o tráfego para o endereço de origem for enviado através dessa interface específica.

    Depois, como você tem cinco interfaces que deseja comportar de maneira diferente em termos de roteamento, é necessário configurar cinco tabelas de roteamento personalizadas. Você poderia usar números para identificá-los, mas geralmente é mais claro especificar nomes para eles. Portanto, escolha números para cada um deles entre 1 e 252 e alguns nomes adequados. (Números 0, 253, 254 e 255 são reservados.)

    Por exemplo, vamos escolher 100 = rtable0, 101 = rtable1, 102 = rtable2, 103 = rtable3 e 104 = rtable4. Adicione esses números e nomes ao final de /etc/iproute2/rt_tables file:

    # ...default stuff above...
    100    rtable0
    101    rtable1
    102    rtable2
    103    rtable3
    104    rtable4
    

    Em seguida, preencha cada tabela de roteamento personalizada com um conjunto mínimo de entradas de rota apropriadas para cada interface. (Estou substituindo valores reais por nomes de variáveis de ambiente nomeados descritivamente).

    ip route add $ETH0_NET dev eth0 proto static src $ETH0_IP table rtable0
    ip route add default via $ETH0_GW dev eth0 proto static src $ETH0_IP table rtable0
    
    ip route add $ETH1_NET dev eth1 proto static src $ETH1_IP table rtable1
    ip route add default via $ETH1_GW dev eth1 proto static src $ETH1_IP table rtable1
    
    # ... and so on, for all 5 interfaces
    

    Por fim, adicione regras de roteamento avançadas que verificarão o endereço de origem de cada pacote e escolherão a tabela de roteamento a ser usada de acordo:

    ip rule add from $ETH0_IP table rtable0
    ip rule add from $ETH1_IP table rtable1
    #...
    

    Para tornar toda essa configuração persistente durante as reinicializações, talvez seja necessário escrever scripts de inicialização personalizados (ou possivelmente ifup-pre ou ifup-post scripts) para atender às convenções da distribuição do Linux.

    Para um seguro extra, você pode adicionar regras iptables por interface para descartar silenciosamente qualquer pacote de entrada que possa ser recebido na interface errada. Se tudo estiver bem, a contagem de pacotes para estes deve permanecer zerada: se eles começarem a aumentar, você pode ter perdido alguma coisa na configuração.

    iptables -A INPUT -m addrtype --dst-type UNICAST -i eth0 ! -d $ETH0_IP -j DROP
    iptables -A INPUT -m addrtype --dst-type UNICAST -i eth1 ! -d $ETH1_IP -j DROP
    # ... and so on for each interface
    

    Nota: uma vez eu implementei uma configuração como essa baseada em uma antiga discussão na internet feita por Rick Jones e outros gurus da rede. Eles disseram, parafraseando, "enquanto tudo isso é claramente necessário para alcançar o comportamento do Strong Host Model no Linux, eu não posso garantir que ele seja suficiente para todos os possíveis casos de uso". Funcionou sem falhas para mim; pode ou não ser o suficiente para você, dependendo de exatamente para o que você vai usá-lo.

    Aviso: assegure-se de que você tenha algum tipo de acesso local ou remoto ao console ao configurar essa configuração. É muito provável que essa configuração atrapalhe completamente o acesso à rede enquanto ela está apenas pela metade.

    Embora seja possível configurar N interfaces apenas com tabelas de roteamento personalizadas (N-1), minha preferência pessoal é mover toda a configuração de roteamento para tabelas personalizadas ao usar o roteamento avançado. Ter route -n ou ip route show praticamente vazio enquanto o sistema está claramente tendo conexões de rede será uma grande pista de que algo muito especial está acontecendo. No entanto, quando eu configurei um sistema como esse, também configurei um aviso permanente em /etc/motd sobre o roteamento avançado em vigor e os locais dos scripts reais que o configuravam.

        
    por 17.12.2017 / 01:44
    2

    Existe outra opção que permite mais controle sobre o manuseio do ARP. Dê uma olhada em arp_ignore .

        
    por 31.01.2016 / 05:04