我真的很难让我们的 SRX 记录不在状态表中的会话并因此被删除。
例如,如果您重新启动防火墙并且某些旧的 NFS 实现继续通过同一会话发送流量,一旦 SRX 返回,它就会丢弃这些数据包,因为它没有看到三向握手。但是,它不会记录这些掉落。是的,已启用登录清理规则。
我真的很难让我们的 SRX 记录不在状态表中的会话并因此被删除。
例如,如果您重新启动防火墙并且某些旧的 NFS 实现继续通过同一会话发送流量,一旦 SRX 返回,它就会丢弃这些数据包,因为它没有看到三向握手。但是,它不会记录这些掉落。是的,已启用登录清理规则。
无论是否监视 TCP 握手,都应对数据包进行分类。如果没有为该流(快速路径)定义会话,则应创建一个新会话(第一个路径)。
你有没有配置任何屏幕?也许是屏幕导致流量下降。
也许您可以使用 traceoptions 配置日志文件:
security {
flow {
traceoptions {
file trace_file;
flag basic-datapath;
packet-filter Match {
protocol tcp;
source-prefix <source-ip>;
destination-prefix <dest-ip>;
destination-port <tcp-port>;
}
}
}
}
当心这些痕迹,因为如果它承载大量流量,它会导致 SRX 上的 CPU 负载很高。尽可能限制过滤器并在维护窗口期间运行它。
作为临时解决方法,您可以始终禁用 tcp-syn-checking,如果它与安全策略匹配但没有正确的 3 路设置,则允许流量返回。基本上它将允许数据包创建会话。
这不太安全,也不理想,但在短期内,直到你修复你的东西,它可能是一个可行的解决方法。
附加信息:http : //www.juniper.net/techpubs/software/junos-security/junos-security10.2/junos-security-swconfig-security/topic-44055.html
http://kb.juniper.net/InfoCenter/index?page=content&id=KB21266
我很想测试这个或看到它记录在某处。我见过似乎超出状态会话的日志,或者至少这是我对它们的解释,因此发现这一点会让我感到惊讶。