Установка OpenVPN на Ubuntu 18.04 LTS. Часть 4 из 12
11.07.2020
Теги: Linux • SSL • Ubuntu • VPN • Клиент • Ключ • Конфигурация • Маршрутизация • Настройка • Сервер • Установка
Мы пока решили две самые простые задачи: защищенный канал связи между клиентом и сервером + маршрутизации всего трафика клиентов через сервер. Но часто бывает необходимо предоставить клиентам доступ к ресурсам локальной сети. У нас есть локальная сеть 192.168.150.0/24 и шлюз, который обеспечивает выход в интернет для компьютеров этой сети. На шлюз мы установим VPN-сервер и предоставим VPN-клиентам доступ внутрь сети.
Настройка сети для gateway
Сначала нужно посмотреть, как называются сетевые интерфейсы в системе:
$ ls /sys/class/net enp0s3 enp0s8 lo
Теперь редактируем файл /etc/netplan/01-netcfg.yaml:
$ sudo nano /etc/netplan/01-netcfg.yaml
network: version: 2 renderer: networkd ethernets: enp0s3: dhcp4: no addresses: [123.123.123.123/24] gateway4: 123.123.123.1 nameservers: addresses: [8.8.8.8, 8.8.4.4] enp0s8: dhcp4: no addresses: [192.168.150.1/24] nameservers: addresses: [8.8.8.8, 8.8.4.4]
Применяем настройки и смотрим сетевые интерфейсы:
$ sudo netplan apply # применить настройки из YAML-файла к работающей системе $ sudo netplan generate # сохранить текущие настройки в файл конфигурации networkd
$ ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 08:00:27:71:2e:a5 brd ff:ff:ff:ff:ff:ff inet 123.123.123.123/24 brd 123.123.123.255 scope global noprefixroute enp0s3 valid_lft forever preferred_lft forever inet6 fe80::1612:c37b:b6f9:64ff/64 scope link noprefixroute valid_lft forever preferred_lft forever 3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 08:00:27:49:10:2a brd ff:ff:ff:ff:ff:ff inet 192.168.150.1/24 brd 192.168.150.255 scope global enp0s8 valid_lft forever preferred_lft forever
Настройка сети для pc1 и pc2
Сначала для компьютера pc1. Смотрим, как называются сетевые интерфейсы в системе:
$ ls /sys/class/net enp0s3 lo
Открываем на редактирование файл /etc/netplan/01-network-manager-all.yaml:
$ sudo nano /etc/netplan/01-network-manager-all.yaml
# Let NetworkManager manage all devices on this system network: version: 2 renderer: NetworkManager ethernets: enp0s3: dhcp4: no addresses: [192.168.150.2/24] gateway4: 192.168.150.1 nameservers: addresses: [8.8.8.8, 8.8.4.4]
Применяем настройки и смотрим сетевые интерфейсы:
$ sudo netplan apply # применить настройки из YAML-файла к работающей системе $ sudo netplan generate # сохранить текущие настройки в файл конфигурации NetworkManager
$ ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 08:00:27:83:c0:ad brd ff:ff:ff:ff:ff:ff inet 192.168.150.2/24 brd 192.168.150.255 scope global noprefixroute enp0s3 valid_lft forever preferred_lft forever inet6 fe80::a00:27ff:fe83:c0ad/64 scope link valid_lft forever preferred_lft forever
Для компьютера pc2 все будет аналогично, так что не буду описывать подробно:
$ ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 08:00:27:69:17:a1 brd ff:ff:ff:ff:ff:ff inet 192.168.150.3/24 brd 192.168.150.255 scope global noprefixroute enp0s3 valid_lft forever preferred_lft forever inet6 fe80::a00:27ff:fe69:17a1/64 scope link valid_lft forever preferred_lft forever
Настройка интернет-шлюза
Сервер gateway должен обеспечивать выход в интернет для всех компьютеров из локальной сети 192.168.150.0/24. По умолчанию транзитный трафик отключен, так что редактируем файл /etc/sysctl.conf:
$ sudo nano /etc/sysctl.conf
# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1
Чтобы внесенные изменения вступили в силу, выполняем команду:
$ sudo sysctl -p net.ipv4.ip_forward = 1
После этого настраиваем netfilter с помощью утилиты iptables:
$ sudo iptables -P FORWARD DROP
$ sudo iptables -A FORWARD -i enp0s8 -o enp0s3 -s 192.168.150.0/24 -j ACCEPT # enp0s8 -> enp0s3 $ sudo iptables -A FORWARD -i enp0s3 -o enp0s8 -d 192.168.150.0/24 -j ACCEPT # enp0s3 -> enp0s8
И смотрим, что получилось:
$ sudo iptables -L -v --line-numbers Chain INPUT (policy ACCEPT 4 packets, 366 bytes) num pkts bytes target prot opt in out source destination Chain FORWARD (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 34 2130 ACCEPT all -- enp0s8 enp0s3 192.168.150.0/24 anywhere 2 0 0 ACCEPT all -- enp0s3 enp0s8 anywhere 192.168.150.0/24 Chain OUTPUT (policy ACCEPT 1 packets, 32 bytes) num pkts bytes target prot opt in out source destination
Мы разрешили ходить транзитным пакетам для нашего диапазона ip адресов, а всё остальное запретили. Теперь настроим SNAT (подмена адреса источника), что позволит всем компьютерам сети выходить в интернет, используя единственный ip-адрес 123.123.123.123.
$ sudo iptables -t nat -A POSTROUTING -o enp0s3 -j MASQUERADE
Созданные нами правила пропадут при перезагрузке gateway. Так что их нужно сохранить и восстанавливать при перезагрузке. В этом нам поможет пакет iptables-persistent:
$ sudo apt install iptables-persistent
При установке пакета будет предложено сохранить текущие правила iptables:
- в файл
/etc/iptables/rules.v4для протокола IPv4 - в файл
/etc/iptables/rules.v6для протокола IPv6
Теперь проверяем наличие интернета на компьютерах pc1 и pc2:
$ ping -c3 ya.ru PING ya.ru (87.250.250.242) 56(84) bytes of data. 64 bytes from ya.ru (87.250.250.242): icmp_seq=1 ttl=49 time=10.7 ms 64 bytes from ya.ru (87.250.250.242): icmp_seq=2 ttl=49 time=8.95 ms 64 bytes from ya.ru (87.250.250.242): icmp_seq=3 ttl=49 time=9.32 ms --- ya.ru ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 8.956/9.691/10.794/0.801 ms
Настройка OpenVPN-сервера
Маршрутизатор настроили, компьютеры сети могут выходит в интернет. Теперь приступим к установке и настройке OpenVPN-сервера.
$ sudo apt install openvpn
1. Создание центра сертификации
Центр сертификации будет на сервере gateway, хотя это и неправильно:
$ cd ~ $ mkdir easy-rsa $ wget https://github.com/OpenVPN/easy-rsa/releases/download/v3.0.7/EasyRSA-3.0.7.tgz $ tar xvf EasyRSA-3.0.7.tgz $ cp -r EasyRSA-3.0.7/* easy-rsa/
Создаем копию файла vars.example — это пример конфигурации. Ничего в нем изменять не будем, в этом случае EASYRSA_DN имеет значение по умолчанию cn_only, требующий ввода только универсального имени (подробности здесь).
$ cd ~/easy-rsa/ $ cp vars.example vars
Запускаем скрипт easyrsa с опцией init-pki для инициализации инфраструктуры:
$ ./easyrsa init-pki init-pki complete; you may now create a CA or requests. Your newly created PKI dir is: /home/evgeniy/easy-rsa/pki
Создаем корневой сертификат удостоверяющего центра:
$ ./easyrsa build-ca nopass Using SSL: openssl OpenSSL 1.1.1 11 Sep 2018 Generating RSA private key, 2048 bit long modulus (2 primes) ................+++++ ....................+++++ e is 65537 (0x010001) You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Common Name (eg: your user, host, or server name) [Easy-RSA CA]: Some Company Auth Center CA creation complete and you may now import and sign cert requests. Your new CA certificate file for publishing is at: /home/evgeniy/easy-rsa/pki/ca.crt
Корневой сертификат — это файл pki/ca.crt, а приватный ключ — это файл pki/private/ca.key.
2. Создание ключей сервера
Создаем закрытый ключ и запрос на подпись сертификата для VPN-сервера:
$ ./easyrsa gen-req vpn-server nopass Using SSL: openssl OpenSSL 1.1.1 11 Sep 2018 Generating a RSA private key ...................+++++ .............+++++ writing new private key to '/home/evgeniy/easy-rsa/pki/easy-rsa-2382.nxMgUT/tmp.AWB9S9' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Common Name (eg: your user, host, or server name) [vpn-server]: Some Company VPN server Keypair and certificate request completed. Your files are: req: /home/evgeniy/easy-rsa/pki/reqs/vpn-server.req key: /home/evgeniy/easy-rsa/pki/private/vpn-server.key
Подписываем сертификат VPN-сервера:
$ ./easyrsa sign-req server vpn-server Using SSL: openssl OpenSSL 1.1.1 11 Sep 2018 You are about to sign the following certificate. Please check over the details shown below for accuracy. Note that this request has not been cryptographically verified. Please be sure it came from a trusted source or that you have verified the request checksum with the sender. Request subject, to be signed as a server certificate for 825 days: subject= commonName = Some Company VPN server Type the word 'yes' to continue, or any other input to abort. Confirm request details: yes Using configuration from /home/evgeniy/easy-rsa/pki/easy-rsa-2403.o3rvmT/tmp.YuzdxZ Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows commonName :ASN.1 12:'Some Company VPN server' Certificate is to be certified until Oct 14 10:01:28 2022 GMT (825 days) Write out database with 1 new entries Data Base Updated Certificate created at: /home/evgeniy/easy-rsa/pki/issued/vpn-server.crt
Теперь создаем ключ Диффи-Хеллмана:
$ ./easyrsa gen-dh .......... DH parameters of size 2048 created at /home/evgeniy/easy-rsa/pki/dh.pem
Это может занять несколько минут. Наконец, создаем ключ TLS:
$ openvpn --genkey --secret ta.key
Копируем ключи и сертификаты в директорию /etc/openvpn/keys/:
$ sudo mkdir /etc/openvpn/keys/ # создаем директорию для ключей и сертификатов $ sudo cp /home/evgeniy/easy-rsa/pki/ca.crt /etc/openvpn/keys/ # корневой сертификат $ sudo cp /home/evgeniy/easy-rsa/pki/private/vpn-server.key /etc/openvpn/keys/ # закрытый ключ сервера $ sudo cp /home/evgeniy/easy-rsa/pki/issued/vpn-server.crt /etc/openvpn/keys/ # открытый ключ сервера $ sudo cp /home/evgeniy/easy-rsa/pki/dh.pem /etc/openvpn/keys/ # ключ Диффи-Хеллмана $ sudo cp /home/evgeniy/easy-rsa/ta.key /etc/openvpn/keys/ # ключ Transport Layer Security
3. Файл конфигурации сервера
Как его создавать, мы уже знаем, так что без подробностей:
$ sudo nano /etc/openvpn/server/config.conf
# порт, на котором работает сервер port 1194 # работа по протоколу UDP (для работы по TCP нужно указать tcp-server) proto udp4 # сетевой интерфейс TUN (или TAP) dev tun # корневой сертификат ca /etc/openvpn/keys/ca.crt # сертификат сервера cert /etc/openvpn/keys/vpn-server.crt # приватный ключ сервера key /etc/openvpn/keys/vpn-server.key # добавляет дополнительную подпись HMAC ко всем пакетам handshake для # проверки целостности; любой пакет, не имеющий правильной HMAC-подписи, # будет отброшен без дальнейшей обработки; это для доп.безопасности tls-auth /etc/openvpn/keys/ta.key # для сервера направление ключа TLS — 0 (для клиента — 1) key-direction 0 # ключ Диффи-Хеллмана dh /etc/openvpn/keys/dh.pem # использовать алгоритм AES-256-GCM шифрования пакетов канала данных; # на данный момент это самый безопасный и быстрый алгоритм шифрования cipher AES-256-GCM # алгоритм хеширования — для проверки целостности передаваемых пакетов # канала данных и (если включено tls-auth) пакетов канала управления auth SHA256 # три варианта: net30, p2p, subnet topology subnet # локальная сеть сервер-клиенты server 10.8.0.0 255.255.255.0 # максимальное количество одновременно подключенных клиентов max-clients 10 # новый механизм компрессии; директива будет автоматически отправлена на клиент compress lz4-v2 push "compress lz4-v2" # для старых версий клиентов (ниже 2.4) отключаем две директивы выше и включаем # директиву ниже; также потребуется добавить в конфигурационные файлы клиентов #comp-lzo # пользователь и группа с минимальными правами — для большей безопасности user nobody group nogroup # каждые 10 секунд отправлять ping-запрос на удаленный узел; если нет ответа # 60*2=120 секунд — перезапускать туннель keepalive 10 60 # не перечитывать файлы ключей при восстановлении после разрыва соединения persist-key # оставлять без изменения устройства tun или tap при перезапуске службы persist-tun # файл статуса, содержит текущие соединения; перезаписывается каждую минуту status /var/log/openvpn/openvpn-status.log # по умолчанию логи идут в syslog; использование одной из директив ниже # предписывает вести отдельный лог; первая — перезаписывать файл лога, # вторая — дополнять файл лога; можно использовать только одну директиву #log /var/log/openvpn/openvpn.log #log-append /var/log/openvpn/openvpn.log # уровень детализации лога от 0 до 11; если 0 — тогда только фатальные ошибки; # при настройке установить значение 3 или 4, при эксплуатации — 0 или 1 verb 3 # предупреждать клиентов, что сервер перезапускается, чтобы клиенты могли # автоматически переподключиться (только при работе по протоколу UDP) explicit-exit-notify 1
Все готово, можно запускать VPN-сервер:
$ sudo systemctl start openvpn-server@config.service
Добавим запуск сервера в автозагрузку:
$ sudo systemctl enable openvpn-server@config.service
Настройка OpenVPN-клиента
Сервер готов к работе, теперь создаем в центре сертификации ключ и сертификат для клиента. Дальше с компьютера клиента копируем ключи и сертификаты и создаем файл конфигурации. Сначала на клиенте устанавливаем пакет openvpn:
$ sudo apt install openvpn
Создаем на сервере закрытый ключ и запрос на подпись сертификата для VPN-клиента:
$ ./easyrsa gen-req sergey-ivanov nopass Using SSL: openssl OpenSSL 1.1.1 11 Sep 2018 Generating a RSA private key ...........................+++++ ......................+++++ writing new private key to '/home/evgeniy/easy-rsa/pki/easy-rsa-17071.anoTXK/tmp.LJvnZP' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Common Name (eg: your user, host, or server name) [sergey-ivanov]: Enter Keypair and certificate request completed. Your files are: req: /home/evgeniy/easy-rsa/pki/reqs/sergey-ivanov.req key: /home/evgeniy/easy-rsa/pki/private/sergey-ivanov.key
sergey-ivanov. Для клиента лучше использовать именно такие имена, потому что может потребоваться использовать директиву файла конфигурации client-config-dir. В этом случае Common Name будет использовано в качестве имени файла — а на имена файлов налагаются некоторые ограничения.
Подписываем сертификат VPN-клиента:
$ ./easyrsa sign-req client sergey-ivanov Using SSL: openssl OpenSSL 1.1.1 11 Sep 2018 You are about to sign the following certificate. Please check over the details shown below for accuracy. Note that this request has not been cryptographically verified. Please be sure it came from a trusted source or that you have verified the request checksum with the sender. Request subject, to be signed as a client certificate for 825 days: subject= commonName = sergey-ivanov Type the word 'yes' to continue, or any other input to abort. Confirm request details: yes Using configuration from /home/evgeniy/easy-rsa/pki/easy-rsa-17449.r7HtCo/tmp.xg8Et3 Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows commonName :ASN.1 12:'sergey-ivanov' Certificate is to be certified until Oct 14 12:51:54 2022 GMT (825 days) Write out database with 1 new entries Data Base Updated Certificate created at: /home/evgeniy/easy-rsa/pki/issued/sergey-ivanov.crt
Переходим на компьютер клиента и копируем с сервера следующие файлы:
$ sudo mkdir /etc/openvpn/keys/ # создаем директорию для ключей и сертификатов $ sudo scp evgeniy@123.123.123.123:/home/evgeniy/easy-rsa/pki/ca.crt /etc/openvpn/keys/ $ sudo scp evgeniy@123.123.123.123:/home/evgeniy/easy-rsa/pki/private/sergey-ivanov.key /etc/openvpn/keys/ $ sudo scp evgeniy@123.123.123.123:/home/evgeniy/easy-rsa/pki/issued/sergey-ivanov.crt /etc/openvpn/keys/ $ sudo scp evgeniy@123.123.123.123:/home/evgeniy/easy-rsa/ta.key /etc/openvpn/keys/
Создаем файл конфигурации клиента:
$ sudo nano /etc/openvpn/client/config.conf
# это клиент, а не сервер client # работа по протоколу UDP (для работы по TCP нужно указать tcp-client) proto udp # сетевой интерфейс TUN (или TAP) dev tun # ip-адрес и порт сервера remote 123.123.123.123 1194 # если не удалось получить ip-адрес сервера от DNS, то через указанное # количество секунд попытаться снова; infinite — повторять бесконечно resolv-retry infinite # использовать динамический порт для подключения к серверу (клиенту не # требуется привязка к определенному порту); актуально только для UDP nobind # корневой сертификат ca /etc/openvpn/keys/ca.crt # сертификат клиента cert /etc/openvpn/keys/sergey-ivanov.crt # приватный ключ клиента key /etc/openvpn/keys/sergey-ivanov.key # для защиты от атаки «человек посередине», когда авторизованный клиент # пытается подключиться к другому клиенту, выдавая себя за сервер; при # указании этой директивы проверяется, что сертификат именно серверный remote-cert-tls server # добавляет дополнительную подпись HMAC ко всем пакетам handshake для # проверки целостности; любой пакет, не имеющий правильной HMAC-подписи, # будет отброшен без дальнейшей обработки; это для доп.безопасности tls-auth /etc/openvpn/keys/ta.key # для клиента направление ключа TLS — 1 (для сервера — 0) key-direction 1 # использовать алгоритм AES-256-GCM шифрования пакетов канала данных; # на данный момент это самый безопасный и быстрый алгоритм шифрования cipher AES-256-GCM # алгоритм хеширования — для проверки целостности передаваемых пакетов # канала данных и (если включено tls-auth) пакетов канала управления auth SHA256 # для старых версий клиентов (ниже 2.4) использовать простое lzo-сжатие; # сервер использует новый механизм компрессии — и сам известит клиентов #comp-lzo # пользователь и группа с минимальными правами — для большей безопасности user nobody group nogroup # уровень детализации лога от 0 до 11; если 0 — тогда только фатальные ошибки; # при настройке установить значение 3 или 4, при эксплуатации — 0 или 1 verb 3
Все готово, можно запускать VPN-клиент:
$ sudo systemctl start openvpn-client@config.service
Добавим запуск клиента в автозагрузку:
$ sudo systemctl enable openvpn-client@config.service
Доступ к ресурсам сети
Чтобы предоставить VPN-клиенту доступ к ресурсам сети, изменим правила на маршрутизаторе gateway. Сначала удалим ранее созданные правила, а потом добавим новые.
$ sudo iptables -D FORWARD 2 $ sudo iptables -D FORWARD 1
$ sudo iptables -A FORWARD -i enp0s8 -o enp0s3 -s 192.168.150.0/24 ! -d 10.8.0.0/24 -j ACCEPT # enp0s8 -> enp0s3 $ sudo iptables -A FORWARD -i enp0s3 -o enp0s8 -d 192.168.150.0/24 -j ACCEPT # enp0s3 -> enp0s8 $ sudo iptables -A FORWARD -i tun0 -o enp0s8 -s 10.8.0.0/24 -d 192.168.150.0/24 -j ACCEPT # tun0 -> enp0s8 $ sudo iptables -A FORWARD -i enp0s8 -o tun0 -s 192.168.150.0/24 -d 10.8.0.0/24 -j ACCEPT # enp0s8 -> tun0
Смотрим, что получилось в итоге:
$ sudo iptables -L -v --line-numbers Chain INPUT (policy ACCEPT 18 packets, 1098 bytes) num pkts bytes target prot opt in out source destination Chain FORWARD (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 6 441 ACCEPT all -- enp0s8 enp0s3 192.168.150.0/24 !10.8.0.0/24 2 6 534 ACCEPT all -- enp0s3 enp0s8 anywhere 192.168.150.0/24 3 0 0 ACCEPT all -- tun0 enp0s8 10.8.0.0/24 192.168.150.0/24 4 0 0 ACCEPT all -- enp0s8 tun0 192.168.150.0/24 10.8.0.0/24 Chain OUTPUT (policy ACCEPT 18 packets, 1071 bytes) num pkts bytes target prot opt in out source destination
И сохраняем эти правила, чтобы они восстанавливались после перезагрузки:
$ sudo iptables-save > /etc/iptables/rules.v4
Теперь пакеты из сети 192.168.150.0/24 можно отправлять в сеть 10.8.0.0/24. Но вот клиент не знает, как отправлять пакеты в сеть 192.168.150.0/24 — для этого на клиенте надо добавить маршрут:
$ sudo ip route add 192.168.150.0/24 via 10.8.0.1 dev tun0
Разумеется, это неудобно — каждому клиенту прописывать маршрут. Но это можно сделать в файле конфигурации сервера:
$ sudo nano /etc/openvpn/server/config.conf
# клиенты будут отправлять все пакеты для сети 192.168.150.0/24 через туннель
push "route 192.168.150.0 255.255.255.0"
$ sudo systemctl restart openvpn-server@config.service
Теперь клиенты все пакеты, предназначенные для сети 192.168.150.0/24 будут отправлять в туннель через интерфейс tun0. Перезагрузим службу на клиенте и проверим маршруты:
$ sudo systemctl restart openvpn-client@config.service
$ route -n Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.0.2.2 0.0.0.0 UG 100 0 0 enp0s3 10.0.2.0 0.0.0.0 255.255.255.0 U 100 0 0 enp0s3 10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0 192.168.150.0 10.8.0.1 255.255.255.0 UG 0 0 0 tun0
Вот теперь все в порядке. С компьютера pc1 пингуем компьютер pc3:
$ ping -c3 10.8.0.2 PING 10.8.0.2 (10.8.0.2) 56(84) bytes of data. 64 bytes from 10.8.0.2: icmp_seq=1 ttl=63 time=7.39 ms 64 bytes from 10.8.0.2: icmp_seq=2 ttl=63 time=8.73 ms 64 bytes from 10.8.0.2: icmp_seq=3 ttl=63 time=9.24 ms --- 10.8.0.2 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 7.396/8.458/9.243/0.779 ms
С компьютера pc3 пингуем компьютер pc1:
$ ping -c3 192.168.150.2 PING 192.168.150.2 (192.168.150.2) 56(84) bytes of data. 64 bytes from 192.168.150.2: icmp_seq=1 ttl=63 time=6.89 ms 64 bytes from 192.168.150.2: icmp_seq=2 ttl=63 time=8.11 ms 64 bytes from 192.168.150.2: icmp_seq=3 ttl=63 time=8.65 ms --- 192.168.150.2 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 6.896/7.891/8.658/0.737 ms
Весь трафик клиента в туннель
В файл конфигурации сервера добавляем директиву:
# использовать VPN-туннель для маршрутизации всего трафика клиентов
push "redirect-gateway def1 bypass-dhcp"
Добавляем новые правила для netfilter:
$ sudo iptables -A FORWARD -i tun0 -o enp0s3 -s 10.8.0.0/24 ! -d 192.168.150.0/24 -j ACCEPT # tun0 -> enp0s3 $ sudo iptables -A FORWARD -i enp0s3 -o tun0 -d 10.8.0.0/24 -j ACCEPT # enp0s3 -> tun0
Сохраняем эти правила, чтобы они восстанавливались после перезагрузки:
$ sudo iptables-save > /etc/iptables/rules.v4
Перезагружаем VPN-сервер с новым файлом конфигурации:
$ sudo systemctl restart openvpn-server@config.service
И смотрим на компьютере pc3 свой ip-адрес:
Post Scriptum
Допустим, что vpn-клиент находится в локальной сети 192.168.100.0/24. Все компьютеры сети выходят в интернет через шлюз. На шлюзе настроен SNAT (подмена адреса источника) и DNAT (подмена адреса назначения). Доступ по ssh извне к серверам внутри сети возможен, поскольку на gateway есть DNAT.
Однако, после запуска службы vpn-клиента — ssh-соединение пропадает. Потому что пакеты, которые приходят на интерфейс enp0s3 — уходят через интерфейс tun0. Мы ведь говорим клиенту, что весь трафик нужно отправлять в туннель. Исправить это можно, если в файл конфигурации клиента добавить директиву.
# маршрут до сервера, с которого будет ssh-соединение
route 222.222.222.222 255.255.255.255 net_gateway
Директива route принимает до четырех аргументов — два обязательных и два дополнительных. Аргумент gateway может быть явно задан как адрес IPv4 или в виде ключевых слов vpn_gateway или net_gateway. Если gateway не указан — подразумевается значение vpn_gateway. Значение net_gateway указывается для сети, которая не должна маршрутизироваться через VPN-туннель.
route network netmask [gateway] [metric]
Если аргумент metric не указан — значение будет получено из директивы route-metric, которая задает метрику по умолчанию для всех маршрутов.
- Установка OpenVPN на Ubuntu 18.04 LTS. Часть 12 из 12
- Установка OpenVPN на Ubuntu 18.04 LTS. Часть 11 из 12
- Установка OpenVPN на Ubuntu 18.04 LTS. Часть 10 из 12
- Установка OpenVPN на Ubuntu 18.04 LTS. Часть 9 из 12
- Установка OpenVPN на Ubuntu 18.04 LTS. Часть 8 из 12
- Установка OpenVPN на Ubuntu 18.04 LTS. Часть 7 из 12
- Установка OpenVPN на Ubuntu 18.04 LTS. Часть 6 из 12
Поиск: Linux • SSL • Ubuntu • VPN • Клиент • Ключ • Конфигурация • Настройка • Сервер • Маршрутизация • Установка • Сертификат • Локальная сеть