【网络工程】网络隔离与微分段：VLAN、SDN 策略与零信任

网络隔离的核心目标是限制攻击者的横向移动——即使突破了一个节点，也无法轻易访问其他系统。传统网络依赖 VLAN 和防火墙实现隔离，但在云原生和微服务时代，工作负载的动态性和密度使传统手段力不从心。微分段（Microsegmentation）和零信任网络架构代表了网络隔离的演进方向。

一、网络隔离的层次

1.1 隔离层级

隔离力度从粗到细：

┌─────────────────────────────────────────────────┐
│ 物理隔离（Physical Isolation）                     │
│  • 独立物理网络、独立交换机                         │
│  • 最强隔离但成本最高、灵活性最差                    │
│  例：军事/政府涉密网络                              │
├─────────────────────────────────────────────────┤
│ VLAN 隔离（L2 Segmentation）                      │
│  • 交换机端口划分虚拟局域网                         │
│  • 不同 VLAN 间需要路由器/三层交换机转发              │
│  例：企业部门间隔离（办公/服务器/访客）               │
├─────────────────────────────────────────────────┤
│ 子网/路由隔离（L3 Segmentation）                   │
│  • 不同子网通过防火墙/ACL 控制互访                   │
│  例：DMZ 与内网隔离                                │
├─────────────────────────────────────────────────┤
│ Overlay 隔离（VXLAN/GENEVE）                      │
│  • 虚拟网络叠加在物理网络之上                        │
│  • 租户/环境级别隔离                                │
│  例：云平台多租户隔离                               │
├─────────────────────────────────────────────────┤
│ 微分段（Microsegmentation）                       │
│  • 工作负载级别的访问控制                            │
│  • 每个 Pod/VM 独立策略                            │
│  例：Kubernetes Network Policy                    │
├─────────────────────────────────────────────────┤
│ 零信任（Zero Trust）                               │
│  • 不信任网络位置，每次访问都验证                     │
│  • 身份+设备+上下文的动态授权                        │
│  例：BeyondCorp / ZTNA                            │
└─────────────────────────────────────────────────┘

1.2 为什么传统隔离不够

传统的”城堡+护城河”（Castle-and-Moat）模型假设：外部不可信、内部可信。这个假设在以下场景中失败：

二、VLAN 隔离

2.1 VLAN 基础

VLAN（Virtual LAN，虚拟局域网）在交换机上将物理端口划分为逻辑广播域。不同 VLAN 的设备在二层不互通，必须通过三层设备（路由器/三层交换机）才能通信。

物理交换机
┌──────────────────────────────────────────────┐
│                                              │
│  VLAN 10 (办公)     VLAN 20 (服务器)          │
│  ┌────┐ ┌────┐     ┌────┐ ┌────┐            │
│  │PC-1│ │PC-2│     │Srv1│ │Srv2│            │
│  └──┬─┘ └──┬─┘     └──┬─┘ └──┬─┘            │
│     │      │          │      │               │
│  Port1  Port2      Port5  Port6              │
│  [VLAN10][VLAN10]  [VLAN20][VLAN20]          │
│                                              │
│           Trunk Port (Port24)                │
│           [VLAN10,20,30 tagged]              │
│                    │                         │
└────────────────────┼─────────────────────────┘
                     │
              ┌──────┴──────┐
              │  三层交换机   │
              │  VLAN 间路由  │
              │  + ACL 控制  │
              └─────────────┘

2.2 802.1Q VLAN Tag

IEEE 802.1Q 在以太网帧中插入 4 字节的 VLAN 标签：

标准以太网帧：
┌──────┬──────┬──────┬─────────┬─────┐
│ Dst  │ Src  │ Type │ Payload │ FCS │
│ MAC  │ MAC  │      │         │     │
└──────┴──────┴──────┴─────────┴─────┘

802.1Q Tagged 帧：
┌──────┬──────┬──────────┬──────┬─────────┬─────┐
│ Dst  │ Src  │ 802.1Q   │ Type │ Payload │ FCS │
│ MAC  │ MAC  │ Tag(4B)  │      │         │     │
└──────┴──────┴──────────┴──────┴─────────┴─────┘
                    │
            ┌───────┴───────┐
            │ TPID │ TCI    │
            │0x8100│        │
            │      │ PCP|DEI│
            │      │ VID    │
            └──────┴────────┘
            VID: 12 bit → 0-4095
            有效 VLAN: 1-4094

