IBM Cloud Docs
Problemas de migração comuns do Vyatta 5400

Problemas de migração comuns do Vyatta 5400

As seções a seguir ilustram problemas comuns ou mudanças de comportamento que podem ser encontrados após migrar de um dispositivo Vyatta 5400 para um IBM Cloud® Virtual Router Appliance. Em alguns casos, ela inclui soluções alternativas para direcionar os problemas.

Política de estado global baseada em interface para firewall stateful

Problemas

O comportamento ao configurar "política de estado de estado" para firewalls stateful por meio da liberação 5.1 foi mudado. Em versões anteriores à liberação 5.1, ao configurar o state -global -state -policy de um firewall stateful, o vRouter incluía automaticamente uma regra Allow implícita para o retorno automático da comunicação da sessão.

Na liberação 5.1 e mais recente, deve-se incluir uma configuração de regra Allow no IBM Cloud® Virtual Router Appliance. A configuração stateful funciona para interfaces em dispositivos Vyatta 5400 e para protocolos em dispositivos VRA.

Soluções alternativas

Ao aplicar a regra firewall-in a uma interface de ingresso/interna, deve-se aplicar a regra Firewall-out à interface de egresso/externa. Caso contrário, o tráfego de retorno será eliminado na interface de egresso/externa.

Ativação de estado em regras de firewall

Problemas de habilitação de estado

Se global-state-policy não estiver configurado, essa mudança de comportamento não será afetada. Além disso, se você estiver usando a opção state enable em cada regra em vez de global-state-policy, a mudança de comportamento não será afetada.

Política baseada em zona: manipulação de zona local

Problemas de manipulação da zona local

Não há pseudo-interface "zona local" para designar para a política de zona.

Soluções alternativas de manipulação de zona local

Esse comportamento pode ser simulado aplicando um firewall baseado em zona para interfaces físicas e um firewall de interface para a interface de loopback. O firewall na interface de loopback filtra tudo que ingresse e egresse do roteador.

Por exemplo:

set security zone-policy zone internal default-action 'drop'
set security zone-policy zone internal description 'Private zone'
set security zone-policy zone internal interface 'dp0bond0'
set security zone-policy zone internal to external firewall 'internal-2-external'
set security zone-policy zone internal to ovpn firewall 'internal-2-ovpn'

set security zone-policy zone ovpn default-action 'drop'
set security zone-policy zone ovpn description 'OpenVPN'
set security zone-policy zone ovpn interface 'vtun0'
set security zone-policy zone ovpn to external firewall 'ovpn-2-external'
set security zone-policy zone ovpn to internal firewall 'ovpn-2-internal'
 
set interfaces loopback lo firewall local 'Local'
 
set security firewall name ovpn-2-external default-action accept
set security firewall name ovpn-2-internal default-action accept
 
set security firewall name external-2-ovpn default-action accept
set security firewall name external-2-internal default-action accept
 
set security firewall name internal-2-external default-action accept
set security firewall name internal-2-ovpn default-action accept
 
set security firewall name Local default-action 'drop'
set security firewall name Local 'default-log'
set security firewall name Local rule 10 action 'accept'
set security firewall name Local rule 10 description 'RIP' ("/opt/vyatta/etc/cpp.conf" )

Ordem de operação para firewalls, NAT, roteamento e DNS

Ordem das questões de operação

Em um cenário no qual o NAT de origem de mascaramento é implementado em um IBM Cloud® Virtual Router Appliance, não é possível usar o firewall para determinar o acesso dos hosts à Internet. Isso ocorre porque o endereço é o mesmo após NAT.

Para os dispositivos Vyatta 5400, essa operação foi possível porque a criação de firewall foi feita antes do NAT, permitindo que a restrição de hosts acessasse a Internet.

Ordem das soluções alternativas de operação

Um novo esquema de roteamento é necessário para o VRA:

os dns de roteamento
Esquema de roteamento

Tabela de roteamento baseado em política

Problemas de tabela de roteamento baseados em políticas

A palavra "Tabela" nas configurações é opcional no roteamento baseado em política do v5400. No entanto, para o VRA, se a ação for accept, o campo Tabela será obrigatório. Se a ação for drop na configuração do VRA, o campo Tabela será opcional.

