Sistema OpenBSD multi-homed: Roteamento baseado em política versus rotas padrão do mpath

Question

TL; DR O roteamento baseado em política do OpenBSD ajuda com uma situação de servidor / gateway multi-homed? Se sim, como faço para configurá-lo?

Formulário longo

Estou gerenciando um OpenBSD com dois links ISP e túneis VPN para nós de roteamento remotos.

Inicialmente, usamos várias rotas padrão com métricas variáveis - a rota preferencial por meio de um endereço IP estático, um roteador NAT que, por sua vez, tem endereços alocados dinamicamente (é basicamente um modem a cabo).

Na prática, isso não era ideal, mas funciona bem o suficiente. Novas conexões estabelecidas a partir do gateway (doravante denominadas simplesmente "gw") selecionariam a rota de maior velocidade e menor latência se estivesse ativa; e sair pelo modem a cabo se o link estiver desativado. A conexão de entrada só poderia vir através da rota melhor, já que os outros endereços IP estavam atrás do NAT (não roteável do lado de fora.

Agora, precisamos direcionar o tráfego por meio de nós de roteador proxy / VPN adicionais para fora "na nuvem" para reduzir os riscos de DDoS em nossos endereços IP estáticos.

Eles estão se conectando ao gateway por meio de túneis.

primeiro. Em seguida, descobrimos que nosso acesso de administrador caía esporadicamente.

Para complicar ainda mais, este gateway possui interfaces ativas adicionais para VLANs específicas. Eles não estão relacionados a este problema, mas não podem ser perturbados.

Solução possível

Tenho a impressão de que devemos usar o roteamento com base em políticas, rdomains . Eu acho que isso significa que eu crio tabelas de roteamento para cada uma das minhas três interfaces envolvidas e qualquer conexão em qualquer uma delas (incluindo a interface de túnel tun0 ) deve ser roteada através da tabela para esse domínio tem sua própria rota padrão).

Estou no caminho certo?

Aqui está um diagrama e uma lista higienizada se as configurações da interface:

 ________
| tunnel |                       _______
 ~~~+~~~~                       | GW    |======++
    |                            ~+~+~+~       ||                   
    |      _________              | | |        ||                                        
    +-----| prefISP |-------------+ | |      __||____       .........               
           ~~~~~~~w~                | +-----| Switch |-----( Cluster )                           
                                    |        ~~~~~~~~       ^^^^^^^^^           
           _________           .....|......    ||                              
          | fallISP |---------( LAN / WiFi )===++
           ~~~~~~~~~           ^^^^^^^^^^^^

    Diagram: I want to avoid asymmetric routing when accessing GW through the tunnel, through                                           the preferred ISP, and when accessing GW or the cluster (through the GW or from the LAN).


 Sanitized interface info:

    em3:  inet 123.45.67.118 netmask 0xfffffff8 broadcast 123.45.67.119        description: prefISP
    em0:  inet 10.1.1.100    netmask 0xffffff00 broadcast 10.1.1.255           description: fallISP
    tun0: inet 192.168.2.2 --> 192.168.2.1 netmask 0xffffff00                  description: tunnel
    em1:  VLAN_TRUNK
          vlan1000: inet 172.29.1.1 netmask 0xffffff00 broadcast

Como observado: em3 é o nosso link para o ISP preferido (mais rápido); tun0 passa por isso; em0 está no mesmo segmento que a LAN / Wifi do escritório e serve como nosso ISP de fallback; e o GW tem links adicionais para o cluster e o switch.

    

Answer 1

Bem-vindo ao sonho do balanceamento de carga.

Isso é possível, mas o melhor modo de rota e ausência de dor é usar o protocolo de roteamento BGP e gerenciar o tráfego Downstream e Upstream usando políticas.

Para que isso seja bem-sucedido, você precisa negociar com os dois ISPs que eles incluam você como um nó iBGP interno, para que você possa enviar seus caminhos de rotas para a Internet.

A maneira correta seria solicitar seu próprio Número de Sistema Autônomo. e gerenciar todos os seus IPs que você possui. isso é um pouco complicado de realizar devido aos requisitos.

link

If you are qualifying under the multihomed policy you will need to provide the exterior gateway protocol to be used, the IP addresses currently in use on your network, the AS number and name of each of your upstream providers and/or peers along with contractual verification of service with at least two of them.

If you are qualifying under the unique routing policy, you must demonstrate the AS’s routing policy will differ from the routing policies of its border peers.

No matter which policy you qualify under, if this is not your first time requesting an ASN, you will also need to show us how the network you are requesting an ASN for is autonomous from all existing ASes in your network as well.

Aqui está um belo artigo sobre Multihoming usando o BGP: link

Se você não estiver disposto, incapaz de criar sessões BGP com seus ISPs, a outra solução é usar um balanceador de carga baseado em hardware. (tecnicamente falando, a maioria dos hardwares executam algum BSD modificado para alcançar os recursos dos produtos. portanto, se você tiver o conhecimento, pode configurá-lo em um servidor executando BSD. mas nunca obterá o trogogo de um hardware com hardware dedicado para processamento de rede , mas se sua carga não for grande (mais de 50 Mbps eu diria) você pode fazer isso)