Ubuntu服务器安全内网隔离业务与管理后台

Ubuntu服务器上把业务网段和管理后台从网络层隔开，很多运维第一时间想到的是配置防火墙规则或者划分VLAN，但真正动手时才发现问题不在“能不能通”，而在“哪些流量必须放行、哪些默认拒绝、管理通道断了怎么恢复”。内网隔离的核心不是把网线拔了，而是让业务流量和管理流量走不同的路径、受不同的策略控制，同时保证管理入口在业务网络出现问题时依然可用。下面直接讲具体做法和容易踩坑的地方。

在Ubuntu服务器上做内网隔离，通常需要至少两块网卡，或者一块网卡通过VLAN子接口区分业务和管理。假设服务器有两块物理网卡：ens18接业务网络，ens19接管理网络。第一步是确认网卡名称和当前路由状态。可以用 ip addr 和 ip route 查看。很多服务器默认只有一条默认路由，所有流量都从同一块网卡出去，这样即使配置了第二块网卡，管理流量也可能绕到业务网卡上。

正确的做法是给管理网卡配置独立的IP段，并且不要让管理网段出现在默认路由里。比如业务网段是192.168.10.0/24，管理网段是10.10.10.0/24。Ubuntu使用netplan配置时，需要明确指定每个网卡的地址和路由策略。管理网卡只配置IP和子网掩码，不添加默认网关，或者使用策略路由让管理流量只从管理网卡进出。

编辑 /etc/netplan/00-installer-config.yaml，典型配置如下：

network:
  version: 2
  ethernets:
    ens18:
      addresses:
        - 192.168.10.20/24
      routes:
        - to: default
          via: 192.168.10.1
      nameservers:
        addresses: [192.168.10.1]
    ens19:
      addresses:
        - 10.10.10.20/24
      routes:
        - to: 10.10.10.0/24
          via: 10.10.10.1

这里的关键是ens19没有默认路由，只有到管理网段的路由。这样业务流量走ens18，管理流量走ens19，两者在路由层面已经分开。但仅靠路由还不够，因为如果业务网络里的主机知道管理IP，仍然可以尝试连接管理端口。所以下一步必须配合防火墙限制来源。

Ubuntu 22.04及以后版本默认使用nftables，但iptables命令仍然兼容。推荐直接用nftables，规则更清晰。核心思路是：管理网卡ens19只允许来自管理网段10.10.10.0/24的访问，并且只开放管理端口，比如SSH的22端口、Web管理后台的443端口。业务网卡ens18则只开放业务端口，比如80、443、数据库端口等，完全拒绝SSH和管理后台端口。

nftables规则示例：

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        
        # 允许回环
        iif lo accept
        
        # 允许已建立连接
        ct state established,related accept
        
        # 管理网卡：只允许管理网段访问SSH和管理后台
        iif ens19 ip saddr 10.10.10.0/24 tcp dport { 22, 443 } accept
        iif ens19 drop
        
        # 业务网卡：只允许业务端口
        iif ens18 tcp dport { 80, 443 } accept
        iif ens18 drop
    }
    
    chain forward {
        type filter hook forward priority 0; policy drop;
    }
}

这个规则集默认丢弃所有入站流量，然后针对不同网卡放行特定端口和来源。管理网卡只接受来自管理网段的22和443端口，业务网卡只接受80和443。这样即使业务网络被入侵，攻击者也无法直接访问管理后台，因为管理端口在业务网卡上根本不开放。

很多人配置了防火墙，但SSH服务默认监听0.0.0.0，这意味着所有网卡上的22端口都在监听。虽然防火墙可以挡住业务网卡的22端口，但更彻底的做法是让SSH只监听管理网卡的IP。编辑 /etc/ssh/sshd_config，找到 ListenAddress 配置：

ListenAddress 10.10.10.20

