Я недавно обновил решение VPN в своей инфраструктурной лаборатории, используя Wireguard; Моя архитектура довольно проста: каждый сайт (в данном случае несколько разнесенных сред и несколько облачных провайдеров) использует конечную точку Wireguard, которая затем подключается друг к другу для подключения к моей сервисной сети (а не сети сами хосты) через эти сайты и провайдеров.
Я переключился после использования Wireguard в контексте прямого подключения сетей облачных провайдеров в своей работе и решил сделать то же самое для моей лаборатории, которая охватывает гораздо меньшие масштабы, но гораздо более разнообразный набор машин и сетей, которые сделали Управление большой конфигурацией OpenVPN несколько обременительно и показало, что Wireguard прост, если немного разбирается в разнообразной документации, но достаточно хорошо подходит для автоматизации.
Есть много отличных руководств онлайн для настройка Wireguard между несколькими одноранговыми узлами и для моего варианта использования я обнаружил, что мне нужны дополнительные изменения маршрута, чтобы каждый узел мог получить доступ к локальным сетям, частью которых являлись сопутствующие одноранговые узлы.
Например, предполагая сеть,192.168.2.0/24для самих интерфейсов Wireguard, мой первый сервер в одном месте,192.168.2.1был частью сети в этом месте для машин, которые не были настроены с помощью Wireguard,192.168.122.0/24и еще одна конечная точка, доступная на Wireguard как192.168.2.2,192.168.1.0/24и я хотел, чтобы последний набор машин имел доступ к машинам в локальной сети для первого, но не наоборот.
Стандартный конфиг Wireguard поддерживаетPostUpа такжеDownаргументы для добавления дополнительных изменений маршрутизации и поддержки таких вещей, как настройка NAT сiptables, В этом отношении это единственное нестандартное использование Wireguard в моем проекте.
На моем сервере моя конфигурация выглядела так:
[Interface] Address = 192.168.2.1 PrivateKey = (Hidden) ListenPort = (Whatever) PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o virbr0 -j MASQUERADE PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o virbr0 -j MASQUERADE
с[Peer]блоки для двух других конечных точек, которые могут получить доступ к сетям, подключенным к192.168.2.1«svirbr0интерфейс:
[Peer] PublicKey = TH+DHbSc7ALMapPCsUlCVzWJdQKtFPNfW8Hkel8m2Uw= Endpoint = (Host):(Port) PersistentKeepalive = 25 AllowedIPs = 192.168.2.3/32
[Peer] PublicKey = 6w/+laHf7m0T13tgogRbwKp5na20yygLObLL9AgSHH8= AllowedIPs = 192.168.2.2/32 Endpoint = (Host):(Port)
Довольно просто, но, чтобы подробно остановиться на поведении, которое я надеюсь достичь здесь, только этот сервер192.168.2.1буду иметьPostUpа такжеDownправила:
iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o virbr0 -j MASQUERADE
в этом случае для пересылки трафика черезwg0интерфейс (в моем случае, но в приведенном выше%iбудет автоматически заменять интерфейс, который вы подключаете к сети, когда вы делаете такие вещи, какwq-quick up {interface name}) к целевой сети, которую вы хотели бы предоставить равноправным узлам (а затем включить в конфигурации клиента, о которой я расскажу чуть позже), которая в данном случае представляет собой сеть, подключенную к мостовому интерфейсу,virbr0,
Потому что я хотел, чтобы мои одноранговые сайты могли запускать рабочие нагрузки в и из этой локальной сети, подключенной к192.168.2.1конечная точка, мой клиентский конфиг не требуетPostUpилиPostDown- управляемые изменения маршрута, но необходимо знать о сетях, которым он будет подвержен (через эти изменения брандмауэра в этой конечной точке - изменения, которые мы не будем вносить в эти конечные точки клиента-клиента):
[Interface] PrivateKey = (Hidden) ListenPort = (Port) Address = 192.168.2.2/24 DNS = 1.1.1.1
[Peer] PublicKey = mXvCVKYmYuYL0AO2AvDPsLmOdUGwXDi5d2DekKCt9RY= AllowedIPs = 192.168.2.0/24, 192.168.122.0/24 Endpoint = (Host):(Port) PersistentKeepalive = 25
Итак, в этой конфигурации мы выставляем новую конечную точку на192.168.2.2вглядываться192.168.2.1, И вAllowedIPsмы не только хотим знать о сети Wireguard, которую мы объявляем192.168.2.0/24, но сеть подключена к первому хостуvirbr0интерфейс, в этом случае,192.168.122.0/24,
За этой новой конечной точкой находится сеть,192.168.0.0/24что первый хост не может быть перенаправлен обратно без добавления аналогичного правила в конфигурации интерфейса этой новой конечной точки, но если мы добавим аналогичные правила кiptablesправила, которые мы добавили выше, а затем в конфигурации для первого блока сервера Peer:
[Peer] PublicKey = 6w/+laHf7m0T13tgogRbwKp5na20yygLObLL9AgSHH8= AllowedIPs = 192.168.2.2/32, 192.168.0.0/24 Endpoint = (Host):(Port)
Таким образом, сеть этого удаленного однорангового узла может аналогично пересылать трафик и направлять его соответствующим образом.
По сути, в конце этого вы можете использовать Wireguard в качестве VPN типа «сеть-сеть», и, как и в случае с любым решением VPN, более гибко управлять доступом к сетям, подключенным к каждой конечной точке, и аналогичноpush "${some route}"поведение в OpenVPN, например, использование интерфейса lean формата конфигурации Wireguard для достижения этой цели.
Дополнительные ресурсы