☰

Веб-сервер за NAT, как прослушивать публичный IP-адрес

tag-icon • tag-icon debian web-server routing ip nat
Веб-сервер за NAT, как прослушивать публичный IP-адрес

У меня есть веб-сервер Debian (nginx), работающий за брандмауэром с использованием NAT. На веб-сервере размещено несколько сайтов, которым требуется SSL и их собственный IP-адрес. Я бы хотел, чтобы сайты SSL слушали только свой определенный IP-адрес, а общие сайты слушали только общий IP.

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

Каков правильный порядок действий? Создать 1:1 NAT для каждого IP-адреса и добавить IP-адреса локальной сети в сетевой интерфейс для прослушивания, а затем назначить IP-адреса локальной сети определенным доменам? Или есть лучший способ? Есть ли способ передать публичный IP-адрес и предпринять действия на его основе? Спасибо.

решение1

Нет, вы не сможете пройти через исходный IP-адрес назначения после выполнения NAT, по крайней мере напрямую.

Я буду использовать 192.0.2.0/24 в качестве внешнего IP-блока и 198.51.100.0/24 в качестве внутреннего (см. RFC5737).

Вот некоторые вещи, которые вы могли бы сделать:

  • NAT целевых портов на каждом внешнем IP-адресе на другой набор портов на внутреннем IP-адресе. Например, NAT 192.0.2.1:80 и 192.0.2.1:443 на 198.51.100.1:80 и 198.51.100.1:443, а затем NAT 192.0.2.2:80 и 192.0.2.2:443 на 198.51.100.1:81 и 198.51.100.1:444. Настройте веб-сервер на прослушивание дифференцированных портов для соответствующих служб. Обязательно выберите порты, которые не используются ни для чего другого, и проверьте настройки брандмауэра.
  • Выделите дополнительные внутренние IP-адреса для веб-сервера. Например, выделите веб-серверу 198.51.100.1 и 198.51.100.2. NAT соответствующих внешних пар IP/порт на соответствующие внутренние пары IP/порт (например, 192.0.2.1 на 198.51.100.1 и 192.0.2.2 на 198.51.100.2). Укажите nginx привязать соответствующие службы к соответствующим внутренним IP-адресам.

Если вы выберете последнее решение, ваша среда будет проще и более соответствующей стандартам, поскольку вам не придется иметь дело с необычными номерами портов и трансляцией портов, но вам нужно будет выделить несколько внутренних IP-адресов для каждого веб-сервера (я полагаю, у вас только один). Кроме того, если вы используете последнее решение, вы можете использовать 1:1 NAT.

Тем не менее, если у вас вообще нет причин размещать веб-сервер за NAT (NAT не является брандмауэром), просто прослушивайте внешние IP-адреса (это также потребует изменения топологии).

решение2

Похоже, вам нужен отдельный публичный IP-адрес для каждого сайта. Это означает, что брандмауэр должен предоставить разные публичные IP-адреса. Затем брандмауэр может пересылать запросы на разные IP-адреса на сервер nginx или может пересылать эти запросы на разные порты на одном и том же IP-адресе. Затем вы можете заставить сервер nginx отвечать соответствующим образом.

Как именно вы это настроите, зависит от вашего брандмауэра. Например, используя iptables, вы можете сделать что-то вроде этого в скрипте:

KINCAID=192.168.1.112
EXTIPJMN=50.60.70.80
iptables -t nat -A PREROUTING -d $EXTIPJMN -p tcp -i $EXT --dport 8081 -j DNAT --to-destination $KINCAID:8080

Это будет маршрутизировать запросы, поступающие на IP-адрес EXTIPJMN (50.60.70.80) и порт 8081, на ваш внутренний сервер по IP-адресу KINCAID (192.168.1.112) и порту 8080.

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

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