windows 远程登录方案分享

1 月 7 日
 shuyuncong

最近看到很多关于 window 远程方案登录的讨论,所以在此也和大家分享一下之前自己的方案,以供相同条件约束下的朋友参考,也借此机会看看大家是怎么处理的。(叠甲:当前方案是目前的资源和约束下的选择)

背景诉求

在公司访问家里的 Windows 开发机,用来浏览器查阅资料、微信、Typora 笔记、Termius 等。

目前的现状是:

核心诉求是

资源和约束

资源

约束

方案对比

方案 访问方式 客户端依赖 延迟 安全性 结论
日本服务器 + Guacamole Web 无 高 高 ⚠️ 可用,但体验一般
FRP + 家庭 Guacamole Web 无 中 高 ⚠️ 可用,但体验一般
FRP + SSH 隧道 + RDP RDP 无 低 高 ✅ 最优解
FRP + RDP + multiOTP RDP 无 低 很高 ⭐ 可叠加
公益 FRP 内置 TOTP RDP 无 低 高 ⚠️ 依赖定制 FRP

最终选择:公益 FRP + SSH 隧道 + RDP

整体架构

公司电脑(自带 SSH 客户端)
   │
   │ ssh -i key -N -L 13389:WIN:3389
   ▼
公益 FRP ( TCP 高位端口)
   │
   ▼
PVE · Debian 跳板机
   │  · 仅 SSH key
   │  · 仅允许访问 Windows:3389
   ▼
家庭 Windows ( RDP )

核心原则

公益 FRP + SSH 隧道方案实施

基础设施搭建

跳板机系统选择

基础系统加固

apt update && apt upgrade -y
apt install -y openssh-server ufw fail2ban curl

用户职责划分

为了安全,我们将“管理权限”和“隧道权限”分开。

# tunnel 用户:仅用于建立隧道,无 Shell 权限
adduser tunnel
usermod -aG sudo tunnel
# debian-cc 用户:管理员,用于维护系统
adduser debian
usermod -aG sudo debian

SSH 安全加固

tunnel 用户(公司 → 跳板机)

在公司电脑生成密钥对,将公钥上传至 Debian 的 /home/tunnel/.ssh/authorized_keys

ssh-keygen -t ed25519 -f id_frp_ssh

authorized_keys 中强制限制能力:我们需要配置 SSH ,使得公司电脑连接时,只能做端口转发,不能执行命令,且只能转发到家里的 Windows IP 。

restrict,port-forwarding,permitopen="192.168.31.120:3389" ssh-ed25519 AAAA...

这个 key:

SSH 服务端限制

编辑 /etc/ssh/sshd_config,修改 SSH 端口为高位端口(防扫描),并禁用密码登录。

Port 53822                  # 高位端口
PermitRootLogin no          # 禁止 Root
PasswordAuthentication no   # 禁止密码
ChallengeResponseAuthentication no
PubkeyAuthentication yes    # 只认 Key
AllowUsers tunnel debian    # 白名单用户

# 针对管理员:允许 Shell ,禁止转发
Match User debian
    PermitTTY yes
    AllowTcpForwarding no

# 针对隧道用户:禁止 Shell ,限制转发目标
Match User tunnel
    AllowTcpForwarding yes
    PermitOpen 192.168.31.120:3389
    X11Forwarding no
    AllowAgentForwarding no
    PermitTTY no

配置完成后重启 SSH 服务:systemctl restart ssh

防火墙策略

验证原则只有一条:

跳板机只能访问 Windows ,不能访问任何其他内网。

# 1. 默认策略:拒绝入站,默认允许出站(稍后限制)
ufw default deny incoming
ufw default allow outgoing

# 2. 允许 FRP 流量进出( SSH 端口)
ufw allow 53822/tcp

# 3. 精细化出站规则 (Output Chain)
# 允许 Debian 访问 Windows 的 RDP
ufw allow out to 192.168.31.120 port 3389 proto tcp

# 允许访问网关 (DNS/路由需要)
ufw allow out to 192.168.31.1

# 拒绝访问内网其他所有 IP (防止横向移动)
ufw deny out to 192.168.31.0/24

# 启用防火墙
ufw enable

Fail2ban

配置 /etc/fail2ban/jail.local 监控 53822 端口,错误尝试 2 次即封禁 24 小时。因为公网暴露 SSH 必然会被扫描,这是最后一道防线。

[sshd]
enabled = true
port = 53822
maxretry = 2
bantime = 24h

关于 Windows 安全的建议

虽然 RDP 不暴露公网,但还是建议对目标 Windows 进行加固:

  1. **启用 NLA (网络级别身份验证)**。
  2. 创建非管理员用户用于远程登录。
  3. 强密码策略。
  4. (进阶) 配合 MultiOTP 软件,在 Windows 登录时强制要求 MFA 动态口令,进一步提升安全性。

内网穿透配置 (FRP)

使用低延迟的国内公益 FRP (如樱花 FRP / Nyat 等),将 Debian 的 SSH 端口暴露出去。

安装 FRPC

