Joe's Linux Blog Linux Admin tips and tricks

March 5, 2014

OpenVPN Linux clients with VPN-based DNS services

Filed under: Centos,Configuration,Installation — jfreivald @ 6:45 am

Openvpn is a really nice, relatively simple VPN service.

There are lots of tutorials on how to get things rolling. This post deals with the specific issue of DNS services made available through the VPN.

Most of my users connect to our VPN using Windows clients, which is great because OpenVPN’s Windows client has the ability to override the existing DNS services that the client is using and replace them with DNS services pushed by the VPN server.  This means that the users have access to all of our internal network using the same names as if they were connected locally.  Just what you would expect.

Under Linux this is a bit more complicated because Linux (and most of the *nix world) uses the /etc/resolv.conf file to resolve name information and the Linux Openvpn client doesn’t change the information stored thereon it’s own. This makes things painful if Linux users don’t have access to the internal DNS.

The Openvpn solution is to use the openvpn scripting feature to pass the information to a script which will process it. After a few false starts with other people’s scripts I came up with the following configuration. OpenVPN will provide warnings in syslog that scripting is enabled because almost anything can be done with scripts, even very bad things.

I hope that you find these scripts helpful.

 

Linux Client Configuration: /etc/openvpn/client.conf

client
dev tun
proto udp
script-security 2
up ./up.sh
down ./down.sh
remote <remote_server_ip_address> 1194
remote <remote_server_ip_address #2> 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/pki/tls/certs/my_cert_authority.pem
cert /etc/pki/tls/certs/my_client_certificate.pem
key /etc/pki/tls/private/my_client_key.key
ns-cert-type server
verb 1
mute 5

The up script: /etc/openvpn/up.sh:

#!/bin/bash
log="openvpn.log"
modified="0"
echo "Initialization: $0 $1 $2 $3 $4 $5 $6" >> $log
echo ";; created by openvpn" > ./resolv.conf.new 
echo ";; Initialization: $0 $1 $2 $3 $4 $5 $6" > ./resolv.conf.new
for opt in ${!foreign_option_*}; do
    optval=${!opt} 
    optiontype="`echo $optval | awk -F ' ' '{ print $1; }';`"
    if [ "$optiontype" == "dhcp-option" ]; then 
        dhcptype=`echo $optval | awk -F ' ' '{ print $2;}';` 
        dhcpval=`echo $optval | awk -F ' ' '{ print $3;}';` 
        if [ "$dhcptype" == "DNS" ]; then 
            modified="1" 
            echo "Adding DNS Server $dhcpval" >> $log 
            echo "nameserver $dhcpval" >>./resolv.conf.new 
        fi 
        if [ "$dhcptype" == "DOMAIN" ]; then 
            modified="1" 
            echo "Adding domain $dhcpval" >> $log 
            echo "domain $dhcpval" >> ./resolv.conf.new 
            echo "search $dhcpval" >> ./resolv.conf.new 
        fi 
        #Note that the DOMAIN must come first for the sed command do match properly.
        if [ "$dhcptype" == "DOMAIN-SEARCH" ]; then 
            modified="1"
            echo "Adding domain search $dhcpval" >> $log
            sed -i "s/^search \(.*\)/search \\1 $dhcpval/" ./resolv.conf.new
        fi
        dhcptype=
        dhcpval=
    else
        echo "Ignore non-dhcp option: $optval" >> $log
    fi
done
if [ "$modified" != "0" ]; then
    if [ -f /etc/resolv.conf ] && [ -f ./resolv.conf.new ]; then
        cp -f /etc/resolv.conf ./resolv.conf.saved
        if [ $? != 0 ]; then
            echo "Failed to copy existing /etc/resolv.conf." >> $log
        fi
    fi
 if [ -f ./resolv.conf.new ]; then
    echo "Replacing existing name services with VPN settings" >> $log
    cp -f ./resolv.conf.new /etc/resolv.conf
        if [ $? != 0 ]; then
            echo "Replacement resolv.conf failed." >> $log
            exit 1;
        else
            rm ./resolv.conf.new
        fi
    fi
