Тайм-аут доступа веб-администратора Ejabberd

Я только что установил ejabberd на удаленный сервер. Допустим, IP-адрес удаленного сервера — 123.123.123.123, а его внутренний IP-адрес — 10.0.0.10.

Затем я отредактировал:

/etc/ejabberd/ejabberd.cfg

%% ... more codes
%% Options which are set by Debconf and managed by ucf

%% Admin user
{acl, admin, {user, "admin", "myexample.com"}}.

%% Hostname
{hosts, ["myexample.com"]}.

%% ... more codes
{5280, ejabberd_http, [
                         %%{request_handlers,
                         %% [
                         %%  {["pub", "archive"], mod_http_fileserver}
                         %% ]},
                         %%captcha,
                         http_bind,
                         http_poll,
                         web_admin
                        ]}
%% ... more codes

и добавил admin в качестве пользователя-администратора, выполнив следующее в ssh на сервере 123.123.123.123:

root:# ejabberdctl register admin myexample.com adminpassword
root:# service ejabberd restart

ВЕЩИ НЕ РАБОТАЮТ:

Однако консоль администратора myexample.com:5280/admin недоступна (тайм-аут). Я также пытался 123.123.123.123:5280/admin, но потерпел неудачу.

ВЕЩИ РАБОТАЮТ:

Однако с консоли сервера, если я получаю доступ к 10.0.0.10:5280/admin, это работает. Кроме того, я могу подтвердить, что пользователь admin зарегистрирован, выполнив следующее:

ejabberdctl registered_users

ВОПРОС:

Как мне заставить работать доступ веб-администратора (или, что более важно, доступ к любым портам с его внешнего IP-адреса или домена)?


xmpp ejabberd
person J. Berman    schedule 09.02.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Это может быть просто проблема с подключением. Вот что я бы сделал:

  1. 'sudo netstat -nap | grep 5280' (или аналогичный), чтобы проверить, на каких интерфейсах ejabberd прослушивает webadmin

  2. Если он прослушивает «все» (0.0.0.0), как я ожидаю, проверьте его доступность с помощью чего-то вроде «telnet 123.123.123.123 5280». Если он не может подключиться, проверьте брандмауэр сервера (например, «sudo iptables -L -n -v»).

Вероятно, вам просто нужно «открыть» 123.123.123.123:5280 для исходного хоста, с которого вы подключаетесь.

person giavac    schedule 10.02.2014
comment
Спасибо! Порт внешнего ip 5280 был закрыт. Открытие порта просто решило проблему! - person J. Berman; 17.02.2014