Possible conflict of documented systemd service definition and eBPF

[wheat0r]

Verify steps

• [X] 如果你可以自己 debug 并解决的话，提交 PR 吧 Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.
• [X] 我已经在 Issue Tracker 中找过我要提出的问题 I have searched on the issue tracker for a related issue.
• [X] 我已经使用 dev 分支版本测试过，问题依旧存在 I have tested using the dev branch, and the issue still exists.
• [X] 我已经仔细看过 Documentation 并无法自行解决问题 I have read the documentation and was unable to solve the issue.
• [X] 这是 Clash 核心的问题，并非我所使用的 Clash 衍生版本（如 OpenClash、KoolClash 等）的特定问题 This is an issue of the Clash core per se, not to the derivatives of Clash, like OpenClash or KoolClash.

Clash version

Premium

What OS are you seeing the problem on?

Linux

Clash config

interface-name: eth0
routing-mark: 7777
ebpf:
  redirect-to-tun:
    - eth0
tun:
  enable: true
  stack: system

Clash log

level=error msg="Start Tun interface error: not found v4 address for interface eth0"

Description

clash on a daemon 提到的systemd service configuration只通过After=network.target体现对网络的依赖。 在一些情况下，当IP地址生效不够快的时候，会出现因为网卡没有地址而无法启动tun。 而当ebpf启用的时候，这个问题还会导致整个主机的inbound连接断开。

临时解决办法是手写[email protected]服务确保网卡IP地址已经存在：

[Unit]
Description=Wait for Network to be Configured
Documentation=man:systemd-networkd-wait-online.service(8)
DefaultDependencies=no
Conflicts=shutdown.target
Requires=systemd-networkd.service
After=systemd-networkd.service
Before=network-online.target shutdown.target

[Service]
Type=oneshot
ExecStart=/lib/systemd/systemd-networkd-wait-online -i eth0 -4
RemainAfterExit=yes

[Install]
WantedBy=network-online.target

再在clash的service配置中依赖这个[email protected]服务

建议可以在网卡IP地址没有生效之前等待一下，而不是直接报错。或者避免ebpf在tun没生效的情况下处理流量。

[fanvinga]

可以在Clash的ExecStart之前加ExecStartPre来做检查吧

[wheat0r]

可以在Clash的ExecStart之前加ExecStartPre来做检查吧

看你喜欢什么办法了，总之是要检查

[BirkhoffLee]

https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/:

network-online.target is a target that actively waits until the nework is "up", where the definition of "up" is defined by the network management software. Usually it indicates a configured, routable IP address of some kind. Its primary purpose is to actively delay activation of services until the network is set up. It is an active target, meaning that is may be pulled in by the services requiring the network to be up, but is not pulled in by the network management service itself. By default all remote mounts defined in /etc/fstab pull this service in, in order to make sure the network is up before it is attempted to connect to a network share. Note that normally, if no service requires it, and if no remote mount point is configured this target is not pulled into the boot, thus avoiding any delays during boot should the network not be available. It is strongly recommended not to pull in this target too liberally: for example network server software should generally not pull this in (since server software generally is happy to accept local connections even before any routable network interface is up), its primary purpose is network client software that cannot operate without network.

Also refer https://unix.stackexchange.com/a/126146.

Seems this is sufficient in the most recent distros?

[Unit]
Wants=network-online.target
After=network.target network-online.target

[wheat0r]

Seems this is sufficient in the most recent distros?

network-online.target only monitors if interface is UP. But the Tun feature only works while IP address is ready. Sometimes IP address would be ready later than physical interface when DHCP or Spanning-tree enabled. As I wrote in original post, I guess, eBPF would run and lead traffic to Tun before Tun is ready. Then Tun won't start, because of the gap between physical interface and IP address. So eBPF would lead traffic to nowhere and break all inbound requests.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days