info_i_25x25.png See important information about Ubiquiti Devices and KRACK Vulnerability in this article. We will update this document as more information becomes available.

WAN-balanceamento de carga e túneis

Este artigo da Base de conhecimento abordaremos algumas das considerações especiais que são necessárias com combinação de WAN-balanceamento de carga e túneis.  Para simplificar este exemplo vai usar um tunnnel GRE (depuração mais fácil com a captura de pacotes em dados não-encyrpted), mas se a teoria deve funcionar para outros túneis.

Nossa topologia:

 

Roteador R1                                                                         Roteador R2

 

eth0 WAN1 20.0.0.2/30                                             eth0 WAN 30.0.0.2/30

eth1 LAN 192.168.1.1/24                                        eth1 LAN 172.16.1.1/24

tun0 WAN2

tun0 GRE 40.0.01/30                                               tun0 GRE 40.0.0.2/30

Nós vai começar com o túnel GRE, em seguida, adicione depois de balanceamento de carga.

Queremos nosso túnel GRE para ir de eth0 R1 R2 eth0.  Então para R1 acrescentamos:

 tunnel tun0 {
     address 40.0.0.1/30
     encapsulation gre
     local-ip 20.0.0.2
     remote-ip 30.0.0.2
 } 

R2:

 tunnel tun0 {
     address 40.0.0.2/30
     encapsulation gre
     local-ip 30.0.0.2
     remote-ip 20.0.0.2
 }

 

Então, precisamos abrir o firewall para o protocolo GRE para WAN_LOCAL:

 

ubnt@R1# show firewall name WAN_LOCAL rule 40
 action accept
 description "Allow GRE"
 protocol gre
 source {
     address 30.0.0.2
 }

 

Então provavelmente nós necessitaremos TCP mss-braçadeira:

 

ubnt@R1# show firewall options 
 mss-clamp {
     interface-type tun
     interface-type pppoe
     mss 1412
 }

 

Última, precisamos adicionar uma rota estática para informar ao sistema que rede de LAN do R2 deve ser enviada a interface tun0.

     interface-route 172.16.1.0/24 {
         next-hop-interface tun0 {
         }
     }

Neste momento o nosso túnel GRE deve funcionar, mas

ubnt@R1:~$ ping 172.16.1.1
PING 172.16.1.1 (172.16.1.1) 56(84) bytes of data.
64 bytes from 172.16.1.1: icmp_req=1 ttl=64 time=0.832 ms
64 bytes from 172.16.1.1: icmp_req=2 ttl=64 time=0.741 ms
64 bytes from 172.16.1.1: icmp_req=4 ttl=64 time=0.635 ms
64 bytes from 172.16.1.1: icmp_req=5 ttl=64 time=0.654 ms
64 bytes from 172.16.1.1: icmp_req=6 ttl=64 time=0.644 ms
64 bytes from 172.16.1.1: icmp_req=7 ttl=64 time=0.614 ms
^C
--- 172.16.1.1 ping statistics ---
8 packets transmitted, 6 received, 25% packet loss, time 7006ms
rtt min/avg/max/mdev = 0.614/0.686/0.832/0.082 ms 

Então isso funciona, mas 25% de perda de pacotes não é bom.  Uma teoria é que, como temos 2 conexão com a Internet, que alguns pacotes estão saindo a interface errada.  Para testar isso Nós derrubamos o 2º interface WAN.

ubnt@R1:~$ disconnect interface pppoe0 
Bringing interface pppoe0 down...
ubnt@R1:~$ 
ubnt@R1:~$ 
ubnt@R1:~$ ping 172.16.1.1
PING 172.16.1.1 (172.16.1.1) 56(84) bytes of data.
64 bytes from 172.16.1.1: icmp_req=1 ttl=64 time=0.789 ms
64 bytes from 172.16.1.1: icmp_req=2 ttl=64 time=0.606 ms
64 bytes from 172.16.1.1: icmp_req=3 ttl=64 time=0.585 ms
64 bytes from 172.16.1.1: icmp_req=4 ttl=64 time=0.667 ms
64 bytes from 172.16.1.1: icmp_req=5 ttl=64 time=0.650 ms
64 bytes from 172.16.1.1: icmp_req=6 ttl=64 time=0.707 ms
64 bytes from 172.16.1.1: icmp_req=7 ttl=64 time=0.752 ms
64 bytes from 172.16.1.1: icmp_req=8 ttl=64 time=0.613 ms
^C
--- 172.16.1.1 ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7007ms
rtt min/avg/max/mdev = 0.585/0.671/0.789/0.069 ms

Problema resolvido! Mas como nós usamos o 2º WAN. Uma maneira é adicionar uma rota estática para o ponto de extremidade distante GRE e forçá-lo a sair por eth0.

     route 30.0.0.2/32 {
         next-hop 20.0.0.1 {
         }
     }

Agora podemos trazer de volta a interface tun0 e ainda o túnel GRE funciona bem.

As completa configurações para o roteador R1 e R2 para esta parte do KB são:

R1 /config/config.boot GRE

