Типичная задача: есть сервер мониторинга (Zabbix) в облачной сети за виртуальным pfSense. Есть удаленный филиал с роутером, за которым живет оконечное устройство (например, видеорегистратор). Между ними поднят туннель WireGuard.
При этом удаленный роутер настроен в режиме обычного WireGuard-клиента. Трафик со стороны самого роутера до облака ходит идеально, статические маршруты прописаны, но вот трафик из локалки pfSense (от Zabbix) долетает до роутера и... молча дропается межсетевым экраном. Знакомо?
Allowed IPs. Роутер ждет трафик только из родной туннельной подсети. Когда в туннель прилетает пакет от «чужого» IP (например, 10.10.35.122), встроенная защита роутера от спуфинга считает этот трафик недоверенным и блокирует его на входе.
Чтобы не воевать с прошивкой удаленного роутера и не отключать его файрвол, мы применим изящный костыль — замаскируем трафик Zabbix прямо на выходе из pfSense. Роутер будет думать, что с ним общается сам pfSense через свой туннельный IP, которому он доверяет.
Пошаговый конфиг в веб-интерфейсе pfSense:
Firewall ➔ NAT, вкладка Outbound.SERVER_WIREGUARD).anyNetwork ➔ IP твоего Zabbix (например, 10.10.35.122/32).Network ➔ Сеть за удаленным роутером (например, 192.168.123.0/24).Interface Address.Теперь traceroute и пакеты мониторинга ходят без единой запинки:
traceroute to 192.168.123.201, 30 hops max 1 10.10.35.1 (pfSense) 0.296 ms 2 172.16.95.140 (Удаленный роутер принял пакет под туннельным IP) 21.993 ms 3 192.168.123.201 (Видеорегистратор успешно ответил!) 22.105 ms
Zabbix не потерял доступ в интернет и к своей LAN, но трафик до конкретной удаленной точки теперь маскируется туннельным адресом pfSense. Схема железобетонная, заводится за 1 минуту и спасает, когда другие методы маршрутизации бессильны.
Комментарии
Пока нет комментариев. Будьте первым!