亚马逊云充值 亚马逊云 AWS 账号内网穿透方案
为什么非得搞内网穿透？——别怪 AWS，是它太安全了
亚马逊云充值 刚用 AWS 的朋友常一脸懵：我 EC2 装好了服务，安全组也开了 80 端口，VPC 路由表配得比我家族谱还全，结果本地 curl 一下——Connection refused。一查发现：哦，这台机器压根没公网 IP，连 NAT 网关都没配，纯纯的「云中隐士」。
这不是 AWS 故意为难你，恰恰是它最值得夸的地方：默认不暴露、最小权限、网络隔离。私有子网里的数据库、Redis、内部管理后台……本就不该裸奔在公网。但开发调试、临时排障、CI/CD 部署又总得连一下——这时候，内网穿透不是偷懒，是刚需。
注意：我们今天聊的，不是让你给 EC2 拿个弹性 IP 再开个安全组放行全世界（那叫裸奔式运维），而是在「零公网暴露」前提下，建立一条受控、可审计、带身份验证的通道。
方案一：SSH 反向隧道——老派但靠谱，Linux 用户的祖传手艺
原理一句话：让内网机器主动“打洞”到跳板机
核心思想：内网服务器（比如 web-prod-01）主动连一台带公网 IP 的跳板机（比如 bastion-us-east-1），并在跳板机上开一个监听端口（如 2222），所有发往跳板机:2222 的流量，都被 SSH 自动转发回内网机的 22 端口（或任意端口）。
命令就这一行，抄了就能跑：
ssh -fNTR 0.0.0.0:2222:localhost:22 -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes [email protected]拆解下关键参数：
-f 后台运行；
-N 不执行远程命令，只建隧道；
-T 不分配伪终端；
-R 反向绑定（Remote）；
0.0.0.0:2222:localhost:22 表示跳板机所有网卡的 2222 端口，映射到内网机本地 22 端口；
ServerAliveInterval=60 每分钟发心跳保活，防断连；
ExitOnForwardFailure=yes 绑定失败直接退出，方便 systemd 监控重启。
实战补丁：别让隧道成“一次性筷子”
手动敲命令？重启就断？别。扔进 systemd：
# /etc/systemd/system/ssh-reverse-tunnel.service
[Unit]
Description=SSH Reverse Tunnel to Bastion
After=network.target
[Service]
Type=simple
User=ec2-user
ExecStart=/usr/bin/ssh -fNTR 0.0.0.0:2222:localhost:22 -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes -o StrictHostKeyChecking=no [email protected]
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target然后 sudo systemctl daemon-reload && sudo systemctl enable --now ssh-reverse-tunnel。隧道从此比你家路由器还稳。
⚠️ 注意三点：
1. 跳板机 sshd_config 必须设 GatewayPorts yes，否则 0.0.0.0 绑定会失败；
2. 安全组要放行跳板机的 2222 端口（来源仅限你办公 IP）；
3. 内网机和跳板机之间建议用密钥对认证，禁用密码登录。
方案二：Cloudflare Tunnel —— 零配置 HTTPS 穿透，适合前端/HTTP 服务
它不碰你的网络，只借你一根“魔法网线”
Cloudflare Tunnel（cloudflared）本质是个反向代理客户端：它在你的内网服务器上跑，定期跟 Cloudflare 边缘节点握手，建立一条加密长连接。你访问 https://myapp.yourdomain.com，请求经 Cloudflare 走隧道抵达内网服务，全程不暴露源 IP、不开放任何端口。
部署三步走：
- 在 Cloudflare Dashboard 创建 Tunnel，复制 token；
- 在内网 EC2 执行：
curl -L https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 | sudo install -Dm755 /dev/stdin /usr/local/bin/cloudflared - 运行：
cloudflared tunnel run --token <your-token>
搞定。不用改 DNS，不用开安全组，连证书都自动签发（Let’s Encrypt）。连不上？先 cloudflared tunnel list 看状态，再 journalctl -u cloudflared -f 看日志。
进阶玩法：一个隧道，多个服务
通过 config.yml 配置多路复用：
tunnel: abc123-def456
credentials-file: /root/.cloudflared/abc123-def456.json
ingress:
- hostname: api.myapp.com
service: http://localhost:8080
- hostname: grafana.myapp.com
service: http://localhost:3000
- service: http_status:404这样，一个 cloudflared 进程，扛起 API、监控、文档三个子域，干净利落。
方案三：AWS SSM Session Manager —— 原生亲儿子，免密钥、可审计、带录像
不是穿透，是“云上直连”，连 SSH 都不用装
SSM Session Manager 是 AWS 官方推荐的堡垒机替代方案。它不依赖 SSH 协议，而是通过 SSM Agent 和 IAM 权限控制，让你从 AWS Console 或 CLI 直连私有子网实例——连安全组都不用开！
前置条件三件套：
✅ EC2 实例角色含 AmazonSSMManagedInstanceCore 策略；
✅ VPC 中 SSM Endpoint 已创建（或允许出站到 ssm.<region>.amazonaws.com）；
✅ SSM Agent 已启动（AMI 默认已装，检查 sudo systemctl status amazon-ssm-agent）。
连上去？就一条命令：
aws ssm start-session --target i-0abcdef1234567890想传文件？aws ssm send-command + aws ssm get-command-invocation 组合拳；
想批量操作？加 --targets "Key=tag:Environment,Values=prod"；
想看谁连过、干了啥？打开 CloudTrail + SSM Session Logs（S3 存储，支持 AES-256 加密）。
它甚至支持端口转发（类似 SSH -L）：
aws ssm start-session \
--target i-0abcdef1234567890 \
--document-name AWS-StartPortForwardingSession \
--parameters '{"portNumber":["3306"],"localPortNumber":["3307"]}'执行完，本地 mysql -h 127.0.0.1 -P 3307 -u root -p 就能连上内网 MySQL——整个过程，MySQL 安全组连 3306 都不用开！
终极选型指南：什么场景选什么方案？
- SSH 反向隧道 → 适合老系统、非 HTTP 服务（如 PostgreSQL、FTP）、需要细粒度端口控制、团队熟悉 Linux 网络；
- Cloudflare Tunnel → 专治 Web 服务、需 HTTPS、不想管证书和域名、希望快速上线且带 DDoS 缓冲；
- SSM Session Manager → 企业级合规需求（审计日志、IAM 细粒度授权）、无公网需求、追求 AWS 原生体验、讨厌密钥管理。
别硬凑：如果你只是临时 debug 一个 Lambda 的 VPC 内依赖，aws ssm start-session 5 秒连上；如果要对外提供客户 API，Cloudflare Tunnel 更省心；如果运维一堆老旧 Java 应用还要连 JMX 端口？SSH 反向隧道仍是你的老伙计。
最后送一句大实话：没有银弹方案。真正的高手，不是死守一种工具，而是左手 SSM 查日志，右手 Cloudflare 暴露服务，脚边还躺着一个永不死的 SSH 隧道——就像厨师不会只用一把刀，而 AWS 工程师，也该有整套穿墙工具箱。
