☰

針對 CNAT 後面的計算機的 IPV4 上的 SSH 隧道代理

tag-icon • tag-icon ssh networking ssh-tunneling tunneling ipv4
針對 CNAT 後面的計算機的 IPV4 上的 SSH 隧道代理

我不確定我是否應該在 Unix & Linux 或網路工程中問這個問題

這是物理場景

[主機1]----[運營商級NAT]---->AWS<----[運營商級NAT]----[主機2]

主機1和主機2透過反向 ssh（autossh）連接到 AWS Box，因此它們確實具有 shell 連接（如果需要），並且可以在需要時公開任何其他連接埠。

主機2將備份轉儲推送到主機1定期使用 SCP。其實有主機2×10推動資料轉儲的盒子。最近的 AWS 位置距離盒子的位置很遠，因此延遲很大。

是否可以使用 AWS 盒子作為集合點來在盒子之間建立 ssh 隧道？我知道 IPv6 隧道代理，但該地區的 ISP 尚未採用它（晚了 20 年......廢話！）我正在探索一種基於以下基礎的解決方案：

  • TCP/UDP打洞（附實際實作）
  • AWS 上的 UPnP / NAT-PMP 服務
  • 使用 Chrome 遠端桌面等工具，破解它以暴露 SSH 連接埠而不是 VNC
  • 任何其他路由器服務。
  • 任何其他實用方法。

盒子大多運行 CentOS 6/7。

答案1

然而，這並不完全是您所需要的：您可以使用 iptables 將 host1 或 host2 反向本機連接埠公開為外部連接埠。假設您將 host2 連線為 ssh 反向隧道：

user2@host2 $ ssh -R 9999:localhost:22 [email protected]

現在您可以將傳入連接埠 aws.com:9999 轉送到 aws [localport:9999]： 在 AWS 伺服器上：

[email protected] # iptables  -t nat -I PREROUTING -p tcp --dport 9999 -j DNAT --to 127.0.0.1:9999

現在您可以透過以下方式從 host2 連線到 host1：

user1@host1 $ ssh [email protected] -p 9999

答對了。您是這樣連接的：

[主機 1] --> [aws:連接埠 9999] --> [aws: 127.0.0.1:9999 上的反向隧道] --> [主機 2]

當不再使用此連線時，您應該刪除 iptable 記錄：

[email protected] # iptables -t nat -A PREROUTING -p tcp --dport 9999 -j DNAT --to 127.0.0.1:9999

此解決方案的缺點是，host2 透過外部連接埠 9999 暴露給所有人。

UPD：您可能還需要啟用本機轉送：

awsuser@aws # ls echo 1 > /proc/sys/net/ipv4/conf/all/route_localnet

或不為所有介面啟用它，而是僅在收入介面上啟用：

awsuser@aws # ls echo 1 > /proc/sys/net/ipv4/conf/eth0/accept_local

相關內容