SecAst: преждевременный выход в режиме демона
Я в чем-то вроде потери... и имею большой красный флаг для помахивания Вам..., если Ваша школа не ВЛАДЕЕТ 140,140 блоками и 130,130 блоками... можно закончить с некоторыми довольно огромными штрафами и судебными процессами, если присоединено к общедоступному Интернету. Существует только 3 блока, зарезервированные для частного выделения, 192.168.0.0 - 192.168.255.255, 10.0.0.0 - 10.255.255.255, и 172.16.0.0 - 172.31.255.255.
140.140.x.x (754-я Electronic Systems Group - американские Вооруженные силы) и 130.130.x.x (Университет Уоллонгонга - Austrailia) оба принадлежат людям в общедоступном Интернете.
... это сказанное. Вот то, о чем я в замешательстве. Какие адреса выпущены к фактическим конечным точкам? они добираются 140.140.x.x адреса? и раз так..., почему Вы - NAT'ing внутренне? Эти две сети должны смочь направить непосредственно друг между другом. Каждый хостел должен иметь маршрутизатор своего собственного трафика направления друг между другом или 1 большой центральный маршрутизатор, где они все встречаются. Необходимо только быть нужно к NAT, если у Вас есть недостаточные общедоступные IP-адреса для конечных точек для соединения с общедоступным Интернетом.
SecAst останавливается, потому что он получает сигнал HUP от Linux, обратите внимание на строку в вашем журнале:
2014-06-25T15:14:45, 00000102, I, General, Received shutdown request via HUP signal
Приложения должны завершиться при получении сигнала HUP. Итак, вопрос в том, почему SecAst получает сигнал HUP.
Скорее всего, SecAst получил запрос на завершение работы от служебного сценария secast init.d (он использует сигнал HUP, чтобы сообщить исполняемому файлу SecAst о правильном завершении работы). Есть ли шанс, что вы / кто-то / cron / и т. Д. Отправили «остановку обслуживания»? Проверьте свой системный журнал - есть ли записи из сценария инициализации SecAst?