web-dev-qa-db-ja.com

サーバーマシンでVPNにログインした後にSSH接続が失われるのを防ぐ

対処できない問題が発生しました。 SSHを介してVPSにログオンし、そのVPSでVPN接続を確立しようとすると、VPSと私のマシン間のSSH接続が失われます。これはVPN設定によってルーティングが変更されたためだと思います。それを防ぐ方法は？

ubuntusshvpnroutingopenvpn
14
mic22

追加する必要がありますroute-nopullオプション（および削除redirect-gateway（存在する場合）VPS上のOpenVPNクライアントの構成ファイルに。

この方法では、VPNサーバーに接続してもVPSのルートは変更されないため、必要なルートを自分で設定できます。

6
Anubioz

次のシナリオを考えてみましょう：

  1. vPSには、IPアドレス4.3.2.1/24で構成された単一のイーサネットインターフェイスがあります。
  2. vPSがデフォルトゲートウェイ4.3.2.254経由でインターネットにアクセスできる
  3. vPSにはnotがまだOpenVPN接続をアクティブ化しています。したがってno tunインターフェースがアクティブです

このようなシナリオでは、マシンから（マシンがdef-gw 9.8.7.254の9.8.7.6/24だとしましょう）、4.3.2.1へのSSH接続を正常に確立できます。したがって、ホスト4.3.2.1と9.8.7.6の両方が正常に相互に到達できます。

さて、そのようなSSH接続が確立されたとしましょう。

  1. vPS 4.3.2.1からOpenVPN接続を起動します。
  2. そのため、新しいtun0インターフェースは動的に構成されます（10.10.10.2 PTPで10.10.10.2 IPが割り当てられると仮定しましょう）。

この段階では：

  • [〜＃〜] if [〜＃〜]リモートOpenVPNサーバーからローカルVPSにルートがプッシュされないため、ルーティングに関して何も変更されず、SSH接続は問題なく存続しますまったく。この場合、VPNを通過するトラフィックは、リモートOpenVPNサーバー（10.10.10.1）に向かうトラフィックのみです。

  • [〜＃〜] if [〜＃〜]リモートOpenVPNサーバーはいくつかのルートをプッシュバックし、特にVPSデフォルトゲートウェイが10.10.10.1（リモートOpenVPNエンドポイント）に置き換えられる場合、[〜＃〜]その後[〜＃〜]問題が発生しています。この場合、トンネリングしています[〜＃〜] all [〜＃〜] VPN内の発信IPトラフィック（OpenVPN自体を除く）。

この2番目のケース（VPN接続を確立した直後にdef-gwを置き換える）では、非対称ルーティングのため、以前のSSH接続が「ハング」します。

  • マシン（9.8.7.6）からVPS（4.3.2.1）へのトラフィックは、以前の、変更されていないパスを経由して流れます。
  • VPS（4.3.2.1）からマシン（9.8.7.6）へのトラフィック：
    • vPNがないため（当初は）、4.3.2.254ゲートウェイ経由でルーティングされました。
    • vPNリンクの確立後、関連するdef-gwの置換により、VPN（10.10.10.1）経由でルーティングされます。

言い換えると、VPNリンクが確立されるとすぐに、VPSからマシンへの戻りルートが変更されます...これは良いことではありません（戻りパスに沿ったいくつかのネットワークデバイスは、このような非対称を認識する可能性がありますパスと単純にパケットをドロップします）。

さらに、リモートOpenVPNサーバーがNATボックスとして機能している可能性が高くなります。VPNからのすべてのトラフィックは、リモートOpenVPNサーバーのパブリックIPアドレスでNAT処理されます。これが本当である場合、それ以上のものではありません... SSH接続に関しては、「良くない」が、間違いなく「悪い」：リターントラフィックは、別のルートに沿って戻ることに加えて、マシンに戻ってくる- ソースIPが異なる（VPNサーバーのパブリックインターフェイスの1つ）。

この問題を解決するには？

実際、かなり簡単です。

VPSサーバーに単に指示するだけですトラフィックをVPNに沿ってマシンにルーティングせず、代わりに以前のルートに依存します。 OpenVPNを開始する前に、追加するのと同じくらい簡単なはずです。

     route add -Host 9.8.7.6 gw 4.3.2.254

どこ：

  • 9.8.7.6はマシンのパブリックIPアドレスです
  • 4.3.2.254はVPSの元のデフォルトゲートウェイです。

追記：より詳細な質問を提供することで、はるかに迅速な回答が得られるでしょう：-）

4
Damiano Verzulli

これは役立ちます：

_TCPKeepAlive=yes_を_/etc/ssh/sshd_config_に入れます

から

_man sshd_config | less +/'^ *TCPKeepAlive'
_

TCPKeepAlive

システムが他の側にTCP=キープアライブメッセージを送信する必要があるかどうかを指定します。メッセージが送信されると、接続の終了またはいずれかのマシンのクラッシュが適切に通知されます。ただし、これは接続ルートが一時的にダウンしていて、一部の人が迷惑だと感じる場合は、が終了します。一方、TCPキープアライブが送信されない場合、セッションがサーバー上で無期限にハングし、「ゴースト」が残る場合があります'ユーザーとサーバーリソースを消費しています。

デフォルトはyes'' (to send TCP keepalive messages), and the server will notice if the network goes down or the client Host crashes. This avoids infinitely hanging sessions. To disable TCP keepalive messages, the value should be set to noです。

0
Gilles Quenot

この問題が発生し、推奨される解決策をすべて試しましたが、それでも問題は解決しませんでした！

多くの解決策を試みた後、screenコマンドを使用しました。 （私のVPNクライアントはCisco-any-connectです）。

$ screen -R VPN
$ openconnect -b "your server"

資格情報を入力したら、すぐにctrl + a + dを押してセッションに戻ります。

0
Nima Ghoroubi

個人的には、SSHへのすべての接続がVPN経由でルーティングされることを好みます。 VPNが確立される前にアクティブなSSH接続の場合、ルートが変更されたため、再接続する必要があります。

autosshを使用することをお勧めしますsshクライアント設定の下に.ssh/configを追加するだけです

Host *
   ServerAliveInterval 300
   ServerAliveCountMax 2
   BatchMode yes
  • BatchModeは自動再接続を表します
  • ServerAliveキープアライブの略
0
Lukáš Viktora