重启媒体应用后sendto系统调用返回EPERM错误的原因问询

• 内核连接跟踪（conntrack）表陈旧条目冲突
  主备切换场景下该问题出现概率最高。主服务器之前处理媒体流生成的五元组（源IP、源端口、目的IP、目的端口、协议）条目会残留在conntrack表中，主节点故障切走流量后这些条目会变为INVALID状态，当主节点重新承接业务发送同五元组的报文时，conntrack校验失败会直接返回EPERM。注意清空iptables规则不会自动清除已有的conntrack表项，只要conntrack模块处于加载状态就会执行校验。可以执行conntrack -F清空所有conntrack条目验证问题是否解决。
• 系统安全模块拦截
  即便清空了iptables规则，SELinux、AppArmor等内核安全模块如果处于enforcing模式，会对应用的发包行为做权限校验：如果应用绑定的端口不在安全模块的授权端口列表、或者应用进程的安全上下文不匹配，都会拦截发包操作返回EPERM。可以临时将安全模块切换为permissive模式验证问题根源。
• 反向路径过滤（rp_filter）触发丢弃
  当主服务器重新承接业务时，VIP路由、ARP表可能还未完全收敛，内核默认开启的rp_filter反向路径校验会判断出报文源IP对应的路由出接口和实际发送接口不一致，直接丢弃报文并返回EPERM。可以临时执行sysctl -w net.ipv4.conf.all.rp_filter=0关闭全局反向路径过滤验证是否是该问题导致。
• 套接字配置与权限问题
  如果应用发送报文使用的源端口是<1024的特权端口，重启后应用如果没有以root权限运行，会触发权限校验失败；另外如果套接字配置了SO_BINDTODEVICE参数绑定了错误的网卡设备，也会触发EPERM错误。可以通过ss -anp检查端口占用状态、核对应用运行权限和套接字初始化参数。

内容的提问来源于stack exchange，提问作者Alexandru Rusu