Dépannage du problème " ; Blank Natted IP" ; dans l'enregistrement de données d'événement

Introduction

Ce document décrit comment dépanner le problème « IP nat vide » dans l'enregistrement de données d'événement (EDR).

Problème

EDR peut être vu avec le champ IP natté comme vide :

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

Dépannage

Scénario 1

Tout d'abord, vérifiez à quel Firewall-and-Nat Policy L'identification internationale d'abonné mobile (IMSI) est mappée et si la configuration est correcte.

Par exemple, dans show subscribers full imsi <> ,vous pouvez voir la politique de traduction d'adresses de réseau (NAT) NAT44 : Non requis qui doit être à l'état « Requis » et vous ne voyez pas non plus de pool d'adresses IP mappé ici :

  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

Lorsque vous vérifiez la configuration pour Firewall-and-Nat Policy: xyz, aucun pool d'adresses IP nantes n'est mappé.

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

Si vous comparez la même chose avec le scénario non problématique, vous pouvez voir Firewall-and-Nat Policy: abc , NAT Policy NAT44 : Required et 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

Si vous vérifiez la configuration pour « abc », vous pouvez observer que nat-realm www_nat est configuré et nat-realm a IP-Pool configuré :

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

Scénario 2

Vérifiez si l'abonnement de l'abonné est valide. Si pour un utilisateur Credit-Control is off, l'abonné n'obtient pas d'adresse IP NAT publique.

Scénario 3

Dans certains cas, l'IP natif n'est pas visible et pour ces EDR, vous voyez une heure de fin incorrecte.

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

Selon les journaux, EDR a une heure de fin de flux avec la date 01/01/1970.

En cas de défaillance de la fonction NAT ou d'une défaillance sur le premier paquet, et lorsque le flux a uniquement l'heure du premier paquet définie, l'heure du dernier paquet est à l'état initialisé. Lorsque ce type de délai d'expiration de flux et d'EDR est généré, alors l'heure du dernier paquet n'est pas définie et donc dans l'EDR, vous voyez l'heure de l'époque.

Scénario 4

EDR ICMP (Internet Control Message Protocol) sans IP publique : pour un abonné compatible NAT, si un flux est initié du côté du serveur, la traduction NAT n'est pas effectuée pour un tel flux, ce qui signifie que de tels flux de liaison descendante ne peuvent pas être nattés. Il s'agit du comportement attendu et conforme à la conception.

En outre, pour un paquet de liaison ascendante, si le serveur est inaccessible (par exemple), une erreur ICMP est renvoyée (dans le sens descendant). Ce flux ICMP ne peut pas être traduit par NAT. Par conséquent, l'EDR généré pour ce flux ICMP ne peut pas avoir l'IP/port public.

Exemple d'extrait :

Dans cette EDR, on peut voir que le flux ICMP suit un flux UDP juste une fraction de seconde plus tard pour le même serveur avec une adresse IP NAT vierge.