Не работает синхронизация времени через шлюз

[Labaman]

Не работает синхронизация времени через шлюз на Unbuntu. На шлюзе открытый фаервол, заворачивающий трафик через сквид в локалку.
В сquid даже добавил:

Код: [Выделить]

acl Safe_ports 123
Но синхронизация на вмашинах в локалке не проходит. Выдается ошибка:
Возврат из операции произошел из-за превышения времени ожидания
Как с этим бороться? Или проблема в провайдере?

[fisher74]

Проблема в админе.
Если бы Вы внимательно читали документацию на кальмар, то поняли бы, что он умеет только http(s).

Что мешает настроить ntp-сервер на этой же машине?

[Labaman]

Проблема в админе.
Если бы Вы внимательно читали документацию на кальмар, то поняли бы, что он умеет только http(s).

Что мешает настроить ntp-сервер на этой же машине?

Safe ports это, вроде как порты, которые сквид не обрабатывает (по крайней мере в базовом варианте конфига, на основе которого я и писал свой конфиг).
NTPD поднять, конечно, мысль, но хотелось бы понять почему не работает "как есть".

[AnrDaemon]

Потому что вы не читали документацию.

[Labaman]

Ладно, немного не точно сформировал мысль: добавил safe_ports для NTP чтобы точно быть уверенным, что не блочится правилом

Код: [Выделить]

http_acess deny !Safe_portsПонимаю, что по-идее прозрачный прокси не должен мешать процессу синхронизации времени, но...
На шлюзе открытый фаерволл.
Из работающих служб только dns, dhcp и squid.
Что может блочить NTPD и почему это происходит предположить даже...

[fisher74]

Что есть "открытый фаерволл"? И если Вы понимаете, то зачем вообще кальмара приплетаете?

[koshev]

Понимаю, что по-идее прозрачный прокси не должен мешать процессу синхронизации времени, но...
На шлюзе открытый фаерволл.
Из работающих служб только dns, dhcp и squid.
Что может блочить NTPD и почему это происходит предположить даже...

Вы издеваетесь? 0.о
Я буду третьим, кто предложил прочитать документацию на прикси-сервер. Хотя бы первое предложение!

[MooSE]

Squid работает только с HTTP. Safe_ports указывает на какие порты squid может пропускать трафик, но пропускать он будет всё равно только http (ну т.е. это пригодится если надо ходить на http-сервера, работающие на нестандартных портах).

Для всех остальных протоколов (включая NTP) надо поднимать NAT.

[AnrDaemon]

MooSE, https://ru.wikipedia.org/wiki/Медвежья_услуга

[fisher74]

Для всех остальных протоколов (включая NTP) надо поднимать NAT.

Для NTP всегда поднимали свой сервер, тем более что он на столько мало потребляет ресурсов, что его фактически не стали разделять на сервер и клиент.
Можно и NAT, но это плохой тон админа.

[AnrDaemon]

На счёт ната и плохого тона можно поспорить…
А на счёт своего NTP соглашусь. 5 секунд работы и никаких проблем.

[fisher74]

Я имел ввиду NAT ради NTP.
Но если NAT уже есть, то можно и NTP разрешить, но ИМХО лучше локальный.
Иногда весьма полезно иметь единое время для предприятия. Даже если интернет упал (длительная авария на стороне провайдера и т.д.), то время всё равно будет одинаковое. Вот это и есть "хороший тон"

[AnrDaemon]

То да. (И если интернет ВНЕЗАПНО появится, время не скакнёт.)

[MooSE]

MooSE, https://ru.wikipedia.org/wiki/Медвежья_услуга

Честно говоря не понимаю почему желание помочь вы считаете медвежей услугой.

Полторы страницы все отправляли человека читать документацию и никто не подсказал хотя бы направления поисков. А как только кто-то подсказал направление - сразу "медвежья услуга".

[fisher74]

Полторы страницы все отправляли человека читать документацию и никто не подсказал хотя бы направления поисков.

Как это не подсказывали?
А это что?

то поняли бы, что он умеет только http(s).

Вариант решения был озвучен в том же, первом ответном сообщении.