Soluções alternativas de tabela de roteamento baseadas em política

"Tabela principal" é uma opção disponível no roteamento baseado em política do Vyatta 5400. O equivalente no VRA é "padrão de instância de roteamento".

Roteamento baseado em política na interface do túnel

Roteamento baseado em política nos problemas da interface do túnel

No IBM Cloud® Virtual Router Appliance PBR (Policy-Based Routing), as políticas podem ser aplicadas a interfaces de plano de dados para o tráfego de entrada, mas não a loopback, túnel, ponte, OpenVPN, VTI e interfaces não numeradas de IP.

Roteamento baseado em política nas soluções alternativas da interface de túnel

No momento, não há soluções alternativas para esse problema.

OpenVPN

Problemas de OpenVPN

O OpenVPN não começa a trabalhar ao usar o parâmetro push-route no IBM Cloud® Virtual Router Appliance.

Soluções alternativas de OpenVPN

Use o parâmetro openvpn-option, em vez de push-route.

GRE/VTI sobre IPSEC + OSPF

GRE/VTI over IPSEC + OSPF issues

  • Quando a VIF tem várias sub-redes configuradas, o tráfego não pode passar por elas no VRA.
  • O roteamento do InterVlan não está funcionando no VRA.

GRE/VTI over IPSEC + OSPF workarounds

Use regras de permissão implícitas para aceitar o tráfego em interfaces VIF.

IPsec

Problemas de IPsec

O Internet Protocol Security (baseado em prefixo) não funciona com o Filtro IN.

Soluções alternativas de IPsec

Use o IPsec (BASEADOS EM VTI).

IPSEC "match-none"

IPSEC "match-none" issues

Com dispositivos Vyatta 5400, a regra de firewall a seguir é permitida:

set firewall name allow rule 10 ipsec

No entanto, com o IBM Cloud® Virtual Router Appliance, não há IPsec.

IPSEC "match-none" workarounds

Possíveis regras alternativas para dispositivos VRA:

   match-ipsec  Inbound IPsec packets
   match-none   Inbound non-IPsec packets                                                                                                                

IPSEC 'match-ipsec"

IPSEC 'match-ipsec" issues

Com dispositivos Vyatta 5400, as regras de firewall a seguir são permitidas:

set firewall name OUTSIDE_LOCAL rule 50 action 'accept'
set firewall name OUTSIDE_LOCAL rule 50 ipsec 'match-ipsec'

No entanto, com o IBM Cloud® Virtual Router Appliance, não há IPsec.

IPSEC 'match-ipsec" workarounds

Inclua os protocolos ESP e AH (Protocolos IP 50 e 51, respectivamente).

A regra action pode ser accept ou drop, conforme mostrado no exemplo a seguir:

set security firewall name <name> rule <rule-no> action accept
set security firewall name <name> rule <rule-no> destination port 500
set security firewall name <name> rule <rule-no> protocol udp
set security firewall name <name> rule <rule-no> action accept
set security firewall name <name> rule <rule-no> destination port 4500
set security firewall name <name> rule <rule-no> protocol udp
set security firewall name <name> rule <rule-no> action accept
set security firewall name <name> rule <rule-no> protocol ah
set security firewall name <name> rule <rule-no> action accept
set security firewall name <name> rule <rule-no> protocol esp

Internet Protocol Security de site a site com DNAT

IPsec site a site com problemas de DNAT

O Internet Protocol Security (baseado em prefixo) não funciona com DNAT.

server (10.71.68.245) -- vyatta 1 (11.0.0.1)
===S-S-IPsec=== (12.0.0.1)
vyatta 2 -- client (10.103.0.1)
Tun50 172.16.1.245

O fragmento de código anterior é um pequeno exemplo de configuração para a conversão de DNAT após um pacote de Internet Protocol Security ser decriptografado em um Vyatta 5400. Neste exemplo, há dois Vyattas, vyatta1 (11.0.0.1) e vyatta2 (12.0.0.1). O peer do IPsec é estabelecido entre 11.0.0.1 e 12.0.0.1. Nesse caso, o cliente está direcionando 172.16.1.245 originado de 10.103.0.1 de ponta a ponta. O comportamento esperado desse cenário é que o endereço de destino 172.16.1.245 seja convertido para 10.71.68.245 no cabeçalho do pacote.

