Linux防火墙不直接处理应用层内容，仅在网络层和传输层基于五元组及连接状态过滤；需结合nginx等代理实现应用层控制，filter表通过INPUT/OUTPUT/FORWARD链及conntrack状态跟踪实现精准放行。
Linux 防火墙本身不直接处理应用层内容（如 HTTP 请求体、URL 路径、JSON 数据），但可通过组合机制实现应用层安全策略效果；真正的报文过滤发生在网络层和传输层，依赖五元组匹配与连接状态跟踪。
防火墙并不等于应用层网关
很多人误以为 iptables 或 firewalld 能像专业 WAF 那样解析 HTTP 头或拦截 SQL 注入——其实不能。Linux 内核的 netfilter 框架只解析到 IP/TCP/UDP 层，最多识别协议类型（如 TCP）、端口（如 80/443）、TCP 标志位（SYN/ACK）和连接状态（ESTABLISHED/RELATED）。它看不到 URI、User-Agent 或 Cookie 内容。
若需应用层控制，必须借助外部代理：比如用 nginx 做反向代理并启用 mod_security，或用 squid 实现 URL 过滤。这些工具工作在用户空间，接收已解封装的应用数据，再做规则判断。
filter 表是报文过滤的核心载体
默认使用的 filter 表专用于决定数据包是否放行，主要作用于 INPUT、OUTPUT、FORWARD 三条链：
- INPUT 链处理目标为本机的数据包（如 SSH 登录请求）
- OUTPUT 链处理本机主动发出的数据包（如 curl 请求外网）
- FORWARD 链仅在开启 IP 转发时生效，处理经本机中转的流量（如路由器模式）
每条链的规则按顺序逐条匹配，一旦命中即执行动作（ACCEPT/DROP/REJECT），不再继续检查后续规则。因此规则排列顺序至关重要——例如“允许 ESTABLISHED 连接”必须放在“拒绝所有”之前，否则已建立的会话也会被拦掉。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
状态跟踪让无状态过滤变“有感知”
单纯靠源 IP+端口放行风险极高（易被伪造），所以实际策略普遍启用 conntrack 模块：
- ESTABLISHED：表示该包属于已有双向通信的后续分片（如 HTTP 响应）
- RELATED：表示该包与已有连接逻辑相关（如 FTP 的数据连接、ICMP 错误报文）
- NEW：表示新发起的连接首包（如 TCP SYN）
典型写法：iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT。这条规则让返回流量自动放行，无需为每个响应端口单独开白名单。
raw 表提前干预，绕过连接跟踪开销
某些场景下（如高吞吐 UDP 流量），连接跟踪会带来性能损耗。此时可用 raw 表在 PREROUTING 和 OUTPUT 链上标记跳过跟踪：
-
iptables -t raw -A PREROUTING -p udp --dport 53 -j NOTRACK可让 DNS 查询不进 conntrack 表 - 配合 filter 表规则使用，避免因状态缺失导致误丢包
注意：NOTRACK 后，该连接将无法使用 ESTABLISHED 状态匹配，需改用静态规则（如按端口/IP 放行）。
不复杂但容易忽略——真正起效的是规则逻辑与链位置的配合，而不是单条命令的华丽程度。
