Ошибка регистрации устройства OS X MDM с прокси-сервером Nginx

Я в своем уме пытаюсь настроить nginx в качестве прозрачного прокси-сервера для моего сервера OS X (в виртуальном боксе), на котором запущена наша служба mdm. Без nginx в миксе сервер mdm работает правильно, и я могу выполнять удаленную регистрацию устройств и управление ими, но я размещаю несколько серверов в одной сети и должен иметь возможность проксировать несколько IP-адресов и портов с помощью nginx.

Настройка без nginx: я использую внешний DNS для своего полного доменного имени, mdm.servername.com, который правильно разрешается в мой общедоступный IP-адрес. Мой брандмауэр успешно перенаправляет порты 443 и 1640 на мой сервер mdm с частным IP-адресом 10.0.1.60. У меня отключен DNS сервера OS X, и я также использую mdm.servername.com в качестве имени хоста OS Server. Я установил для mdm.servername.com разрешение 127.0.0.1 в /etc/hosts для создания открытого каталога, а затем удалил эту запись из /etc/hosts. Не знаю, является ли это одной из проблем. Я могу получить доступ к http://mdm.servername.com/mydevices из-за пределов сети и зарегистрировать свои айпад без проблем. Все работает правильно, пока я не представлю nginx.

Настройка с помощью nginx: снова используется внешний DNS для моего полного доменного имени, mdm.servername.com. У меня nginx работает на частном ip 10.0.1.50, и я перенаправляю порты 443 и 1640 на 10.0.1.50. У меня есть сервер OS X mdm, работающий на ip 10.0.1.50. Сервер mdm отключил DNS, и сервер mdm также использует mdm.servername.com в качестве имени хоста ОС. Я по-прежнему могу получить доступ к веб-сайту mdm (https://mdm.servername.com/mydevices), Я могу установить профиль доверия без каких-либо проблем, но когда я пытаюсь зарегистрировать свой iPad из-за пределов сети, он успешно «регистрирует сертификат», но при «установке профиля» время ожидания истекает. Я вижу прогресс вызовов API в журналах доступа nginx:

Доступ Nginx.log

173.171.23.81 - - [16/Nov/2013:19:56:47 -0500] "GET /scep/?operation=GetCACert&message=Device%20Management%20Identity%20Certificate HTTP/1.1" 200 1126 "-" "profiled/1.0 CFNetwork/672.0.8 Darwin/14.0.0"
173.171.23.81 - - [16/Nov/2013:19:56:48 -0500] "GET /scep/?operation=GetCACaps&message=Device%20Management%20Identity%20Certificate HTTP/1.1" 200 52 "-" "profiled/1.0 CFNetwork/672.0.8 Darwin/14.0.0"
173.171.23.81 - - [16/Nov/2013:19:56:49 -0500] "POST /scep/?operation=PKIOperation HTTP/1.1" 200 3046 "-" "profiled/1.0 CFNetwork/672.0.8 Darwin/14.0.0"
173.171.23.81 - - [16/Nov/2013:19:58:20 -0500] "PUT /devicemanagement/api/device/mdm_checkin HTTP/1.1" 504 191 "-" "MDM/1.0"

Ошибка 504 в PUT возникает примерно через 30 секунд после того, как iPad уже сообщает об ошибке установки профиля.

Ошибка Nginx.log

2013/11/16 19:58:20 [error] 7983#0: *10 upstream timed out (110: Connection timed out) while reading response header from upstream, client: xxx.xxx.xx.xx, server: mdm.servername.com, request: "PUT /devicemanagement/api/device/mdm_checkin HTTP/1.1", upstream: "https://10.0.1.60:443/devicemanagement/api/device/mdm_checkin", host: "mdm.servername.com"

Таким образом, nginx сообщает о тайм-ауте при разговоре с сервером mdm для действия PUT checkin...

На сервере MDM журналы Apache указывают на ошибки подключения, а также Apache access_log.

mdm.servername.com 10.0.1.50 - - [16/Nov/2013:19:56:47 -0500] "PUT /devicemanagement/api/device/mdm_checkin HTTP/1.0" 403 - "-" "MDM/1.0"

Apache error_log

[Sat Nov 16 19:56:22 2013] [error] (61)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:3328 (127.0.0.1) failed
[Sat Nov 16 19:56:22 2013] [error] ap_proxy_connect_backend disabling worker for (127.0.0.1)
[Sat Nov 16 19:56:22 2013] [error] (61)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:3329 (127.0.0.1) failed
[Sat Nov 16 19:56:22 2013] [error] ap_proxy_connect_backend disabling worker for (127.0.0.1)
[Sat Nov 16 19:56:22 2013] [error] (61)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:3327 (127.0.0.1) failed
[Sat Nov 16 19:56:22 2013] [error] ap_proxy_connect_backend disabling worker for (127.0.0.1)
[Sat Nov 16 19:56:22 2013] [error] (61)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:3325 (127.0.0.1) failed
[Sat Nov 16 19:56:22 2013] [error] ap_proxy_connect_backend disabling worker for (127.0.0.1)
[Sat Nov 16 19:56:22 2013] [error] (61)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:3326 (127.0.0.1) failed
[Sat Nov 16 19:56:22 2013] [error] ap_proxy_connect_backend disabling worker for (127.0.0.1)
[Sat Nov 16 19:56:22 2013] [error] (61)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:3324 (127.0.0.1) failed
[Sat Nov 16 19:56:22 2013] [error] ap_proxy_connect_backend disabling worker for (127.0.0.1)
[Sat Nov 16 19:56:22 2013] [error] (61)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:3322 (127.0.0.1) failed
[Sat Nov 16 19:56:22 2013] [error] ap_proxy_connect_backend disabling worker for (127.0.0.1)
[Sat Nov 16 19:56:22 2013] [error] (61)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:3323 (127.0.0.1) failed
[Sat Nov 16 19:56:22 2013] [error] ap_proxy_connect_backend disabling worker for (127.0.0.1)
[Sat Nov 16 19:58:17 2013] [error] [client 10.0.1.50] Re-negotiation handshake failed: Not accepted by client!?

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

Конфигурация Nginx:

user www-data;
worker_processes 4;
pid /run/nginx.pid;

events {
  worker_connections 768;
}

http {
  tcp_nopush on;
  tcp_nodelay on;
  keepalive_timeout 65;

  types_hash_max_size 4096;
  default_type application/octet-stream;

  ssl_certificate /etc/nginx/ssl/servername.com/_.servername.com.combined.crt;
  ssl_certificate_key /etc/nginx/ssl/servername.com/_.servername.com.key;

  access_log /var/log/nginx/access.log;
  error_log /var/log/nginx/error.log;

  gzip on;
  gzip_disable "msie6";

  server {
    listen 443 ssl;
    listen 1640;

    server_name mdm.servername.com;

    location / {
      proxy_pass $scheme://10.0.1.60:$server_port$request_uri;

      sendfile off;

      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_max_temp_file_size 0;

      #this is the maximum upload size
      client_max_body_size 10m;
      client_body_buffer_size 128k;

      proxy_connect_timeout 90;
      proxy_send_timeout 90;
      proxy_read_timeout 90;

      proxy_buffer_size 4k;
      proxy_buffers 4 32k;
      proxy_busy_buffers_size 64k;
      proxy_temp_file_write_size 64k;
    }
  }
}

Дополнительная информация: у меня есть подстановочный сертификат ssl от go daddy, который nginx использует для ssl, и я также использую его для сервера веб-сайтов на OS X Server. Я использую промежуточный сертификат, который сервер генерирует для подписи профиля конфигурации.

Заранее благодарим за любую помощь, которую вы можете предоставить.


person Tommy Adamski    schedule 17.11.2013    source источник


Ответы (1)


Я получал те же ошибки, что и вы, о бэкэнд-работниках и до сих пор получаю.

Прошлой ночью я разговаривал с архитектором решений Apple, который считает, что проксирование Profile Manager никогда не сработает.

По-видимому, рекомендуемым решением является устройство безопасности CISCO, которое перенаправляет порты на ProfileManager в DMZ. Он предположил, что SSL подумает, что Nginx был посредником в атаке, а ошибки PHP были отвлекающим маневром. Он также порекомендовал мне проверить http://twocanoes.com/push-diagnostics. Это £ 2,99, и я определенно рекомендую это.

Сегодня регистрация все еще не удалась - не могу сохранить сертификат центра сертификации, однако есть надежда.

Подключите ваше устройство iOS к вашему Mac или ПК с помощью утилиты настройки iPhone.

Взгляните на консоль, найдите, где начинается ошибка: «Невозможно вставить в Sqlite, невозможно дублировать». Проверено, что на iPad не установлены профили или сертификаты — ничего не установлено.

Протер iPad, нажал кнопку регистрации и, эй, эй, он зарегистрировался.

iPad правильно отображался в разделе «Использование профиля регистрации» и на устройствах со всей правильной информацией. Когда я уходил, ProfileManger нажимал профиль. Кажется, я помню, что читал что-то о возможности удалить профиль регистрации с iPad, но на самом деле он никогда не удаляется!

Чтобы заставить его работать Получите утилиту Push-диагностики Я разделил 1640 из блока сервера на отдельный блок, пытаясь сделать прокси как можно более прозрачным. Очистить iPad Зарегистрироваться

Счастливые дни.

С уважением

Стивен

person Steve    schedule 21.11.2013