Маршрутызацыя Wireguard ад wg1 да wg0
У мяне дзве сеткі настроены з дапамогай Wireguard. Wg0 прызначаны для сервераў і wg1 для карыстальнікаў VPN Калі карыстальнік VPN на wg1 хоча звязацца з сеткай wg0, пакеты павінны быць маршрутызатарам праз адзін з сервераў wg0 (шлюз VPN).
wg0.conf на шлюзе VPN і на ўсіх серверах з інтэрфейсам wg0
[Interface]
Address = 10.1.0.15
ListenPort = 51820
PrivateKey = privatekey1
# node23
[Peer]
PublicKey = pubkey
AllowedIps = 10.1.0.23
Endpoint = node23.fqdn:51820
# node24
[Peer]
PublicKey = pubkey
AllowedIps = 10.1.0.24
Endpoint = node24:51820
# node25
[Peer]
PublicKey = pubkey
AllowedIps = 10.1.0.25
Endpoint = node25.fqdn:51820
...
wg1.conf на шлюзе VPN
[Interface]
Address = 10.100.0.1/32
ListenPort = 51810
PrivateKey = privatekey2
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
# user1 [Peer]
PublicKey = pubkey
AllowedIps = 10.100.0.2/32
...
І гэта гэта карыстальнікі wg1.conf (на самай справе wg0, таму што ў іх няма адраса 10.1.0.0)
[Interface]
Address = 10.100.0.2/32
ListenPort = 21841
PrivateKey = myprivatekey
[Peer]
PublicKey = pubkey
EndPoint = vpngate.fqdn:51810
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
Такім чынам, на саміх брамах VPN я магу запусціць curl -v http://10.1.0.23/ ] і я атрымліваю адказ у сетцы wg0. Пінг працуе на. Я магу звязацца з усімі серверамі ў сетцы. Тое ж самае з wg1-кліентам і wg1-серверам. Таксама я магу праглядаць Інтэрнэт праз VPN-браму. Але калі я спрабую выклікаць ад свайго кліента wg1 такі сервер wg0, як curl -v http://10.1.0.23/ , які павінен быць маршрутам (я думаю) праз vpn-gate і адтуль праз wg1 -> wg0 адказу няма.
Што мне не хапае?
Из объяснений WireGuard Cryptokey Routing:
В конфигурации сервера каждый одноранговый узел (клиент) сможет отправлять пакеты на сетевой интерфейс с IP-адресом источника, совпадающим с его соответствующий список разрешенных IP-адресов. Например, когда пакет полученный сервером от пира gN65BkIK..., после расшифровки и аутентифицирован, если его исходный IP-адрес 10.10.10.230, то он разрешен на интерфейс; в противном случае он упал.
=> входящий адрес должен быть в AllowedIPs, чтобы быть связанным с криптоключом, определенным в Peers и разрешенным.
В конфигурации сервера, когда сетевой интерфейс хочет отправить пакет партнеру (клиенту), он смотрит на пункт назначения этого пакета IP-адрес и сравнивает его со списком разрешенных IP-адресов каждого узла, чтобы увидеть, какой пир, чтобы отправить его. Например, если сетевой интерфейс запрашивается отправить пакет с IP-адресом назначения 10.10.10.230, он будет шифровать используя открытый ключ однорангового узла gN65BkIK..., а затем отправить его этому самая последняя конечная точка Интернета партнера.
=> Аналогично, исходящий адрес должен быть в AllowedIPs, чтобы можно было выбрать правильный криптоключ и его текущую удаленную конечную точку.
Когда клиент запускает curl -v http://10.1.0.23/, исходящие пакеты делают:
10.100.0.2 ----> ✔ 10.100.0.1 ==> 10.1.0.1 ----> ❌ 10.1.0.23
wg0 wg1 wg0 wg0
client gateway server
10.100.0.2 не находится в wg0 сервера . ]AllowedIPs для записи однорангового узла шлюза, чтобы пакет был отброшен.
Аналогичным образом, если сервер попытается связаться с клиентом (с правильно настроенным маршрутом для использования wg0), он не найдет соответствующего узла для адреса назначения, поэтому при отправке будет получена ошибка (т.е. ошибка, поскольку ошибка, возвращаемая сетевым системным вызовом, вероятно, специфична для WireGuard: ENOKEY (необходимый ключ недоступен)).
Таким образом, если все клиенты находятся в 10.100.0.0/24, они должны отображаться в конфигурации каждого сервера в разделе Peer для шлюза в записи AllowedIPs. Таким образом, если адрес шлюза равен 10.1.0.1 (эту информацию нельзя найти в OP), все серверы должны включать что-то вроде:
# gateway
[Peer]
PublicKey = pubkey
AllowedIPs = 10.1.0.1,10.100.0.0/24
Endpoint = vpngate.fqdn:51820
Обратное направление не вызовет проблем, поскольку клиент настроен на связь . ]любой IP-адрес, полученный на wg0 на шлюз.
Самому шлюзу не нужно изменять конфигурацию.