Names on the network
This page covers two names: the guest's own .local name, which lets the Mac reach it by name, and this Mac's .local name as the guest resolves it.
The guest's name (mDNS)
Off by default. Turn it on and reach the guest by name:
The name works in every mode, none included:
Besides its network card, a guest has the network link that a USB-connected iPhone gives the Mac. It shows up on the Mac as an en interface with a 169.254 address. That address is link-local, but the Mac reaches the guest on it directly, so in tunnel mode a connection to <name>.local reaches a guest service without a port forward.
Things to know:
- If another device already uses the name, mDNS renames the guest (
name-2). vm renamerenames a name that--mdns onderived from the VM name; a name you picked by hand stays.- A VM stopped with
vm stopor by closing its window cannot withdraw its announcement. The Mac's resolver keeps returning the old address until the cached record expires, which for a host address is 75 minutes (TTL 4500 s).
vphoned sets the name in the guest's network settings (LocalHostName) each time vphone-vm connects, and the guest's mDNSResponder announces it on every link it has.
This Mac's name in the guest
On by default. The guest resolves this Mac's mDNS name (scutil --get LocalHostName, plus .local) at once, to the address it reaches the Mac at:
To withdraw it:
To see what the guest's resolver returns, and whether each address connects:
Why it is needed
Over mDNS alone, an IPv4 lookup of the Mac's name in the guest could fail. The guest also hears the Mac on the USB link, where the Mac has no IPv4 address and answers "no such record". Whichever link answered first decided the lookup, so an app that wanted an IPv4 address got an error until a real answer had been cached from another link. A lookup also listed the Mac's 169.254 address on the USB link first; iOS routes 169.254.0.0/16 through its primary interface, so a plain socket connecting to that address could leave through en0, where nothing answers, and wait out its timeout.
vphoned registers the name with the guest's own mDNSResponder as a local record, the way an /etc/hosts line works: it answers an IPv4 lookup at once with that one address, without asking the network and without the answers it has cached. It does so each time vphone-vm connects, and again when vphoned starts, so the name is in place before apps run after a reboot. The guest's system volume is read-only, so /etc/hosts itself is not edited, and nothing is announced on any network. IPv6 lookups still go to mDNS.