Posts

去年双11趁着电信活动，把家里的宽带升级到了200Mbps，然后之前家里用的一个是用了三四年的网件 3700V4就成为瓶颈了，主要存在的问题是1. WIFI 5G最多只能到140M2. 有线接上，NAT能力只有180M左右，桥接可以到200+，原因是AR8327不支持HWNAT。作为一个Openwrt的忠实用户，替换路由的第一要素是能得到OpenWrt原生支持的设备，以便配置802.11r，满足无缝漫游的需求。再要综合考虑满足全千兆，无线支持802.11AC，驱动完善，而且价格还不贵的路由器实际就很少了。当前低价位的路由器主要还是螃蟹芯片和MTK为主，尤其是MTK7621AT的路由器非常多。对比了当前的新3（newifi D2）和友华WR1200JS后，还是选择了新3。 WR1200JS CPU MTK7621AT 16M 128MB 5G芯片 MT7612EN 功放芯片 SKY85717-21，它集成了PA与LNA 2.4G MT7603EN，只有PA，无LNA 闪存 16M 内存 128M newifi D2 CPU MTK7621AT 5G芯片 MT7612EN 功放芯片RTC5638H 集成PA和LNA 2.4G MT7603EN 无PA,无LNA 闪存 16M 内存512M主要的原因还是新3内存大太多了，然后实际的做工用料比较足。实际使用的效果也还不错，虽然说2.4G容易出问题，不过5G是比较稳定的。PS:没选K2P是因为Openwrt官网的版本驱动不支持MT7615DN。

由于老房子弱电箱到客厅电视后面只有一根网线，所以我也遇到许多人都有的单线复用场景。之前是直接网上买了2个转接头，把8芯网线拆成2个4芯网线来使用。不过问题就是局域网内只有100M的带宽。双11看电信搞活动，花了之前100M宽带一半的钱把家里的宽带升级到了200M。就想着通过vlan隔离来把单线复用配置一下。 基本的方案其实很简单，首先需要明白从光猫的LAN口和ITV口出来的包都是不带VLAN tag的，因此把ITV的口接到交换机上，把从这个口进入的报文打个VLAN tag，再在电视机后面放个openwrt路由器把这个vlan解出来，桥接到一个lan口即可。大致的网络拓扑如下： 弱电箱里使用了水星的支持VLAN的交换机，配置如下 openwrt路由器上简单设置一下软交换，把对应的vlan和一个lan口桥接在一起，lan口选择untag。

Redhat从RHEL 7.0开始使用chrony替换ntpd作为默认的ntp同步工具。从chrony的官方网站上可以看到与ntpd各维度详细对比：从其测试结果上看似乎是各维度性能都可以吊打ntpd。因此chrony对自身的整体评价还是比较高的在测试之前，从理论上说chrony的主要优点在于：1. 支持Hardware timestamping，时间戳会更加准确，因为从网卡到内核之间的延迟可能有几十us。2. 支持xleave，可以提升对网络延迟的测量精度。为了评估内部是否需要使用chrony来替换ntpd，我自己也做了一些测试。主要是从集群的延迟稳定性和时钟偏差2个维度来衡量。测试集群选择三个城市的多个机房内服务器做测试。1. chrony的延迟稳定性2. ntpd延迟稳定性 chrony时钟稳定性4. ntpd的时钟稳定性 从上面的4个图可以看到，实际上NTPD的同步稳定性相对比较好一些。NTP协议本身精度的瓶颈是在于网络延迟稳定性，NTPD在这一块有大量的算法保证：1. Clock Filter Algorithm （huff-n’-puff filter）2. Clock Select Algorithm3. Clock Cluster Algorithm：4. Clock Discipline Algorithm：整体的流程如下 正因为NTP的设计者一开始就考虑的非常全面，使得目前NTP的授时精度早已经达到理论瓶颈。广域网的授时精度要想稳定性&精度超越ntpd，几乎不太可能（PTP只能用户局域网），因此短期内我还是会继续选择NTPD作为时钟同步软件。对于NTP这种古老的协议，目前还有人愿意投入精力去改进实际是非常难能可贵的，真心希望chrony能早日从稳定性&精度两个方面超越ntpd。 参考链接：1. https://chrony.tuxfamily.org/comparison.html

