По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Windows включает в себя надежный (в целом 🙄), но простой в использовании, брандмауэр с расширенными возможностями. А с помощью PowerShell 7 можно легко настроить его из командной строки. В этой статье описываются общие команды, используемые в межсетевом экране Windows, а также возможные способы их использования.
Модуль NetSecurity хорошо задокументирован. Учтите, что эта статья относится только к операционной системе Windows. Для других операционных систем существуют другие инструменты командной строки, которые могут использоваться для выполнения тех же задач, такие как UFW или IPTables в Linux.
Вызов модуля NetSecurity
Предустановленный в системе модуль NetSecurity обладает всем необходимым функционалом для управления правилами межсетевого экрана Windows. Чтобы задействовать данный модуль, достаточно импортировать его показанным ниже способом (конечно же команду запускаем в PowerShell):
Import-Module -Name 'NetSecurity'
Вывод списка правил
Командлет Get-NetFirewallRule выводит список настроенных правил. В системе большое количество предварительно настроенных правил, но для примера мы выбрали первые 10:
Get-NetFirewallRule | Select-Object DisplayName, Enabled, Direction, Action -First 10
По умолчанию, командлет выводит все параметры, но на примере выше мы выбрали всего четыре из них (они, собственно, перечислены в команде). А получить все параметры можно командой:
Get-NetFirewallRule | Select-Object * -First 1
Создание нового правила
Создать новое правило позволяет команда New-NetFirewallRule. Основные параметры, которые нужно передать команде следующие:
DisplayName - название правила;
Direction - Направление трафика, которое нужно блокировать. Может быть либо входящим (Inbound), либо Исходящим (Outbound);
Action - Действие правила. Правило может быть либо Разрешающим (Allow), либо Запрещающим (Block).
$Params = @{ "DisplayName" = 'Block WINS' "Direction" = 'Inbound' "Action" = 'Block' "RemoteAddress" = 'WINS' }
New-NetFirewallRule @Params
Если не указан параметр Name, система сгенерирует случайный GUID. DisplayName может быть читабельным, но сам Name будет сгенерирован случайным образом.
Изменение существующего правила
Что если нужно изменить какой-то параметр правила, не удаляя и пересоздавая его? Для этого нужно задействовать командлет Set-NetFirewallRule.
$Params = @{
"DisplayName" = 'Block WINS'
"Action" = 'Allow'
}
Set-NetFirewallRule @Params
Данная команда также позволяет вносить изменения в несколько правил сразу. Это можно сделать, передав команде одно из трех параметров правила:
Name - Параметр по умолчанию. Если команде переданы несколько параметров Name в виде строки или же через пайплайн (|), изменения коснутся каждого из правил;
DisplayName - так же, как и в случае с параметром Name, команде можно передать нескольких правил, чтобы изменить их;
DisplayGroup или Group - Если несколько правил сгруппированы, то команде можно передать название этой группы и внести изменения во все члены указанной группы.
Удаление правила
И, наконец, мы хотим удалить правило, которое больше не нужно. Для этого запускаем командлет Remove-NetFirewallRule. Также при удалении часто рекомендуется использовать параметр WhatIf, который позволяет убедиться в том, что будет удалено нужное правило.
Remove-NetFirewallRule -DisplayName "Block WINS"
Следует отметить, что данный командлет позволяет удалять несколько правил сразу. На примере ниже мы удаляем все отключенные правила, которые содержит групповая политика firewall_gpo в домене ad.local.test.
Remove-NetFirewallRule -Enabled 'False' -PolicyStore 'ad.local.test\firewall_gpo'
Запущенный сам по себе командлет Remove-NetFirewallRule достаточно полезный, но в то же время опасный, так как удаляет все локально созданные правила. Если есть доменная групповая политика, определяющая правила межсетевого экрана, данная команда удалит все локальные правила, конфликтующие с правилами групповой политики.
Дополнительные возможности
Модуль NetSecurity включает в себя множество других команд, которые мы не затронули в данной статье. Поэтому ниже приводим список и возможности данных команд.
Copy-NetFirewallRule - данная команда копирует существующее правило и все связанные с ними фильтры в то же или другое хранилище политик;
Disable-NetFirewallRule - отключает ранее созданное правило. Отключенное правило не удаляется из базы, но уже никак не влияет на трафик. Если запустить эту команду без параметров, то она отключит все активные правила на целевой машине. Поэтому если не указано конкретное правило или группа правил, рекомендуется всегда запускать данную команду с параметром WhatIf;
Enable-NetFirewallRule - в противовес предыдущей команде, данный командлет включает все отключенные правила. Если не указано конкретное правило, то данную команду также рекомендуется запускать с параметром WhatIf;
Get-NetFirewallProfile - эта команда отображает параметры, настроенные для указанного профиля, например, профилей Domain, Private или Public;
Get-NetFirewallSettings - глобальные параметры брандмауэра можно получить с помощью команды Get-NetFirewallSettings. Это такие параметры, как параметры сертификатов, организация очередей пакетов или списки авторизации;
Rename-NetFirewallRule - данная команда позволяет переименовать существующее правило. Это полезно, если правило было создано без указания имени, таким образом получив случайный GUID в качестве название, и предпочтительно назначить читабельное название;
Set-NetFirewallProfile - для установки определенных параметров отдельных профилей можно использовать команду Set-NetFirewallProfile. Это позволяет каждому профилю иметь различные настройки;
Set-NetFirewallSettings - позволяет настроить поведение межсетевого экрана независимо от используемого профиля сети;
Show-NetFirewallRule - эта вспомогательная команда отображает правила брандмауэра и связанные с ними объекты в виде отформатированного списка.
Данный модуль также включает расширенные возможности для управления IPSec. Указанные выше команды управляют стандартными настройками межсетевого экрана Windows.
Заключение
Существует множество команд для управления межсетевым экраном Windows. В этой статье рассматриваются только некоторые из них, наиболее важные команды для быстрого вывода списка, создания, изменения и удаления правил брандмауэра. Но с помощью модуля NetSecurity можно сделать настройки и посложнее.
О переходе в IT профессию не думал разве только тот, кто в IT сфере уже работает. Высокие зарплаты, постоянная удаленка, куча плюшек и битвы HR-ов за самый оригинальный подкат к айтишнику на LinkedIn. Насмотревшись на фотографии и рассказы друзей айтишников, все это заставляет многих подумать: а не пора ли сменить профессию? Если задумались - значит пора. А мы, в свою очередь, поможем разобраться, какие бывают айтишники и как вам войти в айти.
Говоря про айтишников, многие представляют себе программистов, их еще называют девелоперы (от английского developer) или разработчики. Но поверьте, айти не заканчивается на них, а скорее только начинается. Разновидностей программистов - как товаров на Amazon: frontend, backend, full-stack, веб-программисты, мобильные и десктоп разработчики, DevOps программисты и прочие.
Особенно важно разобраться с тремя первыми - фронт, бэк, и фуллстэк.
Понять разницу между фронтэнд и бэкэнд девелопером - ну очень просто. Фронтенд пишет все, что происходит в видимой зоне, а бэкенд - за видимой зоной. Сейчас разберемся на конкретных примерах:
Netflix: красивую картинку с палитрой интересных киношек, кнопки, слайдеры и все, что вы видите в видимой зоне - сделали фронты. Алгоритмы рекомендаций, авторизацию, списание денег с вашей карты, то есть биллинг, и другие компоненты на фоне - сделали бэкенд девелоперы. Когда в следующий раз будете реветь от рекомендаций мелодрамы, которая ранила вас прямо в сердечко - это бэки постарались.
Amazon: карточки товаров, категории, навигация, отзывы и прочая визуальщина - фронты. Передача на на фронт актуальных цен товаров, калькуляция условий доставки в ваш регион мешка с леденцами со вкусом корицы, механизм умного поиска - бэки.
А еще есть фуллстэк программисты - это те, кто умеют и бэк и фронт.
В среднем, чтобы стать фронтом, надо поучить HTML, CSS, JavaScript - это база, с которой уже можно верстать сайты. Но технологии не стоят на месте и сейчас зачастую обычного знания JavaScript бывает недостаточно, поскольку во многих местах используются различные фреймворки расширяющие функционал языка, такие как React, Angular или Vue.
Ну а поскольку разработчик всегда работает с командой, то нужно знать как работать с системами управления версиями, зачастую это Git и уметь работать с API, чтобы найти общий язык с бэкэнд.
Бэкенд девелоперу, очевидно, нужно знать один из языков программирования для бэка. Какой? Вам нужно определиться самому. Посмотрите вакансии, которые вас интересуют и поймите, что нужно в компании вашей мечты.
Самые известные и популярные языки это Java, Python, PHP, С, С#, С++, Ruby и Go. Их очень много, но не стоит отчаиваться глядя на их количество - изучив один язык и поняв принципы программирования, вы сможете легко перейти на другой язык.
Еще можно выделить мобильных разработчиков, которые делают приложения для iOS и Android - им нужно подучить Objective-C и Swift для iOS и Kotlin или Java для андроида.
Поскольку разработчики пишут код не в вакууме, а взаимодействуют с различными системами, то вам нужно знать про SQL и принципы работы с базами данных. И очень важно уметь работать с NoSQL - нереляционными базами. Если хочешь заниматься только базами то для этого даже есть отдельная профессия - администратор баз данных (DBA).
Если вы будете заниматься веб разработкой, то нужно знать про принципы работы HTTP и про модель OSI, про веб сервера, как минимум Apache и Nginx, как работают API, аутентификация, основы безопасности. Уф, ну кажется этого должно хватить для начала.
Идем дальше - тестировщики, а они же QA (Quality Assurance). Тестирование бывает ручное, а бывает автоматическое. Автоматизаторы, безусловно, ближе к программистам - им нужно разрабатывать алгоритмы, знать процессы разработки ПО и его тестирования.
В ручном тестировании - все немного попроще. Зачастую тестирование становится отправной точкой для карьеры будущего айтишника. Входной билет сюда чуть ниже, войти проще. Нужно знать классификацию тестирования, методы и инструменты, уметь создавать сценарии тестирования. Нужно базово понимать протокол HTTP и модель OSI, немного HTML и CSS. Хорошо бы уметь работать с командной строкой, знать SQL, принципы API чтобы гонять запросы в каком-нибудь клиенте типа Postman, знать инструменты автоматического тестирования, такие как Selenium или Sahi.
Уф, кажется, основные профессии, связанные напрямую с разработкой софта мы проговорили. Теперь, друг, давай разберемся с не менее крутой частью IT, где ощущается острейший дефицит кадров - это инфраструктурные айтишники.
Итак, сетевые инженеры - без них не “взлетит” ни одно приложение, сервис, сайт, платформа, да что угодно! Сетевики настраивают маршрутизацию трафика, управляют сетью и гарантируют взаимодействие айти - инфраструктуры с внешними сетями. Открывая Tinder, каждый свайп вправо генерирует запрос к серверам, который прилетает в дата - центр тиндера и маршрутизируется на нужный сервер - это как раз сетевик постарался.
Сетевик должен знать основы сетевых технологий - классической школой в этом плане являются технологии Cisco (а также Huawei, Juniper и Mikrotik), надо знать технологии виртуализации, уметь работать с операционными системами Linux и Windows Server, иметь представления о кибербезопасности и уметь читать и базово говорить по английски.
И конечно безопасники - про их востребованность сейчас, вы наверняка догадываетесь. Среди них выделяют:
Инженеров - эти ребята делают безопасной сеть, настраивают фаерволы, антивирусы, анти-DDoS, прокси и прочие средства защиты
Аналитиков - которые выявляют инциденты, мониторят и находят вредоносную активность, расследуют взломы, утечки и другие неприятные моменты
Пентестеров - это HackerMan’ы по найму. Ага, эти ребята занимаются легитимным взломом, чтобы потом вы могли закрыть все дырки обнаруженные ими и не стать жертвой настоящих хакеров
Консультантов - знают все законы и требования в ИБ, помогут в получении нужных бумаг, чтобы не попасть на штрафники от всяких регуляторов
Appsec, Cloudsec - занимаются безопасностью приложений и облачной инфраструктуры
В компаниях постоянно идут эпические битвы между айтишниками и ИБшниками, потому что последние, довольно параноидальные ребята. Они стараются максимально обезопасить инфраструктуру и её активы, вводя для этого различные правила. Например - хочешь подключиться к корпоративному VPN? Сначала пройди двухфакторную аутентификацию! Долго? Зато безопасно.
Для безопасника будет полезно понимать основы сетевой безопасности, а также операционных систем, знать что такое триада CIA и принцип Defense in Depth, ну и конечно же - знать какие существуют методы атак, вредоносного ПО и прочих ИБ угроз.
Так же есть более узкопрофильные направления - Linux или Windows администратор, специалист по IP - телефонии, администратор баз данных, SRE инженер и многие другие! Ну и конечно можно наоборот выделить широкопрофильного системного администратора - специалиста, который настраивает и поддерживает ИТ инфраструктуру компании и должен знать много вещей из разных областей.
Так, кажется большинство популярных технических направлений мы проговорили. Теперь давайте прыгнем к менеджерам, тем, кто управляет ИТ проектами и продуктами с точки зрения бизнеса. Вообще, скажем так, быть техно - коммерческим специалистом в айти отрасли ну крайне выгодно: комбинируя хороший технический бэкграунд, знание бизнес специфики, добавив высокие коммуникативные навыки и надев белую рубашку вы автоматически получаете высочайшую зарплату, корпоративную тачку и прочие радости. Ладно, шутка, давайте разбираться.
Продакт менеджеры (они же продакты) - эти ребята отвечают за коммерческий успех продукта и реализацию бизнес требований. Продакт знает такие фреймворки как Scrum и Agile, должен знать цикл разработки программного обеспечения, отвечать за список задач на разработку, который также называют “бэклог” и обязательно уметь говорить на одном языке с разработчиками, топ-менеджментом, продавцами, маркетингом и другими подразделениями компании. Пожалуй, продакт должен знать такие инструменты как JIRA, Trello, Miro, Slack и Wrike, и уметь анализировать метрики успеха продукта.
Если хотите двигаться в это направление, рекомендуем получить интересующие вас технические навыки, а потом двигать в бизнес плоскость - почитать Lean Startup, “Спросите маму” Роберта Фитцпатрика и про Scrum у Джеффа Сазерленда. Эти книги помогут вам базово сориентироваться в пространстве и получить базовое представление.
Проектные менеджеры, они же delivery менеджеры - они отвечают за реализацию проекта - контроль сроков, доставку функций продукта в продакшн, то есть в реальную среду работы продукта, отвечают за организацию человеческих ресурсов и планирование, в том числе релизов. Из хард скиллов вам надо знать что такое "Диаграмма Ганта", изучите свод знаний по управлению проектами PMBOK, который разработан американским Институтом управления проектами (PMI), знать гибкие методологии и уметь работать с теми же инструментами, что и продакту (JIRA, Trello, Miro, Slack и Wrike).
А еще есть UX - дизайнеры, продуктовые дизайнеры, аналитики, но они имеют менее технический уклон, чем продакты и проджекты.
Познать востреброванные айти профессии, получая знания в легкой и дружелюбной форме можно с помощью нашей платформы доступного айти образования Merion Academy: ознакомиться со списком курсов и пройти бесплатные вводные уроки можно по этой ссылке.
Для устранения неполадок мы должны пройти путь от нижней части модели 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 в следующей статье.