If the files are chmod 400, you must execute openvpn as superuser or it will fail with "Error opening configuration file. Trying to initialize a second tunnel from within the VM failed with an authentication failure, until I turned off the Windows client. While testing I already had my Windows client tunnelling all traffic through my Windows AirVPN client. I was setting this up on a virtual Arch system running in Virtualbox on a Windows 7 host machine. They should already work on default kernels. If you have a custom kernel, note that OpenVPN requires TUN/TAP modules enabled as described in OpenVPN. Presumably it should start before any torrent clients, irc, etc. For security's sake I don't want to guess at it, since some VPN users can't risk leaking untunnelled data. Perhaps putting a small script in /etc/rc.conf.d/ would be appropriate. I'm not sure how to start OpenVPN automatically. Sat Jan 21 02:16:47 2012 Initialization Sequence Completed You can keep an eye on the current load on each server, any existing issues, and a history of previous issues on AirVPNs network status page (which opens. You should get a couple dozen verbose connection logs, hopefully ending in something like.Point openvpn at the config file as superuser:.# chmod 400 air.ovpn ca.crt user.crt user.key Set permissions on the files and delete the zip:.If you move them elsewhere, set their new absolute paths in air.ovpn else it won't be able to find them. As far as the "dot" issue, it isn't new, but (for me) no longer happened in 2.13.6 But, as with all things related to computing, "Your mileage may vary.Note: These assume that these three files are in the same directory as air.ovpn. DHCPCD flat out defeats all of eddie's attempts to stop it from being leaked all over the internet (but, dhclient on DHCP is perfectly OK to use). A warning, DO NOT USE DHCPCD if you wish to keep your actual ISP address connection from being leaked. I'd hold off on using eddie 2.14 beta till they get the bugs ironed out (network lock has major issues right now!). With the current shorewall firewall, configure it AFTER you're connected to AirVPN, and make sure you choose to leave the interface that AirVPN uses (for me, it's tun0) UNPROTECTED, so eddie's firewall doesn't clash with shorewall. You'll also find they've changed how they "flush" the DNS (and THAT can cause interesting issues during connection and disconnection - ESPECIALLY when network lock is engaged). I found the "Check AirVPN DNS" option MUST be unchecked (and IF I remeber correctly - I'm currently using 2.14 beta - so did the "Check if the tunnel works" option). If it does come up, WITHOUT having FIRST restarted your computer, then you nave NO kill-switch protection.Ģ.13.6 is a bit different than 2.12.4, so you may need to adjust a few settings. You MUST restart your the computer in order to get the program interface to work again. There is one other way of checking this issue for those that don't use the net applet: If after deactivating the network lock or, exiting eddie (that had activated the network lock), the program interface should refuse to come up after you have been prompted for your password. If you still have a check mark though, it means your kill-switch protection doesn't work. Here's how to verify that your kill-switch protection is in proper working order: if your network applet icon is a dot (rather than a check mark after having deactivated the lock or exited the eddie program, then all is fine. I'm now of the opinion that if you can seem to ignore 9 )a & 9 )b, your filesystem has some issues to correct! Correcting the "lint" problem restored the proper functioning of the kill-switch protection. It turns out the update process created some "lint" issues on my filesystem, which confused/disabled eddie's kill switch protection.
0 kommentar(er)
