Cara Melindungi Sambungan Rangkaian Anda Menggunakan OpenVPN

Mereka memberitahu bahawa kita hidup di dunia yang mudah alih. Bukan itu yang saya tahu: Saya jarang meninggalkan pejabat rumah saya. Tetapi tentu saja saya hanya dapat menikmati keselesaan di pejabat rumah saya kerana semua sumber pelayan yang mungkin saya perlukan tersedia dari jauh.

Rupanya saya tidak keseorangan. Hampir setiap orang yang kerjanya menyentuh IT akan mengakses alat profesional mereka dari lokasi terpencil dari semasa ke semasa. Dan memandangkan rangkaian awam di mana anda mengakses lokasi terpencil itu tidak selamat, anda pasti ingin mengawal sambungan tersebut dengan teliti.

Penyulitan laman web adalah untuk memastikan bahawa data yang digunakan oleh klien jarak jauh anda dapat dipindahkan dan tidak dapat dilihat oleh siapa pun yang mungkin mengintai di rangkaian penyambung. VPN, dengan kontras yang tajam, fokus pada memastikan bahawa data yang digunakan oleh klien jauh anda dipindahkan dengan tepat dan tidak dapat dilihat oleh sesiapa sahaja yang mungkin mengintai di rangkaian penyambung. Adakah anda melihat perbezaannya? Saya juga tidak

Sebenarnya, ada semua jenis teknologi yang dikhaskan untuk mengamankan komunikasi rangkaian, dan prinsip _defence secara mendalam_ mengajarkan kepada kita bahawa anda jangan sekali-kali bergantung pada satu sahaja. Oleh itu, di sinilah anda akan belajar mengenai _menambah lapisan perlindungan baru untuk aktiviti jarak jauh anda. Khususnya, menggunakan enkripsi untuk membina terowong rangkaian peribadi maya (VPN) untuk membenarkan sambungan jauh yang selamat dan tidak kelihatan.

Membina terowong OpenVPN

Buku Linux dalam Aksi saya - dari mana petikan artikel ini - banyak membincangkan mengenai penyulitan. SSH dan SCP dapat melindungi data yang ditransfer melalui sambungan jarak jauh (bab 3), enkripsi fail dapat melindungi data pada waktu rehat (bab 8), dan sijil TLS / SSL dapat melindungi data dalam perjalanan antara laman web dan penyemak imbas pelanggan (bab 9). Tetapi kadang-kadang keperluan anda menuntut perlindungan di rangkaian sambungan yang lebih luas, kerana kadang-kadang anda mempunyai pelbagai jenis pekerjaan yang perlu dilakukan.

F'rinstance? Sebilangan anggota pasukan anda perlu bekerja dari jalan raya menggunakan hotspot WiFi awam. Pasti tidak bijak untuk menganggap bahawa titik akses WiFi rawak selamat, tetapi orang anda memerlukan cara untuk berhubung dengan sumber syarikat. VPN untuk menyelamatkan.

Terowong VPN yang dirancang dengan betul menyediakan hubungan langsung antara klien jarak jauh dan pelayan dengan cara yang menyembunyikan data ketika dipindahkan melalui rangkaian yang tidak selamat. Tetapi bagaimana? Anda sudah melihat banyak alat yang dapat melakukannya menggunakan penyulitan. Nilai sebenar VPN adalah bahawa setelah anda membuka terowong, adalah mungkin untuk menyambungkan rangkaian jauh seolah-olah semuanya bersatu di dalam negara. Dengan cara tertentu, anda mengelakkan tempat panas kedai kopi itu.

Dengan menggunakan rangkaian yang diperluas seperti itu, pentadbir dapat menyelesaikan pekerjaan mereka di pelayan mereka di mana pun mereka berada. Tetapi yang lebih penting lagi, seperti yang anda lihat dalam gambar, syarikat yang mempunyai sumber yang tersebar di beberapa pejabat cawangan dapat menjadikan mereka semua kelihatan dan dapat diakses oleh semua pasukan yang memerlukannya ... di mana sahaja mereka berada.

