Read connection state from OpenVPN's management interface #22

New issue

Closed

opened 2026-08-17 16:57:01 -04:00 by mysticalsoap · 0 comments

mysticalsoap commented

2026-08-17 16:57:01 -04:00

Owner

tunnel.py:ovpn() (roughly 421-513) is a string-match state machine over
OpenVPN's stdout: Initialization Sequence Completed, TUN/TAP device,
PUSH: Received control message, Restart pause,
SIGTERM[soft,auth-failure], Exiting due to fatal error.

Three of those print zero times under DCO, the default data path since
OpenVPN 2.6. That is the root cause of the device-detection and DNS failures.
The management interface delivers the same information as structured, versioned
events (>STATE:, >FATAL:, >PASSWORD:, >BYTECOUNT:) over a socket.

Sequencing matters -- this is the second move, not the first:

Guard the QThread first, or this refactors a live wire
Set the device name in the config instead of parsing it
Hand DNS to OpenVPN's own --dns / resolved integration rather than porting
the pushed-DNS scrape

Roughly half of what the log scrape does is better eliminated than migrated,
and doing so shrinks what the management client has to cover.

Scope beyond parsing: auth failures arrive as an interactive >PASSWORD: prompt
answered over the socket, which changes how credentials reach OpenVPN.

Will not fix: double-hop orchestration (tunnel.py:172-198), the
stunnel/SSH side channels (tunnel.py:531-572), or firewall/bypass logic.

`tunnel.py:ovpn()` (roughly 421-513) is a string-match state machine over OpenVPN's stdout: `Initialization Sequence Completed`, `TUN/TAP device`, `PUSH: Received control message`, `Restart pause`, `SIGTERM[soft,auth-failure]`, `Exiting due to fatal error`. Three of those print **zero** times under DCO, the default data path since OpenVPN 2.6. That is the root cause of the device-detection and DNS failures. The management interface delivers the same information as structured, versioned events (`>STATE:`, `>FATAL:`, `>PASSWORD:`, `>BYTECOUNT:`) over a socket. **Sequencing matters -- this is the second move, not the first:** 1. Guard the QThread first, or this refactors a live wire 2. Set the device name in the config instead of parsing it 3. Hand DNS to OpenVPN's own `--dns` / resolved integration rather than porting the pushed-DNS scrape Roughly half of what the log scrape does is better *eliminated* than *migrated*, and doing so shrinks what the management client has to cover. Scope beyond parsing: auth failures arrive as an interactive `>PASSWORD:` prompt answered over the socket, which changes how credentials reach OpenVPN. Will **not** fix: double-hop orchestration (`tunnel.py:172-198`), the stunnel/SSH side channels (`tunnel.py:531-572`), or firewall/bypass logic.

mysticalsoap added the

architecture

label

2026-08-17 16:57:01 -04:00

mysticalsoap referenced this issue from a commit

2026-08-19 14:49:32 -04:00

change: read connection state from OpenVPN's management interface

mysticalsoap referenced this issue

2026-08-19 14:50:01 -04:00

change: read connection state from OpenVPN's management interface #68

mysticalsoap referenced this issue from a commit

2026-08-19 15:01:07 -04:00