Prática recomendada para site de hospedagem dupla com dois ISPs?

Estou inscrito em dois ISPs, um rápido e caro e um barato, mas mais lento. Eles usam tecnologias diferentes, cabo e ADSL, para que não haja um único ponto de falha e todos os meus equipamentos de comunicação são alimentados por um no-break.

Os ISPs no Reino Unido caem de maneira bastante aleatória. Por muitos anos, ainda não encontrei um momento em que os meus dois ISPs tenham caído simultaneamente; portanto, claramente a estratégia de dois ISPs é útil se você desejar acesso ininterrupto à rede aqui.

O problema, porém, é como organizar a rede do site para aproveitar essa disponibilidade aprimorada. Muitos ISPs não permitem que você execute seu próprio AS e protocolos de roteamento; portanto, você está mais preocupado em dividir seu roteamento estático nos dois tubos de saída por destino. Isso é menos que brilhante e requer intervenção manual quando um provedor de serviços de Internet cai da face do planeta. Com a ajuda de vários scripts, lida com interrupções no ISP com sucesso razoável e sem muito esforço, e isso se torna comum como sempre. Não é ótimo. Parece que falta alguma tecnologia.

1. Existe uma maneira melhor, geralmente?
2. Existe uma maneira melhor apenas para IPv6 (eu tenho pilha dupla em um ISP e poderia encapsular no outro)? Isso seria um benefício claro para o IPv6.

Que tipo de equipamento você tem para se conectar aos fornecedores? Se for um dispositivo Cisco, você poderá usar o IP SLA para executar ping em um destino como 8.8.8.8 no ISP principal. Assim que você não receber um failover de resposta para a outra rota estática. Exemplo de configuração:

! ISP1
ip route 0.0.0.0 0.0.0.0 x.x.x.x track 1
! ISP2
ip route 0.0.0.0 0.0.0.0 y.y.y.y 250
ip sla 1
icmp-echo 8.8.8.8 source-interface <ISP1_interface>
frequency 3
timeout 1000
ip sla schedule 1 life forever start-time now

Pode ser necessário colocar uma rota estática para 8.8.8.8 no ISP1 para que ele sempre saia desse caminho. Obviamente, se você realmente usa o 8.8.8.8, escolha outro IP, pois, caso contrário, não terá acessibilidade se o ISP1 cair.

!x.x.x.x is next-hop to ISP1
ip route 8.8.8.8 255.255.255.255 x.x.x.x

Você pode querer investigar se há um provedor LISP disponível. O LISP é um protocolo que pode tornar um site independente dos ISPs upstream aos quais ele se conecta. Você obtém um ou mais endereços IP do ISP LISP e eles os direcionam para onde quer que você esteja conectado. É uma técnica de tunelamento, mas com muitos recursos interessantes. Você pode controlar o balanceamento de carga de entrada e saída através dos links; pode fazer o multihoming IPv6 sem precisar recorrer a hacks como o NPT66 (tradução de prefixo). Você pode até se mudar para o outro lado do planeta sem alterar os endereços IP ;-)

Eu mesmo uso o LISP e a rede do meu escritório possui um bloco de / 26 IPv4 e um / 48 de endereços IPv6 independentes dos upstreams (uma conexão de cabo UPC com um endereço IPv4 dinâmico e uma conexão DSL Solcon com um endereço IPv4 estático e um bloco estático de endereços IPv6). Um Cisco 1841 executa o LISP no escritório e usa o link disponível para conectar-se ao restante da Internet. Desde que um link funcione, meu escritório estará conectado usando seus próprios endereços.

Divulgação completa : Eu administro meu próprio ISP baseado em LISP na Holanda, por isso sou tendencioso. O LISP ainda é um protocolo interessante :-)

Na hospedagem múltipla IPv6 com endereços agregados ao provedor, cada host na rede receberá um prefixo de endereço de cada um dos provedores. A seleção do endereço de origem da pilha / aplicativo do host (RFC6724) e a escolha do par SA / DA (RFC6555) determina qual saída é usada.

Ou seja, a escolha do endereço de origem do host / aplicativo escolhe qual link de saída é usado. Várias implementações fazem isso de várias maneiras, e nenhuma faz muito bem no momento.

A rede usa o roteamento dependente do endereço de origem para encaminhar o tráfego para a saída correta. (Caso contrário, o BCP38 (filtragem de entrada) teria descartado um pacote enviado com o endereço de origem do ISP B para o ISP A). Veja http://tools.ietf.org/html/draft-troan-homenet-sadr-01 Temos uma implementação no OpenWRT. Mas também pode ser implementado razoavelmente bem em qualquer roteador que suporte roteamento baseado em políticas.

Um aplicativo deve ser inteligente o suficiente para alterar a conexão (escolha outro par SA / DA) quando a conexão atual falhar. Não é. Nesse meio tempo, nossa recomendação é definir o tempo de vida do prefixo do endereço do link com falha para 0, o que significa que novas conexões não usarão esse endereço.

Q1 Você pode instalar um roteador / firewall que suporte multihoming. Em termos de software livre, o pfSense se encaixa perfeitamente. http://www.pfsense.org/ . Os documentos do pfSense se referem a isso como Multi-WAN. http://doc.pfsense.org/index.php/Multi-WAN_2.0

Ajuda, pfSense possui failover automático e balanceamento de carga.

O que descobri é que um pequeno número de aplicativos da web não funciona quando você está com hospedagem múltipla. Os aplicativos da web geralmente são sites financeiros, como bancos. Por alguma razão, os programadores de aplicativos da Web às vezes pensam que não há problema em testar a segurança com base no endereço IP. Para usuários que precisam desse acesso, você pode reservar um endereço IP para o computador e criar uma "regra de LAN" no pfSense para sempre usar um determinado gateway e não o outro para esse endereço IP.

Acho que isso funciona muito bem para a combinação de modem a cabo e modem ADSL.

Q2 Não há razão para que o multihoming não funcione tanto no IPv6 quanto no IPv4. Dito isto, o pfSense não possui uma versão totalmente suportada que lide adequadamente com o IPv6. A versão atual do pfSense é 2.0x. Depois que o 2.1 for lançado, o pfSense terá um bom suporte para IPv6 e incluirá o multihoming.

Você pode configurar um servidor remoto / VPS em um data center confiável e, em seguida, configurar os túneis da VPN do seu roteador para o servidor remoto em cada ISP. Agora, seu roteador em casa pode rotear pacotes nesses túneis com base em uma proporção de largura de banda e, em seguida, o servidor remoto pode rotear o tráfego entre o restante da Internet.

A desvantagem é que você incorrerá em custos adicionais de CPU, armazenamento e largura de banda para o servidor remoto.

A vantagem é que você pode usar toda a largura de banda fornecida pelos dois provedores enquanto ainda possui uma opção de failover para confiabilidade.

Eu uso o OpenWRT com o Multiwan ( http://wiki.openwrt.org/doc/uci/multiwan ) há algum tempo em casa para fazer o multihome entre meu DSL e o ISP a cabo. Funcionou muito bem. Eu não recomendaria isso como uma solução corporativa, mas tudo bem para SOHO e configurações domésticas.