LINUX.ORG.RU
ФорумAdmin

Присваивание постоянного ip сетевой карте на которой работает DHCP сервер

 , ,


0

1

Прошу помощи, есть сетевая карта, настройки в netplan(е).

Она имеет постоянный IP, но он ей назначается только тогда, когда эта сетевая карта физически соединяется с другой картой другого компьютера.

Если, компы разъединить, выдернуть провод, ребутнуть первый комп, то его сетевая карта теряет статический IP и следовательно DHCP-сервер не может стартануть, поскольку ругается на то, что ни один сетевой интерфейс не настроен.

Получается, что для того, чтобы DHCP-сервер на первом компе запустился сначала надо их соединить проводом, затем включить второй (ведомый) компьютер, а только затем первый.

Не понимаю, как это работает. Можете объяснить?

Я так, понимаю, что DHCP-сервер на первом компе должен запуститься автоматически, даже если его сетевая карта физически ещё не соединена со вторым компом. То есть, сетевая карта первого компа при его старте должна получить свой статический IP в любом случае, подключён от неё провод куда-либо или нет, вслед за ней должен подняться DHCP, и, далее сетевая карта и dhcp-сервис должны находиться в режиме ожидания клиента в локальной сети.

Или я всё неправильно понимаю?


Ответ на: комментарий от ofp

isc-dhcp-server.

Все стандартно, я много чего пересмотрел, но грешить на него нет никакого смысла:

#option domain-name «localhost.localdomain»;

option domain-name-servers 8.8.4.4, 8.8.8.8;

default-lease-time 32400;

max-lease-time 604800;

log-facility local7;

autoritative;

subnet 172.30.0.0 netmask 255.255.255.0 {

range 172.30.0.4 172.30.0.6;

option routers 172.30.0.1;

option subnet-mask 255.255.255.0;

option broadcast-address 172.30.0.255;

}

Резервирование постоянного IP-адреса для (Asus) mvt-1215N:

host mvt-1215N {

hardware ethernet f4:6d:04:5b:a6:8f;

fixed-address 172.30.0.2;

}

mvt
() автор топика
Ответ на: комментарий от Anoxemian

естественно

Я только одну систему видел, для которой такое поведение естественно (и она принудительно дропала tcp-коннекты при потере линка), но кажется в версиях поновее это исправили (а может и нет). Угадай какую.

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

принудительно дропала tcp-коннекты при потере линка

Заинтриговал, жги. Алсо, тут вопрос в неподнятии сетевых служб со старта. Потеря линка - это другой случай.

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

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

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

На нормальных системах tcp-коннекты работают штатным образом вне зависимости от наличия каких бы то ни было линков. То есть завершаются либо по команде от приложения, либо по таймауту. Ну да, если линка нет, то пакет прийти не сможет и спустя какое-то время коннект отвалится, но само по себе отсутствие линка ни на что не повлияет. В частности, если через коннект никто ничего не пытается слать, и у него не включено keep-alive, то он и без линка будет жить вечно, т.к. такому коннекту надобности в пересылке пакетов нет.

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

В моем понимании - это ожидаемое поведение системы. Очевидно, если система запускается без сетевого оборудовая, то и не надо запускать никакие связанные службы. В онтопике это все скорее всего завязано на инит. Можно, конечно, поднять виртуальный интерфейс и запускать службы, но то такое, на дефолт не тянет. Я, собственно, угадал проблему ТС именно из этих соображений, независимо от дистрибутива и инита.

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

«соединения» штука вообще эфимерная. Т.е на самом деле никаких соединений не существует. Есть модуль ядра, который следит за тем куда какие пакеты отправились и откуда какие вернулись, на основании этих последовательностей он изображает «соединения» и заносит их в свою табличку. Вот эту табличку ты и смотришь, когда «видишь соединения». Задача модуля - держать таблицу в актуальном состоянии, и правильно класифицировать по «соединениям» все пакеты. Соотвественно если линк упал, можно… нужно все записи о соединениях привязаных к этому линку из таблицы вычистить, а всем службам разослать что конектион лост, завязывайте со «слать и слушать» т.к после падения линка очевидно соединения прервались и это новое актуальное состояние системы. Если модуль так не делает, значит хреновый модуль, и его таблица соединений отображает погоду на марсе.

Пысы иногда, бывает, что это нам ненужно. в таком случае можно просто исключить некий трафик из обработки этим модулем. Тогда реагировать на линк лост оно не будет никак, как и на неответы противоположной стороны. Возможно, допускаю, есть опции и для этого модуля игнорировать линк лост, но в большинстве ситуаций это плохо а не хорошо. Потому что к моменту восстановления линка, противоположная сторона уже отработала потерю соединения, и закрыла его, а вот твоя приложуха будет упорото долбится, вместо переподнятия соединения в результате линк есть а ничего не работает.

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

Соотвественно если линк упал, можно… нужно все записи о соединениях привязаных к этому линку из таблицы вычистить, а всем службам разослать что конектион лост, завязывайте со «слать и слушать»

Это как раз и есть то совершенно идиотское поведение которое я видел в старой винде (в семёрке такого уже нет). Нет, не нужно удалять соединения при падении линка.

т.к после падения линка очевидно соединения прервались и это новое актуальное состояние системы.

Нет.

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

Это как раз хороший модуль, и к счастью так себя ведёт сетевой стек и в линуксе и в фрибсд - ничего не рвёт при потере линка.

Линк - это физический уровень, и логическому (tcp) до него не должно быть дела. Мало ли из-за чего он упал и мало ли когда он вернётся. Может это кабель надо было переткнуть почему-то, на 1 сек. А для долгих разрывов есть штатные tcp-таймауты, которые от линков опять не зависят. Если же почему-то надо сбросить tcp-соединения, то это как раз и можно сделать вручную уже.

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

Если та сторона закрыла коннект, то она ответит RST при попытке нашей стороны этот коннект использовать. После чего «наша сторона» коннект тоже закроет. Линки тут опять ни при чём.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)