iptables, Wireguard: двусторонняя маршрутизация между VPN и LAN
Я настраиваю VPN с помощью WireGuard и застрял в настройке брандмауэра на соответствующем сервере VPN. хотите, чтобы были доступны следующие функции:
- VPN-устройства (
10.6.0.0/24), доступные из LAN (10.20.0.0/24) (проблема!) - LAN-устройства (
10.20.0.0/24) доступно через VPN (10.6.0.0/24) (работает!)
Текущая конфигурация iptables:
Перенаправлять весь трафик от существующего (уже открытого ) соединения в любом направлении
iptables -t filter -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
Это позволяет устройствам LAN быть доступными через VPN (работает нормально)
# Direction: VPN -> LAN -------------------------------------------------------------
iptables -t nat -A PREROUTING -d 10.20.0.0/24 -j DNAT --to-destination 10.6.0.1 # Act as destination NAT from VPN to LAN (be the LAN-gateway for the VPN)
iptables -t filter -A FORWARD -s 10.6.0.0/24 -d 10.20.0.0/24 -j ACCEPT # Accept traffic from VPN to LAN
iptables -t nat -A POSTROUTING -s 10.6.0.0/24 -d 10.20.0.0/24 -j MASQUERADE # Mask traffic from VPN to LAN for responses
Это позволит устройствам VPN быть доступными из LAN (нужна помощь!)
# Direction: LAN -> VPN -------------------------------------------------------------
iptables -t filter -A FORWARD -s 10.20.0.0/24 -d 10.6.0.0/24 -j ACCEPT # Accept traffic from LAN to VPN
iptables -t nat -A POSTROUTING -s 10.20.0.0/24 -d 10.6.0.0/24 -j MASQUERADE # Mask traffic from LAN to VPN for responses
Текущие результаты:
Из просмотра эти правила, я, вероятно, ошибаюсь в другом DNAT / SNAT в нижнем разделе, но я все еще не могу понять это ...
Счетчики интерфейса на интерфейсе VPN показывают, что эхо-запросы отправляются на VPN-клиент и Вернись! Так т Проблема, похоже, заключается в том, что прибывающий пакет VPN должен быть преобразован и направлен в локальную сеть.
Если требуется дополнительная информация, спросите :) Спасибо за ваше время!
Проблема решена
Как правильно заметил @MichaelHampton выше, в этом сценарии NAT не нужен. Вся задача заключается исключительно в правильной маршрутизации, а не в NAT.
Причина проблемы
Чтобы клиенты могли подключаться к локальной сети (10.20.0.0/24), необходимо добавить эту подсеть в список AllowedIPs внутри вашей конфигурации сервера, чтобы быть разрешенным.
Это, однако, автоматически устанавливает новый маршрут для соответствующей подсети, перекрывая исходный маршрут. Результат: ваш сервер больше не может связаться с хостами в вашей подсети LAN, из-за чего все попытки подключения остаются безуспешными:
Destination Gateway Genmask Flags Metric Ref Use Iface
-ok-> 10.6.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wg0
-!!-> 10.20.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wg0
-ok-> 10.20.0.0 0.0.0.0 255.255.255.0 U 303 0 0 wlan0
Поскольку метрика для этого маршрута равна 0 (ниже, чем метрика маршрута по умолчанию ниже), этот маршрут всегда будет предпочтительным. и делает невозможными попытки подключения к локальной сети.
Постоянное разрешение
В моем случае я просто добавил следующую строку в мой /etc/wireguard/wg0.conf:
PostUp = route del -net 10.20.0.0/24 dev wg0
Это удалило маршрут, который будет создаваться каждый раз Wireguard перезагружается. Это необходимо сделать для всех подсетей, НЕ ЯВЛЯЮЩИХСЯ подсетями VPN, и их нельзя переопределять.
EDIT: Вы можете просто добавить Table=off в свой /etc/wireguard/wg0.conf, и WireGuard перестанет портить вашу таблицу маршрутизации :)
В общем, довольно нервный опыт. Я почти уверен, что напишу скрипт, который позаботится об этих вещах и сделает WireGuard немного более «подключаемым и работающим» :)