search

liquidat / nagios-icinga-openvpn

Nagios/Icinga check for OpenVPN availability monitoring
MIT License
52 stars 27 forks source link

Documentation for tls-auth-inverse #23

Open orlitzky opened 4 years ago

orlitzky commented 4 years ago

Hi, while troubleshooting an issue today, I noticed this description for the --tls-auth-inverse flag:

  --tls-auth-inverse    set tls-auth file direction to inverse (1)

That suggests to me that passing --tls-auth-inverse to check_openvpn is analogous to setting tls-auth secret.key 1 in my openvpn.conf. However, I never even knew about this option, because things just work out of the box. Which is strange in hindsight, because my server uses tls-auth ... 0 and all of my clients use tls-auth ... 1!

Is the documentation backwards, or is something else happening?

andiwand commented 4 years ago

hey @orlitzky ! i don't remember how it is defined by openvpn but it was tricky for sure. i think i looked at their source code since i wasn't able to find documentation about it. as far as i can remember they split the tls-auth key into two pieces and use one for the server and one for the client. the option 0/1 tells the openvpn which part to use on his or their side.

orlitzky commented 4 years ago

To this day, the OpenVPN documentation about this feature is still incomprehensible =)

I guess what surprised me is that in the --help output for the plugin, the number (1) is explicitly mentioned (see my original comment). This suggests to me that it corresponds to passing --key-direction=1 to OpenVPN. But, all of my clients have --key-direction=1 and the plugin works just fine without --tls-auth-inverse. So it seems that passing --tls-auth-inverse to the plugin is the equivalent of setting --key-direction=0?

If that's actually the case, then it seems backwards, but honestly it's hard to tell. The --key-direction parameter is actually ternary, since omitting it does something different than passing either 0 or 1 as an argument. ¯\(ツ)/¯