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;
|
exit;
|
||||||
}
|
}
|
||||||
|
|
||||||
// Resolve HOST1 Tailscale IP
|
// Resolve HOST1's Tailscale IP through the shared resolver, not a bare `tailscale ip -4`.
|
||||||
$ip = trim(shell_exec('tailscale ip -4 ' . escapeshellarg($host1Hostname) . ' 2>/dev/null') ?: '');
|
//
|
||||||
|
// 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) {
|
if (!$ip) {
|
||||||
echo json_encode(['ok' => false, 'error' =>
|
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;
|
exit;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user