По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Предыдущий материал из цикла про ARP в IPv4. Ждет вас по ссылке.
Как хост может узнать, следует ли пытаться отправить пакет хосту через сегмент, к которому он подключен, или отправить пакет на маршрутизатор для дальнейшей обработки? Если хост должен отправлять пакеты на маршрутизатор для дальнейшей обработки, как он может узнать, на какой маршрутизатор (если их несколько) отправлять трафик? Эти две проблемы вместе составляют проблему шлюза по умолчанию.
Для IPv4 проблему довольно легко решить, используя префикс и длину префикса. Рисунок ниже демонстрирует нам это.
Реализации IPv4 предполагают, что любой хост в пределах одной подсети IPv4 должен быть физически подключен к одному проводу. Как реализация может определить разницу? Маска подсети - это еще одна форма длины префикса, которая указывает, где заканчивается сетевой адрес и начинается адрес хоста. В этом случае предположим, что длина префикса равна 24 битам, или сетевой адрес равен /24. 24 указывает вам, сколько битов задано в маске подсети: 24 bits = 11111111.11111111.11111111.0000000
Поскольку в IPv4 используется десятичная запись маски, это также можно записать как 255.255.255.0. Чтобы определить, находится ли C на том же проводе, что и A, A будет:
Логическое умножение маски подсети с адресом локального интерфейса
Логическое умножение маски подсети с адресом назначения
Сравните два результата; если они совпадают, целевой хост находится на том же канале связи, что и локальный интерфейс
На рисунке ниже это продемонстрировано.
На рисунке выше показано четыре IPv4-адреса; предположим, что A должен отправлять пакеты в C, D и E. Если A знает, что длина префикса локального сегмента составляет 24 бита либо с помощью ручной настройки, либо с помощью DHCPv4, то он может просто посмотреть на 24 наиболее значимых бита каждого адреса, сравнить его с 24 наиболее значимыми битами своего собственного адреса и определить, находится ли пункт назначения на сегменте или нет. Двадцать четыре бита IPv4-адреса создают хороший разрыв между третьей и четвертой секциями адреса (каждая секция IPv4-адреса представляет собой 8 бит адресного пространства, в общей сложности 32 бита адресного пространства).
Любые два адреса с такими же левыми тремя секциями, что и у A, называемые сетевым адресом, находятся в одном сегменте; любой адрес, которого нет в сегменте. В этом случае сетевой адрес для A и C совпадает, поэтому A будет считать, что C находится в одном сегменте, и, следовательно, будет отправлять пакеты C напрямую, а не отправлять их на маршрутизатор. Для любого пункта назначения, который A считает вне сегмента, он будет отправлять пакеты на IPv4-адрес конечного пункта назначения, но на MAC-адрес шлюза по умолчанию. Это означает, что маршрутизатор, выступающий в качестве шлюза по умолчанию, примет пакет и переключит его на основе IPv4-адреса назначения. Как выбирается шлюз по умолчанию? Он либо настраивается вручную, либо включается в параметр DHCPv4.
А что насчет D? Поскольку сетевые части адресов не совпадают, A будет считать, что D находится вне сегмента. В этом случае A отправит любой трафик для D на свой шлюз по умолчанию, которым является B. Когда B получит эти пакеты, он поймет, что A и D достижимы через один и тот же интерфейс (на основе своей таблицы маршрутизации), поэтому он будет отправлять ICMP-перенаправление на A, говоря ему, что нужно отправлять трафик на D напрямую, а не через B.
IPv6 представляет собой более сложный набор проблем, которые необходимо решить при выборе шлюза по умолчанию, потому что IPv6 предполагает, что одно устройство может иметь много адресов IPv6, назначенных конкретному интерфейсу. Рисунок ниже демонстрирует это.
На рисунке выше предположим, что администратор сети настроил следующие политики:
Ни один хост не может подключаться к A, если у него нет адреса в диапазоне адресов 2001: db8: 3e8: 110 ::/64.
Ни один хост не может подключиться к D, если у него нет адреса в диапазоне адресов 2001: db8: 3e8: 112 ::/64.
Примечание: В реальном мире вы никогда не построили бы такую политику; это надуманная ситуация, чтобы проиллюстрировать проблему, поставленную в сети минимального размера. Гораздо более реальной проблемой такого же типа была бы одноадресная переадресация обратного пути (uRPF).
Чтобы эти политики работали, администратор назначил 110::3 и 112::12 хосту C и 111::120 хосту F. Это может показаться странным, но совершенно законно для одного сегмента иметь несколько подсетей IPv6, назначенных в IPv6; также совершенно законно иметь одно устройство с несколькими адресами. На самом деле, в IPv6 существует множество ситуаций, когда одному устройству может быть назначен диапазон адресов.
Однако с точки зрения длины префикса нет двух адресов, назначенных C или F, в одной подсети. Из-за этого IPv6 не полагается на длину префикса, чтобы определить, что находится в сегменте, а что нет. Вместо этого реализации IPv6 ведут таблицу всех подключенных хостов, используя запросы соседей, чтобы определить, что находится в сегменте, а что нет. Когда хост хочет отправить трафик из локального сегмента, он отправляет трафик на один из маршрутизаторов, о котором он узнал из объявлений маршрутизатора. Если маршрутизатор получает пакет, к которому, как он знает, другой маршрутизатор в сегменте имеет лучший маршрут (поскольку у маршрутизаторов есть таблицы маршрутизации, которые говорят им, какой путь выбрать к какому-либо конкретному месту назначения), маршрутизатор отправит сообщение перенаправления ICMPv6, сообщающее хосту использовать какой-либо другой маршрутизатор первого перехода для достижения пункта назначения.
В следующей статьей мы поговорим про пакетную коммутацию.
В больших корпоративных сетях могут использоваться несколько протоколов внутренней маршрутизации. Такая практика часто встречается при слиянии двух компаний. Чтобы компьютеры в одном домене маршрутизации (далее просто «домен») видели хосты в другом домене применятся так называемая редистрибуция. Эта функция позволяет маршрутизатору выбрать маршрут, выученный через один протокол маршрутизации, например, EIGRP и добавить в его в список анонсируемых сетей в другой, например, OSPF. Эта операция выполняется на маршрутизаторах, который смотрят в обе сети и называются точкой редистрибуции (Redistirbution Point). Маршрутизаторы, которые занимаются анонсированием сетей из одного домена в другой используют для этого таблицу маршрутизации. Другими словами, если маршрутизатор не найдет путь до какой-то сети в своей таблице, то он не будет анонсировать его в другой домен.
Схема сети
Для построения отказоустойчивой сети обычно применяются два или более маршрутизатора, которые занимаются перебросом маршрутной информации с одного домена в другой. В такой ситуации может образоваться так называемая петля маршрутизации. Поясним на рисунке:
В данном случае пакеты из маршрутизатор 2, чтобы добраться до сети Х, которая находится в том же домене делает круг через RD1 > R1 > RD2 > Subnet X. Это происходит потому, что маршрут, объявленный RD1 в Домен маршрутизации 2, имеет меньшее административное расстояние (Administrative Distance, AD), чем маршруты, объявленные роутерами из того же домена. Далее рассмотрим в каких случаях возможно такое.
Как избежать петель?
Один из самых лёгких методов для избегания петель маршрутизации это при добавлении маршрутов из одного домена в другой более высокой метрики.
В данном случае маршрутизаторы RD1 и RD2 при анонсировании маршрутов, выученных протоколом RIP в домен OSPF, назначают им метрику 500. И наоборот, из домена OSPF в домен RIP маршруты анонсируются с метрикой 5.
Второй способ – это административное расстояние. Любой маршрут, который добавляется в таблицу маршрутизации роутера, сопоставляется с административным расстоянием. Если роутер получил несколько маршрутов в одну и ту же сеть с одной и той же длиной префикса, то в таблицу попадают маршруты с меньшим AD. Маршрутизатор не учитывает метрику. Вместе с этим, AD – это локальное значение для каждого роутера и не объявляется соседним маршрутизаторам. В таблице ниже приведены административные расстояния для всех типов маршрутов на роутерах Cisco.
Тип маршрутаАдминистративное расстояниеConnected (подключённый)0Static (Статический)1EIGRP Summary route5eBGP (external BGP)20EIGRP (internal)90IGRP100OSPF110IS-IS115RIP120EIGRP (external)170iBGP (internal BGP)200
Настройки AD по умолчанию для протокола EIGRP при анонсировании маршрутов в OSPF и RIP предотвращают образование петель маршрутизации.
На рисунке выше подсеть 172.16.35.0/24 анонсируется через RD1 в домен OSPF. Маршрутизатор R2 в свою очередь анонсирует выученную через external OSPF сеть роутеру RD2. Но RD2 уже выучил маршрут до сети 35.0 через EIGRP, у которого административное расстояние равно 90, что меньше чем AD OSFP, которое равно 110. Таким образом RD2 не добавит маршрут, полученный у R2 с AD 110 в таблицу маршрутизации и соответственно не будет редистрибутировать обратно в EIGRP. Таким образом логику работы маршрутизатора RD2 можно сформулировать следующим образом:
RD2 считает маршрут, полученный по EIGRP лучшим, так как у него меньшее административное расстояние, и добавляет его в таблицу маршрутизации.
RD2 не будет анонсировать маршрут, полученный через OSPF, так как его нет в таблице маршрутизации.
В силу своей специфик, протокол EIGRP также предотвращает образование петель маршрутизации при редистрибуции из OSPF и RIP. Как было указано на таблице выше, внешние маршруты в EIGRP имеют административное расстояние равным 170.
В данном случае маршрутизатор RD2 выучил два маршрута в сеть 192.168.11.0/24. Один через R2 в домене OSPF с AD равным 110, второй через R1 в домене EIGRP с административным расстоянием равным 170-ти. Действуя по указанной выше логике, RD2 добавит в таблицу маршрутизации сеть 11.0 выученный у роутера R2 предотвращая таким образом образование петли.
Если в случае EIGRP-OSPF, EIGRP-RIP нам удалось без особых усилий предотвратить петлю маршрутизации, то в случае OSPF-RIP всё немного сложнее. Так как OSPF для всех типов маршрутов использует один показатель AD – 110, то при редистрибуции между RIP и OSPF избежать петель удается только изменение административного расстояния протоколов маршрутизации. Делается это командой distance. Для изменения показателя AD для внешних маршрутов, в интерфейсе настройки OSPF прописываем команду distance external ad-value. Значение, указанное параметром должно быть больше, чем у RIP (120).
Но не редки случаи, когда в сети работают более двух протоколов маршрутизации. В таких случаях значения AD по умолчанию не помогают. На рисунке ниже сеть 172.20.0.0/16 выучена протоколом EIGRP как внешний через RIP с АР (Административное Расстояние) равным 170. В свою очередь RD1 анонсирует данную сеть в домен OSPF с АР равным 110. RD2 же вместо маршрута с АР 170, полученного из домена EIGRP в таблицу добавляет маршрут с АР 110, полученный из домена OSPF. При таком раскладе маршрутизатор R4 получает два маршрута в одну и ту же сеть с одним и тем же АР. И в случае если метрика RD2 лучше, то R4 отправке пакетов в сеть 172.20 будет использовать более длинный путь. Нужно заметить, что это только в том случае, когда домены расположены именно в указанном порядке.
В таких случаях применяется настройка административного расстояния в зависимости от маршрута. Как было указано выше, для изменения АР используется команда distance. Эта команда принимает несколько параметров:
distance distance ip-adv-router wc-mask [ acl-number-or-name ]
В данной команде обязательным параметром является IP соседнего маршрутизатора. Если IP адрес анонсирующего маршрутизатора совпадёт с указанными в команде, то для маршрутов, полученных от этого соседа данный роутер назначит указанный в команде АР.
Рассмотрим указанный случай на практике. Детальная топология сети, показанная выше, указана на рисунке, а конфигурацию можете скачать по ссылке ниже:
Скачать файлы конфигрурации
Для начала просмотрим с каким АР RD1 выучил маршрут до сети 172.20:
Как видим, RD1 добавил в таблицу маршрутизации маршрут, выученный через OSPF, вместо EIGRP, так как АР у OSPF меньше. Теперь изменим поведение маршрутизатора и посмотрим, как это повлияет на таблицу маршрутизации.
ip access-list standard match-172-20
permit host 172.20.0.0
router ospf 2
distance 171 1.1.1.1 0.0.0.0 match-172-20
P.S. В GNS скорее всего придётся выключить, затем включить интерфейс, смотрящий в OSPF домен, чтобы изменения применились. В реальной сети всё работает правильно.
Поясним, что мы написали выше. Со стандартным списком доступа всё понятно. Команде distance параметром задали 171 – административное расстояние. Затем идет router id маршрутизатора, который анонсирует сеть 172.20. В нашем случае это маршрутизатор RD1. Таким образом, OSPF посмотрит полученный LSA и, если там увидит идентификатор маршрутизатора RD1, а также сеть, которая указана разрешённой в списке доступа, то применит этому маршруту расстояние 171.
Отметим, что указанную конфигурацию нужно сделать на всех роутерах, которые занимается распределением маршрутов и для всех сетей их третьего домена.
Будущее за удалённой работой!
Давайте рассмотрим безопасную утилиту для совместного использования ресурсов, документов и компьютера.
Что такое Chrome Remote Desktop?
Многие организации и стартапы предоставили возможность своему сотруднику работать удаленно. Заметив эту тенденцию Google решила представить простой и быстрый инструмент для доступа к системе из любого места. Для работы удаленной системы на собственном ПК требуется только две вещи: Интернет и Chrome Desktop.
Эта утилита облегчает удаленный доступ к файлам и данным с другого устройства. Он работает на всех типах настольных или мобильных ПК и со всеми операционными системами - Windows, Linux, macOS или Chrome OS.
Итог - вы можете получить доступ к компьютеру из любой точки мира, где есть Интернет.
Почему Chrome Remote Desktop?
Он бесплатный!
Он быстрый и легковесный
Дружественный интерфейс
Вы можете удалённо помогать друзьями и родным
Давайте рассмотрим поближе этот дружелюбный инструмент.
Начало работы с Chrome Remote Desktop
Для начала работы с Chrome Remote Desktop достаточно выполнить всего 4 простых шага.:
Для этого необходимо загрузить и установить браузер Chrome на ПК или мобильное устройство, чтобы получить к нему доступ из любого места.
1. Загрузить Chrome Remote Desktop
Откройте веб-страницу Chrome Remote Desktop в браузере Chrome. Вы перейдете на страницу загрузки. В правом нижнем углу появится опция со стрелкой синего цвета для загрузки плагина. Нажмите кнопку, чтобы начать загрузку.
2. Установка Chrome Remote Desktop
После загрузки надпись на кнопке на той же странице, поменяется на Accept & Install чтобы принять условия и начать установку. Нажмите на кнопку для продолжения.
3. Выберите имя устройства и пароль
После нажатия кнопки установки необходимо ввести имя устройства, которое будет отображаться для удаленных пользователей во время доступа к хост-устройству.
После ввода имени устройства необходимо ввести минимум 6-тизначный пин-код, чтобы сделать удаленный доступ более безопасным и предотвратить несанкционированный доступ к устройству.
4. Запуск приложения
После нажатия кнопки Start хост-устройство готово установить или принять удаленные подключения.
Работа с удаленной поддержкой
Google предоставляет функцию использования Google Remote Desktop без установки. На той же странице нажмите кнопку Удаленная поддержка. Появится экран с двумя опциями ниже.
Получение поддержки
Она позволяет пользователям запрашивать разовую поддержку у любого пользователя, известного или неизвестного. Параметр "Получить поддержку" доступен только в том случае, если в системе установлен Google Remote Desktop.
Чтобы получить поддержку, нажмите кнопку "Generate code"; он создаст одноразовый пароль для совместного использования удаленными пользователями.
Щелкните прямоугольное поле, чтобы скопировать одноразовый код. Этот код будет действителен в течение 5 минут. После отмены генерируется новый код.
Удаленный пользователь будет использовать предоставленный одноразовый код для доступа к клиентской системе.
Оказание поддержки
Это помогает удаленным пользователям получать доступ к другим машинам и предоставлять удаленную поддержку. Для обеспечения поддержки удаленным пользователям потребуется одноразовый код доступа, сгенерированный на машине клиента.
Пользователь клиента должен генерировать код доступа (этап 2 выше) и поделиться им с удаленным пользователем, чтобы удаленный пользователь мог работать на машине клиента.
Получив код доступа от узла клиента, удаленный узел должен перейти на веб-страницу Google Chrome Remote Desktop и получить доступ к удаленной поддержке.
Удаленный пользователь должен ввести заданный код доступа в текстовой строке "Give Support" и нажать кнопку "Connect".
После нажатия кнопки подключения на удаленной стороне появится запрос на подтверждение.
После того как удаленный пользователь разрешил и нажал на кнопку “Share”, он может получить доступ к клиентской машине и управлять ею.
Удаленный доступ с помощью мобильного устройства (Android/iOS)
Google предоставила возможность доступа к удаленному ПК через мобильные устройства. Установив на устройство на базе iOS или Android, пользователи могут использовать мобильные устройства для работы с удаленными ПК.
Обратите внимание, что перед использованием мобильного приложения идентификатор электронной почты пользователя, используемый на телефоне, должен быть зарегистрирован на Chrome Remote Desktop; в противном случае приложение отобразит сообщение "Вам не к чему подключиться, сначала нужно настроить компьютер для удаленного доступа".
Действия по подключению ПК с мобильного устройства
После настройки компьютера для удаленного доступа на экране появится список подключенных компьютеров.
После щелчка по одному из перечисленных компьютеров появится сообщение "Подключение к удаленному компьютеру".
При регистрации системы с помощью Chrome Remote Desktop запросит ввод пин-кода удаленной системы. После этого пользователь сможет получить доступ к собственной системе через мобильное устройство.
При доступе к удаленной системе в правом нижнем углу появится синяя кнопка. При нажатии на кнопку отображается доступные функции для работы на удаленном компьютере.
Показать клавиатуру: Это поможет пользователю написать что-либо на удаленной системе.
Режим трекпада/сенсорной панели: выбор режима трекпада для ограничения просмотра пользователями только страницы. В отличие от этого, режим сенсорной панели помогает щелкнуть и выполнить любое действие на удаленной системе.
Отключить: щелкните, чтобы отключить удаленный доступ к системе.
Настройки: даст возможность изменить размер экрана и другие опции для настройки.
Dock Left: Будет сдвигать синюю кнопку слева вниз или справа вниз
Чего не хватает утилите?
Не поддерживается копирование файлов между устройствами методом перетаскивания
Отсутствует функции чата или обмена сообщениями. Пользователь должен использовать другое устройство для подключения и объяснения проблемы
Не поддерживается использование нескольких мониторов
Нет возможности для обслуживания и просмотра нескольких подключений. Пользователи могут одновременно подключаться к одной системе
Заключение
Несмотря на недостатки, данная утилита может помочь при решении проблем удаленных пользователей. А главное – это бесплатно, так что стоит попробовать его на деле.