3. PLCnext设备网络配置与远程连通性
PLCnext 控制器（如 AXC F 2152、AXC F 3152）出厂时通常带有两个独立以太网口：X1 与 X2。理解这两个口的默认角色，是后续所有网络配置的起点。X1 一般作为工程/编程口，出厂默认 IP 为 192.168.1.10/24；X2 常用于连接现场设备或上层网络，默认可能处于 DHCP 客户端模式或另一网段。远程诊断能否建立，本质上取决于三件事：地址是否可达、路由是否知道往哪走、通道是否被允许通过。
IP 地址规划：先定网段，再定角色
建议在项目初期就固定一张地址规划表，而不是现场临时分配。一个可参考的示例规划如下（示例参数，非实测）：
| 对象 | 接口 | IP 地址 | 用途 |
|---|---|---|---|
| PLCnext 控制器 | X1 | 192.168.10.10/24 | 工程组态、本地调试 |
| PLCnext 控制器 | X2 | 10.20.0.10/24 | 连接现场交换机/上层网络 |
| 工程师笔记本 | 以太网 | 192.168.10.100/24 | 本地直连调试 |
| 远程 VPN 客户端 | 虚拟网卡 | 10.99.0.50/24 | 远程访问 |
| 现场网关/路由器 | LAN | 10.20.0.1/24 | 出口与端口映射 |
规划原则有三点：第一，X1 与 X2 不要落在同一网段，否则会产生双网卡同网段的路由歧义；第二，远程访问网段（如 10.99.0.0/24）与现场网段（10.20.0.0/24）必须区分，便于在 VPN 中做精确路由；第三，所有地址应记录在案，避免与现场已有设备冲突。修改 IP 可通过 PLCnext Engineer 的设备属性、Web 界面（WBM）的 Network 页面，或直接编辑 Linux 侧的 netplan/网络配置文件完成。
路由与网关：让数据知道往哪走
网关是“默认出口”，路由是“特定方向”。当 PLCnext 需要访问非本网段地址时，会先查路由表，匹配不到才走默认网关。典型场景是：控制器 X2 接现场网段 10.20.0.0/24，网关为 10.20.0.1；而远程客户端位于 10.99.0.0/24。此时需要在现场出口设备上配置到 10.99.0.0/24 的回程路由，否则请求能到达控制器，响应却回不去，表现为“能 ping 通一半”或连接超时。
在 Linux 侧可用 ip route 查看路由表，确认默认网关与静态路由是否正确。若控制器需要主动访问某个远程服务器，可添加静态路由，例如：
# 示例：添加一条到远程网段的静态路由
sudo ip route add 10.99.0.0/24 via 10.20.0.1 dev eth1
# 查看当前路由表
ip route show判断路由是否生效，最直接的方法是 ping 目标地址并观察是否返回，再用 traceroute 查看路径在哪一跳中断。若第一跳就不通，问题在本地网关；若中途某跳后无响应，问题在该跳之后的回程路由或防火墙。
VPN 接入：把远程客户端“放进”现场网段
远程诊断不建议直接把 PLCnext 暴露在公网。常见做法是使用 VPN，让远程客户端获得一个虚拟地址，并只允许访问必要的现场网段。以 WireGuard 为例，现场网关作为服务端，远程客户端作为对端，配置中需明确 AllowedIPs，只放行 10.20.0.0/24 与 10.99.0.0/24，避免全流量绕行。OpenVPN 则通过 server 与 client 配置、证书和 push "route 10.20.0.0 255.255.255.0" 下发路由。
VPN 建立后，远程客户端应能 ping 通 10.20.0.10（控制器 X2）。若不通，依次检查：隧道是否握手成功、虚拟网卡是否拿到地址、AllowedIPs/路由是否包含目标网段、现场出口是否允许该 VPN 网段进入。VPN 解决的是“通道”，不解决“权限”，因此还需要防火墙与端口映射配合。
防火墙规则与端口映射：只开必要的门
PLCnext 基于 Linux，可用 iptables/nftables 或防火墙管理工具控制入站流量。远程诊断通常只需要少数端口，例如：
- TCP 22：SSH，用于命令行诊断（建议仅限 VPN 网段）；
- TCP 443：Web 管理界面（WBM）；
- TCP 41100 或工程组态相关端口：PLCnext Engineer 在线连接；
- UDP 161：SNMP（如启用监控）。
端口映射（DNAT）用于把公网或上级网络的某个端口转发到控制器。例如，将网关公网地址的 2222 端口映射到 10.20.0.10 的 22 端口，远程即可通过 ssh -p 2222 user@网关公网IP 登录。但更安全的做法是：不直接映射到控制器，而是先接入 VPN，再在 VPN 内访问控制器，减少暴露面。
安全远程通道的建立顺序
把上述环节串起来，一条可用的远程诊断通道通常按以下顺序建立：先完成 IP 规划与接口配置，确保本地可达；再配置网关与静态路由，保证跨网段双向可达；然后建立 VPN 隧道，让远程客户端进入受控网段；接着在控制器与出口设备上设置防火墙规则，只放行必要端口；最后按需做端口映射或直接走 VPN 内访问。每一步都应有明确的验证动作，而不是全部配完再一次性测试。
结果判断与常见问题
配置完成后，判断通道是否真正可用，不能只看“能 ping 通”。建议按层次验证：第一层，本地工程师笔记本 ping 192.168.10.10，确认 X1 可达；第二层，远程客户端 ping 10.99.0.1（VPN 网关）与 10.20.0.10，确认隧道与路由生效；第三层，用 telnet 10.20.0.10 22 或 nc -zv 10.20.0.10 443 确认端口开放；第四层，实际用 PLCnext Engineer 或浏览器登录，确认应用层可用。
常见故障中，最典型的是“单向可达”：远程能发请求，控制器回包却走了默认网关而非 VPN 隧道，导致连接超时。这通常是因为现场网关缺少到 VPN 网段的回程路由，或控制器默认网关指向了错误接口。另一个典型问题是“端口映射后仍不通”，需检查 DNAT 规则是否匹配、防火墙 FORWARD 链是否放行、以及控制器自身是否监听该端口。排查时遵循“先本地、后远程；先网络层、后应用层”的顺序，可以快速缩小范围。