Мне было поручено заставить клиента NTP работать на двух машинах Linux и машине OpenBSD.
Машины устроены так:
NTPServer
/ \
/ \
L1 L2
\ /
\ /
OpenBSD
Мне сказали настроить L1 и L2 для маршрутизации пакетов от OpenBSD к NTPServer (т.е. не создавать новый слой). Окно OpenBSD не может видеть NTPServer (т.е. конфигурация сети запрещает это - из окна OpenBSD я не могу даже пропинговать IP-адрес NTPServer).
А теперь плохие новости: я программист J2EE :) Я не очень понимаю, как действовать дальше.
С чего бы мне начать? Я не ищу полного решения, поскольку, очевидно, люди не знают конфигурации сети, просто несколько указателей, с чего начать. Я довольно хорошо знаю Linux с точки зрения того, что связано с J2EE (установка Tomcat / JBoss, настройка их как сервисов и т. Д.), Но сетевая маршрутизация действительно для меня очень нова и всегда пугала меня (с тех пор, как мне пришлось писать код Java для обнаружения переворота BGP).
Хорошо, благодаря Google я добился некоторого прогресса. Все вышесказанное неверно (не считая того, что я программист J2EE) ...
С использованием ifconfig, routes show, tracerouteи некоторая внутренняя документация, теперь у меня есть следующая диаграмма:
NTP
10.21.3.169
| \______________
| \
10.21.3.160 (eth1) |
L1 |
10.0.0.67 (eth0) |
| |
| |
10.0.0.65 (pcn1) |
OpenBSD |
10.0.0.51 (pcn0) |
| |
| |
10.0.0.49 (eth1) 10.21.3.159 (eth0)
L2
Я также проверил время на трех машинах, и Linux верен, в то время как OpenBSD неверен, поэтому я думаю, что мне просто нужно отсортировать маршрутизацию, чтобы окно OpenBSD могло получать время от NTP через любой из Ящики Linux.
Итак, я думаю, мне нужно добавить маршрут в окно OpenBSD, чтобы сообщить ему, что для доступа к нашему NTP-серверу он должен пройти через L1 (он также может пройти через L2, но диаграмма, которую я видел, делает это неверным).
Ваши комментарии выше имеют смысл. Но если это так, то я бы действительно сильно посоветуйте своему работодателю пересмотреть свою позицию по NTP в отношении Linux-боксов.
Я не думаю, что наличие у этих ящиков должным образом привязанных клиентов NTP менее безопасно, чем наличие у них должным образом привязанных маршрутизаторов. Я почти уверен, что неправильно привязанные клиенты NTP более безопасны, чем маршрутизаторы, администрируемые кем-то, кто не знает, как найти IP-адрес: с плохо привязанными клиентами NTP вы можете повлиять на системные часы; с плохо настроенным маршрутизатором вы можете атаковать всю сеть.
Пожалуйста, не принимайте это на свой счет. Это не должно быть личным: ваши работодатели были бы в еще большей опасности, если бы я, парень, занимающийся сетью и брандмауэрами, написал их код J2EE. Я бы повсюду совершал элементарные ошибки в программировании, вводя потенциальные переполнения буфера и дескрипторы для атак SQL-инъекций и в целом разрушая их жизнь. Это потому, что я некомпетентен как таковой? Нет - это потому, что мне сказали сделать то, что я понятия не имею, как это сделать, в критически важной для безопасности среде.
Есть старая цитата Папы,
За формы правления пусть дураки соревнуются
Что лучше всего вводить, лучше всего
что, я думаю, также применимо к технологиям. Если вам так неудобно работать с сетями, это, вероятно, не лучшее место для начала обучения с нуля (и один ответ serverfault не заменит надлежащего курса IP). По крайней мере, если ваши работодатели настаивают на том, чтобы вы решили эту проблему с помощью маршрутизации, заставьте их подписать что-нибудь, что освобождает вас от любых последствий неправильной настройки маршрутизаторов; посмотрите, сосредоточит ли это их умы на ошибке, которую они собираются совершить.