Inicialmente, o dispositivo Vyatta 5400 executava o DNAT no IPsec de entrada, finalizando a interface e retornando o tráfego normalmente para o túnel do IPsec, usando a tabela de rastreamento de conexão.

Em um IBM Cloud® Virtual Router Appliance, a configuração não funciona da mesma forma. A sessão é criada, no entanto, o tráfego de retorno ignora o túnel IPsec após a tabela conntrack reverter a alteração de DNAT.O VRA, em seguida, envia o pacote na ligação sem a criptografia do IPsec.O dispositivo de envio de dados não está esperando por esse tráfego e, muito provavelmente, não é capaz de recebê-lo.Embora a conectividade de ponta a ponta seja interrompida, esse é o comportamento pretendido.

IPsec site a site com soluções alternativas de DNAT

Para acomodar esse cenário de rede, a IBM criou um RFE.

Enquanto esse RFE está sendo avaliado atualmente, a solução alternativa a seguir é recomendada:

Comandos de configuração da interface

set interfaces dataplane dp0p192p1 address '11.0.0.1/30'
set interfaces dataplane dp0p224p1 address '10.0.0.2/30'
set interfaces dataplane dp0p224p1 policy route pbr 'Backwards-DNAT'
set interfaces loopback lo address '169.254.1.1/24'
set interfaces tunnel tun50 address '169.254.240.1/32'
set interfaces tunnel tun50 encapsulation 'gre'
set interfaces tunnel tun50 local-ip '169.254.1.1'
set interfaces tunnel tun50 remote-ip '169.254.1.1'

Comandos de configuração de VPN

set security vpn ipsec esp-group ESP lifetime '30000'
set security vpn ipsec esp-group ESP proposal 1 encryption 'aes128'
set security vpn ipsec esp-group ESP proposal 1 hash 'sha1'
set security vpn ipsec ike-group IKE lifetime '60000'
set security vpn ipsec ike-group IKE proposal 1 encryption 'aes128'
set security vpn ipsec ike-group IKE proposal 1 hash 'sha1'
set security vpn ipsec site-to-site peer 12.0.0.1 authentication mode 'pre-shared-secret'
set security vpn ipsec site-to-site peer 12.0.0.1 authentication pre-shared-secret 'thekey'
set security vpn ipsec site-to-site peer 12.0.0.1 default-esp-group 'ESP'
set security vpn ipsec site-to-site peer 12.0.0.1 ike-group 'IKE'
set security vpn ipsec site-to-site peer 12.0.0.1 local-address '11.0.0.1'
set security vpn ipsec site-to-site peer 12.0.0.1 tunnel 1 local prefix '172.16.1.245/30'
set security vpn ipsec site-to-site peer 12.0.0.1 tunnel 1 remote prefix '10.103.0.0/24'

Comandos de configuração de NAT

set service nat destination rule 10 destination address '172.16.1.245'
set service nat destination rule 10 inbound-interface 'tun50'
set service nat destination rule 10 source address '10.103.0.1'
set service nat destination rule 10 translation address '10.71.68.245'
set service nat source rule 10 destination address '10.103.0.1'
set service nat source rule 10 'log'
set service nat source rule 10 outbound-interface 'tun50'
set service nat source rule 10 source address '10.71.68.245'
set service nat source rule 10 translation address '172.16.1.245'

Comandos de configuração de protocolos

set protocols static interface-route 172.16.1.245/32 next-hop-interface 'tun50'
set protocols static table 50 interface-route 0.0.0.0/0 next-hop-interface 'tun50'

Comandos de configuração do PBR

