解决开启 IPv6 防火墙后 Unraid Connect 无法使用的问题

给 Unraid 开启 ip6tables 后,发现 Unraid Connect 报错 Unraid API Error, Cloud: socket closed 并且无法备份配置文件了。

2024-06-10 update:
问题解决了,应该是我防火墙没加 ESTABLISHED,RELATED 规则(

ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

推测是防火墙的问题,于是一番查询后发现 Unraid Connect 是由 unraid-api 这个二进制提供的。那就来看看它用的是哪个端口好啦。

lsof -i -P -n | grep unraid-ap
unraid-ap 5448   root   19u  IPv4  21972      0t0  UDP 192.168.1.100:54435 
unraid-ap 5448   root   20u  IPv6  21973      0t0  UDP [2001:xxxx]:51423 
unraid-ap 5448   root   21u  IPv6  21974      0t0  UDP [2001:xxxx]:36283 
unraid-ap 5448   root   25u  IPv6  56784      0t0  TCP [2001:xxxx]:35856->[2606:xxxx]:443 (SYN_SENT)

猜测一下应该是 IPv6 的 35856 端口,那我们用 ip6tables -A INPUT -p tcp --dport 35856 -j ACCEPT 打开这个端口试试。刷新一下控制台发现问题解决了。但这个端口似乎是每次启动后会变的,那就比较麻烦了。

继续阅读“解决开启 IPv6 防火墙后 Unraid Connect 无法使用的问题”

为 Unraid 开启 ipv6 防火墙

最近 Arteria 这家 ISP 抽风,IPv4 很难用,于是便把 Unraid 的 IPv6 打开了。由于这边的 DHCP v6 和 RA 均为 Relay,路由器防火墙不能管理 IPv6 的数据包,这也就导致开启了 IPv6 的 Unraid 服务器直接暴露于 IPv6 公网中。并且 Unraid 默认并没有任何防火墙设置,很不安全。
但 Unraid 系统内有安装 iptables 和 ip6tables,所以配合 User Scripts 这个插件,我们便可实现启动后自动设置 ip6tables 的操作,进而强化服务器安全性。

继续阅读“为 Unraid 开启 ipv6 防火墙”

安装 Proxmox VE 后的一些配置

VMware 被 Broadcom 收购后宣布不再提供免费的 VMware ESXi 了,于是就把家里的机器换到了 Proxmox VE。

安装过程很简单,直接把 ISO 镜像放进 Ventoy 里然后 boot 进去安装就行了。本文主要讲一下安装后的一些必要设置。比如修改存储库为非订阅、移除“无有效订阅”警告、在管理面板增加 CPU 温度显示。

继续阅读“安装 Proxmox VE 后的一些配置”

为 Linux 配置多个无线网卡

最近把吃灰已久的 Raspberry Pi 3 Model B 拿出来跑 Home Assistant 了,但因为是买的比较早的版本所以不支持 5GHz Wi-Fi,只能连在 2.4Ghz 的 Wi-Fi 上面。

正好最近准备把 2.4GHz 的网络给单独划出来一个网段供 IoT 设备用,于是就想把 Raspberry Pi 连到 5GHz 的网络上面。正好手头有个闲置的 TP-Link Archer T2UH 就插到树莓派上用了。

多了一个无线设备,自然就想分开配置一下。搜寻了一些信息以后发现可以这样配置不同的无线设备

首先使用 sudo iwconfig 查看现有的无线设备,执行后可以看到类似于以下的输出

lo        no wireless extensions.

eth0      no wireless extensions.

wlan0     IEEE 802.11  ESSID:off/any
          Mode:Managed  Access Point: Not-Associated
          Tx-Power=31 dBm
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on

wlan1     IEEE 802.11  ESSID:off/any
          Mode:Managed  Access Point: 74:4D:28:BA:EB:30
          Tx-Power=17 dBm
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
Zsh

从输出中我们可以看到现在有两个 wlan 设备,分别为 wlan0 和 wlan1
接下来我们先配置一下 wlan0 的 SSID 和密码
执行 wpa_passphrase Your_SSID Your_passwd 后会返回以下内容

network={
ssid="${your ssid}"
#psk="${your password}"
psk=${key}
}
Zsh

sudo vim /etc/wpa_supplicant/wlan0.conf 将上面生存的内容写入 wlan0 的 wpa 配置文件里(可以把有原始mi

接下来 sudo vim /etc/network/interfaces.d/wlan0 创建 wlan0 的配置文件

auto wlan0
iface wlan0 inet dhcp
wpa-conf /etc/wpa_supplicant/wlan0.conf
Zsh

wlan1 同样按前面的步骤配置即可,完成后 reboot 一下就行

用 Nginx 来反代 Home Assistant

在树莓派上折腾了个 Home Assistant 上去,反正用都能用了就顺便配一下反代以便在外面看家里的设备(?为什么会有这样的需求?)

首先编辑 Home Assistant 的 configuration.yaml,我是跑在 Docker 里的,所以看一下配置文件就知道 config 存在哪里了
volumes:
- /home/username/home-assistant/config:/config

http:
  # For extra security set this to only accept connections on localhost if NGINX is on the same machine
  # Uncommenting this will mean that you can only reach Home Assistant using the proxy, not directly via IP from other clients.
  # server_host: 127.0.0.1
  use_x_forwarded_for: true
  # You must set the trusted proxy IP address so that Home Assistant will properly accept connections
  # Set this to your NGINX machine IP, or localhost if hosted on the same machine.
  trusted_proxies: <Your_Nginx_Server_ip>
configuration.yaml

保存后重启一下 docker service
sudo docker-compose restart

接下来创建一个 Nginx 配置文件

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server
        {
          listen 443;
          listen [::]:443;
          server_name hass.yourdomain.moe;

          ssl_certificate /etc/letsencrypt/live/yourdomain-moe.crt;
          ssl_certificate_key /etc/letsencrypt/live/yourdomain-moe.key;
          ssl_session_timeout 1d;
          ssl_session_cache shared:SSL:10m; # about 40000 sessions
          ssl_session_tickets off;

          # intermediate configuration
          ssl_protocols TLSv1.2 TLSv1.3;
          ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305;
          ssl_prefer_server_ciphers on;
          proxy_buffering off;
          
           location / {
            proxy_pass http://<Your_Home_Assistant_ip>:8123;
            proxy_set_header Host $host;
            proxy_redirect http:// https://;
            proxy_http_version 1.1;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
    }

        #access_log  /var/log/nginx/yourdomain.moe.log;

        }
hass.yourdomain.moe

接下来重启一下 Nginx 服务即可
话说回来我到底有什么必要从外面访问 Home Assistant 啊,于是测试没问题以后就把反代关掉了(((

用 samba 来低成本搭建 Time Machine 备份服务器

三个月前搭了个 NetaTalk 作为Time Machine 备份服务使用:用 Netatalk 来低成本搭建 Time Machine 备份服务器,很稳定地跑了几个月。然后千夏前几天手贱把系统从 Debian 11 (bullseye) 升级到了 Debian 12 (bookworm) 后发现 netatalk 不见了(((

搜索了一下发现是因为 netatalk 因为缺乏维护被 Debian 从 bookworm 中移除掉了
虽然有给出从 Debian Unstable 安装 netatalk 的方法,但千夏不是很想折腾非稳定版本的软件包,再加上 Apple 已经放弃了 AFS 的支持向 SMB 靠拢了,于是就想着用 samba 来重新配一下 Time Machine 服务。

继续阅读“用 samba 来低成本搭建 Time Machine 备份服务器”

在 Gmail 上使用 iCloud 自定义域名收发邮件

前一阵子购买了 iCloud+ 服务,然后发现它自带了一个自定义域名邮箱服务,于是就把手头的域名添加进去了。但是随后发现这个服务要是只能在 Apple 设备上用的话岂不是太鸡肋了,那么是否可以用 Gmail 来方便的收发邮件呢?

答案当然是可以,并且还蛮简单的。长话短说,我们现在就开始吧w

继续阅读“在 Gmail 上使用 iCloud 自定义域名收发邮件”