This is a bash script, so just put the contents in a file (give it a .sh extension if you like, but it isn't required). Let's say you decide to call it myscript.sh. Now run the command "chmod +x myscript.sh" to mark the file as executable.
Now you can run it from the directory you placed it in like so: ./myscript.sh
However, it must be run as root because it uses iptables (either use su or sudo to run it).
You can also run it automatically at boot up by placing it as an init script. That can get a bit involved so I won't go into it unless you ask.
To answer your questions:
We don't mention tun0 because we're not interested in restricting traffic on the vpn, only traffic outside the vpn.
Loopback is just basic networking stuff. Essentially it means allowing the machine to talk to itself, which is required for normal functioning.
The last rule blocks all traffic going out of eth0 that wasn't already allowed by an earlier rule. All vpn traffic will go to one of your vpn servers and will be allowed by one of the dynamically created rules in line 7.
The output rules written in english might look like this:
5) Allow the machine to send data to the local lan over eth0 IF AND ONLY IF the communication was initiated by another machine (one of your clients).
6) Allow the machine to ask for an ip address from your dhcp server.
7) Allow the machine to talk to vpn servers mentioned in /etc/openvpn/*.ovpn files.
Don't talk to anything else on eth0.
How about an example to help clarify? Say you want to go to a website over the vpn. The flow is something like this:
1) Your browser sends data to port 80 on some remote ip via tun0 (No output rule restricts this, so it is allowed. Note: the data hasn't left our machine yet.)
2) Data going out of tun0 (a virtual adapter) get encrypted by the vpn and wrapped into packets destined for the vpn server.
3) Encrypted packets are sent to the vpn server via eth0 (this is allowed by line 7 of our script - not counting the #!/bin/sh header).
4) The response is allowed because the connection was initiated by our machine (line 3 of the script).
Now we look at the flow if the vpn fails:
1) Your browser sends data to port 80 on some remote ip via eth0 (tun0 doesn't exist) and it is rejected. (Why it is rejected: Line 5 does not apply because no other machine on the lan initiated this connection. Line 6 does not apply because we are not currently getting an address via dhcp. Line 7 does not apply unless the website you are trying to hit happens to also be one of your vpn servers. Line 8 applies because the data is going out via eth0, so it is rejected.
This also prevents dns leaks even when the vpn is running:
1) Your browser (or torrent software or whatever) tries to resolve a host name.
2) The machine initiates a dns request using the dns servers in /etc/resolv.conf
3) Worst case scenario happens and the vpn provided dns servers don't respond in a timely fashion.
4) Your machine may try use the locally provided dns servers if they are still listed in /etc/resolv.conf, which generally they are.
5) If the dns servers are not on your local lan, the request will by blocked by line 8, however let's assume that you (like most people) knowingly or unknowingly use your router as a dns proxy, meaning the ip listed in /etc/resolv.conf is likely 192.168.1.1 (if you use 192.168.1.0 as your local network). That's a local lan address, but thankfully it will not match line 5 because no other machine on the lan initiated the communication and it is again blocked by line 8.
