Thứ Ba, 27 tháng 10, 2015

Speed up OpenVPN and get faster speed over its channel

Speed up OpenVPN and get faster speed over its channel

OpenVPN is a well-known VPN client for secure remote access or virtual private networking. If you use OpenVPN and experience a slow speed over its channel, you might be getting annoyed. This issue is very common for all OpenVPN users. While the general advice you can find on the Internet is to tweak the MTU (Maximum transmission unit) value and/or MSSFIX parameters, here is another trick you should try. It can help you significantly improve the bandwith. Here's what you should try.

Open your server.conf file (see the OpenVPN installation directory in Windows and /etc/openvpn in linux) and just add these two lines:
sndbuf 0
rcvbuf 0
This will prevent OpenVPN from tweaking the buffer size between the server and the client. It will be determined by the OS. Windows users who connect to a Linux server will experience faster speeds.
Now, add the same lines to your client configuration file (*.ovpn or *.conf). If for some reason this is not possible, e.g. your client computer is not accessible, put the following additional lines in your server.conf file:
sndbuf 0
rcvbuf 0
push "sndbuf 393216"
push "rcvbuf 393216"

OpenVPN over UDP

If you are running OpenVPN over UDP, you might get a better experience by setting fixed buffer values. Try these lines:
sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"

The causes of the slowdown

You might be wondering why and how these tweaks work? Let's refer to the history of OpenVPN. In the year 2004, OpenVPN had a problem with different buffer sizes on different platforms. To unify the data transfer channel, developers set the fixed buffers to 64Kb. However, this caused completely strange issues with the MTU for all adapters in Windows. To fix it, developers hardcoded these lines, which work for non-Windows based servers and clients:
#ifndef WIN32
    o->rcvbuf = 65536;
    o->sndbuf = 65536;
#endif
These lines are still presented in the OpenVPN source code, so that is why we are getting the slowdown! Additionally, you can try experimenting with MTU and MSSFIX parameters, if you know what you are doing.
Try with these lines in your config:
tun-mtu 1400 
mssfix 1360
In the most common case, MTU on the physical interface is 1500, so it is better to set OpenVPN TUN MTU to a value lower than the real MTU, and MSSFIX to MTU-40, as in the example above.
I hope this article was helpful for you. Share your speed results if you saw a significant improvement

Thứ Sáu, 23 tháng 10, 2015

Installing Python 2.7.10 - Django on CentOS 6.5



Installing Python 2.7.10 - Django on CentOS 6

CentOS 6 still come with Python 2.6 and I need 2.7, below a simple tutorial how to achieve this with no pain and not messing with installed Python.

Update CentOS and install development tools

yum -y update
yum groupinstall -y 'development tools'
Also you need the packages below to enable SSL, bz2, zlib for Python and some utils:
1
yum install -y zlib-devel bzip2-devel openssl-devel xz-libs wget

Installing Python 2.7.8 from source
Download Python and extract it

# tar -xvf Python-2.7.8.tar


Installation process

Since we already installed all the dependencies we are ready to go:

# Enter the directory:
cd Python-2.7.10

# Run the configure:
./configure --prefix=/usr/local

# compile and install it:
make
make altinstall

# Checking Python version:
[root@nicetry ~]# python2.7 -V
Python 2.7.10
If you need set PATH variable check the line below:

export PATH="/usr/local/bin:$PATH"

Installing pip and virtualenv
Now we have Python installed, but something is missing isn’t? Yes! We need pip and virtualenv.

Install setuptools








wget --no-check-certificate https://pypi.python.org/packages/source/s/setuptools/setuptools-1.4.2.tar.gz

# Extract the files:
tar -xvf setuptools-1.4.2.tar.gz
cd setuptools-1.4.2

# Install setuptools using the Python 2.7.8:
python2.7 setup.py install

Installing pip



curl https://raw.githubusercontent.com/pypa/pip/master/contrib/get-pip.py | python2.7 -

And finally virtualenv


pip2.7 install virtualenv
And that’s all, we have Python 2.7.8 installed on CentOS.

And for Django


pip2.7 install django

Thứ Hai, 12 tháng 10, 2015

10 Minutes Install the BIND DNS Server on CentOS 6

10 Minutes Install the BIND DNS Server on CentOS 6
Huy Ha

This article will show you how to setup and configure the BIND DNS Server on 2 server Primary(master) and Secondary(slave).

As with any new server, it's always important to ensure your system is up to date. You can verify this by checking for updates using yum as follows:

yum update -y

Initial BIND Installation

To begin, we will need to install the BIND and BIND Utilities packages using yum.

yum install bind bind-utils -y

Next, we'll open the BIND (named) configuration file and make several modifications.

vi /etc/named.conf

Your "options" section should appear as follows, replacing 2.2.2.2 with the IP of your second droplet.

