mirror of
https://github.com/OpenVPN/openvpn3.git
synced 2024-09-19 19:52:15 +02:00
20edab8dd5
When agent-enabled client disconnects, it signals destroy_tun event, which signals to agent that tun has to be teared down. For dco-win, event handle is passed to agent with /tun-open request. Before sending /establish request, client closes previous tun instance. Closing tun involves signaling destroy_tun event. Event handle is closed after signaling, and here we have a problem: - client calls /tun-open and passes event handle to agent - client calls /establish, and before that it signals destroy_tun event, which handle is now closed - at some point client disconnects and signals tun_destroy event Since event was already signaled and its handle is closed, nothing happens and agent doesn't tear tun down. As a consequence, DNS resolution might not work if DNS is overriden by VPN. When client exits, agent tears tun down by failsafe logic. This doesn't work for Connect client, which obviously doesn't exit on disconnect. Fix this problem by avoiding signaling event between /tun-open and /establish requests. This is done by not adding tun_setup destructor (which signals event) to tun_persist right after /tun-open call. There is nothing to tear down at that point yet since tun is opened later by /establish call. As a downside of this approach, we lose callback in client code if agent process dies in between /tun-setup and /establish. This is not a big problem IMO and can be fixed later. In addition to that, send destroy_tun event also in /establish request when using dco. This is needed to cover persist-tun case when we reconnect and get new tun options. In this case we instantiate new tun_setup instance, but don't call /tun-open since we keep tun handle. Hence we have to pass destroy_tun event via /establish request. Fixes https://github.com/OpenVPN/openvpn3/issues/257 Signed-off-by: Lev Stipakov <lev@openvpn.net> |
||
|---|---|---|
| .. | ||
| mac | ||
| win | ||