同じルーターの背後でVPNクライアントが一台しか接続できない理由

二台のノートPCが同じ家庭内ネットワークにあり、社内VPNはそのうち一台だけを受け付けます。二台目はタイムアウトするか、一台目が切断されるまで待ち、二回の試行の間にクライアント設定を触った人はいません。資格情報は一分前に成功したものと同じで、これが認証は原因ではないという手がかりです。このパターンを作る仕組みは三つあり、どれに直面しているかはサーバー自身のログが示します。

クライアントに触れる前にゲートウェイのログを読む

二回の試行についてのサーバーの記録が最初の問いに答え、その答えは三つのうちのどれかです。二回目の試行がそのログにまったく現れなければ、パケットは待ち受け側に届いておらず、家庭内ルーターかプロバイダーの経路に問題があります。ログが試行を記録して拒否していれば、トンネルは届いており、問題はID、ライセンス、セッション上限のいずれかで、回線上の何かではありません。ログが成功したセッションを記録しているのにクライアントが失敗を報告し続けるなら、戻りの経路か、二つのクライアントに同じトンネルアドレスが割り当てられていないかを確認してください。

スマートフォンのテザリングは、一台目をつないだまま二台目のクライアントをモバイルデータで動かすことで、その二つの系統を安価に切り分けます。そこで成功すれば家庭内ネットワークが疑われ、そこで同じ失敗が出ればゲートウェイが疑われ、ルーターは潔白になります。どちらの結果も単独では決め手になりませんが、どちらも一回の試行で探索範囲を半分に削ります。

何かを変える前に結果を書き留めてください。三つのうちどれを見たかを記したメモは、クライアントのエラー画面のスクリーンショットより価値があります。

ルーターがGREとNAT-Tをどう扱うか

PPTPは典型的な原因で、制御チャネルはTCP 1723、データ経路はGRE、つまりIPプロトコル47です。多くの家庭用ルーターは制御接続を一本だけ追跡するPPTPヘルパーを積んでいるため、同じNATの背後の二台目は制御チャネルを開いても、データ経路をまったく受け取れません。番号47のTCPポートを転送してもGREには何の効果もないのは、GREがポートではなくプロトコル番号だからです。

L2TP over IPsecは、IKEがUDP 500を使い、NATトラバーサルが保護されたペイロードをUDP 4500へ移し、カプセル化はまさに一つのアドレスの背後の複数クライアントが同じゲートウェイに到達できるように存在するので、設計上別の振る舞いをします。その設計は、ゲートウェイや中間装置がアドレスごとのセッション上限を課すことを防がず、ソファから見れば二つの失敗は同じに見えます。SoftEtherの独自プロトコルも同じ種類の問題を抱え、パススルーが機能しないルーターはLANからの一台目を受け入れ、二台目を落とします。ルーターのALGまたはパススルーのスイッチを、古いクライアント向けに書かれたヘルパーが現行のクライアントの送るパケットを壊すことがあるため、両方の位置で試してください。

nc -vz 203.0.113.5 1723
sudo tcpdump -ni any proto gre

転送の上限に見えるIDの上限

ルーターだけが容疑者ではなく、ログはルーターと別の原因を区別します。OpenVPNサーバーが共通名を一つのトンネルアドレスに固定すると、両方の端末がそのアドレスを受け取り、duplicate-cnがないと新しいセッションが古いほうを押し出します。そのオプションを有効にすると両方は接続したままですが、一つのID、一つの証明書、一つの失効判断を共有することになり、見た目より悪い状態です。そうなると二台目だけを失効させることは決してできなくなり、便利なスイッチが、後で必要になるかもしれない制御を静かに奪います。

サーバーのジャーナルとステータスファイルを一緒に読み、一方は認証の判断を、もう一方は今誰が接続しているかを示します。同じ共通名と同じ仮想アドレスを共有する二件の記録は、ルーターの上限ではなくIDの衝突を裏づけます。商用ゲートウェイは独自の上限を加え、同時セッション一本だけを許すプラン、ライセンス数、公衆アドレスごとに一セッションを許す規則などがあり、ルーターの設定ではどれも変わりません。

sudo journalctl -u openvpn-server@server -n 60 --no-pager
cat /run/openvpn/server.status

修理をログの記録に合わせる

ログの拒否には、端末ごとに別の資格情報、サービス運営者からの上限引き上げ、または一台のマシン用の二つ目のゲートウェイ端点が必要です。二回目の試行がサーバーにまったく届かないなら、恒久的な修理はプロトコルを転送し複数セッションを保持できるルーターか、ルーターがうまく扱える転送方式、たとえば単一のTCPまたはUDPフローです。どちらを選ぶかはハードウェアの寿命についての判断で、クライアント設定の話ではありません。

動作している端末のプロファイルを二台目にコピーして済ませないでください。それは接続の問題をアクセス制御の問題に変え、失われたノートPCを今も使われている複製と区別できなくなります。元の不具合も隠され、三台目が現れた瞬間に再発します。

二つの生きたセッションを検証する

両方の端末を同時に接続し、それぞれで目的のアプリを動かし、そのあと片方を再接続して同じことを繰り返してください。一瞬だけ現れる二つ目のアイコンは通信について何も証明せず、十分後に落ちるセッションは、別の担当者の別の不具合です。最後にサーバーが報告する内容と利用者が見た内容を比べてください、この二つの説明はしばしば食い違うからです。

両方のセッションが生き残り通信を運べば、修正は定着し、最初に書いたメモが何が悪かったかの記録になります。片方しか生き残らないなら、最初の手順に戻り、三つのログ結果のどれになったかを確認してください、答えが変わっている可能性があるからです。ルーターのヘルパーは別のネットワークで再発する問題を覆い隠せますが、アドレスごとの上限は端末ではなく利用者についていきます。二つ目のネットワークから試すのが、実際にどちらを直したのかを知る最も安い方法です。