T6928: Support for custom interface type or custom config node

[sskaje]

Change Summary

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Code style update (formatting, renaming)
• Refactoring (no functional changes)
• Migration from an old Vyatta component to vyos-1x, please link to related PR inside obsoleted component
• Other (please describe):

Related Task(s)

https://vyos.dev/T6928

Related PR(s)

vyos/vyos-documentation#1574

Component(s) name

Proposed changes

How to test

https://github.com/sskaje/vyos-clash

Smoketest result

Checklist:

• I have read the CONTRIBUTING document
• I have linked this PR to one or more Phabricator Task(s)
• I have run the components SMOKETESTS if applicable
• My commit headlines contain a valid Task id
• My change requires a change to the documentation
• I have updated the documentation accordingly

[github-actions]

👍
No issues in PR Title / Commit Title

[github-actions]

CI integration ❌ failed!

Details

CI logs

• CLI Smoketests (no interfaces) ❌ failed
• CLI Smoketests (interfaces only) 👍 passed
• Config tests 👍 passed
• RAID1 tests 👍 passed
• TPM tests 👍 passed

[sever-sever]

Instead of hardcoding some /config/utunnels/.yml why not generate .yml files from config/XML and do not use /config/utunnels at all?
Copy config on one server and paste on another is a convenient, but we will loose this due such hacks.

[sever-sever]

Can you share an example of CLI ?
I didn't get how does It looks like. Part of config you do from CLI, another part from some hardcoded path from .yml

[sskaje]

@sever-sever

I explain everything here.

Here is my project vyos-clash: https://github.com/sskaje/vyos-clash

You can see how I use my script on VyOS.

In my script, it manages binary downloading, systemd file setup. Neither VyOS nor iproutes needs to create/delete tun devices because the clash binary does.

This is similar to T5623, tun device is created by binary.

I don't think clash or Socks5 proxy should to be added to VyOS natively.
Only a few ppl, like me, old ubnt user and don't like openwrt, use such things.

Also, such VPN similar solution may meet law issues and things may change, for example, there were two clash implementions for linux, Dreamacro/clash and metaCubeX/clash.meta, the first was was removed by its author (along with many other implementions for other platforms) and only the second one is still there and renamed to https://github.com/MetaCubeX/mihomo
If we add these directly two vyos-1x, we need to rebuild vyos-1x to make changes.

That's why I start T6928 ask if VyOS has 'Support for custom interface type or custom config node'.
UBNT Edgerouter uses old tag node systems, my another project just need to create files to vyatta-cfg and make a little patches to one pm file.

For the /config, I choose this because it's safe between upgrades. I don't need to use deb post-install to perform changes.

[sever-sever]

Why not use containers if it is required only for a few users?

[sskaje]

Why not use containers if it is required only for a few users?

A few users not in China.

I don't see other linux clash solutions use containers, like ShellClash, OpenClash, using containers will make redir-host, TPROXY and TUN much more complicated.

Another thing is I'm not sure if I can make PBR work easily with clash if it's in container.

I know someone gives a LAN ip to clash container, like a VM (sth like macvlan?), but it's hard to change router address for every IoT and other devices like Google/Apple sound boxes, Switch, PS, etc, adding their ips to a PBR source ip set is much easier. (This is how I control my home devices' traffics for now, China local IoT devices to a direct connection policy group, Switch/PS/Android TV box to a VPN policy group, etc).

I also know I can set up container like another upstream router node (I don't know how to name this node), and PBR my traffic to the container and make sure container's traffic use correct route table.

Another problem, docker has been blocked in China for years, and its China mirrors have been blocked since Jun 2024.
But I can easily find proxies for github download urls. That's why I try not use docker on my routers.

My another use case is, I set up clash on my router, create a interface group like

set firewall group interface-group CLIENT_IN_DEV interface 'eth0'
set firewall group interface-group CLIENT_IN_DEV interface 'wg0'

My home devices connect via eth0, when I was not at home, I connect to my home router via wg0. Traffics from this interface group also with source ip in another group will get traffic redirected to clash so I can access github/google everywhere.