Keberadaan terowong sahaja tidak menjamin keselamatan. Tetapi salah satu daripada sebilangan standard enkripsi dapat dimasukkan ke dalam reka bentuk, menjadikan banyak perkara menjadi lebih baik. Terowong yang dibina dengan pakej OpenVPN sumber terbuka menggunakan enkripsi TLS / SSL yang sama yang telah anda lihat digunakan di tempat lain. OpenVPN bukan satu-satunya pilihan yang tersedia untuk terowong, tetapi merupakan antara yang paling terkenal, dan secara meluas dianggap sedikit lebih pantas dan mungkin lebih selamat daripada Protokol Terowong Lapisan 2 alternatif menggunakan enkripsi IPsec.

Agar pasukan anda dapat berhubung dengan selamat antara satu sama lain di jalan raya atau di antara beberapa kampus, anda akan membina pelayan OpenVPN untuk membolehkan berkongsi kedua-dua aplikasi dan akses ke persekitaran rangkaian tempatan pelayan. Untuk menjadikannya berfungsi, semestinya memadai dua VM atau bekas. Satu untuk memainkan peranan pelayan / host dan yang lain dari klien.

Membangun VPN memerlukan beberapa langkah, jadi mengambil beberapa saat untuk memikirkan gambaran besar bagaimana ini akan berfungsi mungkin akan bermanfaat.

Mengkonfigurasi pelayan OpenVPN

Sebelum memulakan, berikut petua berguna. Sekiranya anda akan mengikuti proses ini sendiri - dan saya sangat mengesyorkannya - anda mungkin akan mendapati diri anda berfungsi dengan banyak tingkap terminal terbuka di desktop anda, masing-masing log masuk ke mesin yang berbeza. Ambil dari saya: pada satu ketika anda akan memasukkan perintah ke tetingkap yang salah dan benar-benar mengacaukan persekitaran anda.

Anda boleh menggunakan arahan nama host untuk menukar nama mesin yang dipaparkan pada baris perintah menjadi sesuatu yang secara visual akan mengingatkan anda di mana anda berada. Setelah selesai, anda perlu keluar dari pelayan dan log masuk semula agar tetapan baru dapat dilaksanakan.

[email protected]:~# hostname OpenVPN-Server [email protected]:~$ exit $ ssh [email protected] [email protected]:~# 

Mengikuti pendekatan itu untuk memberikan nama yang sesuai untuk setiap mesin yang anda bekerjasama akan membantu anda menjejaki lokasi anda.

Sediakan pelayan anda untuk OpenVPN

Memasang OpenVPN pada pelayan anda memerlukan dua pakej: openvpn dan, untuk menguruskan proses penjanaan kunci penyulitan, easy-rsa. Pengguna CentOS, jika perlu, terlebih dahulu memasang repositori pelepasan epel seperti yang anda lakukan pada bab 2. Untuk memberi anda cara mudah untuk menguji akses ke aplikasi pelayan, anda juga boleh memasang pelayan web Apache (apache2 untuk Ubuntu dan httpd di CentOS).

Semasa anda menyiapkan pelayan anda, anda mungkin melakukannya dengan betul dan mengaktifkan firewall yang menyekat semua port selain 22 (SSH) dan 1194 (port OpenVPN lalai). Contoh ini menggambarkan cara yang akan berfungsi pada ufw Ubuntu, tetapi saya yakin anda masih ingat firewall CentOS dari bab 9.

ufw enable ufw allow 22 ufw allow 1194

Untuk membenarkan perutean dalaman antara antara muka rangkaian pada pelayan, anda perlu melepaskan satu baris (net.ipv4.ip_forward = 1) dalam fail /etc/sysctl.conf. Ini akan membolehkan klien jarak jauh diarahkan mengikut keperluan setelah mereka berhubung. Untuk memuatkan tetapan baru, jalankan sysctl -p.

nano /etc/sysctl.conf sysctl -p