else
    echo "/etc/resolv.conf not replaced" >> $log
fi

VPN Down script: /etc/openvpn/down.sh

#!/bin/bash
log="openvpn.log"
if [ -f ./resolv.conf.saved ]; then
    echo "Reverting to original name services." >> $log
    cp -f ./resolv.conf.saved /etc/resolv.conf
    if [ $? == 0 ]; then
        rm -f resolv.conf.saved
    else
        echo "Failed to recover /etc/resolv.conf." >> $log
    fi
else
    echo "No stored name service information available." >> $log
fi

Server configuration file: /etc/openvpn/server.conf

port 1194
dev tun
# TLS parms
tls-server
#Notice that the server uses a Diffie-Hellman file. This is to make session key generation less resource intensive.
ca /etc/pki/tls/certs/<my_certificate_authority>.pem
cert /etc/pki/tls/certs/<my_server_certificate>.pem
key /etc/pki/tls/private/<my_server_key>.key
dh /etc/pki/tls/private/<my_server_diffe_hellman_file>.pem
# Tell OpenVPN to be a multi-client udp server
mode server
# The server's virtual endpoints
ifconfig 192.168.200.1 192.168.200.2
# Require all clients to have a ccd file. This provides clients with a static IP address, and no client that isn't assigned a static IP address will be permitted to join the network.
# It is a little more overhead to keep track of clients, and probably isn't necessary in most cases.
ccd-exclusive
# Use individual client configs based on SSL CN
client-config-dir /etc/openvpn/ccd
# Pool of /30 subnets to be allocated to clients.
# When a client connects, an --ifconfig command
# will be automatically generated and pushed back to
# the client.
# ifconfig-pool 10.2.0.4 10.2.0.255
# Push route to client to bind it to our local virtual endpoint.
# These are the only routes that will be delivered to the client over the VPN. All other internet traffic will route based on their current routing tables.
push "route 192.168.200.0 255.255.255.0"
push "route 10.1.0.0 255.255.0.0"
push "route 10.2.0.0 255.255.0.0"
push "route 10.128.0.0 255.255.0.0"
# Push DHCP options to clients. Windows clients use these automatically, Linux clients need our up/down scripts to help them.
push "dhcp-option DNS 192.168.200.12"
push "dhcp-option DOMAIN work"
push "dhcp-option DOMAIN-SEARCH intranet.work"
# Client should attempt reconnection on link
# failure.
keepalive 10 60
# Delete client instances after some period
# of inactivity.
inactive 600
# Route the --ifconfig pool range into the
# OpenVPN server.
route 192.168.201.0 255.255.255.0
# The server doesn't need privileges
user openvpn
group openvpn
# Keep TUN devices and keys open across restarts.
persist-tun
persist-key
verb 2

November 17, 2010

Qt 4.7.1, alix and Qt for el6 and other housekeeping

Filed under: ALIX,Centos,Configuration,qt,Tools,Web Publishing — jfreivald @ 9:59 pm

Sorry for the delay in getting 4.7.1 out. I’m jammed up at work. I hope to get it out in the next week or so.

When Centos 6 is released I’ll be building Qt packages and ALIX images for it but I will not be abandoning el5 until it is EOL. Lord thank you for Virtual Machines!

I will also be re-configuring the repositories to make them non-centos specific.  I’ll be using ‘qt-el’ instead of ‘centos’ to eliminate confusion for RHEL users who have never heard of Centos. The update will involve moving the RPM packages to a new directory structure and updating the repository package.  The old /centos directories will have only the updated repository package in it, so when a ‘yum upgrade’ is performed on an existing machine the new package will redirect the machine to the new directory structure.  A second  ‘yum update’ will then upgrade the packages normally.

