Chiphell - 分享与交流用户体验

标题: 学习大佬帖子，小白简配版自建ownCloud家庭服务器，启用Let's Encrypted证书流程分享 [打印本页]

---

作者: tedaz    时间: 2024-12-26 14:27
标题: 学习大佬帖子，小白简配版自建ownCloud家庭服务器，启用Let's Encrypted证书流程分享


看了kn69968的帖子DIY 家庭小主机 AIO (10)——将私服暴露到公网, 安全便利地回家及无缝网络服务，其中通过创建并启用授信证书，解决浏览器提示自建https服务器证书无效问题深深地吸引了我。

于是开始了下面的折腾。

特别感谢kn69968、elvba、jimmy203308的讨论、帮助和支持！

现况

• 家庭服务器宿主：Windows Server 2016 Data Center版。
• Hyper-V虚拟机：Ubuntu Server 22.04，ip=192.168.1.24，按照官方手册安装ownCloud，启用https，禁用http。
• 局域网通过 https://192.168.1.24 访问，提示https证书无效，但可以点击忽略风险，继续使用。
• 路由上将公网 7777 端口映射到 192.168.1.24 的 443 端口，公网通过 https://ted.ddns.net:7777 进行访问，同样会提示证书无效，但可以使用。
• 安卓版ownCloud app可以通过 https://ted.ddns.net:7777 添加并访问，添加时提示证书无效，但可以使用。
• 考虑到ddns服务器的不稳定性，实际上在路由器上绑定了多个不同服务商的ddns域名，当一个域名暂时挂掉时，可以继续使用其他域名正常访问ownCloud。多个域名均已经添加到ownCould的添加trusted_domains中了。
  

安卓版Moon+ Reader通过“Sync to cloud”的“Sync via WebDav”同步读书进度 和/或 电子书时，会因为证书无效，直接被Moon+ Reader拒绝，没有忽略风险的选项。这个问题困扰我多年，多次尝试过不同的解决方案，均为成功。

直到看到kn69968的帖子，开始再次尝试。

题外话
个人一直不倾向于使用“一键脚本”、“无敌汇总大全docker”等解决方案；而是倾向于使用命令逐步自己完成各项设置。
脚本主要是为了海量、多次部署减轻工作量；不一定真的可以让啥都不懂的电脑小白“一键升天”。

实际上，尝试过很多脚本、集成大包、docker等，都没有成功，而且出现的问题很难解决，因为看不明白脚本中到底写的是什么，给出的错误信息也不知道到底属于哪个软件、程序，想查官方手册都不知道从哪里入手。

我的需求

• 通过生成、启用有效的数字证书，解决https访问时证书无效的问题，达成安卓版Moon+ Reader通过“Sync to cloud”的“Sync via WebDav”同步读书进度 和/或 电子书。
• 添加一个新的有效数字证书的域名来访问ownCloud；同时保持目前路由器端口转发（正向代理）可以继续访问ownCloud。
• 在浏览器地址栏可以看到ownCloud的完整URL而不仅仅是域名（不需要重写URL）。
• 在访问域名时附带端口号。
• 所有服务器、功能、软件均分布在不同的虚拟机上，确保明白每个命令的原理、影响，方便远期维护、更新。
• 尽量不使用手机号码、微信才能注册的服务（比如阿里系列）。
• 不依赖公网VPS（中转对速度影响太大；与其中转，不如直接在公网VPS建立服务了）。
  

前提条件

• 家庭宽带需要有动态公网ipv4；不需要ipv4的80、443端口；不需要ipv6。
• 家庭服务器，可以开启多个虚拟机（方便测试和折腾）。
• ddns服务商支持添加TXT记录，以便在公网ipv4的80、443端口不可用的情况下，完成Let's Encrypt证书的申请。
• 不需要手机号码注册，不需要微信注册。
• 不需要公网服务器。
• 无需域名备案等流程。
• 有折腾的意愿和时间。
  

Let's Encrypt有两种验证方式

• 在本地服务器创建一个URL，然后Let's Encrypt通过访问https://ted.ddns.net/test-string的方式完成域名验证。因为这是Let's Encrypt发起的访问，所以无法自定义https的端口，也就是必然会使用默认的443端口访问。我之前就是在这个步骤卡了几年，一直没找到解决方案。
• 在ddns域名服务商那边设置，添加一个TXT记录，然后Let's Encrypt通过访问https://test-string.ted.ddns.net来完成域名验证。这样就不需要用到本地服务器的80、443端口了，因为仅用了域名解析，没有访问本地服务器。
  

	优点	缺点
第一种验证方式	对ddns服务没有要求（不是所有ddns服务都可以创建TXT记录）。	需要本地服务器（公网ipv4）的80、443端口可用。
第二种验证方式	无需本地服务器（公网ipv4）的80、443端口（目前几乎所有家庭宽带的公网ipv4的80、443端口均已封闭）。	需要ddns服务支持创建TXT记录。

综上，如果ddns服务不支持创建TXT记录，同时公网ipv4也封闭了80、443端口，那就没戏了，放弃吧。或者根本就没有动态公网ipv4也可以放弃了（虽然依然可以用各种神奇的穿透、反代，但都不是本文的讨论范文了）。


实施：第一步 申请Let's Encrypt证书

