[bug] ZeroTier VPN backend couples human-facing Vpn.name with machine configuration

[pandafy]

⚠️ Not suitable for beginners

Describe the bug
The ZeroTier VPN backend injects Vpn.name (a human-facing VPN identifier) as the ZeroTier network name into configuration context variables in two places. This creates a coupling between human administration labels and machine-consumable configuration values, causing cache invalidation issues whenever the VPN name changes.

Expected behavior
Renaming a VPN for administrative clarity should NOT require invalidating all client configurations. The human-facing label (Vpn.name) should be separate from machine configuration values.

Current problematic code locations

In get_vpn_server_context() (line 596-599):

if self._is_backend_type("zerotier") and self.network_id:
    context[context_keys["network_name"]] = self.name  # Vpn.name exposed as context variable

The architectural concern

This design conflates two separate concerns:

• Human administration - organizing and identifying VPNs (Vpn.name)
• Machine configuration - values needed for client configuration (network name)

Consequences of this coupling:

• Renaming a VPN for administrative clarity requires invalidating all client configurations
• The semantic intent is unclear in the codebase

[openwisp-companion]

Hi @Jaydeng75 👋,

Thank you for opening PR #1429 to address this issue!

GitHub did not allow the bot to assign this issue to you automatically, because you are not yet an organization member and have not previously commented on this issue.

To get assigned, please comment @openwisp-companion assign on this issue. Your comment satisfies GitHub's requirement and the bot will then assign the issue to you.

[Jaydeng75]

@openwisp-companion assign

[openwisp-companion]

This issue has been assigned to @Jaydeng75 who opened PR #1429 to address it. 🎯