/Config/config.boot R2 GRE

 

Balanceamento de carga

 

Agora adicionaremos WAN-balanceamento de carga de R1.  Comece com a seção de balanceamento de carga:

 

load-balance {
    group WLB {
        interface eth0 {
        }
        interface pppoe0 {
        }
    }
}

Isto é tudo o que precisamos mesmo, mas nós vamos mudar o destino de ping para um endereço para que o exame de saúde não precisa de DNS.

load-balance {
    group WLB {
        interface eth0 {
            route-test {
                type {
                    ping {
                        target 8.8.8.8
                    }
                }
            }
        }
        interface pppoe0 {
            route-test {
                type {
                    ping {
                        target 8.8.8.8
                    }
                }
            }
        }
    }
}

 Em seguida, adicionaremos um firewall modificar a regra

    
   modify BALANCE {
        rule 10 {
            action modify
            description "Do not load-balance LAN to LAN traffic"
            destination {
                address 192.168.1.0/24
            }
            modify {
                table main
            }
        }
        rule 20 {
            action modify
            description "load-balance the rest of LAN to WAN traffic"
            modify {
                lb-group WLB
            }
        }
    }

Em seguida, aplica a regra de modificar para a LAN "no".

    ethernet eth1 {
        address 192.168.1.1/24
        description LAN
        firewall {
            in {
                modify BALANCE
            }
        }
    }

 Neste ponto nosso tráfego de LAN está sendo equilibrado ambos Wan bastante uniformemente:

 

ubnt@R1:~$ show load-balance status 
Group WLB
  interface   : eth0
  carrier     : up
  status      : active
  gateway     : 20.0.0.1
  weight      : 50
  flows
      WAN Out : 682
      WAN In  : 0
    Local Out : 20

  interface   : pppoe0
  carrier     : up
  status      : active
  gateway     : pppoe0
  weight      : 50
  flows
      WAN Out : 672
      WAN In  : 0
    Local Out : 22

 

Mas nosso túnel GRE agora não funciona.  O primeiro problema é que não queremos para balancear a carga do tráfego de LAN que é suposto para ir ao longo do túnel GRE.  Então vamos adicionar uma regra antes da regra de lb-grupo como:

 

ubnt@R1# show firewall modify 
 modify BALANCE {
     rule 10 {
         action modify
         description "Do not load-balance LAN to LAN traffic"
         destination {
             address 192.168.1.0/24
         }
         modify {
             table main
         }
     }
     rule 20 {
         action modify
         description "Do not load-balance traffic for gre tunnel"
         destination {
             address 172.16.1.0/24
         }
         modify {
             table main
         }
     }
     rule 30 {
         action modify
         description "load-balance the rest of LAN to WAN traffic"
         modify {
             lb-group WLB
         }
     }
 }

 Isto é principalmente de trabalho agora, mas às vezes preciso derrubar a interface pppoe para o túnel GRE para aparecer corretamente.  A próxima edição está relacionada como o recurso de balanceamento de carga é atualmente implementado com uma tabela de roteamento separada por WAN interface que só tem uma rota padrão para o WAN.  Isso funciona bem para LAN para WAN sessões, mas quebra quando precisamos de uma rota conectada da tabela de roteamento "principal".  Assim que o trabalho atual é em vez de usar a tabela de roteamento separada do sistema gerado, em vez disso criar o seu próprio que tem a rota padrão para o WAN e as rotas conectadas que são necessários.

 

ubnt@R1# show protocols static table 
 table 1 {
     interface-route 20.0.0.0/30 {
         next-hop-interface eth0 {
         }
     }
     interface-route 192.168.1.0/24 {
         next-hop-interface eth1 {
         }
     }
     route 0.0.0.0/0 {
         next-hop 20.0.0.1 {
         }
     }
 }
 table 2 {
     interface-route 0.0.0.0/0 {
         next-hop-interface pppoe0 {
         }
     }
     interface-route 20.0.0.0/30 {
         next-hop-interface eth0 {
         }
     }
     interface-route 192.168.1.0/24 {
         next-hop-interface eth1 {
         }
     }
 }

 

E, em seguida, altere a configuração de balanceamento de carga para usar a tabela de roteamento do excesso de carona.

ubnt@R1# show load-balance           
 group WLB {
     interface eth0 {
         route {
             table 1
         }
         route-test {
             type {
                 ping {
                     target 8.8.8.8
                 }
             }
         }
     }
     interface pppoe0 {
         route {
             table 2
         }
         route-test {
             type {
                 ping {
                     target 8.8.8.8
                 }
             }
         }
     }
 }

O arquivo de configuração completo para R1 com GRE e WAN-balanceamento de carga é:

 

R1 /config/config.boot GRE com WAN-balanceamento de carga

 

Abaixo está o exemplo de arquivos de configuração para um túnel IPSec entre R1 e R2 enquanto R1 tem WAN-balanceamento de carga configurado.

 

R1 /config/config.boot IPSec para R2 com WAN-balanceamento de carga

IPSec de /config/config.boot de R2 para R1