How to Create an Intranet with OpenVPN on Ubuntu 16.04
Step 1 — Installing and Configuring a Samba File Server
- sudo apt-get install samba samba-common python-glade2 system-config-samba
Next, make a backup of the Samba configuration file just in case we make a mistake when we modify it later.
- sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.backup
Samba also needs access through the firewall, so add a rule for Samba traffic:
- sudo ufw allow samba
Now create the directories we’ll share. First, create the
- sudo mkdir -p /samba/allusers
Then create the
- sudo mkdir -p /samba/restricted
Now, let’s edit the Samba configuration file to set up the service and define the shares. Open the Samba configuration file:
- sudo nano /etc/samba/smb.conf
Then delete all the content as we will be writing our own configuration from scratch piece by piece.
First, we specify some global settings for the Samba server. Add the following lines to the configuration file:
[global] workgroup = WORKGROUP server string = Samba Server %v netbios name = ubuntu security = user map to guest = bad user dns proxy = no interfaces = 10.8.0.1/8 bind interfaces only = yes
Let’s break down each setting:
workgroup setting specifies the workgroup the server will appear on when queried by clients. The default group is
WORKGROUPfor Windows, but you can change it if you already have a workgroup name you’re using.
server string and
netbios lines specify the name of the Samba server and its platform respectively.
security setting specifies that this will be a stand-alone file server with its own user accounts. The
map to guest setting treats all logins with an invalid username or password as guest users, and the
dns proxy setting tells Samba not to try to resolve domain names since we’re not running our own DNS for this intranet.
interfaces setting, we specify that we’re only listening for connections using the VPN server’s IP, not a publicly-accessible IP. The
bind interface tells Samba to only listen to requests originating from our VPN.
Next, we need to specify the logging settings for Samba. Add this configuration block to the file, in the
[global] ... ## Logging log level = 2 log file = /var/log/samba.log.%m max log size = 50 debug timestamp = yes
log level setting determines the level of detail you want in your log files. These levels range from 1 to 10, but we will stick with level 2 as it is a relatively light debugging level. The
log file setting specifies the file path and name of the log file, with the
max log size limiting the size of the log file. The
debug timestamp setting includes timestamps in the log.
That takes care of the global settings for our server. Now let’s create the actual share definitions. These settings specify the files we want to share, and who is allowed to access those files.
We want two shares; one called
Allusers, and another called
Restricted. Let’s define the
Allusersshare first. For this share, users can browse, write, and read files in the
/samba/allusers directory. Add this configuration to the file:
#============ Share Defenitions ================== [Allusers] path = /samba/allusers browsable = yes writable = yes guest ok = yes read only = no force user = nobody
[Allusers] block indicates that the settings that follow are only applicable to the
Allusers share. It also defines the name of the share that users will see. The
path setting specifies the file directory of the folder we want to share on our intranet. Setting
yes gives users the permission to browse within that folder as well as read and write files.
We want all users to access this share, even if they do not have a user account on the server. Remember that in the
global section we specified the
map to guest setting, meaning that users that do not have an account or valid login credentials can still access files shared as a guest. We allow those guests to access this share by setting
guest ok to
yes and then we force that user to assume the identity of
force user = nobody.
nobody user group is a known default user group on any Linux system. We can set the desired permissions on the
/samba/allusers folder to the
nobody user. Then, with Samba, we allow multiple guests to use that identity. This way we can easily manage guest user access to our system.
Now let’s create the
Restricted file share, which should only be accessible by members of the
[Restricted] path = /samba/restricted valid users = @smbrestricted guest ok = no writable = yes browsable = yes
Once again we start by specifying the directory we want to share and grant browsing and writing permissions, just like we did with the
allusers share. Then we set
valid users = @smbrestricted, which tells Samba to only allow members of the group
smbrestricted to access the share. We’ll create this group shortly.
That does it for the
smb.conf file. Your file should look like the following example:
[global] workgroup = WORKGROUP server string = Samba Server %v netbios name = ubuntu security = user map to guest = bad user dns proxy = no interfaces = 10.8.0.1/8 bind interfaces only = yes ## Logging log level = 2 log file = /var/log/samba.log.%m max log size = 50 debug timestamp = yes #============ Share Defenitions ================== [Allusers] path = /samba/allusers browsable = yes writable = yes guest ok = yes read only = no force user = nobody [Restricted] path = /samba/restricted valid users = @smbrestricted guest ok = no writable = yes browsable = yes
With the Samba configuration in place, we can create the
smbrestricted group and create our first user.
Step 2 — Configuring Access to Samba Shares
To allow access to our shares, we have to create a user account and apply appropriate permissions to the folders we’re planning to share.
First, create the
smbrestricted group with the following command:
- sudo addgroup smbrestricted
Now create a user account on the server and add it to the
smbrestricted group. We’ll create an account for
client1, which matches the name of the VPN connection created in the prerequisite tutorial:
- sudo useradd client1 -G smbrestricted
Finally, we need to assign a Samba password for
client1. With the configuration we’ve set up, Samba uses its own credential verification system that’s separate from the normal Linux system’s verification system. This is nice because we can create users that can access file shares with Samba without giving them access to log into the machine itself.
Create the Samba password for the
client1 user with the following command:
- sudo smbpasswd -a client1
Note: If you have users on your system that you’d like to also be able to access Samba shares, you’ll need to create a Samba password for those users as well, since the login systems are separate with this configuration.
Next, we set the permissions for the directories we want to share. First, we’ll set the permissions for the
- sudo chmod -R 766 /samba/allusers
- sudo chown -R nobody:nogroup /samba/allusers
This grants the owner of the directory full permissions, and only grants read and write permissions for the group and everyone else, We then change the owner and group of the share directory to
nobody:nogroup with the
There is, however, a small problem with changing the owner and group to
chmod -R 766 command only grants read and write permissions to current and new files/directories within the
/samba/allusers directory, regardless of who created those files or directories. This means that as soon as you try and create a new file inside a folder located within the
/samba/allusers directory you would get an insufficient permissions error. Remember that when you are working within the
Allusersshare you are assuming the identity of
nobody has very limited permissions.
To overcome this problem we make use of Access Control Lists, or ACLs. ACL rules let us automatically assign permissions for a user and/or group to newly created files and directories.
Set the ACL rules for the
/samba/allusers folder with the following commands:
- sudo setfacl -dm g:nogroup:rw /samba/allusers/
- sudo setfacl -dm u:nobody:rw /samba/allusers/
setfacl -dm indicates that we are defining new permission rules for a directory or file, and that in the future these permissions should be applied to newly created objects as well.
u:nobody:rw are the new ACL rules granting read and write permissions to the
nobody user and members of the group
You can learn more about ACLs from the Ubuntu Wiki.
That takes care of the guest share. Now we can set permissions for the
- sudo chmod -R 770 /samba/restricted
- sudo chown root:smbrestricted /samba/restricted
This time we completely block access to this directory except for the owner and members of the
smbrestricted group with
chmod 770. We don’t need to set ACL rules because the permissions function normally within this shared folder since we’re using authenticated user accounts.
Now that we have the shares configured, restart the Samba server so that it uses the new configuration file:
- sudo service smbd restart
We can now connect to the Samba server to upload or download files.
Step 3 — Connecting to the Samba Server From a Client
The goal of our intranet is to access and share files in a secure environment as if we were connected to the main network. When a client connects to Samba, it mounts the share directories in the file explorer of that client. Let’s test this out.
Connecting from Windows
To connect from Windows, open Windows Explorer. In the navigation bar, type in the Samba server address,
\\10.8.0.1 and press the
It might take a few moments for Windows to connect. When the connection is successful you’ll see the shared folders hosted on the intranet:
Notice that a new network mount point is created under the Network tab in the Quick access toolbar. The name of the mount point is
10.8.0.1, the same as the VPN’s IP.
You access the
Allusers share just like any other folder, as no credentials are needed. Just double-click on the folder to view its contents:
To access the
Restricted share, double-click on the folder named
Restricted. A Windows Securitypop-up will appear stating that network credentials are required to gain access.
Type in the username and password for the user you created, and optionally check the box to remember your credentials. Then click Ok to connect.
Once connected, you can create new files or folders, or even drag folders over to your server to upload them.
Connecting from Ubuntu
To connect from Ubuntu, open the file explorer and select the Connect to Server option in the sidebar on the left. This opens a new screen where we can input a server address.
smb://10.8.0.1/ and click on the Connect button in the bottom right corner. It may take a few seconds for you PC to connect to the server depending on your connection speed. When you have connected, a screen showing all the shared directories on the server will appear:
To access the
Allusers share, just double click on the folder. A login screen will appear asking for a username and password. The
Allusers share does not require any username and password, so you should select Anonymous for the Connect As option. Click on Connect and it will open the share directory for you.
Notice how these share directories are mounted in your file system after you have accessed them. The
Allusers share is mounted as a network drive alongside the other local drives.
The drive will stay mounted until the system is restarted or the drive is unmounted.
To access the
Restricted share, you need a valid username and password for login. Double click on the
and the login screen will appear again. For the Connect As option select Registered User and fill in the username and password
in the appropriate fields, leaving the Domain option as it is. Then click on Connect, and you will be able to access the shared files.
Connecting from a Mac
To connect from your Mac, open Finder, select the Go menu, and choose Connect to Server…. Then use
smb://10.8.0.1/ for the Server Address:
The rest of the connection process is identical to the process for connecting from Linux or Windows. You’ll be prompted for a username and password and will be able to view and connect to the available shares.
That takes care of our file server. Now let’s look at how to configure Apache to host websites internally and externally on the same server.
Step 4 — Configuring Access to Apache Virtual Hosts
Prior to this tutorial, you created two virtual hosts, which we’ll configure for use on our server. The first host,
example.com, will be accessible by the general public. This might be the main public web site for your domain. The second host,
intranet.example.com, will only be accessible by clients connected to the intranet.
To restrict access to
intranet.example.com, we’ll edit the configuration file for that virtual host. Open the file
- sudo nano /etc/apache2/sites-available/intranet.example.com.conf
Then change the
VirtualHost declaration from this:
Before the change, Apache would serve requests for
internal.example.com on all network interfaces. After this change, it only serves requests on our intranet interface. This is similar to the configuration we used for Samba.
Save the file and restart the Apache service:
- sudo systemctl restart apache2
We also need to allow connections through UFW for Apache to work properly. If you haven’t already done so, execute this command to allow traffic through the firewall for Apache:
- sudo ufw allow http
And if you plan to allow HTTPS traffic, allow that as well now, or configure it later with:
- sudo ufw allow https