With any luck it will be entirely seamless to the community.

On a side note, we’re over 200 registered users, over 700,000 non-bot hits per month (over 670k from Yum and wget alone!), and easily keeping over 50GB of transfer per month, with a peak in October of over 110GB.  We’re #1 on Google’s search with “Qt Centos” and “ALIX Centos” and several others.  We have users in Russia, Germany, Italy, France, India, South Africa, the U.S., and dozens more, with hits coming from .com, .edu, .org and several other top-level domains.

Thank you to everyone for making this project worthwhile.

–JATF

June 9, 2010

Qt 4.6.3 and qt-creator 1.3.1-1 updates for Centos 5.5

Filed under: Centos,Configuration,qt — Tags: , , , , — jfreivald @ 9:49 am

I’ve built the Qt 4.6.3 packages for Centos 5.5.

To install, as root, type:

rpm -ivh http://software.freivald.com/centos/software.freivald.com-1.0.0-1.noarch.rpm
yum update fontconfig fontconfig-devel qt4 qt4-devel qt4-doc qt4-postgresql qt4-odbc qt4-sqlite qt-creator

Also, I’ve updated the qt-creator package to 1.3.1-1.  The issue with the package was that on the 64-bit environment, qt-creator continues to look into /usr/lib/qtcreator for it’s plugins instead of /usr/lib64/qtcreator.  I added a link from /usr/lib/qtcreator to /usr/lib64/qtcreator in the x86_64 arch build.  This means that you should not install the 32-bit version and the 64 bit version on the same machine – but I’m not sure that was ever a good idea in the first place. 🙂

Please post here if you have any issues with the Qt 4.6.3 build or the qtcreator 1.3.1-1.

I’ve also posted the public key that I use to sign the packages here.  To use it, as root, type:

rpm --import http://software.freivald.com/centos/RPM-GPG-KEY-software.freivald.com

NOTE: If you use yum-priorities you will need to set this repository to the same level as ‘core’ for these to install properly.  You’ll know if you have a priorities issue because ‘yum install qt-creator’ will scream at you that you are missing libaries.  These libraries come in the version that I compile but not in the Centos core distribution and if the priorities are wrong it will pull those packages from core.

Cheers.

May 18, 2010

Apache HTTP to HTTPS redirection with mod_rewrite

Filed under: Configuration,Web Publishing — jfreivald @ 5:00 pm

I was trying to enforce ssl for my mail server, which runs on a Hostmonster shared host. I already had SSL configured and the https:// version of the mail server worked perfectly if I typed in the correct https:// url. Trying to find a mod_rewrite configuration that would work redirect http:// connections properly and not give Server Error 500 was not so easy.

There are thousands of pages with ‘how to’ get this to work – but most of them don’t. It’s probably a problem with Apache versions or the setup that Hostmonster has, but I was finally able to devise a solution that works. Place these lines in the .htaccess file of any directory you want to rewrite:

#Hostmonster doesn’t allow +FollowSymLinks, so we use +SymLinksIfOwnerMatch instead.
Options +SymLinksIfOwnerMatch
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://new.location.com/$1 [R=301,L]

This will check to see if SSL is being used. If it isn’t, then it will redirect it to the new location and provide the client with the “permanently redirected” code (301). This will help other scripts, bookmarks, etc., update themselves auto-magically so they don’t make the same mistake twice.

Cheers.

–JATF

February 25, 2010

Qt 4.6.2 packages for Centos 5.4

Filed under: Centos,Configuration,Installation,qt,Tools — jfreivald @ 2:25 pm

UPDATE: New post for the new packages: http://joseph.freivald.com/linux/2010/06/09/qt-4-6-3-and-qt-creator-1-3-1-1-updates-for-centos-5-5/

The Qt4 packages for Centos are updated to 4.6.2 and Qt Creator is updated to 1.3.1.

To install:

