Назад | Перейти на главную страницу

Подкаталог обратного прокси-домена на другой хост, обслуживающий то же доменное имя

У меня правильно работает веб-сервер Debian 6.0 со следующей настройкой:

Nginx as front-server listening on the WAN facing interface port 80
    Serving the domain HTTP mydomainame dot org (via reverse proxy to Apache)
    Directly serving and caching static files

Apache as backend-server listening on localhost port 8080 and WAN facing interface port 443
    Serving the domain HTTP mydomainame dot org (behind Nginx reverse proxy)
    Directly serving SSL for HTTPS mydomainame dot org (port 443)

Мне приходится иметь дело с другим сервером, которым я не управляю, который должен обслуживать только HTTPS mydomainame dot org / subdir.

Таким образом, этот внешний сервер должен прослушивать (WAN) порт 443 и обслуживать подкаталог / подкаталог под тем же именем домена (mydomainame dot org).

Обратите внимание, что записи DNS для mydomainame dot org указывают на мой сервер Debian.

Самое первое, что я попробовал, - это настроить Nginx так, чтобы он возвращал прокси любой запрос / subdir на IP-адрес внешнего сервера:

  location ^~ /subdir {
    proxy_pass https://000.000.00.000;
    include /etc/nginx/proxy_subdir.conf;
    error_log /var/log/nginx/mydomainame_subdir.errors.log;
    access_log /var/log/nginx/mydomainame_subdir.access.log;
    expires off;
  }

Затем установите заголовки так:

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header Host "mydomainame dot org";

Что происходит в этом случае, так это то, что внешний сервер возвращает запрос с 301 и перенаправляет на HTTPS mydomainame dot org / subdir, который записи DNS в основном разрешают обратно на мой сервер Debian Apache, прослушивающий порт 443.

Я думаю, это происходит из-за того, что приложение, работающее на внешнем сервере (Magento), перезаписывает base_url на HTTPS mydomainame dot org / subdir, но я не совсем уверен в этом факте.

Итак, браузер попадает на мой сервер, но Apache не настроен для обслуживания / subdir, поэтому, конечно, я получаю 404.

Должен ли я настроить мой Apache, прослушивающий порт 443, чтобы снова обратный прокси-сервер обратно на внешний сервер?

Звучит как хороший способ создать цикл перенаправления, поэтому я немного скептически отношусь к нему.

Я думаю, что проблема на самом деле связана с внешним сервером, но я не совсем уверен, что предложить обслуживающему персоналу этого хоста.

Они тоже используют Nginx, но обслуживают SSL напрямую через порт 443.

Спасибо за любые предложения по поводу этого беспорядка!

Возможно, пора схитрить с перенаправлением портов и IP.

Настройте https на mydomainname dot org: 8443 / subdir в качестве ответа от NGINX. Затем добавьте rinetd в тот ящик, который получит этот ответ, слепо перенаправляя трафик порта 8443 на порт 443 неуправляемого компьютера. (Не забудьте добавить правила брандмауэра, чтобы разрешить прием 8443 в системе (ах) Apache / NGINX.)

Он должен выполнить следующее:

incoming https at mydomainname dot org:443/subdir > 
NGINX rewrite to https at mydomainname dot org:8443/subdir >
incoming https at mydomainname do org:8443/subdir >
NGINX/APACHE rinetd forwards directly to https at notmyserver dot org:443/subdir

Может ли это сработать для вас?

Кроме того, я бы определенно Докажите, что их сторона примет запросы, потому что они уже могут быть правильными с вашей стороны, но не приняты с их стороны. Самый простой способ? Используйте их IP-адрес в URL-вызове и посмотрите, получите ли вы 404 или сайт.

Я бы запустил порт tcpdump 443 на хосте Apache и посмотрел, кто отправляет 404, или настроил бы ваше сообщение 404, чтобы включить какой-нибудь псевдоним, чтобы определить, какой ящик выдает 404. Кроме того, вы доказали конечный пункт назначения https://somehost.org/subdir работает ли вообще на данный момент?