[Проблема решена. Пишу это, чтобы помочь будущим людям, которые столкнутся с такой же задачей] Я уже несколько часов копаюсь в туториалах, документации и так далее, пытаясь разобраться. Мой pihole — 192.168.9.3, и я хотел перенаправить весь трафик, который идет на порт 53, обратно на pihole для проверки/заглушения перед отправкой на настоящий DNS-сервер. В основном это дополнительный, тонкий уровень защиты на случай, если в моей сети уже есть какое-то вредоносное ПО с жестко прописанным DNS-сервером.
Еще одна проблема — большинство ответов на форумах шли под edgerouter, из-за чего я только запутался [плюс их нельзя было просто скопировать и вставить]. Также у меня была ошибка: когда я наконец нашел рабочую конфигурацию, получил сообщение «reply from unexpected source: 192.168.9.3#53, expected 8.8.8.8#53».
Короче, у меня USG-Pro-4. Вот config.gateway.json, который реально решил мою проблему:
{
"service": {
"nat": {
"rule": {
"1": {
"description": "Redirect DNS queries to pihole",
"destination": {
"port": "53"
},
"source": {
"address": "!192.168.9.3"
},
"inside-address": {
"address": "192.168.9.3",
"port": "53"
},
"inbound-interface": "eth0",
"protocol": "tcp_udp",
"type": "destination"
},
"5002": {
"description": "Translate reply back",
"destination": {
"address": "192.168.9.3",
"port": "53"
},
"outbound-interface": "eth0",
"protocol": "tcp_udp",
"type": "masquerade"
}
}
}
}
}
Особые сложности у меня вызывали "outbound-interface", "inbound-interface" и всякие такие штуки. Оказалось, что в моей голове они должны были быть с точки зрения шлюза [ну, очевидно, если подумать?]. Кстати, в конфиге упоминается только eth0 — это мой LAN1 интерфейс. Чтобы понять, какой у вас основной LAN-интерфейс, зайдите на шлюз, наберите «ifconfig -a» и найдите интерфейс в вашей локальной сети.
Первое правило просто перенаправляет весь трафик на порт 53, если он не от pihole, обратно на pihole. Второе правило типа "masquerade" — оно гарантирует, что шлюз вставлен в обратный поток трафика и умеет переводить пакеты обратно.
Вот страница, где объясняется, что делать с вышеуказанным JSON:
Пишу это 27 июля 2018. Когда мой шлюз попадал в цикл конфигурации, контроллер unifi выдавал предупреждения в окне алертов, что обычно помогало. Я просто временно отключал config.gateway.json командой «mv config.gateway.json config.gateway.json.disabled» и ждал спокойно. Обычно через три-пять минут получал оповещение, что шлюз перезагрузился и успешно сконфигурировался заново.
В общем, если кому-то [особенно, скорее всего, будущему мне] это оказалось полезным — отлично, рад, что смог помочь.
Gary
Еще одна проблема — большинство ответов на форумах шли под edgerouter, из-за чего я только запутался [плюс их нельзя было просто скопировать и вставить]. Также у меня была ошибка: когда я наконец нашел рабочую конфигурацию, получил сообщение «reply from unexpected source: 192.168.9.3#53, expected 8.8.8.8#53».
Короче, у меня USG-Pro-4. Вот config.gateway.json, который реально решил мою проблему:
{
"service": {
"nat": {
"rule": {
"1": {
"description": "Redirect DNS queries to pihole",
"destination": {
"port": "53"
},
"source": {
"address": "!192.168.9.3"
},
"inside-address": {
"address": "192.168.9.3",
"port": "53"
},
"inbound-interface": "eth0",
"protocol": "tcp_udp",
"type": "destination"
},
"5002": {
"description": "Translate reply back",
"destination": {
"address": "192.168.9.3",
"port": "53"
},
"outbound-interface": "eth0",
"protocol": "tcp_udp",
"type": "masquerade"
}
}
}
}
}
Особые сложности у меня вызывали "outbound-interface", "inbound-interface" и всякие такие штуки. Оказалось, что в моей голове они должны были быть с точки зрения шлюза [ну, очевидно, если подумать?]. Кстати, в конфиге упоминается только eth0 — это мой LAN1 интерфейс. Чтобы понять, какой у вас основной LAN-интерфейс, зайдите на шлюз, наберите «ifconfig -a» и найдите интерфейс в вашей локальной сети.
Первое правило просто перенаправляет весь трафик на порт 53, если он не от pihole, обратно на pihole. Второе правило типа "masquerade" — оно гарантирует, что шлюз вставлен в обратный поток трафика и умеет переводить пакеты обратно.
Вот страница, где объясняется, что делать с вышеуказанным JSON:
Пишу это 27 июля 2018. Когда мой шлюз попадал в цикл конфигурации, контроллер unifi выдавал предупреждения в окне алертов, что обычно помогало. Я просто временно отключал config.gateway.json командой «mv config.gateway.json config.gateway.json.disabled» и ждал спокойно. Обычно через три-пять минут получал оповещение, что шлюз перезагрузился и успешно сконфигурировался заново.
В общем, если кому-то [особенно, скорее всего, будущему мне] это оказалось полезным — отлично, рад, что смог помочь.
Gary