☰

Невозможно подключиться к домену через HTTPS на том же сервере за брандмауэром PfSense

tag-icon • tag-icon networking ubuntu firewall nginx https
Невозможно подключиться к домену через HTTPS на том же сервере за брандмауэром PfSense

Я размещаю платформу на сервере с несколькими доменными именами, скажем, example.com и anotherexample.com. Я запускаю бэкенд Spring Boot на этом сервере, который использует домен example.com и пытается связаться с anotherexample.com. Моя проблема в том, что я не могу подключиться к другому домену по HTTPS, он просто даже не подключается. Я попробовал следующие тесты, которые возвращают разные результаты:

  1. Использование curlна машине, не защищенной брандмауэром,https://anotherexample.com, работает отлично
  2. Использование curlна сервере, но вместо этого использованиеhttp://anotherexample.com, работает отлично
  3. Использование curlна сервере дляhttps://anotherexample.com, нет ответа, в конечном итоге истекает время ожидания
  4. Использование curlбрандмауэра дляhttps://anotherexample.com, нет ответа, в конечном итоге истекает время ожидания
  5. Используется openssl s_client -connect anotherexample.com:443 -servername anotherexample.comна сервере, нет ответа, в конечном итоге истекает время ожидания
  6. При изменении /etc/hostsна сервере на 127.0.0.1 anotherexample.com, при запуске openssl s_client -connect anotherexample.com:443 -servername anotherexample.comя получаю ответ.

Что может быть причиной того, что я не могу подключиться ни к одному домену, размещенному на машинах за брандмауэром? Может быть, это что-то неправильно настроено на сервере (Ubuntu 22.04) или на брандмауэре PfSense (2.7.2)?


Моя структура следующая:

  • PfSense Firewall, который использует NAT, чтобы гарантировать, что публичный IP-адрес попадает во внутренний IP-адрес сервера
  • Сервер работает под управлением NGINX с открытыми портами 80 и 443. Сертификаты создаются через LetsEncrypt и отлично работают в браузере.

решение1

Это нормально; DNAT («переадресация портов») не работает, когда и источник, и фактическое место назначения находятся в одной подсети (или даже в одной системе). Было опубликовано много более ранних тем относительно той же проблемы с домашними шлюзами (поиск «NAT hairpin»), но это в равной степени относится к любой реализации NAT, включая pfSense, поэтому ищите более ранние сообщения для полного объяснения; основная проблема в том, что брандмауэр имеет возможность переписывать пакеты только в одном направлении, но не в другом.

Обычный обходной путь — заставить pfSense также переписать исходный IP-адрес, заставив веб-сервер думать, что соединение на самом деле исходит от брандмауэра, а не от него самого. Чтобы сделать это, включитеОтражение NATв вашем брандмауэре. В других местах это будет называться "NAT loopback", "NAT hairpin" или просто пользовательское правило SNAT без определенного имени.

Обратите внимание, что это немного скажется на производительности, поскольку каждый пакет обязательно проходит через Ethernet в pfSense.иназад, вместо того, чтобы полностью оставаться в пределах машины. Ваши веб-приложения также должны будут ожидать IP-адрес брандмауэра, если вы используете доступ на основе IP.

Поэтому я бы личнорекомендоватьзаписи 127.0.0.1/etc/hosts для всех доменов вместо того, чтобы полагаться на отражение NAT.

Связанный контент