BIND9 проблема с собственным доменом

[viktor_g]

@svjat-orb said in BIND9 проблема с собственным доменом:

@werter
Вот из локалки обращаюсь по домену - открывается

У вас NS прописан где надо? Из локалки-то он просто смотрит что в местном BIND'е есть, и всё норм.
53 порт открыт снаружи?
Попробуйте сниффером посмотреть что к вам приходит вообще.

[svjat.orb]

Коллеги, все взлетело. Я забыл про правило на WAN, которое открывает веб морду наружу

Сейчас все заработало.

И если можно последний вопрос:
Сайт внутри локалки, например 192.168.0.53, он настроен на работу через https
Я на pfsense сделал правило которое редиректит с 443 порта на 443 порт веб сервера, все ок. Сделал правило с 80 порта переброс на 443, но вместо этого перекидывает на порт 8080 где висит веб морда pfsense..

[viktor_g]

@svjat-orb выключите автоматический редирект:
на странице System / Advanced / Admin Access.

[werter]

Добрый.
@svjat-orb

Сделал правило с 80 порта переброс на 443

Зачем? Надо правило с 80 на 80. Дальше уже на бэкэнде сработает редирект , если он там настроен.
Пользуйте haproxy для таких целей. Он есть для пф - ставьте develop-версию.

[svjat.orb]

Спасибо коллеги, вроде все заработало.

[svjat.orb]

Добрый день! Вынужден апнуть тему. Домен 56.rospotrebnadzor.ru
DNS зона настроена, сайт доступен извне. НО из локалки его не открыть, даже не пингуется. И это только с собственным сайтом, остальной инет работает.

Прошу помощи

[svjat.orb]

@svjat-orb

Пинг с компа в локалке

[svjat.orb]

Так вроде нашел причину такого странного поведения.

Клиент посылает пакет с 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 правило как я понял его из описания

[Konstanti]

@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. Последний вариант необходим только в том 
случае, если клиенты и серверы находятся в одной подсети.

[svjat.orb]

@konstanti
Спасибо, попробую активировать reflection.