アパートを引っ越した後、とても奇妙な問題が発生しました。私は OpenVPN 接続を使用して日本からリモートで作業しており、リモート デスクトップ経由で仕事用コンピューターに接続しています。最近アパートを引っ越しました。古いアパートではすべて完璧に機能していました。そして現在、モバイル データを使用しているときはすべて正常に機能しています。しかし、新しいインターネットを使用すると、とても奇妙な問題が発生します。
VPN 接続が正常に作成され、リモート デスクトップ経由で接続できます。昨日まで、この部分は問題なく動作していました。今日から、約 1 分後にリモート デスクトップへの接続が失われます。常に例外なく発生します。これは、Parallels リモート デスクトップ クライアントを使用している場合です。Windows リモート デスクトップ クライアントを使用している場合は、まったく接続できません。
ホスト コンピューターから会社の内部 Web サイトに接続できません。ping と traceroute は実行できますが、問題ないようです。
しかし、携帯電話でホットスポットを作成し、ローカルデータを使用すると、すべて正常に動作します。
アパートには壁に埋め込まれた Ruijie AP180-AC ルーターがあります。 AP モードとルーター モードを切り替えてみましたが、違いはありませんでした。
ここで何が起こっているのか全く分からないので、どんな助けでも本当にありがたいです。私にとっては非常に奇妙な動作のように思えますが、私のネットワークの知識は非常に限られています。
答え1
不可解なネットワークの問題 (機能するものと機能しないもの、一見ランダムに機能を開始したり停止したりするもの、接続がランダムに失敗するもの) が発生する場合、多くの場合、(大量の) パケット損失が問題になっています。断片化された IP パケットは、パケット損失の潜在的な要因です。断片化されたパケットを回避するには、MTU を低くする必要があります。
これは、OpenVPN などの一部の VPN トンネルにも当てはまります。トンネルは UDP ベースであるため、トンネル接続は失われたパケットから回復できません。パケット損失はトンネル内でも発生します。一部のソフトウェアはパケット損失にうまく対応できません。
OpenVPN では、この問題に対処する方法が複数あり、それらはすべてクライアント構成ファイルに記述されます。
link-mtu 1300または（両方ではない）のいずれかを使用してtun-mtu 1300、MTUを明示的に下げます。- Path MTU Discoveryを有効にするために使用します
mtu-disc yesが、これはどうやらLinuxでのみ機能するようです。 mtu-testすべてのオペレーティングシステムで機能する可能性があるが、時間がかかる別のMTU検出メカニズムを有効にするために使用します。fragment 1300OpenVPNで内部的にフラグメンテーションを行うために使用します
さらに、mssfix 1300トンネル化された TCP 接続を動作させるために使用することもできますが、これは単なるパフォーマンスの最適化です。
これらのオプションのいずれかに低すぎる制限を選択すると、トンネル内のスループットに重大な影響を与える可能性があります。OpenVPN マニュアルでは、問題が発生した場合の開始点として 1300 を推奨しています。
IPフラグメンテーションについてさらに詳しく読むネットワークエンジニアリングのこのQ/Aについて。
通常のインターネット接続で、パケット損失が顕著かどうか確認する必要があります。数パーセントなら許容範囲ですが、10～20% またはそれ以上になると、非常に煩わしくなります。パケット損失が多すぎる場合は、どこかの接続に問題がある可能性があります。DSL の場合、屋内の電話配線が不良または古いことが原因である可能性があります。ケーブルもこれに敏感で、インピーダンスの不一致、終端の欠落、信号増幅器の不良などにも影響されます。