BIND9 проблема с собственным доменом
-
У вас BIND, случайно, не одновременно с дефолтным DNS Resolver (unbound) запущен?
Чтоdigзапущенный на pfSense выдаёт? -
-
Добрый
@svjat-orb
А с машины из лан в какой ip пф разрешается, если обратится к нему по имени? -
@werter
Вот из локалки обращаюсь по домену - открывается
Вот из локалки по ИП адресу - разрешает
Включаю VPN - по домену уже не пускает
Свежий dig - все пусто, как будто нет NS вообще
-
@svjat-orb said in BIND9 проблема с собственным доменом:
@werter
Вот из локалки обращаюсь по домену - открываетсяУ вас NS прописан где надо? Из локалки-то он просто смотрит что в местном BIND'е есть, и всё норм.
53 порт открыт снаружи?
Попробуйте сниффером посмотреть что к вам приходит вообще. -
Коллеги, все взлетело. Я забыл про правило на WAN, которое открывает веб морду наружу
Сейчас все заработало.
И если можно последний вопрос:
Сайт внутри локалки, например 192.168.0.53, он настроен на работу через https
Я на pfsense сделал правило которое редиректит с 443 порта на 443 порт веб сервера, все ок. Сделал правило с 80 порта переброс на 443, но вместо этого перекидывает на порт 8080 где висит веб морда pfsense.. -
@svjat-orb выключите автоматический редирект:
на странице System / Advanced / Admin Access. -
Добрый.
@svjat-orbСделал правило с 80 порта переброс на 443
Зачем? Надо правило с 80 на 80. Дальше уже на бэкэнде сработает редирект , если он там настроен.
Пользуйте haproxy для таких целей. Он есть для пф - ставьте develop-версию. -
Спасибо коллеги, вроде все заработало.
-
Добрый день! Вынужден апнуть тему. Домен 56.rospotrebnadzor.ru
DNS зона настроена, сайт доступен извне. НО из локалки его не открыть, даже не пингуется. И это только с собственным сайтом, остальной инет работает.
Прошу помощи -
-
Так вроде нашел причину такого странного поведения.
Клиент посылает пакет с IP-источником 192.168.1.10 на IP-адрес назначения 1.1.1.1 на порт TCP / 80 для запроса веб-ресурса. В NAT маршрутизатор пакет назначения заменяет на 192.168.1.2, IP-адрес источника остается прежним: 192.168.1.10. Сервер отвечает на запрос клиента. Так как IP-адрес источника запроса находится в той же подсети, что и веб-сервер, веб-сервер не отправляет ответ обратно к маршрутизатору, а отправляет его непосредственно на 192.168.1.10 с исходным IP-адресом в ответе — 192.168.1.2. Фактически, клиент получает ответ не от того отправителя, от которого ожидает. Он отправлял пакет на маршрутизатор с IP 1.1.1.1 и должен получить от IP 1.1.1.1, а получил от IP 192.168.1.2. Этот пакет считается недействительным и связь не устанавливается, а страничка domain.ru не открывается.Далее идет описание правил для микротика
/ip firewall nat add chain=srcnat src-address=192.168.1.0/24 dst-address=192.168.1.99 protocol=tcp dst-port=22 out-interface=bridge action=masqueradeЯ создал в NAT правило как я понял его из описания
-
@svjat-orb
ЗдрВ том правиле , что Вы указали (микротика ) , помимо пробросать портов , есть еще и правило исходящего NATа . В котором помимо замены адреса назначения , идет еще и подмена адреса источника ( на ip адреса lan интерфейса ) .
То что у Вас сейчас происходит называется ассиметричной маршрутизациейТе что у Вас сейчас происходит ( это актуально для tcp )
Host->PF->internal server (это запрос)
а вот ответ сервера
Internal server -> Host
а хост ждет ответа от PF , но никак не от сервераhttps://docs.netgate.com/pfsense/en/latest/troubleshooting/asymmetric-routing.html
и почитайте тут еще (Может быть поможет)
https://docs.netgate.com/pfsense/en/latest/nat/reflection.html
Enable NAT Reflection for 1:1 NAT Эта опция позволяет клиентам во внутренних сетях получать доступ к локально размещенным службам, подключившись к внешнему IP-адресу записи NAT 1:1. Чтобы полностью активировать эту функцию, установите флажок Enable NAT Reflection for 1:1 NAT и Enable automatic outbound NAT for Reflection. Последний вариант необходим только в том случае, если клиенты и серверы находятся в одной подсети. -
@konstanti
Спасибо, попробую активировать reflection.
