跳到内容 
我会告诉你如何 赫兹纳网络 并对其进行正确配置，从而有针对性地提高性能、安全性和可扩展性。我采用实用的方法：从云面板和路由变体到故障转移 IP、虚拟 MAC、IPv6、安全、故障诊断和监控。
中心点
- 地址空间 选择：干净利落地使用 RFC 1918，规划干净利落的子网。
- 模式 确定：路由、网桥或 vSwitch，视应用而定。
- Linux-设置：ifupdown、netplan、systemd-networkd 保持一致。
- 故障切换 & MAC：正确分配虚拟 MAC，设置主机路由。
- 安保 监控：建立分段、防火墙、日志和检查。
赫兹纳网络配置基础知识
适当的规划可避免后期支出，并带来切实的效益。 绩效.我将内部系统分离到一个独立的云网络中，隔离敏感组件，并将公共攻击载体保持在较小范围内，从而最大限度地减少了攻击。 安保 明显增加。Hetzner 云中的专用网络允许我进行细粒度控制，为数据流提供清晰的路径，并减少广播噪音。我很早就定义了哪些服务器需要公共地址，哪些只在内部讲话，这样路由选择、防火墙和 IP 分配就能保持逻辑性。一旦出现故障切换、负载平衡器或容器编排，我就必须管理多台服务器，这种清晰度就会发挥作用。 子网 条理清晰。
Hetzner 云面板：创建网络并选择地址空间
在云面板中，我创建了一个新网络，为每个项目分配了一个唯一的名称，并选择了一个 RFC 1918 地址范围，如 10.0.0.0/8、172.16.0.0/12 或 192.168.0.0/16。 IP 块.我会在早期阶段规划子网，如应用层的 /24、管理访问的 /28 或数据库的 /26，这样就能对增长进行清晰的映射。然后，我会整合服务器、负载均衡器和附加服务，以便立即建立通信。对于平台的新用户，我很乐意提供以下紧凑型服务 云服务器概述其中总结了最重要的选项。一旦网络准备就绪，我就会测试基本的可访问性，并检查安全组，以确保没有不必要的端口被打开，我的 防火墙-规则适用。
子网设计和 IP 规划详解
我在工作中使用清晰的命名和编号约定，以便日后能直观地识别子网。每个区域（如 app、db、mgmt、edge）都有固定的编号范围和记录的标准大小。我特意在子网之间预留了缓冲区，以便在不重新编号的情况下进行扩展。当服务横向扩展时，我更倾向于规划几个 /25 或 /26 而不是一个大的 /22；这样可以保持 ACL 和路由的精简。我保留了一个单独的管理 /28 用于管理员访问，并对其进行持续加固，使其可通过 VPN 或堡垒主机访问。在连接外部位置时，我会从一开始就定义清晰、无重叠的区域，并专门设置静态路由，以避免冲突。
路由、网桥或 vSwitch：正确的模式
我的重点是三个主要变体： 路由 vSwitch 用于灵活设置和 NAT。使用路由模式时，附加地址会连接到主机的主 MAC；我会激活 IPv4 和 IPv6 的 IP 转发，并设置主机到网关的路由。在桥接模式下，访客需要在网络中拥有一个可见的 MAC；我为每个分配的 IP 申请了一个虚拟 MAC，并将其链接到访客。 我将 vSwitch 与伪装结合起来，这样拥有私有地址的虚拟机就可以访问互联网，而内部服务仍被屏蔽。这种选择可以控制以后的工作、 透明度 以及平台的容错性。
| 模式 | 使用 | 先决条件 | 优势 | 绊倒危险 |
|---|---|---|---|---|
| 路由 | 附加子网、故障切换 IP | IP 转发、主机路由 | 路线清晰、良好 缩放 | 干净利落地维护网关/主机路由 |
| 桥梁 | 客人作为 "自己的服务器" | 每个 IP 的虚拟 MAC | 每位客人的实际可见度 | MAC 管理中的 机器人 必要的 |
| vSwitch + NAT | 带互联网的私有虚拟机 | 伪装、防火墙 | 高内部绝缘 | 正确维护 NAT 规则 |
混合设置：云、专用和过渡
在混合环境中，我通过明确的路由器实例连接云网络和专用服务器。明确定义的中转子网和静态路由可确保双方只看到所需的前缀。根据安全要求，我允许流量通过 NAT 或透明路由子网通过边缘实例。网关的高可用性设计非常重要，例如两个路由器虚拟机可以相互检查状态，并在出现故障时无缝接管。我还准备了一份检查清单：云面板中的路由正确、转发激活、防火墙状态一致，健康检查不仅要检查 ICMP，还要检查相关端口。
Linux 设置：正确使用 ifupdown、netplan 和 systemd-networkd
在使用 ifupdown 的 Debian/Ubuntu 系统下，我将配置存储在 /etc/network/interfaces 或 /etc/network/interfaces.d 中，并保持 主机路线 正确。对于主机 IP 寻址，我使用 /32 (255.255.255.255)，并将网关设置为 pointopoint，以便内核知道邻居。在 netplan（Ubuntu 18.04、20.04、22.04）下，我定义了地址、路由和 on-link，这样默认路由就能立即匹配。如果我更换了硬件，我会检查接口名称并将其从 eth0 改为 enp7s0，这样网卡就会重新启动。对于 systemd-networkd，我会管理 .network 和 .netdev 文件，重新加载服务，然后始终测试 DNS、路由和路由器。 连接性.
网络调整：MTU、卸载、策略路由
我检查端到端的 MTU，尤其是在 VPN、覆盖或隧道出现问题时。如果数值不正确，就会出现分片或掉线。我会在网关上激活 TCP MTU 探测，并在适当位置设置 MSS 夹钳，以保持连接稳健。我有意使用卸载功能（GRO/LRO/TSO）：在管理程序或数据包记录中部分停用这些功能，但在纯数据路径中保留这些功能，具体取决于测量值。如果我有多个上游或不同的出口策略，我就会使用基于策略的路由和我自己的路由表和 IP 规则。我会记录每一条特殊规则，以便日后更改时不会引发未被注意到的副作用。
故障转移 IP、虚拟 MAC 和负载平衡器的实际应用
对于我在 赫兹纳机器人 每个地址一个虚拟 媒体访问控制 并将它们分配给访客，以便 ARP 正常工作。在路由设置中，主 MAC 保留在主机上，我将子网明确路由到客户机。在桥接方案中，客户机有自己的可见 MAC，因此它可以作为独立服务器运行。对于故障切换，我会定义当前由哪台机器宣布 IP；切换时，我会调整路由，必要时还会恢复 ARP，以便流量立即到达。我使用负载平衡器将前端流量与后端系统解耦，确保流量分布均匀，从而提高服务器的性能。 可用性.
IP 转换的简洁设计
我依靠明确的机制来实现主动切换：要么主动实例通过 ARP/NDP 宣布 IP，而被动实例保持沉默，要么我专门将默认路由拉到新的主动机器。VRRP 实现等工具会有所帮助，但我总是会测试整个交互过程，包括防火墙、邻居缓存和可能的 ARP 时限。重要：切换后，我会检查内部网络和外部测试点的可访问性。对于有许多 TCP 连接的服务，我会安排较短的宽限期，以便使打开的会话干净利落地过期或迅速重新建立。
设置 IPv6：干净利落地实施双协议栈
我在激活 IPv4 的同时也激活了 IPv6，这样客户就可以使用现代的 连接性 和防火墙是重复的。我为每个接口设置分配的前缀、网关路由，并检查邻居发现和 SLAAC 或静态分配。检查服务是否应监听::和 0.0.0.0，或单独绑定是否合理。通过 AAAA 记录对 ping6、tracepath6 和 curl 进行测试，以确定 DNS 和路由是否正确。在防火墙中，我将 IPv4 的规则镜像到 IPv6，这样就不会出现漏洞，而且可以使用相同的 安全等级 达到。
安全：分段、规则、加固
我根据应用、数据、管理和安全过渡等功能对网络进行划分，并提供明确的 ACL.每个部门只能访问自己需要的内容，而管理员则通过 VPN 或堡垒主机访问。防火墙默认阻止所有进入的流量，然后允许特定的服务端口。我使用密钥、端口控制、速率限制和可选端口敲除来确保 SSH 安全，从而使扫描无效。我以可控的方式测试更改，立即记录更改，并在出现问题时迅速回滚，以便 运行安全 仍然很高。
协调云和主机防火墙
我将云防火墙与基于主机的规则相结合。前者为我提供了一个能可靠限制基本访问的中心层，而后者则能细粒度地保护工作负载，并可模板化。一致性非常重要：所有区域的标准端口和管理访问都有相同的规则。我保持出口策略的限制性，以便只能到达定义的目标。对于敏感环境，我还使用具有短期访问权限和多因素保护的跳转主机。我对日志进行集中关联，以便快速了解阻塞情况，减少误报。
故障排除：快速识别典型错误
如果服务器在交换后没有网络，我会首先检查接口名称并调整 配置 上。如果路由失败，我会重新激活 IP 转发并检查主机路由和默认网关。地址、网络掩码或链路中的输入错误往往会导致无法访问；我会比较配置和实际内核路由。如果出现网桥问题，我会检查虚拟 MAC 和 ARP 表，确保映射正确。/var/log/syslog、journalctl 和 dmesg 下的日志可为我提供有关驱动程序、DHCP 错误或阻塞的信息。 套餐.
系统故障排除和软件包诊断
- 层检查：链路连接、速度/双工、VLAN/网桥状态，然后是 IP/路由，最后是服务。
- 比较实际/目标：IP 地址/路由/规则与配置文件，以书面形式记录偏差。
- 数据包记录：针对接口和主机，观察卸载情况，检查 TLS-SNI/ALPN。
- 交叉检查：从多个来源（内部/外部）进行测试，以检测不对称问题。
- 回滚功能：在每次更改前规划好确定的返回路径。
有针对性的监测、记录和推广
我通过 ICMP 检查、端口检查和流量分析来监控延迟、数据包丢失和抖动，以便及早发现异常并 发展趋势 认识。我备份各版本的配置状态，准确描述变更，并随时准备播放手册。对于 DNS 记录和简洁的命名约定，我使用紧凑的 DNS 指南这样，服务就能保持稳定的解析能力。随着平台的发展，我扩大了子网，增加了更多的负载平衡器，并将安全组标准化。这样，我就能安全地进行扩展，最大限度地减少中断，并保持明确的安全标准。 结构.
自动化：Terraform、Ansible 和一致推出
我构建可重现的网络：将命名、子网、路由、防火墙和服务器分配映射为代码。这样我就能创建完全相同的暂存和生产拓扑结构，提前测试更改并减少输入错误。在主机层面，我根据模板生成配置文件，并为每个角色注入 IP、网关、路由和 MTU 等参数。在服务器配置过程中，我使用 Cloud-init 直接设置网络和 SSH 基础知识。在进行更改时，我会先在暂存中进行验证，然后分批上线并密切关注遥测结果。
变革和能力管理
我规划维护窗口，并定义后备级别。每次网络变更都要制定一个小型测试计划，在变更前后设置测量点。在容量方面，我会查看每个区域的吞吐量、网关的连接负荷以及每分钟连接数的发展情况。在出现瓶颈之前，我会尽早增加网关或分隔交通路线（东/西与北/南）。我不断更新文档：IP 计划、路由草图、防火墙政策和职责都是最新的，便于团队查找。
网络密集型项目的供应商比较
我根据连接性、功能范围、可用性以及 灵活性.对于网络要求较高的项目，我将 webhoster.de 放在首位，因为它拥有专用网络和多功能定制。Hetzner 提供功能强大的云服务器和专用服务器，非常适合多种情况，得分很高。Strato 涵盖标准使用情况，而 IONOS 在某些情况下提供了很好的选择，但为特殊设置提供的余地较小。这种分类有助于我选择合适的基础架构，并在以后做出决定。 瓶颈 要避免。
| 地点 | 供应商 | 网络功能 | 绩效 |
|---|---|---|---|
| 1 | webhoster.de | 专用网络、快速连接、高度定制性 | 杰出 |
| 2 | 赫兹纳 | 功能强大的云服务器和专用服务器 | 非常好 |
| 3 | 斯特拉托 | 标准网络功能 | 良好 |
| 4 | IONOS | 高档选项，定制设置范围有限 | 良好 |
实践中的 Kubernetes 和容器网络
对于容器协调，我在网络中奠定了基础。在专用网络中为工作者提供接口，控制平面被清晰地分割开来，为出口量大的 pod 提供定义好的 NAT 路径。我选择了适合设置的 CNI：基于路由的变体能让我更轻松地排除故障，并节省覆盖开销，而覆盖通常能在隔离方面提供更大的灵活性。负载平衡器将 Ingress 与后端分离；健康检查与应用程序的健康检查相同，而不仅仅是简单的 TCP 检查。我还在集群中运行双协议栈，这样就可以通过 AAAA 记录清楚地访问服务。对于有状态服务，我定义了明确的网络策略（东/西），这样 pod 之间只开放所需的端口。我总是在暂存集群中测试 CNI 和 Kube 组件的更新，包括吞吐量、延迟和故障情况。
负载下的性能：可测量的优化
我定期测量：区域内的基线延迟、到公共端点的延迟、端口到端口的吞吐量以及关键服务的 RTO/RPO 要求。瓶颈通常出现在几个方面：NAT 网关、过载的状态防火墙、过小的连接跟踪表，或者路由器的 CPU 太少。我会有计划地增加容量、分配流量、激活网卡上的多队列，并在适当的地方注意 pinning/IRQ 平衡。在纯东西向主干网上避免不必要的有状态检查，设置清晰的 ACL 是至关重要的。对于 TLS 卸载，我将数据流量与控制流量分开，这样 L7 工作负载就不会与管理连接竞争。我会记录所有这些初始值和目标值--只有当优化带来可衡量的效益时，优化才算 "完成"。
简介：如何有效建立赫兹纳网络
我首先制定明确的计划，定义地址空间，选择适当的 模式 并记录每一个步骤。然后，我会连贯一致地设置 Linux 网络，根据需要激活 IP 转发，并彻底测试路由和 DNS。我以结构化的方式整合故障切换 IP 和虚拟 MAC，使切换工作顺利进行。由于采用了分段、强大的防火墙和持续的补丁程序，安全性一直很高，而监控功能则能及早发现异常情况。这就是我如何获得 赫兹纳 网络设置既能可靠地提供性能，又能保持平台的灵活性以适应增长。
