WireGuard 上の mDNS：ピアが応答するまでの三つの関門
Avahi には適格なインターフェース、グループへの経路、宛先を所有するピアが必要です。三つの関門、三つの独立した確認、そしてファンアウトはありません。
WireGuard デバイスにマルチキャストフラグを立てると、そのインターフェースはディスカバリソフトウェアにとって適格になりますが、フラグの役割はそこまでです。グループパケットをどこへ送るべきかをプロトコルに伝えるものではなく、複数のピアを持つデバイスでは明快な答えは一つもありません。稼働中のデーモンと発見されたサービスとの間には、三つの独立した関門があります。
順番に試してください。一つを通過しても、次の関門については何も分かりません。
第一の関門：フラグとデーモンのポリシー
Linux の WireGuard デバイスは ARP を持たないポイントツーポイントリンクとして作成され、既定ではマルチキャストフラグを備えません。フラグの追加はローカルなインターフェース変更であり、デバイスを管理する何かが実行します。その上に Avahi は独自の世界観を持っており、既定のポリシーはポイントツーポイントのインターフェースを完全に飛ばします。したがって、一つのパケットが動く前に、二つの独立した適格性テストが適用されます。
つまりデーモンには明示的な判断が必要であり、単にプロセスが動いているだけでは足りません。文書化されている制御には allow-interfaces、deny-interfaces、allow-point-to-point があり、最後のものが人々が見落とす設定です。
以下の確認は、リンクのフラグ、マルチキャスト経路、そしてデーモンの設定がそもそも解析できるかどうかを報告します:
ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --check正常に起動したデーモンが、あなたの関心のあるインターフェースでソケットを開いているとは限りません。サービスの状態がカバレッジと等しいと決めつけず、実際に有効な設定を読んでください。
第二の関門：グループへの経路
第二の関門は通常のルーティングです。224.0.0.251 宛てのパケットは他の何と同じように転送テーブルに従い、テーブルが物理 LAN インターフェースから送り出すなら、どの WireGuard 設定もそれを変えません。まず経路を直せば、残りの調査は短くなります。ピアの鍵に触れる前に、カーネルがグループアドレスについて何を報告するかを見てください。
| Observation | Gate it belongs to | What it does not prove |
|---|---|---|
Multicast flag present on wg0 | Interface eligibility | The daemon will use the interface |
Route to the group via wg0 | Forwarding | Any peer will receive it |
| Destination inside a peer's allowed list | Peer selection | That peer's network will answer |
特定の経路がなければ、カーネルはリンク自身のマルチキャスト処理に戻ります。だから既定の状態はフラットな LAN では正しく見え、同じグループの通信をトンネルから出すべき途端に間違って見えるのです。失敗は送信側からは静かです。問い合わせはどこかへ行き、応答は決して届きません。
第三の関門：WireGuard はパケットごとに一つのピアを選ぶ
WireGuard は許可アドレス集合で宛先を引くことで送信先のピアを選び、Linux の送信経路はその検索をパケットごとに一度だけ行います。結果は一つであり、パケットはそのピア向けに暗号化されます。同じグループプレフィックスが複数のピアの許可リストに現れても、メンバーシップや複製は生まれません。曖昧な検索が生まれ、そのうちの一つに解決されます。
端点が二つだけの専用リンクでは、これはまさに望むとおりです。意図的に運ぶグループ通信の受信者は一つだからです。五つのピアを持つインターフェースでは、これは制限であって機能ではなく、修正はどれか一つのピアの設定ではなく設計に属します。
ファンアウトする設計には、明示的なリレー、別々のリンク、またはまったく別のディスカバリ機構が必要です。どのクライアントもゲートウェイに ping できるからといって、二端点向けのレシピを多クライアント向けの解として公開するのが、これを誤って展開する道です。
受信方向の確認は異なります。受信したパケットの送信元は、認証済みピアの許可リストの内側になければなりません。そこにマルチキャストの宛先を加えても 送信元の本当の所有権を置き換えることにはなりません。
リフレクションは境界であり、橋ではありません
Avahi のリフレクターは、選択したインターフェース間で mDNS メッセージをアプリケーション層で再現します。ネットワーク間のディスカバリ境界であり、イーサネットブリッジでも汎用マルチキャストルーターでもありません。同じネットワークに接続された二つのリフレクターは、繰り返しの告知のループを喜んで作ります。
リフレクションはサービス名とそのメタデータを別のネットワークへ渡すことでもあり、これはルーティングの判断であると同時にプライバシーの判断です。選択するインターフェースを制限し、インストールされたバージョンが対応している場合はサービスフィルターを使い、許可された利用者に必要な告知だけが境界を越えるようにしてください。
発見と利用は別の結果のままです。クライアントは、告知されたアドレスがクライアントの場所から到達できないサービスや、そのアクセスポリシーがポートを拒否するサービスの告知を見ることがあります。告知が現れた後にサービスの接続を確認し、アプリケーションが安定した DNS 名や明示的なサーバーアドレスに対応しているなら、リンクローカルなディスカバリを広げるよりそちらを優先してください。暗号鍵ルーティングの説明は、このすべてが依存する宛先ベースのピア選択を扱っています。