Refactor/mark

[Itsusinn]

A global mark

[ibigbug]

see this https://en.clash.wiki/advanced-usages/wireguard.html

[Itsusinn]

see this https://en.clash.wiki/advanced-usages/wireguard.html

We should allow overwriting the global mark by setting routing-mark in proxy conf?

Only use global mark when routing-mark is empty?

[ibigbug]

yeah that's an option too, since we hardcode 0xff now. @VendettaReborn thoughts?

[VendettaReborn]

yeah that's an option too, since we hardcode 0xff now. @VendettaReborn thoughts?

yep, it should always have a value, so I think a default global value is fine. And the question is, what's the scope of routing-mark that user can customize?
The global mark is definitely needed, but how about the group or single outbound scale? I am not sure( the clash.meta has this option in every outbound, including the outbound group. But so far, i think it's kinda useless.)

[Itsusinn]

@ibigbug @VendettaReborn
please check the major change in
clash_lib/src/session.rs
clash_lib/src/proxy/utils/socket_helpers.rs

[ibigbug]

well isn't this mostly duplicating changes in #343 ?

[Itsusinn]

well isn't this mostly duplicating changes in #343 ?

Yes i cherry pick one commit from #343. just for respect the proxy node specific mark and iface conf
And further, this pr aims to make an agreement about mark between #343 and #350

[Itsusinn]

the clash.meta has this option in every outbound, including the outbound group. But so far, i think it's kinda useless.

Agree as well, i cannot think of any use case

[VendettaReborn]

well isn't this mostly duplicating changes in #343 ?

Yes i cherry pick one commit from #343. just for respect the proxy node specific mark and iface conf And further, this pr aims to make an agreement about mark between #343 and #350

Actually, i am thinking about re-using the shadowsocks-rust's infra: https://github.com/shadowsocks/shadowsocks-rust/blob/b37c6e4dfa13af7bc65b34606baa01e78927199e/crates/shadowsocks/src/net/option.rs#L47. They have done a great job in supporting the fwmark and bind_interface as well as other options across different platforms.

[VendettaReborn]

and actually, we can also set fwmark on macos, see: https://github.com/WireGuard/wireguard-go/blob/12269c2761734b15625017d8565745096325392f/conn/mark_unix.go#L18

[Itsusinn]

Actually, i am thinking about re-using the shadowsocks-rust's infra: https://github.com/shadowsocks/shadowsocks-rust/blob/b37c6e4dfa13af7bc65b34606baa01e78927199e/crates/shadowsocks/src/net/option.rs#L47. They have done a great job in supporting the fwmark and bind_interface as well as other options across different platforms.

It seems they take fwmark and bind_interface options as an independent configuration (instead of add these options to every single proxy)?

[Itsusinn]

I think we could merge this pr as a workaround for now.
I could change those things if they don't match our need.
@ibigbug @VendettaReborn

[VendettaReborn]

I think we could merge this pr as a workaround for now. I could change those things if they don't match our need. @ibigbug @VendettaReborn

any ideas about on how to test it?

[Itsusinn]

any ideas about on how to test it?

You mean unit test？
I dont have any idea. actually.

[VendettaReborn]

any ideas about on how to test it?

You mean unit test？ I dont have any idea. actually.

I've went through the issue list of clash.meta, and one of the most frequently asked issue is about tun, and it even got routing loop in some conditions. So I think we'd better develop some ways to avoid similar problems.

[VendettaReborn]

For example, when testing fwmark & bind feature, we shall create a list of packet to example.org, with unique cookies in each http request's header. And we shall count the number of occurrence. Whenever the occurrence is 2, we knows that there must be some routing problem. What do u think? cc @Itsusinn

[ibigbug]

What about creating multiple tuns locally and listen on those tuns and expect the packets sent from the client with different marks and binds?

…

On Wed, Apr 17, 2024 at 01:18 V ***@***.***> wrote: For example, when testing fwmark & bind feature, we shall create a list of packet to example.org, with unique cookies in each http request's header. And we shall count the number of occurrence. Whenever the occurrence is 2, we knows that there must be some routing problem. What do u think? cc @Itsusinn <https://github.com/Itsusinn> — Reply to this email directly, view it on GitHub <#362 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEEVLMG7LKHWQPJGKSFHLTY5U6NBAVCNFSM6AAAAABF6KPM56VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJZGM2DKNZXG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[VendettaReborn]

But it seems that we cannot get the binded device of a interface? the libc doesn't provide this api

[ibigbug]

You create a tun, and start a listener on the tun.

From client you send packet and bind iface to that tun.

And from the listener you expect receiving traffic.

Would this not work?

[Itsusinn]

I've went through the issue list of clash.meta, and one of the most frequently asked issue is about tun, and it even got routing loop in some conditions. So I think we'd better develop some ways to avoid similar problems.

This pr actually dont cares about routing table. (auto-route do) It just make setting/getting mark/iface easier.

But indeed looping is a vital problem.

It highly depends how routing works.
On linux, tests are hard,we dont have a test environment that allows us use ip commands.
Even we have...

Anyway, i dont have any ideas about test. But i think this could be useful
https://chaochaogege.com/2021/08/01/57/

[VendettaReborn]

I think we can do the test for global proxy(tproxy/tun) by:
when a connection is intercepted via tproxy/tun, report error when the following conditions are satisfied:
a) the dst is one of the outbound handler's addresses; b)the process that owns the socket is clash-rs (since the lookup can be pretty slow, e.g. on linux, it has to lookup the proc file system, we shall only detect loop routing in debug mode or by some flags)

Thoughts? cc @ibigbug @Itsusinn

[ibigbug]

@VendettaReborn Do you see what are the common causes of the routing loop? Wrongly configed routing table? Can we do some validations during start up. And apply runtime checks as you described above?

[VendettaReborn]

these cases are just a sum up of clash.meta's issues when i read through them:

1. when clash.meta starts before network is connected
2. when there is some network switch, such as the original default interface's ip address is lost when switching from work env to home env
3. ... some wired problems

it' true that we shall prevent the routing loop as much as possible, even better with some proofs. But I still think some check may be helpful(maybe for debug?)

and the find process by socket shall also be supported for process-based rules.

[ibigbug]

Yeah I agree. I'll start working on the process rule soon.