set policy route pbr Backwards-DNAT description 'Get return traffic back to tunnel for DNAT'
set policy route pbr Backwards-DNAT rule 10 action 'accept'
set policy route pbr Backwards-DNAT rule 10 address-family 'ipv4'
set policy route pbr Backwards-DNAT rule 10 destination address '10.103.0.0/24'
set policy route pbr Backwards-DNAT rule 10 source address '10.71.68.0/24'
set policy route pbr Backwards-DNAT rule 10 table '50'

PPTP

Problemas do PPTP

O PPTP não é mais suportado no IBM Cloud® Virtual Router Appliance.

Soluções alternativas do PPTP

Em vez disso, use o protocolo L2TP.

Script para a reinicialização do Internet Protocol Security

Script para problemas de reinicialização de IPsec

Sempre que um endereço virtual VRRP é incluído em um IBM Cloud® Virtual Router Appliance em uma VPN de Alta Disponibilidade, deve-se reinicializar o daemon IPsec. Isso porque o serviço do IPsec atenderá apenas para conexões com os endereços que estiverem presentes no VRA quando o daemon de serviço do IKE for inicializado.

Para um par de VRAs com VRRP, o roteador de espera poderá não ter o endereço virtual do VRRP presente no dispositivo durante a inicialização se o roteador principal não tiver esse endereço presente. Portanto, para reinicializar o daemon do IPsec quando ocorrer uma transição de estado do VRRP, execute o comando a seguir nos roteadores principal e de backup:

interfaces dataplane interface-name vrrp vrrp-group group-id notify

Contagem recente e horário recente

Contagem recente e problemas de tempo recentes

A intenção da regra a seguir é limitar as conexões SSH a 3 a cada 30 segundos para SSH usando qualquer endereço:

set firewall name localGateway rule 300 action 'drop'
set firewall name localGateway rule 300 description 'Deter SSH brute force'
set firewall name localGateway rule 300 destination port '22'
set firewall name localGateway rule 300 protocol 'tcp'
set firewall name localGateway rule 300 recent count '3'
set firewall name localGateway rule 300 recent time '30'
set firewall name localGateway rule 300 state new 'enable'

No IBM Cloud® Virtual Router Appliance, essa regra tem os problemas a seguir:

  • A opção para contagem recente e horário recente foi descontinuada.
  • Devido ao problema anterior, a regra não pode funcionar como esperado e bloqueia todas as conexões SSH com a interface aplicada.

Contagem recente e soluções alternativas de tempo recentes

Use CPP como alternativa.

Configurar problemas de conntrack do sistema

Definir problemas de conntrack do sistema

set system conntrack expect-table-size '8192'
set system conntrack hash-size '375000'
set system conntrack modules ftp 'disable'
set system conntrack modules 'gre'
set system conntrack modules h323 'disable'
set system conntrack modules nfs 'disable'
set system conntrack modules pptp 'disable'
set system conntrack modules sip 'disable'
set system conntrack modules sqlnet 'disable'
set system conntrack modules tftp 'disable'
set system conntrack table-size '3000000'

Configurar tempo limite de conntrack do sistema

Definir problemas de tempo limite de conntrack do sistema

set system conntrack timeout icmp '30'
set system conntrack timeout other '600'
set system conntrack timeout tcp close '10'
set system conntrack timeout tcp close-wait '60'
set system conntrack timeout tcp established '432000'
set system conntrack timeout tcp fin-wait '120'
set system conntrack timeout tcp last-ack '30'
set system conntrack timeout tcp syn-recv '60'
set system conntrack timeout tcp syn-sent '120'
set system conntrack timeout tcp time-wait '60'

Firewall baseado em tempo

Problemas de firewall baseados em tempo

set firewall name PRIV_SERVICE_IN rule 58 action 'accept'
set firewall name PRIV_SERVICE_IN rule 58 description '586427 Acesso a base de dados ate 22-2-18'
set firewall name PRIV_SERVICE_IN rule 58 destination address '10.150.156.57'
set firewall name PRIV_SERVICE_IN rule 58 destination port '3306'
set firewall name PRIV_SERVICE_IN rule 58 protocol 'tcp'
set firewall name PRIV_SERVICE_IN rule 58 source address '10.150.156.104'
set firewall name PRIV_SERVICE_IN rule 58 time startdate '2017-08-22'
set firewall name PRIV_SERVICE_IN rule 58 time stopdate '2018-02-22'