2.3 VLAN 的工程限制

# Linux 上配置 VLAN
ip link add link eth0 name eth0.10 type vlan id 10
ip addr add 10.10.0.1/24 dev eth0.10
ip link set eth0.10 up

# 查看 VLAN 配置
cat /proc/net/vlan/config

# 永久配置（netplan）
# /etc/netplan/01-vlans.yaml
# network:
#   version: 2
#   ethernets:
#     eth0:
#       dhcp4: no
#   vlans:
#     vlan10:
#       id: 10
#       link: eth0
#       addresses: [10.10.0.1/24]

2.4 VLAN 安全注意事项

VLAN 本身不是安全机制——它是广播域隔离机制。常见的 VLAN 安全问题：

VLAN Hopping 攻击：攻击者通过伪造 802.1Q 标签，从一个 VLAN 跳到另一个 VLAN。两种方式：

1. 交换机欺骗（Switch Spoofing）：攻击者模拟 Trunk 端口，与交换机协商 DTP（Dynamic Trunking Protocol），获得 Trunk 权限后可以访问所有 VLAN
2. 双标签攻击（Double Tagging）：在以太网帧上叠加两层 VLAN 标签。第一层标签被第一个交换机剥离，第二层标签在第二个交换机上被当作合法标签处理

防御措施：

# 在交换机上禁用 DTP 自动协商
# switchport mode access
# switchport nonegotiate

# 将 Native VLAN 改为不使用的 VLAN
# switchport trunk native vlan 999

# 在所有未使用的端口设置为 access 模式并关闭
# switchport mode access
# shutdown

三、VXLAN Overlay 隔离

3.1 VXLAN 基础

VXLAN（Virtual Extensible LAN，RFC 7348）解决了 VLAN 的规模限制。它将二层以太网帧封装在 UDP 数据包中，通过三层网络传输，实现跨物理网络的虚拟二层域。

VXLAN 封装格式：

┌─────────────┬──────────┬──────────┬───────────┬─────────────────────┐
│ 外层以太网帧 │ 外层 IP  │ 外层 UDP │ VXLAN 头  │ 内层以太网帧（原始）  │
│ (14 B)      │ (20 B)   │ (8 B)    │ (8 B)     │ 原始 MAC + IP + Data │
└─────────────┴──────────┴──────────┴───────────┴─────────────────────┘
                                         │
                                    ┌────┴────┐
                                    │ VNI     │
                                    │ 24 bit  │
                                    │ → 16M   │
                                    │ 虚拟网络 │
                                    └─────────┘

VXLAN vs VLAN：

3.2 VXLAN 在 Linux 上的配置

# 创建 VXLAN 接口
# VNI 100，目标端口 4789（IANA 标准端口）
# 对端 VTEP 地址 192.168.1.2，本端 192.168.1.1

ip link add vxlan100 type vxlan \
    id 100 \
    dstport 4789 \
    remote 192.168.1.2 \
    local 192.168.1.1 \
    dev eth0

ip addr add 10.100.0.1/24 dev vxlan100
ip link set vxlan100 up

# 验证
ip -d link show vxlan100
bridge fdb show dev vxlan100

# 多对端场景（使用桥接 + FDB 表项）
ip link add vxlan100 type vxlan \
    id 100 \
    dstport 4789 \
    local 192.168.1.1 \
    nolearning

ip link add br-vxlan100 type bridge
ip link set vxlan100 master br-vxlan100
ip link set vxlan100 up
ip link set br-vxlan100 up

# 静态 FDB 表项
bridge fdb append 00:00:00:00:00:00 dev vxlan100 dst 192.168.1.2
bridge fdb append 00:00:00:00:00:00 dev vxlan100 dst 192.168.1.3

3.3 GENEVE 与 VXLAN 对比

GENEVE（Generic Network Virtualization Encapsulation，RFC 8926）是 VXLAN 的下一代替代方案，被 OVN（Open Virtual Networking）等现代 SDN 方案采用：

GENEVE 的核心优势是 TLV（Type-Length-Value）可扩展选项——可以在封装头中携带安全标签、服务链信息等元数据，而 VXLAN 的固定格式无法扩展。

3.4 Overlay 隔离的 MTU 问题

