N4接口破解：SMF与UPF之间的PFCP会话建立、报文转发规则配置、流量检测与报告机制

N4接口，说白了就是SMF和UPF之间的“指挥链”。SMF负责下指令，UPF负责执行。这个接口用的是PFCP协议，全称是Packet Forwarding Control Protocol。嗯，这个名字有点长，你记住PFCP就行。

我个人习惯把N4接口比作“交警和红绿灯的关系”。SMF是交警，UPF是红绿灯。交警（SMF）告诉红绿灯（UPF）什么时候变绿、什么时候变红、什么时候抓拍。红绿灯只管执行，不负责决策。

4.1 PFCP会话建立流程

PFCP会话建立，是SMF和UPF之间通信的第一步。没有这个会话，后面所有的事情都干不了。

我在项目中遇到过一个问题：UPF一直收不到SMF的会话建立请求。查了半天，发现是N4接口的IP地址配错了。你想想看，IP都配错了，数据包怎么可能到达？

PFCP会话建立的流程大致如下：

1. SMF构造一个PFCP Session Establishment Request消息
2. SMF把这个消息通过N4接口发给UPF
3. UPF收到后，解析消息内容，分配资源
4. UPF回复PFCP Session Establishment Response消息
5. SMF收到回复，确认会话建立成功

为什么会这样设计？因为一个UPF可能同时服务多个SMF，每个SMF又可能管理多个会话。没有SEID，UPF根本不知道消息属于哪个会话。

4.2 报文转发规则配置

会话建立之后，SMF需要告诉UPF：遇到什么样的数据包，该怎么处理。这就是报文转发规则配置。

PFCP里定义了两种核心规则：

• PDR（Packet Detection Rule）：报文检测规则，告诉UPF“你要抓什么样的包”
• FAR（Forwarding Action Rule）：转发动作规则，告诉UPF“抓到包以后怎么处理”

我举个例子你就明白了：

PDR规则：
- 源IP：10.0.0.0/8
- 目的IP：8.8.8.8
- 协议：UDP
- 端口：53

FAR规则：
- 动作：FORWARD
- 下一跳：192.168.1.1
- 封装：GTP-U

这个规则的意思是：如果UPF收到一个源IP是10网段、目的IP是8.8.8.8、UDP端口53的数据包，就把它封装成GTP-U格式，转发到192.168.1.1。

4.3 流量检测与报告机制

SMF不光要指挥UPF转发数据，还要知道流量情况。比如：用户用了多少流量？有没有异常流量？这些都需要UPF上报。

PFCP里用URR（Usage Reporting Rule）来实现流量检测和报告。URR可以配置成：

• 按流量上报：每用掉1GB就报一次
• 按时间上报：每5分钟报一次
• 按事件上报：会话结束时报一次

我建议你在实际项目中，不要设置太频繁的上报间隔。为什么？因为UPF每报一次，SMF就要处理一次。如果成千上万个用户同时上报，SMF可能会被撑爆。

流量报告的内容通常包括：

字段	说明	示例值
Total Volume	总流量（上行+下行）	1024 MB
Uplink Volume	上行流量	512 MB
Downlink Volume	下行流量	512 MB
Duration	会话持续时间	3600 秒

4.4 核心知识体系

下面这张图展示了N4接口的核心逻辑。你看一眼就能明白SMF和UPF之间是怎么配合的。

这张图展示了N4接口的三个核心步骤：

• 第一步：SMF发起PFCP会话建立，UPF确认
• 第二步：SMF下发PDR和FAR规则，UPF开始按规则处理数据包
• 第三步：UPF根据URR配置，定期或按事件向SMF上报流量使用情况

嗯，这里要注意一点：这三个步骤不是一次性的。会话建立后，SMF随时可以更新规则，UPF也随时可以主动上报异常情况。

我在做渗透测试时发现，很多厂商的UPF实现里，对PFCP消息的校验不够严格。比如SEID字段，有些UPF根本不检查这个值是否合法。这就给了攻击者可乘之机——伪造一个PFCP消息，就能让UPF执行恶意规则。

所以，我建议你在部署时，一定要开启PFCP消息的完整性校验。3GPP标准里定义了PFCP消息的完整性保护机制，虽然会增加一点点处理延迟，但安全性提升是值得的。

---

公众号:蓝海资料掘金营，微信deep3321