新建一台Ubuntu 24.04虚拟机，使用root用户登录，运行命令安装certbot

1. apt install certbot

复制代码

运行certbot命令，开始申请证书。其中“--preferred-challenges dns”的意思是本地ownCloud服务器的80、443端口不可用（也就是家庭宽带的动态公网ipv4的80、443端口不可用），需要通过域名验证方式完成证书申请。

1. certbot certonly --manual --preferred-challenges dns -d "ted.ddns.net"

复制代码

按照提示输入真实邮箱地址（邮箱用于后续证书更新，Let's Encrypt证书需要每90天更新一次）后，会提示

1. Account registered.
   
2. Requesting a certificate for ted.ddns.net
   
3. 
   
4. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   
5. Please deploy a DNS TXT record under the name:
   
6. 
   
7. _acme-challenge.ted.ddns.net.
   
8. 
   
9. with the following value:
   
10. 
    
11. 1rd_7j4uhZDBY_iiQOheE2QvwSU7h47tVi-GoqRLCyk
    
12. 
    
13. Before continuing, verify the TXT record has been deployed. Depending on the DNS
    
14. provider, this may take some time, from a few seconds to multiple minutes. You can
    
15. check if it has finished deploying with aid of online tools, such as the Google
    
16. Admin Toolbox: https://toolbox.googleapps.com/apps/dig/#TXT/_acme-challenge.ted.ddns.net.
    
17. Look for one or more bolded line(s) below the line ';ANSWER'. It should show the
    
18. value(s) you've just added.
    
19. 
    
20. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    
21. Press Enter to Continue
    

复制代码

这段话的主要意思是，到你的ddns服务商创建一个TXT记录，以便Let's Encrypt验证这个域名确实属于你：

Hostname = _acme-challenge.ted.ddns.net   
Type = TXT
Data = 1rd_7j4uhZDBY_iiQOheE2QvwSU7h47tVi-GoqRLCyk


在ddns服务商那里创建好TXT记录后，可以用nslookup验证下TXT记录解析是否成功：

1. nslookup _acme-challenge.ted.ddns.net
   
2. 
   
3. 回显：
   
4. Server:         127.0.0.53
   
5. Address:        127.0.0.53#53
   
6. 
   
7. Non-authoritative answer:
   
8. Name:   _acme-challenge.ted.ddns.net
   
9. Address: 911.911.911.911
   

复制代码

TXT记录解析成功了。
在Let's Encrypt的脚本界面按回车继续，完成域名验证、证书创建成功。

证书在/etc/letsencrypt/live/ted.ddns.net文件夹中。


实施：第二步 更新ownCloud配置文件

修改ownCloud的配置文件/var/www/owncloud/config/config.php，添加trusted_domains。
不需要写http、https等前缀，也不需要写端口号。

1.   'trusted_domains' =>
   
2.   array (
   
3.     0 => 'localhost',
   
4.     1 => '192.168.1.24',
   
5.     2 => 'ted.facebook.net',
   
6.     3 => 'ted.twitter.net',
   
7.     4 => 'ted.youtube.net',
   
8.     5 => 'ted.ddns.net',
   
9.   ),
   

复制代码

这样设置后，可以用本地ip地址和多个域名访问ownCloud，而且每个域名既可以用主路由上的端口映射的7777、6666等端口访问；也可以用Nginx反向代理的有授信证书的https访问端口8888、9999等。

重启apache2服务，使修改后的配置文件生效：

1. systemctl restart apache2

复制代码

可以不用，但不能没有：保留多种访问方式，可以最大程度的提高灵活度。比如Nginx被玩崩了，依然可以用端口转发访问存在ownCloud上的《TCP/IP详解》、《用TCP/IP进行网际互联》、《TCP/IP指南》、《TCP/IP路由技术》 等书籍，学习网络知识，修复Nginx。

端口转发等安不安全不是最重要的，毕竟ownCloud上只是存了一些TCP/IP电子书，和Moon+Reader的读书进度，不怕泄露，不怕攻击。废了就重建，还能顺便复习Nginx教程。

ownCloud的配置文件中，不需要添加trusted_proxies。不需要更改overwrite.cli.url，我这里是

1.   'overwrite.cli.url' => 'https://192.168.1.24/',

复制代码

重要：

• 在ownCloud已经部署正常的情况下，除了修改trusted_domains，绝对不要为了Nginx更改ownCloud的其他任何东西。
• 记住，只要在端口转发状态下ownCloud工作正常，在Nginx反向代理的情况就应该一切正常，就不需要改ownCloud。
• 要改的是Nginx。
  

千万不要用乱七八糟的正则表达式去重写URL等骚操作，那样也许可以暂时解决某些问题，但是ownCloud的功能和代码太复杂了，很可能有的页面、有的功能就不正常了。
特别的，当后期ownCloud版本升级后，可能需要新的URL重写规则，不是顶级高手，不要重写URL；不要乱改ownCloud的配置，确保未来ownCloud可以正常升级和使用。

实施：第三步 配置、运行Nginx

新建Windows虚拟机，ip=192.1681.2。
下载Windows版Nginx，解压缩到C:\。

编辑配置文件nginx-1.27.3\conf\nginx.conf

添加一个server块，注意端口不要冲突。