这样即使防火墙规则被意外清空，业务网络也无法通过SSH连接服务器。同样的道理，如果管理后台是Web服务，比如Cockpit、Webmin或者自研后台，应该让服务绑定管理IP，而不是0.0.0.0。例如Cockpit默认监听9090端口，可以在其配置中指定监听地址。

如果管理后台和业务跑在同一台Ubuntu服务器上，隔离的难度会大一些。更推荐的做法是将管理后台部署在独立的服务器或容器中，通过管理网段访问。如果必须共用一台服务器，至少要把管理后台的进程、端口和文件权限与业务进程分开。比如业务跑在Docker容器里，管理后台跑在宿主机上，或者反过来。关键是管理后台不能依赖业务网络的连通性，否则业务网络出问题时管理后台也上不去。

还有一种常见做法是用带外管理口，比如服务器的IPMI或iDRAC，这类接口本身独立于操作系统，即使Ubuntu系统崩溃也能远程管理。但IPMI通常也有独立的网络接口，需要单独接入管理交换机。对于没有带外管理口的服务器，双网卡加防火墙是基础方案。

如果Ubuntu服务器上跑了Docker，默认的bridge网络和宿主机网络是隔离的，但容器可以通过宿主机路由访问管理网段。要防止业务容器访问管理后台，需要在Docker的网络配置中做限制。可以在docker-compose或启动参数中禁用容器对管理网段的访问，或者使用iptables在FORWARD链中丢弃从docker网桥到管理网段的流量。

例如docker网桥是172.17.0.0/16，管理网段是10.10.10.0/24，可以在nftables的forward链中加规则：

iif docker0 ip daddr 10.10.10.0/24 drop

这样即使业务容器被攻破，也无法横向访问管理后台。另外要注意Docker默认会修改iptables规则，可能和手动配置的防火墙冲突。建议在Docker启动配置中设置 iptables: false，然后统一用nftables管理所有规则，避免规则互相覆盖。

内网隔离不仅是网络层的隔离，日志和审计数据也要分开。如果Ubuntu服务器把系统日志通过syslog发送到业务网络里的日志服务器，那么业务网络被入侵后，攻击者可能篡改或删除日志。正确做法是将日志通过管理网卡发送到管理网段的日志服务器，或者至少配置独立的日志通道。rsyslog可以指定发送日志的源地址，确保日志流量从管理IP出去。

在 /etc/rsyslog.conf 或 /etc/rsyslog.d/ 下的配置中，可以设置：

$LocalHostName ubuntu-server
$ActionSourceIP 10.10.10.20
*.* @10.10.10.100:514

这样日志会从管理IP发出，业务网络无法截获。同时管理后台的登录日志、sudo操作日志都应该集中到管理网段的审计系统里。

配置完成后，必须从业务网络和管理网络分别测试。从业务网络尝试SSH到服务器的业务IP，应该被拒绝；尝试访问管理后台端口，也应该被拒绝。从管理网络访问管理IP的22和443端口，应该正常。还要测试业务流量是否正常，比如网站能否访问、数据库能否连接。很多人在配置防火墙时把业务端口也误杀了，导致业务中断。

另一个重要测试是管理通道的恢复能力。如果管理网卡故障或者防火墙规则配错，如何恢复？对于物理服务器，可以接显示器键盘本地登录；对于云服务器，可以通过控制台的VNC或串口登录。如果没有本地访问手段，建议在防火墙规则中设置一个定时任务，比如每5分钟检查管理网卡连通性，如果连续失败则临时放行业务网卡的SSH端口，或者回滚防火墙规则。这种“自杀开关”可以避免把自己锁在门外。

Ubuntu服务器内网隔离业务与管理后台，核心是路由分离、防火墙限制来源、服务绑定管理IP、日志独立通道。双网卡配置只是第一步，真正起作用的是默认拒绝的防火墙策略和针对管理流量的精细控制。不要把管理后台暴露在业务网段，也不要让业务容器能访问管理网段。测试时要同时验证业务可用性和管理通道的独立性，并准备好本地恢复手段。