全的发一下

日志极简解读（H3C 防火墙 SSL VPN / 上网行为日志）

字段直译

1. SrcIPAddr=10.53.60.185
   源 IP 地址：内网终端 10.53.60.185
2. UserName=10.53.60.185
   登录用户名 / 认证账号直接用 IP 代替，未做账号实名认证
3. RcvVPNInstance=--
   无接收 SSL VPN 实例，该流量不是 VPN 拨号流量，是内网普通上网流量
4. PolicyName = 乱码
   策略名称显示异常乱码，原因 2 点：
   • 防火墙日志编码与日志服务器编码不统一（GBK/UTF-8 冲突）
   • 策略名称含中文，日志接收端不兼容中文，直接显示乱码

整体行为判定

解决乱码方案

1. 防火墙侧：策略名称全部改成英文 / 拼音，删掉中文
2. 日志服务器：接收日志编码统一改为 GB2312/GBK（H3C 设备默认日志编码）
3. 如需实名：内网对接 802.1X/iNode 认证，让日志正常抓取真实用户名，不再显示 IP 当账号

这条日志是H3C防火墙的基础流量会话日志，记录了一次内网设备的上网行为。当前信息是不完整的，但核心部分还是能看出关键问题。

 日志字段解读

• SrcIPAddr(1003)=10.53.60.185: 源IP地址，表明发起本次网络访问的设备IP。

• UserName(1113)=10.53.60.185: 用户名。这里显示的也是IP地址，意味着该用户未进行实名认证，设备便直接使用IP地址作为其用户名标识。

• RcvVPNInstance(1042)=--: 接收的VPN实例名。--代表空值，表示这是一次未经过VPN隧道的普通内网上网流量，直接访问公网。

• PolicyName(1079)= ֹ .: 匹配到的安全策略名称。此处是“乱码+一个点”，是这条日志最需要关注的地方。

 核心问题：PolicyName乱码

PolicyName乱码会导致你无法直接判断该流量是被“允许”还是“拒绝”了，其常见原因有两种：

• 编码不匹配（最可能）：H3C防火墙日志默认采用GB18030或GBK编。如果接收日志的服务器或分析软件使用UTF-8等编码解析，策略名称的中文字符就会变成乱码。

• 流量未命中自定义策略：如果该流量没有匹配到你创建的、带有中文名称的策略，而是走了防火墙底层的默认规则（默认允许或拒绝），由于匹配不到自定义名称，PolicyName字段就可能出现空值或异常字符。

 解决与深入排查

要解决乱码问题，并使日志完整可用，建议按以下步骤操作：

1. 获取完整日志：设法获取此次会话的完整日志，确认Action字段（1053）。该字段的值为permit（允许）或deny（拒绝），是判断行为结果的根本依据。

2. 统一编码（治本）：

   • 调整日志服务器：这是推荐做法。将你的日志服务器或分析软件的接收解码格式，统一设置为GB18030或GBK，以匹配防火墙发出的编码。

   • 调整防火墙：如果无法修改服务器，也可以在防火墙上执行命令来改变发送日志的编码。进入系统视图后，执行以下命令之一：

     • customlog character-encoding utf-8：将快速日志输出编码改为UTF-8。

     • info-center syslog utf-8 enable：将Syslog系统日志输出编码也改为UTF-8。

3. 优化策略命名：为避免类似问题，建议防火墙的安全策略名称统一使用英文或拼音，可以从根本上规避各种编码问题。

4. 排查流量行为：如果完成上述步骤后，PolicyName依然为空，则该流量可能确实没有命中任何自定义策略。可以在防火墙上用命令 display security-policy ip 并指定源IP 10.53.60.185 来模拟匹配，检查该IP实际命中的是哪条策略。