1. server {
   
2.     listen 443 ssl; #Nginx监听443端口
   
3.     server_name ted.ddns.net; #ddns域名
   
4. 
   
5.     ssl_certificate fullchain.pem; #certbot生成的证书文件
   
6.     ssl_certificate_key privkey.pem; #certbot生成证书的key
   
7. 
   
8. location / {
   
9.         proxy_pass https://192.168.1.24; # 指向内网ownCloud地址
   
10. proxy_set_header Host $host:8888; # 传递请求的 Host
    
11.         proxy_set_header X-Real-IP $remote_addr; # 传递真实客户端 IP
    
12. }
    
13. }

复制代码

这里最重要的是proxy_set_header Host $host:8888，这个端口号非常重要，这是公网https访问时使用的端口号。这里不写端口，会导致Nginx跳转后的URL缺少端口号。


重要：不要用各种顶级高手的正则表达式overwrite URL。用最小化修改实现的功能往往是最全面最完整的。修改越多，可能埋的雷越多。

ownCloud的配置文件中，不需要添加trusted_proxies。不需要更改overwrite.cli.url，我这里是

1.   'overwrite.cli.url' => 'https://192.168.1.24/',
   

复制代码

小结
至此，应该可以在公网用浏览器访问ownCloud了，且https的证书是Let's Encrypt的有效证书。

访问时的流程：

• 浏览器访问网址https://ted.ddns.net:8888；
• ddns服务将ted.ddns.net域名指向家庭宽带的公网动态ipv4；
• 主路由收到访问请求后，依照端口映射规则，将来自公网8888端口的请求转发至内网Nginx服务器（ip=192.168.1.2）的443端口；
• Nginx使用Let's Encrypt证书响应，并将请求转发至内网的ownCloud服务器（ip=192.168.1.24）的443端口；
• ownCloud服务器上的apache2提供服务。
  

关于证书自动更新
Let's Encrypt的证书有效期只有90天，需要定期更新。
手动更新是可以的，但是不方便。

目前用Ubuntu+lego+nginx搞定了证书自动更新：每天检查；证书到期前10天更新证书。
暂时dry run通过了，就看80天后自动更新的效果了。

等有时间写自动更新的部分。

---

作者: kn69968    时间: 2024-12-26 14:33
棒棒棒棒棒棒棒棒棒棒棒棒棒棒棒!!!!!

---

作者: elvba    时间: 2024-12-26 15:03
这么来说的话，你把 nginx 改成

