На сервере, выполненном ssh демон на другом порте с включенной отладкой, и подключение к нему с ssh клиентом с подробным флагом. Как в:
sshd -ddd -p 2222
И на клиенте (server1) попытка:
ssh -vvv -p 2222 server2
Это - типичный первый шаг, если у Вас нет некоторых других данных для запуска с. Если бы это не помогает (не дает дальнейший ключ к разгадке), я попробовал бы strace или ltrace против нормального sshd на server2.
Удачи.
Общая процедура здесь должна быть должна устранить классы проблем для сужения вещей, как с любым поиском и устранением неисправностей. Первоначально, я думал, что Ваш вопрос был характерен для ssh (конкретно OpenSSH на Linux), и проверка, что сообщения отладки являются допустимым первым шагом, если у Вас есть ssh проблема между 2 хостами.
Однако Вы упомянули, что другие приложения между этими двумя полями не работают, что означает, что это не специализированная проблема. OpenSSH, отлаживающий, мог бы помочь, но будет стоящим предположить, что существует что-то, что это характерно для всех этих протоколов (сеть), который имеет проблему. Кроме того, Вы говорите, что третий сервер может достигнуть server2... так, чтобы устранил огромное количество потенциальных проблем.
Мое лучшее предположение в данный момент, на основе таймаута соединения и другой информации, что у Вас есть iptables проблема или на сервере или на клиенте, что-то набор для ОТБРАСЫВАНИЯ пакетов, исходящих от клиента или поступающих на сервере, но только от того поля и не других. Мне создает помехи мое незнание APF по этому вопросу, я просто использую запас iptables.
Если iptables полностью отключен (с цепочечным сбросом политик для ПРИНЯТИЯ), то необходимо предположить, что это - более универсальная сетевая проблема. Я спросил о сетевой маске, потому что я думал о подобных проблемах, которые я видел в удаленном прошлом, где поля на различных подсетях могли говорить, но на той же подсети не работали. Если "server3" находится в другой сети и может все еще достигнуть server1 и server2, то это не проблема маршрутизации.
Независимо от того, что ответ здесь, мне любопытно.
Один из моих коллег указал, что уже существует параллельная утилита для nslookup под названием nsupdate ( см. Это короткое введение ). Для меня это кажется идеальным решением, поскольку оно требует минимальных требований к настройке и обслуживанию. Для этого требуется больше "технических" пользователей из-за интерфейса командной строки, но в моем случае это не проблема.
Вы можете использовать MySQL (или аналогичную БД) в качестве бэкэнда и разработать приятный веб-интерфейс для разрешения записи и изменения зоны.
Я не пробовал бэкэнд MySQL для bind, но серверы MySQL MyDNS и PowerDNS работают отлично.
GOSa имеет довольно обширные настройки ACL, позволяющие делегировать привилегии, строгую аутентификацию, политику паролей и устаревание. Это' s используется в основном для администрирования и редактирования LDAP, но помимо прочего имеет плагины для DNS. Вы можете проверить это.
И вы можете использовать его с Bind или PowerDNS. Существуют исправления для Bind, которые позволяют ему работать с LDAP, и сценарии для восстановления файлов зоны. PowerDNS имеет встроенную поддержку серверной части LDAP.