Маршрутизируйте весь трафик через одноранговый узел Wireguard
У меня есть настройка Wireguard VPN, которая в основном выглядит так:
P1 ---- S ---- P ---- LAN
Px -----|
- S (ip 192.168.60.1) - это сервер WG, работающий на Ubuntu 20.04 с включенным ufw, с общедоступным IP-адресом (с использованием wg0 интерфейс).
- P (ip 192.168.60.2) - это одноранговый узел WG, работающий за CGNAT, без общедоступного IP-адреса, подключенный к своей собственной локальной сети.
- P1..Px - другие одноранговые узлы WG (ip 192.168.60.1x) .
Ufw имеет следующую конфигурацию:
To Action From
-- ------ ----
22/tcp ALLOW Anywhere
51820/udp ALLOW Anywhere
Anywhere on eth0 ALLOW FWD Anywhere on wg0
Anywhere on wg0 ALLOW FWD Anywhere on eth0
Anywhere on wg0 ALLOW FWD Anywhere on wg0
Я хочу добиться, чтобы весь трафик, исходящий от одноранговых узлов P1..Px, маршрутизировался через P.
Я пробовал следующее, но безуспешно:
На P1, Я установил AllowedIPs для S на 0.0.0.0/0. В SI установил AllowedIPs для P на 0.0.0.0/0. - Эта конфигурация делает S недоступным через eth0 (и по-прежнему ничего не направляет на P).
На P1 , Я установил AllowedIPs для S на 0.0.0.0/0. В SI попытался настроить маршрутизацию на основе политик на основе IP-адреса источника:
sudo ip rule add from 192.168.60.0/24 lookup 200 sudo ip route добавить по умолчанию через 192.168.60.2 dev wg0 table 200Это предотвращает подключение P1 к чему-либо, кроме 192.168.60.0/24.
Вероятно, вам следует начать с использования Table=off в wg-quick conf на S и P. Значение AllowedIPs= не вызовет изменения в маршрутах/политике правил маршрутизации на них потом.
РЕДАКТИРОВАТЬ: На самом деле было бы нормально оставить Table= нетронутым на P, если только вам не нужно, чтобы AllowedIPs= of S на нем было 0.0.0.0/0 вместо 192.168.60.0/24 по некоторым причинам, например нужно, чтобы трафик исходил из самого себя для маршрутизации S. Вам не нужно возиться с маршрутами и правилами маршрутизации на P самостоятельно, поскольку даже префикс в Address=192.168.60.24 февраля должен быть настроен необходимый маршрут. Следующий абзац, вероятно, не относится к тому, что вам нужно, хотя он может дать вам некоторые дополнительные сведения о том, как все работает.
Вероятно, вам следует использовать дополнительную IP-подсеть для S и P, например
192.168.59.0/30. Это избавит вас от хлопот, связанных с необходимостью дополнительного правила IP. Не забудьте добавить маршрут подсети для192.168.60.0/24на P, хотя, как и в случае сTable=off, ядро будет добавлять только префиксные маршруты для префикса(ов) в поле(я)Адрес=. Хорошо используйтеPostUp=(иPreDown=) между прочим.
Я не думаю, что вы хотите направлять трафик, который исходит от самого S, к P, поэтому вместо этого вы, вероятно, захотите использовать следующее правило ip:
# ip rule add iif wg0 from 192.168.60.0/24 lookup 200
Если вам действительно нужно направить, например. трафика, отличного от ответов сервера ssh и wireguard на P, вы можете дополнительно иметь:
# ip rule add iif lo lookup 200
# ip rule add iif lo ipproto tcp sport 22 lookup main
# ip rule add iif lo ipproto udp sport 51820 lookup main
Примечание: вы не можете просто сопоставить с из 192.168.60.1, добавленным в первое правило, и опустить два других, потому что для неотвечающего трафика исходный адрес часто (если не всегда) выбирается на основе выбранного маршрута - на данный момент он еще не установлен.
Обратите внимание, что порядок команд обычно определяет приоритет, поэтому убедитесь, что вы добавили правило «надмножества» перед правилами «подмножества», иначе последние будут переопределены первыми.
Также лучше оставить таблицу 200 пустой до тех пор, пока не будут установлены все необходимые правила, в противном случае удаленный доступ к хосту может быть отключен.
Наконец, nexthop не имеет смысла при маршруте к туннелю L3:
# ip route add default dev wg0 table 200
P.S. Убедитесь, что вы не только разрешили переадресацию IP в брандмауэре, но и включили ее с помощью sysctl.