rpm -ivh http://software.freivald.com/el/5/i386/os/software.freivald.com-2.0.0-0.el.noarch.rpm
yum update fontconfig fontconfig-devel qt4 qt4-devel qt4-doc qt4-postgresql qt4-odbc qt4-sqlite qt-creator

Verify that the versions are coming from software.freivald.com and enjoy. 🙂

June 5, 2009

Using rsync to update a website on hostmonster.com

Filed under: Configuration,Web Publishing — Tags: , , , , — jfreivald @ 8:32 pm

I was working on a website with a software repository that had hard links in it. Linking reduces disk space on the server, and when mirroring with rsync, reduces the time needed to sync the entire mirror.  If you are using scp or ftp to push to the server it causes problems because those programs copy each link as a new file, meaning more bandwidth consumed, more time in transfer, and more disk space used on the server side.  Just what we wanted to avoid by using rsync in the first place.

So how do we use rsync to push our web site to the server when we don’t have access to any of the rsyncd configuration files and can’t work with anything higher in the file tree than our home directory?  Sure we could pay more for a dedicated server, but why?  Lets use the tools we have as a simple user to accomplish what we need cheaply and easily.

First, get ssh access for your host server. Hostmonster requires a faxed copy of a picture ID and some other confirmation. Whatever your host requires, follow their procedures.

Test your ssh connection by opening a terminal and typing:

ssh username@hostname

It will ask you if you want to remember the host key and you should respond with a yes.

If you are able to enter your password and log in, you should be at your home directory on the host server. You should be able to see the files for your website with

ls ~/public_html

Type the following commands:

mkdir ~/.ssh
chmod 700 ~/.ssh

Log out and return to your local computer’s prompt and enter the following commands:

ssh-keygen -t dsa -C youremailaddress

ssh-keygen will ask you some questions. Using the default file name (/home/username/.ssh/id_dsa) is fine. It will also prompt you for a password. This will guard your ssh key, and you only have to type it once per session, so make it a good one.

Once complete, you should have two new files in ~/.ssh: id_dsa and id_dsa.pub.   Create a configuration shortcut:

echo -e "host shortname\n\tHostName hostname\n\tUser username" >> ~/.ssh/config

Where shortname is any name that you want to use to represent your website, hostname is the host that you are uploading to, and username is your login name on that server.

Now, send the public key to the server with:

scp ~/.ssh/id_dsa.pub username@hostname:~/.ssh/authorized_keys2

Now, to prevent yourself from having to type your password every time you want to copy files or log in, type:

ssh-add

and type your password. This will put your ssh key into an ‘agent’, which will authorize you without a password for the rest of the time you are logged in.  After you log out you’ll have to do ssh-add again, but as long as you stay logged in you should be able to log into the hosting server with a simple:

ssh shortname

No password, no nothing, and all encrypted, too.  Log out of the server and get back to a local prompt.

Change to your directory that has the local copy of your web site, such as:

cd ~/public_html

To push the update your web site, type the command is:

rsync -e ssh -vramlHP --exclude '*.log' --numeric-ids --delete --delete-excluded --delete-after --delay-updates . shortname:~/public_html/

To pull the webserver down to your local directory, the command is:

rsync -e ssh -vralmHP --exclude '*.log' --numeric-ids --delete --delete-excluded --delete-after --delay-updates shortname:~/public_html/ .

It will transmit only the changed data, saving you time, and will properly handle hard and soft links, which will save you space on the server.

Just to finish the job I put them into shell scripts by:

mkdir ~/bin
echo -e '#!/bin/bash\n\nrsync -e ssh -vralHP --numeric-ids --delete --delete-excluded --delete-after --delay-updates localdirectory shortname:~/public_html/\n' >> ~/bin/pushsite
echo -e '#!/bin/bash\n\nrsync -e ssh -vralHP --numeric-ids --delete --delete-excluded --delete-after --delay-updates shortname:~/public_html/ localdirectory\n' >> ~/bin/pullsite
chmod +x ~/bin/pushsite ~/bin/pullsite

