weixin_44184011的博客

在互联网场景下使用DNS会受到中间DNS服务器的影响，最常见的就是缓存问题，运营商的DNS服务器往往会强制改写域名的TTL并将该结果进行缓存。遇到需要通过域名进行业务切换的场景时（比如，想要将一个业务通过域名从一个数据中心切换到另一个数据中心），需要等待DNS缓存时间过期，这个机制延长了切换的时间。很多DNS的策略是基于源地址进行配置的，但是在实际通过DNS请求域名解析的过程中，运营商DNS会作为代理DNS，以其自身的源IP去向权威DNS请求结果。

在使用ratio算法的过程中，发现修改比例以后，结果没有很快体现出来。查了一下官方的文档，说修改比例以后，会存在明显的延迟。于是对GTM的比例算法进行了一些测试。

本案例中的 apache tomcat明显存在目录映射的情况，以不同的Host去访问，会映射到不同的目录中。在IP访问的情况下，Host字段就是在浏览器中输入的IP，经过负载时，Host字段为负载的VIP，直接访问服务器时，Host字段为服务器的真实IP。

用Prometheus+Grafana来对F5设备的全量指标进行监控，配合grafana现成的F5 Dashboard，轻轻松松实现多维度的监控

可以看出来，隧道建立以后，自动把私网DNS加入到所有网卡的DNS里，包括公网网卡里。测试环境的内网DNS服务器，对于不存在的域名会直接回应REFUSED，所以客户端会直接尝试下一个DNS服务器。在使用VPN的情况下，如果涉及到同时需要访问公私网的域名，那么对于私网域名应该到内网DNS服务器解析，对于客户端来说，怎么能将私网域名的DNS解析流量引导到隧道中，到达内网DNS服务器进行解析。curl访问公网域名，先到私网DNS服务器解析，再到公网DNS服务器解析。实现DNS的公私网分离。

又到了护网的时候，客户开始关注安全问题，来跟我咨询两个F5的CVE，CVE-2022-1388 CVE-2021-22986。在给客户提供了解决方案之后，由于这两个CVE时间都比较长（一个是2021年一个是2022年的），所以做了个简单的POC。两个CVE都是基于F5的RESTAPI进行利用，可绕过身份验证，远程执行命令。可通过升级的方式修复，如果暂时不方便升级，可以根据官方指示进行缓解。

从BIGIP-11.5开始，数据平面和控制平面在采用Intel 超线程技术HT CPU的平台上使用单独的逻辑核心。偶数逻辑核心分配给TMM，而奇数核心可供其他进程使用。比如i10600共有8个CPU核，16个逻辑核心，8个tmm线程。正常情况下，控制平面不会占用太多的CPU，大部分的CPU使用都集中在tmm上。这里演示如何查看tmm各个tmm线程的CPU利用率。