img src https habrastorage org webt gu ux _r guux_rw3bw9b6_0h617y yow4

  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
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
<img src="https://habrastorage.org/webt/gu/ux/_r/guux_rw3bw9b6_0h617yyow4xrq.png" />
<b>TL;DR </b> <i>В статье описывается самый простой способ настроить VPN сервер, у которого IP-адрес для подключения VPN-клиентов отличается от IP-адреса с которого клиенты выходят в интернет.</i>
Используете VPN для защиты приватности в интернете и арендуете для этого свой личный сервер? При этом вы единственный клиент, который подключается к этому серверу во всем мире? Так ли сложно найти ваш реальный IP-адрес как вам кажется? С вступлением в силу закона Яровой, это становится намного проще.
<b>Double VPN</b> — популярная тема вокруг которой много спекуляций, часто этим термином называют совершенно разные технологии, но почти всегда это означает разнесенные на уровне IP-адресов точка подключения и выхода в интернет. Мы рассмотрим самый простой способ настройки VPN сервера в таком режиме, который не требует дополнительной настройки на серверной стороне и позволяет получить максимальную скорость и самые низкие задержки.
<cut />
<h2>Модель угроз</h2>
Для того, чтобы от чего-то защищаться, нужно четко понимать модель угроз. Мы не будем рассуждать о новых законах, требующих от провайдеров хранить весь трафик клиентов, но совершенно точно можно сказать, что данные о подключениях, т.н. Netflow, хранить достаточно просто и это давно и успешно делается. То есть факт подключения условного IP-адреса <b><code>1.1.1.1</code></b> к адресу <b><code>2.2.2.2</code></b> в определенное время суток.
Имея доступ к такой информации в масштабах провайдера, города или страны, достаточно просто установить кто именно скрывается за VPN.
Чтобы повысить уровень приватности при использовании VPN, необходимо разделить точку подключения и точку выхода в интернет на IP уровне. На картинке выше наш пользователь находится за забором под пристальным вниманием Ирины Яровой. Все подключения проходящие через забор Ирина строго запоминает. Пользователь, как порядочный гражданин, подключается к адресу <b><code>good.citizen.vpn</code></b>, при этом назад он возвращается уже с адреса <b><code>super.cool.guy.vpn</code></b>. В итоге для Ирины эти два подключения выглядят не связанными между собой.
<h2>Какие бывают двойные VPN</h2>
Под названием "двойной" VPN часто понимают разные вещи, но почти всегда это значит разнесенные территориально или на сетевом уровне узлы подключения и выхода в интернет. Иногда это просто маркетинговый трюк VPN провайдеров который не значит абсолютно ничего, такие услуги могут называться "тройным" и "четверным" VPN.
Мы разберем самые типовые схемы, которые применяют на практике.
<h3>VPN между серверами</h3>
Самый распространенный способ. В таком режиме клиент устанавливает VPN-подключение к только первому серверу. На первом сервере настроен тоннель ко второму и весь трафик от клиента уходит ко второму серверу и так далее. Промежуточных серверов может быть несколько. При этом тоннель между серверами может быть установлен по любому другому протоколу, отличному от протокола, по которому подключен клиент, например IPsec или вообще без шифрования, вроде GRE или IPIP. В таком режиме все промежуточные сервера <b>видно в трассировке маршрута.</b> Проверить как именно подключены между собой промежуточные сервера на стороне клиента нет возможности, поэтому можно только доверять провайдеру.
На всем пути следования трафика, минимальный MTU (Maximum transmission unit) остается равным значению самого первого тоннеля и каждый промежуточный сервер <b>имеет доступ к расшифрованному трафику клиента</b>.
<img src="https://habrastorage.org/webt/-f/k8/0p/-fk80pf8rdttoxn4tbpu7qcnopi.png" />
<h3>VPN через прокси</h3>
Тоже достаточно распространенный способ. Часто используется для маскирования VPN трафика под другой протокол, например в Китае. Такой способ удобнее цепочки из проксей, потому что с помощью VPN легко маршрутизировать весь системный трафик в тоннель. Существуют так же инструменты для перехватывания системных вызовов программ и перенаправления их в прокси: ProxyCap, Proxifier, но они менее стабильны, так как иногда пропускают запросы и они уходят мимо прокси или работают некорректно с некоторыми программами.
В этом режиме прокси сервер не видно в трассировке маршрута.
<img src="https://habrastorage.org/webt/hd/uf/ar/hdufardfsfqecwuasklqamx_fzw.png" />
<h3>VPN внутри VPN</h3>
Самый пароноидальный и медленный способ: все тоннели поднимаются на стороне клиента, при этом каждый внутри другого. Такой способ требует хитрой настройки маршрутов на стороне клиента и запуска всех VPN клиентов в нужном порядке. Это плохо сказывается на задержках и производительности, зато промежуточные сервера не имеют доступа к открытому трафику клиента. Все накладные расходы по инкапсуляции суммируются и максимальный размер пакета (MTU), доступный в итоге клиенту, уменьшается в зависимости от числа тоннелей. Промежуточные сервера не видны в трассировке маршрутов.
<img src="https://habrastorage.org/webt/1f/bc/_d/1fbc_dpm24jxomg-gtt-t4xhouu.png" />
<h2>Настройка VDS</h2>
Самый легкий способ настроить VPN с разделенными точками входа и выхода — подключить несколько IP адресов на один виртуальный сервер. Это способ позволяет получить максимальную скорость и минимальные задержки, так как по сути трафик терминируется на одном сервере. У нас, в <a href="https://Vdsina.ru">Vdsina.ru</a> вы можете это сделать самостоятельно из панели управления. Даже на серверах за 60 рубелй в месяц доступно 2 IP-адреса!
Разберем поэтапно настройку сервера.
<h3>Выбираем сервер</h3>
Заказываем VDS с подходящим тарифом и в нужном датацентре. Учитывая нашу задачу, выберем датацентр подальше, в Нидерландах ;)
<img src="https://habrastorage.org/webt/xf/jv/nt/xfjvntqtokkir7sgkqlzcctlgyq.png" />
<h3>Подключаем дополнительный IP</h3>
Дополнительный IP адрес добавляется на сервер моментально и не требует настройки или перезагрузки сервера.
<img src="https://habrastorage.org/webt/um/er/ot/umerotsqubrxdreezekpld2jzyi.png" />
Для наглядности назначим PTR записи на IP. Это доменное имя, которое будет видно при обратном преобразовании IP-адреса в домен. Это может быть любое значение, в том числе несуществующий домен.
Для примеров будем использовать такие значения:
<source lang="bash">
xxx.xxx.38.220 — super.cool.guy.vpn # внешний адрес (точка выхода)
xxx.xxx.39.154 — good.citizen.vpn # адрес подключения (точка входа)
</source>
<img width="400" src="https://habrastorage.org/webt/mz/oh/uj/mzohujvwi-8-ahlpeuuaduo1rie.png" />
<h2>Проверка двух IP</h2>
Важно помнить, что тот IP адрес, который был установлен на сервере изначально, будет точкой выхода, соответственно новый адрес, будет точкой входа. Подключимся по SSH к серверу и проверим какой адрес используется как внешний.
Для этого проще всего из консоли использовать сервис <a href="http://ifconfig.co">ifconfig.co</a>. При запросе через curl он возвращает IP адрес с которого был сделан запрос.
<source lang="bash">
$ curl ifconfig.co
super.cool.guy.vpn
</source>
По последним цифрам видно, наш внешний адрес действительно соответствует точке выхода. Попробуем проверить корректность работы второго IP в качестве точки входа. Для этого просто используем встроенную в SSH функцию SOCKS-прокси.
Команды выполняются на клиенте:
<source lang="bash">
ssh -D 9999 root@good.citizen.vpn
# в новом окне
curl -x socks5h://127.0.0.1:9999 ifconfig.co
super.cool.guy.vpn
</source>
Первая команда устанавливает SSH-сессию с адресом good.citizen.vpn и одновременно активирует SOCKS-прокси внутри этой сесси, который доступен на локальном порту. Вторая делает обычный HTTP-запрос через этот прокси.
<blockquote>Важно помнить, что в наших примерах для запросов используются выдуманные доменные имена. Они будут отображаться только при PTR-резолве и полноценный запрос к ним сделать не получится. Поэтому на данном этапе обращаться к серверу нужно используя IP-адрес.</blockquote>
<h2>Настройка IKEv2 сервера</h2>
<img align="center" width="500" src="https://habrastorage.org/webt/gg/tv/jr/ggtvjr7iq-tknhzeiv-3cdogqw0.png" />
IPsec IKEv2 — современный протокол VPN поддерживаемый почти всеми операционными системами из коробки. Он используется как протокол по-умолчанию в Windows, macOS и iOS. При этом не требует установки стороннего ПО и работает в большинстве случаев быстрее OpenVPN. На хабре уже были <a href="https://habr.com/ru/post/250859/">статьи по настройке сервера IKEv2</a>, но все они описывают использование самоподписанных сертификатов, и неудобны тем, что требуют установить корневой сертификат на стороне VPN клиента.
Мы же разберем пример настройки сервера с использованием доверенного сертификата от Letsencrypt. Это позволяет не устанавливать клиенту посторонние корневые сертификаты а выдать только логин и пароль.
<h3>Подготовка сервера</h3>
Мы будем использовать сервер на базе Ubuntu 18.04, но инструкция так же подходит для большинства современных дистрибутивов.
Обновляем систему и устанавливаем нужные пакеты
<source>
apt update && apt upgrade
apt install certbot strongswan libstrongswan-extra-plugins
</source>
<h3>Выпуск сертификата</h3>
Для выпуска доверенного сертификата вам потребуется направить реальный домен на IP-адрес точки входа. Мы не будет рассматривать этот пункт подробно, так как он выходит за рамки статьи. В качестве примера мы будем использовать вымышленный домен <b>good.citizen.vpn</b>
Если у вас на сервере уже есть есть веб-сервер, используйте подходящий способ выпуска сертификата через certbot или другой клиент для letsencrypt. В данном примере предполагается что порт HTTP (80) ничем не занят.
<source lang="bash">
certbot certonly --standalone --agree-tos -d good.citizen.vpn
</source>
Ответив на вопросы мастера мы получим подписанный сертификат и ключ
<source lang="bash">
# find /etc/letsencrypt/live/good.citizen.vpn/
/etc/letsencrypt/live/good.citizen.vpn/
/etc/letsencrypt/live/good.citizen.vpn/fullchain.pem
/etc/letsencrypt/live/good.citizen.vpn/README
/etc/letsencrypt/live/good.citizen.vpn/cert.pem
/etc/letsencrypt/live/good.citizen.vpn/privkey.pem
/etc/letsencrypt/live/good.citizen.vpn/chain.pem
</source>
<h3>Отключение AppArmor</h3>
Технология AppArmor изолирует программы друг от друга и запрещает им доступ в папки других программ. Например она непозволяет программе strongswan иметь доступ к файлам сертификатов letsencrypt. Эта хорошая функция и по возможности ее нужно использовать по-назначению. Правильным вариантом будет разрешить storngswan доступ в папку letsencrypt.
Однако настройка профиля AppArmor выходит за рамки данной статьи, поэтому для простоты мы его просто отключим. После отключения необходимо перезагрузиться.
<source lang="bash">
systemctl disable apparmor
reboot
</source>
<h3>Настройка Strongswan</h3>
Для проверки подлинности VPN сервера используются те же X.509 сертификаты, что и для HTTPS.
Установим системные корневые сертификаты. Таким образом корневые сертификаты для strongswan будут обновляться вместе с пакетами.
<source>
rmdir /etc/ipsec.d/cacerts
ln -s /etc/ssl/certs /etc/ipsec.d/cacerts
</source>
Letsencrypt использует промежуточный сертификат, установим и его:
<source>
wget https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem.txt -O /etc/ssl/certs/lets-encrypt-x3-cross-signed.pem
</source>
Установим полученный сертификат и ключ:
<source>
ln -s /etc/letsencrypt/live/good.citizen.vpn/privkey.pem /etc/ipsec.d/private/
ln -s /etc/letsencrypt/live/good.citizen.vpn/cert.pem /etc/ipsec.d/certs/
</source>
Добавим конфиг strongswan <b>/etc/ipsec.conf</b>
<source lang="bash">
config setup
# Разрешить несколько подключений с одного аккаунта
uniqueids=no
# Increase debug level
# charondebug = ike 3, cfg 3
conn %default
# Универсальный набор шифров для большинства платформ
ike=aes256-sha256-modp1024,aes256-sha256-modp2048
# Таймауты "мертвых" подключений
dpdaction=clear
dpddelay=35s
dpdtimeout=2000s
keyexchange=ikev2
auto=add
rekey=no
reauth=no
fragmentation=yes
#compress=yes
# left - local (server) side
leftcert=cert.pem # Имя файла сертификата в папке /etc/ipsec.d/certs/
leftsendcert=always
# Маршруты отправляемые клиенту
leftsubnet=0.0.0.0/0
# right - remote (client) side
eap_identity=%identity
# Диапазон внутренних IP-адресов назначаемых VPN-клиентам
rightsourceip=10.0.1.0/24
rightdns=8.8.8.8,1.1.1.1
# Windows and BlackBerry clients usually goes here
conn ikev2-mschapv2
rightauth=eap-mschapv2
# Apple clients usually goes here
conn ikev2-mschapv2-apple
rightauth=eap-mschapv2
leftid=good.citizen.vpn
</source>
Логины и пароли VPN-клиентов задаются в файле <b>/etc/ipsec.secrets</b>
В этом файле также нужно указать имя приватного ключа, который мы ранее копировали из папки letsencrypt
<source>
# Имя файла приватного ключа в папке /etc/ipsec.d/private/
: RSA privkey.pem
# Пользовати VPN
# имя : EAP "Пароль"
IrinaYarovaya : EAP "PleaseLoveMe123"
Mizooleena : EAP "IwannaLoveToo3332"
</source>
На данном этапе можно перезапустить сервер strongswan и проверить активировался ли новый конфиг:
<source>
$ systemctl restart strongswan
$ ipsec statusall
Virtual IP pools (size/online/offline):
10.0.1.0/24: 254/0/0
Listening IP addresses:
xxx.xxx.38.220
Connections:
ikev2-mschapv2: %any...%any IKEv2, dpddelay=35s
ikev2-mschapv2: local: [CN=good.citizen.vpn] uses public key authentication
ikev2-mschapv2: cert: "CN=good.citizen.vpn"
ikev2-mschapv2: remote: uses EAP_MSCHAPV2 authentication with EAP identity '%any'
ikev2-mschapv2: child: 0.0.0.0/0 === dynamic TUNNEL, dpdaction=clear
ikev2-mschapv2-apple: %any...%any IKEv2, dpddelay=35s
ikev2-mschapv2-apple: local: [good.citizen.vpn] uses public key authentication
ikev2-mschapv2-apple: cert: "CN=good.citizen.vpn"
ikev2-mschapv2-apple: remote: uses EAP_MSCHAPV2 authentication with EAP identity '%any'
ikev2-mschapv2-apple: child: 0.0.0.0/0 === dynamic TUNNEL, dpdaction=clear
</source>
Можно видеть, что конфиг успешно активирован и сертификат подключен. На данном этапе уже можно подключаться к VPN-серверу, но он будет без доступа к интернету. Чтобы выпустить клиентов в интернет, нужно включить форвардинг и настроить NAT.
<h3>Настройка NAT</h3>
Активируем форвардинг пакетов:
<source>
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
sysctl -p
</source>
Включаем NAT заменив <b>ethName0</b> на свое имя интерфейса:
<source>
iptables -t nat -A POSTROUTING -o ethName0 -j MASQUERADE
</source>
<h3>Отладка</h3>
На данном этапе настройка мы должны получить полностью работающий сервер к которому уже могут подключаться клиенты. Перед продолжением лучше убедиться в этом проверив подключение.
В случае проблем с подключением можно смотреть лог в реальном времени:
<source>
journalctl -f -u strongswan
</source>
<h3>Автозапуск при загрузке </h3>
Если все успешно, можно добавить strongswan в автозапуске при загрузке:
<source>
systemctl enable strongswan
</source>
<h3>Автоматический перепуск сертификатов</h3>
По-умолчанию certbot добавляется в системный планировщик и автоматические перевыпускает сертификаты. Но для того, чтобы новый сертификат подхватил strongswan, его нужно уведомить об этом. Отредактируем скрипт certbot:
<source>
systemctl edit certbot
# Добавляем эти строки и сохраняем файл
[Service]
ExecStartPost=/usr/sbin/ipsec reload
ExecStartPost=/usr/sbin/ipsec purgecerts
ExecStartPost=/usr/sbin/ipsec rereadall
</source>
Теперь strongswan будет автоматически перечитывать файлы сертификатов каждый раз после работы certbot, таким образом новый сертификат будет сразу активирован.
<h3>Сохранение правил iptables</h3>
Чтобы сохранить правила iptables после перезагрузки, существует специальный пакет <b>iptables-persistent</b>. Важно помнить, что он сохранит текущий набор правил и добавит его в автозагрузку.
<source>
apt install iptables-persistent
</source>
<h2>Настройка клиентов</h2>
Настройка на стороне клиентов выполняется крайне просто. Достаточно сообщить клиенту адрес сервера, логин и пароль. Для macOS и iOS можно создать профили автоконфигурации, которые достаточно будет активировать в два клика.
<spoiler title="Настройка Windows">
добавь картинку
</spoiler>
<spoiler title="Настройка macOS">
добавь картинку
</spoiler>
<spoiler title="Настройка iOS">
добавь картинку
</spoiler>
<spoiler title="Настройка Linux">
добавь картинку
</spoiler>
<h2>Итог</h2>
Мы показали самый простой вариант настройки сервера с разнесенными точками входа и выхода. Такая конфигурация позволяет получить максимальную скорость VPN, так как не используют дополнительные тоннели между серверами, при том что IP-адреса точек входа и выхода находятся в разных подсетях. Такой подход позволяет экспериментировать и дальше, подключив к серверу более двух IP адресов.
Протокол IKEv2 прекрасно подходит для использования его на десктопных ОС для каждодневной работы, так как максимально нативно интегрирован в систему и при прочих равных, позволяет получить бОльшую скорость через сторонние программы VPN.
<img src="https://habrastorage.org/webt/hi/b3/xj/hib3xjmkyohwf9yqp_irjum5tls.png" />