В чем разница между полями Endpoint и AllowedIPs в файле конфигурации Wireguard?

Да, у каждого интерфейса есть свой файл конфигурации. WireGuard не имеет встроенных ролей клиента или сервера - каждый узел считается одноранговым.

Если у вас есть два одноранговых узла, одноранговый узел A и одноранговый узел B, конфигурационный файл для однорангового узла A будет иметь настройки для его собственного локального интерфейса в разделе [Interface] и настройки для его удаленного соединения с одноранговым узлом B в разделе [Peer]. Точно так же файл конфигурации для однорангового узла B будет иметь настройки для его собственного локального интерфейса в разделе [Interface] и настройки для его удаленного соединения с одноранговым узлом A в разделе [Peer]. Таким образом, раздел [Interface] в конфигурации узла A соответствует разделу [Peer] в конфигурации узла B; а раздел [Interface] в конфигурации узла B соответствует разделу [Peer] конфигурации узла A.

Конечная точка ([Peer] раздел конфигурации) - это реальный IP-адрес и порт удаленного однорангового узла за пределами WireGuard VPN. Этот параметр сообщает локальному хосту, как подключиться к удаленному узлу, чтобы настроить туннель WireGuard.

В примере конфигурации, где Endpoint = 54.91.5.139:1952 для удаленного узла, любые пакеты, маршрутизируемые через виртуальный туннель WireGuard для этого однорангового узла, будут фактически зашифрованы, заключены в новый набор пакетов UDP и отправлены через Интернет (или другую реальную сеть, например вашей корпоративной сети) на 54.91.5.139 UDP-порт 1952.

