Linux 上の Kerio：kvnet にサーバーが期待する MAC を渡す

Kerio トンネルがトラフィックを運ぶ前に、三つのことが一致していなければなりません：kvnet インターフェースのアドレス、クライアントがログに記録した値、そしてサーバーポリシーや DHCP が期待する内容です。一致しない場合でもトンネルは認証を通過して起動するため、失敗の原因が分かりにくくなるのです。インターフェースは接続ごとに作成されるため、手動で設定したアドレスはそのセッションだけに属し、他には引き継がれません。これが問題の形であり、解決策は設定ファイルではなくフックです。残るのは、値をどこから読み、どこで適用するかです。

アドレスが元に戻り続ける理由

kvnet は、接続の開始時にクライアントが作成し、終了時に削除する仮想アダプターです。そのため手動の ip link set は、適用したセッションが続く間だけ有効で、次の接続はクライアントが割り当てた値から始まります。クライアントが期待されるアドレスを適用できないマシンでは、再接続のたびに同じ不一致が再現され、リースやアクセスのルールが再びデバイスを拒否します。

このパターン自体が診断材料になります。あるセッションでは動作し、次で失敗するトンネルは、接続のたびに変わるわけではない資格情報の問題ではありません。

値をインターフェースではなくクライアントから読む

Linux クライアントはネゴシエーションの詳細をデバッグログに書き出し、使用しようとしているアドレスは接続シーケンスの最後のアドレス形式トークンとしてそこに現れます。カーネルが実際に保持している値とは readlink 一つ分の距離にあり、cat /sys/class/net/kvnet/address で確認できます。

二つが異なるなら、クライアントは正しい値を知りながら適用に失敗しており、インターフェースが存在した後にその値を適用するフックがこの隙間を埋めます。ログにアドレスがまったく含まれていないなら、問題はより手前にあり、スクリプトではなくクライアントのバージョンやサーバープロファイルに属します。

インターフェースが存在した後に適用する

NetworkManager の利用者は、その dispatcher ディレクトリにスクリプトを置き、VPN インターフェースが立ち上がったときだけ動作させられますが、systemd が管理するクライアントには、より慎重な対応が必要です。サービス起動時に走る drop-in は通常、アダプターが存在する前に発火するため、フックはアダプターを前提にせず、インターフェースを待つ必要があります。そのうえでアドレスを設定し、リンクが上がったままカーネルが拒否する場合は、いったん下げて設定し、もう一度上げてください。抽出したトークンは ip link に渡す前に MAC パターンで読み直し、予期しないログ行が引数にならないようにします。

クライアントのログから root として実行されるものには、root 所有で他人が書き込めないファイルと、検証済みアドレス以外のシェル補間をしないという、狭い所有権がふさわしいです。パターン検査はスクリプトの内側に保ってください。ログの内容に、どのコマンドを実行するかを決めさせてはいけません。

リンクではなくリースを検証する

ip -4 -o addr show dev kvnet は期待される範囲のアドレスを、ip neigh show dev kvnet はゲートウェイを示し、さらに VPN の向こう側のサービスが一つ応答するはずです。そのうえで一度切断して再接続し、アドレスが元に戻るなら、フックが誤ったイベントで動いているか、まったく動いていません。

正しいアドレスで現れながらリースを取得しないインターフェースは、サーバー側を示します。それは別の確認であり、通常は別のチームの担当です。フックを再び編集する前に、アカウントが許可されていてプールにまだアドレスがあることを確認してください。

アップグレード後に回避策を見直す

アドレスを正しく設定するクライアントのビルドではフックが古い値を適用したままになり、これは修正によって持ち込まれた新しい不具合です。他のマシンやフォーラムの投稿から MAC をコピーせず、このクライアントがこのアカウントのために記録した値を使い、検証した日付を残してください。

スクリプトは一息で読める長さに保ってください。ログを解析する回避策は本質的に一時的なものです。生き残るのは、元のスレッドを知らない将来の読者にも理解できるものだけです。