1. server {
   
2.     listen 8888 ssl;

复制代码

路由器上端口映射也改为 8888 到 8888 ，那么 nginx 那里就不需要加

1. proxy_set_header Host $host:8888;

复制代码

去改 Host 了。

---

作者: jimmy203308    时间: 2024-12-26 15:08
其实可以多用用docker，Windows Server 2016不知道能不能安装docker，docker版本NPM自带ssl申请和反代，可以自动定期更新ssl证书，不知楼主需要用到owncloud哪些功能，owncloud也有docker版本，这样整体架构就简单很多，WinServer下跑几个docker应用，实现需求，通过映射文件夹管理ssl证书，运维也简单很多

---

作者: elvba    时间: 2024-12-26 15:09
对的，最后你会发现你还需要一个自动续签证书的东西。
所以，推荐 Nginx Proxy Manager，这个好用，可以自动帮你管理证书，自动帮你通过 dns 服务商做证书验证，自动更新 nginx 的证书配置。

---

作者: mysky    时间: 2024-12-26 15:53
ssl证书这个东西，现在几家服务商都只给90天免费了，折腾个半天太麻烦了，还是选择tb十几块搞定一年的。。。

---

作者: tedaz    时间: 2024-12-26 16:40

jimmy203308 发表于 2024-12-26 15:08
其实可以多用用docker，Windows Server 2016不知道能不能安装docker，docker版本NPM自带ssl申请和反代，可 ...

Windows Server可以运行docker：直接运行windows构架的docker，通过hyper-v虚拟化运行linux构架docker。

尝试过ownCloud的docker，一直没弄明白docker如何扩容，或者如何让docker直接使用宿主上的文件夹作为ownCloud的存储空间。

hyper-v的unbuntu装ownCloud就比较简单，直接暴力的建立一个100TB的vhd。ownCloud安装时就用默认路径，直接用“/”。后来需要扩容，将vhd扩展到200TB，然后ubuntu运行Gparted扩展一下就好。

---

作者: tedaz    时间: 2024-12-26 16:42

elvba 发表于 2024-12-26 15:03
这么来说的话，你把 nginx 改成

试过了，改server块的listen不管用。跳转后的URL是没有端口号的。

只有在proxy_set_header Host $host添加“:8888”才能让跳转后的URL带有端口号。

---

作者: tedaz    时间: 2024-12-26 16:45

elvba 发表于 2024-12-26 15:09
对的，最后你会发现你还需要一个自动续签证书的东西。
所以，推荐 Nginx Proxy Manager，这个好用，可以自 ...

NPM有非docker的版本吗？

感觉这东西完全没必要做成docker。
理论上一个可执行程序就行了。

---

作者: tedaz    时间: 2024-12-26 16:46

mysky 发表于 2024-12-26 15:53
ssl证书这个东西，现在几家服务商都只给90天免费了，折腾个半天太麻烦了，还是选择tb十几块搞定一年的。。 ...

淘宝一年后还是要手动更新，不如自动更新方便。
已经用Ubuntu+lego+nginx搞定了证书自动更新，每天检查，证书到期前10天更新证书。目前dry run通过了，就看80天后自动更新的效果了。

---

作者: elvba    时间: 2024-12-26 17:38

tedaz 发表于 2024-12-26 16:45
NPM有非docker的版本吗？

感觉这东西完全没必要做成docker。

NPM 是专门给 docker 用的，以前没有的时候也得自己手撸，有了之后方便很多。

你折腾这么多真的不如多用下 docker，其实难度比你折腾的这些还要小的。

docker 直接用 -v 就可以挂载宿主机的文件夹作为 owncloud 的存储空间，-v 就是映射本地的目录到 docker 里面的目录， -p 就是映射本地的端口到 docker 里面的端口，然后就没了，这不比你开虚拟机再去单独部署简单的多。

---

作者: mysky    时间: 2024-12-26 22:31

tedaz 发表于 2024-12-26 16:46
淘宝一年后还是要手动更新，不如自动更新方便。
已经用Ubuntu+lego+nginx搞定了证书自动更新，每天检查， ...

问题是我需要证书部署在几个别的地方，还得同步也是个麻烦事。。。

---

作者: 红色狂想    时间: 2024-12-26 22:33
提示: 作者被禁止或删除 内容自动屏蔽

---

作者: goat    时间: 2024-12-26 22:45
内网设备证书只能特定服务商的表示我还是手动更吧
另外个人倾向泛域名，这样一般人基本一个证书全搞定了

---

作者: lasx    时间: 2024-12-27 00:36
我一直在aio上的黑裙里申请的证书，然后给docker里面的服务开反代就好了，都有https

---

作者: tedaz    时间: 2024-12-27 10:21

elvba 发表于 2024-12-26 17:38
NPM 是专门给 docker 用的，以前没有的时候也得自己手撸，有了之后方便很多。

你折腾这么多真的不如多用 ...

试了一下，NPM支持的ddns太少了，没有我在用dyn、dynv6，这个有什么办法吗，比如装个NPM的插件？

看github上有discussion，2022年就有人提出添加dynv6，https://github.com/NginxProxyMan ... er/discussions/2488
到现在还没加上，这是不打算添加的样子。

(, 下载次数: 49)

上传

点击文件名下载附件

---

作者: tedaz    时间: 2024-12-27 10:24

mysky 发表于 2024-12-26 22:31
问题是我需要证书部署在几个别的地方，还得同步也是个麻烦事。。。

不是很明白你的意思。

一个证书只能绑定一个域名，就家用来说，一个域名只能帮顶一个公网ipv4。这个公网ipv4也就是家里主路由的wan口ip。
然后内网nginx服务器使用一个证书，就可以反向代理局域网的多个内网地址、多个内网服务。

为什么说还要同步到别的地方呢？

---

作者: chip_discovery    时间: 2024-12-27 10:26
owncloud 我记得是把文件打散了存储吧，对普通家用来说，是不是出了问题文件恢复起来又难了点

---

作者: tedaz    时间: 2024-12-27 10:26

红色狂想 发表于 2024-12-26 22:33
ownCloud和Joplin哪个强大好用呀？

这两个是不同的东西吧。
ownCloud是用于同步海量文件的，而且实际测试下来，ownCloud官方原版非常robust；nextcloud同步海量文件会出错，即使暂停同步确保文件拷贝完成后再开启同步，nextcloud依然有很大几率会出错，几乎没法用于海量、大型文件的同步。

Joplin类似于WordPress，是写笔记、写博客的。

---

作者: mhggpo    时间: 2024-12-27 10:26

tedaz 发表于 2024-12-27 10:21
试了一下，NPM支持的ddns太少了，没有我在用dyn、dynv6，这个有什么办法吗，比如装个NPM的插件？

...

使用Lucky可以快速解决问题

---

作者: tedaz    时间: 2024-12-27 10:32

chip_discovery 发表于 2024-12-27 10:26
owncloud 我记得是把文件打散了存储吧，对普通家用来说，是不是出了问题文件恢复起来又难了点 ...

这不是问题。一方面最近十来年的使用，ownCloud没出过问题。另一方面，即使ownCloud崩了，也只需要新建虚拟机重装ownCloud，然后用本地的文件重新同步到ownCloud服务器就行了。

---

作者: tedaz    时间: 2024-12-27 10:34

mhggpo 发表于 2024-12-27 10:26
使用Lucky可以快速解决问题

Lucky是什么，也是nginx的docker吗，有完整的名字或关键字吗？
我用google搜索Lucky，Lucky let's encrypt，Lucky nginx都搜不出来啊。

---

作者: mysky    时间: 2024-12-27 10:44

tedaz 发表于 2024-12-27 10:24
不是很明白你的意思。

一个证书只能绑定一个域名，就家用来说，一个域名只能帮顶一个公网ipv4。这个公网 ...

有些服务在一个内网但不在一个服务器上，在不同虚拟机

---

作者: mhggpo    时间: 2024-12-27 10:54

tedaz 发表于 2024-12-27 10:34
Lucky是什么，也是nginx的docker吗，有完整的名字或关键字吗？
我用google搜索Lucky，Lucky let's encryp ...

用go写的反代
docker镜像：gdy666/lucky:latest

---

作者: tedaz    时间: 2024-12-27 10:58

mysky 发表于 2024-12-27 10:44
有些服务在一个内网但不在一个服务器上，在不同虚拟机

nginx就是为了满足你这种需求的啊。

所有https访问都会先到nginx，然后nginx用证书相应，并按照nginx的配置文件，将访问转发到多个内网服务器、多个服务。

---

作者: mysky    时间: 2024-12-27 11:01

tedaz 发表于 2024-12-27 10:58
nginx就是为了满足你这种需求的啊。

所有https访问都会先到nginx，然后nginx用证书相应，并按照nginx的 ...

我不是所有机都适合nginx，而且服务多了网络阻塞。

---

作者: tedaz    时间: 2024-12-27 11:10

mhggpo 发表于 2024-12-27 10:54
用go写的反代
docker镜像：gdy666/lucky:latest

试了一下，这玩意儿是个ddns客户端，然后集成了所有功能并强制同时使用它的所有功能。这也太霸道了。

我不需要lucky管理、更新ddns。可以用lucky仅申请证书、做nginx转发吗？

---

作者: highchh    时间: 2024-12-27 11:13

tedaz 发表于 2024-12-27 11:10
试了一下，这玩意儿是个ddns客户端，然后集成了所有功能并强制同时使用它的所有功能。这也太霸道了。

我 ...

可以，我就是ddns在ikuai上，只做证书更新和反代。

---

作者: tedaz    时间: 2024-12-27 11:19

highchh 发表于 2024-12-27 11:13
可以，我就是ddns在ikuai上，只做证书更新和反代。

能简单说下从哪个菜单进入证书申请吗？
官方教程没有文字版证书申请，视频也没有有包含“证书”关键字的。

---

作者: highchh    时间: 2024-12-27 11:26


https://post.色魔张大妈.com/p/awz4dnrk/
安全管理里面，添加证书。

---

作者: mhggpo    时间: 2024-12-27 11:27

tedaz 发表于 2024-12-27 11:19
能简单说下从哪个菜单进入证书申请吗？
官方教程没有文字版证书申请，视频也没有有包含“证书”关键字的 ...

左上角菜单直接能看到SSL/TLS证书

---

作者: elvba    时间: 2024-12-27 13:53

tedaz 发表于 2024-12-27 10:21
试了一下，NPM支持的ddns太少了，没有我在用dyn、dynv6，这个有什么办法吗，比如装个NPM的插件？

看gith ...

去买那种便宜的域名，比如几十块钱就 10 年的数字 xyz 域名，我就是买的这个，之后你想怎么解析就怎么解析，多方便，这样就不会受制于免费的域名服务商了。

如果你只是为了能访问内网的服务，那我最推荐用 tailscale，安装到想要互相访问的设备即可，什么都不用配置，机器名加端口访问就完事。

---

作者: tedaz    时间: 2024-12-27 13:55

mhggpo 发表于 2024-12-27 10:54
用go写的反代
docker镜像：gdy666/lucky:latest

---

作者: tedaz    时间: 2024-12-27 14:01

elvba 发表于 2024-12-27 13:53
去买那种便宜的域名，比如几十块钱就 10 年的数字 xyz 域名，我就是买的这个，之后你想怎么解析就怎么解 ...

不是的。

首先，真正固定的域名限制更多，我之前买过，后来没法被国内dns解析了。并不是我是域名有什么问题，而是某些域名被正则表达式模糊匹配后国内就不给解析了。这是选择ddns主要原因。

其次，访问内网访问也早就解决了。

目前只是希望在原来的基础上更进一步，让https能有一个有效的证书，特别是为了Moon Reader的webdav同步。

到目前为止，似乎就lego+nginx支持的ddns最多，而且迭代非常快，新的、支持TXT的ddns都会被快速添加，从这个角度说，lego比NPM好些。
lego已经实现了我的需求。

在测试lucky，这玩意儿是大全型的，而且不透明。又卡在URL带端口号这个问题上了，无论怎么设置都不行。

---

作者: 英雄哥    时间: 2024-12-27 14:17

tedaz 发表于 2024-12-27 13:55
试了下，搞不定公网URL带端口号的映射。

我的公网访问为https://ted.ddns.net:8888

我的lucky用的很好啊，根据官网教程一步步就行了。 (, 下载次数: 44)

上传

点击文件名下载附件

---

作者: mhggpo    时间: 2024-12-27 14:18

tedaz 发表于 2024-12-27 13:55
试了下，搞不定公网URL带端口号的映射。

我的公网访问为https://ted.ddns.net:8888

你的图片和文字内容描述的不一样，建议再检查一下

---

作者: tedaz    时间: 2024-12-27 14:52

英雄哥 发表于 2024-12-27 14:17
我的lucky用的很好啊，根据官网教程一步步就行了。

你的公网访问链接是带端口号的吗？
再就是你的lucky是在主路上直接监听16666，还是lucky在单独的内网机器上？

---

作者: tedaz    时间: 2024-12-27 14:54

mhggpo 发表于 2024-12-27 14:18
你的图片和文字内容描述的不一样，建议再检查一下

已经更正，但还是不行。

URL带端口号的话，lucky应该怎么设置？

---

作者: mhggpo    时间: 2024-12-27 15:08

tedaz 发表于 2024-12-27 14:54
已经更正，但还是不行。

URL带端口号的话，lucky应该怎么设置？

确认申请证书的域名和你访问的域名是否匹配

---

作者: 英雄哥    时间: 2024-12-27 15:34

tedaz 发表于 2024-12-27 14:52
你的公网访问链接是带端口号的吗？
再就是你的lucky是在主路上直接监听16666，还是lucky在单独的内网机器 ...

公网链接带端口号；lucky放在旁路由上的；旁路由是在群晖的docker上；所以我的16666端口，要先在主路由上映射到旁路由上，再在旁路由的防火墙映射到群晖的ip地址。

---

作者: elvba    时间: 2024-12-27 15:36

tedaz 发表于 2024-12-27 14:01
不是的。

首先，真正固定的域名限制更多，我之前买过，后来没法被国内dns解析了。并不是我是域名有什么 ...

没太明白“某些域名被正则表达式模糊匹配后国内就不给解析了”，你是说泛解析？

我觉得你对 ddns 的理解有问题，ddns 本质就是通过调用接口的方式让 dns 解析服务商把域名的解析到你的 ip 上，和你直接用 curl 调用一次接口没任何区别，并不是说你买了域名就不能用 ddns，能不能用 ddns 核心在 dns 服务商有没有开放这个接口。

举例你现在用的 dyn。
那就是 dyn 给你一个免费的二级域名，然后你可以用 ddns 的方式，去设置 dyn 给你的二级域名解析的 ip。

国外买域名，然后用 dnspod 做解析，也不用备案，dnspod 只要是个 ddns 工具都支持的。

另外使用 ddns 最好地方是在你拨号的路由器，用路由器自带的 ddns 工具：
1. 只有这样才能获取到最准确的 ip，别的工具都是去调用查询本机 ip 的网站或者接口来查询你的 ip，这个时候获取到的 ip 地址不一定就是你的公网 ip，换句话说，这类工具可以做到随意把你的域名解析到一个骗人用的 ip 地址去。
2. 能实现公网 ip 变了之后马上就配置域名解析，你用别的方式就只有去定时比如每隔一个小时去执行一次，实时性差了很多的。

---

作者: tedaz    时间: 2024-12-27 15:48

mhggpo 发表于 2024-12-27 15:08
确认申请证书的域名和你访问的域名是否匹配

是匹配的，现在是访问不通，不是证书错误之类的，应该是lucky的映射写的不对，但是不知道应该怎么写

---

作者: tedaz    时间: 2024-12-27 15:52

elvba 发表于 2024-12-27 15:36
没太明白“某些域名被正则表达式模糊匹配后国内就不给解析了”，你是说泛解析？

我觉得你对 ddns 的理解 ...

简单来说，就是被qiang了。买的域名被qiang就需要重新购买新域名，ddns服务商的免费域名被qiang了，随便再注册个新的就行了。

我的思路是，解决方案必须有灵活性、机动性，不能只有唯一路径。

我现在的构架就是在openwrt主路由上使用openwrt的ddns工具更新域名ip。

但是这几天在尝试https ssl证书。因为公网ipv4 80、443被封锁，只能使用dns验证的方式申请证书。

dns验证申请证书需要ddns支持TXT记录，同时需要证书工具（比如lego、NPM等）支持对应的支持TXT记录的ddns，这样的话就导致NPM无法使用了。

---

作者: mhggpo    时间: 2024-12-27 15:52

tedaz 发表于 2024-12-27 15:48
是匹配的，现在是访问不同，不是证书错误之类的，应该是lucky的映射写的不对，但是不知道应该怎么写 ...

建议加官网QQ群反馈

---

作者: tedaz    时间: 2024-12-27 15:54

mhggpo 发表于 2024-12-27 15:52
建议加官网QQ群反馈

这玩意儿不好用，本b站很多东西类似，没有资料，黑箱一个，然后什么都是扫码加群……

话说，windows版docker desktop怎么修改已经生成的container的json文件呢，只能在UI上看到RAW json，但是不允许修改。

---

作者: elvba    时间: 2024-12-27 16:09

tedaz 发表于 2024-12-27 15:52
简单来说，就是被qiang了。买的域名被qiang就需要重新购买新域名，ddns服务商的免费域名被qiang了，随便 ...

你做了啥把域名给 qiang 了 我买过的域名都没被墙过。

那你可以用 lego 专门做证书验证，然后把 lego 获取的证书拿去给 nginx 用，然后再用别的 ddns 工具去配置 dns 解析，我看 dyn 官方有提供 ddns 工具：https://help.dyn.com/update-clients/

---

作者: tedaz    时间: 2024-12-27 16:14

elvba 发表于 2024-12-27 16:09
你做了啥把域名给 qiang 了 我买过的域名都没被墙过。

那你可以用 lego 专门做证书验证，然后把 lego 获 ...

我啥都没干，被正则表达式qiang的。

现在就是用lego+nginx，可以申请、自动更新证书，没啥问题，但这东西是一个命令搞定的，没用docker不够高级、不够时尚。

很多人推荐各种新式武器，于是就想试试NPM、Lucky等高级东西，但现在这两个都没搞定。NPM因为不支持dynv6卡壳了；Lucky因为不会设置卡壳了。

---

作者: highchh    时间: 2024-12-27 16:25
测了一下你tedaz.dynv6.net的8888端口没有开放。你先检查一下端口开放的问题。

---

作者: tedaz    时间: 2024-12-27 16:30

highchh 发表于 2024-12-27 16:25
测了一下你tedaz.dynv6.net的8888端口没有开放。你先检查一下端口开放的问题。

是的，tcping不通。
主路由端口转发，如果转发到其他主机，测试就是通的。
转发到lucky就不通了，应该是lucky没能正常的监听。
windows防火墙已经关闭，在lucky的电脑上用其他程序监听tcp，测试是可以通过的。

所以现在问题就出在docker 和/或 lucky上。

想修改container的配置文件，我用的windows版docker desktop，不知道如何修改container的配置文件。

---

作者: tedaz    时间: 2024-12-27 17:08

highchh 发表于 2024-12-27 16:25
测了一下你tedaz.dynv6.net的8888端口没有开放。你先检查一下端口开放的问题。

我现在直接用纯内网测试lucky

---

作者: Charles-Lee    时间: 2024-12-27 17:33
syno-acme脚本更新证书更便捷

---

作者: elvba    时间: 2024-12-27 17:51

tedaz 发表于 2024-12-27 16:14
我啥都没干，被正则表达式qiang的。

现在就是用lego+nginx，可以申请、自动更新证书，没啥问题，但这东 ...

我还是不能理解正则表达式和域名被qiang怎么关系上的，有种在看意大利面拌42号混凝土的感觉。

---

作者: tedaz    时间: 2024-12-27 17:58

elvba 发表于 2024-12-27 17:51
我还是不能理解正则表达式和域名被qiang怎么关系上的，有种在看意大利面拌42号混凝土的感觉。 ...

这就不能细说了

---

作者: tedaz    时间: 2024-12-27 17:59

Charles-Lee 发表于 2024-12-27 17:33
syno-acme脚本更新证书更便捷

这个仅限于群晖集成吧，没法跟普通的ububtu nginx自动集成证书。

---

作者: elvba    时间: 2024-12-27 18:03

tedaz 发表于 2024-12-27 16:14
我啥都没干，被正则表达式qiang的。

现在就是用lego+nginx，可以申请、自动更新证书，没啥问题，但这东 ...

NPM 相当于 lego + nginx，解决的是自动更新证书，证书验证，nginx 配置的问题，和 ddns 没关系。

dyn 有提供官方的 ddns 工具：https://help.dyn.com/update-clients/

任何 docker 可以跑的东西，你都可以不用 docker 跑，不存在 docker 高级时尚一说，包括 NPM、Lucky ，他们的文档里都有手动安装和运行的方式。

---

作者: tedaz    时间: 2024-12-27 18:09

elvba 发表于 2024-12-27 18:03
NPM 相当于 lego + nginx，解决的是自动更新证书，证书验证，nginx 配置的问题，和 ddns 没关系。

dyn  ...

NPM不支持dynv6的域名，而免费ddns服务商支持TXT记录的本就不多，而且NPM也没有打算添加dynv6支持。我只是说了这个事实，看看有没插件之类能解决这个问题。

所有这些都没有直接联系，但将各种限制条件综合起来，就有间接联系了。

dyn和dynv6是两个不同的ddns服务商。

另外说的是NPM不支持用dynv6的ddns域名申请证书，而不是ddns客户端功能。

现在要寻找很多很好解决方案的是，用ddns域名申请和自动更新证书给nginx或者其他反向代理工具。

---

作者: elvba    时间: 2024-12-27 18:16

tedaz 发表于 2024-12-27 18:09
NPM不支持dynv6的域名，而免费ddns服务商支持TXT记录的本就不多，而且NPM也没有打算添加dynv6支持。我只 ...

那个 lucky 我觉得没必要继续折腾了，看了下作者的最新版本也不开源。

就下载 dyn 的客户端呗，你用的是 window 虚拟机，就下载他的 windoes 客户端，安装完应该就行了。

---

作者: elvba    时间: 2024-12-27 18:28

tedaz 发表于 2024-12-27 18:09
NPM不支持dynv6的域名，而免费ddns服务商支持TXT记录的本就不多，而且NPM也没有打算添加dynv6支持。我只 ...

dyn 和 dynv6 还是两家呀，我还以为是同一家。

我也并不是一定要你用 NPM 哈，你用  lego + nginx 已经能解决证书的问题了，那剩下的就是 dns 解析问题。

我找了一个支持 dynv6 更新 dns 解析的工具，还可以自定义，以后你用新的 ddns 服务商也可以自己配置即可：

https://github.com/timothyye/godns

dynv6 的参考配置： https://github.com/timothyye/godns?tab=readme-ov-file#dynv6


那 dyn 就用他们官方的工具，安装运行就行，dynv6 就用我上面发的 godns。
godns 可以自定义，也可以看 dyn 的 api 文档自己配置 dyn 的解析。

---

作者: tedaz    时间: 2024-12-27 19:13

elvba 发表于 2024-12-27 18:28
dyn 和 dynv6 还是两家呀，我还以为是同一家。

我也并不是一定要你用 NPM 哈，你用  lego + nginx 已经 ...

谢谢回复。
其实我已经用openwrt的ddns客户端，lego+nginx完美解决了证书申请、自动更新证书。

只是在继续探索更多、更好的解决方案。

过程中发现NPM确实不错，但是竟然不支持dynv6这个非常普及、功能非常全的ddns，就描述试试，并看看有没有插件之类的。

这里是lego的支持列表，https://go-acme.github.io/lego/dns/
dynv6是标准的RFC2136，lego将其归为RFC2136，命令类似于这样

1. RFC2136_NAMESERVER=127.0.0.1 \
   
2. RFC2136_TSIG_KEY=example.com \
   
3. RFC2136_TSIG_ALGORITHM=hmac-sha256. \
   
4. RFC2136_TSIG_SECRET=YWJjZGVmZGdoaWprbG1ub3BxcnN0dXZ3eHl6MTIzNDU= \
   
5. lego --email you@example.com --dns rfc2136 -d '*.example.com' -d example.com run

复制代码

NPM看起来很美，可惜不支持dynv6，也不支持RFC2136。

实测Lucky可以申请dynv6的证书，但是Lucky不好用。

就看还有没有其他的方案了，或者现有方案有插件之类的办法也行。

---

作者: elvba    时间: 2024-12-27 21:52

tedaz 发表于 2024-12-27 19:13
谢谢回复。
其实我已经用openwrt的ddns客户端，lego+nginx完美解决了证书申请、自动更新证书。

NPM 也支持 RFC2136

(, 下载次数: 52)

上传

点击文件名下载附件

dynv6 的参考配置：

1. # Target DNS server
   
2. dns_rfc2136_server = ns1.dynv6.com
   
3. # TSIG key name
   
4. dns_rfc2136_name = tsig-299015.dynv6.com
   
5. # TSIG key secret
   
6. dns_rfc2136_secret = TtW8XESzg5bhirg4/RHRUSORrACQz+BBX2qe5LkrX7yW94s9KB5dW0EIXh0eGGQNNYgoBzg8A7QF3+6y7/cezw==
   
7. # TSIG key algorithm
   
8. dns_rfc2136_algorithm = HMAC-SHA512

复制代码

NPM
- dyn： 不支持
- dynv6：支持，使用 RFC2136

lego
- dyn：支持
- dynv6: 支持，通过 RFC2136

---

作者: 寒山湖    时间: 2024-12-28 06:23
收藏，学习，折腾……

---

作者: qjj2857    时间: 2024-12-28 11:48

tedaz 发表于 2024-12-27 14:01
不是的。

首先，真正固定的域名限制更多，我之前买过，后来没法被国内dns解析了。并不是我是域名有什么 ...

moonreader 只传输进度，纯文本格式的，为啥要上 https？我现在是 ftp 协议，你这么一说我有点慌

---

作者: highchh    时间: 2024-12-30 08:56

tedaz 发表于 2024-12-27 17:08
我现在直接用纯内网测试lucky，lucky在192.168.22.186上用windows docker desktop运行。
owncloud在192.1 ...

前端地址不用写端口号，端口的设置在web设置规则里面已经填过了。

---

作者: tedaz    时间: 2024-12-30 13:46

elvba 发表于 2024-12-27 21:52
NPM 也支持 RFC2136

谢谢，终于用NPM申请dynv6域名的证书成功了。
但是NPM还是不会设置。

---

作者: tedaz    时间: 2024-12-30 22:19

qjj2857 发表于 2024-12-28 11:48
moonreader 只传输进度，纯文本格式的，为啥要上 https？我现在是 ftp 协议，你这么一说我有点慌 ...

我以前就是用ftp同步进度的，除了响应速度稍微慢于webdav，其他没什么问题。当然，可能是我搭建ftp的技术不行。

MoonReader的书籍同步太鸡肋了，会把所有文件同步到一个文件夹，不能保留手机的上树形目录结构，几乎没什么实用性。如果可以保留树形结构的话，MoonReader的书籍同步好挺有用的。

---

作者: qjj2857    时间: 2024-12-30 22:42

tedaz 发表于 2024-12-30 13:46
谢谢，终于用NPM申请dynv6域名的证书成功了。
但是NPM还是不会设置。

我还没有你那么庞大的数据，都是直接搜书名的。。。。你有没有找到替代品啊？

---

作者: kakkk    时间: 2025-1-21 11:56

tedaz 发表于 2024-12-27 15:52
简单来说，就是被qiang了。买的域名被qiang就需要重新购买新域名，ddns服务商的免费域名被qiang了，随便 ...

我几年前在阿里云30元申请了一个域名，十年期，好用。同样公网ipv4 80、443被封锁，只能使用dns验证的方式申请证书。现在windows server 2021上用docker desktop部署ddns和NPM，一切使用正常。

路由器上转发端口12345到部署NPM的443端口，实现的效果：
1、https://photo.AAA.com:12345，访问局域网内 192.168.1.6：2283，immich相册。

2、https://Bitwarden.AAA.com:12345，访问局域网内 192.168.1.10:8080，Bitwarden 密码库

3、https://AAA.com:12345，返回一个404页面，防小人撞墙。

---

欢迎光临 Chiphell - 分享与交流用户体验 (https://www.chiphell.com/)

Powered by Discuz! X3.5