| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
The gateway-direct-mode.service was never triggering when WireGuard
interfaces were removed, leaving VPN iptables rules active even when
VPN was disconnected. This caused internet connectivity to fail in
direct mode.
Root cause: SYSTEMD_WANTS in udev rules only works for ACTION=="add"
events. When a device is removed, the device unit is already gone
before systemd can process the SYSTEMD_WANTS dependency, so the
service never starts. This is a documented systemd limitation.
Fix: Replace SYSTEMD_WANTS with RUN+ for the remove action, which
executes systemctl directly during udev event processing without
requiring a device unit to exist.
References:
- https://stackoverflow.com/questions/72208534/why-does-systemd-wants-not-pass-a-parameter-to-a-service-file-from-a-udev-remov
- https://stackoverflow.com/questions/73148448/how-to-start-systemd-user-service-when-device-is-removed-and-stop-it-when-devic
- https://bugzilla.redhat.com/show_bug.cgi?id=871074https://bugzilla.redhat.com/show_bug.cgi?id=871074
- https://unix.stackexchange.com/questions/528803/systemd-doesnt-stop-the-service-when-the-device-is-removed
The VPN mode (ACTION=="add") continues to use SYSTEMD_WANTS as it
works correctly for device addition events.
|
|
The ansible vars fail on CI because the validate arguments task runs way
before the setting of the variables, which causes the ansible undefined
vars on CI to cause errors.
This is a way better approach of having the static values as defaults
and allowing setting the variables to ansible vars in the host/group vars
|
|
|
|
|
|
This reverts commit fdd0b5b58f0ebd39ad05e2dcb17faa6603145f97.
|
|
This reverts commit 025abf3ce9497f51d21b14aa31907c0c3bd75ecf.
|
|
|
|
As the role now functions as a gateway and not just a wireguard gateway
it's better name for clarity
|