# VXLAN 封装开销：50 字节
# 外层以太网 14 + 外层 IP 20 + 外层 UDP 8 + VXLAN 8 = 50

# 如果物理 MTU 为 1500：
# 内层有效 MTU = 1500 - 50 = 1450

# 推荐方案：物理网络设置 Jumbo Frame
# 物理交换机 MTU 设为 9000
# 则内层 MTU = 9000 - 50 = 8950（远超需求）

# 或在 VXLAN 接口设置 MTU
ip link set vxlan100 mtu 1450

# 检查 PMTUD 是否正常工作
ping -M do -s 1422 10.100.0.2
# -M do: 设置 DF 位
# -s 1422: 1422 + 8(ICMP) + 20(IP) = 1450

四、Kubernetes Network Policy

4.1 Network Policy 基础

Kubernetes Network Policy 是 K8s 原生的微分段机制。它允许以声明式的方式定义 Pod 间的网络访问控制。

关键概念： - 默认情况下，K8s 集群中所有 Pod 之间完全互通（扁平网络） - Network Policy 是白名单模型：一旦有 Policy 选中某个 Pod，该 Pod 的所有未明确允许的流量都被拒绝 - Network Policy 由 CNI 插件实现（Calico、Cilium、Weave 等），不是 kube-proxy

# 示例 1：只允许前端 Pod 访问后端 Pod 的 8080 端口
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend       # 应用于 backend Pod
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend    # 只允许 frontend Pod
      ports:
        - protocol: TCP
          port: 8080

---
# 示例 2：默认拒绝所有入站流量（零信任基础）
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}         # 选中命名空间内所有 Pod
  policyTypes:
    - Ingress             # 不指定 ingress 规则 → 拒绝所有

---
# 示例 3：允许监控系统访问所有 Pod 的 metrics 端口
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-monitoring
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: monitoring    # monitoring 命名空间
        - podSelector:
            matchLabels:
              app: prometheus
      ports:
        - protocol: TCP
          port: 9090

4.2 Calico Network Policy

Calico 扩展了 K8s Network Policy，提供更丰富的策略能力：

# Calico GlobalNetworkPolicy — 集群级别策略
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: deny-external-egress
spec:
  # 应用于所有非系统 Pod
  selector: projectcalico.org/namespace != "kube-system"
  types:
    - Egress
  egress:
    # 允许集群内通信
    - action: Allow
      destination:
        nets:
          - 10.0.0.0/8        # Pod CIDR
          - 172.16.0.0/12     # Service CIDR
    # 允许 DNS
    - action: Allow
      protocol: UDP
      destination:
        ports: [53]
    # 允许 HTTPS（指定外部服务）
    - action: Allow
      protocol: TCP
      destination:
        ports: [443]
        nets:
          - 0.0.0.0/0         # 或指定特定 IP 范围
    # 默认拒绝其他出站
    - action: Deny

---
# Calico NetworkPolicy — 带 HTTP 方法匹配（L7）
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: api-l7-policy
  namespace: production
spec:
  selector: app == "api-gateway"
  types:
    - Ingress
  ingress:
    - action: Allow
      protocol: TCP
      source:
        selector: app == "frontend"
      destination:
        ports: [8080]
      http:
        methods: ["GET", "POST"]
        paths:
          - prefix: "/api/v1/"

4.3 Cilium Network Policy

Cilium 基于 eBPF 实现网络策略，支持 L7 协议感知、DNS 感知和身份感知：

# Cilium L7 策略 — DNS 感知出站控制
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: external-api-access
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: payment-service
  egress:
    # 只允许访问特定外部 API
    - toFQDNs:
        - matchName: "api.stripe.com"
        - matchName: "api.paypal.com"
      toPorts:
        - ports:
            - port: "443"
              protocol: TCP
    # 允许集群内 DNS
    - toEndpoints:
        - matchLabels:
            k8s:io.kubernetes.pod.namespace: kube-system
            k8s-app: kube-dns
      toPorts:
        - ports:
            - port: "53"
              protocol: UDP
          rules:
            dns:
              - matchPattern: "*.stripe.com"
              - matchPattern: "*.paypal.com"

---
# Cilium 身份感知策略
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: db-access
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: database
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: backend
            environment: production
      toPorts:
        - ports:
            - port: "5432"
              protocol: TCP

4.4 Calico vs Cilium 对比

五、微分段设计方法论

5.1 微分段原则

微分段的核心是将网络划分为尽可能小的安全域，每个域有独立的访问控制策略。

传统分段（粗粒度）：            微分段（细粒度）：

┌──────────────────┐          ┌──────────────────┐
│     DMZ 区        │          │  ┌───┐  ┌───┐    │
│                  │          │  │Web│──│API│    │
│  Web  API  DB    │          │  └───┘  └─┬─┘    │
│  全部互通         │          │           │      │
│                  │          │  ┌───┐  ┌─┴─┐    │
└──────────────────┘          │  │Log│  │ DB│    │
                              │  └───┘  └───┘    │
传统：同区内无控制              │  每个服务独立策略  │
攻击者突破任一服务即可横向      └──────────────────┘
                              微分段：突破 Web 只能访问 API
                              无法直接访问 DB 或 Log

5.2 分段策略设计步骤

步骤 1：资产发现与分类
         │
         ↓
步骤 2：绘制通信矩阵（谁需要和谁通信）
         │
         ↓
步骤 3：定义安全域（按业务功能/敏感度/合规要求）
         │
         ↓
步骤 4：制定策略（最小权限原则）
         │
         ↓
步骤 5：部署策略（检测模式 → 强制模式）
         │
         ↓
步骤 6：持续监控与优化

通信矩阵示例：

基于此矩阵编写 Network Policy，确保只有矩阵中标记的通信被允许。

5.3 渐进式部署

# 阶段 1：可视化现有流量（Cilium Hubble）
# 安装 Hubble
cilium hubble enable

# 观察命名空间内的流量
hubble observe --namespace production --last 1000

# 导出流量矩阵
hubble observe --namespace production -o json | \
    jq -r '[.source.labels[] | select(startswith("k8s:app=")) | 
    ltrimstr("k8s:app=")][0] + " -> " + 
    [.destination.labels[] | select(startswith("k8s:app=")) | 
    ltrimstr("k8s:app=")][0]' | \
    sort | uniq -c | sort -rn

# 阶段 2：以审计模式部署策略
# Calico 的 staged 策略
# apiVersion: projectcalico.org/v3
# kind: StagedNetworkPolicy  # 不强制执行，只记录

# 阶段 3：分析策略匹配日志
# 检查哪些流量会被策略阻断

# 阶段 4：逐步切换到强制模式
# 从最不关键的服务开始

六、零信任网络架构

6.1 零信任原则

零信任（Zero Trust）的核心思想是”永远不信任，始终要验证”：

6.2 零信任架构组件

┌──────────────────────────────────────────────────┐
│                零信任架构                          │
├──────────────────────────────────────────────────┤
│                                                  │
│  ┌────────────────┐    ┌─────────────────┐       │
│  │ 策略决策点 (PDP) │    │ 身份提供者 (IdP)│       │
│  │                │←──│ • 用户身份       │       │
│  │ • 评估策略      │    │ • 设备状态       │       │
│  │ • 授权决策      │    │ • 上下文信息     │       │
│  └───────┬────────┘    └─────────────────┘       │
│          │                                       │
│          ↓                                       │
│  ┌───────────────┐                               │
│  │ 策略执行点 (PEP)│                               │
│  │               │                               │
│  │ • 代理/网关    │                               │
│  │ • 拦截所有请求 │                               │
│  │ • 执行授权决策 │                               │
│  └───────┬───────┘                               │
│          │                                       │
│     ┌────┴────┐                                  │
│     ↓         ↓                                  │
│  ┌─────┐  ┌─────┐                               │
│  │应用A │  │应用B │  ← 不直接暴露，只能通过 PEP 访问│
│  └─────┘  └─────┘                               │
│                                                  │
└──────────────────────────────────────────────────┘

6.3 零信任网络分段策略

# 零信任策略示例（伪配置）
# 结合身份 + 设备 + 网络 + 行为的多维策略

