サーバーマシンでVPNにログインした後にSSH接続が失われないようにする

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

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

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

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

1. VPSには、IPアドレス4.3.2.1/24で構成された単一のイーサネットインターフェイスがあります。
2. VPSはデフォルトゲートウェイ4.3.2.254を介してインターネットにアクセスできます
3. VPSはまだOpenVPN接続をアクティブにしていません。したがって、アクティブな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接続が確立された状態で、次のことを考えてみましょう。

4. VPS 4.3.2.1からOpenVPN接続を開始します。
5. そのため、新しいtun0インターフェイスは動的に構成されます（10.10.10.1 PTPで10.10.10.2 IPが割り当てられるとします）。

この段階では：

• IF NOルートがローカルVPSにリモートのOpenVPNサーバからプッシュされません、何もルーティングの期間に変更されます、そして、あなたのSSH接続が全く問題なく存続します。この場合、VPNを通過するトラフィックは、リモートOpenVPNサーバー（10.10.10.1）に向けられたトラフィックのみです。

• IFリモートOpenVPNのサーバは、いくつかのルートをプッシュバックし、VPSのデフォルトゲートウェイは10.10.10.1（リモートOpenVPNのエンドポイント）に置き換えられますexpecially場合、THENあなたは問題を抱えています。この場合、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ゲートウェイを介してルーティングされました。
  • 関連するdef-gw置換を使用したVPNリンクの確立後、VPN（10.10.10.1）経由でルーティングされます。

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

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

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

本当に簡単です。

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

     route add -host 9.8.7.6 gw 4.3.2.254

どこ：

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

PS：より詳細な質問を提供することで、より迅速な回答が得られるでしょう:-)

これは助けることができます：

に入れTCPKeepAlive=yesて/etc/ssh/sshd_config

から

man sshd_config | less +/'^ *TCPKeepAlive'

TCPKeepAlive

システムがTCPキープアライブメッセージを反対側に送信するかどうかを指定します。それらが送信されると、接続の切断またはマシンの1つのクラッシュが適切に通知されます。ただし、これは、ルートが一時的にダウンした場合に接続が切断されることを意味し、一部の人々はそれが煩わしいと感じています。一方、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 tono です。

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

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

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

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

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

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

Host *
   ServerAliveInterval 300
   ServerAliveCountMax 2
   BatchMode yes

• BatchModeは自動再接続の略です
• ServerAliveはKeeping Aliveの略です

VPNに接続すると、サーバーからのsshトラフィックがVPNサーバーを経由するため、sshが切断されます。したがって、これを回避するには、VPNに接続する前に次のコマンドを実行します。

route add -host your-machine-public-ip gw Server-gatway-ip dev eth0

your-machine-public-ip：SSHを実行しているマシンのIP。Server-gatway-ip：そのサーバーのGatway /ルーターのIP

上記のコマンドは、VPN Server経由ではなく、指定されたゲートウェイ経由でトラフィックをリダイレクトします。