howto

Making service survives reboot on Ubuntu

This might seems trivial to many people. However, I don't really know how to have some of my SysV init scripts being executed every time a machine restart. For Fedora, this is very simple using chkconfig. However, I don't know what is its equivalence on Ubuntu.

Googling around and I found that the command is actually update-rc.d. A default modus operandi is

update-rc.d foobar defaults

where foobar is my init script. This will place links to /etc/init.d/foobar on appropriate run levels.

mod_rewrite

Anybody could notice that there are at least two urls that direct to this page. Originally, I registered for http://www.nattee.net/ and http://our.obor.us/. Both works well thanks to Drupal site configuration method. Drupal use name based resolution. All I have to do is to edit the setting.php to point to the same database for both of the name. Users can access my site using any of these urls and drupal simply direct it to the same place (because all information is stored in the database).

The problem is that the module from drupal that access these API does not allow me to authenticate with the API using different certificate for different host name. This is definitely not the bug of drupal because what I did in the first place is a workaround, not a recommended way. I personally says that the two urls use the same database which is originally intended to be used for single url.

The problem started when I was trying to use off-site module, e.g., Google Analytic, reCAPTCHA or mollom. These APIs require some security measurement. The APIs are available for the registered site only and they all adopt the name based identification. The method they adopt is that the RSA key is provided to the site owner and the site must supply the key when communicating with the APIs providers. Different keys are issued for different host name. In short, each call of this APIs must come from the correct URL.

RewriteCond %{HTTP_HOST} ^our\.obor\.us$ [NC]
RewriteRule ^(.*)$ http://www.nattee.net/$1 [L,R=301]

The first line simply matches the content of HTTP_POST variable with our.obor.us (using regular expression) as a first token. Then [NC] flag indicates that case is irrelevant. The second line simply match everything after the host name and prefixes it with http://www.nattee.net/. The $1 is back reference to the first line and [L,R=301] means that this line is the last rule to apply and apache should send the redirect command to the client.

That's all.

Now, it came across my mind that mod_rewrite would solve the problem. mod_rewrite is an apache module rewrite the name of the url, perfectly what I want. After reading some document, all I need to do is to put these two lines on the .htaccess

Originally, I wish to solve the problem by redirecting anything from http://our.obor.us/ to http://www.nattee.net/. The problem is that GoDaddy won't allow so, (they actually have this option but when I turned it on, nothing happens). For about a year after I adopt reCAPTCHA, nobody can post comment on http://our.obor.us/.

OpenVPN on Ubuntu

Once again I have to build up a machine for OpenVPN. I have previously wrote articles about this but when I follow those instruction it still does not work. But first, let us talk about what I want to achieved. I just simply want to set up a road warrior configuration, i.e., I would like to have a machine, from any place, to securely access all the resource within our laboratory. This is not possible via public interface because the firewall rules block most of the port. Besides, it is not secure.

Now, the generic howto of OpenVPN will lead you to the point that you have the VPN connection between the client and the server, but no other machine on the client side or the server side is accessible by both side. My previous article tells you how to set up the routing on the client such that when it wish to connect to the other machine in the office, it should be routed through OpenVPN. This seems to work so far for my last machine but actually it does not on the new machine.

The problem is that

  1. I have to enable port forwarding on the server. This is already covered in OpenVPN howto here.

Specifically for ubuntu, you have to execute the following command.

$echo 1 > /proc/sys/net/ipv4/ip_forward

This is to tell the kernel to allow routing, now. However, this does not survive a reboot. For ubuntu, you have to add the following file to /etc/sysctl.conf

net.ipv4.ip_forward=1
  1. I also need to enable NAT on the server, for WinXP, this is not actually needed, but for my latest ubuntu machine, I have to execute the following command.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

And that is enough.

OpenVPN for DotA again, once and for all

-- updated 08 March 07 --

From the stat at mybloglog, many ppl come to my web from the Google search about OpenVPN and DotA. I will summarize the howto again because my previous two entries do not give enough information.

First, let us define the problem. My particular problem is that we have several players sitting on different subnets and each subnet has a very strong firewall rules, i.e., the firewall block most of the ports and doesn't allow UDP package.

If this is not the case of you, e.g., your subnet is an open subnet then the solution is simple, just logon to any existing PvPGN server!!! (the battle.net emulator). That should solve all the problem.

However, in our case, we don't enjoy such luxury. Our network administrator are much more paranoid. UDP port is blocked, so that it is not possible for the gaming data to be sent between the player. The straightforward approach is to create some virtual privacy network (VPN). My solution uses OpenVPN. However, configuring OpenVPN is not a simple task for non-tech-savvy user. Besides, having everyone install OpenVPN seems like a bit over cost. The requirement is that the solution should be done in a minimum of fuzz.