# 切换到 tunnel 用户安装,避免使用 root
su - tunnel
wget https://github.com/fatedier/frp/releases/download/v0.56.0/frp_0.56.0_linux_amd64.tar.gz
# ...解压并移动到 /usr/local/bin/frpc

配置文件 (/etc/frpc.toml)

我们**不直接穿透 RDP (3389)**,而是穿透 **SSH (53822)**。

serverAddr = "rdp.example.com" # FRP 服务端地址
serverPort = 7000
user = "your_user_id"
auth.token = "your_token"

[[proxies]]
name = "tunnel_ssh"
type = "tcp"
localIP = "127.0.0.1"
localPort = 53822
remotePort = 53389

设为系统服务

创建 /etc/systemd/system/frpc.service 并启动,确保断电重启后自动上线。

公司电脑使用方式

在公司电脑上,不需要安装任何软件,只需要一个 SSH 私钥文件(id_frp_ssh)。

建立隧道

打开 PowerShell 或 CMD:

ssh -i id_frp_ssh -N \
  -L 13389:192.168.31.120:3389 \
  -p 53389 tunnel@frp.example.com

连接 RDP

打开 Windows 自带的“远程桌面连接”

mstsc → 127.0.0.1:13389

实际体验

原文: https://blog.illsky.com/posts/homelab-ssh-rdp/

6288 次点击
所在节点    Windows
45 条回复
PandaChan
1 月 7 日
@shuyuncong 原来如此🫡
deepbytes
1 月 7 日
@shuyuncong 666 ,我之前也想着发一个帖子,太忙了,不了了之,给你点赞👍
yangyujun
1 月 7 日
公司整个小主机,直接网线直连,组个局域网,手机整个热点,随便玩,壁纸调成一样的,利用 windows 的任务视图新建个桌面,远程桌面 app 单独占个桌面,公司电脑一个桌面,切换远程直接快捷键切换桌面即可
嫌网速慢,就整个 typec 转 2.5G 网卡,速度飞起,还流畅,文档类的在自己主机写完 copy 到公司,不会产生任何的风险
xmt328
1 月 7 日
我们这里执行这一步就已经被风控了,别问我怎么知道的
ssh -i key -N -L 13389:WIN:3389
axiauk
1 月 7 日
好复杂,家里可以装 Apache Guacamole ?公司直接 https 网页直接访问不就好了?
jpyl0423
1 月 7 日
现在公司没有禁止 wg ,先收藏下
shuyuncong
1 月 7 日
@axiauk #25 之前考虑过这种方案,还是选择了 RDP 的方式
shuyuncong
1 月 7 日
@xmt328 #24 不同公司限制要求不一样,理想状态还是组网比较好
hailun3202475
1 月 7 日
mark 一下,我现在是直接用 Zerotier 自建 MOON 组的网,有需求对外的服务我就直接反代出去
liuliancao
1 月 7 日
既然公司限制了 应该是公司对安全比较重视 感觉个人方面还是可以克服的吧 比如用手机啥的 家里和公司分开好点 如果家里要求应急 可以考虑下双系统 公司非要访问家里 宽带换成公网 ipv4 也可以考虑下
axiauk
1 月 7 日
@shuyuncong Guacamole (HTML5) 因为协议转换和转发,确实增加 60 - 150ms 略带粘滞,还算可以容忍的范围。
Ackvincent
1 月 7 日
直接蒲公英走起。
Foxkeh
1 月 7 日
OP 的公司管的比较严格,所以挑战难度高一些了,不过不推荐突破公司管控规定,现在找工作不容易。

公司要是扯这个理由不给 N+1 这不就亏死了
letmefly
1 月 8 日
好复杂,同意楼上的意见,如果是为了工作上的事,更亏。
ResponseBody
1 月 8 日
好复杂,自己的 PC 和服务器做组网,然后做个高位的端口映射不就好了吗。
shuyuncong
1 月 8 日
@ResponseBody #35 之前想过组网的方式,但这样需要在公司电脑安装组网的软件。目前的这种方式就不需要安装了
shuyuncong
1 月 8 日
@letmefly #34 现在的方案就像买了一台带公网 ip 的 window 云服务器,公司电脑不允许安装代理软件。在开发过程中就比较难受,这样折腾之后就算折中的方案,既没泄露内网资源,也没安装软件,开发效率也提升了
ResponseBody
1 月 8 日
@shuyuncong #36 你误会了,我指的是你的公网服务器和你家的 PC 组网,然后公网服务器开一个高端口的映射到你组网的 PC 的 3389 端口,这样的效果是一样的,没必要中间那么多层转发来转发去的。
ResponseBody
1 月 8 日
@shuyuncong #36 你的 Windows 是虚拟机也一样。在 Windows 上装个 tailscale ,公网服务器也装个 tailscale ,然后公网服务器配置端口映射到 tailscale 网络上的 Windows 的 IP:3389 就行了。
shuyuncong
1 月 8 日
@ResponseBody #39 我明白老哥的意思了,但是现在已拥有的公网服务器在国外,延迟在 200ms 左右,这样就算使用 RDP 的方式,之前猜测延迟也应该比较大吧。我晚上试试老哥的方案

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1183658

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX