諺
云中的网络相关介绍
2022-01-03 / modified at 2023-02-20 / 1.9k words / 7 mins
️This article has been over 1 years since the last update.

最近接触了私有云相关的应用方案部署设计，将部分云上的网络知识记录。

常见网络定位工具

掌握了下面功能，基本上可以协助网络层进行定位。非渗透场景，仅供常见问题定位。

  • 大部分场景使用tcpdump -i any与traceroute 进行VM层的定位即可，还可以将多个pcap包合并后放到wireshark中进行分析
  • 活用nmap，在合规的前提进行各种流量测试
  • 使用iperf进行速度与延迟测试，尤其是验收软交换性能
  • 尽可能不要碰上游硬件与拓扑，那是一个对时间与经验要求很高的工作

IP协议介绍

什么是IPV4协议

虽然有很多课本教程，最好的方法是学习专业设备的文档。

ARP协议

ARP是指 （IP）地址解析（为Mac）的协议，这个在真实网络（三层交换）中一般不会有奇怪的问题，但是软考中经常出现。

此外，它经常与虚拟IP一起使用，比如LVS/pgpool等。

路由器与交换器

下面是在网络工作中的命名

  • 核心/汇聚层交换机：拥有三层交换功能，一般一个小机房需要一个小的核心交换机，型号比如CE6800，实现了IP转发、路由表，DHCP等功能。跨PM（物理机）的流量需要经过这里。
  • 接入层交换机：只有二层交换功能，比如放在每个机柜的上面（即TOR）互为主备，最主要优势是简化了连线
  • 路由器：在网络领域中一般不在机房中被特指，一旦被使用时特指昂贵的大型设备，比如NE9000

上述设备即使安装后，也一般不会直接使用，而是首先基于这些设备实现网络虚拟化，然后再交给上游的SDN/云软件。这些设备一般需要专人维护，最好当作虚拟后的黑盒来看待。

路由协议的工作流程

路由协议通过路由表进行IP包转发：目的地的、下一跳（网关）、出接口

  • 路由器不需要认识所有远程网络，一般会转发给下一跳
  • 下一跳一定要有路由处理能力（比如核心交换机，或者通过iptable搭建的软路由），需要在同一个物理链路下
  • 非NAT场景下，路由器只会转发IP包，而不会修改IP包的内容（连from和dest也不会改）。

应用程序侧是不需要分清"下一跳"与"目标地址"
路由表：除非PPTP等点对点场景，都不应该在VM层配置路由表，否则运维负担太大。

VPC介绍

什么是VPC

VPC是虚拟私有云，比如你购买了一个172.16.0/24的VPC，当申请完成后，相当于买了一个软件定义的网络，即SDN，它拥有

  • DHCP功能（广播后返回给客户端的路由网关/IP/DNS等）
  • IP包转发功能（客户端IP的下一跳也是这里，一般也支持配置静态路由表）
  • Edge/网关等功能，比如SNAT/DNAT/EIP-NAT/ELB，注意需要区分托管的NAT网关和自己用虚拟机搭建的NAT实例。广义上托管的实例（比如APIGW）不归属于VPC
  • 安全组与ACL功能（基本的三层/四层防火墙，不能承担OWASP的七层安全服务，可以被主动部署frp等工具穿通）

VPC底层如何实现

取决于厂商架构，一般有两个方案

  • 基于OpenStack的软路由实现，需要一定比例的物理机作为软交换，性能较弱，同时导致机房密度降低，而且隧道加解封的运算经过CPU，导致时延上升。在这种场景使用虚拟机traceroute外网，可能发现前两跳丢失，因为走的是等价路由。
  • 基于智能网卡（比如IN5500）或硬件交换机实现流量卸载（offload），比如RoCE网络，缺点就是网卡很贵，但是它是未来数据中心的趋势。

网络出口方案

使用IPTable实现简易网关出口实例

在某些场景下（比如双网卡/加密/去广告等）可能需要将某台Linux物理机器作为软路由使用。简单场景可以用IPTable，复杂场景可以使用OpenWrt等专业OS。

建议基于旁路部署，配置VPC路由器下的静态路由表，将外网IP段的下一跳配置为软路由机器，这样这台软路由仅作为接入的网关使用，没有内部转发的压力

如下是SNAT && MASQUERADE的例子，SNAT将IP包中from的包改为新的地址

1
2
3
4
5
6
7
modprobe iptable_nat
echo 1 > /proc/sys/net/ipv4/ip_forward
# 所有from地址匹配`192.168.1.0/24`的出流量将通过eth0，并修改为外网IP，然后外发
# way1. 主动配置IP
iptables -t nat -s 192.168.1.0/24 -A POSTROUTING -o eth0 -j SNAT --to-source <外网IP>
# way2. 自动分配，但是大部分场景都是固定IP，更推荐
iptables -t nat -s 192.168.1.0/24 -A POSTROUTING -o eth0 -j MASQUERADE

配置完成后，需要在云VPC的设置界面配置静态路由指向这台机器，并开通ACL策略。此外在云机器中，可能在"网卡硬件"的设置中配置rp_filter，需要关闭。

注意私自搭建NAT以突破边界可能是开除级别的安全违规操作。

使用防火墙实现出口

这个涉及到防火墙引擎，只能买商业平台或者开源的opnsense等软件。

网络进口方案

ELB

很成熟的方案，跳过

DNAT

除非特别需要（比如节约公网IP），一般的Web场景不推荐自己搭建软路由做NAT，而是推荐替代方案如下

  • 云服务：Web服务场景一般使用ELB，反而DNAT缺少各种健康检查/负载算法而不会被使用（即使ELB在TCP场景下仍然通过DNAT实现）。TCP代理可以拿到用户侧的真实IP；而在HTTP场景下一般会提供真实IP的Header。
  • 软路由：更推荐使用L7的负载均衡，只用来DNAT转发有点浪费，肯定比不过专用硬件。

应用层入口的网格方案

以下方案，从中小团队的角度来说划不来，因为它对开发者的网络控制面的运维能力（安全加固/私钥存储/跨AZ高可用）要求太高了，而收益却很有限。到目前为止，我看到云原生与Service Mesh就很头大。这种潮流方案的半衰期很短，除非是裸金属部署，否则这种软件封包方案后期必然会被云服务的专用硬件给成本压制。

Calico

通过配置Router和IPTables，不需要overlay封包开销也能实现虚拟化。通过etcd进行控制域的管理。在最常见的云K8S场景中，云厂商更偏向使用私有的硬件方案以提高机房密度。

Consul Connect & Nomad CNI

基于connect隧道实现TLS，当前对用户来说还是比较尴尬，因为它和Nomad混合在一起后的容器方案，部署与维护的难度和K8S也差不多了。

Traefik

这个方案很不错，既可以当作简化的带GUI的Nginx，也可以实现各种维度的AOP，甚至Mesh。普通开发能快速上手。

QA

可以伪造源IP以绕过firewall吗？

可以伪造（比如静态IP），但是可以用urpf等技术处理。参考：https://saucer-man.com/network/629.html