通常我们为了防止自己域名邮箱被伪造，会通过配置SPF记录来限制域名邮箱可以外发的IP网段。SPF相关配置说明可以参考：https://support.google.com/a/answer/33786?hl=zh-Hans例如我个人的邮箱是托管在QQ企业邮箱，因此就设置了相关的SPF记录 SPF记录相对来说只是限制了外发邮件的IP段，但是当你的邮箱被人伪造后自己实际并不知道（虽然绝大部分邮件服务器都会把SPF检查不通过的邮件放入垃圾箱）。DMARC记录相对来说是SPF记录的一种加强，相关的说明见 https://dmarc.org/overview/ 。以个人邮箱的DMARC记录为例v：版本（纯文本；必要的）值为“DMARC1”，必须作为第一个标签。p：要求的邮件接收者策略（纯文本；必要的）表明接收者根据域名所有者的要求制定的策略。none：域名所有者要求不采取特定措施quarantine：域名所有者希望邮件接收者将DMARC验证失败的邮件标记为可疑的。reject：域名所有者希望邮件接收者将DMARC验证失败的邮件拒绝。rua：发送综合反馈的邮件地址（逗号分隔的DMARC URI纯文本列表；可选的）ruf：发送消息详细故障信息的邮件地址（逗号分隔的DMARC URI纯文本列表；可选的）sp：要求邮件接收者对所有子域使用的策略（纯文本；可选的），若缺省，则“p”指定的策略将应用到该域名和子域中。adkim：（纯文本；可选的；默认为“r”）表明域名所有者要求使用严格的或者宽松的DKIM身份校验模式，有效值如下：r: relaxed modes: strict modeaspf：（纯文本；可选的；默认为“r”）表明域名所有者要求使用严格的或者宽松的SPF身份校验模式，有效值如下：r: relaxed modes: strict modefo：故障报告选项（纯文本；可选的；默认为0），以冒号分隔的列表，如果没有指定“ruf”，那么该标签的内容将被忽略。0：如果所有身份验证机制都不能产生“pass”结果，那么生成一份DMARC故障报告；1：如果任一身份验证机制产生“pass”以外的结果，那么生成一份DMARC故障报告；d：如果消息的签名验证失败，那么生成一份DKIM故障报告；s：如果消息的SPF验证失败，那么生成一份SPF故障报告。那么我这个dmarc的作用就是，告诉收件服务器将dmarc检查失败的邮件标记为可疑，并将综合反馈邮件和详细的信息都发送到我的个人邮箱。 当配置了dmarc记录后，各邮件服务器会加强对邮件源的检查从邮件头，可以看到gmail有对dmarc记录做校验。

bind 从9.10开始，将RPZ（Response Policy Zones）的性能做了进一步优化，解决了之前RPZ引起的性能下降问题，目前是可以大规模做部署。简单整理常见的RPZ规则用法1. 劫持某个域名(劫持www.google.com)./client add www.google.com.rpz.zone. A 8.8.8.8 丢弃某个域名的解析请求（丢弃对www.google.com的解析请求）./client add blog.gnuers.org.rpz.zone. CNAME rpz-drop. 3. 将某个域名解析到NXDOMAIN（www.google.com指向NXDOMAIN）./client add www.google.com.rpz.zone. CNAME .

政策趋势从去年年底开始国家开始力推IPV6。目前看到的相关文件有1. “推进互联网协议第六版（IPv6）规模部署行动计划”，这个由中共中央办公厅、国务院办公厅印发。2. “工业和信息化部关于贯彻落实《推进互联网协议第六版（IPv6）规模部署行动计划》的通知”，这是由工信部印发。 基本方案周末有时间，把blog重新整理了一下，目前支持native IPV6 only环境访问。相关的方案1. DNS服务器迁移到cloudflare。原本是准备自己再弄个VM，部署IPV6的DNS。后来觉得太费钱，直接用了cloudflare。2. V6地址是通过He.net的隧道接入。 注意事项使用隧道接入V6，需要注意防火墙规则的设定，主要是以下几点：1. 阿里云的网络安全组上放开he的隧道接入IP。2. 服务器上itables-v4放开he的隧道接入IP。3. 服务器上的ip6tables打开相关的端口。4. nginx的上的geoip库都使用IPV6（V6的包括了V4）的 相关的防火墙规则如下：v4规则 v6规则 4. 参考链接1. http://www.gov.cn/zhengce/2017-11/26/content_5242389.htm2. http://www.miit.gov.cn/n1146295/n1652858/n1652930/n3757020/c6154756/content.html

问题 网络的拓扑图大致如下虽然在客厅和主卧都有部署无线路由器，2个AP的SSID一致，实际使用的时候从客厅走入主卧时实际接入端还是在连接之前的AP。另外也经常出现电脑一会连AP1，一会连AP2导致无线中断。所有没有AC+AP的方案，都会存在以上的情况，为了提升体验就在openwrt上配置好802.11r，结果还是比较满意的。 配置方案 所有的AP需要都是桥接在同一个LAN中，我的2个WNDR3700都是把路由器的WAN口设置一个静态的IP（方便登陆管理），另外无线网络都是桥接到WAN上，所有AP的客户端的IP实际都是走光猫DHCP。 配置802.11r实际比较简单，只需要在openwrt上把wpad安装一下（默认是wpad-mini）,涉及的配置如下：1. NASID: PMK-R0 Key Holder identifier,每个AP不同，可以设置为MAC地址2. Mobility Domain: 每个AP相同，随便设置4位字符3. R0 Key Lifetime: 每个AP相同，可以就用默认值100004. R1 Key Holder: 每个AP不同，可以设置为MAC地址5. Reassociation Deadline: 每个AP相同，可以设置为默认的10006. r0kh(External R0 Key Holder List)，格式Valid format:,,<128-bit key as hex string> ，每个设备的配置都是相同的，可以按照格式：– MAC,NASID,32位字符串7. r1kh (External R1 Key Holder List)，格式：,,<128-bit key as hex string> ，每个设备相同，可以按照格式：– MAC,MAC,32位字符串我的实际配置如下： External R0 Key Holder List： - A4:2B:8C:0C:D7:B3,A42B8C0CD7B3,8a7fcc966ed0691ff2809e1f38c16999 - 04:A1:51:9B:0D:25,04A1519B0D25,8a7fcc966ed0691ff2809e1f38c16999 External R1 Key Holder List: - A4:2B:8C:0C:D7:B3,A4:2B:8C:0C:D7:B3,8a7fcc966ed0691ff2809e1f38c16999 - 04:A1:51:9B:0D:25,04:A1:51:9B:0D:25,8a7fcc966ed0691ff2809e1f38c16999