Persekitaran pelayan kini sudah siap, tetapi masih ada cara untuk pergi sebelum anda bersedia menukar suis.

Hasilkan kunci penyulitan

Semasa anda memasang OpenVPN, direktori / etc / openvpn / automatik dibuat secara automatik, tetapi belum banyak yang terdapat di dalamnya. Walau bagaimanapun, kedua-dua paket openvpn dan easy-rsa dilengkapi dengan contoh fail templat yang boleh anda gunakan sebagai asas untuk konfigurasi anda. Untuk memulakan proses pensijilan, salin direktori templat easy-rsa dari / usr / share / ke / etc / openvpn / dan kemudian ubah ke direktori easy-rsa / baru.

cp -r /usr/share/easy-rsa/ /etc/openvpn cd /etc/openvpn/easy-rsa

Fail pertama yang anda gunakan dipanggil vars ringkas, dan mengandungi pemboleh ubah persekitaran yang akan digunakan oleh easy-rsa ketika menghasilkan kuncinya. Anda mahu mengedit fail untuk menggantikan nilai anda sendiri dengan contoh lalai yang sudah ada. Inilah rupa fail saya:

export KEY_COUNTRY=”CA” export KEY_PROVINCE=”ON” export KEY_CITY=”Toronto” export KEY_ORG=”Bootstrap IT” export KEY_EMAIL=”[email protected]” export KEY_OU=”IT”

Menjalankan fail vars akan meneruskan nilainya ke persekitaran shell dari mana ia akan dimasukkan ke dalam isi kunci baru anda. Setelah selesai, skrip akan mendorong anda untuk menjalankan skrip clean-all untuk menghapus kandungan yang ada di direktori / etc / openvpn / easy-rsa / keys /.

cd /etc/openvpn/easy-rsa/ . ./vars NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/openvpn/easy-rsa/keys

Secara semula jadi, langkah seterusnya adalah menjalankan skrip clean-all ... diikuti oleh build-ca yang akan menggunakan skrip pkitool untuk membuat sijil root anda. Anda akan diminta untuk mengesahkan tetapan pengenalan yang diberikan oleh vars.

./clean-all ./build-ca Generating a 2048 bit RSA private key

Next, the build-key-server script, since it uses the same pkitool script along with the new root certificate, will ask you the same confirmation questions to generate a key pair. The keys will be given names based on the argument you pass — which, unless you’re running multiple VPNs on this machine, would normally be server, as in this example.

