Wireguard работает даже без настройки IP-адреса туннеля, т.е. достаточно задать AllowedIPs, адреса конечных точек, закрытый и открытый ключи.
В документахOpnSense, появляется следующее предупреждение:
Примечание:Адрес туннеля должен быть в нотации CIDR и должен быть уникальным IP-адресом и подсетью для вашей сети. [..]Не используйте туннельный адрес /32 (IPv4) или /128 (IPv6)
и у pfSense есть вероятное объяснение:
Примечание:Маршруты не создаются автоматически в системной таблице маршрутизации. Маршруты для сетей, отличных от самой туннельной сети, должны быть настроены отдельно с использованием статических или динамических маршрутов.
Поиск в интернете не дает много объяснений:
- Reddit: путаница с масками подсетей
- Reddit: Помощь по /24 и /32 при использовании в качестве VPN-сервера
- Reddit: различия между /8, /16 и т. д. Для чего они используются?
Подсеть, похоже, не имеет никакой функциональности, мы провели небольшое тестирование:
- Это не связано с локальной маршрутизацией трафика, т.е. маршрутизация ко второму подключенному узлу работает как с подсетью, содержащей оба узла, так и без нее.
- это не связано с "оставаться на интерфейсе" или проходить через ядро. В обоих случаях мы могли бы контролировать трафик с помощью правил брандмауэра.
Итак, каково назначение маски подсети в туннельном IP?
решение1
Маска подсетиничего не делаетСпецифично для WireGuard.
Сам WireGuard не использует и не заботится о масках подсетей на своих интерфейсных адресах (или даже не использует и не заботится о самих адресах). Однако сетевой стек и другие сетевые инструменты на хосте WireGuard заботятся об IP-адресах и подсетях, зарегистрированных для каждого сетевого интерфейса, и будут использовать их, чтобы попытаться выяснить, подключен ли конкретный интерфейс напрямую к конкретной сети.
Ваше наблюдаемое поведение может различаться в зависимости от ОС и конкретных сетевых инструментов, которые вы используете (например, OPNSense/pfSense и все их разнообразные плагины), но множество вещей, таких как таблицы маршрутизации, правила брандмауэра, сообщения ARP, таблицы соседей и т. д., могут быть сгенерированы автоматически на основе IP-адресов и подсетей, которые вы настроили для каждого сетевого интерфейса. Однако во многих случаях вы все равно можете переопределить эти значения по умолчанию с помощью пользовательских правил маршрутизации/брандмауэра, настроек ядра, конфигурации сетевого демона и т. д.
Например, когда вы запускаете интерфейс WireGuard со стандартнымwg-быстрыйскрипт на Linux, этот скрипт будет использоватьiproute2инструмент для добавления каждого адреса и подсети, которые вы настроили для интерфейса. Для каждого добавляемого адреса iproute2 автоматически добавляет соответствующий маршрут в основную таблицу маршрутизации, чтобы соответствовать подсети адреса. Использование этого скрипта для запуска интерфейса с именем и wg0адресом 10.0.0.123/24приведет к тому, что iproute2 добавит следующий маршрут в основную таблицу маршрутизации:
10.0.0.0/24 dev wg0 proto kernel scope link src 10.0.0.123
Это не проблема WireGuard, это просто поведение по умолчанию некоторых стандартных сетевых инструментов в Linux. Вы можете удалить этот маршрут и добавить другие маршруты или просто использовать другой набор инструментов для настройки интерфейса WireGuard. (Но имейте в виду, что этот или любой другой маршрут, добавленный к интерфейсу WireGuard, не имеющий соответствующей AllowedIPsзаписи в собственной конфигурации интерфейса, фактически станет черной дырой.)
В результате в большинстве случаев вполне нормально использовать адрес с маской подсети /32 или /128 на интерфейсе WireGuard. Вы можете настроить собственные правила маршрутизации и брандмауэра, чтобы отправлять любой трафик на этот интерфейс. Но в более сложных случаях — особенно когда вы хотите запустить на интерфейсе такие инструменты, как Proxy ARP, NDP Proxy, OSPF и т. д. (которые предназначены для использования в локальных подсетях) — вы можете избежать необходимости бороться с поведением этих инструментов по умолчанию, назначив интерфейс WireGuard и его виртуальных соседей согласованной логической подсети.