ネットワークが使えるようになる前に起動するノート PC についてのスレッドで connection.gateway-ping-timeout を見かけ、値を上げると、何かが変わります。その変化が思っている理由で効いたかどうかは別の話です。答えは、そのタイマーが動いている間アクティベーションが実際に何をしているか、そして待機には二つの終わり方があるという事実から始まります。

コマンドラインから一つの接続を追うと、意味が具体的になります。

一つのアクティベーションを追う

グローバルな既定値ではなく保存済みの接続を見るのは、これが接続ごとのプロパティだからです。付けるのは --show-secrets が本当に必要なときだけで、設定自体は秘密ではありません。

nmcli -f connection.id,connection.gateway-ping-timeout connection show
nmcli connection show "Wired connection 1" | grep gateway-ping

プロパティがゼロ、これが文書化された既定値ですが、その場合はアドレス設定が終わり次第アクティベーションが進みます。正の値にすると、IP 設定のアクティベーションはゲートウェイからの応答が届くかタイムアウトが切れるまで待ちます。

次に、イベントストリームを見ながら接続を落として上げます。見える順序がこの設定の仕事で、デバイスの状態、アドレス設定、待機、そして最後に、依存サービスが通常その順序で並べられるアクティブ状態です。

待機には二つの終わり方がある

どちらの終わり方も重要ですが、ほとんどの人は片方しか覚えていません。ゲートウェイからの応答は待機を早く終わらせ、タイムアウトもまた、何かが応答したかどうかに関係なく待機を終わらせます。このプロパティは、アクティベーションが完了する前に ping の成功を要求しません。

この一文は、ホテルや会議場のノート PC に関する多くの混乱を片づけます。そこではキャプティブポータルがログインするまで ICMP を拒否することがよくあり、タイムアウトが切れた後でも接続はアクティブになりますが、必要より遅くそうなるだけで、接続の後に並ぶすべてのサービスがそれと一緒に待ちます。

これは生存確認でもありません。説明のどこにも、接続が上がった後にゲートウェイへ ping を始めるものはなく、後からの ping が失敗したからといってアクティブなプロファイルを切断するものもありません。損失検出が必要なら、それはプロトコルやトンネルの持ち主の仕事であり、アクティベーション中に一度だけ動いたプロパティの仕事ではありません。

二つのオブジェクト、一つの設定

有線の基本プロファイルと VPN プロファイルは別々の設定オブジェクトで、片方にプロパティを設定してももう片方には影響しません。基本接続を名指す VPN プロファイルはそのアクティベーション設定を一切継承しないので、変更した値が見ていたものに効いていないように見えるのです。

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show "Office VPN" | grep gateway-ping

名前ではなく UUID を読みます。 再インストールやプロファイルの復元の後には名前が重複します、そして同じ表示名の二つの接続があると、本物はそのままなのに間違ったファイルを編集させられます。

インストールされている NetworkManager のリリースも重要です。プラグインの挙動や、接続タイプがこのプロパティを独自のアクティベーション手順にどう対応づけるかは変わりますから、見つけた記事がそのまま当てはまると決めつけず、配備するバージョンで試してください。

待機が保証できないもの

ここが最も時間を食う部分です。ローカルルーターからの応答は、アクティベーション中に一つのホストが一つの ICMP エコーに応答したことを証明します。VPN エンドポイントが名前解決できること、クライアントの身元が受け入れられること、プライベートルートが入ったこと、社内リゾルバーが応答すること、そして目的のアプリが動くことは証明しません。

それらは別々の証拠を持つ別々の依存関係です。DNS が失敗していてもゲートウェイは応答できますし、アプリの経路がすべて通っていてもゲートウェイはポリシーで ICMP を黙って捨てられます。したがってこのプロパティで足切りするのは、どの層が遅いかについての推測であり、その測定ではありません。

依存サービスの完了を待つなら、それが何を必要とするかを名指してください。割り当てアドレスはアドレス設定が答えます。トンネルはトンネル自身の状態が答えます。プライベート名は問い合わせが答えます。アプリはアプリが答え、これらの答えはどれも、ゲートウェイの名を冠したタイマーからは出てきません。

変えるなら理由を書く

承認された変更の前に、以前の値と理由を記録し、あちこちではなく特定の接続に設定します。待機を長くすると、その接続の後に並ぶすべてのアクティベーションのタイミングがずれ、遅いシステムは問題なく見え、速いシステムは壊れて見えることがあります。

歴史的な落とし穴を一つ挙げておきます。こうした値は、古いエディターにプロファイルを受け入れさせるために変えられることがあります。それが本当の話なら、出来事は二つあって一つではありません。エディターが保存し、稼働中のネットワークポリシーが変わったのですから、エディターかプラグインを直し、タイマーを元に戻してください。

NetworkManager のソースは、このプロパティを、ゲートウェイの応答かタイムアウトまでの IP アドレス設定成功の遅延として定義し、既定値はゼロとしており、そして 接続設定の定義 が、伝聞で語られる挙動を信じる前に読むべき参照先です。

関連記事