./build-key-server server […] Certificate is to be certified until Aug 15 23:52:34 2027 GMT (3650 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated

OpenVPN will use parameters generated using the Diffie-Hellman algorithm (by running build-dh) to negotiate authentication for new connections. The file that will be created here does not need to remain secret, but must have been generated using the build-dh script against the RSA keys that are currently active. If you create new RSA keys at some time in the future, you’ll also need to update the Diffie-Hellman file.

build-dh

Your server-side keys will now have been written to the /etc/openvpn/easy-rsa/keys/ directory, but OpenVPN doesn’t know that. By default OpenVPN will lookfor them in /etc/openvpn/, so copy them over.

cp /etc/openvpn/easy-rsa/keys/server* /etc/openvpn cp /etc/openvpn/easy-rsa/keys/dh2048.pem /etc/openvpn cp /etc/openvpn/easy-rsa/keys/ca.crt /etc/openvpn

Prepare client encryption keys

As you’ve already seen, TLS encryption uses matching key pairs, one installed on the server and the other on a remote client. That means you’re going to need client keys, and our old friend pkitool is just the thing to cook some up. This example, run while still in the /etc/openvpn/easy-rsa/ directory, passes client as an argument to generate files called client.crt and client.key.

./pkitool client

The two client files, along with the original ca.crt file that’s still in the keys/ directory, will now have to be securely transferred to your client. Because of their ownership and permissions, this might be a bit complicated. The simplest approach is to manually copy the contents of the source file (and nothing but those contents) in a terminal running on your PC’s desktop (by highlighting the text, right-clicking over it, and selecting copy from the menu) and then pasting it into a new file of the same name you create in a second terminal logged into your client.

But anyone can cut and paste. Instead, think like an admin — especially since you won’t always have access to a GUI where cutting and pasting is possible. Instead, copy the files to your user’s home directory (so a remote scp operation can access them) and then use chown to change the ownership of the files from root to your regular, non-root user so that remote scp action can work. Make sure your files are all settled and comfy for now…you’ll move them over to the client a bit later.

cp /etc/openvpn/easy-rsa/keys/client.key /home/ubuntu/ cp /etc/openvpn/easy-rsa/keys/ca.crt /home/ubuntu/ cp /etc/openvpn/easy-rsa/keys/client.crt /home/ubuntu/ chown ubuntu:ubuntu /home/ubuntu/client.key chown ubuntu:ubuntu /home/ubuntu/client.crt chown ubuntu:ubuntu /home/ubuntu/ca.crt

With a full set of encryption keys ready for action, you’ll need to tell your server how you want to build your VPN. That’s done using the server.conf file.

Configure server.conf file

How are you supposed to know what the server.conf file should look like? Well, remember the easy-rsa directory template you copied over from /usr/share/? Well there are more goodies where that came from. The OpenVPN installation left a compressed template configuration file which you can copy over to /etc/openvpn/.

I’ll use the fact that the template is compressed to introduce you to a useful tool: zcat. You’re already know about printing a file’s text contents to the screen with cat, but what if the file is compressed using gzip? Of course, you could always decompress the file and cat will then be happy to print it, but that’s one or two steps too many. Instead, as you’ve probably already guessed, you can use zcat to load the decompressed text into memory all in one step. In our case, rather than print it to the screen, you’ll redirect the text to a new file called server.conf.

zcat \ /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz > /etc/openvpn/server.conf cd /etc/openvpn

Leaving out the extensive and helpful documentation that comes with the file, here’s how it might look once you’re done editing. Note that a semicolon (;) tells OpenVPN _not_ to read and execute the line that follows.

port 1194 # TCP or UDP server? proto tcp ;proto udp ;dev tap dev tun ca ca.crt cert server.crt key server.key # This file should be kept secret dh dh2048.pem server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt push “route 10.0.3.0 255.255.255.0” keepalive 10 120 comp-lzo port-share localhost 80 user nobody group nogroup persist-key persist-tun status openvpn-status.log log openvpn.log ;log-append openvpn.log verb 3 

Let’s work through some of those one at a time.

  • By default, OpenVPN works over port 1194. You can change that — perhaps to further obscure your activities, or avoid conflicts with other active tunnels. But, because it will require the least coordination between clients, 1194 is normally your best choice.
  • OpenVPN can use either the Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) for data transmissions. TCP might be a little bit slower, but it’s more reliable and more likely to get along with applications running at either end of the tunnel.
  • You specify dev tun when you want to create a simpler and more efficient IP tunnel that transfers data content and nothing much else. If, on the other hand, you’ll need to connect multiple network interfaces (and the networks they represent) by creating an _ethernet bridge_, then you’ll have to select dev tap. If you haven’t a clue what all that means, go with tun.
  • The next four lines pass OpenVPN the names of the three server authentication files and the dh2048 parameters file you created earlier.
  • The server line sets the subnet range and netmask that will be used for assigning IP addresses to clients when they log in.
  • The optional push “route 10.0.3.0 255.255.255.0” setting will allow remote clients to access private subnets “behind” the server. Making this work will also require network configuration on to server itself to ensure that the private subnet is aware of the OpenVPN subnet (10.8.0.0).
  • port-share localhost 80 allows client traffic coming in on port 1194 to be rerouted to a local web server listening on port 80. This will be useful in our case since we’re going to use a web server to test our VPN. This will only work when proto is set to tcp.
  • The user nobody and group nogroup lines should be enabled by removing the semicolons. Forcing remote clients to work as nobody and nogroup ensures that their sessions on the server will be unprivileged.
  • log sets current log entries to overwrite old entries every time OpenVPN starts up, while log-append appends new entries to the existing log file. The openvpn.log itself will be written to the /etc/openvpn/ directory.

