OSX Server 3, клиенты Mac связываются с OD и не работают диспетчера профилей

Я сделал установку, содержащую Mac Mini с OSX Server 3 (Mavericks 10.9.2), используя Open Directory и Profile Manager (Mail и т. Д. Все настроено и работает).

Теперь дело в том, что внутри локальной сети все прекрасно работает. Клиенты могут связываться с OD, а пользователи могут войти в систему. Я могу установить профили доверия и настройки (пользовательские или групповые), и все службы в указанных профилях настраиваются правильно. Я могу входить и выходить, ходить и делать это 100 раз на разных компьютерах с разными пользователями, это работает.

Моя цель - сделать эту услугу публичной. Домен с полным доменным именем, которым я владею, скажем для простоты server.domain.com, Теперь для меня единственный способ привязать клиентов к OD - использовать отображение LDAP. RCF2307 (без SSL) и суффикс DN dc=server,dc=domain,dc=com используя утилиту каталогов. Варианты from server, или же open directory выдаст несколько ошибок вроде Connection failed to node '/LDAPv3/server.domain.com (2100),

Прежде всего, я не совсем понимаю проблему, почему клиенты не могут связываться с OD, как это происходит локально, с и без SSL (все порты открыты, буквально все порты открыты, не только 389 636 и 1640, не было уверен, если я что-то пропустил).

Когда клиенты используют привязку LDAP RFC2307 для привязки (только без SSL), клиенты могут проходить проверку подлинности, входить в систему и даже загружать профиль доверия. Но каждый профиль настроек потерпит неудачу с Debug Message: Unable to find GUID in user record OD или не удается установить поговорку missing user identification,

Есть ли способ заставить это работать без RFC2307? Потому что при использовании чего-то не хватает RFC2307 и не тянуть отображение с сервера или использовать open directory,

Возможна ли такая настройка? Или я должен использовать VPN для аутентификации с OD?

Настройка сети - модем / маршрутизатор (DHCP выключен) с WAN NAT, установленным в Airport Extreme (с использованием DHCP+NAT). AE уведомляет с double NAT сообщение, но у меня не было проблем с ним на любом другом сервисе. Итак WAN -> 192.168.2.220 (статический), AE -> 10.0.1.* (Dhcp)

Вывод DIG извне с помощью dig server.domain.com

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;server.domain.com.     IN  A
;; ANSWER SECTION:
server.domain.com. 77   IN  A   91.50.*.* (valid WAN IP)
;; SERVER 172.*.*.1#53(172.*.*.1) (iPhone)

DIG локально с клиента и сервера (один и тот же вывод)

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;server.domain.com. IN  A
;; ANSWER SECTION:
server.domain.com. 10800    IN  A   10.0.1.11
;; AUTHORITY SECTION:
server.domain.com. 10800    IN  NS  domain.com. (used for email send in relay)
server.domain.com. 10800    IN  NS  server.domain.com.
;; SERVER 10.0.1.11#53(10.0.1.11)

Есть ли вещи, которые я должен проверить? Есть только OSX.

-двойная проблема NAT, подключенная к серверу непосредственно на модеме / маршрутизаторе со статическим IP и проблема остается. Угадайте, что исключает двойную NAT вещь.

-changeip -checkhostname поставляется с Здесь нечего менять, например, успех.

Primary address     = 10.0.1.11
Current HostName    = server.domain.com
DNS HostName        = server.domain.com

На данный момент я сделал обходной путь, используя учетную запись администратора, которая заставляет постоянное VPN-соединение при загрузке. Это означает, что до входа в систему соединение уже установлено или выполняется.

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

Unless, of course, I get sidetracked with having a life. Which is arguably 
not very likely.       
                                                               krypted.com