LINUX.ORG.RU
ФорумAdmin

Bind, но не бинд.

 , ,


0

1

Привет.

Help me please.

Суть.

Есть внешний сервер с белым ip. Надо без доменного имени организовать что-то типа dyndns.

Может ли такое bind? Или может есть провереный метод другой?

В основном это нужно для каких-то своих ssh, sftp умных вещей. Там адреса динамические.

Чужих сервисов не хочу, зачем, есть же свой сервер.

без доменного имени

Мнэээ. Вот этого не понял. Ты хочешь ресолвить днс-запросы, не имея доменного имени? Это будет какое-то сугубо личное хозяйство, не расчитанное на внешних клиентов?

thesis ★★★★★ ()
Последнее исправление: thesis (всего исправлений: 1)
Ответ на: комментарий от thesis

Да. Для себя. Для своих родных, близких, друзей. Ip-шник вводить никого не ломает.

Ищу простой вариант.

По сути я хочу с помощью внешнего сервера входить на свои устройства имеющие динамисеские адреса. В идеале. Ну. Или хотя бы видеть их ip-шники там.

uriukti ()
Последнее исправление: uriukti (всего исправлений: 2)
Ответ на: комментарий от uriukti

То есть у тебя получается днс-сервер вне глобальной доменной системы. Ну и захапай любое имя, которое тебе по вкусу, создай зону в бинде, сгенери ключ[и] для клиентов и пусть они регистрируются сколько влезет. Задача сводится к тому, как прикрутить скрипт динамического обновления к событию смены айпишника, ну и собственно man nsupdate или что-то еще. Можно на крон повесить раз в минуту запрашивать у днс-сервера собственное имя, и если возвращенный айпишник не совпал с реальным, инициировать апдейт. Я так делал.

thesis ★★★★★ ()
Ответ на: комментарий от bhfq

Оно что, позволяет узнать заранее известный айпишник? Какой полезный сервис.

thesis ★★★★★ ()
Ответ на: комментарий от thesis

Вообще в идеале я бы хотел именно методом bind-а. Так как он по идее как-то так должен работать. Это его задача. Но. Я с ним никогда не работал. И мозг кипит. Не могу понять, что мне вообще нужно для этой задачи. Если только bind, на сервере, и больше ничего, то супер. Я думал вообще что… Ставлю на сервер bind. Настраиваю его так, чтобы он не пытался приклеить внешнее доменное имя, а работал с ip-шником сервера вместо имени. Но при подключении к нему моих устройств он выдаёт им какие-то идентификаторы. Хоть цифровые, хоть именные, мне не важно. То есть, мне бы для входа в удалённый комп или какой-то гаджет по ssh, sftp пришлось бы вводить условно - blabla.236.345.45.98:654 А на устройстве в кроне какой-то скрипт, который просто 1 раз в минуту или 5 минут, стучится на сервер. И сервер опознаёт его как-то. Или по имени, которое транслирует гаджет, или по mac, или по ключу. И в случае если ip-шник изменился, то в этой общей системе новый ip-шник обновляется в bind для этого устройства.

В идеале хотелось бы так, я догадываюсь, что это возможно…но как это всё сделать нифига опыта нету. Первый раз вообще подхожу к этой задаче. И вот думаю, может есть уже готовые настройки такие? О которых все знают, а я пока ещё нет.

uriukti ()
Последнее исправление: uriukti (всего исправлений: 1)
Ответ на: комментарий от thesis

А может подскажешь, как так можно это настроить в bind-е, точнее что настраивать и как. Вообще не пойму, что читать, как, с какой стороны подойти к этой программе. Смотреть то, что относится к стандартным настройкам bind? Там, как я понял для настройки 2-3 файла? А если да, то как изменить, чтобы он не лез в доменные внешние зоны, а просто всё делал как обычно, но только с ip-шником сервера? Хотя бы намекни…я дальше почитаю, разберусь…

uriukti ()
Ответ на: комментарий от uriukti

Ну вот для дебианов: https://wiki.debian.org/DDNS

Не уверен в актуальности, но надеюсь все ок. Обратную зону (которая zone «2.168.192.in-addr.arpa» и т.д.) и все, что с ней связано, создавать не нужно. И там странное что-то про пути к файлам зон, какие-то симлинки... В дебианах зоны по умолчанию не в /etc, и нечего их туда костылить.

DHCPшную часть пропускаем, само собой. Как запустишь бинд, проверяй nsupdate'ом (примеры в мане) и смотри в лог named'а. В случае успеха около файла зон появляется файл журнала апдейтов zonename.jnl, для его просмотра есть named-journalprint.

thesis ★★★★★ ()
Ответ на: комментарий от thesis