I have to add a remark here that, if UDP is allow in your network, you might give Hamachi a try. Hamachi is a zero-configuration VPN. It is surprisingly easy to use and if every body can use Hamachi, that should be OK. But again, my situation does not sport such luxury.

In contrast, OpenVPN allows you to config various thing, you can pick protocol, port number, etc., at the cost of configuration complexity.

Now back to my solution. I am lucky enough to have a machine with a public fixed IP in one particular subnet. So, that machine is used as a central server for OpenVPN and PvPGN.

My solution is like this:

  1. Install PvPGN on that server.
  2. Install OpenVPN on that server also, and configure the server to forward the package from the VPN interface (Let that machine do NAT for its OpenVPN interface).
  3. Let the ppl on the different subnet (not the same subnet of the server) connect to the server, using OpenVPN.
  4. Let the ppl on the same subnet as the server create the game and let the others join.

This solution is possible because I configure OpenVPN to route every package from VPN client to the server subnet. Hence, gaming data using UDP port will be packed and sent to the game server via VPN, while other ppl on the same subnet of the server could directly use their network, without using OpenVPN.

Here are the detailed description of the solution.

Step 1 is really simple, just go to the PvPGN website, download the latest version and install, that should be OK.

Step 2 requires some manpower. I won't describe the detail here. My earlier post already gives some detail and the Official OpenVPN HOWTO provides a very detailed step-by-step explanation. In general, what you have to do is to set up OpenVPN server normally as described in the official how-to. Then, you have to re-configure your server to accept multiple client using the same client key (this is not recommended by the OpenVPN standard since all client would be able to decrypt other clients data, but we just want to play DotA, no secret is required to be protected. So, this should be fine).

Step 3 is to generate one client key and configuration and let the ppl on the other subnet use them. What you have to do is to configure the client configuration file such that all data that is bounded for the server subnet should go through VPN. However, this must not include the traffic from the client to the VPN server, this particular traffic has to go via the normal network, otherwise, OpenVPN will not work. This could be done in the routing setting of the client configuration file. Adding the following line should do the job.

route a.a.a.a b.b.b.b
route s.s.s.s 255.255.255.255 net_gateway 1

where a.a.a.a and b.b.b.b is the network and the subnet mask of the server while s.s.s.s is the IP of the server. Consider this example,

route 11.22.33.0 255.255.255.0
route 11.22.33.29 255.255.255.255 net_gateway 1

In this case, the network is 11.22.33.* and the server is located at 11.22.33.29.

That is all, let everybody login to the PvPGN and let someone in 11.22.33.* create a game. Everybody should be able to join and play.

Step 4 requires no explanation, I believe that you know how to create the game.

Some might ask, why we have to do step 3? The point is that, when a Warcraft III client from different subnet join the game, gaming data (UDP) must be transmit to the machine of the creator that resides on the server subnet. That is not possible, so we have to route the traffic from the client on different subnet via OpenVPN and let the OpenVPN server do NAT for us. And since we don't generally know the IP of the game creator beforehand, we simply route everything bounded for server subnet to the OpenVPN server. However, this also include the "data-for-VPN" packet to be routed in the same way, and it won't reach the server, so we have to add the exception that, if data is to be routed to the openvpn server, we simply use the normal routing.

OpenVPN and Squid

Today I cannot access my blog site from my home because of the [bad behavior] module that block malicious request. It is blocked because my home IP (dynamically determined) is listed in CBL(Composite Blocking List) because someone who used this IP a week ago seems to have lots of trojan and spam bot installed in his/her machine.

My solution is that I need another proxy and the best one out there is my own. I Installed squid in my server. However, I don't want to share this proxy with anyone else. So, this are what I have to do.

  1. setup a secure channel from my home to my server
  2. setup squid to accept only the connection from my server (itself).

The first task can be done very easily by my good old tools, OpenVPN.

  1. Install openvpn on the server and the client
  2. Setup the config file for the server, modifying the following value

    port [put port number here]
    ca easy-rsa/keys/ca.crt
    cert easy-rsa/keys/server.crt
    key easy-rsa/keys/server.key  
    dh easy-rsa/keys/dh1024.pem
    
  3. run the following command in the server (in directory /etc/openvpn/easy-rsa).

    . ./vars
    ./clean-all
    ./build-ca
    ./build-key-server server
    

    The final step will build the certificate key for openvpn. It will request some information where default value would do nicely. When the script asks for a passphrase, I simply use blank. The Yes/No questions are positive. After that, I have to build a certificate for the client by

    ./build-key client1
    

    With the same information used in the server. Finally, build the Diffie-Hellman parameters.

    ./build-dh
    
  4. After that, I take the following files to my home PC.

    ca.crt
    client1.crt
    client1.key
    
  5. Set up the config file for the client (home PC), modifying the following values

    remote [my.server.ip.address] [my port]
    

