Добрый день, всем. У меня возникла такая ситуация: я использую два устройства pfSense, каждое из которых обслуживает свою локальную сеть. Есть также отдельный сервер в интернете, на котором настроен сервер Wireguard. Итак, вот характеристики сети: 1. Wireguard сервер: 172.31.0.1/24 (сеть WG) - назовём его "Внешний" 2. pfSense "Домашний": 172.31.0.2/24 (сеть WG), 192.168.1.1/24 (LAN) 3. pfSense "Рабочий": 172.31.0.3/24 (сеть WG), 10.10.0.1/24 (LAN) Существующие маршруты: - pfSense "Домашний": 10.10.0.0/24 через 172.31.0.1 - Внешний сервер: 10.10.0.0/24 через 172.31.0.3 В настоящее время я пытаюсь настроить связь в одну сторону. В результате, любой клиент сети LAN (192.168.1.0/24) или сети WG (172.31.0.0/24) может успешно пинговать и трассировать до pfSense "Рабочий" по адресу 172.31.0.3. Однако, **pfSense "Рабочий" по адресу 10.10.0.1 не отвечает на пинг из сети 172.31.0.0/24.** Задача состоит в том, чтобы pfSense могли отвечать на запросы с адресов из сетей 192.168.1.0/24 и 10.10.0.0/24. Для начала мне нужно разобраться, почему "Рабочий" pfSense не отвечает на запросы к своему собственному адресу 10.10.0.1. Я предполагаю, что проблема может быть связана с настройками фаерволла, однако у меня всё разрешено в обе стороны. Может быть, в pfSense есть какие-то дополнительные настройки, которые я упускаю? И поскольку я заметил, что на Хабре любят визуализировать информацию, вот схема моей сети:
Ваша проблема действительно может быть связана с настройками фаерволла или маршрутами на вашем pfSense "Рабочий". Давайте рассмотрим несколько направлений, которые могут помочь вам диагностировать и решить проблему без ответа на пинг с адресов из сети 172.31.0.0/24 на pfSense "Рабочий" по адресу 10.10.0.1. 1. **Проверка правил фаерволла**: - На pfSense "Рабочий", убедитесь, что у вас есть соответствующие правила фаерволла для интерфейса LAN (10.10.0.1), которые разрешают входящие ICMP (пинг) запросы. - Проверьте правила фаерволла, чтобы убедиться, что они разрешают трафик из сети 172.31.0.0/24 на интерфейс 10.10.0.0/24. 2. **Проверка маршрутов**: - Убедитесь, что хосты в сети 172.31.0.0/24 корректно маршрутизируют трафик к 10.10.0.1. Это означает, что у вас должен быть маршрут, указывающий на pfSense "Рабочий", который знает, как достичь 10.10.0.0/24 через 172.31.0.3. - Также проверьте, что pfSense "Рабочий" знает, как возвращать трафик обратно в сеть 172.31.0.0/24. 3. **Ping и ICMP на pfSense**: - Убедитесь, что в разделе "System" -> "Advanced" -> "Firewall & NAT" у вас включено разрешение на ICMP пинг. - Иногда pfSense может блокировать ICMP пакеты по умолчанию, поэтому это стоит проверить. 4. **Логи фаерволла**: - Проверьте логи фаерволла на pfSense. Это даст вам информацию о том, блокируются ли какие-либо пакеты ICMP, а также о том, где именно происходит блокировка. 5. **Тестирование из сети 172.31.0.0/24**: - Попробуйте выполнить `traceroute` или `tracert` до pfSense "Рабочий" из сети 172.31.0.0/24, чтобы увидеть, где именно теряется пакет (если это происходит). 6. **Настройка NAT**: - Проверьте настройки NAT. Если NAT неправильно настроен, это может повлиять на то, как пакеты маршрутизируются и обрабатываются. 7. **Проверка подключений**: - Убедитесь, что сеть 10.10.0.0/24 и интерфейс pfSense "Рабочий" физически работает (например, отключение и повторное подключение к сети) и нет проблем с кабелем или оборудованием. 8. **Проверка пингов**: - Пинговать можно как с интерфейса pfSense, так и с клиентов в сети. Попробуйте пинговать адрес 10.10.0.1 с самого pfSense через Diagnostics -> Ping, чтобы исключить проблемы на стороне клиента. Если вы проверите все эти настройки и всё равно не сможете получить ответ от pfSense "Рабочий", желательно также рассмотреть возможность получения помощи на форумах pfSense, где участники могут подробно проанализировать ваши настройки и предложить конкретные решения.
В общем, задал вопрос с которым почти неделю бился, и сам на него напишу решение.
Кроме настройки фаерволов в которых должно быть всё разрешено и прописи маршрутов на обоих PFSENSE и сервере WG необходимо еще в серверном конфиге wireguard в конкретном пире прописать AllowedIps.
Изначально в AllowedIps добавляется только адрес клиента. Например:
#Home [Peer] PublicKey = <public_client_key> PresharedKey = <preshared_key> AllowedIPs = 172.31.0.2/32 #Work [Peer] PublicKey = <public_client_key> PresharedKey = <preshared_key> AllowedIPs = 172.31.0.3/32
Но для того чтобы пакеты начали двигаться в другие подсети, необходимо у каждого клиента указать его внутренние LAN, т.е.:
#Home [Peer] PublicKey = <public_client_key> PresharedKey = <preshared_key> AllowedIPs = 172.31.0.2/32, 192.168.1.0/24> #Work [Peer] PublicKey = <public_client_key> PresharedKey = <preshared_key> AllowedIPs = 172.31.0.3/32, 10.10.0.0/24
Повторюсь, Внутренние подсети необходимо прописать только тем клиентам, через которые мы коннектимся к подсетям, а не клиентам С которых.
Клиенты С которых необходимо подключиться в внутренним подсетям и которые напрямую подключены к серверу WG (мобильный телефон например) у них в клиентском необходимо разрешить подсети LAN 192.168.1.0/24 10.10.0.0/24