群晖NAS再折腾

端口转发

两年前我买了一台双盘位的群晖NAS，配置两个4T的硬盘，这玩意儿一度改变了我使用电脑的模式，真是爽爆了！最最主要的功能就是我能用它规整我所有的资料，并且不管何时何地，只要有网就能访问。为了能够做到这点，我需要一些网络配置，这就是：端口转发。(或者称作“虚拟服务器”)

这是我家网络的结构图：

群晖NAS放在我家的内网中，网段是192.168.1.0/24，家用路由器的WAN口连着光猫，组成了“上级网络”，网段是192.168.0.0/24，光猫具有一个公网地址，这个地址是动态分配的。在外网要访问NAS，就得通过光猫，将网络包转到家用路由器，再通过家用路由器转到NAS，很显然，这里面有两次转发。

你也许这时候有疑问了，为什么NAS和台式机不直接接上光猫？这样能省一个网络节点啊？不这么干的原因是：
1，光猫的WIFI功能垃圾透顶，多连几台设备就卡壳
2，光猫作为路由器的功能太弱，可玩性太差，用来管理设备各种不便

你也许还有另一个疑问，为什么不把光猫接到家用路由器的LAN口上，使得所有局域网设备在同一个内网中？这样设置端口转发也只需要设置一次转发即可。像这样：

嗯，好问题，事实上我也这样玩过，但很快发现这样做之后，家用路由器就丧失了很多功能，比如流量监控，还有许多网管功能，都已经失效，因为路由器设计的时候，这些功能都是针对WAN口的控制，如果数据不流经WAN口，路由器不认为各个设备在访问外网，这样的连接方式相当于是将路由器当做一个普通交换机+一个无线AP来用了。

所以，我把光猫WIFI关掉，DHCP关掉，手动设置了光猫的网络地址192.168.0.1，手动设置家用路由器的WAN口地址为静态IP，192.168.0.2，以及LAN地址为192.168.1.1，打开家用路由器的DHCP功能，设置DHCP的范围是192.168.1.2-192.168.1.99。

光猫端口转发设置：

就是说把对外网地址的5000端口的TCP包转发到192.168.0.2的5000端口去。也许你想知道我为什么能登录到光猫去设置，这是因为我跟电信的人要了光猫的管理密码:P

接着是家用路由器的设置，类似的：

这样，假设公网动态IP地址是：101.202.15.46(我瞎写的)，那么我对http://101.202.15.46:5000的访问，就被最终转到内网的http://192.168.1.200:5000去。

这样就能在外网访问群晖的DSM界面了。

DDNS

很显然，101.202.15.46这个地址不便记忆，且有可能会变动，所以我们还需要个“动态域名解释”，说起动态域名解释服务，有大家耳熟能详的“花生壳”，当然，这次我没用花生壳，群晖自己就有提供这个服务，可以在群晖的控制面板-外部访问-DDNS中配置：

一旦完成，你就可以使用http://yourname.synology.me:5000来访问你的DSM管理界面了。

另外DDNS的服务商有很多，找一个能用的就够了，弄多个反倒麻烦。

值得注意的是，有一种情况会导致你的DDNS配置不成功，那就是你的宽带根本没有公网地址，这个并不奇怪，你的手机连3G、4G上网，手机的地址就不是公网地址，它是移动/联通的一个局域网地址，不信自己去看看。很明显，DDNS将域名解释到这么一个局域网地址是没有任何意义的。如果是这种情况的话，就得用反向代理了，原理是你的NAS跟一台有公网地址的主机保持一个数据通道，DDNS将域名解释到这台公网主机的地址去，公网主机通过数据通道将数据转发到你的NAS上来，显然，这种做法很低效，并且对公网主机造成的开销较大，所以一般都是要收取一定费用的，花生壳等提供了这类服务，群晖的QuickConnect也是类似这种服务，群晖是免费的，但用起来感觉不是很稳定，并且速度很慢。

SSL证书

下一个问题，我要用https访问我的DSM界面：https://yourname.synology.me:5001。

但我自签的证书浏览器不认，会阻止一般的用户访问，比如你想让你的家人/同事也用NAS，他们一打开就看到证书无效，然后就没有然后了。

解决方法是让浏览器认这个证书，将根证书安装到访问者的电脑上即可。但这种方法不好，第一很麻烦，第二如果使用移动设备(手机平板之类)的话，就很难弄。于是你要给自己的域名搞一张证书，一看，都是收费的，且麻烦一大堆，遂放弃。

其实现在已经有一个完美的解决方案，那就是Let' Encrypt，这是它的官方站点：https://letsencrypt.org/

通过它，我们能获取到免费的证书，且非常好用，唯一的问题是有效期比较短，但要续也很简单。

如果你用的是群晖，你甚至都不需要什么复杂的注册和配置的过程，仅仅在“控制面板-安全性-证书”这页面中点几下，一张有效的证书很快就能部署完成。

这样你和你的小伙伴就能愉快地在外网访问这个地址了：https://yourname.synology.me:5001

关于Let's Encrypt的更多配置，请参考它的官网，总之这个是个好东西。

局域网里直接用域名访问

局域网里直接用域名访问你的NAS，可行不？试试看，你很快发现不可行，不可行就换回用内网IP地址访问即可，如果你不想折腾，就到此为止。如果想折腾或者了解下为什么，就接着往下看。

