add OpenVpnAuthType, OpenVpnConfig, VpnType::OpenVpn

[cachebag]

part of #288. depends on the VpnConfig trait being merged first.

changes

add VpnType::OpenVpn variant (additive, non-breaking).

add OpenVpnAuthType enum:

#[non_exhaustive]
pub enum OpenVpnAuthType {
    Password,
    Tls,
    PasswordTls,
    StaticKey,
}

add OpenVpnConfig struct with fields for:

• name, remote, port, tcp
• auth_type
• credentials: username, password
• certs: ca_cert, client_cert, client_key, key_password
• common: auth, cipher, dns, mtu, uuid

impl VpnConfig for OpenVpnConfig.

files

• api/models/vpn.rs
• lib.rs — re-exports

[Dandiggas]

i've started working on this.

[Dandiggas]

I noticed VpnConfig seems to model the common WireGuard shape well, but OpenVPN has extra fields and splits endpoint info into remote + port. Do you want OpenVpnConfig to adapt into the existing trait, or should the trait evolve to represent shared VPN concepts more generally?

[cachebag]

@Dandiggas good question! the trait should stay general. just the shared stuff: name(), vpn_type(), dns(), mtu(), uuid(). openvpn and wireguard are too different at the dbus layer to force a common shape beyond that. OpenVpnConfig owns its own remote, port, auth_type, certs, etc. the trait is just for generic dispatch in the core layer.

[Dandiggas]

Ok, should the shared trait be made more general by removing WireGuard-shaped assumptions?

[cachebag]

Ok, should the shared trait be made more general by removing WireGuard-shaped assumptions?

I'm not sure what you mean @Dandiggas. Did you take a look at https://github.com/cachebag/nmrs/tree/dev-openvpn ?

#303 already addresses the structure of the trait.