共计 1982 个字符，预计需要花费 5 分钟才能阅读完成。
背景
站内文章：使用 socks5 代理网络流量 曾提到过，怎么使用 socks5 来实现应用侧的代理出海加速。
近期业务侧有需求，需要在国内华为云的某北京 region 下稳定访问海外的一些服务，例如 Google、AWS、微软等公司提供的服务。
众所周知，从国内直接访问海外，数据包往往会被QOS，对于业务侧来说稳定性无法保证。
而此次业务侧提出的需求更为复杂，他们有两个加速需求：
- A类应用可进行改造，请求可以通过代理转发
- B类应用无法进行改造，请求不可以主动链接代理转发。在访问海外服务，例如微软的 exchange 时，期望应用侧流量能直接走专线出海，不进行任何代理配置。
由于发起需求的业务侧region下的VPC是多部门混用，还需注意变更的影响只能限定为发起团队的业务部门，不可以影响整个VPC。
最终确定会用两种方式来实现加速：
- 对于可主动链接代理的应用，用之前所说的 socks5 即可以实现加速。
而对于不能动链接代理的应用，这次会尝试利用其他手段来实现。
同时，前文 使用 socks5 代理网络流量 中，并未详细说明如何配置云连接，本文这次会补充上相关实现。
逻辑分析
最终的逻辑图如下：
| 资源 | CIDR | 备注 | |
|---|---|---|---|
| 华为云北京VPC A | 10.0.0.0/16 | 现有VPC。业务侧现有应用部署在此VPC。 | |
| 华为云北京VPC B | 10.1.0.0/24 | 需新建VPC。业务侧代理节点部署在此VPC。 | |
| 华为云香港VPC C | 10.1.1.0/24 | 现有VPC。用于出海加速。 | |
| 对等连接 | – | 用于同region下VPC联通。 | |
| 云连接 | – | 用于跨region下VPC联通。 | |
| NAT网关 | – | 用于指定VPC的公网出口。 |
可能读者会有疑问，为什么需要在北京新建VPC B，而不是直接使用云连接拉通A和C呢？
下面将问题拆解，实际上我们需要同时解决三个事儿：
- 如何通过专线拉通 北京和香港，解决数据包在内网流转时使用专线加速？
- 如何实现应用侧无需改造，在北京通过公网域名访问 微软exchange 时使用专线加速？
- 北京VPC A 不仅是提出需求的业务方在使用，还有其他业务方使用，如何确保其他业务不受影响？
解答：
对于 问题1，只需要新建香港VPC C，和 北京VPC A联通就好，为什么要新建VPC B呢？其实是为了解决问题2和3。
对于 问题2，由于微软exchange服务提供了域名给业务侧连接，而域名具体解析的IP我们是无法得知的。由于业务侧无法改造主动链接代理，所以我们只能从路由表入手。而路由表上只能配置IP。无法配置域名。所以只能将所有出公网的流量通过添加粗路由 ，将 0.0.0.0/0 指向云连接，即所有流量使用云连接走到香港，再通过香港的SNAT出口出公网。
对于问题3， VPC A是多业务部门混用的VPC，我们不可能去修改0.0.0.0/0的路由，影响其他业务。所以需要创建VPC B，专门提供给此次发起需求的业务侧来使用，实现控制影响面。
综上。为了在控制影响范围的情况下，我们需要新建两个VPC。B用于单一业务部署代理和中转流量，控制影响面。C用于控制最终的公网出口。
底层网络由SRE配置，业务侧只需要在VPC B上部署应用以及代理：
- 对于业务侧现有在VPC A的应用出海加速，需主动链接VPC B 的代理
- 对于业务侧无法配置主动连接代理的应用，需将应用部署在VPC B。VPC B 的所有出公网流量其实都会自动走香港SNAT出口。
具体实现
- 新建 北京4 VPC B 10.1.0.0/24 和子网 10.1.0.0/27
- 新建 香港 VPC C 10.1.1.0/24 和子网 10.1.1.0/27
- 新建 对等连接，拉通 北京4 VPC A 10.0.0.0/16 和新建的VPC 10.1.0.0/24
在 10.0.0.0/16 路由表下添加 下一跳路由：10.1.0.0/24，设备为对等连接
- 新建云连接，并绑定5Mbps带宽包
-
云连接配置拉通 北京4 新VPC 10.1.0.0/24 和 香港 新VPC 10.1.1.0/24
云连接自动下发默认路由
云连接侧配置香港区其他子网为 0.0.0.0/0，用于指定北京新VPC 粗路由全流量通过CC指向香港
- 香港 新VPC 10.1.1.0/24 新建 SNAT 出口，并绑定IP。用于配置该VPC的全局公网出口
- 北京4 新VPC子网 创建测试机，用于验证北京新VPC下的 ECS 公网流量会全部指向香港SNAT出口。验证已通过。
- 业务侧申请服务器进行加速验证
优势与缺陷
优势：
- 新建VPC B 可确保代理业务不会影响到其它业务
- VPC B下的所有出公网流量均会被路由到香港出口，无论是访问微软exchange 或者其他流量。无需业务侧做任何改造。
缺陷：
- VPC B下的所有出公网流量均会被路由到香港出口，会导致部分不应该被加速的流量也被绕行到香港。由于此次需求业务侧确认过应用没有其他的公网需求，故忽略。
总结
还是那句老话，方案没有明显的优劣之分。
针对不同的场景选择更为适合的手段即可。但是一定确保控制影响面，不要干扰正常业务。