这是一个困扰了我很久的问题，这个问题简单描述为：为什么我不能用公网地址访问本地服务器？

这又是一个非常非常常见的问题，公司里有一台服务器，地址是192.168.1.200，我们通过端口转发，使得外网能通过101.202.15.46这个公网IP地址来访问这台服务器，当然通过域名访问也是一样的，域名就被解释为101.202.15.46嘛。现在我的工作电脑(192.168.1.100)想通过域名访问这台服务器，会出现什么状况？

我先把网络结构简化成这个样子：

过程描述如下：

1，工作电脑，要访问服务器，于是跟路由器说：“我要访问http://101.202.15.46:80”,
2，路由器接到请求，看到地址原来就直接是自己的公网地址，于是按照端口转发的配置规则，将请求转到192.168.1.200:80去(注意，这个时候数据包并未流经公网)
3，服务器收到请求后要给客户端返回数据，如何返回？当然是根据原地址来了，由于数据包并未流经公网(未经过NAT)，所以源地址是192.168.1.100，于是告诉路由器，我要发数据包到192.168.1.100去
4，路由器一看，这不就是内网地址么？于是直接将数据包丢给了工作电脑，工作电脑收到了数据包

嗯？表面上看数据包有来有回，应该可以，事实上不行——工作电脑尝试跟101.202.15.46建立连接，但收到的包却来自192.168.1.200，TCP连接无法成功建立，通信失败。这个问题又有另外一个常见的称呼，叫：IP回流。大家搜一下就能收到。

如何解决这个问题？

方法一：增加一个外网路由设备(称之为路由器B吧，原先路由器叫路由器A)，并在路由器A上配置这么一条路由规则：当来自内部的主机尝试访问101.202.15.46:80时，将数据包转发到路由器B，路由器B收到数据包后再按正常操作把数据包转回给路由器A，数据包走向大致这样：

红色箭头是去，蓝色箭头是回，路由器B就充当了一个外部的中转站。当然了，实际的情况可能不需要额外的一个设备，但由于我只是有所了解，没有实际操作过，所以也写不出更具体的内容了，若有不对，请不吝赐教。

方法二：将内网要访问的yourname.synology.me域名解释为192.168.1.200，然后……搞定！

显然方法二比方法一直截了当得多，这也是我认为的“正统方法”。怎么配这个域名解释？最简单的方法是直接修改自己电脑上的hosts文件，这样不需要找公司的IT，自己就能搞定。但电脑上能弄弄，手机上呢？再说这么多电脑，要一台台配置么？还有如果你用的是笔记本，哪天拿到外网去办公了，是不是又要把hosts文件改回来？

所以，最好的方法，还是在路由器上配置，我家的路由器(ASUS RT-AC86U，刷了梅林固件)就可以配。具体方法如下：

1，先开启路由器的SSH功能(过程略)
2，SSH登录至路由器
3，创建文件/jffs/dnsmasq.conf.add，内容是：

addn-hosts=/jffs/configs/hosts

4，创建文件/jffs/configs/hosts，内容是：

192.168.1.200 yourname.synology.me

5，重启Dnsmasq服务

service restart_dnsmasq

搞定。这时候你试着在电脑上看看yourname.synology.me解释到哪里去了

nslookup yourname.synology.me

也许还是外网地址，这是因为dns缓存的缘故，你清一下就好了

ipconfig /flushdns

最后

折腾，有时候不在于直接产生了多少价值，还在于在这个过程中真正学到了些东西。

原文链接：https://blog.csdn.net/anw53724/article/details/101591888?ops_request_misc=&request_id=&biz_id=&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~koosearch~default-23-101591888-null-null.268%5Ev1%5Ekoosearch&utm_term=NAS%E3%80%81%E7%BE%A4%E6%99%96%E3%80%81%E9%98%BF%E9%87%8C%E4%BA%91%E3%80%81%E5%9F%9F%E5%90%8D%E8%A7%A3%E6%9E%90%E3%80%81%E5%86%85%E7%BD%91%E7%A9%BF%E9%80%8F%E3%80%81ipv6%E3%80%81ddns%E3%80%81%E8%BD%BB%E9%87%8F%E7%BA%A7%E4%BA%91%E6%9C%8D%E5%8A%A1%E5%99%A8%E3%80%81%E9%93%81%E5%A8%81%E9%A9%AC%E3%80%81%E5%A8%81%E8%81%94%E9%80%9A%E3%80%81DSM%E3%80%81DSM6.0%E3%80%81%E7%BE%A4%E6%99%96nas%E3%80%81%E4%BA%91%E6%9C%8D%E5%8A%A1%E5%99%A8%E3%80%81%E8%9C%97%E7%89%9B%E6%98%9F%E9%99%85%E3%80%81%E9%BB%91%E7%BE%A4%E6%99%96%E3%80%81docker%E3%80%81%E5%AE%B9%E5%99%A8%E9%95%9C%E5%83%8F%E3%80%81%E5%9F%9F%E5%90%8D%E6%B3%A8%E5%86%8C%E3%80%81%E5%AE%9D%E5%A1%94%E3%80%81%E5%8F%8D%E5%90%91%E4%BB%A3%E7%90%86%E3%80%81nginx%E3%80%81frp%E3%80%81%E5%8A%A8%E6%80%81%E5%9F%9F%E5%90%8D%E8%A7%A3%E6%9E%90