Виды IP-адресов: unicast, broadcast, multicast, anycast. Loopback IP-адреса и интерфейсы.
Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжаем изучать основы работы компьютерных сетей и протокол сетевого уровня IP, а если быть более точным, то его версию IPv4. IP-адреса бывают разные и делятся не только на частные и публичные, серые и белые. В этой теме мы разберемся с видами IP-адресов и поговорим о видах трафика в IP сетях и как это все связано с IP-адресами, ведь логично предположить что для каждого вида взаимодействия используются свои IP-адреса, в IPv4 всего можно выделить три полноценных вида взаимодействия и одно костыльное. К полноценным относятся: unicast (одноадресная рассылка), multicast (многоадресная рассылка), broadcast (широковещательная рассылка). К неполноценному в IPv4 относится anycast взаимодействие (доставка ближайшему узлу из группы). А в качестве бонуса мы еще рассмотрим loopback адреса и интерфейсы.
Если тема компьютерных сетей вам интересна, то можете ознакомиться с другими записями курса.
Оглавление первой части: «Основы взаимодействия в компьютерных сетях».
Оглавление четвертой части: «Сетевой уровень: протокол IP и его версия IPv4».
4.8.1 Введение
Содержание статьи:
Последняя исключительно теоретическая тема, касающаяся протокола IPv4, следующие темы будут сопровождаться небольшой практикой. Здесь нам нужно будет рассмотреть виды взаимодействия в IP сетях и соответствующие IP-адреса: unicast (одноадресная рассылка), multicast (многоадресная рассылка), broadcast (широковещательная рассылка), anycast взаимодействие (доставка ближайшему узлу из группы).
4.8.2 Виды трафика в IP
Мы говорили о различных видах взаимодействия в компьютерных сетях еще в самой первой части, теперь стоит поговорить про виды трафика, который передается по сетям IP, то есть способы, которыми могут общаться наши узлы друг с другом, решая различные задачи, при этом для каждого вида трафика используют свои IP-адреса.
- Одноадресная рассылка или unicast IP-адреса. Обычно самую большую долю трафика в компьютерной занимает одноадресная рассылка. Практически для любого взаимодействия между двумя конечными узлами используется unicast.
- Широковещательная рассылка и broadcast IP-адреса. Суть взаимодействия понятна из названия. Если unicast можно описать как взаимодействия точка-точка, то broadcast, как точка-многоточка. Сразу стоит обратить внимание на то, что широковещательный трафик ограничен канальной средой узла, в котором он находится.
- Многоадресная рассылка или multicast IP-адреса. Multicast адреса используется, когда нужно передать какую-то информацию не всем узлам канальной среды, а какой-то определенной группе, при этом узлы группы могут находиться в разных канальных средах. Представим, что у нас есть жилой дом на несколько подъездов и у этого дома есть доска объявлений, на которой управляющая компания информирует жильцов своего дома. Если в объявление будет написано: «всем жильцам дома», то это будет похоже на broadcast, если написано «жильцам третьего этажа» или «жильцам второго подъезда», то это будет похоже на multicast.
- Anycast взаимодействие очень хорошо прописано и реализовано в IPv6, а вот в IPv4, решая задачи маленькой сети, вы, скорее всего, не столкнетесь с anycast. Anycast взаимодействие можно описать так: твой запрос может обработать любой из этих десяти узлов, но тебе нужно обратиться к ближайшему. Классический пример anycast взаимодействия: в Интернете есть корневые DNS-сервера, каждый корневой сервер имеет свою копию в различных точка планеты, если вы находитесь в Омске, то вам нет смысла обращаться к корневому серверу в Лондоне, поскольку такая же копия есть в Новосибирске.
Loopback интерфейсы и loopback адреса – это не отдельный вид трафик, зачем я его сюда добавил? Да просто потому что могу, а почему бы и нет, создавать отдельную тему, чтобы рассказать про loopback просто не вижу смысла. Если говорить про loopback интерфейс, то это интерфейс, которого нет физически, но есть в голове у узла или маршрутизатора, этот интерфейс будет доступен другим физическим устройствам до тех пор, пока жив хотя бы один физический интерфейс узла, на котором создан loopback. Про loopback IP-адреса мы уже говорили, когда разбирались с видами IP-адресов.
4.8.3 Одноадресная рассылка и unicast адреса
Начнем с самого просто и стандартного вида взаимодействия в компьютерной сети. Unicast или одноадресная рассылка используется для взаимодействия между двумя узлами сети. Графически unicast взаимодействие показано на Рисунке 4.8.1.
Рисунок 4.8.1 Unicast взаимодействие между двумя узлами компьютерной сети
То есть компьютер источник (красный), формируя IP-пакет в качестве IP-адреса назначения, указывает адрес конкретного узла, к которому хочет обратиться (зеленый), все остальные узлы компьютерной сети не должны получить этот пакет, поскольку им он не предназначен. Когда зеленый узел решит ответить красному, то он также в качестве IP-адреса назначения запишет unicast IP-адрес красного узла.
Вы легко можете убедиться в том, что unicast означает, что пакет пойдет одному конкретному адресату, если соберете схему, как показано на Рисунке 4.8.2, а затем выполните команду Ping от одного узла до другого в режиме симуляции.
Рисунок 4.8.2 Демонстрация использования unicast IP-адресов в Cisco Packet Tracer
Обратите внимание: в поле IP-пакета IP-адрес назначения указан адрес 192.168.2.2, собственно, это и есть пример unicast адреса, в данном случае это и означает, что получатель у нас только один, который однозначно идентифицируется этим адресом, то есть сформированный пакет обязан будет принять и обработать только этот узел. При этом топология компьютерной сети не важна, даже если будет среда с общей шиной, здесь пакет придет всем узлам, но обработает его только один узел, все остальные просто его отбросят.
4.8.4 Широковещательная рассылка и broadcast адреса
Тут сразу стоит напомнить о сетевых коммутаторах и их CAM таблицах, в которых ведется сопоставление портов коммутатора и мак-адресов, которые «светятся» за этими портами. У коммутаторов есть механизм unknown unicast flooding и это понятие не стоит путать с broadcast, как понятно из названия, unicast flooding реализуется при помощи unicast рассылок во все порты, в свою очередь broadcast означает отправить пакет все участникам канальной среды или подсети, проще говоря, broadcast ограничивается портом маршрутизатора. Схематично broadcast взаимодействие показано на Рисунке 4.8.3.
Рисунок 4.8.3 Broadcast взаимодействие между узлами компьютерной сети
Как видим, получается взаимодействие точка-многоточка. Другими словами, когда красный узел формирует широковещательный пакет, его получат все соседи, находящиеся с красным узлом в одной канальной среде. Тут вы можете спросить, а зачем нужен broadcast, если красный узел может отправить запрос каждому соседу по отдельности, и этот вопрос очень хороший! Во-первых, красный узел не обязан знать канальные и сетевые адреса всех своих соседей, более того, вероятно он их и не знает, а пытается выяснить как раз-таки при помощи broadcast, на основе этого механизма работает протокол ARP, который позволяет узнать мак-адреса по известному IP-адресу. Также при помощи broadcast запросов конечные узлы делают запросы DHCP-серверу на получение IP-адреса и других опций.
Второй момент связан с неэкономным использованием времени и других ресурсов компьютерной сети. Представим себе такую ситуацию: у нас есть узел с настройками 192.168.12.45/24, этот узел хочет отправить пакет своему соседу с IP-адресом 192.168.12.230/24. Чтобы это сделать нашему узлу нужен MAC-адрес, при помощи broadcast он сформировал бы один пакет и направил бы его в сеть всем соседям по канальной среде, а сосед с IP-адресом 192.168.12.230 получил бы такой пакет и прислал бы нашему узлу информацию о своем мак-адресе. Если бы у нас не было механизма broadcast, то нашему узлу пришлось бы обращаться к каждому узлу в канальной среде по отдельности с вопросом: извините, а не у вас ли IP-адрес 192.168.12.230? Таким образом мы бы получили вместо одного пакета несколько сотен пакетов.
Как определить, что IP-адрес является широковещательным в подсети? Да мы уже про это говорили, когда разбирались с CIDR и VLSM. Вы же помните, что IP-адрес состоит из номера сети и номера узла. У широковещательного IP-адреса в номере узла будут все единицы в двоичной системе счисления. Например, возьмем нашу сеть 192.168.1.0/24, иначе маску можно записать 255.255.255.0, а это означает, что под номер узла выделен последний октет IP-адреса, то есть восемь бит, из этого следует, что широковещательным адресом в такой сети будет: 192.168.1.255, если перевести 255 в двоичную систему счисления, то получим: 11111111. Если ничего непонятно, то настоятельно рекомендую сперва ознакомиться с темами «Классовые сети» и «Маски подсети переменной длины» в том порядка, как я их указал.
Давайте теперь немного модифицируем нашу схему и посмотрим на количество канальных сред в нашей сети и на то, как распространяется broadcast трафик по нашей сети. На Рисунке 4.8.4 показана схема сети и ее канальные среды.
Рисунок 4.8.4 Три канальных среды в компьютерной сети
У нас здесь три канальных среды. Не забываем о правиле, связанном с маршрутизаторами: каждый интерфейс маршрутизатора должен «смотреть» в свою канальную среду, то есть вы не сможете сделать так, чтобы первый порт маршрутизатора имел префикс 192.168.2.23/24, а второй порт имел такой префикс: 192.168.2.12/24, так как в этом случае они находятся в одной подсети. По этой причине у нас здесь не две канальных среды, а три:
- Первая канальная среда отмечена синим и в ней ровно два участника: левый маршрутизатор с IP-адресом и маской 10.10.10.1/30 и второй: 10.10.10.2/30.
- Вторая канальная среда отмечена зеленым и в ней у нас пять участников: четыре компьютера и основной шлюз, которым выступает интерфейс маршрутизатора, который «смотрит» в подсеть 192.168.1.0/24.
- Третья канальная среда имеет трех участников: два ноутбука и интерфейс второго маршрутизатора.
Теперь давайте сделаем широковещательную рассылку в зеленой канальной среде и посмотрим, что из этого выйдет. Для этого откроем командную строку компьютера 192.168.1.2 и выполним команду ping на IP-адрес 192.168.1.255, который в данном случае является широковещательным, естественно, делать это нужно в режиме симуляции Cisco Packet Tracer.
Рисунок 4.8.5 Пример широковещательного запроса в канальной среде
Cisco Packet Tracer некорректно указывает IP-адрес назначения в широковещательном IP-пакете, в данном случае написано, что это 255.255.255.255, когда на самом деле должно быть: 192.168.1.255, а вот с широковещательным мак-адресом никаких проблем, он действительно: FF-FF-FF-FF-FF-FF. В этом можно убедиться, повторив ping на реальном ПК и запустив Wireshark, моя локальная подсеть 192.168.0.0/24, вот что показывает Wireshark при пинге IP-адреса 192.168.0.255.
Рисунок 4.8.6 Так выглядит широковещательный запрос в Wireshark
Здесь я выделил красным цветом IP и MAC-адреса источника и назначения. Мак-адрес при широковещательном запроса у нас: FF:FF:FF:FF:FF:FF, а вот широковещательный IP-адрес выглядит так: 192.168.0.255. Стоит сразу заметить, что тип запроса (каким он будет: широковещательным или одноадресным?) определяется узлом отправителем. Делается это при помощи маски подсети, которая задана узлу отправителю и IP-адресу назначения, то есть тому адресу, на который будет отправлен пакет.
Узел-отправитель берет свой IP-адрес, прикладывает его к маске подсети, которая ему задана, таким образом он узнает в какой подсети он находится, затем он берет IP-адрес назначения и прикладывает его к своей маске и сравнивает с результатами первой операции, давайте это посмотрим более детально. Для примера возьмем сеть 10.10.10.0/24. У нашего узла IP-адрес 10.10.10.12, а отправить он хочет пакет на адрес 10.10.10.255, то есть сделать широковещательный запрос.
Сначала узел сравнит свой адрес и маску, что понять в какой сети он находится.
Таблица 4.8.1 Узел сравнивает свой IP-адрес с маской подсети
Сделав это вычисление, он понимает, что номер его сети 10.10.10.0, а это значит, что все узлы, у которых первых три октета совпадают и равны 10, а в последнем значения меняются от 1 до 255 находятся в одной канальной среде с этим узлом. Затем наш узел возьмет IP-адрес назначения и сравнит его со своей маской.
Таблица 4.8.2 Узел сравнивает свой IP-адрес назначения с маской подсети
Компьютер видит, что номер сети в IP-адресе назначения совпадает с номером сети, в которой он находится (первых три октета), а вот номер узла не совсем обычный, в нем прописаны все единицы, а это значит, что запрос широковещательный и его нужно направить всем узлам в канальной среде! Но как это сделать? Проблема заключается в том, что маска подсети по сети не передается: ни в IP-пакете, ни тем более в Ethernet кадре нет поля для передачи маски подсети.
Как транзитные узлы поймут, что пакет/кадр являются широковещательными? Да очень просто! Помните, мы говорили, что широковещательные запросы в модели TCP/IP не выйдут за пределы канальной среды, это значит, что такие пакеты не маршрутизируются и их можно доставить от источника до отправителя, используя только мак-адреса. Теперь всё становится на свои места. Если узел отправитель видит широковещательный кадр, он в поле мак-адрес назначения Ethernet кадра подставляет широковещательный мак-адрес FF:FF:FF:FF:FF:FF. Мы же помним, что когда коммутаторы коммутируют, они не смотрят на IP-адреса, более того, простенькие коммутаторы даже не умеют этого делать, но когда коммутатор получит Ethernet кадр с адресом назначения FF:FF:FF:FF:FF:FF, он поймет, что этот кадр широковещательный и его надо разослать всем участникам канальной среды, в которой находится узел-отправитель (обратите внимание: не во все свои порты, а всем участникам канальной среды, все дело в том, что есть технология VLAN, которая позволяет разделять канальные среды на канальном уровне).
Давайте теперь посмотрим на всё это в Cisco Packet Tracer. Напомню, что наш узел сформировал широковещательное сообщение и готовится отправить его в сторону коммутатора. Пропустим тот момент, когда сообщение только пришло на коммутатор и сразу посмотрим на то, что коммутатор направит широковещательное сообщение всем участникам канальной среды.
Рисунок 4.8.7 Коммутатор направил широковещательный запрос всем участникам канальной среды
Если будете повторять эту схему самостоятельно, то обратите внимание, что на роутере один пакет будет перечеркнут красным крестиком, в сущности, это будет означать, что широковещательное сообщение не уйдет дальше порта маршрутизатора, который смотрит в зеленую канальную среду. Теперь давайте посмотрим, как узлы получатели будут отвечать на широковещательный запрос.
Рисунок 4.8.8 Как отвечают узлы на широковещательный запрос
Как видим, узлы отвечают на широковещательный запрос юникастом, а зачем им отвечать при помощи broadcast, если запрос делал один конкретный узел, значит и отвечать нужно одному конкретному узлу, а не всем подряд. На рисунке показано, что сообщения на коммутаторе выстроились в очередь и ждут своей участи.
Рисунок 4.8.9 Как отвечают узлы на широковещательный запрос
По мере поступления сообщений от коммутатора к узлу, мы будем видеть изменения на экране эмулятора терминала, на рисунке выше показано, что узел 192.168.1.2 получил ответ от 192.168.1.3, но еще не получил ответа от трех других. В итоге мы должны будем увидеть, что на один широковещательный запрос, который был сформирован на узле 192.168.1.2, мы получим четыре одноадресных ответа. От всех участников нашей канальной среды.
Рисунок 4.8.10 Как отвечают узлы на широковещательный запрос
Наш узел должен будет еще три раза сделать ICMP-запросы к своим соседям, это стандартное поведение утилиты Ping, но смотреть на них нам уже не интересно. Поэтому остановимся на этом. Я отмечал, что широковещательный запрос ограничен портом маршрутизатора и это хорошо, дело всё в том, что сети, построенные на Ethernet, имеют проблему, называемую широковещательным штормом. Хорошо, что это не глобальная проблема и она ограничивается портом роутера.
Давайте лучше посмотрим на пример широковещательного запроса в коммутируемой сети, такой пример с технической точки зрения вреден, но он хорошо демонстрирует опасность широковещательных штормов, обратите внимание на Рисунок 4.8.11.
4.8.11 Широковещательные запросы в коммутируемой сети
Здесь я даже не стал выделять границы канальных сред, поскольку их по сути и нет, представим, что два коммутатора на схеме являются неуправляемыми и они ничего не знают о технологии VLAN, а также допустим, что эти коммутаторы очень и очень мощные и способны прокоммутировать любой объем трафика, ну совершенно любой, им это не важно. А вот каналы от коммутаторов до узлов ограничены полосой пропусканию 100 Мбит/c. Теперь давайте выполним ping с узла 10.10.10.1 на широковещательный адрес его сети, то есть 10.10.10.255. Момент номер один: первый коммутатор, к которому подключен наш узел источник, разослал полученный пакет всем узла, находящимся в канальной среде вместе с нашим узлом источником, в том числе и на соседний коммутатор.
Рисуноу4.8.12 Широковещательные запросы в коммутируемой сети
Вот тут вы можете сказать: но как так, Кирилл, ты же говорил, что подсеть и канальная среда – это одно и то же, а пакеты из подсети 10.10.10.0/24 направлены в подсеть 20.20.20.0/24 и даже в подсеть 30.30.30.0/24! И да, получается, что ранее я говорил не совсем правду, хотя нет, я говорил всю правду, поскольку постоянно повторял, что коммутаторы не умеют работать с IP-адресами, у них есть другой механизм по разделению на канальные среды – VLAN, но о нем позже.
Выходит, что для нашего коммутатора в данной ситуации единой канальной средой являются все узлы, которые подключены непосредственно к нему, хотя с точки зрения протокола IP у нас тут целых три подсети: серверы, компьютеры и ноутбуки. Но коммутатор об этом ничего не знает, вланов нет, IP-адреса коммутатором не анализируются, поэтому только и остается, что разослать широковещательный кадр во все активные порты, а конечные узлы сами смогут разобраться: нужно ли им отвечать на этот запрос или нет.
Обратите внимание: на широковещательный запрос ответили только компьютеры, потому что только они находятся в одной подсети с узлом 10.10.10.1. Ноутбуки откинули широковещательный запрос от этого узла и этих кадров мы уже не видим на рисунке выше, а сервера в данный момент откидывают кадры (они помечаются красным крестиком на рисунке). Два сообщения, которые мы видим на первом коммутаторе были сформированы и направлены узлами 10.10.10.2 и 10.10.10.3. Все остальные участники нашей сети сравнили свои IP-адреса и маски с теми адресами, которые были указаны в IP-пакете и поняли, что этот пакет не для них и им отвечать на него не нужно.
4.8.13 Широковещательные запросы в коммутируемой сети
Теперь о проблеме широковещательного шторма. Помним про условия: коммутатор может обработать любой объем трафика, а полоса пропускания всех каналов конечная и равна 100 Мбит/c. А теперь представим, что наш узел 10.10.10.1 сошел с ума и начал бомбардировать нашу маленькую сеточку бесконечным количеством широковещательных запросов и в конце концов дошло до того, что он начал утилизировать всю полосу 100 Мбит/c своими широковещательными запросами, что произойдет? А произойдет то, что каналы до всех узлов нашей сети будут забиты на 100% и ничего в них передаваться не будет, кроме широковещательных запросов этого узла.
Как работает broadcast? Коммутатор получает кадр, копирует его и рассылает всем участникам канальной среды. То есть все линки до ноутбуков будут забиты широковещательным трафиком, все линки до стационарных ПК будут забиты этим бесполезным трафиком и линк между двумя коммутаторами будет использоваться только под Broadcast.
Ну хорошо, скажите вы, ты нам потом расскажешь про VLAN, мы увидим, что если на коммутаторах используется VLAN, то широковещательный трафик не выйдет за пределы этого самого VLAN, а это значит, что, если сойдет с ума узел из подсети 10.10.10.0/24, то от широковещательного шторма пострадают только узлы из его подсети и никто более. Хорошо. Давайте смотреть. Только теперь давайте всё по-честному. Производительность коммутаторов не бесконечна, более того, центральный процессор коммутатора – это его самое слабое место. Когда в сети Ethernet случается широковещательный шторм или петля, то проблемы начинаются не из-за того, что «забиты» каналы, а из-за того, что коммутаторам доступа банально не хватает процессорной мощности или объема CAM таблиц, в которых ведется сопоставление порт — мак-адрес. Теперь представляем, что в одной подсети у нас не три узла, а двести узлов и делаем выводы.
4.8.5 Многоадресная рассылка и multicast адреса
Тема многоадресной рассылки или multicast трафика – это отдельный мир в IP сетях, детальное знакомство с которым не входит в программу нашего курса по компьютерным сетям для начинающих, но нам важно знать, что такой трафик бывает и нам важно понимать базовый принцип работы узлов компьютерной сети при многоадресной рассылке. Схематично она показана на Рисунке 4.8.14.
4.8.14 Multicast взаимодействие между двумя узлами компьютерной сети
В самом начале я уже приводил пример с объявлением у дома, повторять его не буду. Многоадресная рассылка, как и широковещательная, характеризуется взаимодействием точка-многоточка, но здесь есть существенное «но». Участники в таком взаимодействие могут находиться в разных канальных средах. IP-адреса multicast мы уже называли (далее повторим), но тут стоит сказать, что для реализации многоадресной рассылки можно использовать и обычные IP-адреса, было бы желание.
Подсеть | Пояснение |
224.0.0.0/24 | Local Network Control Block. IP-адреса из этой подсети вам лучше не использовать для своих нужд, поскольку они заняты для нужд различных протоколов, которые могут работать в вашей сети. Так, например, IP-адреса из этой подсети используют роутеры при обмене служебной информацией в протоколах OSPF или EIGRP. В RFC 3171 сказано, что узел, отправляющий пакет на адрес из данной подсети в поле TTL должен выставлять значение 1. |
С 224.0.1.0 по 238.255.255.255 | Это multicast IP-адреса, для которых разрешена глобальная маршрутизация, можно сравнить с публичными IP-адреса, но только для multicast трафика. |
239.0.0.0/8 | Эти multicast адреса может использовать кто угодно в своих локальных сетях для организации многоадресного вещания, то есть, если мы провайдер и хотим предложить своим абонентам услугу IPTV, то для этих целей у нас есть вот эта подсеть. |
Детальную информацию о зарезервированных multicast адресах можно получить из RFC 5771, при необходимости вы сможете найти этот документ. Нам бы просто разобраться с механизмом. Давайте начнем. Представим, что у нас есть сеть, как показано на Рисунке ниже.
4.8.15 Схема для демонстрации Multicast взаимодействия
Схема с виду ужасная, но в реальной жизни будет хуже, поверьте. Здесь пока не указаны никакие IP-адреса, здесь просто показаны канальные среды. Вообще, мы не будем ничего настраивать, но следует заметить: для работы multicast в реальной сети, вам сперва нужно настроить unicast взаимодействие между узлами, а уже поверх unicast разворачивать свою multicast сеть. Теперь давайте представим, что мы провайдера, который хочет предоставлять своим абонентам услугу IPTV. Для этого нам нужен источник, пусть это будет сервер. У этого сервера, как минимум, должно быть два порта: один порт получает картинку от какой-нибудь спутниковой антенны, а второй порт раздает эту картинку в нашу IP-сеть. Первый порт на рисунке не показан, да и сейчас он нам не интересен.
А вот второй порт нам интересен. Он транслирует каналы в нашу сеть, второй порт обычно называют источником. Сейчас всё огрубим и будем говорить, что порт просто транслирует каналы в сеть. За каждым ТВ каналом, который в сеть транслируется, закрепляется multicast IP-адрес. Пусть наш сервер транслирует три канала:
- Первый канал, за ним закреплен IP-адрес 239.0.1.1.
- У второго канала будет адрес 239.0.2.1.
- Третьему каналу провайдер назначил адрес 239.0.3.1.
Нужно учесть и то, что для трансляции одного канала требуется полоса пропускания определенной ширины, то есть на трансляцию одного канала тратится кусочек существующей полосы пропускания, пусть у нас каждый канал забирает 4 Мбит/c. Итак, у нас есть три мультикаст группы, для каждой из которых требуется по 4 Мбит/c. Представим, что все наши конечные узлы купили у провайдера услугу IPTV, но не все и не всегда что-то смотрят. Допустим компьютеры PC8, PC11 и PC17 (зеленая группа) сейчас смотрят первый канал, значит они являются подписчиками первой multicast группы или иначе – они состоят в первой группу. Ко второй группе (смотреть второй канал) у нас будут относиться PC10 и PC12 (красная группа). А третий канал у нас будут смотреть PC14 и PC15 (желтая группа).
4.8.16 Схема для демонстрации Multicast взаимодействия
Да, рисунок чутка корявый, но давайте попробуем разобраться. Конечные устройства, на которых пользователи смотрят каналы называются подписчиками, это может быть как обычный компьютер или ноутбук, так и IPTV приставка, называемая STB. Для простоты пусть это будет компьютер.
Представим, что в нашей сети еще никто ничего не смотрит, а это значит, что сервер еще ничего не транслирует в сторону своего первого маршрутизатора. Когда пользователь PC8 осознает, что он хочет смотреть первый канал, он открывает IPTV-плеер и выбирает в нем первый канал, в этот момент компьютер осознает, что нужно послать запрос серверу о том, что он хочет быть подписчиком группы 239.0.1.1. При этом unicast связь между сервером и компьютером PC8 уже должна быть, иначе как дойдет запрос до сервера о том, что кто-то чего-то хочет смотреть.
Тогда сервер начинает транслировать первый канал в сторону маршрутизатора, пусть это будет называться потоком, но сервер не просто транслирует поток 239.0.1.1, но еще и сообщает маршрутизатору, что этот поток нужно перенаправить в сторону узла PC8 с unicast IP-адресом PC8.
Что будет, когда пользователь PC17 захочет посмотреть первый канал? Правильно, он пошлет запрос серверу о том, что хочет быть подписчиком multicast группы 239.0.1.1. При этом сервер понимает, что этот поток он уже транслирует на маршрутизатор и он просто дает указание маршрутизатору: друг, смотри, первый поток, который я тебе отдаю, нужно транслировать не только на unicast адрес PC8, но еще и на unicast адрес PC17. Маршрутизатор скажет, окей, я получаю от тебя первый поток, но теперь буду направлять его не только влево, но и вправо. При этом обратите внимание: у нас появилось два подписчика, но объем трафика между сервером и первым маршрутизатором не возрос.
Теперь у нас включается PC11 и говорит серверу: я хочу смотреть первый канал. Сервер понимает, что он уже транслирует первый канал, поэтому он говорит первому маршрутизатору: я отдаю тебе первый канал, теперь его хочет смотреть еще и узел с unicast адресом PC11. Первый маршрутизатор понимает, что он получает поток первого канала, более того, он понимает, что он уже направил этот поток в сторону PC11, поэтому он просто дает указание левому маршрутизатору: смотри, я отдаю тебе поток первого канала, но теперь тебе его нужно транслировать не только на PC8, но и на PC11. Левый маршрутизатор говорит: окей, я тебя понял, буду отдавать поток первого канала не только вверх, но и вниз.
Давайте теперь посчитаем занятую полосу пропускания. У нас есть три подписчика, которые смотрят один канал, на который требуется 4 Мбит/c. Если бы это был unicast трафик, то между сервером и первым роутером была бы утилизирована полоса в 12 Мбит/c, между левым и первым роутерами утилизировалось бы 8 Мбит/c, а между правым и первым 4 Мбит/c. Посчитать не трудно. Но у нас multicast трафик, он подразумевает, что источник просто транслирует канал, а транзитные узлы его просто копируют в те порты, откуда стучатся подписчики, то есть получатели, поэтому один канал вне зависимости от количества подписчиков в нашем случае всегда будет занимать полосу 4 Мбит/с и не битом больше.
Если вы знакомы с делителями телевизионного сигнала, который передается по коаксиальным проводам, то здесь принцип похожий: у нас есть один источник и есть транзитные узлы, которые выполняют роль делителей сигнала. Но если говорить про настоящие делители, то это пассивные устройства и деление происходит с потерями, то есть при прохождении через делитель сигнал неизбежно будет затухать. Маршрутизаторы устройства активные и они не просто делят сигнал, а создают его копию.
Не стоит воспринимать данный раздел как подробное описание работы multicast в IP-сетях. Это скорее грубый и поверхностный взгляд с большими неточностями. Так, например, клиенты не запрашивают каналы у сервера, ведь сервер просто вещает потоки, а клиенты обращаются к ближайшему маршрутизатору при помощи протокола IGMP, если между ближайшим маршрутизатором к клиенту и сервером есть еще L3 устройства, то взаимодействие между ними происходит по протоколу PIM.
4.8.6 Anycast взаимодействие или доставка ближайшему узлу из группы
Anycast трафик практически не используется в IPv4, по факту здесь этот механизм и не реализован. Но в IPv6 это упущение учли и описали как должны действовать устройства при взаимодействии anycast. Здесь мы не будем касаться IPv6, а поговорим про частный случай реализации anycast в сетях IPv4. Схематично взаимодействие anycast показано на Рисунке 4.8.17.
4.8.16 Anycast взаимодействие между узлами компьютерной сети
Вы часто можете встретить такую фразу: anycast взаимодействие означает, что узел будет посылать запрос ближайшему узлу из группы. Читая определение можно вспомнить, что группы есть в multicast и сделать вывод о том, что сообщение должно быть послано ближайшему узлу из multicast группы, но это будет неверное понимание сути anycast.
Давайте сперва разберемся, что понимается под группой? В данном случае под группой будет правильнее понимать узлы, которые оказывают одинаковые услуги. Например, в IPv4 anycast взаимодействие реализовано с корневыми DNS-серверами. Зачем реализовано такое взаимодействие? Да всё просто, чтобы уменьшить нагрузку на корневые DNS-сервера.
В мире всего существует тринадцать корневых DNS-серверов. Доменные имена этих DNS-серверов имеют вид letter.root-servers.net, где вместо letter нужно подставить букву от a до m. Если не ошибаюсь, то все корневые сервера находятся на территории США, представьте, что бы было, если бы компьютер из России делал каждый раз запрос к серверу из США, чтобы узнать IP-адрес домена? Всем было бы плохо. Поэтому каждый из тринадцати оригинальных DNS-серверов имеет свои точные копии в различных точках нашей планеты, чтобы заходя на сайт васька-пупкин.рф, вы не делали запрос к серверу из США, а обращались к копии этого сервера где-нибудь в России.
Для примера возьмем корневой DNS сервер К. Его копии находятся в: Амстердаме, Лондоне, Токио, Дели, Майами, Рейкьявике, Новосибирске, Хельсинки и еще нескольких других городах. Все копии DNS-серверов полностью идентичны, в том числе у них одинаковые IP-адреса, в частности у сервера К вот такой IPv4 адрес: 193.0.14.129. Но как так, спросите вы, ведь ты говорил, что IP-адрес должен быть уникальным в пределах той сети, в которой он находится. Да, должен, но всегда, есть исключения из общих правил.
Благодаря тому, что есть anycast взаимодействие, DNS-запросы из Якутии скорее всего пойдут в Новосибирск, а из Ливерпуля в Лондон. То есть в данном конкретном примере anycast взаимодействия группа узлов в различных городах имеет одинаковый IP-адрес: 193.0.14.129, этот адрес их как раз-таки и объединяет в группу. И получается, что обычные узлы, выполняя DNS-запросы, даже не подозревают, что это anycast, никаких механизмов чтобы это понять у узлов нет.
Но за счет чего получается, ситуация, при которой не возникает конфликта IP-адресов. А дело всё в том, что маршрутизатор из всех известных ему маршрутов, полученных от всех своих соседей, выберет наикратчайший маршрут до узла назначения. Сейчас это может показаться непонятным, но если вы разберетесь с динамической маршрутизацией и принципами ее работы, то всё встанет на свои места.
4.8.7 Loopback интерфейсы и loopback адреса
Loopback интерфейс и loopback IP-адрес – это виртуальный интерфейс, который всегда доступен, если доступно само устройство и его сетевые библиотеки работают корректно. Иногда вы можете встретить словосочетание петлевой интерфейс/адрес, циклический и даже кольцевой, всё это про loopback. В протоколе IPv4 выделена целая сеть 127.0.0.0/8 для программной реализации loopback интерфейсов на конечных узлах. Так, например, если у вас есть компьютер под управлением Windows, вы можете попробовать пропинговать любой IP-адрес из указанного диапазона и получить ответ от машины в том случае, если сетевые библиотеки вашего ПК будут работать нормально.
C:\Users\Dell>ping 127.0.0.1 Обмен пакетами с 127.0.0.1 по с 32 байтами данных: Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128 Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128 Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128 Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128 Статистика Ping для 127.0.0.1: Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь) Приблизительное время приема-передачи в мс: Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек C:\Users\Dell>ping 127.255.255.254 Обмен пакетами с 127.255.255.254 по с 32 байтами данных: Ответ от 127.255.255.254: число байт=32 время<1мс TTL=128 Ответ от 127.255.255.254: число байт=32 время<1мс TTL=128 Ответ от 127.255.255.254: число байт=32 время<1мс TTL=128 Ответ от 127.255.255.254: число байт=32 время<1мс TTL=128 Статистика Ping для 127.255.255.254: Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь) Приблизительное время приема-передачи в мс: Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
C:\Users\Dell>ping 127.0.0.1
Обмен пакетами с 127.0.0.1 по с 32 байтами данных: Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128 Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128 Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128 Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128
Статистика Ping для 127.0.0.1: Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь) Приблизительное время приема-передачи в мс: Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек
C:\Users\Dell>ping 127.255.255.254
Обмен пакетами с 127.255.255.254 по с 32 байтами данных: Ответ от 127.255.255.254: число байт=32 время<1мс TTL=128 Ответ от 127.255.255.254: число байт=32 время<1мс TTL=128 Ответ от 127.255.255.254: число байт=32 время<1мс TTL=128 Ответ от 127.255.255.254: число байт=32 время<1мс TTL=128
Статистика Ping для 127.255.255.254: Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь) Приблизительное время приема-передачи в мс: Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек |
Когда вы пингуете IP-адреса из диапазона 127.0.0.0/8, вы пингуете сами себя, в Windows такой адрес иногда называют localhost, так как он используется для реализации взаимодействия клиент-сервер в рамках одной машины. Так, например, вы можете установить на свою машину MySQL сервер и делать SQL запросы локально при помощи адреса из диапазона 127.0.0.0/8 и TCP порта 3306, который слушает MySQL по умолчанию. Таким образом получается, что и клиент, и сервер используют один IP-адрес, но разные порты.
Различные веб-сервера типа Денвера или AMPPS в Windows используют адрес из диапазона 127.0.0.0/8. То есть на конечных узлах loopback адреса и loopback интерфейсы используются для того, чтобы была возможность обратиться самому к себе. Если говорить про транзитные узлы, то там зачастую IP-адреса из диапазона 127.0.0.0/8 недоступны, то есть там по умолчанию вообще не созданы loopback интерфейсы, их создает администратор вручную, но при этом он может задать loopback интерфейсу тот IP-адрес, который ему хочется, стоит заметить, что в маршрутизаторах у loopback интерфейсов несколько иной функционал, нежели на конечных узлах.
Чаще всего loopback интерфейсы создаются для того, чтобы обеспечить надежную связь с внешним миром. Так, например, в протоколе BGP, чтобы реализовать iBGP соединение используют loopback интерфейсы, которые будут доступны до тех пор, пока не упадут все физические линки, а, следовательно, и iBGP соединение не разорвется до тех пор, пока хотя бы один линк к этому маршрутизатору жив. Также очень часто loopback интерфейсы используется для того, чтобы получить доступ к устройству для его удаленного администрирования. Когда мы будем говорить про настройку IP-адресов на интерфейсах маршрутизаторов Cisco мы поработаем и с loopback интерфейсами.
4.8.8 Выводы
Самыми интересными для нас на данном этапе будут multicast и broadcast IP-адреса, а также loopback интерфейсы, именно с этим всем мы будем работать. Anycast мы оставим до знакомства с IPv6, а multicast вообще больше трогать не будем, возможно, в блоге появится отдельная серия публикаций про multicast, но это далеком идущие планы.
Сетевые настройки | Русскоязычная документация по Ubuntu
Сетевые настройки
Ubuntu поставляется с набором графических утилит для настройки ваших сетевых устройств. Этот документ предназначен для серверных администраторов и сфокусирован на управлении вашей сетью через командную строку.
Интерфейсы Ethernet
Интерфейсы Ethernet идентифицируются системой с использованием имен ethX, где X является числовым значением. Первый интерфейс обычно обозначается как eth0, второй как eth2, и все последующие с увеличивающимися номерами по порядку.
Определение Ethernet интерфейсов
Для быстрого определения всех доступных сетевых интерфейсов вы можете использовать команду ifconfig как показано ниже.
ifconfig -a | grep eth eth0 Link encap:Ethernet HWaddr 00:15:c5:4a:16:5a
Другое приложение, которое может помочь идентифицировать все доступные вашей системе сетевые интерфейсы, это команда lshw. В примере ниже lshw показывает один Ethernet интерфейс с логическим именем eth0 вместе с информацией по шине, деталями драйвера и всеми поддерживаемыми возможностями.
sudo lshw -class network *-network description: Ethernet interface product: BCM4401-B0 100Base-TX vendor: Broadcom Corporation physical id: 0 bus info: pci@0000:03:00.0 logical name: eth0 version: 02 serial: 00:15:c5:4a:16:5a size: 10MB/s capacity: 100MB/s width: 32 bits clock: 33MHz capabilities: (snipped for brevity) configuration: (snipped for brevity) resources: irq:17 memory:ef9fe000-ef9fffff
Логические имена интерфейсов Ethernet
Логические имена интерфейсов настраиваются в файле /etc/udev/rules.d/70-persistent-net.rules. Если вы захотите определить какой интерфейс получит определенное логическое имя, найдите строку по совпадению физического MAC адреса интерфейса и измените значение NAME=ethX на желаемое логическое имя. Перегрузите систему для применения изменений.
Настройки интерфейса Ethernet
ethtool — это программа, которая показывает и изменяет настройки сетевых карт, такие как автоопределение, скорость порта, режим дуплекса и функция Wake-on-LAN (пробуждение системы через сеть). Эта программа не устанавливается по умолчанию, но доступна к установке из репозиториев.
sudo apt-get install ethtool
Ниже приведен пример как посмотреть возможности карты и настроить параметры интерфейса Ethernet.
sudo ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: g Wake-on: d Current message level: 0x000000ff (255) Link detected: yes
Изменения, сделанные с использованием команды ethtool, временные и будут утеряны после перезагрузки. Если вы хотите сохранить настройки, просто добавьте требуемую команду ethtool в строку pre-up в файле /etc/network/interfaces.
Ниже приведен пример как интерфейс, определенный как eth0, может быть постоянно настроен на скорость порта 1000Мб/с в режиме полного дуплекса.
auto eth0 iface eth0 inet static pre-up /sbin/ethtool -s eth0 speed 1000 duplex fullНесмотря на то, что пример выше показывает интерфейс, настроенный статично, это работает и с другими методами, такими как DHCP. Этот пример слишком примитивен, чтобы продемонстрировать всю важность и возможности использования строки pre-up по отношению к настройке интерфейсов.
Адресация IP
Следующая секция описывает процесс настройки IP адреса вашей системы и шлюза по умолчанию, необходимые для подключения к локальной сети и интернету.
Временное назначение IP адреса
Для временной настройки сети вы можете использовать стандартные команды, такие как ip, ifconfig и route, которые присутствуют также и в других системах на базе GNU/Linux. Эти команды позволят изменить настройки, которые будут применены мгновенно, но они не будут постоянными и будут утеряны после перезагрузки.
Для временной настройки IP адреса вы можете использовать команду ifconfig следующим образом. Только замените IP адрес и маску подсети на соответствующие требованиям вашей сети.
sudo ifconfig eth0 10.0.0.100 netmask 255.255.255.0
Для проверки настройки IP адреса eth0 вы можете использовать команду ifconfig таким образом:
ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:15:c5:4a:16:5a inet addr:10.0.0.100 Bcast:10.0.0.255 Mask:255.255.255.0 inet6 addr: fe80::215:c5ff:fe4a:165a/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:466475604 errors:0 dropped:0 overruns:0 frame:0 TX packets:403172654 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2574778386 (2.5 GB) TX bytes:1618367329 (1.6 GB) Interrupt:16
Для настройки шлюза по умолчанию вы можете использовать команду route следующим образом. Измените адрес шлюза по умолчанию на требуемый для вашей сети.
sudo route add default gw 10.0.0.1 eth0
Для проверки настройки шлюза по умолчанию используйте команду route таким образом:
route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.0.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0 0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 eth0
Если вам требуется DNS для временной настройки сети, вы можете добавить IP адреса DNS серверов в файл /etc/resolv.conf. Пример ниже показывает как указать два DNS сервера в /etc/resolv.conf, которые могут быть заменены на сервера использующиеся в вашей сети. Более пространное описание настройки DNS клиента приведено в следующей секции.
nameserver 8.8.8.8 nameserver 8.8.4.4
Если вам больше не требуется эта конфигурация и вы хотите отменить все IP настройки интерфейса, вы можете использовать команду ip с опцией flush как показано ниже:
ip addr flush eth0
Сброс IP настроек с использованием команды ip не очистит содержимое /etc/resolv.conf. Вам придется удалять или менять эти значения вручную.
Динамическое присвоение IP адреса (клиент DHCP)
Чтобы настроить ваш сервера на использование DHCP для динамического присвоения адреса, добавьте dhcp метод в адресную секцию inet для соответствующего интерфейса в файле /etc/network/interfaces. Пример ниже предполагает, что вы настраиваете ваш первый интерфейс Ethernet, обозначенный как eth0.
auto eth0 iface eth0 inet dhcp
Добавив настройку интерфейса как показано выше, вы можете вручную включить интерфейс командой ifup, которая активизирует процесс DHCP через dhclient.
sudo ifup eth0
Для отключения интерфейса вручную вы можете воспользоваться командой ifdown, которая запустит процесс освобождения DHCP и остановки интерфейса.
sudo ifdown eth0
Статическое присвоение IP адреса
Для настройки вашей системы под использование статического присвоения IP адреса добавьте метод static в секцию inet для соответствующего интерфейса в файле /etc/network/interfaces. Пример ниже предполагает, что вы настраиваете ваш первый интерфейс Ethernet, обозначенный как eth0. Измените значения адреса, маски сети и шлюза для соответствия требованиям вашей сети.
auto eth0 iface eth0 inet static address 10.0.0.100 netmask 255.255.255.0 gateway 10.0.0.1
Добавив настройку интерфейса как показано выше, вы можете вручную включить интерфейс командой ifup.
sudo ifup eth0
Для отключения интерфейса вручную вы можете воспользоваться командой ifdown.
sudo ifdown eth0
Интерфейс Loopback (обратной петли)
Интерфейс loopback определяется системой как lo и по умолчанию задает адрес 127.0.0.1. Он может быть выведен командой ifconfig.
ifconfig lo lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:2718 errors:0 dropped:0 overruns:0 frame:0 TX packets:2718 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:183308 (183.3 KB) TX bytes:183308 (183.3 KB)
По умолчанию может присутствовать две строки в /etc/network/interfaces отвечающих за автоматическую настройку интерфейса loopback. Рекомендуется оставить эти настройки без изменений пока не возникнет специфической причины для их изменения. Пример этих двух строк приведен ниже.
auto lo iface lo inet loopback
Разрешение имен
Под разрешением имени по отношению к IP сетям подразумевается процесс определения IP адреса по имени хоста, упрощающий идентификацию ресурса в сети. Данная секция раскрывает как правильно настроить вашу систему для разрешения имен с помощью DNS и статических записей имен хостов.
Настройка клиента DNS
Традиционно файл /etc/resolv.conf был статическим файлом настроек, который очень редко требовалось изменять или он менялся автоматически по запросам DHCP клиента. В настоящее время компьютер может переключаться с одной сети на другу слишком часто и структура resolveconf теперь используется для отслеживания этих изменений и автоматического обновления настроек разрешений. Это выглядит как промежуточный слой между программами, которые предоставляют информацию от серверов имен, и приложениями, которым она требуется. Resolvconf делает доступной информацию через подключение сценариев, связанных с настройкой сетевых интерфейсов. Наиболее значимое отличие для пользователя в том, что любые ручные изменения /etc/resolv.conf будут потеряны при перезаписи по каждому срабатыванию триггеров resolveconf. Вместо этого resolveconf использует ловушки клиента DHCP и /etc/network/interfaces для генерации списка серверов имен и доменов, чтобы положить в /etc/resolv.conf, который теперь является символьной ссылкой:
/etc/resolv.conf -> ../run/resolvconf/resolv.conf
Для настройки разрешений добавьте IP адреса серверов имен, соответствующие вашей сети, в файл /etc/network/interfaces. Вы также можете добавить необязательный список подбора DNS суффиксов для получения доменных имен. Для каждой другой разрешенной опции настройки resolv.conf вы можете добавить внутри абзаца по отдельной строке с этой опцией с префиксом имени dns-. Результирующий файл может выглядеть так:
iface eth0 inet static address 192.168.3.3 netmask 255.255.255.0 gateway 192.168.3.1 dns-search example.com dns-nameservers 192.168.3.45 192.168.8.10
Опции поиска также могут использоваться разные доменные имена, таким образом DNS запросы будут дополняться ими в том порядке, как они вводились. Например, ваша сеть может иметь несколько поддоменов для поиска; родительский домен example.com и два поддомена sales.example.com и dev.example.com.
Если у вас несколько доменов, в которых вы собираетесь искать, ваша конфигурация может выглядеть так:
iface eth0 inet static address 192.168.3.3 netmask 255.255.255.0 gateway 192.168.3.1 dns-search example.com sales.example.com dev.example.com dns-nameservers 192.168.3.45 192.168.8.10
Если вы попытаетесь проверить хост с именем server1, ваша система автоматически запросит DNS по их полным доменным именам (FQDN) в следующем порядке:
server1.sales.example.com
Если совпадений не будет, DNS сервер предоставит результат notfound и запрос DNS потерпит неудачу.
Статические имена хостов
Статические имена хостов — это локально определенные соотношения «имя хоста-IP», находящиеся в файле /etc/hosts. Значения, определенные в файле hosts, по умолчанию превалируют над DNS. Это означает, что если система пытается разрешить имя и находит его в /etc/hosts, она не будет пытаться смотреть записи в DNS. В некоторых конфигурациях, особенно когда доступ в интернет не требуется, сервера, соединенные с ограниченным количеством ресурсов, могут просто использовать статический список имен вместо DNS.
Далее приведен пример файла hosts, где ряд локальных серверов определены обычными именами хостов, алиасами и их эквивалентами полных имен (FQDN).
127.0.0.1 localhost 127.0.1.1 ubuntu-server 10.0.0.11 server1 vpn server1.example.com 10.0.0.12 server2 mail server2.example.com 10.0.0.13 server3 www server3.example.com 10.0.0.14 server4 file server4.example.com
В примере выше обратите внимание, что каждый сервер имеет алиас в добавок к их правильным коротким и полным именам. server1 соотносится с именем vpn, server2 определен как mail, server3 как www и server4 как file.
Настройка переключения сервиса имен
Последовательность, в которой ваша система выбирает метод разрешения имен по IP адресам управляется настроечным файлом переключателя сервиса имен (NSS) /etc/nsswitch.conf. Как отмечено в предыдущей секции, обычно статические имена хостов, определенные в системном файле /etc/hosts, имеют приоритет перед разрешением имен через DNS. Далее пример строки, отвечающей за этот порядок перебора имен хостов в файле /etc/nsswitch.conf.
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
files сперва пытается разрешить статическое имя хоста в /etc/hosts.
mdns4_minimal пытается разрешить имя с использованием параллельного (multicast) DNS.
[NOTFOUND=return] означает, что любой ответ notfound, предшествующий процессу mdns4_minimal, должен считаться значимым (авторитетным) и что система не будет пытаться продолжать искать ответ.
dns представляет собой наследуемый последовательный (legacy unicast) DNS запрос.
mdns4 представляет параллельный (multicast) DNS запрос.
Для изменения последовательности вышеупомянутых методов разрешения имен вы можете просто заменить строку hosts: на значение по вашему выбору. Например, если вы предпочитаете использовать последовательный DNS до параллельного DNS, вы можете изменить строку в /etc/nsswitch.conf как показано ниже:
hosts: files dns [NOTFOUND=return] mdns4_minimal mdns4
Строительство мостов 🙂
Соединение нескольких интерфейсов — наиболее продвинутая настройка, но очень полезная во множестве сценариев. Один вариант — установка взаимодействия между несколькими сетевыми интерфейсами и затем использование защитного экрана (firewall) для фильтрования трафика между двумя сегментами сети. Другой сценарий — использование связывания на системе с одним интерфейсом для разрешения виртуальным машинам иметь прямой доступ во внешнюю сеть. Следующий пример раскрывает последний сценарий.
Перед настойкой взаимодействия вам потребуется установить пакет bridge-utils. Для установки пакета введите в терминале:
sudo apt-get install bridge-utils
Далее настройте взаимодействие, отредактировав /etc/network/interfaces:
auto lo iface lo inet loopback auto br0 iface br0 inet static address 192.168.0.10 network 192.168.0.0 netmask 255.255.255.0 broadcast 192.168.0.255 gateway 192.168.0.1 bridge_ports eth0 bridge_fd 9 bridge_hello 2 bridge_maxage 12 bridge_stp off
Введите значения соответствующие вашим физическому интерфейсу и сети.
Теперь перезапустите сеть для разрешения взаимодействия интерфейсов:
sudo /etc/init.d/networking restart
Теперь новый мост между интерфейсами поднят и работает. Утилита brctl предоставит полезную информацию о статусе моста, определяет какие интерфейсы участвуют во взаимодействии и т.д. Смотрите man brctl для дополнительной информации.
Ссылки
Страница Ubuntu Wiki Network содержит ссылки на заметки по более продвинутым настройкам сети.
Страница resolvconf man содержит больше информации по resolvconf.
Страница interfaces man содержит детали по дополнительным опциям для /etc/network/interfaces.
Страница dhclient man содержит детали по большему количеству опций для настройки DHCP клиента.
Для дополнительной информации по настройке DNS клиента смотрите страницу resolver man. Также 6 глава руководства O’Reilly Администрирования сетей Linux является хорошим источником по разрешению имен и настройке сервиса имен.
Для дополнительной информации по сетевому связыванию смотрите страницу brctl man и страницу Net:Bridge от Linux Foundation.
Сетевой интерфейс — Xgu.ru
Материал из Xgu.ru
Сетевой интерфейс — физическое или виртуальное устройство, предназначенное для передачи данных между программами через компьютерную сеть.
Примеры сетевых интерфейсов:
- Физические интерфейсы сетевых карт и телекоммуникационных устройств (коммутаторов, маршрутизаторов и так далее)
- Петлевые интерфейсы для обмена данными между процессами на одном компьютере или управляемом сетевом устройстве. Для них выделена специальная подсеть 127.0.0.0/8
- Туннели — для инкапсуляции протокола того же или более низкого уровня в другой протокол
- Интерфейсы виртуальных сетей (VLAN)
Каждый интерфейс в сети может быть однозначно идентифицирован по его адресу. Разные сетевые протоколы используют разные системы адресации, например MAC-адреса в Ethernet или IP-адреса в IP.
Настройка сетевых интерфейсов в UNIX/Linux-системах традиционно выполняется с помощью команды ifconfig, а в Linux ещё и при помощи команды ip.
[править] Сетевой интерфейс в Linux
Сетевое взаимодействие Linux-компьютера происходит через сетевые интерфейсы. Любые данные, которые компьютер отправляет в сеть или получает из сети проходят через сетевой интерфейс.
Интерфейс определён реализацией модели TCP/IP для того чтобы скрыть различия в сетевом обеспечении и свести сетевое взаимодействие к обмену данными с абстрактной сущностью.
Для каждого устройства, поддерживаемого ядром, существует сетевой интерфейс. Существует соглашение о наименовании интерфейсов, в соответствии с которым имя интерфейса состоит из префикса, характеризующего его тип, и числа, соответствующего номеру интерфейса данного типа в системе. Так, например, ppp0 соответствует первому интерфейсу PPP, а eth2 соответствует интерфейсу второго сетевого адаптера Ethernet. Обратите внимание на то, что нумерация интерфейсов начинается с 0.
[править] Наименования сетевых интерфейсов в Linux
Начиная с середины 2011 года (Fedora 15) в Linux используется новая схема наименования интерфейсов. Интерфейсы называются em[1234] (для интегрированных) или pci<slot>#<port>_<vf> (для навесных). Подробнее: [1], [2], [3]. |
- lo
- Интерфейс петли обратной связи.
- eth
- Сетевой интерфейс к карте Ethernet или картам WaveLan (Radio Ethernet).
- tr
- Сетевой интерфейс к карте Token Ring.
- ppp
- Сетевой интерфейс к каналу PPP (Point-to-Point Protocol).
- sl
- Сетевой интерфейс к каналу SLIP (Serial Line IP).
- plip
- Сетевой интерфейс к каналу PLIP (Parallel Line IP). Используется для организации сетевого взаимодействия с использованием параллельного порта.
- ax
- Сетевой интерфейс к устройствам любительского радио AX.25.
- fddi
- Сетевой интерфейс к карте FDDI
- arc0e, arc0s
- Сетевой интерфейс к карте ArcNet. Используется инкапсуляция пакетов в формате Ethernet или RFC 1051.
- wlan
- Сетевой интерфейс wi-fi адаптеров
Интерфейсы создаются автоматически для каждого обнаруженного сетевого устройства при загрузке ядра ОС.
Каждый интерфейс характеризуется определёнными параметрами, необходимыми для обеспечения его нормального функционирования, и в частности для сетевого обмена данными по протоколу IP.
[править] Параметры интерфейса
- IP-адрес
- Адрес IP, соответствующий данному сетевому интерфейсу. Пакеты, отправленные по этому адресу, поступят на соответствующий интерфейс
- Маска подсети
- Битовая маска, необходимая для вычисления маршрута передачи IP-пакета
- Широковещательный адрес
- Адрес, используемый при широковещательной рассылке пакетов через интерфейс.
- Метрика
- Условная характеристика интерфейса соответствующая уровню затрат при передаче информации через него. Используется при маршрутизации пакетов, для выбора оптимального маршрута.
- MTU
- Maximum Transfer Unit. Максимальный размер блока данных обрабатываемого интерфейсом. Наибольшее значение MTU определяется типом интерфейса (например, для Ethernet MTU=1500), но может быть искусственно снижено.
- MAC-адрес
- Аппаратный адрес сетевого устройства, соответствующего интерфейсу (для которых это имеет смысл).
Кроме этих параметров интерфейс характеризуется ещё:
- Флагами, которые определяют состояния устройства, например такие как: включен ли интерфейс (Up/Down), находится ли он в неразборчивом режиме (promiscuous/nonpromiscuous)
- Аппаратными характеристиками, такими как адрес памяти, номер IRQ, DMA, порт ввода/вывода;
- Статистической информацией, характеризующей различные аспекты работы интерфейса. Например, количество переданных/полученных байтов/пакетов, число переполнений, коллизий и др. с момента создания интерфейса.
Debian. Долговременные настройки хранятся в файле /etc/network/interfaces.
[править] Программа ifconfig
Для управления интерфейсами в ОС Linux используется программа ifconfig. Команда позволяет как получать диагностическую информацию об интерфейсах системы, так и выполнять их настройку.
Формат вызова команды:
- ifconfig
- ifconfig interface options
Для получения информации, программа ifconfig может вызываться простым пользователем. Файл ifconfig находится в каталоге /sbin, поэтому, чаще всего, при вызове нужно указывать абсолютное путевое имя. |
При вызове без параметров, программа выводит на экран информацию обо всех активных (up) интерфейсах. Если указано имя интерфейса, но отсутствуют options, выводится информация только о нем одном.
$ ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:01:02:B4:61:10 inet addr:10.0.0.188 Bcast:10.255.255.255 Mask:255.0.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1347443 errors:0 dropped:0 overruns:0 frame:0 TX packets:865328 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:830641609 (792.1 Mb) TX bytes:72315353 (68.9 Mb) Interrupt:10 Base address:0xcc00
Формат вывода информации о интерфейсе программой ifconfig:
- Характеристики канального уровня
- Канальный уровень Link encap. Аппаратный MAC-адрес устройства HWaddr
- Характеристики сетевого уровня
- IP-адрес интерфейса inet addr; широковещательный адрес интерфейса Bcast; маска подсети интерфейса Mask
- Флаги, метрика и MTU
- Список установленных флагов интерфейса: включён UP; принимает широковещательные пакеты BROADCAST; принимает групповые пакеты MULTICAST. Среди списка установленных флагов может присутствовать слово PROMISC, означающее, что интерфейс работает в неразборчивом режиме. Установленный размер максимального блока, передаваемого через интерфейс MTU и метрика интерфейса Metric.
- Информация о полученных пакетах RX
- Число пакетов packets, ошибок errors, отброшенных пакетов dropped, переполнений overruns. Такое назначение полей соответствует только сетям Ethernet. В других сетях, смысл может отличаться.
- Информация об отправленных пакетах
- Число пакетов packets, ошибок errors, отброшенных пакетов dropped, переполнений overruns, потерь несущей carrier, коллизий collisions ; объем буфера передачи txqueuelen. Такое назначение полей соответствует только сетям Ethernet. В других сетях, смысл может отличаться.
- Объем переданных данных
- Количество байтов полученных RX bytes и отправленных TX bytes через интерфейс
- Аппаратные параметры
- Номер линии IRQ Interrupt и адрес памяти Base address
Если в командной строке ifconfig указаны options, выполняется настройка интерфейса. В процессе настройки можно изменить режим работы интерфейса, настройки IP-адреса и другие характеристики.
Перед списком опций в командной строке ifconfig следует обязательно указать имя интерфейса, к которому они применяются. В команде может быть указано имя, не больше чем одного интерфейса.
Задаваемые в командной строке options выглядят как набор ключевых слов с дополнительными параметрами. Последовательность ключевых слов в строке не имеет значения, хотя и существует общепринятый порядок.
[править] Аргументы командой строки ifconfig
- interface
- Имя интерфейса, к которому применяется действие программы ifconfig.
- up | down
- Включает/выключает интерфейс.
- address
- IP-адрес, который назначается интерфейсу.
- netmask address
- Устанавливает значение сетевой маски для интерфейса равному значению address.
- [-]broadcast [address]
- Устанавливает значение широковещательного адреса равному значению address. Если дополнительный аргумент address отсутствует, включает или выключает работу интерфейса в широковещательном режиме.
- [-]promisc
- Включает/выключает неразборчивый режим работы интерфейса.
- [-]arp
- Разрешает/запрещает использование протокола ARP по этому интерфейсу.
- metric N
- Устанавливает метрику интерфейса равной N.
- mtu N
- Устанавливает значение MTU интерфейса равным N
- irq N
- Установить IRQ устройства равным N (если позволяет драйвер устройства)
- io_addr address
- Установить адрес ввода-вывода, равным параметру address (если позволяет драйвер устройства)
- media type
- Задать тип физической среды передачи данных (если позволяет драйвер устройства)
При изменении IP-адреса интерфейса автоматически изменяются значения его маски и широковещательного адреса. Если параметры netmask и broadcast не указаны явно, соответствующие значения вычисляются исходя из класса IP-адреса. Например, для IP-адреса 200.200.200.200, который относится к диапазону адресов класса C, значения сетевой маски и широковещательного адреса будут соответственно равны 255.255.255.0 и 200.200.200.255, а для адреса 1.2.3.4 (адрес класса A), равны соответственно 255.0.0.0 и 1.255.255.255.
Более тонкую настройку интерфейса можно произвести при помощи утилиты ip
[править] Пример использования ifconfig
Просмотр информации обо всех интерфейсах
$ ifconfig
Просмотр информации об интерфейсе eth0:
$ ifconfig eth0
Назначить IP-адрес 10.0.0.1 первой Ethernet-карте:
# ifconfig eth0 10.0.0.1
Интерфейс не включается автоматически. Если необходимо включить интерфейс, в командной строке следует явно указать параметр up:
# ifconfig eth0 10.0.0.1 up
Значения широковещательного адреса и сетевой маски будут определены автоматически на основе информации о классе адреса. Если необходимо явно задать маску, например, ограничить размер сети 14 хостами (4 бита на хост), нужно использовать команду:
# ifconfig eth0 10.0.0.1 netmask 255.255.255.240 broadcast 10.0.0.15
Запретить использование ARP на интерфейсе eth0:
# ifconfig eth0 -arp
Перевести интерфейс в неразборчивый режим:
# ifconfig eth0 promisc
[править] Создание сетевого интерфейса
Интерфейс создается ядром автоматически при обнаружении устройства. Для того чтобы устройство было доступно, необходимо включить его драйверную поддержку в состав ядра. Это может быть сделано в момент сборки ядра или при работе системы с использованием механизма загружаемых модулей.
Если устройств, обеспечивающих одинаковый тип интерфейса, несколько, их автоматическое определение не производится. |
При использовании нескольких устройств одного типа нужно произвести их ручную настройку, то есть явным образом назначить интерфейс каждому из них. Это необходимо, поскольку при автоматическом определении устройств порядок привязки к интерфейсам непредсказуем, что недопустимо.
Не путайте интерфейсы и устройства системы. Интерфейсам не соответствуют никакие специальные файлы в каталоге /dev |
Вновь созданный интерфейс является ненастроенным: он выключен и к нему не привязан никакой IP-адрес. Для того чтобы ввести интерфейс в работу, нужно провести его настройку и включить (поднять) его при помощи команды ifconfig.
При настройке интерфейса обычно настраиваются следующие параметры:
- IP-адрес должен быть указан обязательно, поскольку без него использование интерфейса неосуществимо;
- Сетевая маска должна указываться в том случае, если она отличается от той, которая соответствует классу IP-адреса;
- Широковещательный адрес указывается в том случае, если он отличается от широковещательного адреса, вычисляемого на основе значений IP-адреса и сетевой маски.
Эти параметры задаются одной командой, которая при этом, как правило, сразу и включает интерфейс.
# ifconfig eth0 192.168.1.1 up # ifconfig eth2 10.0.0.1 netmask 255.255.255.0 up
[править] Настройка интерфейсов при загрузке системы
Настройки интерфейса, выполненные при помощи ifconfig, автоматически пропадают при выключении компьютера. После того как ядро Linux загружено опять, всю настройку нужно выполнять снова. Обычно она производится автоматически специальными скриптами при загрузке компьютера.
Рассмотренная ниже процедура автоматической настройки сетевых интерфейсов при загрузке выглядит так только в RedHat-based системах. В Slackware и Debian сетевые интерфейсы настраиваются несколько иначе.
Настройка интерфейсов производится скриптом /etc/rc.d/init.d/network, который автоматически вызывается при переходе на 2, 3, 4 или 5 уровень выполнения. Скрипт network при вызове с параметром start поднимает интерфейсы, т.е. выполняет настройку и включение всех описанных интерфейсов, после чего настраивает статическую маршрутизацию.
Конфигурационные файлы интерфейсов могут быть созданы вручную или при помощи псевдографических и графических инструментов настройки, таких как netconfig или neat |
Описание интерфейсов находится в файлах ifcfg-* в каталоге /etc/sysconfig/network-scripts. В названии файла, за символом — следует имя интерфейса, например файл ifcfg-eth0 содержит настройки интерфейса eth0. Файл описания интерфейсов — это небольшой скрипт, содержащий только несколько команд присвоения variable=value где variable — определённый параметр настройки интерфейса, а value — необходимое значение этого параметра.
Параметры интерфейса в файле ifcfg.
- DEVICE
- Имя устройства
- ONBOOT
- Нужно ли инициализировать интерфейс при загрузке (yes | no)
- BOOTPROT
- При динамической настройке тип протокола, при помощи которого должен быть сконфигурирован интерфейс ( bootp | dhcp )
- BOOTP
- Интерфейс необходимо настроить с использованием протокола удаленной загрузки BOOTP
- IPADDR
- IP-адрес, который должен быть присвоен интерфейсу
- NETMASK
- Маска подсети IP-адреса интерфейса
- NETWORK
- Адрес сети интерфейса
- BROADCAST
- Широковещательный адрес интерфейса
Значения NETMASK, NETWORK, BROADCAST могут быть вычислены скриптом ifup автоматически при помощи программы ipcalc, поэтому, если они соответствуют классу IP-адреса, указывать явно их не обязательно
Для настройки интерфейсов во время загрузки компьютера используется скрипт ifup, который принимает в качестве аргумента командной строки имя интерфейса interface.
ifup interface
Он читает конфигурационный файл interface или, если он отсутствует, файл из каталога /etc/sysconfig/networking/default. В крайнем случае, если не найден ни один из этих файлов читается конфигурация из ifcfg-interface. После этого скрипт производит настройку интерфейсов при помощи утилиты ip. Настраиваются не только интерфейсы сами по себе, но и необходимые маршруты для обращения к сетям, непосредственно доступным через интерфейс.
Скрипты ifup и ifdown могут вызываться не только во время загрузки компьютера или при смене уровня выполнения, но и в ходе нормальной работы, когда нужно вручную поднять или опустить интерфейс.
Перезапуск интерфейса eth0:
# ifdown eth0 # ifup eth0
Файлы ifup и ifdown в каталоге /etc/sysconfig/network-scripts являются символическими ссылками на файлы ifup и ifdown в каталоге /sbin. Поэтому, при вызове вручную можно просто воспользоваться командами ifup и ifdown.
При вызове в ходе начальной загрузки, скрипту ifup передается дополнительный аргумент boot, который сообщает, что интерфейс нужно поднимать только в том случае, если в файле его конфигурации параметр ONBOOT не установлен в no.
[править] Файл конфигурации eth0
Вот пример наиболее распространённой конфигурации Ethernet-интерфейса:
DEVICE=eth0 ONBOOT=yes IPADDR=10.0.0.188 NETMASK=255.255.255.0 NETWORK=10.0.0.0 BROADCAST=10.0.0.255
В данном случае файл описывает интерфейс eth0, которому назначен IP-адрес из диапазона рекомендованного для локальных сетей 10.0.0.188. Поскольку адрес принадлежит классу A, а необходимо чтобы под сетевую часть было отведено 24 бита, явным образом задана сетевая маска NETMASK, адрес сети NETWORK и широковещательный адрес BROADCAST.
- /etc/init.d/network — Скрипт, выполняющий настройку сетевых интерфейсов и маршрутизации при загрузке.
- /etc/sysconfig/network — Конфигурационный файл, содержащий имя хоста, IP-адрес основного шлюза и IP-адреса основного и вспомогательного DNS-серверов
- /etc/sysconfig/network-scripts — Каталог, содержащий конфигурационные файлы интерфейсов и скрипты, выполняющие их инициализацию
- /etc/sysconfig/network-scripts/ifup — Скрипт, который выполняет настройку и активацию интерфейса
- /etc/sysconfig/network-scripts/ifdown — Скрипт, который выполняет деактивацию интерфейса
- /etc/sysconfig/network-scripts/ifcfg-* — Конфигурационные файлы, описывающие интерфейсы системы.
[править] Вопросы и ответы
[править] Как создать фиктивный сетевой интерфейс с заданным названием?
Создать tap-интерфейс:
с помощью tunctl:
tunctl -t eth0
С помощью ip:
ip tuntap add dev eth0 mode tap
Создать dummy-интерфейс:
modprobe dummy0 ip l set dev dummy0 name eth0
[править] Дополнительная информация
Сетевой уровень
Опция | Описание |
---|---|
interface | Имя интерфейса. Обычно это имя драйвера, за которым идет номер устройства, например, eth0 для первого интерфейса Ethernet. |
up | Помечает интерфейс как включенный. Это можно использовать для включения интерфейса после ifconfig down. Это происходит автоматически при установке первого адреса интерфейса. Если интерфейс был переустановлен при предыдущей пометке в качестве отключенного, аппаратное обеспечение будет переинициализировано. |
down | Помечает интерфейс как отключенный. Когда интерфейс помечен как отключенный, система не пытается пересылать сообщения через этот интерфейс. При возможности, интерфейс будет переустановлен, чтобы отключить также прием. Это действие не отключает автоматически маршруты, использующие данный интерфейс. |
arp | Включает использование протокола разрешения адреса (Address Resolution Protocol) при сопоставлении адресов на уровне сети и адресов на уровне связи (используется по умолчанию). В настоящее время это реализуется путём сопоставления адресов DARPA Internet и адресов Ethernet 10 Мбит/с. |
-arp | Отключает использование протокола разрешения адреса (Address Resolution Protocol). |
promisc | Помещает интерфейс в состояние promiscuous. В широковещательной сети это заставляет интерфейс получать все пакеты независимо от того, были ли они предназначены для этой машины или нет. Это позволяет, используя фильтры пакетов, анализировать сетевой трафик. Обычно, это хорошая техника охоты на сетевые проблемы, которые иначе трудно отловить. Здесь весьма полезна утилита tcpdump. С другой стороны, это позволяет хакерам исследовать движение паролей по сети и делать другие черные дела. Одна защита против этого типа нападения: не позволять присоединяться к сети чужим компьютерам. Другой способ: использовать безопасные опознавательные протоколы, типа Kerberos, или SRA login. Эта опция соответствует флагу PROMISC. |
-promisc | Запрещает режим promiscuous. |
allmulti | Включает или отключает режим all-multicast. В этом режиме все многоадресные (multicast) пакеты в сети будут приниматься этим интерфейсом. |
-allmulti | Отключает режим all-multicast. |
metric N | Устанавливает стоимость маршрутизации для интерфейса равной n, вместо стандартного значения 0. Стоимость маршрутизации (routing metric) используется протоколом маршрутизации (см. routed). Большие стоимости делают маршрут менее предпочтительным; стоимости учитываются как дополнительные пересылки на пути к целей сети или хосту. |
mtu N | Этот параметр устанавливает максимальный размер пакета (maximum transmission unit — MTU) для интерфейса. Обычно нет необходимости менять значение этого параметра, но, в некоторых случаях, уменьшение значения MTU позволяет добиться устойчивой работы абонентов с очень низким уровнем сигнала. Кроме того, он может использоваться для изменения параметров туннельных интерфейсов. |
dstaddr addr | Устанавливает удаленный IP-адрес для двухточечной связи (например, по протоколу PPP). Это ключевое слово сейчас считается устаревшим; используйте вместо него ключевое слово pointopoint. |
netmask addr | Устанавливает маску сети IP для этого интерфейса. По умолчанию используется обычная маска сети класса A, B или C (что определяется по IP-адресу интерфейса), но можно установить любое значение. |
add addr/prefixlen | Добавляет адрес IPv6 для интерфейса. |
del addr/prefixlen | Удаляет адрес IPv6 для интерфейса. |
tunnel aa.bb.cc.dd | Создает новое устройство SIT (IPv6-в-IPv4) — тоннель к указанной цели. |
irq | Устанавливает аппаратное прерывание, используемое данным устройством. Не для всех устройств можно динамически менять значение IRQ. |
io_addr addr | Устанавливает адрес начала области ввода-вывода для данного устройства. |
mem_start addr | Устанавливает адрес начала области разделяемой памяти, используемой этим устройством. Это нужно лишь для немногих устройств. |
media type | Устанавливает физический порт или тип носителя, используемый устройством. Не для всех устройств можно менять этот параметр, и для разных устройств могут поддерживаться различные значения. Типичные значения типа — 10base2 (коаксиальный кабель Ethernet), 10baseT (витая пара Ethernet 10 Мбит/сек), AUI (внешний передатчик) и т. д. Специальный тип носителя auto можно использовать, чтобы потребовать от драйвера автоматически определять тип носителя. Не все драйверы могут это делать. |
bootproto [[static][dhcp]] | Устанавливает способ получения IP адреса. (статический, которые описывается Вами, либо динамический получаемый от DHCP-сервера) |
broadcast [addr] | Устанавливает широковещательный адрес. Широковещательный адрес обычно создается из сетевого адреса установкой всех бит части машины. Некоторые реализации IP используют другую схему, эта опция помогает приспособиться к этим странным средам. Если широковещательный (broadcast) адрес был установлен, ifconfig показывает флаг BROADCAST . |
pointopoint [addr] | Это ключевое слово включает двухточечный (point-to-point) режим интерфейса, означающий, что он обеспечивает непосредственную связь между двумя машинами, которую никто не прослушивает. Если указан также аргумент адрес, устанавливает соответствующий протоколу адрес другой стороны связи, как и устаревшее ключевое слово dstaddr. В противном случае, устанавливает или сбрасывает флаг IFF_POINTOPOINT для интерфейса. |
-pointopoint [addr] | Это ключевое слово отключает двухточечный (point-to-point) режим интерфейса |
hw class address | Устанавливает аппаратный адрес соответствующего интерфейса, если драйвер устройства поддерживает такую возможность. После ключевого слова hw необходимо указать имя класса оборудования, а также аппаратный адрес в текстовом виде. В настоящее время поддержимвается оборудование классов ether (Ethernet), ax25 (AMPR AX.25), ARCnet и netrom (AMPR NET/ROM). |
multicast | Устанавливает у интерфейса флаг поддержки групповой передачи данных. Обычно в этом нет нужды, поскольку драйвер сам выставляет этот флаг. |
address | IP-адрес, присваиваемый интерфейсу. |
txqueuelen length | Устанавливает длину очереди передачи для устройства. Это позволяет установить меньшие значения для более медленных устройств с продолжительными задержками (модемные линии, ISDN), чтобы быстрая передача больших объёмов данных не слишком мешала передаче данных интерактивных сеансов, например, telnet. |
Файловый сервер на Linux [БАЗА ЗНАНИЙ]
В этой статье мы расскажем как установить и настроить файловое хранилище на операционной системе Linux, а точнее будет использована серверная Ubuntu 16.04 LTS. Аналогичным образом настраивается большинство deb-based дистрибутивов.
Такой сервер можно использовать для сетевой установки файловой базы 1С:Предприятие — это гораздо надежнее, чем хранить ее на одном из рабочих компьютеров пользователей. Или такой сервер можно приспособить под сетевое хранилище резервных копий.
Только не используйте один и тот же сервер для установки информационной базы и хранения ее резервных копий.
Почему Linux? Во-первых это бесплатно и при этом совершенно легально. Во-вторых Linux потребляет гораздо меньше аппаратных ресурсов, и даже старая, списанная в утиль техника отлично справится с задачей файлового хранилища. В-третьих, хорошо настроенный Linux практически не нуждается во вмешательстве системного администратора, эксплуатируются по принципу «настроил и забыл».
И так, начнем…
Выбор оборудования
Как я уже написал, оборудование нам подойдет практически любое, но все же кое-какие пожелания у нас есть. Поскольку сервер будет файловый, то и пожелания наши будут касаться дисковой системы. Было бы неплохо найти машину с RAID контроллером на борту. Если мы делаем сервер для размещения рабочей файловой базы, было бы неплохо разместить ее на RAID-5, если хранилище резервных копий, отличным вариантом будет RAID-1.
При этом у нас нет особых требований к оперативной памяти, хватит и 1 Гбайта. К процессору тоже нет особых требований, Linux будет работать на всем, что еще живо.
Пожалуй, самый оптимальный вариант — приобрести восстановленный сервер «с пробегом». Берите самый дешевый, какой найдете, главное, что бы перед этим он прошел профилактику, его очистили от пыли и прогнали все системные тесты.
За неимением лучшего, можно использовать любой старый компьютер, но помните, что Вы это делаете на свой страх и риск. Самое уязвимое место файлового сервера — дисковая подсистема. Если она у Вас будет состоять из одного единственного старого диска, Вы очень сильно рискуете.
Если не удалось найти RAID-контроллер, можно настроить программный RAID средствами операционной системы. Учтите, что это повысит требования к процессору и оперативной памяти, зато Вам будет не страшен выход из строя контроллера.Установка операционной системы
Сначала определимся с архитектурой сервера. Если Вам известна марка процессора, установленного в сервер, ознакомившись с его спецификацией Вы узнаете, совместим ли он с архитектурой x86-64 (64 бит) или только i386 (32 бит). Косвенный признак — размер оперативной памяти, 32-битная архитектура не может работать с оперативной памятью объемом более 3 Гбайт, иногда в эту архитектуру устанавливали 4 Гбайт памяти, но в системе было видно только 3 Гбайт.
Идем на страницу загрузки Ubuntu Server и скачиваем дистрибутив, соответствующей архитектуры. Дистрибутивы Ubuntu распространяются в виде образов загрузочных DVD дисков.
Для установки Вам потребуется записать загрузочный DVD диск из скачанного образа, или, что как правило удобнее, подготовить загрузочную флешку специальной утилитой. Вставляйте диск или флешку в сервер и загружайтесь с нее.
Выбирайте русский язык и в меню Установить Ubuntu Server
.
Далее Вам предложат указать страну, выбрать раскладку клавиатуры, дать имя серверу, указать имя и пароль суперпользователя (аналог администратора в Ubuntu) и подтвердить временную зону.
Некоторое затруднение может вызвать разметка диска. Если сомневаетесь, выбирайте автоматическую разметку и использовать весь диск. Но лучше выделить домашние папки пользователей в отдельные логические диски.
Так будет удобнее обновлять операционную систему, когда выйдет новая LTS версия 18.04.
Создавать или нет раздел подкачки зависит от объема оперативной памяти. Если у Вас ее немного, создайте раздел подкачки с таким же объемом. Впрочем, это не обязательно, можно после установки создать файл подкачки.
Далее в процессе установки Вам нужно будет выбрать каким образом Вы хотите управлять обновлением системы. Рекомендую устанавливать обновления безопасности автоматически.
И ближе к концу установки Вам предложат выбрать готовые наборы серверного программного обеспечения. Нам понадобятся:
Samba file server
Standart system utilites
OpenSSH server
Инсталлятор завершит свою работу, перезапустит сервер, Вы увидите протокол загрузки операционной системы, который завершится приглашением ввести логин и пароль пользователя в консоль.
Добро пожаловать в Linux!
Настройка сервера
Вводите логин и пароль суперпользователя, созданного при установке операционной системы. Ввод пароля никак не отображается в командной консоли — это нормально.
Первым делом настроем сетевое подключение.
Во время установки инсталлятор продиагностировал установленное оборудование и определил имеющиеся в системе адаптеры. По умолчанию Ethernet адаптер настраивается на получение IP адреса через DHCP, нас это не устраивает, т.к. у нас не будет возможности обращаться к серверу по его логическому имени, мы настроим статический IP адрес.
Откройте конфигурационный файл сетевых интерфейсов командой
$ sudo nano /etc/network/interfaces
Здесь использована команда sudo
— специальная конструкция deb-based дистрибутивов Linux для выполнения команд с правами root. Когда Вы делаете это первый раз система попросит Вас ввести пароль и на какое-то время запомнит его.
и приведите его к такому виду
# The loopback network interface - этот раздел не трогаем, оставляем как есть auto lo iface lo inet loopback # The primary network interface - этот раздел настраивает Ethernet адаптер auto enp0s3 # имя интерфейса оставляем без изменений iface enp0s3 inet static # меняем опцию dhcp на static address 192.168.1.9 # укажите свободный IP адрес в Вашей сети # за пределами диапазона адресов, выдаваемых DHCP сервером, # если таковой используется netmask 255.255.255.0 # маска подсети gateway 192.168.1.1 # шлюз по умолчанию, обычно IP адрес сетевого маршрутизатора
Сохраните файл нажав Ctrl-O и закройте редактор Ctrl-X. После редактирования перезапустим сеть:
$ sudo /etc/init.d/networking restart
и проверим что у нас получилось
$ ifconfig
В выдаче этой команды внимательно смотрим на значения inet addr
— в нашем примере там должен быть статический адрес 192.168.1.9.
Дальнейшую настройку удобнее производить с рабочей станции, подключившись по протоколу SSH. От сервера можно отключить монитор, клавиатуру и разместить его там, где он не будет никому мешать.
Для дистанционного управления сервером с рабочей станции Windows мы будем использовать PuTTy. Скачайте, установите и подключайтесь. Адрес сервера в нашем примере указывается так [email protected]
, где user
— имя суперпользователя, порт по умолчанию 22
.
Мы не будем использовать анонимный доступ к нашему файловому серверу, для того, что бы что-то записать или прочитать с сервера потребуется указать логин и пароль. И нам потребуется создать пользователя на сервере, от имени которого будут производиться все соответствующие файловые операции в хранилище.
$ sudo adduser storageuser
При создании пользователя так же будут созданы одноименные группа и домашняя папка. В домашней папке этого пользователя мы и организуем сетевое файловое хранилище
$ sudo -u storageuser mkdir /home/storageuser/nas
Пакет samba мы уже установили вместе с системой, дополнительно что-либо устанавливать не требуется.
Добавим пользователя в Samba
$ sudo smbpasswd -a storageuser
— тут нужно указать пароль пользователя Samba, и включим пользователя
$ sudo smbpasswd -e storageuser
Сделаем на всякий случай копию файла настроек и приступим к настройкам файлового сервера Samba.
$ sudo cp /etc/samba/smb.conf /etc/samba/smb.bak $ sudo nano /etc/samba/smb.conf
Конфигурационный файл сопровождается подробными комментариями, можете пройтись по настройкам самостоятельно, а можете скопировать рекомендуемые настройки полностью
[global] workgroup = WORKGROUP # Здесь укажите имя рабочей группы одноранговой сети server string = %h server (Samba, Ubuntu) name resolve order = wins lmhosts hosts bcast dns proxy = no wins support = yes # только если в сети нет Wins сервера (он может быть, например, в роутере) ;wins server = 192.168.1.1 # только если wins support = no и по указанному адресу действительно есть Wins сервер log file = /var/log/samba/log.%m max log size = 1000 syslog = 0 panic action = /usr/share/samba/panic-action %d server role = standalone server passdb backend = tdbsam obey pam restrictions = no unix password sync = yes passwd program = /usr/bin/passwd %u passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* . pam password change = yes security = user username map = /etc/samba/smbusers map to guest = bad user usershare allow guests = yes [storage] comment = nas storage writable = yes browseable = yes public = yes path = /home/storageuser/nas guest ok = no directory mask = 755 create mask = 644 valid users = @storageuser
Перезапустим службу
$ sudo service smbd restart
Пробуем зайти с какой-либо рабочей станции Windows, указав в проводнике путь \\192.168.1.9
.
В сетевом окружении сервер появится через какое-то время, когда служба Wins обновит свои данные.
Windows сначала попробует открыть папку под своей локальной учетной записью, у нее это не получится и она запросит логин и пароль для доступа к сетевому ресурсу — это как раз тот пользователь, которого мы создали специально для доступа к сетевому хранилищу.
Готово!
При необходимости можно добавить новых пользователей и новые разделы. Разграничение доступа к разделам производится через опцию valid users
в соответствующем блоке конфигурационного файла Samba.
Антивирус
Операционные системы на базе Linux практически не подвержены риску заражения компьютерными вирусами, от части потому, что вирусов способных им навредить крайне мало, а в основном потому, что без получения привилегий суперпользователя эти вирусы ничем не могут навредить операционной системе.
Но эти вирусы могут использовать файловый сервер Samba для распространения от одной Windows системы на другие. Что бы поддерживать наше файловое хранилище в чистоте, мы установим антивирус и настроим автоматическое сканирование.
Установим антивирус ClamAV
$ sudo apt install clamav
Сразу же после установки в фоновом режиме запуститься обновление сигнатур, в дальнейшем мы настроим автоматическое обновление сигнатур по расписанию.
Удалять подозрительные файлы мы сразу не будем, мы их будем перемещать в карантин, где они никому не навредят. Если среди этих файлов было что-то важное, администратор сможет найти их в карантине и что-то сделать. Создадим папку карантина и ограничим доступ к ней
$ sudo mkdir /quarantine $ sudo chmod 600 /quarantine
Попробуем просканировать домашние папки пользователей
$ sudo clamscan -i -r --move=/quarantine /home
После сканирования получим протокол
----------- SCAN SUMMARY ----------- Known viruses: 6278963 Engine version: 0.99.2 Scanned directories: 13 Scanned files: 13 Infected files: 0 Data scanned: 4.79 MB Data read: 1.59 MB (ratio 3.00:1) Time: 22.176 sec (0 m 22 s)
Все хорошо, вирусов не обнаружено. Если бы нашлось что-то подозрительное, оно было бы перемещено в папку карантина.
Нам остается настроить автоматическое расписание обновления сигнатур и сканирования домашних папок. Редактируем файл расписания демона cron
$ sudo crontab -e
Для обновления сигнатур и сканирования нам потребуются привилегии суперпользователя, поэтому crontab запускается через sudo, сами команды в файле расписания нужно указывать без sudo.
Добавьте две строчки
0 1 * * * freshclam 0 2 * * * clamscan -i -r --move=/quarantine /home
Каждый день в 1:00 ночи будет автоматически запускаться обновление сигнатур, а в 2:00 ночи будет запущено сканирование всех домашних папок пользователей, инфицированные файлы будут перемещены в папку карантина.
Мониторинг
Регулярность резервного копирования
Если Вы пользуетесь мессенджером Telergam, у нас для Вас есть утилита мониторинга резервного копирования. Она умеет сканировать папки сетевого хранилища и сообщать о наличии или отсутствии новых файлов. Например, если резервное копирование запланировано на ночь, а утром в сетевом хранилище нет новых файлов, значит что-то пошло не так и нужно с этим разобраться.
Утилита написана на Python, сам Python в Ubuntu установлен по-умолчанию, нужно установить дополнительный модуль.
$ sudo apt install python-pip $ sudo pip install --upgrade pip $ sudo pip install python-telegram-bot
Сама утилита устанавливается из репозитория GitHib
$ cd ~ $ git clone https://github.com/kuleshovdv/backtracker.wiki.git $ cd backtracker
Создайте для себя нового Telegram бота. Подробная инструкция как это сделать приведена тут (англ).
Свяжитесь с Отцом Ботов, отправьте ему сначала команду /start
, затем /newbot
. Далее отвечайте на вопросы Отца Ботов, в итоге Вы получите от него токен и ссылку на Вашего бота.
Открываем конфигурационный файл
$ nano backtracker.conf
и настраиваем
[Telegram] token = # Тут нужно указать токен telegram-бота, полученный от Отца Ботов failonly = # False если хотите получать сообщения о наличии новых файлов или True если только об их отсутствии [Scan] path = # Укажите путь к сканируемым папкам hours = # Укажите "свежесть" файлов в часах, например 8
Запускайте утилиту
$ ./backtracker.ry
Первый запуск нужен для того, что бы автоматически определить ID абонента Telegram, который будет получать сообщения (это не номер его телефона). Подключайтесь к своему боту по ссылке, которую Вам дал Отец Ботов и отправляйте ему команду /start
. В ответ Вы получите сообщение, что Ваш ID определен, а утилита самонастроится и закроется. Запустите ее повторно для выполнения сканирования.
После настройки и проверки работы утилиты, добавьте ее в расписание демона cron
$ crontab -e
Добавьте строчку
0 8 * * * ~/backtracker/backtracker.py
Проверка будет запускаться каждый день в 8 утра. Если ночью что-то пошло не так, Вы узнаете об этом.
Системные ресурсы
Мониторить ресурсы сервера можно консольной утилитой top
или ее более красочной версией htop
. Установим и запустим ее
$ sudo apt install htop $ htop
Периодически контролируйте использование оперативной памяти. Если часто наблюдается загруженность около 100%, настройте файл подкачки.
$ sudo dd if=/dev/zero of=/swapfile bs=1M count=1024 $ sudo chmod 600 /swapfile && sudo mkswap /swapfile $ sudo swapoff -a $ sudo swapon /swapfile $ echo "/swapfile swap swap defaults 0 0"| sudo tee -a /etc/fstab
Здесь count=1024
— размер файла подкачки в мегабайтах.
Дисковое пространство
Для мониторинга файловой системы удобно пользоваться файловым менеджером Midnight Commander. Если Вы застали времена MS DOS и Notron Commander, то объяснять ничего не нужно.
Устанавливаем и запускаем
$ sudo apt install mc $ mc
Так удобно наблюдать за файловым хранилищем, карантином, свободным дисковым пространством.
nas_linux.txt · Последнее изменение: 2019/12/16 21:42 — kuld
Настройка сети на гостевой ОС в VirtualBox (ssh, ftp) | Perl, Python
- Базовая система: Windows XP
- VirtualBox v.4.3
- Гостевая OS: Ubuntu 16.04 LTS xenial
На виртуальную машину была установлена Ubuntu. Сразу после этого потребовалось настроить к ней ssh-доступ (для более удобного взаимодействия).
Виртуальная машина используется только для «домашних» исследований и обучения. Поэтому, аспекты безопасности при настройке ssh и ftp не рассматриваются.
Как настроить ssh-доступ
Настройки сети по умолчанию, созданные при установке системы:
Выбираем виртуальную машину и нажимаем кнопку «Настроить». Изменяем настройки у первого сетевого адаптера. Вместо «Intel PRO» в поле «Тип адаптера» указываем «virtio-net».
Добавляем второй сетевой адаптер. На вкладке «Адаптер 2» устанавливаем флаг «Включить сетевой адаптер», в поле «Тип подключения» выбираем «Виртуальный адаптер хоста», в поле «Имя» выбираем «VirtualBox Host-Only Ethernet Adapter».
«Virtio-net» — это специальный тип сетевого адаптера. Эмуляцию сетевого устройства в гостевой системе будет обеспечивать драйвер «virtio». Преимущество использования в увеличении производительности сетевого ввода/вывода.
Можно пойти в настройки сети на основном компьютере, и поинтересоваться, что прописано в свойствах выбранного сетевого адаптера:
Далее, запускаем виртуальную машину. Необходимо настроить дополнительный сетевой интерфейс. Изучаем текущую ситуацию:
$ ifconfig enp0s3 Link encap:Ethernet HWaddr 08:00:27:d5:6c:0f inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fed5:6c0f/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:64670 errors:0 dropped:0 overruns:0 frame:0 TX packets:21653 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:93952418 (93.9 MB) TX bytes:1180832 (1.1 MB) lo Link encap:Локальная петля (Loopback) inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:160 errors:0 dropped:0 overruns:0 frame:0 TX packets:160 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:11840 (11.8 KB) TX bytes:11840 (11.8 KB)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
$ ifconfig enp0s3 Link encap:Ethernet HWaddr 08:00:27:d5:6c:0f inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fed5:6c0f/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:64670 errors:0 dropped:0 overruns:0 frame:0 TX packets:21653 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:93952418 (93.9 MB) TX bytes:1180832 (1.1 MB)
lo Link encap:Локальная петля (Loopback) inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:160 errors:0 dropped:0 overruns:0 frame:0 TX packets:160 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:11840 (11.8 KB) TX bytes:11840 (11.8 KB) |
Смотрим доступные сетевые интерфейсы:
$ ifconfig -a enp0s3 Link encap:Ethernet HWaddr 08:00:27:0d:17:fc … enp0s8 Link encap:Ethernet HWaddr 08:00:27:11:ec:0c … lo Link encap:Локальная петля (Loopback) …
$ ifconfig -a enp0s3 Link encap:Ethernet HWaddr 08:00:27:0d:17:fc …
enp0s8 Link encap:Ethernet HWaddr 08:00:27:11:ec:0c …
lo Link encap:Локальная петля (Loopback) … |
Открываем файл /etc/network/interfaces :
$ sudo mcedit /etc/network/interfaces
$ sudo mcedit /etc/network/interfaces |
На старых Ubuntu настройки выглядели бы примерно так:
auto eth2 iface eth2 inet static address 192.168.56.10 netmask 255.255.255.0
auto eth2 iface eth2 inet static address 192.168.56.10 netmask 255.255.255.0 |
В новых версиях Ubuntu используются другие названия сетевых интерфейсов, например:
- enp0s3 вместо eth0
- wlp3s0 вместо wlan0
Вносим правки, в результате получается что-то вроде этого:
source /etc/network/interfaces.d/* auto lo iface lo inet loopback auto enp0s3 iface enp0s3 inet dhcp auto enp0s8 iface enp0s8 inet static address 192.168.56.10 netmask 255.255.255.0
source /etc/network/interfaces.d/*
auto lo iface lo inet loopback
auto enp0s3 iface enp0s3 inet dhcp
auto enp0s8 iface enp0s8 inet static address 192.C |
Вывод ifconfig после перезагрузки гостевой ОС:
$ ifconfig enp0s3 Link encap:Ethernet HWaddr 08:00:27:0d:17:fc inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fe0d:17fc/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:16 errors:0 dropped:0 overruns:0 frame:0 TX packets:23 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2240 (2.2 KB) TX bytes:2230 (2.2 KB) enp0s8 Link encap:Ethernet HWaddr 08:00:27:11:ec:0c inet addr:192.168.56.10 Bcast:192.168.56.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fe11:ec0c/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:283 errors:0 dropped:0 overruns:0 frame:0 TX packets:291 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:24985 (24.9 KB) TX bytes:42405 (42.4 KB) lo Link encap:Локальная петля (Loopback) inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:160 errors:0 dropped:0 overruns:0 frame:0 TX packets:160 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:11840 (11.8 KB) TX bytes:11840 (11.8 KB)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
$ ifconfig enp0s3 Link encap:Ethernet HWaddr 08:00:27:0d:17:fc inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fe0d:17fc/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:16 errors:0 dropped:0 overruns:0 frame:0 TX packets:23 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2240 (2.2 KB) TX bytes:2230 (2.2 KB)
enp0s8 Link encap:Ethernet HWaddr 08:00:27:11:ec:0c inet addr:192.168.56.10 Bcast:192.168.56.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fe11:ec0c/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:283 errors:0 dropped:0 overruns:0 frame:0 TX packets:291 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:24985 (24.9 KB) TX bytes:42405 (42.4 KB)
lo Link encap:Локальная петля (Loopback) inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:160 errors:0 dropped:0 overruns:0 frame:0 TX packets:160 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:11840 (11.8 KB) TX bytes:11840 (11.8 KB) |
Далее необходимо установить ssh-сервер:
$ sudo apt-get install ssh
$ sudo apt-get install ssh |
Старт ssh-сервера будет прописан в автозагрузке. Перезапускаем виртуальную машину:
Файл настройки ssh-сервера — /etc/ssh/sshd_config . Для начала можно обойтись настройками по умолчанию.
Управлять запуском или остановкой сервера можно с помощью команд:
$ sudo service ssh stop|start|restart|status
$ sudo service ssh stop|start|restart|status |
Теперь можно попробовать подключиться к ssh-серверу.
Как настроить ftp-доступ
Для обмена файлами между гостевой системой и основной очень удобно использовать ftp-доступ. Устанавливаем сервер:
$ sudo apt-get install vsftpd
$ sudo apt-get install vsftpd |
Конфигурационный файл ftp-сервера: /etc/vsftpd.conf . По умолчанию права пользователя, использующего ftp — сильно ограничены. Поэтому, сразу же вношу правки:
# Uncomment this to enable any form of FTP write command. write_enable=YES
# Uncomment this to enable any form of FTP write command. write_enable=YES |
Иначе нельзя будет копировать файлы на гостевую систему.
sudo service vsftpd restart
sudo service vsftpd restart |
Доступ к web-приложениям
Если на гостевой системе запускается веб-сервер, можно получить к нему доступ, прописав в адресной строке браузера: http://192.168.56.10 .
Либо можно внести правки в файл C:\WINDOWS\system32\drivers\etc\hosts в основной системе, и добавить туда строку:
192.168.56.10 www.mysite.ru
192.168.56.10 www.mysite.ru |
Тогда можно будет обращаться к web-серверу, используя имя www.mysite.ru .
MPI Broadcast и коллективное общение · MPI Tutorial
Автор: Уэс КендаллДо сих пор в руководствах по MPI мы исследовали двухточечную связь, то есть связь между двумя процессами. Этот урок является началом секции коллективного общения . Коллективное общение — это метод общения, который предполагает участие всех процессов в коммуникаторе. В этом уроке мы обсудим последствия коллективного общения и рассмотрим стандартный коллективный распорядок — вещание.
Примечание — Весь код этого сайта находится на GitHub. Код этого руководства находится в разделе tutorials / mpi-broadcast-and-коллективная связь / code.
Пункты коллективной связи и синхронизации
Одна из вещей, которые следует помнить о коллективной коммуникации, заключается в том, что она подразумевает точку синхронизации между процессами. Это означает, что все процессы должны достичь определенной точки в своем коде, прежде чем все они смогут снова начать выполнение.
Перед тем, как вдаваться в подробности о процедурах коллективного общения, давайте рассмотрим синхронизацию более подробно. Как оказалось, в MPI есть специальная функция, предназначенная для синхронизации процессов:
MPI_Barrier (коммуникатор MPI_Comm)
Название функции довольно информативное — функция образует барьер, и ни один процесс в коммуникаторе не может пройти барьер, пока все они не вызовут функцию. Вот иллюстрация. Представьте, что горизонтальная ось представляет выполнение программы, а кружки представляют различные процессы:
Обнуление процесса сначала вызывает MPI_Barrier
в первый моментальный снимок (T 1).В то время как нулевой процесс зависает на барьере, процесс один и три в конечном итоге его добиваются (T 2). Когда процесс два наконец достигает барьера (T 3), все процессы снова начинают выполнение (T 4).
MPI_Barrier
может быть полезен для многих вещей. Одним из основных применений MPI_Barrier
является синхронизация программы, чтобы части параллельного кода могли быть точно синхронизированы.
Хотите узнать, как реализован MPI_Barrier
? Конечно, знаете 🙂 Вы помните программу звонков из учебника по отправке и получению? Чтобы освежить вашу память, мы написали программу, которая передавала токен по всем процессам в виде кольца.Этот тип программы — один из простейших методов реализации барьера, поскольку токен не может быть полностью передан, пока все процессы не будут работать вместе.
Последнее замечание о синхронизации. Всегда помните, что каждый ваш коллективный вызов синхронизируется. Другими словами, если вы не можете успешно завершить MPI_Barrier
, вы также не сможете успешно завершить ни один коллективный вызов. Если вы попытаетесь вызвать MPI_Barrier
или другие коллективные подпрограммы, не гарантируя, что все процессы в коммуникаторе также вызовут его, ваша программа будет бездействовать.Это может сбить с толку новичков, поэтому будьте осторожны!
Вещание с MPI_Bcast
Трансляция — один из стандартных методов коллективной связи. Во время широковещательной рассылки один процесс отправляет одни и те же данные всем процессам в коммуникаторе. Одним из основных применений широковещательной передачи является отправка пользовательского ввода в параллельную программу или отправку параметров конфигурации всем процессам.
Схема связи трансляции выглядит так:
В этом примере нулевым процессом является корень
ATP: что это такое и почему это важно?
Вся реакция, которая превращает АТФ в энергию, немного сложна, но вот хорошее резюме:
- Химически АТФ представляет собой адениновый нуклеотид, связанный с тремя фосфатами.
- В связи между второй и третьей фосфатными группами хранится много энергии, которую можно использовать для подпитки химических реакций.
- Когда клетке нужна энергия, она разрывает эту связь с образованием аденозиндифосфата (АДФ) и свободной молекулы фосфата.
- В некоторых случаях вторая фосфатная группа также может разрушаться с образованием аденозинмонофосфата (АМФ).
- Когда клетка имеет избыток энергии, она накапливает эту энергию, образуя АТФ из АДФ и фосфата.
- АТФ необходим для биохимических реакций, участвующих в сокращении мышц. По мере того, как работа мышцы увеличивается, потребляется все больше и больше АТФ, и его необходимо восполнить, чтобы мышца продолжала двигаться.
Поскольку АТФ так важен, в организме есть несколько различных систем для создания АТФ. Эти системы работают вместе поэтапно. Интересно то, что в разных формах упражнений используются разные системы, поэтому спринтер получает АТФ совершенно по-другому, чем бегун-марафон!
АТФ поступает из трех различных биохимических систем в мышцах в следующем порядке:
- Фосфагенная система
- Система гликоген-молочная кислота
- Аэробное дыхание
А теперь давайте подробно рассмотрим каждую из них.
Фосфагенная система
Мышечная клетка имеет некоторое количество АТФ, плавающее вокруг, которое она может использовать немедленно, но не очень много — хватит только на три секунды. Чтобы быстро восполнить уровень АТФ, мышечные клетки содержат высокоэнергетическое фосфатное соединение, называемое креатинфосфатом.
Фосфатная группа удаляется из креатинфосфата ферментом, называемым креатинкиназой, и передается на АДФ с образованием АТФ.
Клетка превращает АТФ в АДФ, а фосфаген быстро превращает АДФ обратно в АТФ.По мере того как мышца продолжает работать, уровень креатинфосфата начинает снижаться. Вместе уровни АТФ и уровни креатинфосфата называются фосфагенной системой. Фосфагенная система может обеспечивать энергетические потребности работающих мышц с высокой скоростью, но только в течение 8-10 секунд.
Система молочной кислоты гликоген
Мышцы также обладают большими запасами сложных углеводов, называемых гликогеном. Гликоген — это цепочка молекул глюкозы. Клетка расщепляет гликоген на глюкозу.Затем клетка использует анаэробный метаболизм (анаэробный означает «без кислорода») для производства АТФ и побочного продукта, называемого молочной кислотой, из глюкозы.
В этом процессе происходит около 12 химических реакций, в результате которых образуется АТФ, поэтому он поставляет АТФ медленнее, чем фосфагенная система. Система все еще может действовать быстро и производить достаточно АТФ примерно на 90 секунд. Эта система не нуждается в кислороде, что удобно, потому что сердцу и легким требуется некоторое время, чтобы начать действовать вместе. Это также удобно, потому что быстро сокращающаяся мышца отжимает собственные кровеносные сосуды, лишая себя богатой кислородом крови.
Существует определенный предел анэробному дыханию из-за молочной кислоты. Кислота вызывает боль в мышцах. Молочная кислота накапливается в мышечной ткани и вызывает усталость и болезненность, которые вы чувствуете в тренированных мышцах.
Аэробное дыхание
К двум минутам упражнений организм отвечает на снабжение работающих мышц кислородом. Когда присутствует кислород, глюкоза может полностью расщепляться на углекислый газ и воду в процессе, называемом аэробным дыханием.
Глюкоза может поступать из трех разных источников:
- Остаточные запасы гликогена в мышцах
- Расщепление гликогена печени на глюкозу, которая попадает в работающие мышцы через кровоток
- Всасывание глюкозы из пищи в кишечнике, которая попадает в работающие мышцы через кровоток
Аэробное дыхание может также использовать жирные кислоты из жировых запасов в мышцах и теле для производства АТФ. В крайних случаях (например, при голодании) белки также могут расщепляться на аминокислоты и использоваться для производства АТФ.При аэробном дыхании сначала используются углеводы, затем жиры и, наконец, белки, если это необходимо.
Аэробное дыхание требует даже большего количества химических реакций для производства АТФ, чем любая из вышеперечисленных систем. Аэробное дыхание производит АТФ с самой низкой скоростью из трех систем, но оно может продолжать поставлять АТФ в течение нескольких часов или дольше, пока есть запас топлива.
Обзор
Итак, представьте, что вы начинаете бежать. Вот что происходит:
- Мышечные клетки сжигают АТФ примерно за 3 секунды.
- Срабатывает фосфагеновая система и подает энергию в течение 8-10 секунд. Это будет основная энергетическая система, используемая мускулами 100-метрового спринтера или штангиста, где происходит быстрое ускорение и короткие упражнения.
- Если упражнения продолжаются дольше, включается система гликоген-молочная кислота. Это верно для упражнений на короткие дистанции, таких как бег на 200 или 400 метров или плавание на 100 метров.
- Наконец, если упражнения продолжаются, то берет верх аэробное дыхание.Это может происходить в соревнованиях на выносливость, таких как бег на 800 метров, марафонский бег, гребля, беговые лыжи и бег на коньках.
Если внимательно присмотреться к тому, как устроено человеческое тело, это действительно потрясающая машина!
Список литературы
- Как работает «АТФ — это энергия». 2000 * Каменные тела «Машина тела». 2000
Трансляция
int MPI_Bcast (void * buffer, int count, тип данных MPI_Datatype, int root,
14
MPI_Comm comm)
15
16MPI_BCAST (БУФЕР, СЧЁТ, ДАТАТИП, КОРНЕВОЙ, СВЯЗЬ, ОШИБКА)
17 <тип> БУФЕР (*)
18 СЧЕТЧИК ИНТЕГЕРА, ТИП ДАТЫ, КОРНЕВОЙ, СВЯЗЬ, IERROR
19
fvoid MPI :: Comm :: Bcast (void * buffer, int count,
20
const MPI :: Datatype & datatype, int root) const = 0 (привязка
21
не рекомендуется, см. Раздел 15.2) г
22
23 Если связь является интракоммуникатором, MPI_BCAST передает сообщение от процесса
24 с рангом root для всех процессов группы, включая ее самого. Его называют все участники
25группа, использующая одни и те же аргументы для comm и root. По возвращении содержимое корневого каталога
26buer копируется для всех остальных процессов.
27Обычно для типа данных разрешены производные типы данных. Типовая подпись графа,
28datatype для любого процесса должен быть равен сигнатуре типа count, datatype в корне.
29 Это означает, что количество отправленных данных должно быть равно полученному количеству попарно
30 между каждым процессом и корнем. MPI_BCAST и весь другой коллектив перемещения данных
31 подпрограммы накладывают это ограничение. Карты различного типа между отправителем и получателем по-прежнему
32разрешено.
33 Опция \ in place «здесь не имеет смысла.
34 Если связь является интеркоммуникатором, то в вызове участвуют все процессы внутренней связи.
35 коммуникатор, но с одной группой (группа A), определяющей корневой процесс.Все процессы в
36 другая группа (группа B) передает то же значение в корне аргумента, которое является рангом корня
37в группе A.