Присвоить виртуальной машине IPv4-адрес

В предыдущем руководстве вы создали первую виртуальную машину на этой платформе и установили на ней гостевую ОС - систему Debian, доступ к которой возможен только изнутри собственного моста хоста Proxmox. Чтобы получить к ней доступ из Интернета, вам сначала нужно заказать маршрутизируемый IPv4-адрес и туннель у Taipan, подключить этот туннель к самому хосту Proxmox, а затем маршрутизировать один из адресов на виртуальную машину.

Заказать маршрутизированный IPv4-адрес и туннель

Настройка осуществляется непосредственно в панели управления, а не в Proxmox: при выборе типа туннеля из списка сервисов открывается собственная страница настройки данного продукта, которая имеет одинаковую структуру для GRE, IPsec и WireGuard.

Пять IP-адресов, выделенных на этом скриншоте, - это именно тот объем, который рекомендуется в данном руководстве: один для виртуальной машины, созданной в предыдущем разделе, и ещё четыре для распределения после появления дополнительных виртуальных машин. Трафик отображается таким же образом - в виде фиксированной плитки, а не индикатора, и зачеркнутая цена рядом с ней соответствует той же скидке по рекламной кампании, которая уже указана на странице с ценами.

На данном снимке экрана показан интерфейс продукта GRE, а его последнее поле - «IPv4-адрес конечной точки клиента» - является специфическим для GRE: это фиксированный исходный адрес, с которого туннель ожидает поступления трафика. В версии этой же страницы для WireGuard это поле полностью отсутствует, поскольку узел WireGuard аутентифицируется с помощью пары ключей, а не по фиксированному источнику, при этом все остальные элементы страницы - «Term», «IPv4 count», «traffic tier» - остаются неизменными.

За этим выбором продукта стоят три типа туннелей, и каждый из них предполагает свой набор компромиссов:

• GRE: самый простой из трёх. В нём полностью отсутствует шифрование, поэтому он работает быстро, но сам по себе не сможет пройти через NAT.
• IPsec: аутентификация и шифрование осуществляются в рамках сеанса, установленного с помощью протокола IKE; это оптимальный выбор в тех случаях, когда сам трафик должен оставаться конфиденциальным при передаче.
• WireGuard: современное шифрование на основе пар ключей с минимальной настройкой, которое продолжает работать даже при смене IP-адреса - самый простой вариант для установления соединения без фиксированного публичного адреса.

Этот хост Proxmox находится за тем адресом, который ему предоставляет его собственное подключение к вышестоящему серверу, поэтому WireGuard - именно тот тип туннеля, который рекомендуется в данном руководстве: статическая пара ключей сохраняется даже при смене адреса, в то время как фиксированная модель «от конечной точки до конечной точки» GRE не позволила бы этого.

Для целей данного руководства достаточно пяти адресов: один для виртуальной машины, созданной в предыдущем разделе, и ещё четыре - для распределения после появления дополнительных виртуальных машин. После оформления заказа вы получите реальный идентификатор заказа, блок из пяти маршрутизируемых IPv4-адресов и конечную точку WireGuard, с которой заканчивается этот туннель:

order:    NL7R2aRA2oVbjHiL3DLfzXBd
endpoint: 195.123.189.9
routed:   195.123.189.17
          195.123.189.18
          195.123.189.19
          195.123.189.20
          195.123.189.21

Закрытие туннеля на хосте Proxmox

Ничто в туннеле WireGuard не является специфическим для Proxmox: это обычный интерфейс Linux, настраиваемый одинаково независимо от того, работает ли он на гипервизоре или на любом другом компьютере под управлением Debian. Это также означает, что каждая из приведённых ниже команд - это именно то, что выполнил бы скрипт автоматической настройки в автоматическом режиме, без какого-либо мастера, стоящего между панелью управления и самим интерфейсом.

Создать пару ключей

WireGuard осуществляет аутентификацию узлов с помощью пар ключей, а не общего секретного ключа, поэтому первый этап происходит полностью в автономном режиме, ещё до того, как к процессу подключается Taipan:

install -d -m 700 /etc/wireguard
sh -c 'umask 077; wg genkey | tee /etc/wireguard/taipan.key | wg pubkey > /etc/wireguard/taipan.pub'
cat /etc/wireguard/taipan.pub

Эта последняя команда выводит на экран открытую половину - единственную часть, которая действительно должна покинуть этот хост:

FIv6nJ3IE0EsMH79Hxj6wV4piku0Guj8nvyaUJ7PEic=

Личный ключ в /etc/wireguard/taipan.key никогда никуда не вставляется, не отправляется и не передается по электронной почте: в Taipan передается только открытый ключ - та же самая асимметрия, благодаря которой пару ключей SSH можно безопасно генерировать ещё до того, как появится учетная запись, с которой они будут использоваться.

Написать конфигурацию WireGuard

Имея адреса маршрутизации и конечную точку из заказа, а также собственный открытый ключ Taipan и порт UDP из панели управления, /etc/wireguard/wg0.conf содержит всё, что необходимо интерфейсу:

