По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Все, кто так или иначе причастен к миру IT, точно слышал это слово из трех букв - DNS. Domain Name System это своего рода телефонный справочник, в котором указаны адреса всех веб-сайтов в интернете. Также DNS это довольно простой протокол, работающий, как правило, через 53 порт и который используется системными администраторами в буквально каждой сети - ну а куда без него? В данной статье мы не будем подробно разбирать схему работы DNS и типа DNS серверов - это мы оставим на потом. Каждый раз когда приложение или человек пытается попасть на какой-нибудь веб-сайт, DNS запрашивает в образном "телефонном справочнике" IP-адрес этого ресурса и отправляет вас по нужному адресу. Темой этой статьи будет некорректное использование службы злоумышленниками: в какой-то момент умные товарищи поняли, что DNS также является прекрасным вектором атаки и научились использовать DNS в целях передачи информации и команд на компьютер жертвы, и это, по сути является основным принципом DNS туннелирования. Принцип работы DNS туннелирования на пальцах Пять шагов DNS туннелирования: Злоумышленник использует DNS для маскировки вредоносных действий, т.к DNS трафик в 99,99% разрешен и не проверяется; Далее злодеи туннелирует другие протоколы (к примеру, http) через DNS Далее они туннелируют IP-трафик и передают украденную информацию Украденную информация снова преобразуют в удобный для восприятия вид Установленный туннель используют для передачи вредоносного ПО Обратите внимание на скриншот - я запросил IP-адрес gismeteo.ru. В терминах технологии DNS, вы сделали запрос типа А (от слова Address). Типов подобных запросов существует несколько, и чуть ниже я попробую это продемонстрировать. В любом случае, под капотом у DNS работает простая схема клиентский запрос на сервер, который в свою очередь отвечает клиенту обратно. А что если можно было бы "зашить" сообщение внутрь запроса? Представьте себе, что хакеры контролируют DNS сервер: в таком случае, они смогут просто собирать всю нужную информацию без риска оказаться замеченными. Опять же - как DNS запрос может быть нелегитимным? Все привыкли к тому, что эта служба работает всегда и не несет никакой угрозы. Но если служба оказалась скомпрометированной, злоумышленники могут фальсифицировать запросы и использовать информацию, скрытую в различных полях ответных пакетов для контроля вредоносного ПО на компьютере жертвы. Самая интересная часть - это туннелирование, то есть маскировка информации и передаваемых команд. Делается это, очевидно для того, чтобы подобный трафик прошел незамеченным мимо защитных систем и ПО. Для маскировки используются base32, base 64, а порой и полноценное шифрование. Base32 и Base64 - это способы кодировки информации используя 32 символа и 64 соответственно. Суть данного упражнении в передаче любой информации в текстовом виде.У обоих методов есть минусы - Base32 код оказывается в 1,6 раза больше оригинальной информации, а Base64 - регистрозависим. Когда возник данный тип атак? Впервые подобный вид атак был упомянут в рассылке Buqtraq неким Оскаром Пирсоном в апреле 1998 года. Далее в 2004 на ежегодной конференции Black Hat была представлена подробная техника - то есть буквально руководство по использованию данной атаки. Шло время и данный тип атак становился все популярнее - сегодня этот механизм встроен буквально в каждый вирус-шифровальщик. Попробуйте погуглить словосочетание Sea Turtle - это все еще активная кампания, целью которой является взлом легитимных DNS серверов для перенаправления запросов на свои собственные сервера. То есть злоумышленники смогут отвечать на эти запросы ложными сайтами. К примеру пользователь будет пытаться зайти на Facebook или свой аккаунт Ozon, но на самом деле это будут копии страниц, созданные для перехвата пользовательской информации. Честно говоря, такой тип атак не имеет ничего общего с туннелированием DNS, но вектор атаки остается тем же. И представьте себе последствия от украденных учетных данных - лично я бы не хотел, что злоумышленники получили доступ к моим аккаунт в онлайн банках и социальных сетях. Основные опасности DNS туннелирования Как вы уже могли понять из моей спутанной и слегка аутичной статьи, DNS туннелирование является механизмом, который является катализатором для различного вида неприятностей, а именно: Утечка данных: злоумышленники используют DNS для банального вывода текстовой информации с помощью определенной маскировки. Объемы вывода небольшие, но порой много и не требуется - к примеру, данные паспорта улетят очень быстро; Удаленный контроль: злоумышленники отправляют различные команды через DNS, к примеру для управления RAT-ами (троянами с удаленным управлением). К слову, большое количество шифровальщиков именно так получают свои инструкции и ключи шифрования; IP-Over-DNS туннелирование: сейчас уже можно найти специальные утилиты, в которых IP стэк имплементирован в клиент-серверную модель работы DNS. То есть такие утилиты позволяют относительно просто передавать информацию используя стандартные штуки вроде FTP, Netcat, ssh и пр. То есть через DNS можно будет передать буквально любую информацию Техники детектирования DNS - туннелирования Существует два основных метода по обнаружения некорректного использования DNS службы: анализ трафика и анализ полезной нагрузки. При анализе полезной нагрузке необходимо обращать внимание на странные и аномальные запросы, особенно если они содержат в себе странные доменные имена, странные символы и пр. Для выявления подобного используются различные статистические техники. В свою очередь, при анализе трафика, нужно обращать внимание на общее количество запросов к домену и сравнивать это число со средними значениями. Хакеры, осуществляющие DNS туннелирование, будут создавать большой объем DNS трафика - что сразу должно вызвать подозрения, так как отличия в объемах будут буквально на порядки. Утилиты для создания DNS туннеля: Если вам хочется посмотреть, уязвима ли ваша инфраструктура к такому виду атак, то можете попробовать несколько утилит из списка ниже (только на свой страх и риск). Все эти утилиты реализуют IP-over-DNS механизм атак. Iodine: данная утилита доступна на большинстве платформ (Linux, Mac OS, Windows, FreeBSD) и позволяет установить SSH туннель между целью и вашим компьютером. Утилита не самая простая, когда-нибудь мы напишем статью чс примером ее использования; OzymanDNS: функционал схож с Iodine, то есть утилита также позволяет строить SSH туннель. Интересно то, что это проект целиком и полностью написан на Perl; DNSCat2: многофункциональный комбайн, который создает зашифрованный канал для управления (C2) и позволяет скачивать/загружать файлы, запускать cmd/powershell и пр. Утилиты для мониторинга DNS туннеля: dnsHunter: модуль на питоне, написанный для Mercenary-Linux. Данный модуль читает .pcap файлы, выделяет из них DNS-запросы и осуществляет геолукапы, что также может помочь при расследовании; reassemble_dns: также утилита, написанная на питоне, которая позволяет читать .pcap файлы и реконструировать DNS запросы;
img
Когда дело доходит до облачной инфраструктуры, виртуальная машина является стандартом перехода по многим своим преимуществам. Однако, что делать, если у вас была альтернатива виртуальной машине, которая была бы более легкой, экономичной и масштабируемой? Это именно то, чем является Docker. Docker - это контейнерная технология, позволяющая разрабатывать распределенные приложения. В этой статье мы объясним разницу между виртуальными машинами и контейнерами Docker. Что такое виртуальная машина? Виртуальная машина - это система, которая действует точно так же, как компьютер. Виртуальные машины позволяют запускать операционную систему в приложении, которое ведет себя как полноценный отдельный компьютер. Вы можете использовать их для работы с различными операционными системами, запускать программное обеспечение, которое не может работать на вашей основной ОС. Что такое Docker? Docker - это инструмент, который использует контейнеры для упрощения создания, развертывания и запуска приложений. Он связывает приложение и его зависимости внутри контейнера. Docker против виртуальной машины Теперь поговорим о существенных различиях между докерными контейнерами и виртуальными машинами. Что ж, существенными различиями являются их поддержка операционной системы, безопасность, мобильность и производительность. Итак, давайте обсудим каждый из этих терминов. Поддержка операционной системы Поддержка операционной системы виртуальной машины и контейнера Docker сильно отличается. На изображении выше вы можете видеть, что каждая виртуальная машина имеет свою гостевую операционную систему над основной операционной системой, что делает виртуальные машины тяжелыми. С другой стороны, контейнеры Docker используют общую операционную систему хоста, и поэтому они легковесны. Совместное использование операционной системы хоста между контейнерами делает их очень легкими и помогает им загружаться всего за несколько секунд. Следовательно, накладные расходы на управление контейнерной системой очень низкие по сравнению с виртуальными машинами. Docker контейнеры подходят для ситуаций, когда вы хотите запустить несколько приложений в одном ядре операционной системы. Но если у вас есть приложения или серверы, которые должны работать в разных версиях операционной системы, тогда требуются виртуальные машины. Безопасность Виртуальная машина не имеет общей операционной системы, и в ядре хоста существует сильная изоляция. Следовательно, они более безопасны по сравнению с контейнерами. Контейнер имеет много угроз безопасности и уязвимостей, поскольку контейнеры имеют общее ядро хоста. Кроме того, поскольку ресурсы докера являются общими и не имеют пространства имен, злоумышленник может использовать все контейнеры в кластере, если он получает доступ даже к одному контейнеру. В виртуальной машине вы не получаете прямого доступа к ресурсам, а гипервизор предназначен для ограничения использования ресурсов в виртуальной машине. Портативность Контейнеры Docker легко переносимы, поскольку у них нет отдельных операционных систем. Контейнер может быть перенесен на другую ОС, и он может запуститься немедленно. С другой стороны, виртуальные машины имеют отдельную ОС, поэтому портирование виртуальной машины затруднено по сравнению с контейнерами, а также требуется много времени для портирования виртуальной машины из-за ее размера. Для целей разработки, где приложения должны разрабатываться и тестироваться на разных платформах, контейнеры Docker являются идеальным выбором. Производительность Сравнение виртуальных машин и контейнеров Docker было бы несправедливым, поскольку они оба используются для разных целей. Но легкая архитектура Docker и его менее ресурсоемкая функция делают его лучшим выбором, чем виртуальная машина. В результате контейнеры могут запускаться очень быстро по сравнению с виртуальными машинами, а использование ресурсов варьируется в зависимости от нагрузки или трафика в нем. В отличие от виртуальных машин, нет необходимости постоянно выделять ресурсы для контейнеров. Масштабирование и дублирование контейнеров также является простой задачей по сравнению с виртуальными машинами, поскольку в них нет необходимости устанавливать операционную систему. Вывод Вот таблица, которая показывает различия между виртуальной машиной и контейнером Docker. Виртуальная машинаDocker контейнерИзоляция процесса на аппаратном уровнеИзоляция процесса на уровне ОСКаждая виртуальная машина имеет отдельную ОСКаждый контейнер может совместно использовать ОСЗагружается в считанные минутыЗагружается в считанные секундыВиртуальные машины занимают несколько ГБКонтейнеры легкие (КБ / МБ)Готовые виртуальные машины трудно найтиГотовые док-контейнеры легко доступныВиртуальные машины могут легко перейти на новый хостКонтейнеры уничтожаются и воссоздаются, а не перемещаютсяСоздание ВМ занимает относительно больше времениКонтейнеры могут быть созданы в считанные секундыБольше использования ресурсаМеньшее использование ресурсов
img
Для устранения неполадок мы должны пройти путь от нижней части модели OSI к верхней. Для этого нам придется начать с протоколов, которые используются для коммутации. Будем думать о VLAN, транкинге, об агрегировании каналов и связующем дерева. Мы рассмотрим различные протоколы и различные сценарии, где "что-то работает" не так. Мы решим эти проблемы с помощью комбинации команд show и debug. Первая остановка ... проблемы с интерфейсом! Следующие статьи этого цикла: Траблшутинг STP (Spanning tree protocol) Устранение неисправностей EtherChannel Case #1 В этом примере мы имеем коммутатор в центре и два компьютера, которые подключены к нему. Каждый компьютер имеет свой IP-адрес, и они должны иметь возможность пинговать друг друга. Мы будем считать, что компьютеры настроены правильно и там нет никаких проблем. Интерфейс FastEthernet 0/1 находится в состоянии down. Это может указывать на проблему уровня 1, такую как неисправный кабель, неправильный кабель (кроссовер вместо прямого) или, возможно, нерабочая сетевая карта. Обратите внимание, что этот интерфейс работает в полудуплексном режиме. Если повезет, вы можете получить дуплексное сообщение через CDP, которое сообщит вам, что существует дуплексное несоответствие. Если вам не повезло, возможно, из-за этого ваш интерфейс переходит в состояние down. Имейте в виду, что гигабитный интерфейс не поддерживает halfduplex. SwitchA(config)#interface fa0/1 SwitchA(config-if)#duplex auto Изменим настройки интерфейса на duplex auto, чтобы коммутатор мог само настроиться. Может быть, нам повезет...но не в этот раз, пинг не работает. Интерфейс fa0 / 3, подключенный к хосту B, также не работает. После проверки кабелей и разъемов мы можем проверить ошибки дуплекса и скорости. Дуплекс включен в режим auto, так что это не является проблемой. Скорость была установлена на 10 Мбит, однако в то время как этот интерфейс является каналом Fast Ethernet (100 Мбит). SwitchA(config)#interface fa0/3 SwitchA(config-if)#speed auto Давайте переключим скорость на авто и посмотрим, что произойдет. Похоже, что несоответствие скорости привело к тому, что интерфейс перешел в состояние down. Изменение его на auto-speed возвращает интерфейс в состояние up. Это то, что мы искали. Интерфейсы, с которыми мы работаем, оба показывают состояние up/up. По крайней мере, теперь мы знаем, что нет никаких ошибок в кабеле, скорости или дуплексе. Теперь наш пинг проходит. Первый урок усвоен: Проверьте свои интерфейсы и посмотрите, отображаются ли они как up/up. Case #2 Та же топология, но здесь другая проблема. Хост A не может пропинговать хост B. Мы начнем с проверки интерфейсов: Состояние интерфейса FastEthernet0/3 выглядит нормально, но что-то не так с интерфейсом FastEthernet 0/1. Давайте изучим его подробнее: Так так, мы видим сообщение err-disabled. Это уже дает нам понять, что проблема, где здесь (по крайней мере, это означает, что мы на что-то наткнулись). Используйте команду show interfaces status err-disabled, чтобы узнать, почему интерфейс перешел в режим error-disabled. Это сообщит нам, что причина-безопасность порта. Мы можем посмотреть на конфигурацию безопасности порта, и мы видим, что только 1 MAC-адрес разрешен. Последний MAC-адрес, который виден на интерфейсе - 000с.2928.5c6c. Выше мы видим, что интерфейс был настроен для обеспечения безопасности на другой MAC-адрес. Именно по этой причине порт перешел в режим err-disabled. SwitchA(config)#interface fa0/1 SwitchA(config-if)#no switchport port-security Давайте уберем port security, чтобы решить эту проблему. SwitchA(config)#interface fa0/1 SwitchA(config-if)#shutdown SwitchA(config-if)#no shutdown Главное, что вы не должны забыть сделать - это после очистки настройки от port security ваш интерфейс все еще находится в режиме err-disabled. Вам нужно выполнить команды отключения и включения порта (shutdown и no shutdown), чтобы он снова заработал! Консоль сообщает нам, что интерфейс теперь включен. Как мы видим эхо-запрос проходит между компьютерами. Проблема решена! Урок 2 усвоен: проверьте, находится ли интерфейс в состоянии err-disabled, и если да, то: а) проверьте, почему это произошло, и Б) решите проблему. Case #3 Давайте продолжим с другой проблемой. Та же топология, но опять проблема. Эти два компьютера не "видят" друг друга. Интерфейсы выглядят хорошо, никаких ошибок здесь нет. И так мы видим, что port security отключена на этом коммутаторе. На данный момент мы, по крайней мере, знаем, что нет никаких проблем с интерфейсом и port security не фильтрует никакие MAC-адреса. В данный момент это хорошая идея, чтобы проверить информацию о VLAN. Вы можете использовать команду show vlan, чтобы быстро проверить, к какой VLAN принадлежат интерфейсы. Как вы можете видеть, наши интерфейсы находятся не в одной и той же VLAN. SwitchA(config)#interface fa0/3 SwitchA(config-if)#switchport access vlan 1 Мы переместим интерфейс fa0/3 обратно в VLAN 1. Теперь оба компьютера находятся в одной VLAN. Проблема решена! Урок 3 усвоен: убедитесь, что интерфейсы находится в нужной VLAN. Case #4 Пришло время для другой проблемы! Наши два компьютера не пингуюся между собой. Вы теперь знаете, как выглядит неудачный пинг, поэтому скрин не будет публиковаться снова. Интерфейсы не показывают никаких ошибок. Мы изучим настройку VLAN. Вы видите, что FastEthernet 0/1 находится в VLAN 10, но мы нигде не видим FastEthernet 0/3. Вот возможные причины: Что-то не так с интерфейсом. Мы проверили и убедились, что это не так, потому что он показывает состояние up/up, поэтому он кажется активным. Интерфейс не в режиме access port, а в режиме trunk. Быстрый взгляд на информацию о коммутаторе показывает нам, что нам нужно знать. Мы убедились, что интерфейс fa0/3 находится в режиме trunk, а native VLAN - 1. Это означает, что всякий раз, когда хост B отправляет трафик и не использует маркировку 802.1 Q, наш трафик заканчивается в VLAN 1. SwitchA(config)#interface fa0/3 SwitchA(config-if)#switchport mode access SwitchA(config-if)#switchport access vlan 10 Мы включим fa0/3 в режим доступа и убедимся, что он находится в VLAN 10. Оба интерфейса теперь активны в VLAN 10. Возможно, лучше проверить информацию на коммутаторе. Теперь я могу отправить пинг с хоста а на хост Б...проблема решена! Урок 4 усвоен: убедитесь, что интерфейс находится в нужном режиме (доступ или магистральный режим). Case #5 Те же два компьютера, тот же коммутатор. Однако этот сценарий немного интереснее. Компьютеры не могут пинговать друг друга, поэтому давайте пройдемся по нашему списку "возможных" ошибок: Интерфейсы выглядят хорошо, up/up-это очень хорошо. Оба интерфейса находятся в VLAN 10, так что это тоже хорошо. Просто чтобы быть уверенным...там нет port security. Это очень интересная ситуация. Интерфейсы работают (в состоянии up/up), мы находимся в одной VLAN, и нет никакой защиты портов. Что еще может быть причиной "перекрытия" трафика? Ага! Это может быть не то, о чем нам может прийти в голову, но мы же можем использовать VACLs (VLAN access-list), чтобы разрешить или запретить трафик в пределах VLAN. Если вы устраняете неполадки коммутаторов, то необходимо проверить эту настройку, если все остальное кажется вам нормальным. В этом случае есть VACL, подключенный к VLAN 10, давайте проверим его. Есть два порядковых номера ... 10 и 20. Порядковый номер 10 соответствует access-list 1, и его задача состоит в том, чтобы отбросить трафик. Давайте посмотрим, что это за access-list 1: Не смущайтесь из-за заявления о разрешении здесь. Использование оператора permit в access-list означает, что он будет "соответствовать" подсети 192.168.1.0/24. Наши два компьютера используют IP-адреса из этого диапазона. Если он соответствует этому access-list, то VLAN access-map отбросит трафик. SwitchA(config)# vlan access-map BLOCKSTUFF 10 SwitchA(config-access-map)# action forward Давайте изменим действие на "forward" и посмотрим, решит ли оно нашу проблему. Ну вот, все работает. Урок 5 усвоен: если все остальное кажется нормальным, убедитесь, что нет никакого VACL! Case #6 Давайте продолжим урок 6 с другой топологией. Теперь вы знаете, что нам нужно сначала проверить интерфейсы, а затем VLAN. В этом примере у нас есть те же два компьютера, но теперь у нас есть два коммутатора. Пинг от Хост А к Хосту Б не работает, так с чего начнем поиск? Сначала мы проверим интерфейс fa0/1 на коммутаторе 1. Интерфейс запущен и работает, это switchport, назначенный для VLAN 10. Пока все выглядит неплохо. Port security не включен, так что нам не нужно беспокоиться об этом. Давайте проверим то же самое на коммутаторе 2. Интерфейс работает, и он был назначен на VLAN 10. В данный момент мы видим, что интерфейсы, "смотрящие" к компьютерам выглядят хорошо. В этот момент Вы могли бы сделать две вещи: Подключите другой компьютер к коммутатору 1 и назначьте его во VLAN 10. Посмотрите, можно ли общаться между компьютерами во VLAN 10, когда они подключены к одному коммутатору. Сделайте то же самое на коммутаторе 2. Проверьте интерфейсы между коммутатором 1 и коммутатором 2. Мы сконцентрируем свое внимание на интерфейсах между коммутатором 1 и коммутатором 2, потому что там много чего может пойти не так! Интерфейсы не показывают никаких проблем, время проверить информацию о switchport. Коммутатор A находится в магистральном режиме и использует инкапсуляцию ISL. Коммутатор B также находится в магистральном режиме, но использует инкапсуляцию 802.1Q. Имейте в виду, что (в зависимости от модели коммутатора) административный режим по умолчанию может быть dynamic auto. Два интерфейса, которые оба работают в dynamic auto режиме, станут портом доступа (access). Лучше всего самостоятельно переключить интерфейс в магистральный режим. В нашем случае оба интерфейса магистральные, так что это хорошо, но у нас есть несоответствие протокола инкапсуляции. SwitchA(config)#interface fa0/15 SwitchA(config-if)#switchport trunk encapsulation dot1q Мы изменим тип инкапсуляции, чтобы оба коммутатора использовали протокол 802.1Q. Проблема решена! И опять все работает. Урок 6 усвоен: убедитесь, что при настройке магистралей используется один и тот же протокол инкапсуляции. Case #7 Вот опять тот же сценарий. Сейчас рассмотрим еще кое-что, что важно проверить при решении проблем trunk. Предположим, мы проверили и убедились, что следующие элементы не вызывают никаких проблем: Интерфейсы (скорость/дуплекс). Безопасность портов. Конфигурация Switchport (назначение VLAN, интерфейс, настроенный в режиме доступа). К сожалению, эхо-запрос между компьютерами все еще не проходит. Давайте взглянем на интерфейсы fa0/15 на коммутаторах: Проверим, что оба интерфейса находятся в магистральном режиме и что мы используем один и тот же протокол инкапсуляции (802.1 Q). Здесь нет никаких проблем. Что-нибудь еще, что может пойти не так с этой магистральной связью? Да! Магистраль может быть работоспособной, но это не означает, что все VLAN разрешены по магистральному каналу связи. В приведенном выше примере вы видите, что разрешена только VLAN 20. SwitchA(config)#interface fa0/15 SwitchA(config-if)#switchport trunk allowed vlan all SwitchB(config)#interface fa0/15 SwitchB(config-if)#switchport trunk allowed vlan all Давайте позволим всем VLAN пройти магистраль. По магистральной линии может передаваться трафик VLAN 10 между двумя коммутаторами. В результате пинг идет между компьютерами....еще одна проблема решена! Урок 7 усвоен: всегда проверяйте, разрешает ли магистраль все VLAN или нет. Case #8 Вот вам новый сценарий. Два компьютера, имеют разные IP-адреса. Коммутатор - это многоуровневый коммутатор. Поскольку компьютеры находятся в разных подсетях, нам приходится беспокоиться о маршрутизации. Мы видим, что два компьютера не могут связаться друг с другом. С чего мы должны начать устранение неполадок? Это статья не о настройке windows, но нам нужно обратить внимание на наши хосты. Поскольку компьютеры должны "выйти из своей собственной подсети", мы должны проверить, что IP-адрес шлюза по умолчанию в порядке и доступен. Хост А может достичь шлюза по умолчанию, поэтому мы, по крайней мере, знаем, что хост А работает нормально. Вот IP-конфигурация хоста B. Давайте проверим доступность шлюза по умолчанию! Здесь тоже все работает. Мы знаем, что компьютеры рабочие, потому что они знают, как выйти из своей собственной подсети, и шлюз по умолчанию доступен. Пора проверить коммутатор. Как мы видим, что хост А находится в VLAN 10 и хост B находится в VLAN 20. Мы не проверяли, включены ли интерфейсы, потому что мы можем пинговать IP-адреса шлюза по умолчанию. Это говорит о том, что fa0/1 и fa0/3 работают, но мы не знаем, к какой VLAN они принадлежат. Были сконфигурированы два интерфейса SVI. Это IP-адреса, которые компьютеры используют в качестве шлюза по умолчанию. Так почему же наш коммутатор не маршрутизирует трафик? Наличие IP-адресов на интерфейсах не означает автоматическую маршрутизацию трафика. Для этого нам потребуется таблица маршрутизации. Этот коммутатор не имеет SwitchA(config)#ip routing Давайте включим маршрутизацию на этом коммутаторе. Давайте сделаем так, чтобы это выглядело получше. Теперь коммутатор знает, куда перенаправлять IP-пакеты на этом коммутаторе. Вот так...теперь два компьютера могут достучаться друг до друга! Проблема решена! Урок 8 усвоен: если вы используете многоуровневый коммутатор для маршрутизации interVLAN, убедитесь, что интерфейсы SVI настроены правильно и что маршрутизация включена. Мы рассмотрели наиболее распространенные ошибки, которые могут произойти с нашими интерфейсами, VLAN, транками и проблемами маршрутизации при использовании многоуровневых коммутаторов. В следующей статье мы рассмотрим связующее дерево. Spanning-tree-довольно надежный протокол, но есть ряд вещей, которые могут пойти не так, как, вы ожидаете. Кроме того, из-за неправильной настройки могут произойти некоторые странные вещи...давайте рассмотрим траблшутинг STP в следующей статье.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59