That's all.

Now, the next step is to config the squid, setting up the acl (access control list) of the squid as follows.

acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255     10.8.0.0/255.255.255.0
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443 563
acl Safe_ports port 80 21 443 563 70 210 1025-65535 280 488 591 777
acl <span class="caps">CONNECT</span> method <span class="caps">CONNECT</span>

http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny <span class="caps">CONNECT</span> !SSL_ports
http_access allow localhost
http_access deny all

These acl simply allow only http access from the localhost (which include openvpn server at 10.8.0.1) and deny the rest.

OpenVPN + NAT + PvPGN = DotA from home :D

UPDATED!!! More recent summarize and route setting can be found here.

The situation is that, our lab network is behind firewall, only a few ports/protocol are permitted. In fact, the entire network in CU has a firewall. Moreover, our network is sectioned such that ppl in the different rooms will be under different subnet. Hence, LAN game is not possible.

The problem: let me play DotA with my friend living not in our room.
subproblem 1a: let me play DotA with my friend living not in our room but in CU.
subproblem 1b: let me play DotA with my friend living outside CU.

Sol 1: Goes for public PvPGN
Status: Failed...
1a is solved. Since battle.net is just a chat room and game browsing mechanism. Once the game is created, it is listed on the battle.net (PvPGN, in our case). After that, any connection is made directly to the creator machine. In this case, that machine is inside Chula where most faculty do not apply any special firewall. But there still exists some problems. Our network is so damn slow and it is very hard to login to any PvPGN.

This solution is not OK for 1b. Even though WCIII allows us to choose any arbitrary high port, The protocol itself required UDP communication, which is blocked.

Sol 2: Use our own PvPGN
Status: Failed....
solve the sub problem of 1a. Since it is our own machine and it resides in the same network, we face no lag. However, 1b remains unsolved. Ppl outside CU can't even login to the PvPGN.

Sol 3: Zero Config VPN
Status: Failed....
We choose Hamachi. Hoping that it will create a virtual LAN for us. However, Hamachi does not work inside CU. So, this one also failed.

Sol 4:OpenVPN
Status: Very promising... but failed...
OpenVPN is highly configurable. It allows us to use either TCP or UDP and any port of our choice. We can create VPN from everywhere. However, everybody has to use OpenVPN and OpenVPN is damn hard to config for those who ain't familiar with command line. This one is not so user friendly. It is best if we can require only the ppl outside CU to use OpenVPN while the rest should do anything they like.

Sol 5: OpenVPN + PvPGN
Status: Failed...
Instead of going for a LAN game over virtual network, this choice combine the previous solutions. However, it still ain't work. With OpenVPN running on the same machine of PvPGN, ppl outside CU can login to the PvPGN and see the list of the games. Unfortunately, they cannot join since the game traffic still travels in the public internet.

Sol 6:OpenVPN + PvPGN + NAT
Status: Work!!!
This one finally work. The solution is that we must redirect the traffic from ppl outside CU to the game creator machine to travel via VPN. So there are basically two things to do

  • (1) Make the OpenVPN machine to become a NAT server
  • (2) Change the rounting of the outside machine.

To do task (1), it is very simple. Just executing these commands (as root, of course).

echo 1 > /proc/sys/net/ipv4/ip_forward
http://openvpn.net/howto.html#examples

The problem (2) can be done also by using the route command in WinXP

route <span class="caps">ADD</span> x.x.x.x <span class="caps">MASK</span> y.y.y.y z.z.z.z 

where x.x.x.x is the creator machine (or network) and y.y.y.y is the subnet mask while z.z.z.z is the gateway. In our case, it is the OpenVPN gateway side. We can check this by running

route <span class="caps">PRINT</span>

Finally, (2) can be done directly from the config file of openVPN client, by adding a line

route x.x.x.x y.y.y.y

and OpenVPN will determine the rest for you.

A special care should be taken with this route command. Do not route the entire LAB network since it will route the connection to the OpenVPN machine via itself. In other words, you should not add any routing that covers the OpenVPN machine.

UPDATED!!! More recent summarize and route setting can be found here.

Syndicate content