Tag Archives: IT

解决电视上KODI播放IPTV时无法识别IPV6地址的问题

  前一段时间《广电总局出手整治电视直播乱象,提升用户体验 》,提升的结果就是电视上一直在用了几年的“电视家”和“火星直播”两个看电视的软件,再也看不了电视了。家里办的宽带虽然附带有IPTV,但需要多一个盒子,多一个遥控,占用一个电视HDMI接口,更无法忍受的是必须连接光猫自带的WiFi热点,整个流程上的所有环节都极不优雅。

  为了在电视上不用IPTV的盒子观看IPTV,可以在KODI软件里安装IPTV插件,搜索关键字“kodi iptv设置”。大致步骤如下:

  • 设置->插件->从库安装->PVR 客户端->安装 PVR IPTV Simple Client。
  • 之后设置插件:插件->我的插件,找到刚安装的PVR IPTV Simple Client,设置中添加一个配置文件。其中M3U8播放源选择”远程路径“(指向一个https://开头的在线地址,播放源由维护者自动更新)或”本地路径“(指向比如NAS上的.m3u文件,播放源需手动更新)都可以。配置后可能需要重启KODI以生效。
  • 最后在“电视直播”中就可看到所有更新的电视节目。

  这里推荐两个我自己测试了一段时间的源,感谢维护的作者。包含央视,所有卫视,和一些国外的频道节目:

  但在电视上KODI播放时,发现了一个问题:有些节目可以正常播放,有些则不能播放,报错“一个或多个项目播放失败。更多相关信息见日志。”,类似 https://www.right.com.cn/forum/thread-8265882-1-1.html 。测试macOS的IINA软件中打开同样的.m3u文件,所有频道可正常播放。查看.m3u内容,发现无法播放的频道全部是IPV6的地址。电脑可以播放说明网络环境是支持IPV6的,问题在KODI软件里。最终搜索到了网友x3669的提供的解决办法(链接1链接2:在IPV6的源上,手动添加80端口。比如:

  • cctv1原地址:http://[2409:8087:2001:20:2800:0:df6e:eb03]/ott.mobaibox.com/PLTV/4/224/3221227896/index.m3u8
  • 修改后地址:http://[2409:8087:2001:20:2800:0:df6e:eb03]:80/ott.mobaibox.com/PLTV/4/224/3221227896/index.m3u8

  保存成.m3u文件放到NAS上,KODI中读取修改后的.m3u文件所有频道即可正常播放。为了自动更新在线的播放源到本地文件,请ChatGPT写了一个bash脚本,在家里另一个Linux机器上crontab每30分钟运行一次即可:

#!/bin/bash

# 设置下载URL和NAS存储路径
URL="https://raw.githubusercontent.com/YueChan/Live/main/IPTV.m3u"
NAS_PATH=""  # NAS上的存储路径
NAS_USER=""  # 请替换为您的NAS用户名
NAS_IP=""  # 请替换为您的NAS IP地址

# 下载最新的.m3u文件
wget -O IPTV.m3u $URL

# 检查文件是否下载成功
if [ ! -f IPTV.m3u ]; then
    echo "Failed to download file."
    exit 1
fi

# 修改文件内容
sed -i 's/]\//]:80\//g' IPTV.m3u

# 检查文件是否修改成功
if [ $? -ne 0 ]; then
    echo "Failed to modify file."
    rm IPTV.m3u
    exit 1
fi

scp -i /root/.ssh/id_rsa_nas IPTV.m3u "$NAS_USER@$NAS_IP:$NAS_PATH"

# 检查文件是否成功传输
if [ $? -ne 0 ]; then
    echo "Failed to transfer file to NAS."
    exit 1
fi

echo "Operation completed successfully."

威联通 NAS 中使用 Nginx Proxy Manager 反向代理多个 docker 应用

  前一阵在威联通 QNAP 的 NAS 中通过 docker 安装了 ChatGPT-Next-Web 这个项目,给朋友分享ChatGPT使用,但这个 web 项目本身不涉及SSL证书的配置,于是应用一直跑在未加密的 HTTP 协议下;加上之前的另一个 docker 媒体播放应用 Jellyfin,目前已经在路由器上设置了多个端口转发,需要通过记忆特定端口来打开对应的应用。有没有什么办法能同时解决这两个问题呢?显然 Nginx 来做反向代理再合适不过了。但这次跳过手写配置文件,我们使用 Nginx Proxy Manager 来达到目的。

目的

  现状:

  要实现的目的:

  • docker中运行的应用都可以通过 HTTPS 方式访问。
  • 通过不同的(子)域名访问对应的应用,方便记忆。比如: https://chat.mydomain.com:7443 打开 ChatGPT 应用, https://jellyfin.mydomain.com:7443 打开 Jellyfin 应用。
    • 注:因为运营商屏蔽 80 和 443 端口,所以你需要选择一个非默认端口来打开你的应用。

具体步骤

1. docker 安装 Nginx Proxy Manager 。我这里使用 docker compose 方式如下:

version: '3.3'
services:
  nginx-proxy-manager:
    container_name: nginx-proxy-manager
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      - '9080:80' # 监听的 HTTP 端口
      - '9081:81' # 管理页面的端口
      - '9443:443' # 监听的 HTTPS 端口
    volumes:
      - /share/Container/nginxProxyManager/data:/data
      - /share/Container/nginxProxyManager/letsencrypt:/etc/letsencrypt 

2. 通过 http://<nasIP>:9081 登陆 Nginx Proxy Mananger,SSL Certificates 页面给想要分配给应用的域名申请 SSL 证书。

  • 默认用户名密码是 admin@example.com/changeme,首次登陆需要修改。
  • mydomain 是你提前注册好的域名。我的域名托管在 CloudFlare,所以 DNS Provider 处选择 Cloudflare;另外需要在 CloudFlare 提前设置好 API token 填入下图对应位置。

3. 将你的域名 DNS 记录解析至家里 NAS 的 DDNS 地址。比如我在 CloudFlare 对应域名的 DNS 设置中,添加了两个子域名 chat.mydomain.com 和 jellyfin.mydomain.com,都通过 CNAME 记录指向我的 DDNS 地址 https://mydns.myqnapcloud.com 。之后通过这些域名和特定端口的请求会被运行的 Nginx Proxy Manager 接管。

4. Nginx Proxy Manager 的 Hosts 页面,添加 New Proxy Host。Forward Hostname / IP 和 Forward Port 是你内网应用运行的地址和端口,Nginx Proxy Manager 会将此域名的请求转发到这个应用。其中 SSL tab 页的 SSL Certificate 选择步骤 2 中申请号的泛域名证书。

5. 最后到路由器中设置端口转发,允许特定外网端口转到 Nginx Proxy Manager 监听的端口。比如我所有应用都强制 HTTPS 访问,则只需转发上面 docker compose 文件中的 9443 端口到外网 7443 (可随意修改)即可。

  至此设置完毕。

遇到的问题和解决办法

  此时发现通过 https://chat.mydomain.com:7443 并不能打开内网的 ChatGPT 应用,等待之后显示 504 Gateway Time-out openresty 错误。但如果通过路由器端口转发,直接访问 ChatGPT 应用或 Nginx Proxy Manager 管理页面都是没有问题的,证明这两个应用本身可以独立运行。
进入 Nginx Proxy Manager docker 的控制台,查看 /data/logs 下的 _error.log 和 _access.log 文件,发现提示上游请求无法通过;另外通过 curl 命令打到内网 ChatGPT 应用地址发现无响应。判断是 Nginx Proxy Manager 的 docker 和其它 docker 应用无法通信。
  查看威联通的”网络与虚拟交换机“,发现自己通过 docker compose 方式创建的应用,都分别使用了独立的虚拟交换机并且网段不同;而如果通过 Container Station UI 创建的 docker 应用,则都会默认连接到名为 lxcbr0 的同一个虚拟交换机中,可以互相通信。因此只需将 docker compose 创建的应用,接入同一个网络中即可。
  为此,首先 SSH 到 NAS 主机中,通过 docker network create my-custom-network 命令在 docker 中创建一个新的网络。之后在需要连接到此网络的应用的 docker compose 文件中加入对应的 networks 配置。修改后的 Nginx Proxy Manager docker compose 文件如下:

version: '3.3'
services:
  nginx-proxy-manager:
    container_name: nginx-proxy-manager
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      - '9080:80'
      - '9081:81'
      - '9443:443'
    volumes:
      - /share/Container/nginxProxyManager/data:/data
      - /share/Container/nginxProxyManager/letsencrypt:/etc/letsencrypt
    networks:
      - my-dockers-network

networks:
  my-dockers-network:
    external: true

  同样修改 ChatGPT 和 Jellyfin 应用的 docker compose 文件,添加上面最后几行 networks 的设置并重启后,”网络与虚拟交换机“里可以观察到几个 docker 应用接入了同一个虚拟交换机。此时通过不同域名加固定端口号的方式,便可以分别访问对应的应用了。

自动更新 AWS Lightsail 实例的公网 IP 地址并同步到 Cloudflare 的域名 DNS 记录

  近几个月来科学上网的环境持续不稳定,即使方式从 v2ray 的 websocket+tls 换成了 xray 的 vless+xtls-rprx-direct 配置,印象中去年底开始,刚刚更新好的上网环境,包括自建和订阅,用一阵以后(几天时间不等)也会断流继而彻底失效。

  经过观察发现,如果是自己搭建的环境,刚开始ping域名是可以返回背后的 IP 地址,但断流失效后,ping域名就没有响应了;此时 VPS 里的相关服务是持续稳定的,所以可能是 VPS 的 IP 地址被加入了“黑名单”。这时如果更换 VPS 的 IP 地址,并重新绑定到先前的域名,上网环境又重新可用,如此往复。这篇文章针对自建环境的情况,分享一种解决目前问题的方法。对于订阅的情况,只要更新一次订阅的服务器节点即可。

  根据上面的思路,只需要定期自动更新 VPS 的外网 IP 地址,然后同步到自己域名的 DNS 解析记录即可。我目前使用的是 AWS Lightsail 和 Cloudflare,在 Linux 环境里解决问题的具体步骤如下。如果你使用其它服务商,需要查询一下相关的 API。

1. 安装和配置 AWS CLI

  AWS Lightsail可以看作是廉价的EC2服务,因此其实例同样可以用AWS CLI来进行操作。安装只需要依次执行以下命令:

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

  完成之后需要使用 aws configure 命令配置安全认证以便能够和你的 Lightsail 交互。这里需要提前创建好 IAM 用户和 access key。参考步骤和文章:

2. 用 AWS CLI 更新 Lightsail 实例的 IP 地址

  在 Lightsail 控制台界面上操作时只需要删除掉目前的静态公网 IP 地址并重新创建一个新的地址即可,创建过程中可以顺便绑定到你的实例机器。同样的过程用命令行操作,需要依次输入以下命令:

  1. 根据名称删除当前的 IP 地址 aws lightsail release-static-ip --static-ip-name StaticIp-1
  2. 申请新的 IP 地址并命名 aws lightsail allocate-static-ip --static-ip-name StaticIp-1
  3. 将新的ip绑定到指定的实例上 aws lightsail attach-static-ip --static-ip-name StaticIp-1 --instance-name Ubuntu2004LTS-Tokyo1

  参考 https://docs.aws.amazon.com/cli/latest/reference/lightsail/index.html

3. 利用 Linux shell 脚本更新 Cloudflare 中域名的 DNS 记录

  这一步在之前文章“OpenWrt中通过自定义脚本为Cloudflare域名更新DDNS“中有具体内容,此处略过。这里给出完整的脚本供参考。

  上面步骤2中的命令有些需要用户输入才能继续,因此脚本里禁用了 AWS CLI 的输出以便可以自动执行。

4. 定时自动执行以上脚本

  在稳定的 Linux 环境中 crontab -e 将上述脚本加入 cron 任务定时运行。比如我这里是每天早上6点执行一次:

0 6 * * * /root/updatePublicStaticIPForLightsailAndCloudflare.sh

  尾巴:如果问为什么要同时使用自建和订阅服务,考虑的因素有两点:1. 隐私安全;2. 鸡蛋不放在一个篮子里,避免需要“初始化”上网环境时,无法“上网”的窘境。

OpenWrt中通过自定义脚本为Cloudflare域名更新DDNS

  在上一篇文章中,威联通NAS上myQNAPcloud DDNS获取外网地址不准确的问题,提到使用myQNAPcloud服务来设置DDNS。这次尝试不依赖QNAP的服务,在OpenWrt里定时运行自定义脚本来直接更新域名的DNS地址。

  我的域名托管在Cloudflare上,所以主要思路是定时在OpenWrt里运行脚本检测公网IP地址是否有变化,如果有就用Cloudflare的token和API来更新相关DNS设置。

  记录具体步骤如下:

  1. 获取Cloudflare的API token,稍后脚本中会用到。进入 https://dash.cloudflare.com/profile/api-tokens 页面,Create Token,为了使token权限最小化选择Create Custom Token,设置如下图。Specific zone选项可限制token权限为仅允许更新某一个域名。
  2. 在上面所选域名的DNS设置中,添加一条A记录,设置成DDNS想要绑定的域名。IP地址随意设置比如8.8.8.8(之后脚本会付覆盖),Proxy status设置为DNS only。
  3. OpenWrt运行的脚本。参考了一些网上的脚本,发现 https://raw.githubusercontent.com/K0p1-Git/cloudflare-ddns-updater/main/cloudflare-template.sh 这个脚本比较全面(下载链接),注释也清楚。几点注意事项:
    • 第一行的#!/bin/bash需要修改成#!/bin/sh,否则OpenWrt中没有bash环境无法运行。
    • 要填写的项目有auth_email,auth_key,zone_identifier,record_name,其余可留空。
    • auth_method="token" 注意保持token方式,对应步骤1中创建的API token。同一页面还可看到Cloudflare的Global API Key,因为它可以操作账户里的所有设置,不建议使用。
    • 如果OpenWrt设置了科学上网/透明代理,curl -s -4 https://cloudflare.com/cdn-cgi/trace运行时可能获取到代理服务器的ipv4地址。可以注释掉相关if判断部分,改为用其它API直接获取,即ip=$(curl -s https://api.ipify.org || curl -s https://ipv4.icanhazip.com) 。注:此地址需添加到科学上网的“不走代理域名”列表内,否则全局代理时,访问这些地址获取到的也变成了代理地址。
  4. 用scp命令将修改好的脚本上传到/root目录,chmod +x updateDDNS_cloudflare.sh赋予执行权限。先手动运行一次观察输出是否正常/bin/sh -x updateDDNS_cloudflare.sh。如果脚本运行无误的话,可以在Cloudflare中观察到对应A记录的DNS更新成功。
  5. crontab -e编辑计划任务,添加一行内容*/10 * * * * /root/updateDDNS_cloudflare.sh,这样此脚本会每10分钟运行一次以按需更新DDNS。此步骤也可在OpenWrt网页端的“系统->计划任务”里完成。

  其实同样的工作也可以在OpenWrt的web管理页面上完成,如果你可以在“服务->动态DNS->DDNS 服务提供商 [IPv4]”的设置中找到Cloudflare选项的话。我用的OpenWrt编译了动态DNS的应用(luci-app-ddns, ddns-scripts),但没有Cloudflare的入口点。尝试安装ddns-scripts-cloudflare或更早的ddns-scripts_cloudflare.com-v4_2.7.8-3_all.zip,不仅依然找不到Cloudflare入口点,还有可能破坏掉OpenWrt:实际后台依然运行,可以上网,但web页面(LuCI web interface)报错Bad Gateway The process did not produce any response.,只能借助ESXI里的快照恢复或重新安装OpenWrt。所以才有了这篇博客。

威联通NAS上myQNAPcloud DDNS获取外网地址不准确的问题

  威联通(QNAP)NAS上自带的myQNAPcloud服务可以识别到NAS所在网络的外网地址,从而和你注册的QNAP域名(*.myqnapcloud.com)绑定,方便从外网通过该域名访问NAS服务。

  问题:最近发现家里的两台NAS中,一台的myQNAPcloud服务可以识别正确外网地址,而另一台NAS识别出的外网地址不对,实际上是软路由里科学上网的代理地址。猜测有问题的这个NAS不知为什么通过代理访问了myQNAPcloud的服务器。

  解决办法:在软路由的代理设置中,将访问myQNAPcloud服务器的地址 edge.api.myqnapcloud.com 设置成不走代理即可。

myQNAPcloud服务器地址加入不走代理设置

参考文章:

利用Real-ESRGAN修复制作高清版国产经典动画《大闹天宫》

  之前和儿子看了几次西游记的舞台剧,为了让他对故事的来龙去脉有更完整的印象,答应了和他一起看孙悟空动画片。当然不是白龙马,蹄朝西,而是更久远的 1961 年首映的国产动画《大闹天宫》,至少那时的动画是真的为了做好动画,没有商业目的,看完即走不卖周边可以放心食用。找到了 [大闹天宫(影迷修复版)].The.Monkey.King.(Fan.Restored.Edition).1965.DVDRip.x264.AC3-CMCT.mkv (1.46GB) ,虽然已经是修复版,但画质仍然是比较感人。于是自己也有了这次动画的修复经历。

  修复使用的是 Real-ESRGAN 这个库,它基于 PyTorch 实现,用于对图像进行超分辨率成像 (super-resolution) 。根据作者 xinntao 的介绍,

Real-ESRGAN 的目标是开发出实用的图像/视频修复算法。我们在 ESRGAN 的基础上使用纯合成的数据来进行训练,以使其能被应用于实际的图片修复的场景(顾名思义:Real-ESRGAN)。

  ESRGAN 的作者也是同一人,属于自我进化了。另外作者还提供了论文和详细的 PPT 介绍。这次我用到的是专门针对动漫视频制作了模型的 RealESRGAN AnimeVideo-v3 ,介绍页面中作者已经提供了编译好的各平台可执行文件以及使用步骤,此处就不重复粘贴具体命令了,只对大致过程和遇到的问题说明一下。

  从超分辨率成像的描述可以看出,Real-ESRGAN 的核心是对图像进行“修复”。那么对视频文件如何处理呢?思路和把大象关进冰箱是一样的,总共分三步:

  1. 利用 FFmpeg 把视频中的每一帧图像都抽取出来,类似把视频解压缩成图像。开头提到的《大闹天宫》视频变成了 170,977 张 720*512 的图片文件,总大小 14.33GB。
  2. 使用编译好的可执行文件 realesrgan-ncnn-vulkan 对每帧图片进行增强。我选择的是默认 2 倍分辨率,于是得到了同样数量的 1440*1024 的图片文件,总大小 171.79GB。
  3. 利用 FFmpeg 把增强后的图像文件合并成视频文件,类似把图片打包成视频。最后修复好的两倍分辨率高清版视频是 2.42GB,libx264 编码格式。这里要注意两点:
    • 把图像打包成视频,要使用原始视频文件的fps,即每秒的帧数,也是利用FFmpeg的到。开头提到的《大闹天宫》是25 fps,由此也能推断出视频长度是 170977/25/60≈114分钟。
    • 常见的 mp4 格式只支持 hard subtitles (硬字幕,也等于不支持字幕),也就是把字幕直接合并到每帧图像上,播放时就不能开关或切换字幕了。所以此处我选用了 mkv 格式,一并把原来的简体和繁体中文两种字幕拷贝到了新的视频中,播放时可以按需切换或关闭。具体命令是 ffmpeg -i out_frames/frame%08d.jpg -i dntg.mkv -map 0:v:0 -map 1:a:0 -map 1:s -c:a copy -c:s copy -c:v libx264 -r 25 -pix_fmt yuv420p output_w_audio.mkv ,大致意思是视频按照 libx264 格式每秒 25 帧合并,音频从dntg.mkv文件中直接拷贝,字幕也是从 dntg.mkv 文件中拷贝所有可用字幕。可参考 FFmepg 的 -map 参数

  下面是美猴王孙悟空出场时一帧图像的对比,左侧是原视频中的图像,右侧是修复后视频中的图像。可以看出效果还是很不错的。

  GitHub 介绍中可看到作者 xinntao 是在腾讯工作,在腾讯视频上还能找到已经修复的一些动画片,有《爱探险的朵拉》,《巴布工程师》等。仅在动画领域就可以使小朋友的童年回忆变得更美好一些,在此对作者表示感谢。

  最后儿子问,孙悟空七十二变的本领是怎么学来的?他表示有兴趣学习……

通过威联通NAS上的WireGuard VPN连接回家里的网络环境

  以前在外访问家里NAS内容时,都是通过路由器上的端口转发,登陆NAS管理页面。这样做一是有一定安全隐患,二是所有内容都在NAS管理网页这个”沙盒“里,无法通过本地应用直接访问。比如听歌,要么用NAS自带的网页播放器,要么需要先把歌曲文件下载到本地。最近趁618低价,新添了 QNAP 威联通 NAS TS-464C,今年的网红N5105 CPU配上32G内存(虽然官方硬件规格说最大支持16G内存),足足比14年使用至今的QNAP 212P的512M内存大了64倍……212P虽慢但稳定异常,目前依旧继续服役稳定输出。

  解决上面提到的安全和内容访问问题,标准答案就是VPN,连通后无论身处何地,你的设备就像连到家中的WIFI一样。目前QANP的操作系统QTS 5.0自带了QVPN Service 3软件,内建提供QBelt(QNAP自家标准),PPTP,L2TP/IPSet(PSK),OpenVPN,WireGuard共5种VPN服务。参考NordVPNQNAP自家页面,Wire Guard在安全性和传输速度方面表现都相对更好。

VPN protocolSpeedEncryptionStreamingStabilityP2P
OpenVPNFastVery goodGoodGoodGood
IPSec/IKEv2FastGoodGoodVery goodGood
WireguardVery fastVery goodGoodVery goodGood
SSTPMediumGoodMediumMediumGood
L2TP/IPSecMediumMediumPoorGoodPoor
PPTPFastPoorPoorGoodPoor
VPN协议比较

  于是这次就用QVPN Service搭建WireGuard VPN服务。具体步骤此处省略,可参考QNAP官方文档:How to Configure WireGuard VPN Server and Client Settings in QVPN Service 3。搭建好后,QVPN Service服务器端和Android客户端设置分别如下:

  有几点注意事项分享如下:

  • 服务器端
    • 如果NAS里启用了QNAP的防火墙QuFirewall,请参照How to setup QuFirewall to allow VPN connections设置以允许WireGuard服务通过防火墙。
    • 需要在路由器上做端口转发以允许外网访问WireGuard VPN服务。上图使用的是默认端口51280。
  • 客户端
    • 接口的地址需要填入服务器端对等表中分配好的“允许的IP”地址。服务器端的对等表,建议一个设备添加一条记录方便区分。
    • 对等中的端点地址,填入通过路由器转发的WireGuard服务外网地址端口。
    • 对等中的允许IP地址,填入0.0.0.0/0以允许所有IP地址的流量。

  至此,你应该可以随时随地通过WireGuard服务接入家中的网络环境了。经过几天测试使用,速度和稳定性都很不错。在外面通过4G网络加WireGuard给小朋友看家中NAS里的《绿色星球》很流畅。另外因为等同接入家中WIFI,家里软路由上运行的所有服务也都是可以直接使用的,比如访问国际互联网。

  这次虽然使用的是QNAP自带的QVPN Service软件,但理论上在NAS的docker中或软路由(docker)中运行WireGuard服务器端都是可以的。

  总结一下使用WireGuard VPN服务接入家中网络的一些特点:

  • 连接速度和安全性都有保证。
  • 可通过客户端本地软件访问NAS内容,比如电影和音乐,不受网页端限制。
  • 以下两点,对于家里其他成员非常方便。一人维护家里的设置,所有客户端一次性配置免去今后维护,对于外地家庭成员尤其友好:
    • 可以替代NAS本身的网页“分享链接”功能。比如外地的家中成员看NAS里的电视剧时可以摆脱网页播放器,从而使用平板或手机的本地播放器进而投射到电视大屏上。
    • 可以直接使用软路由上的服务访问国际互联网,比如备份照片到Google Photos里。
  • 依然需要保留NAS网页端直接访问功能,以便在已经连入其它VPN的情况下访问NAS。

几种需要内网穿透情况下Windows远程桌面的方案

要解决一个比较典型的需求:在家里的时候需要远程桌面到办公室的电脑做一些操作,最大问题是办公室的机器在局域网内没有公网IP,所以不能直接使用远程桌面工具连接。想要完成这个任务核心是需要进行所谓的内网穿透,之后就可以选择自己熟悉的远程桌面工具操作了。这里介绍几种我使用过的办法,供有需要的朋友参考。

* 如果你需要操作的是一台内网Linux机器,也可以参考之前的这篇《从Internet访问没有外网ip的NAS服务器的解决办法》。

 

方案一 TeamViewer

TeamViewer是一款简单好用的工具,不仅允许个人用户免费使用,还支持多平台下机器相互连接,比如可以从Android手机或macOS电脑远程到Windows电脑。只要两台电脑都安装了该软件,便可直接相互远程桌面,内网问题完全透明,操作速度也完全可以接受。不过使用一段时间后,被提示有可能是商业用途使用,也考虑过付费购买,但单个用户49刀/月的价格对于偶尔使用来说确实比较贵。于是就转到了第二个方案。

 

方案二 ZeroTier

ZeroTier也是一款可以直接安装使用的工具,相比TeamViewer的好处是,第一提供免费套餐,不区分个人和商业用途,并且免费套餐允许同时100台设备组网,第二它是更完整的内网穿透方案,安装了ZeroTier软件的所有设备都会加入到一个自己指定的虚拟局域网内,这样这些设备之间相当于都是局域网访问,所以不仅能远程桌面,还能进行其他任何操作。ZeroTier的使用也很简单,每台设备上安装软件后加入到自己创建的网络内即可,具体可参考相关帮助。

唯一可惜的是在远程操作时,速度有些慢,这是因为同TeamViewer一样,设备之间的连接都是通过他们的服务器转发的,而ZeroTier的服务器,在国内的访问速度显然不如TeamViewer的好,如果TeamViewer的连接速度比作1的话,ZeroTier不经过额外配置的情况下,对于我的网络状况下差不多是0.6。

所谓的额外配置,是ZeroTier允许你自己加入中转服务器(通常是自己所有设备都能访问到的具有公网IP的VPS),这样两台设备连接时会自动利用ZeroTier自身服务器(称作planet)和你指定的中转服务器(称作moons)之间连接速度更好的一个。在按照官方文档Creating Your Own Roots (a.k.a. Moons)和相关参考文章《ZeroTier moon 设置教程》 设置好以后,发现速度确实有所提升,感觉可以达到TeamViewer的1-1.3倍的速度。

 

方案三 frp

frp是国内大牛开发的一个开源方案(A fast reverse proxy to help you expose a local server behind a NAT or firewall to the internet.,目前仍处在开发状态,不推荐用于生产环境),相比于TeamViewer客户端/服务器端都闭源,ZeroTier客户端开源/服务器端闭源来说,frp的客户端和服务器端都在GitHub上开源。主要思路是通过自己指定中转服务器,实现两台不同内网设备之间的点对点链接。它的好处是和ZeroTier一样能够暴露某个机器上的所有指定端口,而且服务器端完全走指定的中转服务器(ZeroTier是自动选择)。具体配置步骤如下:

1. 在中转服务器VPS上配置服务器端。

wget https://github.com/fatedier/frp/releases/download/v0.23.3/frp_0.23.3_linux_amd64.tar.gz

tar -zxvf frp_0.23.3_linux_amd64.tar.gz

//编辑服务器端配置文件frps.ini

[common]
bind_port = 7000  # VPS监听的端口,用于和frp客户端连接 。需防火墙开放

//启动服务器端(可自己配置系统服务)

nohup ./frps -c frps.ini & &> /dev/null

 

2. 在需要远程桌面的机器上配置客户端

//从github release获取同样的release文件(服务器端和客户端的所有文件都在里面)

//编辑客户端配置文件frpc.ini

[common]
server_addr = xxx.xxx.xxx.xxx  #中转VPS的Ip
server_port = 7000                #同服务器端配置的端口
[rdp]
type = tcp
local_ip = 127.0.0.1
local_port = 3389                 # 当用户连接 frps的以下3443端口时,会被转发到frp client的此端口
remote_port = 3443              # frps监听的端口,任何机器通过此端口与frps连接。需防火墙开放

custom_domains = xxx.xxxxxxxxxxx.com              #可选,如此可通过域名访问3443端口

 

3. 客户端通过frpc -c frpc.ini即可启动。办公室的电脑是Windows机器,可通过如下方法开机自动启动frp。

//创建一个frp_autostart.bat文件如下

@echo off
cd C:\frp_0.23.3_windows_amd64
frpc -c frpc.ini
exit

//创建Windows服务

C:>sc create frp binPath=  C:\frp_0.23.3_windows_amd64\frp_autostart.bat start= auto

 

最后即可通过[中转VPS的IP]:3443进行远程桌面连接了。家里的是macOS,推荐使用微软官方的Microsoft Remote Desktop的软件(目前beta)。最后frp这个方案速度最快,如果TeamViewer是1的话,感觉连接速度可达2以上。值得一提的是,这三个方案都是跨操作系统的,并且后两种方案,不局限于远程桌面,其他应用都可以支持。

北京联通烽火HG220G-U光猫升级+路由改桥接

  去年家里宽带升到200M之后,因为原先的光猫是百兆LAN口,网速受限,所以打联通客服要求换一个千兆LAN口的光猫。当时说我们这片只有烽火HG220G-U个型号的二手光猫支持千兆了,于是就先用着,还算稳定,但发现光猫的工作模式被锁死在路由模式下,不像原来的百兆光猫是桥接模式,这样光猫后面的路由器就没法拨号,导致路由后的NAS没法从外网直接访问,又用回了之前的SSH反向端口转发的办法

  后来又联系过两次联通客服,总说新猫没有到货,于是想看看有没有什么办法自己解决。找到了老周部落贴吧里的《烽火HG220G-U E00L2.03M2000光猫改桥接教程》,修改完成后发现光猫确实按桥接模式工作了,路由器也能正常拨号上网,但网速从200M降到了不到100M,发现是因为光猫的固件版本掉坑里了,2.02版本的光猫确实会出现改桥接后掉速的问题。当时也没找到升级光猫固件的办法,无奈又改回了路由模式。

  昨天恰好看到老周部落贴吧里的又出了新文章《北京联通烽火HG220G-U/HG221G/HG260G-U/HG261G互通型HGU升级指导》,先看了下跟贴,发现有一人情况和我一样,原来是2.02版本,想通过升级再改桥接。但他升级到最新2.04版本后,改完桥接依然掉速。

image 

  本想希望不大,抱着试试看的心态也升级了家里的光猫固件版本,但没有直接升到最新的2.04,而是到之前教程里改桥接肯定没问题2.03版本,然后改桥接,路由拨号,测试,200M–>200M。又可以从外网愉快的访问NAS啦~

image

 

image

 

image

家用(影像)存储及备份方案选择

  随着家庭成员和移动设备的增多,我们日常生活中越来越频繁地产生着各种照片和视频文件,日积月累,这些数字资料的保存,读取,备份或早或迟都会成为困扰你的一个问题。

 

  先来说说存储。我们移动设备存储空间满额的时候,最先想到的是把照片和视频导出保存到电脑硬盘上;而你肯定经历或者听说过硬盘坏掉这件事情,所以你可能觉得电脑硬盘靠不住了,买个移动硬盘来寸照片和其他重要资料吧,一来不用天天通电读取,看起来寿命似乎要更长,二来可以当作备份使用。但仔细想想,移动硬盘只不过是一个体积更大,容量更大的u盘(而且抗震性能还不如u盘),把你认为重要的资料存在u盘里可靠吗?你听说周围朋友移动硬盘坏了,丢了的情况多还是他说我家里台式机硬盘坏了的情况多?既然台式机硬盘无法保障我的照片和视频,更好的方案是什么呢?答案就是NAS。关于NAS的介绍大家可以自己google一下,品牌一般就是Synology(群晖)和QNAP(威联通)二选一。而当你使用NAS超过一段时间后,会发现对NAS硬盘里的资料进行备份又变成一个不可避免的话题。虽然比台式机硬盘坏掉概率要小很多,但只要发生,对于你的资料就是100%的丢失。

 

  再来说说备份。如何对NAS上的资料进行备份呢?通常NAS里不仅有比较珍贵的照片和视频,可能还有不太重要的一堆高清电影。最先想到的办法是多块硬盘做RAID1或者RAID5。前者硬盘空间浪费多,后者对NAS硬件级别又有要求(最少3块硬盘)。自己手上的QNAP 212P是比较低端的NAS,虽然有两个盘位,但发现做RAID1的话需要自己把现有资料备份,然后塞两块硬盘进行重新格式化,之后再把备份的数据倒回去;想做热备份的话就得换更好的NAS。前者需要多加一块硬盘,外加数据导入导出,成本1000元左右;后者换NAS,加硬盘,成本更高。

 

  最后目光又落回了云存储上面。之前也看到NAS里有应用可以备份本地数据到云存储上面,一般都支持增量备份及本地/云端双向同步备份,足够满足需求了。但感觉有额外的费用,没有细想。这回重新计算一下成本发现,云存储的备份办法确实比较划得来。目前需要备份的照片和视频差不多有100G,按照AWS S3最贵的Standard存储级别0.03美元/GB/月来算,就算200G数据,每月成本6美元,2年的成本大约1000人民币,相比加硬盘,换NAS来说更有优势。因为目前家用NAS正在快速普及,两年后NAS功能,硬盘容量,成本几何都是未知数。

 

   下来就比较一下可选的云存储方案。能考虑的也就是三家,亚马逊的AWS S3,谷歌的Google Cloud Storage和微软的Azure Storage。从信誉度来说国内的各种所谓云计算直接pass,从持久性来说微软的Azure也pass,不是说Azure的durability不行,而是怕微软的Azure哪天就不行了。。。S3中的Glacier响应速度4小时,就不用考虑了;S3还有一个Reduced Redundancy Storage(RRS)的durability是99.99%,相比其他剩余选项的99.999999999%来说,在成本差别不大的情况下也可以淘汰掉。剩余的选项对比如下:

 

  AWS S3 Standard AWS S3 Standard – Infrequent Access GCD Standard GCD Durable Reduced Availability GCD Nearline Storage
Durability 99.999999999% 99.999999999% >= 99.9% >= 99.0% >= 99.0%
Availability 99.99% 99.99% “High availability” “Lower availability than Standard” “Lower availability than Standard”
Storage Pricing (per Month) $0.03 per GB $0.0125 per GB $0.026 per GB $0.02 per GB $0.01 per GB
 

Data Transfer Pricing

$0.09 per GB $0.09 per GB $0.012 per GB $0.012 per GB $0.012 per GB
Retrieval Fee $0.01 per GB $0.01 per GB

 

  其中,S3的价格以us-east为准;Data Transfer即是数据下载到本地的价格(存储收费,下载消耗网络带宽也要收费),而Google Cloud Storage还要区分下载到哪,大部分地区是$0.012/GB,而下载到中国(可能吗?)和澳大利亚地区费用更高;Retrieval Fee是价格保护策略的收费,对于价格更低的AWS S3 – IA和Google的Nearline Storage来说,本身存储成本低,划算,所以设置了额外的费用增加使用成本,也就下载是除了Data Transfer的费用外还要额外收取$0.01 per GB的费用;此外的Request Pricing(请求次数的费用)很低,可以忽略不计。

 

  Google Cloud Storage和S3的设计理念完全一致,IAM管理,bucket,object,storage class等,但控制台界面的友好性,即使用策略的灵活性来说(S3允许单向切换Storage Class,Google不行;S3的Life Cycle策略的应用粒度可以到bucket内的某个/某些文件夹,google不行),AWS完胜Google。另外,虽然家里已经有能翻墙的路由器,但在其他网络上访问Google的数据的不便利性,也是需要考虑的一个因素。

 

 基于上面的数据,和大约200GB左右的数据量,几乎完全是单向备份,极少机会会下载到本地(除非NAS硬盘坏掉)的使用场景来看,AWS S3 Standard – Infrequent Access是最好的选择。最后从安全性上来说即使RAID1,硬盘加再多也有可能出事故,比如搬家时摔坏了,丢掉了;云存储可以防止此类隐患,理论上来说即使地震也不怕了。。。当然地震后你本人仍要有能够访问云端数据的机会:)

 

参考:

1. Amazon S3 Storage Classes

2. Amazon S3 Pricing

3. Google Cloud Storage Storage Class

4. Google Cloud Storage Pricing

5. Google Cloud Storage SLA