TCP-MSS

Problemas de TCP-MSS

set interfaces tunnel tun3 address '172.17.175.45/30'
set interfaces tunnel tun3 encapsulation 'gre'
set interfaces tunnel tun3 local-ip '169.55.223.76'
set interfaces tunnel tun3 mtu '1476'
set interfaces tunnel tun3 multicast 'disable'
set interfaces tunnel tun3 policy route 'change-mss'(in 18.x unable to apply tcp-mss using PBR only option is to set on interface directly which i believe is not equivalent to pbr .
set interfaces tunnel tun3 remote-ip '104.129.200.34'
set policy route change-mss rule 1 protocol 'tcp'
set policy route change-mss rule 1 set tcp-mss '1436'
set policy route change-mss rule 1 tcp flags 'SYN

Aplicativo específico ou porta quebrada no VPN do Internet Protocol Security do S-S

Aplicativo específico ou porta quebrada em problemas de VPN S-S IPsec

vyatta@v5600dallas09# set security vpn ipsec site-to-site peer 12.0.0.1 tunnel 1 remote
Possible Completions:
   <Enter> Execute the current command
   port    Any TCP or UDP port
   prefix  Remote IPv4 or IPv6 prefix                                                                                                                                     set security vpn ipsec esp-group ESP lifetime '30000'
set security vpn ipsec esp-group ESP proposal 1 encryption 'aes128'
set security vpn ipsec esp-group ESP proposal 1 hash 'sha1'
set security vpn ipsec ike-group IKE lifetime '60000'
set security vpn ipsec ike-group IKE proposal 1 encryption 'aes128'
set security vpn ipsec ike-group IKE proposal 1 hash 'sha1'
set security vpn ipsec site-to-site peer 12.0.0.1 authentication mode 'pre-shared-secret'
set security vpn ipsec site-to-site peer 12.0.0.1 authentication pre-shared-secret 'thekey'
set security vpn ipsec site-to-site peer 12.0.0.1 default-esp-group 'ESP'
set security vpn ipsec site-to-site peer 12.0.0.1 ike-group 'IKE'
set security vpn ipsec site-to-site peer 12.0.0.1 local-address '11.0.0.1'
set security vpn ipsec site-to-site peer 12.0.0.1 tunnel 1 local prefix '172.16.1.245/30'
set security vpn ipsec site-to-site peer 12.0.0.1 tunnel 1 remote prefix '10.103.0.0/24'                                          set security vpn ipsec site-to-site peer 12.0.0.1 tunnel 1 remote port 21 (ftp)

Mudança significativa no comportamento de criação de log

Mudança significativa nos problemas de comportamento de criação de log

Há uma mudança significativa no comportamento de criação de log entre o dispositivo Vyatta 5400e o IBM Cloud® Virtual Router Appliance, de criação de log por sessão para criação de log por pacote.

  • Criação de log de sessão: registra transições de estado de sessão stateful
  • Criação de log de pacote: registrar todos os pacotes que correspondem à regra. Como a criação de log de pacotes é registrada no arquivo de log em "unidades de pacotes", há uma diminuição acentuada de rendimento e a pressão da capacidade do disco.
  • O recurso de criação de log do vRouter pode ser usado para capturar a atividade do firewall. Como qualquer função de criação de log, será necessário ativá-la apenas se estiver solucionando um problema específico e desativar a criação de log assim que puder.

O firewall stateful, que gerencia sessões do Firewall/NAT, grava em "unidades de sessão". É recomendado usar a criação de log de sessão. Cada exemplo de configuração é descrito.

Sessão/criação de log

  • security firewall session-log <protocol>
  • system syslog file <filename> facility <facility> level <level>

Firewall de criação de log de pacotes

  • security firewall name <name> default-log <action>
  • security firewall name <name> rule <rule-number> log

conversão de endereço de rede

  • service nat destination rule <rule-number> log
  • service nat source rule <rule-number> log PBR
  • policy route pbr <name> rule <rule-number> log

QoS

  • policy qos name <policy-name> shaper class <class-id> match <rule-name>