Я пытаюсь настроить VPN-сервер Wireguard, чтобы один одноранговый узел мог подключаться и получать доступ к сети, в которой находится VPN-сервер, а также чтобы серверы в сети могли получить доступ к одноранговому узлу, который подключается к VPN-серверу. В моем описании ниже я попытался упростить конфигурацию и наложил еще много ограничений и мер безопасности в производственную систему, но я попытался сохранить модель как можно более простой. По сути, это VPN типа «сеть-сеть», но в которой удаленный сайт является одним клиентом, а не «клиент-сайт», где клиент подключен к основной сети через NAT.
Описание сетевой архитектуры. В настоящее время работает с одним одноранговым компьютером, но их будет несколько. В этом примере он работает под управлением Windows, а для интерфейса Wireguard установлено значение 192.168.2.2. Интерфейс локальной сети - 10.0.0.4. С этого момента я буду называть его Peer1. VPN-сервер под управлением Wireguard в Ubuntu 19.09 имеет два интерфейса: eth0 (192.168.1.1) и wg0 (интерфейс Wireguard 192.168.2.1). Я буду называть этот сервер VPN1 Несколько серверов в подсети 192.168.1.0/24 под управлением различных Linux и Windows. Я буду называть их Server1, Server2 и т. Д. Или все вместе как серверы.
Желаемое подключение. Любой сервер в сети (Server1, Server2 и т. Д.) Может получить доступ к службе на Peer1 (EG RDP на TCP3389). Peer1 может получить доступ к службам, размещенным на любом из серверов (EG RDP или SSH)
Текущее подключение. Peer1 может подключиться к VPN1 VPN1 может каждый сервер Peer1 не может подключиться к Peer1 Peer1 может подключиться к серверам, но это не всегда работает. Кажется, что он волшебным образом начинает работать после того, как я не обнаружил никаких изменений в таблицах маршрутизации или брандмауэре.
Вещи, на которые я смотрел.
Туннель Wireguard работает правильно, о чем свидетельствует подключение между Peer1 и VPN1.
Маршруты правильные, трафик с серверов на 192.168.2.2 отправляется на 192.168.1.1, а трафик с Peer1 на серверы отправляется на VPN1
Таблица маршрутов от Peer1. Обратите внимание, маршруты Wireguard добавляются автоматически клиентом Wireguard:
PS C:\Users\TheRealVimShady> route print
===========================================================================
Interface List
8...........................WireGuard Tunnel
7...00 0d 3a 8f 0b 69 ......Microsoft Hyper-V Network Adapter
1...........................Software Loopback Interface 1
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.0.0.1 10.0.0.4 10
10.0.0.0 255.255.255.0 On-link 10.0.0.4 266
10.0.0.4 255.255.255.255 On-link 10.0.0.4 266
10.0.0.255 255.255.255.255 On-link 10.0.0.4 266
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
168.63.129.16 255.255.255.255 10.0.0.1 10.0.0.4 11
169.254.169.254 255.255.255.255 10.0.0.1 10.0.0.4 11
192.168.1.0 255.255.255.0 On-link 192.168.2.2 5
192.168.1.255 255.255.255.255 On-link 192.168.2.2 261
192.168.2.0 255.255.255.0 On-link 192.168.2.2 5
192.168.2.2 255.255.255.255 On-link 192.168.2.2 261
192.168.2.255 255.255.255.255 On-link 192.168.2.2 261
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 10.0.0.4 266
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 10.0.0.4 266
===========================================================================
Persistent Routes:
None
IPv6 Route Table
===========================================================================
Active Routes:
If Metric Network Destination Gateway
1 331 ::1/128 On-link
7 266 fe80::/64 On-link
7 266 fe80::1940:442a:7d85:2b8/128
On-link
1 331 ff00::/8 On-link
7 266 ff00::/8 On-link
===========================================================================
Persistent Routes:
None
Таблица маршрутов от Server1. Обратите внимание, вручную добавленный маршрут для трафика VPN:
default via 192.168.1.253 dev kvmbr0 proto static metric 425
169.254.0.0/16 dev kvmbr0 scope link metric 1000
192.168.1.0/24 dev kvmbr0 proto kernel scope link src 192.168.1.6 metric 425
192.168.2.0/24 via 192.168.1.2 dev kvmbr0
Таблица маршрутов от VPN1:
default via 192.168.1.253 dev eth0 proto static
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1
192.168.2.2 dev wg0 scope link
Трассировка маршрута от Server1 до Peer1:
traceroute to 192.168.2.2 (192.168.2.2), 30 hops max, 60 byte packets
1 vpn1.xxx.xxx (192.168.1.1) 0.095 ms 0.028 ms 0.026 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 *^C
Трассировка маршрута от Peer1 до Server1
PS C:\Users\TheRealVimShady> tracert 192.168.1.6
Tracing route to 192.168.1.6 over a maximum of 30 hops
1 179 ms 88 ms 87 ms 192.168.2.1
2 87 ms 87 ms 88 ms 192.168.1.6
Trace complete.
Пересылка включена на VPN1:
root@vpn1:~# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
IPTables очень снисходителен к VPN1. У меня есть несколько конкретных примеров служб в этих правилах, но с принятой по умолчанию политикой я не думаю, что это проблема:
root@vpn1:~# iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p udp -m udp --dport 51820 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i wg0 -o eth0 -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -i eth0 -o wg0 -p tcp -m tcp --dport 3389 -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -p icmp -m icmp --icmp-type 0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -p icmp -m icmp --icmp-type 8 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
Брандмауэры на Серверах и Peer1 не мешают. Были добавлены определенные исключения, которые были протестированы с отключенными брандмауэрами.
Многие руководства, которые я прочитал, заявляют, что следует добавить правило MASQUERADE, но для моего сценария я считаю, что это неверно, потому что я хочу получить доступ к службам на Peer1, и в конечном итоге будет несколько одноранговых узлов. Настроить переадресацию портов было бы неудобно и я считаю ненужным.
Мои конкретные вопросы
Почему трафик, предназначенный для серверов, достигает VPN1, но не дальше?
Почему трафик не всегда проходит от Peer1 к серверам?
Есть что-то, что я упустил или чего-то не понимаю, любые рекомендации были получены с благодарностью.
С уважением, OttoTheBusDriver