Если вы также не выполняете причудливую маршрутизацию на локальном хосте за пределами WireGuard, если вы попытаетесь отправить пакеты ping с локального хоста на эту конечную точку (например, ping 54.91.5.139), или если вы попытаетесь получить доступ к какой-либо другой службе удаленного однорангового узла из локальный хост через этот адрес конечной точки (например, перейдите к http://54.91.5.139/ в веб-браузере), вы не будете использовать туннель WireGuard - вы будете использовать свое обычное Интернет-соединение (или другую реальную сеть).

AllowedIPs ([Peer] раздел конфигурации) - это набор IP-адресов, которые локальный хост должен направлять удаленному узлу через туннель WireGuard. Этот параметр сообщает локальному хосту, что входит в туннель.

В примере конфигурации, где AllowedIPs = 10.129.130.1/32 для удаленного узла, любые пакеты на локальном хосте, предназначенные для 10.129.130.1, не будут отправляться напрямую через ваше обычное Интернет-соединение (или другую реальную сеть), а вместо этого сначала будут отправлены в виртуальный туннель WireGuard. WireGuard зашифрует их, обернет в новый набор пакетов UDP и отправит через Интернет (или другую реальную сеть) на конечную точку партнера 54.91.5.139. Оттуда одноранговый узел развернет и расшифрует пакеты и попытается переслать их 10.129.130.1.

Поэтому, если вы попытаетесь отправить ping-пакеты с локального хоста на 10.129.130.1 (например, ping 10.129.130.1) или попытаетесь получить доступ к какой-либо другой службе 10.129.130.1 (например, перейдите к http://10.129.130.1 в веб-браузере), вы будете использовать туннель WireGuard.

И наоборот, как вы упомянули, для пакетов, которые прошли через туннель от этого удаленного однорангового узла, если они после развертывания и дешифрования имеют исходный IP-адрес вне блока (-ов), указанного в AllowedIPs (например, исходный IP-адрес 10.1.1.1 вместо 10.129.130.1), локальный хост их сбросит.

Адрес ([Interface] раздел конфигурации) - это виртуальный IP-адрес локального хоста в WireGuard VPN. Этот параметр влияет на маршрутизацию пакетов, входящих и исходящих из туннеля WireGuard, и поэтому он не должен быть реальным IP-адресом, маршрутизируемым за пределами VPN.

В примере конфигурации, где Address = 10.193.130.174/16, виртуальный IP-адрес локального хоста в WireGuard VPN равен 10.193.130.174. Поэтому любые пакеты из локальных сокетов, которые локальный хост отправляет через туннель WireGuard, будут иметь адрес источника 10.193.130.174, и любые пакеты, которые он получает из туннеля с адресом назначения 10.193.130.174, будут перенаправлены обратно в локальный сокет (если вы не делает какую-то причудливую маршрутизацию за пределами WireGuard).

Допустим, реальный сетевой адрес хоста 10.10.10.10. Если с хоста вы запустите ping 10.129.130.1, хост будет генерировать пакеты ping с исходным адресом 10.193.130.174 и адресом назначения 10.129.130.1 и отправлять их через туннель WireGuard. WireGuard зашифрует эти пакеты и обернет их пакетами UDP, где адрес источника - 10.10.10.10, порт источника - 51820 (по умолчанию WireGuard, поскольку в конфигурации не было указано ListenPort), адрес назначения - 54.91.5.139, а порт назначения - 1952. Затем он отправит эти UDP-пакеты в реальную сеть.

Когда удаленный узел, прослушивающий реальный сетевой интерфейс с IP-адресом 54.91.5.139 и UDP-портом 1952, получает эти пакеты, он распаковывает и расшифровывает их. Затем он повторно поставит их в очередь в своем собственном сетевом стеке в их исходной форме в виде пакетов ICMP с адресом источника 10.193.130.174 и адресом назначения 10.129.130.1.

И если исходный хост получит ответ от этого удаленного узла на эхо-запрос, он будет первоначально получен от реального сетевого интерфейса в виде пакетов UDP с исходным адресом 54.91.5.139, исходным портом 1952, адресом назначения 10.10.10.10, и порт назначения 51820. WireGuard развернет и расшифрует эти пакеты обратно в их исходную форму в виде пакетов ICMP с адресом источника 10.129.130.1 и адресом назначения 10.193.130.174 и повторно поставит их в очередь. Поскольку IP-адрес виртуального интерфейса WireGuard - 10.193.130.174 (как настроено с помощью параметра Address), локальный хост будет знать, как направить эти пакеты обратно в локальный сокет.

Обратите внимание, что указание сетевой маски для параметра Address (/16 в нашем примере) влияет на решения о маршрутизации, принимаемые локальным хостом относительно того, какой трафик должен быть отправлен в туннель (и что делать с трафиком, полученным туннелем) таким образом, что может быть избыточным или пересекающимся с параметром AllowedIPs. В нашем примере Address = 10.193.130.174/16, что обычно приводит к тому, что весь трафик, предназначенный для любого адреса в диапазоне 10.193.x.x, направляется на этот интерфейс WireGuard на локальном хосте (не включая собственный адрес интерфейса 10.193.130.174, который будет перенаправлен на интерфейс обратной связи. ).

Однако параметр AllowedIPs для единственного однорангового узла в нашем примере не включает ничего в диапазоне 10.193.x.x. Итак, если бы мы запустили ping 10.193.0.1 на хосте, хост генерировал бы пакеты ping с исходным адресом 10.193.130.174 и адресом назначения 10.193.0.1 и отправлял бы их через туннель WireGuard. Но поскольку этот адрес назначения не соответствует AllowedIPs каким-либо настроенным одноранговым узлам, WireGuard отбрасывает эти пакеты.

Поэтому обычно проще всего опустить сетевую маску в настройке Address (для адресов IPv4 или использовать /32, что дает тот же эффект) и использовать только настройки AllowedIPs на каждом одноранговом узле для управления тем, что на него направляется. Обычно вы указываете сетевую маску только в том случае, если у вас есть несколько разных одноранговых узлов, использующих одну и ту же виртуальную подсеть (или если вы выполняете какую-то причудливую маршрутизацию за пределами WireGuard).

Еще одна вещь, которую нужно знать о Endpoint, заключается в том, что вам нужно установить его только на одной стороне туннеля WireGuard (но вы можете установить его на обеих сторонах, если у обеих сторон есть статический IP-адрес). Если вы установите Endpoint для Peer B в конфигурации Peer A, но опустите его для Peer A в конфигурации Peer B, Peer A сможет инициировать и настроить туннель с Peer B, без того, чтобы Peer B знал конечную точку Peer A. раньше времени.

Это идеально, если одноранговый узел A имеет динамически назначаемый общедоступный IP-адрес; но недостатком является то, что узел B не сможет инициировать туннель - ему придется ждать, пока узел A подключится к нему. Если вам иногда требуется, чтобы одноранговый узел B инициировал соединение с одноранговым узлом A, вы можете смягчить это, включив параметр PersistentKeepalive для узла B в конфигурацию узла A - это направит узел A на проактивное соединение и подключение к узлу B каждые N секунд. (где N - значение, которое вы указали в настройке PersistentKeepalive).

Конечная точка - это URL-адрес, по которому Wireguard может подключаться через облако. Таким образом, он должен содержать общедоступный IP-адрес и номер порта.

Allowed-ips - это список адресов, которые будут перенаправлены одноранговому узлу. Обязательно укажите хотя бы один диапазон адресов, который содержит внутренний IP-адрес (а) соединения WireGuard.

Итак, конечная точка имеет общедоступный IP-адрес, но Allowed-ips - это список адресов (внутренний IP-адрес соединения Wireguard).

Я действительно не так много могу добавить к ответу г-на Людвига. WireGuard довольно прост по дизайну. Тем не менее, вот пример моей текущей настройки, включая правила nftables на стороне сервера, позволяющие всем клиентским узлам пинговать машины в моей локальной сети.

Конфигурация сервера (Ubuntu), хранящаяся в /etc/wireguard/wg0.conf. Адрес локальной LAN 192.168.2.0/24, и этот конкретный адрес сервера 192.168.2.1 на интерфейсе LAN и 192.168.3.1 на интерфейсе VPN (WireGuard) (wg0). Адрес, присвоенный WireGuard VPN: 192.168.3.0/24:

[Interface]
Address = 192.168.3.1/24
#SaveConfig = true
ListenPort = 51820
PrivateKey = +N3K<redacted>

# Peer configurations
[Peer]
PublicKey = h/tr<redacted>
AllowedIPs = 192.168.3.0/24

Конфигурация клиента (или однорангового узла) (Windows), хранящаяся в официальном клиенте WireGuard для Windows (не знаю, где сейчас находится файл или реестр). Локальный адрес VPN: 192.168.3.2:

[Interface]
PrivateKey = gIIB<redacted>
Address = 192.168.3.2/24

[Peer]
PublicKey = od4j<redacted>
AllowedIPs = 192.168.3.0/24, 192.168.2.0/24
Endpoint = <MyFreeDdnsDomainOn>.duckdns.org:51820
PersistentKeepalive = 25

Правила nftables на стороне Ubuntu (сервера), хранящиеся в /etc/nftables.conf, включая мои правила брандмауэра:

define wan = "eth0"
define lan = "br0"
define lo = "lo"
define vpn = "wg0"

table ip nat {
        chain PREROUTING {
                # priority dstnat = -100.
                type nat hook prerouting priority dstnat; policy accept;
        }

        chain INPUT {
                # priority srcnat = 100.
                type nat hook input priority 100; policy accept;
        }

        chain OUTPUT {
                # priority dstnat = -100.
                type nat hook output priority -100; policy accept;
        }

        # For all packets to WAN (eth0), after routing, replace the source address
        # with the primary IP of WAN interface (masquerade).
        # Also necessary to enable masquerade on LAN for WireGuard (VPN).
        chain POSTROUTING {
                # priority srcnat = 100.
                type nat hook postrouting priority srcnat; policy accept;
                oifname $wan counter masquerade
                oifname $lan counter masquerade
        }
}

# Allow all outgoing, but drop incoming and forwarding packets by default:
table ip filter {
        chain INPUT {
                type filter hook input priority filter; policy drop;
                # Boilerplate acceptance policy.
                iifname $lo counter accept
                iifname $lan counter accept
                iifname $vpn counter accept
                # Accept already established and related connections.
                iifname $wan ct state established,related counter accept
                # Drop invalid packets.
                iifname $wan ct state invalid counter drop
                # Pass traffic to protocol-specific chains:
                # Only allow new connections (established and related should already be handled)
                # For TCP, additionally only allow new SYN packets since that is the only valid
                # method for establishing a new TCP connection.
                iifname $wan ip protocol udp ct state new counter jump UDP
                iifname $wan tcp flags & (fin | syn | rst | ack) == syn ct state new counter jump TCP
                iifname $wan ip protocol icmp ct state new counter jump ICMP
                # Drop anything that's fallen through to this point.
                counter drop
        }

        chain FORWARD {
                type filter hook forward priority filter; policy drop;
                # Forward filtering boilerplate rules.
                iifname $wan oifname $lan ct state established,related counter accept
                iifname $vpn oifname $lan counter accept
                iifname $lan oifname $vpn counter accept
                iifname $lan oifname $wan counter accept
        }

        chain OUTPUT {
                type filter hook output priority filter; policy accept;
        }

        # Custom per-protocol chains:
        chain ICMP {
        }

        # Acceptable TCP traffic:
        chain TCP {
                # Example:
                #iifname $wan tcp dport 51413 counter accept
        }

        # Acceptable UDP traffic:
        chain UDP {
                # Allow WireGuard
                iifname $wan udp dport 51820 counter accept
        }
}