[Interface]
PrivateKey = <contents of /etc/wireguard/taipan.key>
Address = 100.64.0.2/32
Table = off
PostUp = ip rule add from 195.123.189.17/32 table 20 priority 100
PostUp = ip rule add from 195.123.189.18/32 table 20 priority 100
PostUp = ip rule add from 195.123.189.19/32 table 20 priority 100
PostUp = ip rule add from 195.123.189.20/32 table 20 priority 100
PostUp = ip rule add from 195.123.189.21/32 table 20 priority 100
PostUp = ip route add default dev %i table 20
PreDown = ip rule del from 195.123.189.17/32 table 20 priority 100
PreDown = ip rule del from 195.123.189.18/32 table 20 priority 100
PreDown = ip rule del from 195.123.189.19/32 table 20 priority 100
PreDown = ip rule del from 195.123.189.20/32 table 20 priority 100
PreDown = ip rule del from 195.123.189.21/32 table 20 priority 100

[Peer]
PublicKey = <Taipan's public key, from the panel>
Endpoint = 195.123.189.9:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

Table = off остановки wg-quick не затрагивая собственный маршрут по умолчанию этого хоста, по которому по-прежнему должен осуществляться трафик через обычный канал связи для всего, что не относится к этим пяти адресам. Этот PostUp Вместо этого строки формируют вторую таблицу маршрутизации, к которой обращается только трафик, исходящий с маршрутизируемого адреса, поэтому ответ от 195.123.189.17 проходит через туннель, в то время как обычный исходящий трафик с хоста остается совершенно незатронутым.

Поскольку самому туннельному интерфейсу не требуется публичный идентификатор, он нужен только маршрутизируемым адресам, передаваемым по нему. 100.64.0.0/10 - это общее адресное пространство, выделенное именно для такого рода ненумерованных соединений «точка-точка», поэтому интерфейс нумеруется без использования одного из пяти адресов, за которые фактически оплачивается данное руководство.

Поднимите туннель

wg-quick считывает этот же файл и выполняет, в указанном порядке, именно то, что перечислено в его собственном выводе: создает интерфейс, загружает ключ, назначает адрес и запускает каждый PostUp строка.

Новый интерфейс показывает, что получено 0 байт, пока сопряженный узел фактически не ответит, что может занять некоторое время после отправки самого первого пакета. Установление соединения подтверждает лишь то, что само зашифрованное соединение между сопряженными узлами работает, поэтому стоит целенаправленно проверить, действительно ли маршрутизируемый адрес доступен от начала до конца, а не просто предполагать это на основании исправного wg show в одиночку.

Направить адрес на виртуальную машину

Теперь туннель выходит на сам хост Proxmox, поэтому для фактического доступа к виртуальной машине требуется ещё один переход: маршрут, который преобразует конкретный адрес в собственный частный адрес этой виртуальной машины на интерфейсе vmbr0 - том же мосте, который был настроен в предыдущем руководстве.

ip route add 195.123.189.17/32 via 10.0.2.100 dev vmbr0

Эта единственная строка и составляет всю разницу между предоставлением маршрутизируемого адреса непосредственно самим шлюзом и его передачей виртуальной машине, расположенной за ним: вместо добавления адреса в lo на хосте, как это делал бы сервис, запущенный непосредственно на шлюзе, хост пересылает его ещё на один прыжок дальше на любой внутренний адрес, который уже закреплён за виртуальной машиной.

На стороне виртуальной машины требуется две соответствующие составляющие: сам публичный адрес и маршрут обратного выхода через хост для всех данных, исходящих от неё.

ip address add 195.123.189.17/32 dev ens18
ip route add default via 10.0.2.100 dev ens18 onlink

Если функция переадресации включена и настройки выполнены с обеих сторон, ip route get 1.1.1.1 from 195.123.189.17 Запуск на хосте Proxmox подтверждает, что для данного адреса действительно выбран именно этот путь: результат показывает dev wg0 это означает, что ответы проходят через туннель, как и предполагалось, а в любом другом случае необходимо ещё раз проверить маршрутизацию, зависящую от источника, которая была настроена на предыдущем этапе, прежде чем приступать к дальнейшему тестированию.

Распределить оставшиеся адреса

Четыре адреса из этого же заказа пока не используются, и схема, по которой был выделен первый адрес, точно повторяется для каждого из них: частный адрес на vmbr0 для соответствующей виртуальной машины, маршрут на стороне хоста, указывающий на него, и сам адрес, добавленный на собственный интерфейс этой виртуальной машины.

195.123.189.17  ->  web01, 10.0.2.100 (this guide)
195.123.189.18  ->  next VM, once created
195.123.189.19  ->  next VM, once created
195.123.189.20  ->  next VM, once created
195.123.189.21  ->  next VM, once created

Все пять по-прежнему используют один и тот же туннель и одну и ту же таблицу маршрутизации, настроенную ранее: таблица 20 уже содержит правило, специфичное для источника, для каждого адреса в блоке, поэтому новой виртуальной машине требуется только своё собственное ip route add <address>/32 via <its internal IP> dev vmbr0 со стороны хоста, а что касается самого туннеля, то ничего больше.