Remove tun-setup and the attach path it served
The managed interface supersedes both. They go together because apart they are useless: attaching needs an interface somebody prepared, and tun-setup existed only to say how to prepare one. This also corrects what the last commit's README claimed. It said the manual route was needed on macOS and Windows; it was not, and could not be. The recipe printed Linux `ip` commands, and a persistent TUN that a second process can attach to is a Linux concept — macOS creates a utun by opening a control socket and there is nothing to hand over. So those platforms were never served by this path, and their honest state is that a real interface waits on a provisioner, with --no-tun meanwhile. Gone with it: the interface-existence check, the /proc/net/if_inet6 address inspection and its DAD flag decoding, and the --interface flag, which had one mode left. Kept: the check that the allocated IPv4 address is really on a local interface. The agent now assigns that address itself, so the check is no longer telling a user what to run — it verifies the outcome instead of trusting it, which is worth keeping precisely because the assumptions around Linux address behaviour have been wrong here more than once. Its message says which interface should have had the address rather than a command to run. Boxing Up(UpArgs) is fallout: TunSetupArgs had been masking how much larger that variant is than its siblings. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
1 parent
b23e832a73
commit
4759e47e31
10 files changed
+106
-669
No files matched your search
@@ -35,10 +35,9 @@
|
||||
//! The only part that needs privileges is the packet interface. With
|
||||
//! [`tun::MemoryTunFactory`] the whole data plane — handshake, encryption,
|
||||
//! routing, address ownership — runs and is tested with no privileges at all.
|
||||
//! For real traffic there are two ways in: [`provision::ManagedTunFactory`],
|
||||
//! where the agent creates and configures the interface itself over netlink
|
||||
//! and removes it again on exit, and `SystemTunFactory`, which attaches to an
|
||||
//! interface somebody else prepared and needs no privileges.
|
||||
//! For real traffic there is [`provision::ManagedTunFactory`], where the
|
||||
//! agent creates and configures the interface itself over netlink and
|
||||
//! removes it again on exit.
|
||||
//!
|
||||
//! See `docs/wireguard.md` for the full picture.
|
||||
|
||||
@@ -74,9 +73,3 @@ pub use tun::{MemoryTun, MemoryTunFactory, TunDevice, TunFactory, TunRequest, ad
|
||||
|
||||
#[cfg(all(feature = "tun-device", target_os = "linux"))]
|
||||
pub use provision::NetlinkProvisioner;
|
||||
|
||||
#[cfg(feature = "tun-device")]
|
||||
pub use tun::{
|
||||
Assigned, SystemTunFactory, interface_addresses, interface_exists, parse_if_inet6,
|
||||
setup_commands,
|
||||
};
|
||||
Reference in new issue
Block a user