vlan advertisement что это
Vlan advertisement что это
Большинство коммутаторов D-Link поддерживают протокол GVRP, который может сэкономить уйму времени сисадмину.
GARP VLAN Registration Protocol (GVRP) — протокол используемый для управления VLAN (создания, удаления и переименования VLAN), позволяет коммутаторам автоматически передавать информацию о VLAN. Без использования GVRP все VLAN пришлось бы конфигурировать на каждом коммутаторе вручную. Является свободным протоколом, описан в стандарте 802.1Q.
Настройка GVRP на коммутаторах D-Link
1. На крайних коммутаторах (SW1 и SW4) cоздаем VLAN и добавляем их на порты.
Создаем VLAN на коммутаторе SW1.
Создаем VLAN на коммутаторе SW4.
Добавляем VLAN на порты коммутатора SW1.
Добавляем VLAN на порты коммутатора SW4.
myvlan1, myvlan2, myvlan3 – названия vlan
10, 20, 30 – номера tagged vlan
2. На всех коммутаторах (SW1-SW4) включаем GVRP глобально и на uplink (trunk) портах.
Включаем GVRP гобально
Включаем на uplink (trunk) портах.
3.На крайних коммутаторах (SW1 и SW4)включаем анонсирование VLAN.
Вся информация о созданных нами на крайних коммутаторах (SW1 и SW4) VLAN разнесется по протоколу GVRP на коммутаторы SW2 и SW3. Таким образом, ненужно при добавление новых VLAN вручную конфигурировать промежуточные коммутаторы.
На этом все. Всем пока.
1″ :pagination=»pagination» :callback=»loadData» :options=»paginationOptions»>
Работа с vlan на коммутаторах D-Link | Часть 1: 802.1Q
Часть 1: 802.1Q VLAN
Сегодня хотелось бы разобрать работу с vlan на коммутаторах Dlink.
Если вы еще не находитесь в CLI коммутатора, предлагаю ознакомится тем как это осуществить в разделе «Подключение к CLI» — ТУТ
Список доступных команд
Вланы могут создавать только пользователи с правами администратора и оператора.
Cоздание Vlan
Обязательно должен быть указан vlan id.
Формат: create vlan tag
Параметры:
— имя создаваемого влана. Может содержать до 32х символов.
— vlan id или таг влана. Может быть в диапазоне от 2 до 4094.
type 1q_vlan advertisement — параметр разрешающий анонсировать влан основанный на стандарте 802.1Q по протоколу GVRP. Использовать не рекомендуется, т.к. на разных моделях коммутаторов может вести себя непредсказуемо.
Массовое создание Vlan по ID
Метод используется для создания нескольких VLAN одновременно. Уникальное имя VLAN будет назначаться автоматически (например VLAN10). Назначение имени VLAN основано на следующем правиле: «VLAN»+ID. Например, для VLAN ID 100 имя VLAN будет VLAN100. Если это имя VLAN конфликтует с именем существующего VLAN, то оно будет переименовано. Происходит это на следующим образом: “VLAN”+идентификатор+”ALT”+счетчик совпадений. Например, если конфликт является вторым, то имя будет VLAN100ALT2.
Формат: create vlan vlanid
Параметры:
— количество вланов (VID) для создания.
Удаление Vlan
Формат: delete vlan
Пример:
Массовое удаление Vlan по ID
Формат: delete vlan vlanid
Пример:
Конфигурирование Vlan
| advertisement [enable | disable]>
Параметры:
add [tagged | untagged | forbidden] | delete] — Назначит порт Тегированным |Не тегированным | Запрещенным. forbidden (Запрещенный) указывает на то, что порт не сможет присоединиться к влану ни при каких условиях, кроме ручного добавления. Примером автоматического присоединения портов является протокол GVRP.
delete — удаление портов из влана
advertisement [enable | disable] — включение/отключение анонсирования влана в сеть. Используется протоколом GVRP
GVRP и Ingress Checking
Ingress Checking — «проверка попадания» фрейма в набор VID, ассоцирированных с портом. Если Ingress Checking включен, то при поступлении в порт коммутатора фрейма, производится сравнение VID фрейма с набором идентификаторов VID, ассоциированных с портом (включая PVID порта). Если нет совпадения, то фрейм отбрасывается. Т.е. на порт принимаются только фреймы с идентификаторами VLAN ID, для которых данный порт является выходным. Если же Ingress Checking выключен, то никакой проверки не производится.
Формат: config port_vlan [
Параметр:
gvrp_state [enable | disable] — Включает или отключает GVRP для портов, указанных в списке
ingress_checking [enable | disable] — включение/отключение функции Ingress Checking
acceptable_frame [tagged_only | admit_all] — Разрешить только тегированный трафик на порту или весь.
Команды просмотра Show
show vlan — Отображение информации о всех vlan, включая параметры и настройки.
show vlan ports 6 — отображает информацию о vlan на требуемом порту.
show vlan vlanid 1 — отображает информацию о требуемом vlan по его ID
show port_vlan — отображения атрибутов VLAN yна портах на коммутатора
PVID auto assign
PVID — указывать на то, каким тегом будет помечен трафик поступивший от хоста на порт коммутатора.
Пример:
Порт 16 — транковый порт. На него приходит несколько вланов. В том числе vlan2
Порт 1 — порт доступа (Access/Untagged). За ним располагается хост. Например абонент.
1. На коммутатор в порт 16, приходит тегированный фрейм. Коммутатор проверяет ARP таблицу и видит, что абонент доступен через порт 1.
2. Порт 1 работает в режиме Untagged, поэтому с фрейма снимается метка влана (его принадлежность к данному влану). После этого фрейм становится нетегированным.
3. Так как порт настроен как Untagged, то когда фрейм от абонента приходит на порт 1 коммутатора, в нём проставляется тег соответствующий PVIDу, который указывает какому VLAN’у принадлежит этот фрейм. В данном случае проставляется тег с VLAN’ом 2.
Для абонента фреймы остаются нетегированными. Операция тегирования, которую выполняют коммутаторы абсолютно прозрачна. Хосты ничего не знают о тегах и получают обычные фреймы.
PVID auto assign используется для включения автоматического назначения PVID. Когда назначается VLAN X untagged, PVID этого порта будет назначен VLAN X. PVID будет автоматически обновляться на последний добавленный untagged vlan. Когда untagged порт удаляется, PVID порта будет назначается на «default VLAN» или предыдущий.
Значение по умолчанию включено.
Пример:
Проверка автоматического сопоставления PVID
show pvid auto_assign
Асимметричные VLAN
Суть данной технологии в том, что бы предоставить доступ с одного влана в другой, не используя маршрутизацию. Например абоненты разных сегментов сети не имея доступ друг к другу могли подключаться к требуемому серверу или интернет шлюзу.
Настройка GVRP
GVRP (GARP VLAN Registration Protocol) служит для передачи между устройствами информации о vlan, используемых на данном отрезке сети. При использовании в сети большого количества устройств, добавление в сеть нового vlan часто влечет за собой перенастройку всех устройств, через которые должен проходить новый vlan. В сети провайдера, особенно при применении схемы vlan-per-customer, это может создавать огромную головную боль. Использование протокола GVRP позволяет избежать перенастройки оборудования каждый раз при изменении vlan в сети.
nni_bpdu_addr [dot1d | dot1ad] — Используется для определения адреса протокола BPDU для GVRP в узле предоставления услуг. Он может использовать адрес GVRP 802.1d, адрес GVRP поставщика услуг 802.1ad или пользовательский multicast адрес. Диапазон определенного пользователем адреса: 0180C2000000 — 0180C2FFFFFF.
Пример:
Пример настройки GVRP
Схема подключения
На коммутаторах №2 и №3:
Напоминаю, что ключ advertisement при создании vlan говорит коммутатору о том, что этот vlan необходимо анонсировать соседним устройствам.
Администрирование #03. VLAN.
VLAN — Virtual Local Area Network
Сегодня мы поговорим про эту полезную вещь. Очень многие о ней слышали, но не все из них представляют, что это такое зачем оно нужно.
Сетевая топология — способ описания конфигурации сети, схема расположения и соединения сетевых устройств.
Физическая топология — описывает реальное расположение и связи между узлами сети.
Логическая топология — описывает хождение сигнала в рамках физической топологии.
1) Локальную сеть, физически состоящую из нескольких железок (aka коммутаторов), но которая видится как сеть, в которой одна многопортовая железка.
2) И наоборот, на одной железке можно уместить несколько сетей так, что они не будут видеть друг-друга. Как будто мы попилили коммутатор на несколько маленьких свитчиков.
3) Комбинацию из 1 и 2:
То есть, мы можем создавать логическую топологию сети не зависимо от физической топологии.
Тут надо отступить чуть в сторону. Никто не запрещает вам создать несколько локальных сетей без всяких VLAN и компы из одной сети будут видеть друг-друга (см. картинку ниже)
Когда и зачем это нужно:
3) Когда вы сталкиваетесь с IP-телефонией и моделью подключения комп-телефон-свич (то есть, 2 устройства на одном порту и нужно разделать их трафик). Телефонию в принципе принято выносить в отдельный VLAN не зависимо от типа подключения телефонов. В общем случае, когда на порт приходит по некоторым признакам разный трафик, который не должен смешиваться. Например, интернет, телефония и некоторый прямой канал с дружественной фирмой от провайдера.
4) Когда вы хотите развести всех этих людей по подсетям. Бухи налево, юристы прямо, маркетологи направо. Может, им не стоит видеть друг друга в целях безопасности, кто знает?
Как всё происходит: на устройстве создается VLAN, в него добавляются порты, которые в этот VLAN входят. Порты бывают тегированные и нетегированные. Тег – это некоторая метка (число), которая идентифицирует принадлежность трафика к VLAN. Помечать трафик нужно, когда в одном проводе передается трафик нескольких VLAN’ов (см. картинку).
VLAN1 — зеленый, в него входят порты 1, 7, 12, 14, 16 на switch1 и порты 1, 3, 4, 7, 8, 9, 11, 15 на switch2.
VLAN2 — синий, в него входят порты 3, 4, 6, 8, 9, 11, 13, 15, 16 на switch1 и порты 2, 5, 8, 13, 14, 16 на switch2.
VLAN3 — красный, в него входят порты 2, 5, 10, 16 на switch1 и порты 6, 8, 10, 12 на switch2.
Можно было бы соединить свитчи тремя патч-кордами (пунктирные линии) по одному на каждый VLAN, но не всегда это возможно и здорово (например, когда ваши свитчи расположены на разных этажах или когда VLAN’ов много, а свободных портов мало).
Сейчас свитчи соединены патч-кордом, который воткнут в 16 порт на первом свитче и в 8 порт на втором. Чтобы по нему могли ходить пакеты всех трёх VLAN’ов и не перемешиваться, патч-корд должен быть воткнут в тегированные порты. Порты 16 на первом и 8 на втором свитче — тегированные, каждый из них принадлежит всем трём VLAN’ам (также говорят и наоборот – три VLAN есть в этих портах). На входе в эти порты метка ставится (если нету), но на выходе не снимается.
Порты, помеченные одним цветом — нетегированные, в них нет меток, так как метки внутри одной сети не нужны. То есть, метка на входе в порт снимается (если есть) и на выходе не ставится.
И вот у вас несколько VLAN’ов, все счастливы, но друг друга сети совсем не видят. А надо. Чтобы настроить между ними маршрутизацию, нужен (тссс!) маршрутизатор. Ну или хотя бы L3-switch.
По просьбам трудящихся подписчиков несколько команд:
VLAN на компе с Debian:
Можно настраивать с помощью vconfig или с помощью ip link.
Создать VLAN на интерфейсе eth0. Имя VLAN’a – eth0.80, оно по-хорошему должно быть именно в таком формате: интерфейс.тег, ну и тег тут 80, уже понятно:
# ip link add link eth0 name eth0.80 type vlan id 80
# ifconfig eth0.80 up
# ip a a 172.16.1.1/24 dev eth0.80
Создать VLAN с названием 45 и тегом 45:
# create vlan 45 tag 45
Добавить нетегированные порты с 8 по 11:
# config vlan 45 add untagged 8-11
Добавить тегированный порт 14:
# config vlan 45 add tagged 14
Удалить 10 порт из VLAN:
# config vlan 45 delete 10
Посмотреть информацию о VLAN:
Добавить тегированные порты:
# config vlan2 add tagged 2,25
Изменить что-то с VLAN’ом:
# ip address 10.1.2.1 255.255.255.0
Чтоб перевести порт в тегированный режим:
# switchport trunk encapsulation dot1q
# swichport mode trunk
Разрешить VLAN’ы 1 и 2:
# switchport trunk allowed vlan 1,2
Включение нетегированного VLAN’а:
# switchport trunk native vlan 1
Режим по умолчанию, в этом порту не может быть тегированных пакетов:
# switcport access vlan 1
Ну и напоследок: не стоит наслушавшись цискокурсов или начитавшись статей пилить свою сеть на VLAN’ы, если вы не понимаете, зачем вам это надо. Если у вас в широковещательном домене пару сотен устройств и все в одной сети, то не стоит заморачиваться (это моё личное мнение).
Лига Сисадминов
663 поста 12.5K подписчика
Правила сообщества
— # mount /dev/good_story /sysodmins_league
— # mount /dev/photo_it /sysodmins_league
— # mount /dev/best_practice /sysodmins_league
— # mount /dev/tutorial /sysodmins_league
Зачем при работе с интерфейсом использовать одновременно и старый Net-tools и новый iproute2? В данном случае нужно заменить
-ться
Прям чума 21 века
добавлю
FreeBSD
ifconfig vlan900 create
ifconfig vlan900 vlan 900 vlandev igb0
на линупсе так же можно пользоваться командой vconfig
switchport trunk encapsulation dot1q такое нужно только на L3 коммутаторах
Расскажите про Q-in-Q vlan, пожалуйста
Если у вас в широковещательном домене пару сотен устройств и все в одной сети, то VLAN необходимы как минимум для четкой структуризации и более простого документирования сети.
зачем телефоны выводить в отдельный влан?
Вас на хабре забанили?
Искал как удалить порт из влана, нашел твою статью, а у тебя только длинк.
Крч no swichport access vlan №
Поговорим про агрегирование каналов.
Поговорим про свитчи, маркировку, broadcast домены, arp и vlan-ы.
Изучаем Администрирование Инфраструктуры 02. Подготовка лабораторной
Подготовим лабораторную для дальнейших уроков.
Изучаем Администрирование Инфраструктуры 01. Как устроена инфраструктура
Особенностью курса является то, что вся наша инфраструктура будет строиться на операционных системах семейства GNU/Linux. Реальная инфрастуктура зачастую состоит из множества готовых проприетарных решений, я же буду акцентировать внимание не на инструментах, а на задачах администратора. Т.е. мы научимся практикам, которые применимы везде, независимо от программного обеспечения. И тем не менее, умение работать с опенсорсными решениями также будет вам полезно.
С Днем системного администратора!
Для меня самого сегодняшний праздник оставался незамеченным до первого поздравления. Вот так внезапно наступила последняя пятница июля, когда по традиции отмечается День системного администратора.
«Эталонных», стереотипных админов с бородой, пузом и пивом наперевес остается все меньше, границы профессии расширяются, специализаций становится всё больше, так хочу поздравить всех админов, девопсов, эникеев и всех-всех причастных к стабильному функционированию компов, серверов и сервисов с профессиональным праздником!
Как мое рабочее место менялось с годами
в разное время рабочее место может выглядеть по разному.
у меня как то так менялось с годами )))
Как переставить жесткий диск с Windows на борту в новое железо, не переустанавливая систему
Все дело в том, что при установке Винда создает временные файлы, заполняет системный журнал событий и ставит драйвера комплектующих под текущее железо. При перестановке диска в другой компьютер, с отличным от первого железом, система, проще говоря, не поймет как ей работать с новым оборудованием, т.к. настроена для работы с другими комплектующими. То есть, в теории (да и на практике), системный диск можно переставлять из одного компьютера в другой, при абсолютной идентичности оных: одинаковая материнка, одинаковый проц и т.п.
Логичный вывод: нужно каким-то образом «сбросить» уже установленные драйвера и конфигурации. Для этого существует безмерное количество различного софта, но в этом посте я расскажу про встроенную утилиту «sysprep».
Утилита позволяет очистить журнал событий, временные файлы, сбросить драйвера устройств и активацию(!) системы, не удаляя пользовательские файлы и программы.
Находится по адресу C:\Windows\system32\sysprep\sysprep.exe
Вызвать можно двумя способами:
1. Зайти по указанному выше адресу, и запустить вручную
2. Нажать сочетание клавиш Win + R и в открывшемся окне ввести sysprep. (бм ругается на скрин :D)
Здесь предстоит выбрать параметры отвязки системы от железа.
Для переноса системы на другую машину, выбираем «Переход в окно приветствия», ставим галочку напротив пункта «Подготовка к использованию» и в параметрах завершения работы указываем «Завершение работы». Это важно, так как, например, при выборе «Перезагрузка», по завершению сброса системы, компьютер, что логично, перезагрузится, подсосав драйвера для этого же железа после загрузки.
В итоге должно получиться следующее:
Нажимаем «Ок» и ждем завершения работы утилиты
По завершению, компьютер отключится. Ни в коем случае не включайте его, ибо, в таком случае, всю процедуру придется проводить заново.
Теперь можно переставлять диск в новый комп.
При первой загрузке, винда откроет окно первичной настройки, как при установке. Не пугаемся, просто выбираем нужные пункты и жмем «Да», «Далее» и т.д.
При первичной настройке нужно создать нового пользователя для входа в систему. После завершения всех настроек, его можно будет удалить. Для Windows 10 советую создавать локального пользователя, без подключения к аккаунтам Microsoft, если есть такая возможность (зависит от дистрибутива).
Также, не забываем про то, что sysprep сносит активацию системы. Так что после загрузки ее придется активировать заново.
4. Сфера применения
1. Перенос диска с компьютера на компьютер, как описано выше.
2. Создание бекапа системы и файлов (большинство бесплатных бекап-софтин пляшут от аналогичного скрипта действий)
3. Создание корпоративного дистрибутива с предустановленными программами для установки на офисные машины. Полезно для админов, если нет централизованной системы управления конфигурациями.
Пост адресован начинающим администраторам и обычным пользователям, оказавшимся в ситуации, схожей с Васиной из начала поста.
UPD. Многие говорят что десятка сама прекрасно умеет подсасывать драйвера на новые компоненты. Отчасти это правда, зачастую так и происходит и статья больше относится к Win 7 и 8.1, однако и с десяткой раз на раз не приходится, имею горький опыт.
Вопросы с собеседований по Linux
Какие вопросы вам задавали на собеседованиях на должность линукс админа, помощника админа и т.п., всё что связано с линуксами?
Собираю базу вопросов с собеседований, думаю, будет полезно новичкам, да и в целом интересно почитать. Вопросы выложу в открытый доступ по ссылке. Просьба также указывать должность, на которую подавали.
Отказы ИС 0.Twilio и Redis
Введение. В IT существует такое понятие как post-mortem, обозначающее исследование, проводимое с целью выявления причин возникновения проблемы и недопущения их в будущем. В результате такого анализа IT-специалисты формируют post-mortem отчет, некоторые из которых выкладываются в открытый доступ.
В серии постов (если, конечно, она получится) планируется краткое изложение некоторых из подобных отчетов.
Сразу оговорюсь, что посты пишутся в свободное время, поэтому не ругайте сильно за ожидаемую их нерегулярность.
В качестве первого отчета выбран отчет компании Twilio (занимается предоставлением различных программных сервисов, в т.ч. автоматизированной отправки sms-сообщений и телефонных звонков). Отчет представлен на сайте компании и датируется 23 июля 2013 года.
Сам инцидент возник 18 июля 2013 и затронул 1,4; пользователей компании и заключался в следующем:
— во время инцидента при оплате с банковских карт в пользу Twilio пользователи не видели соответствующих изменений на своем балансовом счете;
— автоплатежи выполнялись несколько раз (так как баланс клиента в Twilio не обновлялся после оплаты);
— часть учетных записей были заблокированы из-за деактивации банковских карт, связанной с повторяющимся списанием средств;
— отчеты об использовании сервисов не доставлялись клиентам из-за того, что что биллинговая система (система выставления счетов) находилась в режиме оффлайн.
18.07.2013 08:35 UTC: из-за обрыва сетевого соединения с ведущим (master) узлом ведомые узлы выполнили переподключение и запустили процесс полной синхронизации одновременно.
18.07.2013 09:39 UTC: сервисы, использующие ведущий узел, начали отказывать из-за повышенной нагрузки на него.
18.07.2013 09:42 UTC: redis-master был перезапущен для того, чтобы справиться с нагрузкой.
18.07.2013 10:28 UTC: системы мониторинга Twilio зафиксировали аномалию в системе выставления счетов (ошибки платежей по картам и блокировки учетных записей пользователей). Затронуто было 1.1% пользователей. Проблемой начала заниматься дежурная команда инженеров.
18.07.2013 11:10 UTC: биллинговая система была отключена для избежания дальнейших ошибок обработки банковских карт.
18.07.2013 13:24 UTC: были разблокированы все затронутые учетные записи. Система выставления счетов оставалась в режиме оффлайн пока специалисты занимались поиском основной причины ошибки.
18.07.2013 18:58 UTC: биллинговая система была включена.
18.07.2013 21:57 UTC: Twilio начал возврат денежных средств. Работа по возврату заняла следующие 24 часа.
19.07.2013 22:00 UTC: возврат ден. средств был завершен.
19.07.2013 22:30 UTC: всем затронутым учетным записям на счет было зачислена сумма в размере 10% от их трат за последние 30 работы в сервисе.
20.07.2013 02:30 UTC: система выставления счетов запускалась постепенно для учетных записей, разделенных на группы.
20.07.2013 03:14 UTC: биллинговая система была запущена для всех групп пользователей (процесс запуска был завершен).
20.07.2013 04:15 UTC: работоспособность всех систем была восстановлена.
Основная причина. Twilio использует СУБД Redis для хранения баланса учетных записей. Кластер реализован на одном ведущем (master) и нескольким ведомым (slave) узлам, распределенным по разным ЦОД. Обрыв соединения 18.07.2013 08:35 UTC привел к значительному падению производительности Redis и возникновению тайм-аутов взаимодействия между ведомыми и ведущими узлами. Деградация была настолько значительной, что связанные сервисы начали отказывать.
Дежурная группа из-за высокой нагрузки на кластер Redis приняла ошибочное решение о необходимости его перезагрузки, так как она привела к чтению ошибочного файла конфигурации. Из-за ошибки конфигурационного файла Redis принял решение выполнить восстановление из AOL файла (файл, содержащий лог всех операций), которого не существовало, вместо использования бинарного снимка файловой системы (snapshot). В связи с этим Redis удалил все сведения о балансе учетных записей. Кроме того некорректная конфигурация привела к тому, что Redis сам запустился в режиме ведомого (slave) узла, что привело к его работе в режиме «только на чтение» и не давало биллинговой системе изменять сведения о балансе учетных записей.
У учетных записей с небольшим балансом и подключенными автоплатежами после выполнения платной операции производилось автоматическое списание ден. средств с привязанных банковских карт.
Состояние счетов хранится в двух независимых реляционных базах даннных. Эти сведения впоследствии использовались для восстановления корректного состояния баланса на учетных записях.
После восстановления состояния счетов биллинговая система была запущена, но системы мониторинга опять сообщали об ошибках. В связи с этим система была остановлена вновь и далее запускалась уже по частям для разных групп пользователей.
Что было сделано. В процессе решения проблемы кластер Redis был полностью заменен. Ошибка в конфигурационном файле была выявлена и поправлена. Во избежание проблем в будущем практика перезагрузки ведущего узла Redis была прекращена. Теперь он заменяется одним из ведомых узлов.
Потеря сведений о платежах также была признана ошибочной в системе автоплатежей. Ее отказ был высокорисковым, приводящим к неверным платежам клиентов и блокировкам их учетных записей. Теперь в случае, если счета клиентов не существуют или не могут быть изменены система не выполняет списаний и не блокирует учетные записи. Кроме того биллинговая система теперь сверяется также с бухгалтерскими базами данных в реальном времени.
Администрирование #04. DHCP.
Прошу прощение за долгое отсутствие. Я поняла, что в моём man’е по DHCP написано прискорбно мало и решила полностью его переписать.
В данном посте я буду идти от сильного упрощению к менее сильному упрощению, и в конце приближусь к правде, мне кажется, это логичнее, чем сразу углубляться в протокол.
Для начала, что делает DHCP (Dynamic Host Configuration Protocol – протокол динамической настройки узла). С помощью этой штуки сетевые устройства могут получать IP-адрес и другие сетевые настройки автоматически. Работает этот протокол по клиент-серверной модели. В самом общем случае это выглядит так:
Клиент-всем: Дайте мне кто-нибудь настройки!
Сервер-клиенту: Держи, я тут сервер, вот настройки: «настройки». Тебе норм?
Клиент-серверу: Ага, «настройки» подходят, ништяк.
Сервер-клиенту: Пометил у себя, «настройки» записаны на твоё имя.
Клиент /сам с собой/ уф, применил «настройки», кажись пошел трафик.
Для работы сервера выделяется некоторый пул (pool) – диапазон адресов, которые DHCP-сервер может раздавать клиентам.
Существует протокол, его описание и куча его реализаций на различных устройствах. Я не буду рассматривать каких-то конкретных реализаций – все они придерживаются единого формата.
Как видно из примера диалога выше, общение клиента и сервера разбито на несколько этапов-сообщений. В DHCP есть следующие типы сообщений: DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK, DHCPNAK, DHCPDECLINE, DHCPRELEASE, DHCPINFORM. Клиент и сервер общаются по протоколу UDP (у сервера порт 67, у клиента 68).
Эти сообщения выглядят в общем случае так: в шапке всякая важная мура из разряда кому, от кого, идентификаторы и всё такое, а в конце пачка опций. Вот эти опции и есть те настройки которые клиент запрашивает, а сервер выдаёт. Кому интересны подробности (а они правда интересны и важны), почитайте rfc2131.
На первом этапе клиент рассылает всем в локальной сети широковещательное сообщение на MAC-адрес FF:FF:FF:FF:FF:FF.
Отступление: Если у вас есть специальный сервер перенаправления запросов DHCP-relay, то сообщение может уйти и за пределы локальной сети.
В ответ все DHCP-серверы, до которых дошел запрос, присылают свои предложения DHCPOFFER тоже широковещательно на MAC-адрес FF:FF:FF:FF:FF:FF. Это происходит в том случае, если желаемый IP НЕ указан (о том, что происходит, когда указан – будет ниже). Клиент из них выбирает наиболее приглянувшееся (чаще всего по принципу «кто раньше прислал – того и тапки»). Сервер же, прежде чем прислать адрес, проверяет (протокол не обязывает, но настоятельно рекомендует), что адрес ещё не занят. В этом сообщении указывается уже предлагаемый IP, предлагаемые параметры и известен адрес-идентификатор сервера.
Подробнее про то, как выглядят остальные сообщения DHCP в Wireshark можно посмотреть в посте из соседней лиги. Или запустить wireshark дома.
Клиент, когда выбрал предложение, посылает DHCPREQUEST тоже широковещательно на MAC-адрес FF:FF:FF:FF:FF:FF, но с идентификатором сервера в соответствующем поле.
Сервер, если ничего криминально не случилось и адрес всё ещё свободен, посылает клиенту (всё так же широковещательно на MAC-адрес FF:FF:FF:FF:FF:FF) DHCPACK с настройками и помечает у себя адрес выданным. Уникальный идентификатор клиента и выданный IP-адрес однозначно идентифицируют DHCP-lease – так называемую аренду IP адреса. Если же адрес в процессе успел стать занятым, то клиенту посылается DHCPNACK с отказом и всё идёт заново.
Клиент получает сообщение DHCPACK с настройками, может сделать финальную проверку на занятость адреса и применяет эти параметры. С этого момента клиент сконфигурирован (и у вас пишется в винде «сеть1: подключено»).
Общая схема еще раз:
Когда клиент заканчивает работу, например, при выключении интерфейса, он посылает серверу сообщение DHCPRELEASE о том, что адрес свободен – можно пользоваться.
Вернёмся к DHCPDISCOVER и ситуации, когда мы просим выдать адрес, который у нас уже когда-то был. Rfc говорит нам, что в этом случае сервер сразу присылает DHCPACK (если адрес не помечен за кем-то другим) или DHCPNACK (если вы прошатались в отпуске месяц и адрес ушел к другому). Причем проверка на конфликты (пинг на всякий случай) ложится на клиента.
На самом деле, сколько ни ловила, так такую ситуацию и не поймала. У меня на DHCPDISCOVER с предпочитаемым IP в ответ приходил «Неправильный» DFCPOFFER на конкретный адрес. Подозреваю, что это ловился ipconfig /renew.
Если клиент обнаруживает, что с адресом что-то не в порядке, он посылает серверу DHCPDECLINE.
Немного о времени аренды IP-адреса. Это время в секундах, оно относительно, а потому не требует синхронизации времени между сервером и клиентом. То есть «забрать адрес через 3600 секунд» и без разницы, что у вас локаль Камчатки, а у сервера Москвы. Время аренды надо выбирать сообразно задачам – чтоб и адреса не кончались и слишком большой нагрузки на сервер не было. Интернет-кафе – час, дома – месяц, на работе – неделя, например. А еще есть время, через которое IP-адрес можно перезапросить, не отдавая его. Оно должно быть меньше времени аденды, тогда никто не захапает ваш адрес, пока ваш комп онлайн.
Теперь об опциях. Чаще всего, это DNS сервер, шлюз по умолчанию, ntp-сервер. А может быть куча всего – на это даже отдельный rfc2132 есть. У нас, например, такие.
Бывает еще такая вещь, как резервации (reservations). Это не когда индейцев ограничивают, а когда адрес добавляют к резервированию. Некоторые lease’ы запоминаются (админ указывает, какие именно). То есть, пара MAC-IP становится постоянной. Это позволяет получить статические адреса внутри пула, которые клиенты тем не менее получают по DHCP.
P.S.: Тема очень обширна, можно добавлять и добавлять. Но мне хотелось выдержать баланс между пересказом rfc и «DHCP для домохозяек».
Администрирование#02. Удаленный доступ.
Сегодня я сделаю некоторый вбоквел. Почему именно удаленный доступ? Потому что мы, админы, пользуемся этим ежедневно.
Администрирование#02. Удаленный доступ.
Вообще, что это такое: это когда вы с одного устройства попадаете на какое-то другое устройство и что-то можете с ним сделать. То есть, сидя попой в кресле за рабочим компом и сеть настраивать, и серваки админить, и пользователям помогать.
Для удобства, попробую разделить виды удаленного доступа на несколько классов.
1. Терминальный доступ. Сейчас этим словом называют доступ через консоль (такую, как в фильмах о хакерах – белые буковки на черном фоне). Этот вид доступа текстовый. Он используется для доступа на сервера без GUI (Graphical User Interface); для доступа на сервера с GUI, но с устройств без GUI; для доступа на различное сетевое оборудование; ну и просто как универсальный-доступ-куда-угодно, так как что может быть универсальнее консольки?
Кстати, цвет буковок и фона часто настраивается – всё для людей!
Для работы в терминале существуют команды с флагами и параметрами:
Команда — команды набираются в терминале текстом, это программы, которые выполняют заложенные в них действия.
Флаг (ключ) — Флаги уточняют действие команд. Флаг – это модификатор, который указывается в командной строке вместе с именем команды, обычно после дефиса. (например, не просто соединиться с устройством, а по определенному порту).
Параметры пишутся после команды или после флагов, их иногда называют аргументами. Параметры задают информацию, необходимую для выполнения команды (например, IP адрес по которому надо подключиться).
Порт — идентифицируемый номером системный ресурс, выделяемый приложению, выполняемому на некотором сетевом хосте, для связи с приложениями, выполняемыми на других сетевых хостах.
Некоторые особо известные порты:
[Лайфхак] Можно посмотреть, открыт ли порт на оборудовании следующим образом:
Коннектимся на оборудование по telnet по проверяемому порту. Если можно нажать Enter и при этом курсор перескакивает на следующую строку, значит порт открыт.
Windows telnet-клиент включается из «программы и компоненты»->«Включение или отключение компонентов Windows».
SSH — Secure Shell. Это протокол по которому осуществляется защищенный удаленный доступ. Плюсы в том, что весь трафик шифруется. Логиниться по ssh можно как используя логин-пароль, так и пару открытый-закрытый ключ.
Изменить в конфигурации ssh-сервера порт не помешает, так как про стандартный все в курсе, и злобные хакеры нехорошие автосканеры портов найдут открытый 22 порт, сделают вам DdoS атаку и подвесят ваш сервер, что вызовет печаль.
Лирической отступление. Схемы удаленного доступа чаще всего клиент-серверные. В этом случае сервер стоит там, КУДА мы подключаемся, а клиент – там, ОТКУДА идет подключение. То есть, у сисадмина стоит клиент, а на другой стороне сервер (даже если другая сторона является компьютером пользователя).
1.1) Команды, выполняемые на удаленном устройстве. В Windows, в виду отсутствия ssh, для многих команд (как обычных, так и powershell) можно указать имя или IP компьютера, на котором они должны выполниться.
2) Доступ к удаленному рабочему столу. Здесь я подразумеваю доступ с ПК/сервера на ПК/Сервер, где на обоих сторонах есть графический интерфейс. Вы просто работаете на чужом рабочем столе как на своем.
В Windows чаще всего используется протокол RDP, так как он встроен в систему. Если ваш Win-сервер не является терминальным сервером (с установленной специальной ролью), то на нем разрешено только два одновременных логина. В пользовательских Win-системах только один. Вероятно, кто-то пользуется удаленным помощником Windows, но обычно для пользователя его тапуск и создание приглашения является слишком сложным.
3) «Низкоуровневый» доступ к серверам. ILO в серверах HP, IPMI в серверах DEPO (и вообще, там, где материнки supermicro), может кто дополнит в комментариях по решениям. Это фактически доступ к серверной платформе. Может осуществляться как из браузера, так и из специального клиента. Предоставляет доступ к серверам до загрузки ОС (можно зайти в BIOS, можно в конфигурилку RAID, можно подключить ISO-образ и накатить ось, можно даже перепрошить BIOS удаленно), а также ограниченный доступ к управлению железками (сделать power off/on, поправить скорость кулеров, посмотреть температуру). Очень-очень удобно. Прощай дежурства в офисе вечером, всё можно сделать из дома. Не надо мерзнуть в серверной, если что сломалось – всё можно сделать с рабочего места. Для всего этого достаточно назначить IP, маску и шлюз на интерфейс IPMI/ILO, это делается из BIOS.
В заключение: хотелось больше рассказать про shell, привести примеры подключений, расписать подробнее про RDP, но поняла, что получится а) много и б) не нужно для общего ознакомления, потому безжалостно удалила лишнее.
P.S.: баянометр люто ругался на скрин консольки, но ничего похожего по содержанию не нашла.
Администрирование#01. Адресация в IP сетях
Как и обещала, выкладываю первую часть.
Некоторое введение: статьи о базовых понятиях я писала еще в универе по лекциям, затем их вычитывал мой научный руководитель (aka nixleader), поэтому тега «моё» не будет. Статьи не претендуют на оригинальность, есть множество других. Они, также, вероятно, могут встретится в сети (распространялись в универе и свободно висят в справочной системе на работе). Я постараюсь указывать места, где будет встречаться копипаста с других ресурсов (далее такое будет). Помимо простых вещей, попробую привести в литературную форму некоторые сложные маны, которые писала чисто для себя, и выложу их отдельно.
Администрирование#01. Адресация в IP сетях
В семействе протоколов TCP/IP используются три типа адресов: локальные (физические, аппаратные), IP-адреса и символьные (доменные) имена. Рассмотрим первые два типа адресов.
Хост (Host) – устройство, работающее в сети на сетевом уровне модели OSI (компьютер, маршрутизатор и т.п.). Часто понятие путают с IP-адресом.
IP-адрес — это 32 бита (4 байта), 4 октета, представляющие собой «логический» адрес хоста в сети (сетевой адрес). Нужно понимать, что у одного хоста может быть много IP-адресов.
IP-адреса обычно записываются в десятичной системе счисления виде четырёх октетов X1.X2.X3.X4, где X1 – старший байт адреса.
Маска подсети — указывает, какая часть IP-адреса приходится на адрес сети, а какая — на адрес хоста в ней. Без адреса сети или IP-адреса используется только в обсуждении количества используемых/необходимых адресов.
Маска записывается через “/” после IP-адреса и может записываться как IP (например, 192.168.1.100/255.255.255.0; Здесь маска 255.255.255.0 — это 24 единички и 8 нулей (в двоичной системе), первые 24 символа будут адресом сети, оставшиеся 8 — адресом хоста), или как число от 0 до 32 (192.168.1.100/24 — здесь «/24» — это маска, то есть 24 единички в начале, остальные — нули).
Адрес сети – зарезервированный IP адрес, используемый для обозначения всей сети (совместно с указанием маски сети). В адресе сети на месте адреса хоста все биты выставляются в нули.
Широковещательный запрос — отправка пакета всем устройствам в сети. Для реализации такой рассылки назначается специальный широковещательный адрес: в IP-адрес после адреса сети (вместо адреса хоста) все биты выставляются в единицы.
Соответственно, максимально возможное количество хостов в сети вычисляется по формуле 2^(32-маска)-2. (Так как, когда вместо адреса хоста все нули — это адрес сети, а когда все единички — это широковещательный запрос, соответственно, теряем два адреса из всех вариантов)
Маска /32 — указывает, что написан адрес одного и ровно 1 (одного) хоста
Маска /31 — используется для маршрутизации для соединения точка-точка, или если два адреса на один комп (это делается для экономии адресов и для сокращения количества записей о маршрутизации соответственно).
0.0.0.0/0 — весь интернет.
255.255.255.255 — широковещательный запрос всем в локальной сети. Используется обычно в случаях, когда хосту неизвестны настройки локальной сети.
Адреса, которые запрещены в сети интернет, или же «локальные» адреса, которые можно использовать для себя без ограничений (так называемые, «серые» адреса):
Для собственных локальных сетей:
127.0.0.0/8 – loopback – адреса которые доступны только внутри одного хоста
Адреса класса D используются для многоадресной (multicast) передачи.
Остальные адреса на данный момент зарезервированы и не используются.
Стоит отметить, что ранее классы использовались для маршрутизации. Теперь же вся маршрутизация «бесклассовая» и классы сетей указываются только для указания размера сети (например, “сеть класса C” обозначает сеть с 256 адресами (с маской /24) (любую, даже 10.2.4.0/24!!))