options {
        #listen-on port 53 { 127.0.0.1; };
        listen-on-v6 port 53 { ::1; };
        directory    "/var/named";
        dump-file    "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        allow-query { any; };
        allow-transfer     { localhost; 2.2.2.2; };
        recursion no;

        dnssec-enable yes;
        dnssec-validation yes;
        dnssec-lookaside auto;

        /* Path to ISC DLV key */
        bindkeys-file "/etc/named.iscdlv.key";

        managed-keys-directory "/var/named/dynamic";
};

Above, listen-on must be commented to listen on all available interfaces. Recursion should be turned off to prevent your server from being abused in "reflection" DDoS attacks. The allow-transfer directive whitelists transfers to your secondary droplet's IP. Furthermore, we have changed the allow-query directive to "any" in order to allow users proper access to hosted zones.

Next, we'll want to add a new zone for our first domain, you should add the following to your named.conf below the existing zones.

        zone "mydomain.com" IN {
                type master;
                file "mydomain.com.zone";
                allow-update { none; };
        };

After saving named.conf with the changes above, we're ready to create our first zone file.
Configure BIND Zones

Firstly, we'll need to open the zone file, using the name you specified in the configuration above. (Ex: mydomain.com.zone)

vi /var/named/mydomain.com.zone

We'll add the following contents to our newly created file. You should replace the applicable information with your own, where 1.1.1.1 is the IP of your first droplet, 2.2.2.2 is the IP of your second droplet and 3.3.3.3 is the IP you wish to point the domain itself to, such as a droplet running a webserver. You are free to add additional entries in the same format.

$TTL 86400
@   IN  SOA     ns1.mydomain.com. root.mydomain.com. (
        2013042201  ;Serial
        3600        ;Refresh
        1800        ;Retry
        604800      ;Expire
        86400       ;Minimum TTL
)
; Specify our two nameservers
        IN    NS        ns1.mydomain.com.
        IN    NS        ns2.mydomain.com.
; Resolve nameserver hostnames to IP, replace with your two droplet IP addresses.
ns1        IN    A        1.1.1.1
ns2        IN    A        2.2.2.2

; Define hostname -> IP pairs which you wish to resolve
@        IN    A        3.3.3.3
www        IN    A        3.3.3.3

We can now start named for the first time. This may take several minutes while named generates the rndc.key file, which only occurs on first execution.

service named restart

Once named has started successfully, we'll want to ensure that it is enabled as a startup service, by running the following:

chkconfig named on

By now, we should have a fully operational primary nameserver. You can verify that BIND is working correctly by running the following command, replacing 1.1.1.1 with the IP of your first droplet.

dig @1.1.1.1 mydomain.com

If you recieve a response which includes an answer and authority section, your nameserver has been configured correctly.
Slave Nameserver Configuration

With our primary nameserver configured, we'll now setup a slave nameserver.

As always, please assure your system is up to date by checking for updates with yum as follows:

yum update -y

We can start by installing BIND (and related utilities) on the second droplet, in the same manner as the first:

yum install bind bind-utils -y

We'll proceed by opening named.conf and making the same changes we made previously, ommitting the "allow transfer" line. This directive is unnecessary as we will only be transfering records from our primary name server.

nano -w /etc/named.conf

options {
        #listen-on port 53 { 127.0.0.1; };
        listen-on-v6 port 53 { ::1; };
        directory    "/var/named";
        dump-file    "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        allow-query { any; };
        recursion no;

        dnssec-enable yes;
        dnssec-validation yes;
        dnssec-lookaside auto;

        /* Path to ISC DLV key */
        bindkeys-file "/etc/named.iscdlv.key";

        managed-keys-directory "/var/named/dynamic";
};

We will add the zone we configured on the first droplet, this time changing the "type" directive to slave, instead of master. You should replace "1.1.1.1" with your first droplet's IP address.

zone "mydomain.com" IN {
    type slave;
    masters { 1.1.1.1; };
    file "mydomain.com.zone";
};

After configuring our slave zone, we'll start named. Again this may take several minutes while our rndc.key file is initially generated.

service named start

As with the first cloud server, we want to assure named is set to run at startup with the following:

chkconfig named on

Your slave nameserver should now be up and running. You can verify that it is fully operational by using dig again, replacing 2.2.2.2 with the IP of your second droplet.

dig @2.2.2.2 mydomain.com

After any changes you make to the master zone files, you will need to instruct BIND to reload. Remember, you must also increment the "serial" directive to ensure synchronicity between the master and slave.

To reload the zone files, we need to run the following command on the master nameserver, followed by the slave:

rndc reload

BIND in a chroot environment

It is generally advised to install the additional package "bind-chroot" which will drop the privileges of BIND into a chroot environment.

Luckily, the CentOS package makes this extremely simple. The only aspect worth noting is that active paths for BIND will change to their chrooted equivalents, for example /var/named becomes /var/named/chroot/var/named With CentOS 6, you will not need to move any files as the package automatically creates hard symlinks to the non-chrooted directories.

If you'd like to enable this feature for the added security which it provides, you can do the following:

yum install bind-chroot -y
service named restart