Спасибо, thesis. Круто вот так немного знать, куда лезть и не лезть. Буду разбираться и делать. Потом продолжу тут.

uriukti ()
Ответ на: комментарий от uriukti

Но при подключении к нему моих устройств он выдаёт им какие-то идентификаторы. Хоть цифровые, хоть именные, мне не важно.

Смотри, тебе плевать на весь интернет, поэтому ты хмуро берешь любое понравившееся имя второго уровня, например uriukti.lan, создаешь соответствующую зону, создаешь ключ и разрешаешь с этим ключом обновлять эту зону. А на системы-клиенты вешаешь скрипты, отличающиеся лишь в части имени хоста, которое они будут сообщать в команде динамического обновления (nsupdate или что найдешь). То есть приходит виртуалка условно именуемая myvm1, и говорит что-то вроде «удалить из зоны uriukti.lan хост myvm1; добавить в зону uriukti.lan хост myvm1 с айпишником <новый айпишник>».

thesis ★★★★★ ()
Ответ на: комментарий от thesis

Понял. А как потом мне заходить на myvm1 со стороны? Оно всё будет правильно таким образом работать на внешнем (dns) сервере как я понял. Но как писать снаружи, чтобы попасть через этот dns сервер на нужное из устройств? Например на myvm1? Или имеется ввиду вхожу по ssh на dns сервер по его ip, а там уже на myvm1.uriukti.lan? Или по другому? Вот это пока не ясно. А если напрямую, то как это будет выглядеть? Вникаю в bind и вроде уже начинаю понимать кое чего. Про зоны уже вроде немного понимаю.

uriukti ()
Последнее исправление: uriukti (всего исправлений: 1)
Ответ на: комментарий от thesis

С клиентом вроде ясно. Он смотрит свой публичный ip и в случае не совпадения делает запрос на dns для изменения ip.

uriukti ()
Ответ на: комментарий от uriukti

Аааага. «Попасть через» это отдельная задача, с DNS не связанная. Если динамические айпишники белые, то клиент попадет куда надо, если серые - то ой, надо городить VPN и забывать все, что написано раньше.

thesis ★★★★★ ()
Ответ на: комментарий от thesis

Не. Динамические белые во всех местах. В принципе зная эти айпишники можно по ssh напрямую зайти. Но меняются зараза. Я сначала отправлял их на почту. Но так устаёшь.

Пользовался и внешними dyndns, но они совершенно не вовремя начинают отказывать в работе.

uriukti ()
Последнее исправление: uriukti (всего исправлений: 1)
Ответ на: комментарий от thesis

Не совсем это понял. Просто пока толком не знаю как оно всё работает не могу видимо все вопросы корректно задать. Ведь доменного имени не будет зарегестрированного. Только своё, внутри сервера. Зона. А значит в этот сервер зайти, а так же перейти на любое из подключеных к нему клиентов я смогу только по ip сервера? Или может я не понимаю что-то?

uriukti ()
Ответ на: комментарий от uriukti

Ну раз ты не входишь в общеинтернетную систему доменных имен, то да, по-простому не выйдет. Есть несколько путей разной степени неудобства.

Например, всякий, кто ищет какой-либо из твоих динамический айпишников, будет вынужден выполнять вручную запрос к бинду (dig, nslookup или что-то еще) и потом обращаться к полученному айпишнику. Это не сильно удобнее отправки айпишников в почту.

Либо ты разрешишь своему бинду форвардить все запросы, после сам станешь использовать его как основной днс-сервер во всех своих системах и системах тех, кому ты захочешь бросить ссылку на какой-то из хостов с динамическими айпишниками (а никто этого не хочет).

Либо ты городишь нормальную VPN-сеть с отдельным внутренним диапазоном адресов, запихиваешь всех друзей и виртуалки в нее и вы там живете как вам нравится. Собственно, VPN примерно для этого и придуманы.

Самое простое и умное - таки встроиться глобальную систему имен, т.е. купить доменное имя наподобие mycoolname.com и обслуживать эту зону со своего бинда, и регистрировать туда все принадлежащее тебе хозяйство. И тогда весь мир будет ресолвить ссылки на твои хосты удобно и прозрачно.

Есть чуваки, раздающие доменные имена на халяву, но я не понимаю их мотивации и советовать не могу. Может быть, они через годика два отбирают такое имя и ты оказываешься вынужден выкупать его втридорога, я не знаю.

thesis ★★★★★ ()
Ответ на: комментарий от voltmod

Чуть позже придётся доделывать. Но как всё будет готово отпишусь тут. Это моя традиция. Спасибо за советы.

uriukti ()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.