bastion 3.0.210.113 持续拒绝我的出口 IP，阻断所有 prod 开通/充值（跨多 session 复现，非临时惩罚）

[Zhiying-Li-dot]

@xbfool 这是基础设施问题，找你看。关联 #16 —— 那条里把 bastion 这事塞在最底下当附录、且当时判断成「一次 session 隧道压测触发的临时 PerSourcePenalties」。现在确认不是临时的，单独提出来。

问题

我这台 Windows 机器的出口 IP 持续连不上 bastion 3.0.210.113，导致所有需要 prod DB 隧道的运营 CLI 全部失败：

• optima-grant-subscription（开 Pro / 会员）
• optima-grant-balance（充值余额）
• optima-query-db（查库）

结果：每次给客户开 Pro / 充值都卡在这里，得改由团队代劳。

现象签名（应用层拒绝，不是网络不通）

• TCP 能连到 22 端口：Test-NetConnection 3.0.210.113 -Port 22 → TcpTestSucceeded: True
• 但 sshd 在回 SSH banner 之前（kex 阶段）就关连接：

kex_exchange_identification: Connection closed by remote host
Connection closed by 3.0.210.113 port 22

• 裸 ssh -i ~/.ssh/optima-ec2-key ec2-user@3.0.210.113（完全不经过 dev-skills）一样复现 → 与包版本 / 密钥 / 账号无关，纯服务端拒绝。

为什么不是临时惩罚（#16 的旧判断要更新）

#16（2026-05-31）里我推测是某次短时间开关大量隧道触发 PerSourcePenalties / fail2ban 的临时封禁，会自己过期。但：

• 今天 2026-06-04，跨了多天、多个 session，仍然复现；
• 中间没再做任何隧道压测，正常单连也直接被拒。

所以这更像我的出口 IP 被持久 ban，或被 bastion 安全组 / sshd 配置挡在外面，不会自动恢复。

我的出口 IP

203.27.106.146（解封 / 加白用。若不固定我可在你方便时复查当前值。）

今天被它挡住的客户开通（举证「反复发生」）

• 1024868502@qq.com —— 本周早些时候，最后团队自己开的
• 33859231@qq.com —— 今天，Pro 未开
• bmcqxmlyj@gmail.com —— 今天，Pro 未开

请帮忙

1. 在 bastion 上查 sshd PerSourcePenalties / fail2ban / /var/log/secure，看 203.27.106.146 的封禁状态并解封；
2. 确认是否要把这个 IP 加进安全组 / AllowUsers 白名单做持久放行，避免再被周期性 ban；
3. 解了之后我能复连就能自助开通，不用每次找团队代开。

[xbfool]

@Zhiying-Li-dot 查清楚了,结论和你的判断不一样,贴一下排查过程。

先说定位:3.0.210.113 是我们 optima-terraform 里 shared-services 的那台 BI 数据机(i-03286fb0a9ce7e6b1,EIP optima-bi-data-eip),被复用成连 prod RDS 的 SSH 跳板。我用 SSM 进去做了只读排查(SSM 不走 sshd,所以你 IP 被挡也不影响我进)。

你推测的"持久 ban"——证伪了:

• ❌ fail2ban 根本没装(inactive,无 client)
• ❌ sshd 是 OpenSSH 8.7p1,而 PerSourcePenalties 是 9.8+ 才有的特性 → 这机器压根没这功能
• ❌ iptables / nftables 没有任何针对 203.27.106.146 的规则
• ❌ 你的 IP 在过去 14 天 journald 里零记录(机器是 AL2023,日志在 journald 不在 /var/log/secure)

真因:MaxStartups 节流被公网扫描洪水打爆。journald 有实锤:
```
May 31 13:13 error: beginning MaxStartups throttling
drop connection #10 from [34.11.41.120] ... past MaxStartups
May 31 23:07 beginning MaxStartups throttling / drop connection #15 ...
```
配置是 maxstartups 10:30:100。因为 SG 的 22 端口对 0.0.0.0/0 全开(日志里全是 root/invalid-user 的僵尸扫描),未认证并发一冲过 10 就进入节流,sshd 在 kex 阶段、回 banner 前概率性丢新连接,且不记被丢方 IP —— 这正好解释你看到的 kex_exchange_identification: Connection closed + "日志里查不到我的 IP"。所以不是针对你的封禁,是扫描洪水误伤正常用户,跨 session 复现是因为扫描 24/7 不停。

解法:DB 隧道从 SSH 切到 SSM 端口转发(接入指南里 SSM 本来就是"方式 A"),零公网端口,免疫这个失败模式,后续可关 22。已实测经这台机连 prod RDS 通:冷启 ~2.9s、warm reuse ~0.7s、每次往返 ~117ms(和 SSH 同量级,主要是新加坡物理距离)。

dev-skills 的隧道改造已开 #20(feat/db-tunnel-via-ssm):query-db / grant-balance / grant-subscription 全切 SSM,默认 SSM、OPTIMA_DB_TUNNEL=ssh 可回退。合并打包后你升级就自助开通,不用再找人代开。

升级前你要立刻干活的话,两个临时顶替办法(都不依赖那条被节流的 SSH):

1. 先拉 feat/db-tunnel-via-ssm 分支本地 build 用;
2. 或手动起一条 SSM 隧道再 psql:
   ```bash
   aws ssm start-session --region ap-southeast-1 --target i-03286fb0a9ce7e6b1
   --document-name AWS-StartPortForwardingSessionToRemoteHost
   --parameters 'host=optima-prod-postgres.ctg866o0ehac.ap-southeast-1.rds.amazonaws.com,portNumber=5432,localPortNumber=15433'

另开终端:psql postgresql://:@127.0.0.1:15433/optima_auth

```
前置:session-manager-plugin + aws CLI + IAM ssm:StartSession(你的 EC2 key 排查时确认是 sshd 侧问题,SSM 走 IAM 不受影响)。