Author: 芳草苑主

  • DNSSEC 诱出的一些 bugs

    我在 Netcetera 买有几个域名,其中一个出现一个问题:设好 MX 并在邮件服务器上开有邮箱,能收到大部分的邮件,但 hotmail.com 发给它的邮件总是收不到,hotmail 发件人邮箱也收到拒收提示。

    因为找不到原因,我把域名注册商迁移到 Godaddy。之后我没关注 hotmail 能不能往该域名的邮箱投递邮件(因为域名迁移又出了一点小插曲,迁移成功已经是一个多月以后的事,没有继续检测),直到最近邮件服务器试图为该域名的子域名 auto renew Letsencrypt certificate 时,总是失败。

    我花了一点时间看懂了 Letsencrypt 的失败通知邮件,里面提到了 DNSSEC: DNSKEY Missing。

    可我从来不用 DNSSEC,有这种提示就很诡异。我用第三方工具查了一下 DNSSEC 状态,显示 Signed。Godaddy 的 DNSSEC 页里显示该域名没有启用 DNSSEC。

    或许在 Netcetera 时 DNSSEC 就已经不正常了。我回 Netcetera 看了看,人家根本没提供 DNSSEC 管理页面。要是 DNSSEC 在那时就被 Signed,那肯定是 Netcetera 的 bug,但现在无从查证。

    Godaddy 的 bug 在于没有正确提示 DNSSEC 的状态。

    最后,我用 Godaddy 的 DNSSEC 页 enable 一下,再马上 disable,静待一段时间等它生效,终于 auto renew Letsencrypt certificate 成功。顺手再测试用 hotmail 发信,也能收到了。

  • 避开备案租中国大陆的服务器

    首先,如果不想备案,最简单的就是租香港的服务器。我这里特指中国大陆。

    其次,澄清一个概念:租中国大陆的服务器并非要备案。备案特指的是域名备案。

    再次,域名可以指向中国大陆的服务器,只要不建站,也可以不备案。比如,拿它做 SIP server。

    那么,建站想用中国大陆的服务器,不备案可以吗?我只想从技术上挑战一下,还成了。是在一定限定条件下的成功,但已具有极强的实操性,所以我有兴致讲一讲。

    大陆机房会抓数据包来分析 http(s) 流量是否为某个未备案的域名,是,则拦截并提示去备案。依我所见,无法 100% 抓包来分析(机房路由器算力无法 100% 抓包分析?),所以会有个别几次 http://unicped.domain 访问成功。机房的算法也是相当巧妙,所以也只是偶尔能访问成功,绝大部分次数是不成功的。

    有人说,只要改掉 http 默认的 80 端口就可以不备案建站。我已试过,此路不通,不管曾经有没有通过,反正现在不通。未加密的数据包能被分析,https 协议下的数据包是无法被分析的。所以,要避开备案,只能用 https 建站。

    好在如今 https 已是主流,http 建站可以不考虑了。需要注意的是,在 tls 1.3 出来前,https 的握手数据包是不加密的,不加密就能被分析,分析后就能阻断握手。

    好在如今的主流浏览器和主流 web server 都已支持 tls 1.3,这让不备案建站有了实操性。简单点说,就是用最新版的 web server 建个 https://any.domain。

    最后,我想用一点时间讲一讲如何不备案建一个 free SSL certificated https://freepbx.server.domain。

    1,FreePBX 安装完成后,用 http://ip.address 是可以管理的。

    2,在 System Admin > Hostname 输入域名 freepbx.server.domain,在 > Port Management 修改 Admin port 80 至一个未使用的端口,比如 48561,这样 80 端口就可以留给 LetsEncript 做 http-01 challenge。

    3,之后可以用 http://ip.address:48561 来管理。但这样去 Certificate Management 生成 LetsEncript 证书会失败,因为 FreePBX 只会用 http-01 challenge(如果会 dns-01 challenge 就好了)。

    4,我的研究表明,用 http://non-fqdn-domain:48561 来管理,就能让 FreePBX 完成 http-01 challenge。这需要在本地解析 non-fqdn-domain。

    5,在 System Admin > HTTPS Setup 启用这张证书就可以用 https://freepbx.server.domain 来管理了。

    后记:虽然成功了,但我挺纳闷的,用 http://non-fqdn-domain:48561 来管理和用 http://ip.address:48561 来管理,LetsEncript http-01 challenge 所涉及的数据包都是未加密的、无分别的、能被分析的,为什么 http://non-fqdn-domain:48561 一次就挑战成功,而 http://ip.address:48561 屡次失败。

  • Grandstream GXV3275 挺鸡肋的

    当初为了和可视 SIP 门禁机可视对讲,我买了几台当时比较稀有的大屏 SIP 话机,其中三台是 Grandstream GXV3275。我想吐槽一下:

    1,bugs 应该很多,比如总是提示 http 自动下载更新失败。好在 fireware 不需要经常更新,我忽略了这消息。

    2,web GUI 那是相当的难看,也不好用。

    3,SIP 账号改动后重新注册,到注册成功,那是相当地慢,有时好几分钟仍显示未注册,以致于我开始怀疑账号错了,东检查西检查的时候,它又突然注册成功了。

    4,接上条,可能注册时,FreePBX 检查了账号密码,认定账号合法就已经注册成功,而 Grandstream GXV3275 仍认为未注册成功,不停尝试注册,FreePBX 认为之后的注册请求都是非法的,被请求若干次后,fail2ban 就把话机的 IP 给禁了(除非事先添在白名单上)。

    谁要是想收了这三台 Grandstream GXV3275 就好了。我觉得下次再挑选 SIP 话机时,手气不会这么差。

  • Firewall and fail2ban in FreePBX

    之前一直不理解 FreePBX 里 Firewall 和 fail2ban 的关系,只感觉 FreePBX 动辄把我给关门外了,搞得我灰头土脸,为了方便起见,我干脆把 fail2ban 给关了。

    FreePBX 处于裸奔状态很久了,直到最近发生一件事:fail2ban 的日志在一天之内迅速膨胀,把硬盘写满了,于是 FreePBX 崩溃了。其中,我还是没搞懂为什么 fail2ban 禁用状态仍然在写日志?可能这就是 fail2ban 的设定。

    这个事件让我觉得应该启用 fail2ban,但我不熟 fail2ban 的命令行,甚是困惑。也是机缘巧合,这时我发现 FreePBX 激活以后(是的,很长一段时间我都不愿意激活,以为它没什么用,以为它只是为了方便 Sangoma 推销自己的付费产品),在 System Admin 或是在 Firewall 菜单页面里,就能找到 Intrusion Detection 了。Intrusion Detection 就是 fail2ban 的图形版,虽然很简化,但是足够了。

    如果在 Networks 标签页里添了一个 IP 或 Hostname 作为 Trusted Zone,但在 Intrusion Detection 标签页里没有把这个 IP 添入白名单,fail2ban 还是有可能把这个 IP 给 ban。这也是我之前经常被关门外的原因。

    那么,一个 IP 在 Networks 添一遍 Trusted Zone,还要在 Intrusion Detection 添一遍白名单,岂不是重复劳动?

    而且,Networks 可以填 Hostname,Intrusion Detection 只能填 IP,似乎灵活性差点意思?

    非也。Intrusion Detection 里 Import 选中 Trusted Zone,Trusted Zone 里的 IP 和 Hostname 就同步到白名单了。白名单只存 IP,Hostname 被自动解析了。

    自此,我只要维护好 Trusted Zone,就不再会把自己关门外了。

  • Contabo 避坑

    别误会,我不是说 Contabo 不好。

    相反,Contabo 是典型德国品质,用得让人放心。

    但是,前几天我写了一篇文章,后来发现消失了。我怀疑有人黑了我的博客,后来发现发布文章的时候恰逢 Contabo 在维护,维护结束后服务器回滚到维护之前。所以,避坑之一,避免在维护期间做事,做了白做。Contabo 确实有提前通知维护时间,但被我无视了。

    避坑之二,别订英国的 Contabo,如果一定要订,也别拿来建 PBX。

  • Contabo and FreePBX

    前几天我写了一篇长文《避坑Contabo》,不知怎么的消失了。不想花时间重新写,但又忍不住不写,毕竟最近两周我花了很多时间在 Contabo 的 VPS 里捣鼓 FreePBX,我就换个角度说一说 Contabo 和 FreePBX。

    去年黑五期间我新购了英国 VPS,用来替换德国 VPS。两周前我开始试用英国 VPS,同时把 FreePBX 从 16 升级到 17。本以为是很简单的一件事,装好后测试一下,发现分机无法接听外线,具体症状是分机响铃正常,按接听键,显示已接听,但外线显示一直在振铃,直到无人接听超时。

    我花了近两周时间才确定是 FreePBX 所在的路由器的问题,也就是说数据中心机房的问题,就想把 VPS 从英国迁回德国,毕竟之前没碰到过这种莫名其妙的问题。

    我担心我的问题不具有普遍性,Contabo 没发现潜在的问题就不愿意帮我迁移。于是我写了一篇长长的邮件,千方百计想证明我碰到的问题不是我这端的问题,是英国机房的问题,既然英国机房找不到问题所在,就帮我迁回德国吧。

    结果,Contabo 短短回了封邮件,告诉我迁移 VPS 可以登录账号自助操作。哎,真是浪费表情。

    顺便提一下,迁回德国后,FreePBX 就一切正常了。可怜我浪费两周时间就得出这么个结论。

  • 消失的 Post

    前几天写的一篇 Post《Contabo 避坑》,今天发现不见了。

    难道有人黑入芳草苑的后台删帖?

    为什么要黑我?

  • No more www

    以前网站域名总是冠以 www,后来谁说 www 是多余了,建议大家不要拖泥带水,域名前裸奔成了时尚。

    但我总是很念旧,如果以前是带 www 访问的,我倾向于保留这个传统,直到我发现——

    有个静态网站托我管,N 多年了也不更新,我自作主张决定送他一张 Let’s Encript 证书。可是 Certbot –nginx 在修改带 www 的 conf 文件后,造成访问来回重定向(无法访问)。我只好放弃 www 传统,Certbot 就能给我生成一个正常的 conf。

    附 Certbot 不能自主修改的带 www 的 conf

    ## Html only

    server {
    listen 80;
    server_name www.example.com;
    root /document_root/public_html;
    index index.html;
    }

    # Redirect undesired domains

    server {
    listen 80;
    server_name example.com *.example.com;
    return 301 $scheme://www.example.com$request_uri;
    }

    附 Certbot 能自主修改的不带 www 的 conf

    ## Html only

    server {
    listen 80;
    server_name example.com;
    root /document_root/public_html;
    index index.html;
    }

    # Redirect undesired domains

    server {
    listen 80;
    server_name *.example.com;
    return 301 $scheme://example.com$request_uri;
    }

    我喜欢捕捉 undesired domains,这也是困扰 Certbot 的一个因素。但为了拥抱 Certbot,还是彻底放弃传统的 www 吧。

  • Use long established business for your hosting

    前段时间用了一个名不见经传的公司的 VPS 产品。当时看它性能不错才切换过去,但是它操作极不规范,到期前不催续费,我想主动续费都没有链接可以让我续。突然有一天,它意识到有未收账款,也不通知我付款,就停了我的帐号。然后我付款,重新开通服务。中间中断了大约半天的服务,让我损失惨重——那天以后来自 Google 和 Facebook 的流量突然就下降了。这也让我百思不得其解:

    1. 我知道一个网站的 uptime 是很重要的指标,但是,好像影响过头了?以致我怀疑流量下降不是 uptime 的问题,但转折点就在宕机的那一天,是巧合吗?
    2. Google 和 Facebook 使用同样的算法?

    总之,不正规的公司是绝对不敢用了。离开之前,我自己清空数据,以下一行命令删除 MySQL 里所有的数据库,抄来的,很方便。

    mysql -uroot -pPASS -e "show databases" | grep -v Database | grep -v mysql| grep -v information_schema| grep -v test | gawk '{print "drop database " $1 ";"}' | mysql -uroot -pPASS
  • Magento not rebuilding image cache

    I changed a server for Magento sites. When I migrated the sites, they looked fine. However after I flushed Magento image cache, all sites stopped working. Web pages were not completed. The code stopped rendering after the first product image’s “src”. But there was no error message afterwards.

    At first I thought it was file permission problem. But it was not.

    Then I thought it was some rubbish left over after flushing cache. So I took the advice by removing the folder media/catalog/product/cache and clearing everything under var. But the problem was still there.

    Then I realised it was php not generating images for Magento. Magento requires php-gd to generate images. My new server did not have php-gd installed. If I was installing a Magento instance, I would not get through. But I migrated the sites. So they “looked” fine.

    After installed php-gd, product images came back.

    By the way, Magento requires some other PHP extensions to run. I took the chance to install them all.
    pdo_mysql
    simplexml
    mcrypt
    hash
    gd
    dom
    iconv
    curl
    soap