... 以补偿我们无法控制的损坏的 DNS 服务器。
我们的问题：我们部署了嵌入式设备，这些设备在各个站点（主要是仅支持 IPv4 的站点）收集传感器数据。一些站点的网络维护不善，例如错误配置或以其他方式损坏的 DNS 缓存和/或防火墙，它们要么完全忽略 AAAA 查询，要么以损坏的回复（例如错误的源 IP！）响应它们。作为设施部门的外部供应商，我们对（有时是不情愿的）IT 部门几乎没有影响。他们很快修复 DNS 服务器/防火墙的机会微乎其微。
对我们设备的影响是，对于每个 gethostbyname()，进程必须等到 AAAA 查询超时，此时某些进程已经完全超时了它们的连接尝试。
我正在寻找解决方案...
最明显的解决方案是配置解析器库，例如通过 /etc/{ resolv , nsswitch , gai }.conf 不查询 AAAA 记录。中resolv.conf选项no-inet6建议作为这里会正是我所期待的。不幸的是，它没有实现，至少在我们的系统上没有实现（Debian 7 上的 libc6-2.13-38+deb7u4；Ubuntu 14.04 上的 libc6-2.19-0ubuntu6.3）
那怎么办呢？有人发现在 SF 和其他地方建议使用以下方法，但它们都不起作用：
sysctl -w net.ipv6.conf.all.disable_ipv6=1. （出于好奇：为什么解析器要求禁用 IPv6 的 AAAA？）options inet6从 /etc/resolv.conf 中删除。它一开始并不存在，inet6现在只是默认启用。options …我想要做的是从主机系统设置来宾的网络配置（IP 地址、子网、网关、广播地址）。使用的网络设置处于bridge模式。如何从主机配置网络而不是将客户端本身配置为静态网络配置？
如果我执行：
virsh edit vm1
还有一个<network>块，我试图从那里配置网络接口，但不幸的是来宾 VM 似乎没有使用它，因此对网络离线（因为它仅使用自动网络配置）......来宾VM 都基于 Linux 和 Windows。任何帮助将不胜感激。
许多管理员一直在坚持——在 ServerFault 和其他地方——TCP-over-TCP 的想法有多糟糕，例如在 VPN 中。如果不是 TCP 崩溃，即使是最轻微的数据包丢失也会使一个人遭受至少严重的吞吐量下降，因此应严格避免 TCP-over-TCP。这可能曾经是真的，例如 2001年写这篇文章时仍然被引用。
但从那时起，我们看到了技术和协议的重大进步。现在我们几乎在所有地方都实现了“选择性 ACK”，摩尔定律给了我们更多的内存，随之而来的是针对 Gbit 上行链路优化的大型 TCP 缓冲区。如今，在非无线电链路上，数据包丢失的问题要少得多。所有这些都应该显着缓解 TCP-over-TCP 问题，不是吗？
请注意，在现实世界中，例如基于 TCP 的 VPN 比基于 UDP/ESP 的 VPN 更容易实现和操作（参见下文）。因此我的问题：
在什么情况下（链路数据包丢失和延迟），TCP-over-TCP 的性能比单独的 TCP 差得多，假设两端都有 SACK 支持和大小合适的 TCP 缓冲区？
看到一些显示（外部连接）数据包丢失/延迟和（内部连接）吞吐量/抖动之间的相关性的测量结果会很棒——对于 TCP-over-TCP，以及单独的 TCP。我发现了这篇有趣的文章，但它似乎只关心延迟，而不是解决（外部）数据包丢失问题。
另外：是否有推荐的设置（例如 TCP 选项、缓冲区设置、减少 MTU/MSS 等）来缩小 TCP 和 TCP-over-TCP 之间的性能差距？
更新：我们的理由。
这个问题在一些现实世界的场景中仍然非常相关。例如，我们在大型建筑物中部署嵌入式设备，收集传感器数据并通过 VPN 将其输入我们的平台。我们面临的问题是我们无法控制的防火墙和不正确配置的上行链路，以及不情愿的 IT 部门。请参阅此处讨论的详细示例。
在很多这样的情况下，从非 TCP 切换到基于 TCP 的 VPN（如果你像我们一样使用 OpenVPN 就很容易）是一个快速解决方案，它使我们能够避免上坡的相互指责。例如，通常 TCP 端口 443 通常是允许的（至少通过代理），或者我们可以通过简单地减少 TCP 的 MSS 选项来克服 Path-MTU 问题。
最好知道在什么情况下可以将基于 TCP 的 …
我们在客户处安装了数十个嵌入式设备，所有这些设备都可以使用我们的 OpenVPN 服务。一般情况下这很好，但我们的一些客户有严重的路径 MTU 问题。我们对客户修复网络的影响是有限的，因此我们需要 OpenVPN 来处理它。简而言之，我的问题是：
我如何在每个客户端的基础上减轻某些客户端的低路径 MTU，即不使用全局设置来适应所有客户端的最坏情况
请注意，我们的最坏情况非常糟糕：路径 MTU 576，丢弃所有碎片，不对自身进行碎片化，不尊重 DF 位。你明白为什么我不想在全球范围内解决这个问题。
该OpenVPN的联机帮助提供了许多MTU的相关选项，最显着的--link-mtu, --tun-mtu, --fragment and --mssfix。但它也说
--link-mtu [...] 除非您知道自己在做什么，否则最好不要设置此参数。
--tun-mtu [...] 最好使用 --fragment 和/或 --mssfix 选项来处理 MTU 大小问题。
于是我开始尝试用--fragment和--mssfix，但很快就意识到，至少前者必须设置不仅客户端，但也服务器端。然后我查看了服务器端每个客户端的配置，--client-config-dir但它说
以下选项在特定于客户端的上下文中是合法的：--push、--push-reset、--iroute、--ifconfig-push 和 --config。
没有提到 MTU 选项！
所以这里是我更具体的问题：
link-mtu和tun-mtu气馁？这些选项有哪些潜在问题？请注意，我对低级 IP 标头处理非常满意。link-mtu tun-mtu fragment mssfix必须在服务器端镜像才能工作？link-mtu tun-mtu fragment mssfix可以用于client-config-dir？client-config-dir：是否有任何替代方案来对抗每个客户端的低路径 MTU？笔记：
使用 http(s)://CompanyName.com/xyz 作为 URL（例如用于品牌目的）而不对服务端配置进行任何更改是否安全？
我知道 DNS 不区分大小写，但还会有副作用吗？我正在考虑例如链的各个部分无法匹配 CompanyName.com ~ companyname.com：
有人在 URL 的主机名部分遇到过这些或其他问题吗？
[edit] @Michael Hampton 指出，根据 HTTP 标准，主机名不区分大小写，但某些软件在这方面不合规。
我试图了解不合规软件的流行程度，尤其是客户。我认为所有最近的主要浏览器都很好，但是例如移动应用程序呢？（我应该更好地将其拆分为一个单独的 SF 问题吗？）[/edit]
是否有一种现有的机制可以在在线时将 linux 系统与 NTP 同步，并在离线时与可预测的漂移 RTC 同步？
我们操作远程“收集器”：收集和时间戳传感器数据的嵌入式 Linux 系统。我们需要他们的时钟误差保持在相当小的范围内，比如低于 5 秒。通常我们使用 NTP 来同步他们的时钟，只要系统在线，就可以正常工作。
问题是一些收集器的上行链路非常糟糕，可能会中断数小时、数天甚至数周。这不会停止本地数据收集，但如果没有 NTP，Linux 系统时钟漂移严重且不可预测。
OTOH，硬件的 RTC 漂移也很大，但速率恒定。RTC 漂移率因板而异，但每块板都是恒定的，并且可以测量。
我想我们需要的是一种执行以下操作的机制：
对于“机制”，我指的是一些维护良好、记录在案的软件和/或配置，可以处理“在线”与“离线”两种状态，确保系统时钟与正确的时间源（ntp 与 ntp 与 ntp 同步）。 rtc)，检测状态变化，并校正 RTC 漂移。无论是作为特殊的 ntpd 配置/插件、作为单独的守护程序、作为 cron 作业还是其他方式实现，都没有多大关系。
我看过Chrony，但根据它的文档，它试图预测系统时钟的漂移，在我们的例子中，它的漂移比 RTC 更难以预测。Chrony 似乎只使用 RTC 来保持重新启动的时间。
(1) 注意 ntpd 激活内核的“11 分钟模式”（每 11 分钟从系统时钟更新 rtc）。当前的内核和 ntpd 似乎没有办法阻止 11 分钟模式。因此，任何 rtc 漂移信息在 ntpd …
我们有一个基于 Debian 的嵌入式设备。它运行一个通过串行（RS-232、/dev/ttyS*）与其他嵌入式设备通信的应用程序。通常，这效果很好。但当然，有时会出现问题，虽然我们的应用程序仍然可以毫无错误地发送字节，但另一端没有任何返回。
现在我希望能够区分
[A] 串行连接处于活动/启动/建立状态（我知道我可能使用了不恰当的术语），因为其他设备正在接收我们的数据。但无论出于何种原因，其他设备上的应用程序都不会与我们对话（例如，因为它崩溃了）。
[B] 串行连接未激活/启动/建立，例如因为电缆被拔出或其他设备断电。
有没有办法做到这一点？（就像以太网连接一样，很容易判断它是否有链接）
一些细节：
如果 Linux 主机接收并接受 ICMP 重定向（accept_redirects=1在有问题的接口上），该路由被缓存和观察多长时间？我可以降低那个时间吗？
我之所以这么问，是因为我有许多系统被虚假路由毒害，这些路由很可能源于不幸的 ICMP 重定向：
$ ip route get 10.2.2.2
10.2.2.2 via 10.2.2.2 dev eth0 src 10.1.1.2
cache <redirected>
并且他们根本没有忘记重定向，即使在收到最后一个 ICMP 重定向后超过 12 小时！我必须手动ip route flush cache删除条目并恢复正确的路线：
$ ip route get 10.2.2.2
10.2.2.2 via 10.1.1.1 dev eth0 src 10.1.1.2
cache
我知道首先发送、接收和接受 ICMP 重定向的方式和原因，这个问题与此无关。
我认为这与问题无关，但这里有一些细节：
我们有一个内部网络，比如说 10.1.0.0/16。其中一台机器 10.1.1.1 是 OpenVPN 服务器，远程客户端在 10.2.0.0/16 内获得分配的地址。其他内部机器有一个静态路由 10.0.0.0/8 --> 10.1.1.1。它故意比 10.2.0.0/16 更宽，因为 VPN 服务器将来可能会服务更多的客户端。
不幸的是，我们的配置管理将更广泛的静态路由 10/8-->10.1.1.1 也推送到 VPN 服务器本身，它被建立为 10/8-->eth0。这种不必要的路线通常没有任何效果。
在正常情况下，此设置工作正常。但后来发生了这样的事情：
多宿主设备需要为 DHCP 配置多个上行链路。除了一个DHCP 上行链路，它需要忽略所有的默认路由和 DNS 。
这里有一个类似的问题 [ Debian 接口文件 - 忽略来自 dhcp 的网关和 dns 条目]，但那里的答案并没有解决我的问题：
ifmetric建议仅涉及路由，而不涉及 DNS。此外，我希望自 2009 年以来情况有所改变。
请注意，我说的是无头嵌入式系统。NetworkManager 不是一个选项。
首选解决方案仅是 /etc/network/interfaces{.d/}。我正在寻找这样的东西：
auto eth0
iface eth0 inet dhcp
auto eth1
iface eth1 inet dhcp
ignore-dhcp-option routers domain-name-servers domain-name
附录：
我们在各种环境中安装了数十个这样的盒子。网络不在我们的控制之下。在某些情况下，这些盒子需要在多个接口上执行 DHCP。我们通常事先不知道默认路由和 DNS，即使知道，它们也可能会随着时间的推移而更改，恕不另行通知。因此我们不能静态设置它们，而必须通过“主”DHCP 客户端配置它们。
我需要使用 shell 脚本确定设备（如果有）的 IPv4 广播地址。如果有多个，选择一个（例如第一个由 /sbin/ip 排序）。
我有一个解决方案，但我不喜欢它，因为它对 /sbin/ip 的输出格式做出了假设，而且我不知道该输出格式跨系统的稳定性如何。
DEV=eth0
BROADCAST=`ip address show $DEV | grep 'inet .* brd ' | head -1 | sed -e 's/^.* brd \([0-9\.]*\) .*$/\1/'`
echo $BROADCAST
在 /proc/ 或 /sys/ 中不是有什么东西可以让我简单地捕捉吗？为什么不？
我需要该解决方案能够可靠地工作，至少在 Debian/Ubuntu Linux 家族中是如此。
编辑：这不是关于 sed/awk/grep 魔法的问题。问题是：
ip（ifconfig就此而言）跨架构和 Linux 风格具有相同的输出格式，以便我可以可靠地解析例如接口的 IPv4 广播地址？cat？