因长度限制，只能分成2个贴发。
重大突破，解决Hetzner Spaceberg等一众欧洲商家重装难问题 2
https://91ai.net/thread-1191828-1-1.html
论坛主贴：
https://91ai.net/thread-1159839-1-1.html
github：
https://github.com/leitbogioro/Tools
图库为 imgur.com，国内用户需挂梯子全局才能查看。
省流版：
Hetzner、Spaceberg、tk-hosting 等一大众欧洲商家双栈机，IPv4 公网 + IPv4 内网网关这种组合，脚本可启用 IPv6 优先策略连接到源并装好系统，并在安装后期把 IPv4 地址写进去，保证重装后双栈都能正常工作，此策略适用于 Debian/Kali。
红帽系 8 9 支持原生 IPv4 公网 + IPv4 内网网关这种组合配置网络，所以测试通过适用的系统为：
Debian 12
Kali rolling
AlmaLinux 8 9
RockyLinux 8 9
CentOS Stream 8 9
Fedora 37 38
AlpineLinux 由于原生启动仅支持 IPv4 配置，且其临时环境为和 Debian installer 相同的 busybox，所以无法通过先配置 IPv6 再配置 IPv4 的方法来解决，并且 Ubuntu 也是基于用 AlpineLinux dd 实现，所以以上这些欧洲商家机型无法顺利重装成 AlpineLinux Ubuntu。
脚本无法重装成功的系统：
Debian 11 及以下
CentOS 7
AlpineLinux 全系
Ubuntu 全系
近期大量改进，更新详情：
支持 Debian/Kali，红帽系（CentOS AlmaLinux RockyLinux Fedora）多盘 raid 0 1 5 6 10。
添加 -windows 参数，可指定 10 11 2012 - 2022 来安装来自秋水逸冰制作的 Windows 镜像 dd，并支持自动配置静态 IPv4，自动扩展主分区解决了无法重装为 AlpineLinux 3.16 3.17 的问题；重装前脚本会根据 IPv4 IPv6 主 IP 和 网关段对比，算出一个临时掩码，并记录系统实际掩码，临时掩码仅用于通过 Debian 安装检测，装好后会将实际掩码替换回去；对于有些需要搭建网桥的用户，可以指定 --autoplugadapter 参数，把 Debian 中 allow-hotplug 改为 auto，避免搭建网桥重启后连接失败，但此项会导致部分机型重启后因对每张网卡都尝试使用 dhcp 配置，直到超时后再尝试下一个，造成启动时间过长。有些机型采用 eth0 配置 IPv4、eth1 配置 IPv6，脚本目前安装 Debian 时也能正确分别对其配置；自动识别系统中通过 warp 实现的网络栈，并将其排除，比如一些靠套 warp 实现 IPv6 访问的 IPv4 机器，只保留机器自带的 IP 栈，避免重装时写入错误网络配置。修复 Fedora 源失效问题；优化硬盘判断逻辑，排除系统内被挂载成 iso 光盘的 /dev/sda 硬盘（本来应该靠挂载 /dev/sr0 实现），避免将系统装到光盘设备中造成安装失败；改善了失去主流支持的老 Debian 版本，如 Debian 9，因连接 Debian 源出错造成依赖安装失败问题，脚本会自动将源改为 archive.debian.org，如果你坚持要安装 Debian 9 及更旧系统，脚本不会从 security.debian.org 获取更新，避免出现安装旧 Debian 版本无法获取更新弹红框的情况；优化用户时区判断逻辑，不再依赖同一家 IP 归属地查询商；改善判断国内国外逻辑，如果发现 ping IPv4/IPv6 到 有图比 wikipedia instagram bbc 全部失败，才判断为机器在国内，并适配与其相应的国内源、dns 等。
本期主题正文：
Linux一键重装在众多坛友的反馈下，不断改进和优化，近半年时间以来，有一大问题一直在困扰着我，那就是大名鼎鼎的“unreachable gateway”，症状如下：
简单来讲，这个红框出现的原因，是 Debian 安装程序配置网络时，根据主 IPv4 地址和掩码，计算出一个属于内网的 IPv4 地址范围，如果发现网关不在其中，就会返回该错误。
这个问题仅在 Debian/AlmaLinux 等采用 busybox 环境的 Linux 安装阶段出现，如果该系统已安装到硬盘，按此配置不会有问题。
举一个例子，该机器来自 tk-hosting：
主 IPv4 ：89.163.208.10
掩码：255.255.255.0 （简写 24）
网关：169.254.0.1
用 vultr 的 IPv4 子网计算器（https://www.vultr.com/resources/subnet-calculator/ ）计算一下该机器的地址范围为：89.163.208.0 - 89.163.208.255
显然，169.254.0.1 不在其中，所以 Debian 安装程序会报错，此问题同样也会影响到 Hetzner（主 IPv4 公网，网关 172.31.1.1）、Spaceberg（主 IPv4 公网，网关 192.168.4.1）等一众欧洲云服务商家。
这类商家有个很明显的特点，就是统一公网 IPv4 + 内网网关配置，仿佛它们后台技术都是同一个师父教的，这种网络配置风格，跟其他各国云服务商家普遍支持 dhcp、主 IPv4 内网地址（由路由映射到公网 IPv4，可通过 dns 查询到） + 同 A B C 类内网网关，或主 IPv4 公网地址 + 同 A B C 类公网网关迥然不同。
这种配置风格对网管来说可能比较省事（所有机器网关都一样），但对需要拿来用脚本重装的我们来说是一个大麻烦。这意味着我们不能把系统里原带的 IPv4 配置直接写到 Debian preseed.cfg 里，否则你就会碰到和我一样的令人头疼的红框。
这个问题令人魂牵梦萦，我至少尝试过 4 种方法来解决：
1. 给大掩码，如
主 IPv4 ：89.163.208.10
掩码：128.0.0.0 （简写 1）
网关：169.254.0.1
这样机器承认的内网地址范围就变成了：0.0.0.0 - 127.255.255.255，显然，如果机器网关是 172.31.1.1，它是在这个范围内的，但对于 169.254.0.1，169 还是比 127 大，还是无法被包含其中，所以这个办法并不高明。
掩码的设置是一个需要谨慎考虑的工作，它指定了计算机和哪些范围的 IP 地址当做内联通信，把除前述之外的 IP 地址当做外联通信。这个范围如果过大（简写值更小），会造成很多与公联通信的计算机被当做内联通信，造成通信失败；如果这个范围过小（简写值更大），会造成与部分内联通信的计算机当做公联通信，造成内联通信丢失。
所以即使给 1 侥幸逃过 Debian 安装程序的网络检测，但如果恰好 Debian 源在掩码规定的内联通信范围内，那么会造成连接源失败，有时候同一地区的源，十有**都会连接失败。
所以不到万不得已，千万不要随便给掩码值，我最初解决这个问题的时候，就是尝试用这种方法，显然这并不高明。
另外，如果把掩码设置成 0，倒是可以彻底解决网关不在内联通信范围内这个问题，但所有 IPv4 地址都被当做内网来通信了，这种设置并无意义。
2. 猜测实际网关地址
还是这个例子，在“大多数”情况下，虽然网关是一个内网地址，但它后面映射的还是一台跟主 IPv4 相近网段的主机，在 tk-hosing web 后台查到的实际网关是：89.163.208.1
主 IPv4 ：89.163.208.10
掩码：255.255.255.0 （简写 24）
网关：169.254.0.1
然后可以用 shell 脚本，实现一个和 Vultr IPv4 计算器一样的 IPv4 范围计算功能，把主 IPv4 89.163.208.10 和掩码 255.255.255.0 当做参数传入，可计算出一个 IP 地址范围，把该范围内第一个 IP 当做网关就行。
但这种方法还是有局限性，网关是一串内网地址，而且我们无法通过查询商家机器上游网络拓扑，来找到网关背后映射到的真实 IPv4 地址，凭什么根据主 IPv4、掩码计算出的 IP 地址范围的第一个就一定是网关？
靠猜显然是不行的。
