JJ wrote:

> A reliable test will depend on how competent a software developer is. That
> is, whether the software provide output/result which is usable for
> determining the result of the connection or a task.

I guess I didn't word the problem set correctly, and I apologize that I
really don't know what the correct words are since I'm not a coder.

The problem, as I see it, is not whether the test is reliable since a ping
or a curl icanhazip.com will be "reliable enough" as long as the result is
an IP address that isn't what you already know to be yours from your ISP.

C:\> ping vpnserver.com
C:\> curl icanhazip.com

The problem as I see is it that there's _nothing_ you can do inside the
command window that is connecting to the VPN service other than kill it.

I must make it clear if you've never done it (although I thought it was
obvious - so that's my mistake) that you run the command and up pops
a window but there's _nothing_ you can do _in_ that window anymore.

All you can do is control-C (or more gracefully, F4) that command window.

If it works - you control-C (or more gracefully, F4) out when you want.
If it fails - you control-C (or more gracefully, F4) out of that failure.

> All programs have an exit code which can be checked with `errorlevel`, or
> `%errorlevel%` variable (if under Windows NT's CMD). It should be set
> according the result of the task given to the program, where zero is
> commonly a successful result, and a specific non zero for specific error
> code which are usually vendor specific.

But how can you test for that exit code when anything you do inside the
command window will accomplish nothing (other than F4 to gracefully exit)?
> If the software developer is not competent enough to set the program exit
> code, we can try to use the program's console output to find a specific
> keyword such as "connected", "successfully", etc. which is unique enough to
> indicate a successful result. We can use the FIND (or FINDSTR if Windows NT)
> tool to search for the keyword, where the tool will provide the result of
> the search in form of program exit code.

The problem is there is no "console" when connecting to VPN using this:
set vpncmd=C:\the\path\to\openvpn\bin\openvpn.exe
set configdir=C:\the\path\to\the\config-files\
cd %configdir%
set vpnserver=219.100.37.1.ovpn
set vpnserver=219.100.37.2.ovpn
set vpnserver=219.100.37.3.ovpn
"%vpncmd% .\%vpnserver%

If that works, all you see are these obscure lines which, for illustrative
purposes, I'll put EXACTLY verbatim below of _this_ very VPN connection!
2023-03-30 11:39:59 DEPRECATED OPTION: --cipher set to 'AES-128-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-128-CBC' to --data-ciphers or change --cipher 'AES-128-CBC' to --data-ciphers-fallback 'AES-128-CBC' to silence this warning.
2023-03-30 11:39:59 OpenVPN 2.5.8 [git:none/0357ceb877687faa] Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Dec 2 2022
2023-03-30 11:39:59 Windows version 10.0 (Windows 10 or greater) 64bit
2023-03-30 11:39:59 library versions: OpenSSL 1.1.1s 1 Nov 2022, LZO 2.10
2023-03-30 11:39:59 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
2023-03-30 11:39:59 TCP/UDP: Preserving recently used remote address: [AF_INET]211.10.41.160:1534
2023-03-30 11:39:59 Socket Buffers: R=[65536->65536] S=[65536->65536]
2023-03-30 11:39:59 UDP link local: (not bound)
2023-03-30 11:39:59 UDP link remote: [AF_INET]211.10.41.160:1534
2023-03-30 11:39:59 TLS: Initial packet from [AF_INET]211.10.41.160:1534, sid=2c3480fa 29ab1b52
2023-03-30 11:39:59 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2023-03-30 11:39:59 VERIFY OK: depth=2, C=US, O=Internet Security Research Group, CN=ISRG Root X1
2023-03-30 11:39:59 VERIFY OK: depth=1, C=US, O=Let's Encrypt, CN=R3
2023-03-30 11:39:59 VERIFY OK: depth=0, CN=opengw.net
2023-03-30 11:39:59 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256
2023-03-30 11:39:59 [opengw.net] Peer Connection Initiated with [AF_INET]211.10.41.160:1534
2023-03-30 11:40:00 SENT CONTROL [opengw.net]: 'PUSH_REQUEST' (status=1)
2023-03-30 11:40:01 PUSH: Received control message: 'PUSH_REPLY,ping 3,ping-restart 10,ifconfig 10.211.1.105 10.211.1.106,dhcp-option DNS 10.211.254.254,dhcp-option DNS 8.8.8.8,route-gateway 10.211.1.106,redirect-gateway def1'
2023-03-30 11:40:01 OPTIONS IMPORT: timers and/or timeouts modified
2023-03-30 11:40:01 OPTIONS IMPORT: --ifconfig/up options modified
2023-03-30 11:40:01 OPTIONS IMPORT: route options modified
2023-03-30 11:40:01 OPTIONS IMPORT: route-related options modified
2023-03-30 11:40:01 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2023-03-30 11:40:01 Using peer cipher 'AES-128-CBC'
2023-03-30 11:40:01 Outgoing Data Channel: Cipher 'AES-128-CBC' initialized with 128 bit key
2023-03-30 11:40:01 Outgoing Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication
2023-03-30 11:40:01 Incoming Data Channel: Cipher 'AES-128-CBC' initialized with 128 bit key
2023-03-30 11:40:01 Incoming Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication
2023-03-30 11:40:01 interactive service msg_channel=0
2023-03-30 11:40:01 open_tun
2023-03-30 11:40:01 tap-windows6 device [Local Area Connection] opened
2023-03-30 11:40:01 TAP-Windows Driver Version 9.24
2023-03-30 11:40:01 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.211.1.105/255.255.255.252 on interface {8970EFE9-1460-429C-B94D-FD7EAC28BF7C} [DHCP-serv: 10.211.1.106, lease-time: 31536000]
2023-03-30 11:40:01 Successful ARP Flush on interface [17] {8970EFE9-1460-429C-B94D-FD7EAC28BF7C}
2023-03-30 11:40:01 IPv4 MTU set to 1500 on interface 17 using SetIpInterfaceEntry()
2023-03-30 11:40:06 TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
2023-03-30 11:40:06 C:\Windows\system32\route.exe ADD 211.10.41.160 MASK 255.255.255.255 192.168.1.1
2023-03-30 11:40:06 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=35 and dwForwardType=4
2023-03-30 11:40:06 Route addition via IPAPI succeeded [adaptive]
2023-03-30 11:40:06 C:\Windows\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.211.1.106
2023-03-30 11:40:06 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=25 and dwForwardType=4
2023-03-30 11:40:06 Route addition via IPAPI succeeded [adaptive]
2023-03-30 11:40:06 C:\Windows\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.211.1.106
2023-03-30 11:40:06 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=25 and dwForwardType=4
2023-03-30 11:40:06 Route addition via IPAPI succeeded [adaptive]
2023-03-30 11:40:06 Initialization Sequence Completed

If it fails, it fails in many ways, where here is just one of them
that I tested using one of the VPN connections that fails but the point
is that whether or not it works or fails, there is no console to access.
2023-03-30 11:37:06 Windows version 10.0 (Windows 10 or greater) 64bit
2023-03-30 11:37:06 library versions: OpenSSL 1.1.1s 1 Nov 2022, LZO 2.10
2023-03-30 11:37:06 TCP/UDP: Preserving recently used remote address: [AF_INET]167.179.45.158:1314
2023-03-30 11:37:06 Socket Buffers: R=[65536->65536] S=[65536->65536]
2023-03-30 11:37:06 UDP link local: (not bound)
2023-03-30 11:37:06 UDP link remote: [AF_INET]167.179.45.158:1314
2023-03-30 11:38:06 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2023-03-30 11:38:06 TLS Error: TLS handshake failed
2023-03-30 11:38:06 SIGUSR1[soft,tls-error] received, process restarting
2023-03-30 11:38:06 Restart pause, 5 second(s)
2023-03-30 11:38:11 TCP/UDP: Preserving recently used remote address: [AF_INET]167.179.45.158:1314
2023-03-30 11:38:11 Socket Buffers: R=[65536->65536] S=[65536->65536]
2023-03-30 11:38:11 UDP link local: (not bound)
2023-03-30 11:38:11 UDP link remote: [AF_INET]167.179.45.158:1314

The only thing you _can_ do (AFAIK) in that command window is kill it.

> Some programs generate logging outputs onto the console's standard error
> handle, instead of the standard output handle. So, you'll have to check
> first, from which console's standard handle should the keyword be searched
> for.

That may be a good idea to redirect some kind of output to a log file.
But how?

> Some programs only generate logging outputs into a file using an optional
> command line switch. In ths case, the switch must be used and the keyword
> should be searched from that file.

That's a good idea to see if the openvpn.exe command has those switches.
<https://openvpn.net/community-resources/reference-manual-for-openvpn-2-0/>

Note that most people use the openvpn client GUI but I use "openvpn.exe"
so almost everything you find in a search does NOT apply to "openvpn.exe" itself.
<https://stackoverflow.com/questions/61456939/how-can-one-use-the-command-line-to-use-openvpn-on-windows>
<https://superuser.com/questions/547396/arguments-to-connect-using-open-vpn-windows-client>
<https://openvpn.net/community-resources/running-openvpn-from-a-console-window/>
etc.
--
Posted out of the goodness of my heart to disseminate useful information
which, in this case, is to faithfully try to solve this general problem.