policy:
  name: "database-access"
  effect: allow
  
  subject:
    # 谁在访问？
    identity:
      - role: "backend-developer"
      - group: "platform-team"
    # 什么设备？
    device:
      - os_version: ">= 14.0"
      - encrypted: true
      - managed: true
      - compliance: "passed"
  
  resource:
    # 访问什么？
    service: "production-database"
    protocol: "postgresql"
    port: 5432
  
  conditions:
    # 什么条件下？
    time:
      - weekday: [1, 2, 3, 4, 5]   # 工作日
      - hours: [8, 20]              # 工作时间
    location:
      - country: ["CN", "US"]
    risk_score:
      - max: 50                     # 风险分 < 50
  
  actions:
    # 允许后做什么？
    log: true
    mfa_required: true               # 强制 MFA
    session_timeout: 3600            # 1 小时过期
    record_session: true             # 录制会话

6.4 Service Mesh 与零信任

Service Mesh（如 Istio、Linkerd）天然支持零信任的几个关键能力：

# Istio AuthorizationPolicy
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: backend-authz
  namespace: production
spec:
  selector:
    matchLabels:
      app: backend
  action: ALLOW
  rules:
    - from:
        - source:
            principals:
              - "cluster.local/ns/production/sa/frontend"
      to:
        - operation:
            methods: ["GET", "POST"]
            paths: ["/api/v1/*"]

七、网络隔离实施检查清单

7.1 VLAN 隔离检查

# 检查 VLAN 配置
# 1. 确认 Trunk 端口只允许必要的 VLAN
# 交换机上查看 trunk 配置
# show interfaces trunk

# 2. 确认 Native VLAN 不是默认的 VLAN 1
# VLAN 1 跳跃攻击（VLAN Hopping）利用默认 Native VLAN

# 3. Linux 上查看 VLAN 接口
ip -d link show type vlan

# 4. 确认 VLAN 间路由有 ACL 控制
iptables -L FORWARD -n -v | grep -i vlan

7.2 Kubernetes Network Policy 验证

# 1. 确认 CNI 插件支持 Network Policy
kubectl get pods -n kube-system | grep -iE "calico|cilium|weave"

# 2. 列出所有 Network Policy
kubectl get networkpolicy --all-namespaces

# 3. 检查是否有 default-deny 策略
kubectl get networkpolicy -n production -o json | \
    jq '.items[] | select(.spec.podSelector == {}) | .metadata.name'

# 4. 测试策略是否生效
# 从 frontend Pod 测试到 backend
kubectl exec -n production deploy/frontend -- \
    curl -s -o /dev/null -w "%{http_code}" http://backend:8080/health
# 期望：200

# 从不相关的 Pod 测试（应被拒绝）
kubectl exec -n production deploy/logging -- \
    curl -s -o /dev/null -w "%{http_code}" \
    --connect-timeout 3 http://backend:8080/health
# 期望：超时或连接被拒绝

# 5. Cilium 策略验证
cilium policy get -n production
cilium monitor --type policy-verdict -n production

7.3 隔离有效性持续验证

# 定期扫描——检测策略之外的异常通信

# 使用 Hubble 检查被策略丢弃的流量
hubble observe --namespace production --verdict DROPPED --last 100

# 使用 Calico 日志检查被拒绝的连接
kubectl logs -n calico-system -l k8s-app=calico-node --tail 100 | \
    grep -i "denied\|dropped"

# 网络策略覆盖率检查
# 统计有 Network Policy 覆盖的命名空间
for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do
    count=$(kubectl get networkpolicy -n "$ns" --no-headers 2>/dev/null | wc -l)
    echo "$ns: $count policies"
done

7.4 常见陷阱

八、隔离方案选型

参考文献

1. IEEE 802.1Q-2022, “Bridges and Bridged Networks,” IEEE Standards Association.
2. RFC 7348, “Virtual eXtensible Local Area Network (VXLAN),” IETF, 2014.
3. Kubernetes Documentation, “Network Policies,” kubernetes.io/docs.
4. Project Calico, “Calico Network Policy Documentation,” docs.tigera.io.
5. Cilium Documentation, “Network Policy,” docs.cilium.io/en/stable/network/kubernetes/policy.
6. Rose, S., et al., “Zero Trust Architecture,” NIST SP 800-207, 2020.
7. Ward, R., and Beyer, B., “BeyondCorp: A New Approach to Enterprise Security,” Google, 2014.
8. Gilman, E., and Barth, D., “Zero Trust Networks,” O’Reilly Media, 2017.

上一篇: VPN 技术工程对比：IPSec vs WireGuard vs OpenVPN 下一篇: 网络取证：流量分析、异常检测与事件响应