In addition, it is also very common to add client-to-client to the config file so multiple clients will be able to see each other in addition to the OpenVPN server.

Once you’re satisfied with your configuration, you’re ready to fire up the OpenVPN server.

systemctl start openvpn

Running ip addr to list your server’s network interfaces should now include a reference to a new interface called tun0. This will have been created by OpenVPN for the use of incoming clients.

ip addr […] 4: tun0:  mtu 1500 qdisc […] link/none inet 10.8.0.1 peer 10.8.0.2/32 scope global tun0 valid_lft forever preferred_lft forever

It is _possible_ that you’ll need to reboot the server before everything will fully function. Next stop: the client computer.

Configuring an OpenVPN client

Traditionally, tunnels are built with at least two ends (otherwise we prefer calling them caves). Having OpenVPN properly configured on the server directs traffic into and out of the tunnel at that end. But you’ll need some kind of software running on the client side as well.

In this section I’m going to focus on manually configuring a Linux computer of one sort or another to act as an OpenVPN client. But that’s not the only way you might want to consume the service. OpenVPN itself maintains client apps that can be installed and used on Windows or Mac desktop/laptops, or Android and iOS smart phones and tablets. See the //openvpn.net web site for details.

The OpenVPN package will need to be installed on the client machine, as it was on the server — although there’s no need for easy-rsa over here, because the keys you’ll use already exist. You will need to copy the client.conf template file over to the /etc/openvpn/ directory that the installation just created. This time, for some reason, the file won’t be compressed, so a regular cp will do the job just fine.

apt install openvpn cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf \ /etc/openvpn/

Most of the settings in your client.conf file will be fairly obvious: they’ll need to match the values used by the server. As you can see from the sample file below, one that’s unique is remote 192.168.1.23 1194 — which points the client to the server’s IP address. Again, make sure you use your server’s actual address. You should also force your client to verify the authenticity of the server certificate to prevent a possible man-in-the-middle attack. One way to do this is by adding the remote-cert-tls server line.

client ;dev tap dev tun proto tcp remote 192.168.1.23 1194 resolv-retry infinite nobind user nobody group nogroup persist-key persist-tun ca ca.crt cert client.crt key client.key comp-lzo verb 3 remote-cert-tls server 

Now you can move to the /etc/openvpn/ directory and pull those certification keys from the server. You will obviously substitute your server’s actual IP address or domain name for the one in the example.

cd /etc/openvpn scp [email protected]:/home/ubuntu/ca.crt . scp [email protected]:/home/ubuntu/client.crt . scp [email protected]:/home/ubuntu/client.key .

Nothing exciting is likely to happen until you start up OpenVPN on the client. Because you’ll need to pass a couple of arguments, you’ll pull the trigger from the command line. — tls-client tells OpenVPN that you’ll be acting as a client and connecting via TLS encryption while — config points to your config file.

openvpn — tls-client — config /etc/openvpn/client.conf

Read the command output carefully to make sure you’re connected properly. If something does go wrong the first time, it’s probably either due to a setting mismatch between the server and client configuration files or perhaps a network connectivity/firewall issue. Here are some troubleshooting steps:

  • Carefully read the output from the OpenVPN operation on the client — it will often contain valuable hints to exactly what it couldn’t do and why.
  • Check for error-related messages in the openvpn.log and openvpn-status.log files in the /etc/openvpn/ directory on the server.
  • Check OpenVPN-related and timely messages in the system logs on both the server and client (journalctl -ce will print out a screenfull of the most recent entries).
  • Confirm that you’ve got an active network connection between the server and client (see chapter 14 for details).

This article is excerpted from my Manning “Linux in Action” book. There’s lots more fun where this came from, including a hybrid course called Linux in Motion that’s made up of more than two hours of video and around 40% of the text of Linux in Action. Who knows…you might also enjoy my Learn Amazon Web Services in a Month of Lunches.