Where localdirectory is where you want the site stored locally.

Now typing ‘pushsite’ at a terminal prompt will push the update, and ‘pullsite’ will pull it down from the server (assuming your local bin dir is in your path, which it is on most systems).  Assuming you have previously done an ‘ssh-add’, you won’t even need to use a password.

Of course, this doesn’t backup databases, just static files.  But if you are dealing with static files, rsync can’t be beat.  It will push and pull only the changes, and will properly handle hard and soft links without duplicating the files.

Happy publishing.

May 14, 2009

Subversion, SSL and Apache for Secure, Passwordless, User-based repository access controls

Filed under: Configuration — Tags: , , , — jfreivald @ 9:54 am

I get tired of passwords.  Password here, password there, everywhere a password.

I am a systems designer who does a lot of admin out of necessity.  When I get tired enough of a task, I eliminate it.

I use subversion on several projects to track documentation, source, configurations and more.  All of my servers are SSL only, and use user certificates for identity verification.  Here’s what I did to make passwordless, user-based restrictions on Subversion:

First, make sure that SSL is working on your apache server (if you get a server error when you do an https request, but http://yourserver.com:443 works then SSL is not set up right).

Put the following in /etc/httpd/conf.d/subversion.conf:

<Location /yourSubversionWebLocation>
   DAV svn
   SVNParentPath pathToYourSubversionFolder

   AuthzSVNAccessFile /etc/httpd/yourSubversionAccessFile

   SSLRequireSSL
   SSLVerifyClient require
   SSLUserName SSL_CLIENT_S_DN_Email
   SetOutputFilter DEFLATE
</Location>

Some people might want to use SSL_CLIENT_S_DN_CN as the user name instead of the email, but in my case I use the CN to put the person’s real full name in the certificate, so the email worked out better.  Also, this way I can have jsmith@company1.com and jsmith@company2.com without a collision.  Use whichever works for your situation.

Put your repository access information into your SVN access file like this:

[shared:/]
user1@yourplace.com = rw
user2@yourplace.com = rw
user3@yourplace.com = rw
readonlyuser@yourplace.com = r

[user1:/]
user1@yourplace.com = rw

[user2:/]
user2@yourplace.com = rw

[user3:/]
user3@yourplace.com = rw

Generate your User SSL keys. I do it with a script (lots of stuff on the web on how to set up your own CA, so I’m not re-hashing it here):

#!/bin/bash

[ "$1" == "" ] && exit -1;

openssl req -config openssl.myconf.cnf -new -sha1 -newkey rsa:1024 -nodes -keyout private/$1.key -out csr/$1.pem
openssl ca -config openssl.myconf.cnf -policy policy_anything -extensions usr_cert -out certs/$1.pem -infiles csr/$1.pem
openssl pkcs12 -export -clcerts -in certs/$1.pem -inkey private/$1.key -out userp12/$1.p12

Be sure to use the same email addresses that you use in the SVN authorization file.

To access subversion from the command line, put the following into your .subverions/servers file.  Be certain that the file has strict permissions (chmod -R 0600 ~user1/.subversion; chmod -R 0600 ~user1/certs):

[groups]
myrepositories = <your server address>
[myrepositories]
ssl-authority-files = /home/user1/certs/<your CA file>.crt
ssl-client-cert-file = /home/user1/certs/user1.p12
ssl-client-cert-password = <user's certificate password>

To access it with a browser, import the CA and user certificates into the browser of your choice.  Users should then be able to select your web page and auto-magically get the right repositories with the right permissions.  No passwords needed.

If you want a pretty web interface for your repository, try out websvn.  Use the same SSL configuration information for your websvn.conf as you did for your subversion.conf, follow the install information for websvn, put your repositories into your config.php and you’re done.

Powered by WordPress