我可能需要在中心辐射型设计中添加（启动）10 个 IPSec 隧道，而通信是单向的（仅辐射 -> 中心），目的是在中央数据库服务器中收集数据。每个事务都很小，可能是 10Kb 的 XML 数据，每个辐射每小时可能发起 10-20 个事务。另外我应该注意，我无法控制辐射网络；所有辐射都有一个静态的、可公开路由的 IP 地址；所有辐射实际上只是 NAT 防火墙后面的主机，需要将数据发送到中央数据库。中央数据库位于 NAT 防火墙后面，为了讨论的目的，位于 192.168.0.0/24 子网上。
我最初的想法是 IPSec 隧道是开销大/过度的，因为我必须考虑每个辐射的网络拓扑（我无法控制）以及路由，更不用说维持所有这些 IPSec 隧道所需的硬件（特别是如果它扩展到数百个）。
然而，有人“敦促”我使用 IPSec 隧道，因为它们最“安全”，但在我看来，我觉得 IPSec 非常适合大型可信网络，甚至分支机构之间大多数可信的 LAN 到 LAN 通信，特别是当您完全控制网络拓扑时，但并不适用于非常狭窄的用途，而且（我认为）可以通过 SSH 隧道或 SFTP 批处理作业（或可能是按需/移动 VPN？）之类的方式来实现。
如果我必须使用 IPSec，我该如何处理路由？我的意思是，如果我的中央数据库位于 192.168.0.0/24 子网上，而分支 A 恰好有相同的子网（或者可能在其他地方有另一个隧道），我该如何解决这个问题？每个“发送”主机上的静态路由可能会起作用，但如果该主机需要访问其他地方的同一子网怎么办？
如果不是 IPSec，您会建议什么来确保从对等点到中央主机的交易安全？
答案1
我曾经经历过这种情况——签约成为一家大公司的众多合作伙伴之一，我们必须建立 IPSec 隧道。它的工作方式是：
- 我收到一份表格，详细说明我的网络布局，包括哪些子网需要访问我们的新大合作伙伴
- 他们发送了一个预先配置好并完全锁定的 VPN 设备
- 我已经为它分配了一个公共 IP，所以我将它插入可以使用该 IP 的地方
- 我的公司向 Sprint 支付了少量费用来管理它
我知道隧道仅锁定在应用程序所需的端口上。
对于您来说，就您的职位而言，要点是：
- 如果可以的话，可以把这件事外包出去。有些公司可以为你负责实施和管理
- 如果你自己做这件事，你将需要实施一个坚如磐石的流程来吸纳新合作伙伴
- 你还应该对客户端硬件进行标准化
另一个要点 - FFS，只需使用安全协议。SSH/SFTP/HTTPS 都是标准且极其安全 - 例如，有符合 FIPS 标准的 SFTP 服务器。
通过 IPSec 隧道进行此操作要么会浪费您团队的时间（也就是金钱），要么只会浪费网络管理合同的钱。如果您的企业无法从新合作伙伴那里获得回报，那么一开始就确保产品/流程的安全即可。
如果您陷入这种情况，请不要自己动手，因为您最终将不得不支持每个拥有 SOHO 路由器和一些喜欢 BitTorrent 的人的小商店，并且当路由器出现问题时，他们会打电话给您，了解您的应用程序为何会宕机。
此外，您处理重叠私有 IP 子网的具体问题可以通过额外的复杂 NAT 来解决，您也必须维护它。这绝对不是什么大问题，只是需要做更多的工作。