Resolve the partner through the shared Tailscale resolver, so a shared-tailnet peer is findable
This commit is contained in:
@@ -234,11 +234,24 @@ if ($action === 'pull') {
|
||||
exit;
|
||||
}
|
||||
|
||||
// Resolve HOST1 Tailscale IP
|
||||
$ip = trim(shell_exec('tailscale ip -4 ' . escapeshellarg($host1Hostname) . ' 2>/dev/null') ?: '');
|
||||
// Resolve HOST1's Tailscale IP through the shared resolver, not a bare `tailscale ip -4`.
|
||||
//
|
||||
// master.conf records the OS hostname (unRAID-Gmer4Lfe). Tailscale knows the same machine by
|
||||
// its own name, and when the two nodes are in different tailnets linked by node sharing, a
|
||||
// shared peer is only addressable by its full name — `unraid-gmer4lfe.tonkinese-monster.ts.net`
|
||||
// resolves while both `unRAID-Gmer4Lfe` and `unraid-gmer4lfe` fall through to public DNS and
|
||||
// fail. A bare lookup therefore reported "is Tailscale running on both servers?" on a mesh
|
||||
// where Tailscale was running perfectly on both.
|
||||
//
|
||||
// vv_resolve_tailscale_ip() already handles this: it tries the direct lookup, then falls back
|
||||
// to an unambiguous prefix match against `tailscale status` with the domain stripped, and
|
||||
// refuses to guess when more than one peer could qualify.
|
||||
$ip = vv_resolve_tailscale_ip($host1Hostname);
|
||||
if (!$ip) {
|
||||
echo json_encode(['ok' => false, 'error' =>
|
||||
"Cannot resolve Tailscale IP for $host1Hostname — is Tailscale running on both servers?"]);
|
||||
"Cannot resolve a Tailscale address for $host1Hostname. Check `tailscale status` on "
|
||||
. "this server — the name in master.conf must match a peer there, or be an unambiguous "
|
||||
. "prefix of one."]);
|
||||
exit;
|
||||
}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user