流程记录 软件包安装 并关闭SELinux – 配置epel源，直接使用yum安装 yum install cobbler cobbler-web dhcp bind pykickstart tftp -y 需要注意dhcp/bind需要单独安装一下，cobbler没依赖dhcp/bind sed -i 's#SELINUX=enforcing#SELINUX=disabled#g' /etc/selinux/config setenforce 0 ```bash systemctl restart cobblerd 配置cobbler参数 – 修改/etc/cobbler/settings的参数 allow_dynamic_settings: 1 ```bash default_password_crypted: "$1$random-p$yqLCVPP/OBjIT02WekZic1" next_server: 192.168.117.134 manage_dhcp: 1 manage_dns: 1 server: 192.168.117.134 manage_rsync: 1 pxe_just_once: 1 #防止循环装机 manage_forward_zones: [‘gnuers.org’] manage_reverse_zones: ['10.0.0', '192.168', '172.16.123'] - 修改dhcp池配置 /etc/cobbler/dhcp.template subnet 192.168.117.0 netmask 255.255.255.0 { option routers 192.168.117.2; option domain-name-servers 192.168.117.2; option subnet-mask 255.255.255.0; range dynamic-bootp 192.168.117.10 192.168.117.20; ...

bind 9.11 实际已经发布很久了，之前是简单的做过测试,简单做个总结。从功能上说9.11的几个特点：1. 持续完善了9.10 开始有的prefetch 功能2. 相比9.10 RPZ 的性能得到提升。3. 支持了dnstap。4. 支持了Catalog zone，zone的增加删除更加方便。5. 终于支持了ECS（EDNS Client-Subnet）。 9.12在9.11的基础上主要是新增了1. stale-answer ，递归失败的时候使用历史记录做响应。2. 完善了dnstap的文件轮转。 实际做了一些测试，简单的总结如下:1. 9.11.2 默认开始了cookie，实测9.11.2在递归的时候失败率相比9.9版本明显增加，性能上有少量的提升。2. dnstap对性能的影响比较小，关闭query log后 dnstap 关闭/开启的性能对比大概是13W/S VS 10W/S。相比传统的querylog的性能影响实在好太多了。但是因为是二进制的文件，查看需要用dnstap-read还是非常不方便的。3. 9.12的stale-answer还很不完善，最主要的问题是还是会先尝试同步做一次递归，失败了再用历史记录响应，测试中也经常出现找不到历史缓存的情况。目前了解是的akamai收购了nominum，这个patch应该是nominum 提供的。4. bind 9.10/9.11/9.12都支持了 EDNS Client-Subnet扩展协议，不过实际配置是比较脑残的。估计再等一两个版本会好一点。5. bind 9.11/9.12目前用于生产环境的风险还是比较高，建议企业用户继续使用9.9。整体来说这两年bind的发展相比之前还是快了很多，只是dns这个领域目前国内厂商因为国内运营商的各种奇葩要求做的工作还是很多的，无论是从性能，管控的便捷程度来说国内的成熟度都是超过国外的（除了对新扩展协议的跟进支持）。

新版本代码获取 从官网下载 https://openbsd.hk/pub/OpenBSD/OpenSSH/portable/openssh-7.6p1.tar.gz 编译RPM包注意事项 需要注意新版的openssh的spec文件里使用的pam配置文件会导致无法登陆 #%PAM-1.0 auth required pam_stack.so service=system-auth account required pam_nologin.so account required pam_stack.so service=system-auth password required pam_stack.so service=system-auth session required pam_stack.so service=system-auth 需要修改为 #%PAM-1.0 auth required pam_sepermit.so auth include password-auth account required pam_nologin.so account include password-auth password include password-auth # pam_selinux.so close should be the first session rule session required pam_selinux.so close session required pam_loginuid.so # pam_selinux.so open should only be followed by sessions to be executed in the user context session required pam_selinux.so open env_params session optional pam_keyinit.so force revoke session include password-auth ...