早期电信家用宽带支持IPv6的时候，我就尝试通过PPPoE拨号获取原生（Native）IPv6，一直使用正常，唯一遗憾就是由于当时IPv6刚刚起步，所以大部分支持IPv6的网站延迟都比较高，相应的访问速度比较慢，经过这几年发展国内IPv6业务日趋成熟，延迟和速度都有了较大提高，新的计算机、移动设备等都能较好的支持IPv4和IPv6双栈（Dual-Stack）访问。 近两年开始出现部分网站访问卡顿、应用无法加载的情况，经过调查发现这些网站和应用使用了IPv6的访问方式，极大影响了浏览体验，于是我决定先暂停IPv6的解析（DNS仅返回A记录）以缓解卡顿的问题，不过后来搜索网络我终于找到了问题的根源，彻底解决了，在这里把解决的过程记录下来以备忘用，如果读者想快速解决问题的话建议直接跳转到第2节 配置路由器TCP MSS。 1 配置返回IPv4 Only DNS服务器 可能有人说配置返回IPv4 …

我的网站老访客可能会有印象，之前的联系表单是支持PGP/GPG加密正文的，后来使用ASP.NET重构后这一部分实现始终存在问题，判断可能是第三方库的BUG，一直没有再加上这个功能，最近该第三方库进行了升级，发现这个BUG已经修复了，于是在联系表单启用了PGP/GPG加密特性。 1 什么是PGP/GPG PGP/GPG虽然是两种写法，但实际上是一种东西，首先我们要介绍PGP（Pretty Good Privacy），这是一套消息加密、验证的技术，由一系列散列、数据压缩、对称密钥加密，以及公钥加密的算法组合而成，最早由菲利普·齐默曼（Philip R. Zimmermann）发明并应用于电子邮件安全隐私保障，可以这么说在没有PGP和TLS加密的时代电子邮件或多或少的在互联网上明文裸奔，而且被篡改的几率很大。PGP最初由Philip免费在互联网上发布，但其本人也因此违反了美国政府关于加密软件出口 …

nginx作为反向代理服务器一直以轻巧高效著称，在日常实践中我将其作为项目的反向代理应用前端并取得了不错的效果，这里记录nginx其中利用njs模块的脚本支持读取ipset黑名单（白名单）从而实现访问控制列表（Access Control List）的方法，做法仅供参考，如有想法欢迎评论提出。 1 主要背景 1.1 问题的提出 互联网环境日益复杂和危险，对于新上线的服务器主机来说，每天都将面临大量的漏洞扫描、DDoS攻击，对于配置不当或者存在安全漏洞的主机，很容易就会沦为跳板机或者挖矿机，继而攻击网络中其他主机或者白白消耗宝贵的计算资源，对于互联网威胁我认为有必要采取积极的防御策略。 1.2 基本的防御策略 主要有这几种手段：① 关注安全公告并及时打补丁避免漏洞；② 复杂的身份认证策略，避免弱口令存在于SSH或者数据库系统中，建议采取证书或者key方式完成认证流程；③ 最小权限划分原则，避 …

Docker默认是不开启IPv6支持的，但是我们某些业务往往又需要IPv6的支持，特别是IPv6普及大势所趋，本文主要介绍的是如何开启Docker桥接网络IPv6支持，这篇文章具体操作仅供参考，建议以官方文档为准。 本文最重要的先决条件是主机商已经分配给你一个公网IPv6地址段，我们可以通过查看主机控制面板中信息、询问主机供应商或者直接SSH登录主机使用命令ip -f inet6 addr show eth0获取。命令方式获取的ipv6地址输出如下： 6: eth0: mtu 9000 inet6 2607:f0d0:1002:51::4/64 scope global valid_lft forever preferred_lft forever inet6 fe80::230:48ff:fe33:bc33/64 scope link …

记得很久之前就尝试使用废弃的银行U盾存储加密用的数字证书，也考虑过购买空白USB Key或者智能卡，直到有一天看到了YubiKey这个小玩意儿，彻底被种了草，由于国内购买不便，淘宝上价格虚高也不放心，一直等到亚马逊支持了海外直邮，立马入手，如果说仅将YubiKey用来存储数字证书，那么没有完全发挥出其在个人信息安全保护上的威力。比如就现在的YubiKey而言，在我的个人信息安全保护体系中主要承担了重要信息资产两步认证、SSH证书登录、GnuPG签名与加密、常用密码数据库KeePass保护等等，预计今后将会通过YubiKey逐步替代掉所有不安全的认证方式。 今天主要介绍的是YubiKey配置SSH登录备忘，配置内容仅供参考，实际上SSH最早是在采用YubiKey 4的时候就已经配置了，当时仅有一把YubiKey，串在钥匙扣上，配置GnuPG的时候顺带支持了SSH登录，当然主要是依赖于 …

大多数情况下我们开发的应用可能需要与其他服务进行交互，比如数据库服务、第三方服务等等，出于安全考虑，这些服务的交互都需要发起端提供认证凭据，这里可能是账号密码、API Key等，这里就涉及到认证凭据的保管问题，很长一段时间我们都是将认证凭据写死到配置文件中，这样做一开始是简单可行，但是随后你就会发现带来了一系列的问题：首先你的所有开发环境和生产环境都需要配置成一样的，比如生产环境数据库账号和密码和开发环境数据库账号和密码最好是一致的，否则部署到生产环境则需要手动修改这个认证凭据，当然你也可以通过配置分离或者环境变量控制来避免这个问题；其次是代码仓库提交，尤其是开源项目，至今GitHub公共库仍然存在大量配置文件明文保管着敏感凭据；最后分布式开发或者交付麻烦，需要团队合作或者直接提供给终端用户的项目，团队成员或者终端用户需要修改为本地环境凭据。 1 .NET Core与secrets. …