일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- openssl
- SwiftUI
- Android
- 안드로이드
- OSX
- SSL
- FIDO2
- 앱리소스
- 2FA
- SSH
- apple
- MYSQL
- 인증
- 애플
- OTP
- Xcode
- otpkey
- MFA
- SWIFT
- appres
- WebAuthn
- css
- kmip
- 앨범북
- MSYS2
- 앱스토어
- fido
- Nodejs
- git
- albumbook
- Today
- Total
인디노트
Configure openvpn on a Debian server and client 본문
Configure openvpn on a Debian server and client
These notes cover the installation of OpenVPN on a Debian server and client. Once setup, all internet traffic, including browser traffic, from the client will travel via the VPN to the server. We do a quick "client baseline," then the server config, then the client config, then testing.
These notes presume you are not ethernet bridging: i.e., these instructions are for dev tun not dev tap.
Client baseline
First, let's be sure that you know the real IP#s of both your client and your server, and that your underlying networking is sound. Switch to your client and run the following diagnostics:
1. Your client's ifconfig should not have an entry for tun0. E.g., from a workstation with both wired and wireless ethernet interface, you should see something like
you@client:~$ sudo ifconfig -a Sat Nov 8 17:26:05 EST 2014 eth0 Link encap:Ethernet HWaddr ... ... lo Link encap:Local Loopback ... wlan0 Link encap:Ethernet HWaddr ... ...
2. From your ifconfig, note the IP# (or inet addr) of the ethernet interface you are using. This is your client's IP#.
3. ping your server from your client using the server's IP#. If this fails, you probably don't actually know its IP#, and you must know it, so stop now and learn it.
4. ping your server from your client using IP#=10.8.0.1. This should fail, since you have not yet setup your VPN.
5. Check that DNS works from your client. Use www.whatismyip.com (or the IP-echo website you prefer), since you will access this website later. You should see something like
you@client:~$ nslookup www.whatismyip.com ... Non-authoritative answer: Name: www.whatismyip.com Address: 141.101.120.14 Name: www.whatismyip.com Address: 141.101.120.15
6. ping www.whatismyip.com (or the IP-echo website you prefer): this will later be used to establish validity of routing beyond your VPN. You should see something like
you@client:~$ ping -c 4 www.whatismyip.com PING www.whatismyip.com (141.101.120.15) 56(84) bytes of data. 64 bytes from 141.101.120.15: icmp_seq=1 ttl=57 time=94.7 ms 64 bytes from 141.101.120.15: icmp_seq=2 ttl=57 time=157 ms 64 bytes from 141.101.120.15: icmp_seq=3 ttl=57 time=88.3 ms 64 bytes from 141.101.120.15: icmp_seq=4 ttl=57 time=88.8 ms --- www.whatismyip.com ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 15621ms rtt min/avg/max/mdev = 88.370/107.325/157.369/29.002 ms
7. Trace the route to www.whatismyip.com (or the IP-echo website you prefer). You should see something like
you@client:~$ traceroute www.whatismyip.com traceroute to www.whatismyip.com (141.101.120.15), 30 hops max, 60 byte packets 1 192.168.15.1 (192.168.15.1) 0.850 ms 0.838 ms 1.378 ms ... 10 141.101.120.15 (141.101.120.15) 96.397 ms 96.392 ms 95.841 ms
The first IP# is your IP gateway (e.g., the modem/router on your client's physical LAN). The last IP# must be that of your target IP-echo website (as noted by nslookup and ping). The number of lines of traceroute output (aka the number of "hops") is probably not relevant.
8. Open a web browser and access http://www.whatismyip.com (or the IP-echo website you prefer). It should return the client IP# as listed in your ifconfig.
Note that, in section=Client configuration (below), you'll be installing some network-related packages. If you're cautious (and that's a good thing!), repeat these baseline diagnostics after installing those packages, to be extra-sure your client is still networking properly.
Server configuration
Switch to your server. First, install OpenVPN on it, with (e.g.)
aptitude install openvpn
Next, create the keys needed by both server and client.
mkdir /etc/openvpn/easy-rsa cp -ai /usr/share/doc/openvpn/examples/easy-rsa/2.0/ /etc/openvpn/easy-rsa cd /etc/openvpn/easy-rsa/2.0 vi vars
In the vars file, edit the KEY_* entries at the bottom of the file, such as KEY_COUNTRY, KEY_ORG, KEY_EMAIL, etc. Next, source the vars file and then clean the directory.
. ./vars ./clean-all
Next build the certificates. For the 'Common Name' field, you can use anything to your liking. I used 'OpenVPN-CA-rustybear'. For the Certificate Authority (build-ca), use 'server'. For the client keys (build-key), use 'client1' or 'client2' or whatever you like, I used 'client_kevin'.
./build-ca ./build-key-server server ./build-key client_kevin ./build-key client2
Generate the Diffie Hellman parameters for the server.
./build-dh
When this is done, you will have a number of files in the keys/ subdirectory. Copy the keys listed below to the server's /etc/openvpn directory.
cd /etc/openvpn cp easy-rsa/2.0/keys/ca.crt . cp easy-rsa/2.0/keys/server.key . cp easy-rsa/2.0/keys/server.crt . cp easy-rsa/2.0/keys/dh1024.pem .
And copy the keys needed for the client either directly to the client via scp or to a USB disk. The files needed by the client are ca.crt, client_kevin.crt, and client_kevin.key (or whatever you named the files when you generated them with the build-key script).
Switching to the client machine for just a moment, copy the client keys to the /etc/openvpn directory.
Next, back on the server, create the openvpn server config file. Start with the example in the docs.
cd /etc/openvpn cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf .
Gunzip it if necessary then edit it. Here's a simple but workable example:
Note the entries for push "dhcp-option DNS. The DNS servers you list must be accessible from your server and client. They will be pushed out to the client and can cause networking problems on the client if incorrect.
Now start the openvpn server with either of the following commands.
/etc/init.d/openvpn start
or
openvpn /etc/openvpn/server.conf
You will need to enable IP forwarding.
echo 1 > /proc/sys/net/ipv4/ip_forward
You can make this a permanent change by uncommenting the line:
net.ipv4.ip_forward = 1
in the file /etc/sysctl.conf.
You'll also have to allow NAT forwarding through your firewall. This will most likely be accomplished with something like the following rule in iptables:
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
This assumes you have set up your openvpn server with the IP 10.8.0.0 in the server.conf file as described above.
Client configuration
Switch to your client. You'll need to install two packages on it:
openvpn for OpenVPN (you guessed !-)
resolvconf. This is more problematic (resolvconf can potentially conflict with other DNS-writing programs on your client) but we need it to make DNS work correctly on the client. If you're cautious (and that's a good thing!), read README.Debian in the OpenVPN docs and the README for resolvconf.
Install the packages with (e.g.)
aptitude install openvpn resolvconf
In the server config above, you created keys for the client, which you should have already copied from the server to the client's directory at /etc/openvpn. This includes the ca.crt file.
Next you need a client.conf file, a sample of which is found in the docs.
cd /etc/openvpn cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf . vi client.conf
or feel free to use this simple but workable example ... after you substitute
your server's IP number for your.server.IP.number
your client name for client_kevin (unless you used that name when generating certificates and keys)
Some obvious things: You'll want to use your server's IP for the remote entry. List your client keys and the server CA. Uncomment the user and group entries.
Not so obvious are the last two lines. They call the script update-resolv-conf, which should be in your /etc/openvpn directory. The script will use resolvconf (which you installed above) and the DNS settings of your openvpn server, to rewrite your client's resolv.conf file.
To start openvpn on the client, issue the command:
openvpn --script-security 2 --config /etc/openvpn/client.conf &
You'll need the --script-security setting to get the update-resolv-conf script to execute. You can place this setting in the client.conf file if you like.
On both the server and the client, you can control whether your vpn is automatically started on machine startup by editing the AUTOSTART lines in the file /etc/default/openvpn.
Testing
Check your installation by
1. Start your server (as instructed above) if you have not already done so.
2. Start your client (as instructed above) if you have not already done so.
3. Run ifconfig on your client. You should see a new entry for tun0: i.e., in addition to the ifconfig entries you noted in your client baseline (above), you should now also see an entry like the following (possibly with slightly different inet addr)
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.8.0.6 P-t-P:10.8.0.5 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:14 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 B) TX bytes:896 (896.0 B)
4. ping your server from your client using the server's real IP#: i.e., the one you listed in your client.conf in the line beginning with remote. This is just a sanity test: if this does not work, something is very wrong with your networking.
5. ping your server from your client using IP#=10.8.0.1. You should see something like
you@client:~$ date ; ping -c 4 10.8.0.1 Sat Nov 8 17:49:40 EST 2014 PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data. 64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=100 ms 64 bytes from 10.8.0.1: icmp_seq=2 ttl=64 time=92.0 ms 64 bytes from 10.8.0.1: icmp_seq=3 ttl=64 time=80.7 ms 64 bytes from 10.8.0.1: icmp_seq=4 ttl=64 time=83.5 ms --- 10.8.0.1 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 80.705/89.308/100.980/7.930 ms
6. Check that DNS works from your client, using www.whatismyip.com (or the IP-echo website you prefer). You should see something like
you@client:~$ date ; nslookup www.whatismyip.com Sat Nov 8 17:51:21 EST 2014 ... Non-authoritative answer: Name: www.whatismyip.com Address: 141.101.120.14 Name: www.whatismyip.com Address: 141.101.120.15
7. ping www.whatismyip.com (or the IP-echo website you prefer) to establish validity of routing beyond your VPN. You should see output similar to those you got when you did this for your client baseline, though the response times will probably be longer. If instead you see something like
you@client:~$ ping -c 4 www.whatismyip.com PING www.whatismyip.com (141.101.120.14) 56(84) bytes of data. --- www.whatismyip.com ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3023ms
you have a routing problem at your server, which you need to fix.
7. Trace the new route to www.whatismyip.com, or the IP-echo website you prefer, or some other IP address beyond your VPN. You should see output not too different to those you got when you did this for your client baseline, though you will probably see more lines/hops. If instead you see something like
you@client:~$ traceroute www.whatismyip.com traceroute to www.whatismyip.com (141.101.120.15), 30 hops max, 60 byte packets 1 10.8.0.1 (10.8.0.1) 99.579 ms 99.584 ms 104.230 ms 2 * * * ... 30 * * *
you have a routing problem at your server, which you need to fix.
8. Open a web browser and access http://www.whatismyip.com (or the IP-echo website you prefer). It should return the IP of the server (i.e., the one you listed in your client.conf in the line beginning with remote), not the client. The browser should not hang while either looking up or connecting.
'개발 플랫폼 및 언어' 카테고리의 다른 글
How to install latest Apache HTTPD on CentOS (0) | 2018.11.20 |
---|---|
Postgres PSQL USER 관리하기 (0) | 2018.11.17 |
OS X DD 명령 - Progress 표시 (0) | 2018.11.16 |
JDK Command Line 에서 다운로드 (0) | 2018.11.09 |
httpd: bad user name daemon (0) | 2018.11.09 |