Solucionar problemas de "Vazio Nacionado IP" no Registro de Dados de Eventos

Introdução

Este documento descreve como solucionar o problema do "IP nativo em branco" no Registro de dados de eventos (EDR).

Problema

O EDR pode ser visto com o campo de IP natado como em branco:

06/06/2022 14:53:03:056,01/01/1970 05:30:00:000,a.b.c.d,123,,,e.f.g.h,443,6,0
06/06/2022 14:53:03:098,01/01/1970 05:30:00:000,a1.b1.c1.d1,456,,,e1.f1.g1.h1,443,6,0
06/06/2022 14:53:03:109,01/01/1970 05:30:00:000,a2.b2.c2.d2,789,,,e2.f2.g2.h2,8888,6,0

Troubleshooting

Cenário 1

Primeiro, verifique para qual Firewall-and-Nat Policy A Identificação Internacional de Assinante Móvel (IMSI) é mapeada e se a configuração é precisa.

Por exemplo, em show subscribers full imsi <> ,você pode ver a Política de conversão de endereço de rede (NAT) NAT44: Não obrigatória, que deve estar em "estado obrigatório", e também não vê nenhum pool de IP mapeado aqui:

  Firewall-and-Nat Policy: xyz
  Firewall Policy IPv4: Required
  Firewall Policy IPv6: Not-required
  NAT Policy NAT44: Not-required
  NAT Policy NAT64: Not-required
  CF Policy ID: n/a
  Congestion Mgmt Policy: n/a
  active input plcy grp: n/a             active output plcy grp: n/a            
  S6b Auth Status: N/A

Quando você verificar a configuração para Firewall-and-Nat Policy: xyz, não há nenhum Pool de IPs mapeado.

fw-and-nat policy fw-policy
      access-rule priority 3 access-ruledef acc_P3_Server1 permit 
      access-rule priority 4 access-ruledef acc_P3_Server2 permit 
      access-rule priority 5 access-ruledef acc_P3_Server3 permit 
      access-rule priority 6 access-ruledef acc_P3_Server4 permit 
      access-rule priority 7 access-ruledef acc_P3_Server5 permit 
      access-rule priority 8 access-ruledef acc_P3_Server6 permit 
      access-rule priority 9 access-ruledef acc_P3_Server7 permit 
      access-rule priority 10 access-ruledef acc_P3_Server8 permit 
      access-rule priority 11 access-ruledef acc_P3_ipv6_Server1 permit 
      access-rule priority 16 access-ruledef ACC_ICMP_DENY_ALL deny

Se você comparar o mesmo com o cenário não problemático, poderá ver Firewall-and-Nat Policy: abc , NAT Policy NAT44: Required e Nat Realm: www_nat.

 
Firewall-and-Nat Policy: abc
  Firewall Policy IPv4: Required 
  Firewall Policy IPv6: Required 
  NAT Policy NAT44: Required 
  NAT Policy NAT64: Required 
  Nat Realm: www_nat                     Nat ip address: a.b.c.d  (on-demand) (publicpool1) 
                                         Nexthop ip address: n/a

Se você verificar a configuração de "abc", poderá observar que nat-realm www_nat está configurado e nat-realm tem o pool de IP configurado:

fw-and-nat policy abc
      access-rule priority 12 access-ruledef DNSipv41 permit bypass-nat 
      access-rule priority 13 access-ruledef DNSipv42 permit bypass-nat 
      access-rule priority 20 access-ruledef DNSipv61 permit bypass-nat 
      access-rule priority 21 access-ruledef DNSipv62 permit bypass-nat 
      access-rule priority 36 access-ruledef ACC_ICMP_DENY_ALL deny 
      access-rule priority 59 access-ruledef NAT64-prefix permit nat-realm www_nat
      access-rule priority 60 access-ruledef ipv4_any permit nat-realm www_nat
      access-rule priority 2000 access-ruledef ar-all-ipv6 permit bypass-nat
 
    ip pool public_www8 a.b.c.d 255.255.255.0 napt-users-per-ip-address 1100 group-name public_internet max-chunks-per-user 10 port-chunk-size 32
    ip pool publicpool1 a1.b1.c1.d1 255.255.252.0 napt-users-per-ip-address 1024 group-name www_nat alert-threshold pool-used 80 clear 70 on-demand max-chunks-per-user 8 port-chunk-size 64
    ip pool publicpool2 a2.b2.c2.d2 255.255.252.0 napt-users-per-ip-address 1024 group-name www_nat alert-threshold pool-used 80 clear 70 on-demand max-chunks-per-user 8 port-chunk-size 64
    ip pool test a3.b3.c3.d3 255.255.255.248 private 0 group-name Test

Cenário 2

Verifique se o assinante tem uma assinatura válida. Se para qualquer usuário Credit-Control is off, o assinante não obtém um IP público nativo.

Cenário 3

Em alguns cenários, o IP antigo não pode ser visto e, para esses EDRs, você vê uma hora de término incorreta.

06/29/2022 04:35:57:754,01/01/1970 05:30:00:000,a.b.c.d,51564,,,w.x.y.z,443,6,0
06/29/2022 04:35:57:752,01/01/1970 05:30:00:000,a1.b1.c1.d1,46060,,,w1.x1.y1.z1,443,6,0
06/29/2022 04:35:57:755,01/01/1970 05:30:00:000,a2.b2.c2.d2,60670,,,w1.x1.y1.z1,443,6,0

De acordo com os registros, o EDR tem uma hora de término de fluxo com a data 01/01/1970.

Quando há uma falha de NAT ou alguma falha no primeiro pacote e o fluxo tem apenas o tempo do primeiro pacote definido, o tempo do último pacote está no estado inicializado. Quando esse tipo de timeout de fluxo e EDR é gerado, o último tempo do pacote não é definido e, portanto, no EDR, você vê o tempo de epoch.

Cenário 4

EDRs do Protocolo de Mensagem de Controle da Internet (ICMP - Internet Control Message Protocol) sem IP público: para um assinante habilitado para NAT, se houver um fluxo iniciado do lado do servidor, a conversão de NAT não será feita para esse fluxo, o que significa que esses fluxos de downlink não podem ser classificados. Este é o comportamento esperado e de acordo com o projeto.

Além disso, para um pacote de uplink, se o servidor estiver inacessível (como exemplo), um erro ICMP será retornado (na direção de downlink). Este fluxo ICMP não pode ser traduzido por NAT. Portanto, o EDR gerado para esse fluxo ICMP não pode ter o IP/porta público.

Trecho de exemplo:

Neste EDR, pode-se ver que o fluxo ICMP segue um fluxo UDP apenas uma fração de segundo mais tarde para o mesmo servidor com IP nativo em branco.