По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Почитатей первую часть статьи про траблшутинг NAT/PAT на Cisco.
В этой части мы рассмотрим проблемы DHCP.
Урок 1
Вот новый сценарий, позвольте мне сначала объяснить его:
Зеленая зона - это наша локальная сеть, так что это наш NAT inside.
Красная область - это Интернет, поэтому это наш NAT outside.
Предполагается, что хост - это компьютер с шлюзом по умолчанию 192.168.12.2.
Наш маршрутизатор NAT подключен к маршрутизатору ISP.
Маршрутизатор ISP назначил нам подсеть 172.16.1.0 / 24, которую мы собираемся использовать для трансляции NAT.
BGP был настроен между NAT и маршрутизатором ISP для доступа к сети 192.168.34.0/24.
Предполагается, что веб-сервер прослушивает TCP-порт 80 и использует 192.168.34.3 в качестве шлюза по умолчанию.
Однако пользователи нашей локальной сети жалуются на то, что не могут подключиться к веб-серверу. Давайте проверим нашу конфигурацию NAT:
Мы можем убедиться, что трансляция работает:
Inside local IP-адрес нашего хоста.
Inside global находится один из IP-адресов из нашей подсети 172.16.1.0/24.
Outside local and global IP-адрес нашего веб-сервера
Эта трансляция выглядит хорошо, потому что все IP-адреса верные.
Мы видим, что маршрутизатор NAT научился достигать сети 192.168.34.0 / 24 через BGP.
Наш NAT-маршрутизатор может подключаться к веб-серверу, поэтому проблема с подключением отсутствует. Однако следует помнить одну важную вещь. Пакет IP, который производит маршрутизатор NAT, выглядит следующим образом:
IP-адрес получателя является нашим веб-сервером, и с ним нет проблем. Исходный IP-адрес - 192.168.23.2, и поскольку мы получили ответ, мы знаем, что маршрутизатор ISP знает, как достичь подсети 192.168.23.0 / 24. Это важно, поскольку подсеть 192.168.23.0 / 24 напрямую подключена к маршрутизатору ISP.
Однако, если мы отправляем эхо-запрос с хост-устройства, он преобразуется из-за NAT в IP-адрес в подсети 172.16.1.0/24. Пакет IP будет выглядеть так:
Вот что происходит, когда этот IP-пакет покидает маршрутизатор NAT и отправляется маршрутизатору ISP:
Маршрутизатор ISP получает IP-пакет и проверяет свою таблицу маршрутизации, знает ли он, куда отправлять трафик для сети 192.168.34.0 / 24.
Сеть 192.168.34.0/24 напрямую подключена к маршрутизатору ISP, поэтому она выполняет запрос ARP для MAC-адреса веб-сервера, получает ответ ARP и может пересылать IP-пакет на веб-сервер.
Веб-сервер хочет ответить, и он создает новый IP-пакет с IP-адресом назначения 172.16.1.
Поскольку веб-сервер имеет маршрутизатор ISP в качестве шлюза по умолчанию, он отправит IP-пакет маршрутизатору ISP.
Маршрутизатор ISP должен выполнить поиск в таблице маршрутизации, чтобы узнать, знает ли он, где находится сеть 172.16.1.0 / 24.
Маршрутизатор ISP не знает, где находится 172.16.1.0 / 24, и отбросит IP-пакет.
Если бы это была настоящая производственная сеть, у нас не было бы доступа к маршрутизатору ISP. Так как это эмуляция сети и устройств, к которой у нас есть доступ, поэтому давайте сделаем отладку!
ISP#debug ip packet 1
IP packet debugging is on for access list 1
ISP#conf t
ISP(config)#access-list 1 permit host 192.168.34.4
Сначала включим отладку IP-пакетов и используем список доступа, который соответствует IP-адресу веб-сервера.
Следующим шагом является то, что мы будем генерировать некоторый трафик с хост-устройства.
Это то, что будет производить маршрутизатор ISP. Он говорит нам, что понятия не имеет, куда отправить IP-пакет для 172.16.1.1 to...it является не маршрутизируемым и будет отброшен.
Так как же мы решим эту проблему? ISP-маршрутизатор требует сеть 172.16.1.0 /24 в таблице маршрутизации. Поскольку мы уже запустили BGP мы можем использовать его для объявления этой сети с нашего маршрутизатора NAT:
NAT(config)#ip route 172.16.1.0 255.255.255.0 null 0
NAT(config)#router bgp 1
NAT(config-router)#network 172.16.1.0 mask 255.255.255.0
Сначала мы создадим статическое правило, которое указывает сеть 172.16.1.0 / 24 на интерфейс null0. Мы делаю это потому, что невозможно объявлять то, чего у тебя нет. Следующий шаг-объявить эту сеть в BGP.
Пинг прошел проблема решена!
Итог урока: убедитесь, что ваши маршрутизаторы знают, как связаться с translated сетями.
Урок 2
Начнем с простого сценария. Маршрутизатор с левой стороны - это наш DHCP-клиент, а маршрутизатор с правой стороны - это наш DHCP-сервер. Клиент, однако, не получает никаких IP-адресов ... что может быть не так?
Сначала мы проверим, включен ли интерфейс на клиенте DHCP и настроен ли он для DHCP. И это действительно так.
Мы также должны убедиться, что интерфейс на сервере DHCP включен/включен и что у него есть IP-адрес. Пока все выглядит хорошо...
Если мы хотим быть абсолютно уверенным, что проблема не в клиенте, нам надо применить отладку командой debug dhcp detail, чтобы посмотреть, отправляет ли клиент DHCP сообщения об обнаружении DHCP.
Мы видим некоторые отладочные выходные данные, как показано выше. Это говорит о том, что наш DHCP-клиент отправляет сообщения DHCP Discover. Клиент, скорее всего, не является источником этой проблемы.
DHCPServer#show ip dhcp pool
Мы будем использовать команду show ip dhcp pool, чтобы проверить, существует ли пул DHCP. Вы видите, что у нас есть пул DHCP с именем "MYPOOL", и он настроен для подсети 192.168.12.0 / 24. Пока все выглядит хорошо.
Мы можем использовать команду show ip dhcp server statistics, чтобы узнать, что делает сервер DHCP. Вы видите, что он ничего не делает ... что это может значить?
Эта команда не часто применяется. show ip sockets показывает нам, на каких портах роутер слушает. Как вы видите, он не прослушивает никакие порты ... если мы не видим здесь порт 67 (DHCP), это означает, что служба DHCP отключена.
DHCPServer(config)#service dhcp
Включим сервис.
Так-то лучше! Теперь мы видим, что маршрутизатор прослушивает порт 67, это означает, что служба DHCP активна.
Как только служба DHCP будет запущена, вы увидите, что клиент получает IP-адрес через DHCP ... проблема решена!
Итог урока: если все в порядке, убедитесь, что служба DHCP работает.
Урок 3
Взгляните на сценарий выше. У нас есть 3 маршрутизатора; маршрутизатор на левой стороне настроен как DHCP-клиент для своего интерфейса FastEthernet0/0. Маршрутизатор с правой стороны настроен как DHCP-сервер. Помните, что DHCP-сообщения об обнаружении от клиентов транслируются, а не пересылаются маршрутизаторами. Вот почему нам требуется команда ip helper на маршрутизаторе в середине, именуемым как relay. Проблема в этом сценарии заключается в том, что клиент не получает IP-адреса через DHCP
Сначала мы проверим, что интерфейс настроен для DHCP. Мы определим это с помощью команды show ip interface brief.
DHCPClient(config)#interface fastEthernet 0/0
DHCPClient(config-if)#shutdown
DHCPClient(config-if)#no shutdown
Мы будем переводить интерфейс в режимы up и down для проверки, будет ли он отправлять сообщение DHCP Discover.
Мы видим, что сообщения DHCP Discover принимаются на DHCP-сервере. Это означает, что маршрутизатор в середине был настроен с IP helper, в противном случае мы даже не получили бы эти сообщения. Сообщения с предложениями DHCP отправлены, но мы не видим сообщений DHCPACK (Acknowledgment). Это дает нам понять, что что-то происходит...
DHCPServer#debug ip dhcp server packet
Включим отладку, чтобы увидеть, что происходит.
Мы видим, что наш DHCP-сервер пытается достичь IP-адреса 192.168.12.2, это интерфейс FastEthernet0/0 нашего маршрутизатора в середине. Знает ли DHCP-сервер, как добраться до этого IP-адреса?
Как вы можете видеть, его нет в таблице маршрутизации, это означает, что IP-пакеты с назначением 192.168.12.2 будут отброшены.
Чтобы доказать это, мы можем включить отладку
Здесь видим, что IP-адрес назначения 192.168.12.2 не является маршрутизируемым, и в результате IP-пакет будет отброшен. Давайте исправим эту проблему.
DHCPServer(config)#ip route 192.168.12.0 255.255.255.0 192.168.23.2
Мы добавим этот статический маршрут, чтобы исправить нашу проблему с подключением.
Через некоторое время вы должны увидеть, что клиент получает IP-адрес через DHCP.
Если вы оставили "debug ip dhcp server packet" включенным, вы увидите весь процесс DHCP:
DHCP Discover
DHCP Offer
DHCP Request
DHCP ACK
Вот и все ... проблема решена!
Итог урока: если вы используете IP helper, убедитесь, что DHCP-сервер знает, как связаться с подсетью, в которой находится клиент.
3 часть статьи про FHRP траблшутинг на Cisco доступна по ссылке.
Почитайте первую часть статьи.
Первая проблема. Два роутера работают с одной областью OSPF, и каждый роутер имеет loopback интерфейс, объявленный в OSPF. Вот вывод таблиц маршрутизации:
Как мы можем наблюдать, что роутер R1 узнал о сети 10.2.2.0/24 от роутера R2, но в таблице маршрутизации роутера R2 пусто. Что не так?
Видно, что OSPF не включен на интерфейсе loopback0 роутера R1, так что же мы тогда объявляем в сетях?
Похоже, мы объявляем сеть 10.10.1.0/24, но эта сеть не настроена ни на одном интерфейсе... Сеть 10.1.1.0/24 настроена на интерфейсе loopback0 роутера R1.
Здесь вы видите неправильно введенную команду network. Удалим ее.
R1(config)#router ospf 1
R1(config-router)#no network 10.10.1.1 0.0.0.0 area 0
R1(config-router)#network 10.1.1.0 0.0.0.255 area 0
Давайте удостоверимся, что команда network настроена правильно.
Проблема устранена! Эта проблема может показаться не серьезной, но использование неправильных сетевых операторов - это то, что происходит постоянно. Особенно если мы используем меньшие подсети (например, /27 или /28 или аналогичные), люди склонны делать ошибки с обратными маскам.
Итог урока: убедитесь, что вы настроили правильный сетевой адрес, обратную маску и область.
Видео: протокол OSPF (Open Shortest Path First) за 8 минут
Урок №2
Очередная возможная ситуация. Опять два роутера, но другая проблема. Вот таблицы маршрутизации:
В очередной раз роутер R2 не увидел сеть 10.1.1.0/24. Что интересно, что роутер R1 не имеет сети 10.1.1.0/24 в своей таблице маршрутизации как непосредственно подключенной.
Мы можем проверить, что роутер R1 использует правильную настройку команды network. Поскольку R1 даже не имеет сети в своей таблице маршрутизации, предположим, что проблема с интерфейсом.
Кажется, кто-то забыл применить команду "no shutdown" на интерфейсе.
R1(config)#interface loopback 0
R1(config-if)#no shutdown
Давайте включим интерфейс.
И теперь он появляется в таблице маршрутизации роутера R2. Итог урока: нельзя объявлять то, чего у тебя нет!
Урок №3
Новый урок! Одна область, опять два роутера... мы хотели бы иметь "full connectivity", но не работает OSPF ... вот вывод таблиц маршрутизации:
Роутер R1 не показывает никаких маршрутов OSPF, R2 показывает ... Необходимо выяснить, что не так:
Быстро взглянем на роутер R2, чтобы убедиться, что он действительно объявляет правильную сеть(и). Да это так и есть.
Вывод роутера R1 более интересен ... видно, что у него настроен distribute-list.
В этом заключается наша проблема. Давайте удалим distribute-list.
R1(config)#router ospf 1
R1(config-router)#no distribute-list 1 in
Эта команда отключит его.
Задача решена! Итог урока: знать о distribute-list, запрещающий объявление и / или установку префиксов в таблице маршрутизации.
Урок №4
Взглянем на более сложные проблемы OSPF. На изображении выше мы имеем роутер R1 и роутер R2, но на этот раз мы имеем конфигурацию OSPF с несколькими областями. Вот конфигурация OSPF этих роутеров:
Видно, что все сети были объявлены. Область 2 не связана напрямую с областью 0, поэтому была создана виртуальная связь.
Роутер R1, однако, не увидел сеть 2.2.2.0/24 от роутера R2, но роутер R2 увидел сеть 1.1.1.0/24. Лучше всего начать с виртуальной линии здесь:
Хм, это выглядит не очень хорошо. Виртуальная связь отключена. Обратите внимание на IP-адреса, которые мы видим здесь, это IP-адреса, настроенные на интерфейсах FastEthernet обоих маршрутизаторов.
Всякий раз, когда мы настраиваем виртуальное соединение, нам нужно настроить идентификатор маршрутизатора OSPF другой стороны, а не IP-адрес другой стороны!
Вот ошибка, так что давайте исправим ее.
R1(config)#router ospf 1
R1(config-router)#no area 12 virtual-link 192.168.12.2
R1(config-router)#area 12 virtual-link 2.2.2.2
R2(config)#router ospf 1
R2(config-router)#no area 12 virtual-link 192.168.12.1
R2(config-router)#area 12 virtual-link 1.1.1.1
Вот так должна выглядеть virtual-link, настроенная между идентификаторами маршрутизаторов OSPF.
Сразу после ввода правильных команд появятся данные сообщения в консоли.
Запись OSPF для сети 2.2.2.0/24 появилась.
Урок №5
Другая проблема. Те же роутеры, но появился "домен внешней маршрутизации". Это может быть другой протокол маршрутизации, такой как RIP или EIGRP, который мы будем распространять в OSPF. R2 перераспределяет сеть 2.2.2.0 / 24 в OSPF, но по какой-то причине она не отображается на R1. Чтобы было интересно, мы не будем просматривать конфигурацию OSPF на роутерах.
Нет сети 2.2.2.0/24 на роутере R1, поэтому давайте изучим роутер R2.
Как мы можем видеть, сеть находится в таблице маршрутизации роутера R2 как directly connected.
Как мы можем видеть роутер R2 был настроен для перераспределения напрямую подключенных сетей. Это должно включать сеть 2.2.2.0/24 на интерфейса loopback0.
Однако в базе данных OSPF пусто? Что может быть причиной этого? Возможно, вы помните правила различных типов областей OSPF. Давайте выясним, что это за область!
Вот и объяснение, это stub area! Stub area не допускают LSA type 5 (внешние маршруты). Мы можем либо превратить эту область в normal area или NSSA. Давайте переведем в NSSA.
R1(config)#router ospf 1
R1(config-router)#no area 12 stub
R1(config-router)#area 12 nssa
R2(config)#router ospf 1
R2(config-router)#no area 12 stub
R2(config-router)#area 12 nssa
Изменим тип области на обоих маршрутизаторах. Область NSSA допускает внешние маршруты с помощью LSA type 7.
Наша сеть 2.2.2.0 / 24 теперь в базе данных OSPF маршрутизатора R2.
Итог урока: Stub area не допускают внешних префиксов (LSA Type 5). Либо измените область на NSSA, либо прекратите перераспределение.
Урок №6
Очередная проблема. Проблема default route OSPF. На рисунке имеются роутер R1 и роутер R2, и сеть 192.168.12.0 /24 объявленная в OSPF. Loopback интерфейсы роутера R2 не объявляется в OSPF, но мы используем default route, чтобы роутер R1 мог добраться до них. Здесь представлены конфигурации OSPF:
Видно, что в выводе роутера R2 присутствует команда default-information originate для объявления default route.
Увы, но мы не видим default route на роутере R1. Будем искать неполадки в настройке. Давайте проверим роутер R2:
В таблице маршрутизации роутера R2 не виден default route. Чтобы OSPF объявлял default route, можно использовать два варианта:
Убедитесь, что у вас есть default route в routing table (невозможно объявлять то, чего нет);
Примените команду default-information originate always. Она объявит default route, даже если он не прописан.
R2(config)#ip route 0.0.0.0 0.0.0.0 null 0
Выше первый метод решения проблемы. Мы создадим default route на роутере R2. Обычно указывается default route на ISP роутере, но сейчас другого роутера нет. Мы укажем default route для интерфейса null0, и он будет внесен в routing table.
Правило работает!
R2(config)#no ip route 0.0.0.0 0.0.0.0 null 0
R2(config)#router ospf 1
R2(config-router)#default-information originate always
Итог урока: что бы объявить default route с помощью OSPF, вам нужно иметь default route в таблице маршрутизации или использовать ключевое слово "always".
Урок №7
Немного сложнее проблема... те же два роутера , все в зоне 0. Вот настройки OSPF:
Ничего особенного, все сети объявлены, и мы используем одну область.
Увы ... таблицы маршрутизации пусты! По крайней мере, никакой отсутствует информация о OSPF ... Настройки network выглядят хорошо, так что это хороший момент вникнуть поглубже в OSPF LSDB. Давайте сначала проверим идентификаторы маршрутизатора OSPF:
Здесь мы видим OSPF router ID. Если вы внимательно посмотрите на информацию выше, вы заметите что-то необычное. State full, но роутер R1 не выбрал DR / BDR, а роутер R2 выбрал роутер R1 в качестве BDR.
Мы можем использовать команду show ip ospf database router для поиска информации от определенного соседа OSPF. Роутер R1 говорит нам, adv router is not-reachable. Это плохо.
Роутер R2 также сообщает нам, что роутер R1 недоступен, и если вы посмотрите внимательно, то увидите, что он видит связь как point-to-point. Мы не видим этого в выводе на роутере R1. Это, вероятно, означает, что роутер R1 и роутер R2 используют другой тип сети OSPF, что приводит к разнице в LSDB. Это не позволит нашим роутерам устанавливать маршруты в таблицу маршрутизации!
Теперь мы кое-что выяснили. Тип сети отличается ... широковещательная передача на роутере R2 и точка-точка на роутере R1. Нам действительно удалось установить соседство OSPF с этим, но возникает разница в LSDB.
Произведем исправления.
R1(config)#interface fa0/0
R1(config-if)#ip ospf network broadcast
Изменение типа сети на роутере R1 сделает свое дело.
Наконец "О" появляется в наших таблицах маршрутизации...проблема решена!
Итог урока: убедитесь, что вы используете правильный тип сети OSPF на обоих роутерах.
Урок №8
Очередная внештатная ситуация. OSPF настроено между роутерами R1 и R2, но не все сети объявлены. Loopback интерфейсы роутера R2 перераспределяются в OSPF. Вот настройки обоих роутеров:
Мы наблюдаем команду redistribute connected на роутере R2, которая должна перераспределить сети на интерфейсах обратной связи в OSPF.
Однако здесь ничего нет ...
Обычно было бы неплохо проверить, есть ли distribute list или нет.
Ключ к решению этой проблемы - эта команда. Если вы наберете redistribute connected OSPF будет распространять только classful networks.
R2(config)#router ospf 1
R2(config-router)#redistribute connected subnets
Нам нужно добавить параметр "subnets", позволяющий заставить его выполнять redistribute subnet основных сетей.
Ну вот, наша маршрутная таблица заполнена.
Итог урока: добавьте параметр " subnets " при использовании перераспределения или перераспределяются только classful networks.
Active Directory, который является службой каталогов играет такую важную роль в структуре ИТ-инфраструктуры большинства организаций.
Служба каталогов - это система программного обеспечения, которая хранит, организует и предоставляет доступ к информации в каталоге операционной системы компьютера. В разработке программного обеспечения каталог представляет собой карту между именами и значениями. Это позволяет искать именованные значения, аналогично словарю. Чаще всего используется для представления персонала, материальных или сетевых ресурсов.
Коротко говоря: AD - это база данных служб каталогов, а LDAP - один из протоколов, которые вы можете использовать для общения с ней. LDAP - это протокол, а Active Directory - это сервер.
Что такое Active Directory?
Active Directory - это реализация служб каталогов, которая предоставляет все виды функций, таких как аутентификация, управление группами и пользователями, администрирование политик и многое другое. Active Directory служит единым хранилищем данных для быстрого доступа к данным для всех пользователей и контролирует доступ для пользователей на основе политики безопасности каталога.
Active Directory (AD) поддерживает как Kerberos, так и LDAP - Microsoft AD на сегодняшний день является наиболее распространенной системой служб каталогов, используемой сегодня. AD обеспечивает Single-SignOn (SSO) и хорошо работает в офисе и через VPN. AD и Kerberos не являются кроссплатформенными, что является одной из причин, по которой компании внедряют программное обеспечение для управления доступом для управления входами с разных устройств и платформ в одном месте. AD поддерживает LDAP, что означает, что он все еще может быть частью вашей общей схемы управления доступом.
Active Directory - это только один пример службы каталогов, которая поддерживает LDAP. Также есть и другие варианты: служба каталогов Red Hat, OpenLDAP, сервер каталогов Apache и другие.
А еще Active Directory можено интегрировать с Asterisk
Что такое LDAP?
LDAP (Lightweight Directory Access Protocol) - это открытый и кроссплатформенный протокол, используемый для аутентификации служб каталогов.
LDAP позволяет приложениям взаимодействовать с другими серверами служб каталогов. Это важно, потому что службы каталогов хранят и передают важную конфиденциальную информацию, связанную с пользователями, паролями и учетными записями компьютеров.
Как Active Directory и LDAP работают вместе?
Active Directory поддерживает LDAP, что означает, что вы можете объединить их, чтобы улучшить управление доступом. Фактически, многие различные службы каталогов и решения для управления доступом могут понимать LDAP, что делает его широко используемым в средах без Active Directory.
Что такое аутентификация LDAP?
В LDAP v3 есть два варианта аутентификации LDAP - простой и SASL (Simple Authentication and Security Layer).
Простая аутентификация допускает три возможных механизма аутентификации:
Анонимная аутентификация: предоставляет клиенту анонимный статус для LDAP.
Аутентификация без аутентификации: только для целей регистрации, не должна предоставлять доступ клиенту.
Аутентификация по имени или паролю: Предоставляет доступ к серверу на основе предоставленных учетных данных - простая аутентификация пользователя или пароля не является безопасной и не подходит для аутентификации без защиты конфиденциальности.
Аутентификация SASL связывает сервер LDAP с другим механизмом аутентификации, таким как Kerberos. Сервер LDAP использует протокол LDAP для отправки сообщения LDAP другой службе авторизации. Это инициирует серию ответных сообщений запроса, которые приводят либо к успешной аутентификации, либо к неудачной аутентификации.
Важно отметить, что по умолчанию LDAP передает все эти сообщения в виде открытого текста, поэтому любой человек, имеющий сетевой анализатор, может читать пакеты. Вам нужно добавить шифрование TLS или подобное, чтобы сохранить ваши имена пользователей и пароли в безопасности.
Что такое запрос LDAP?
Запрос LDAP - это команда, которая запрашивает у службы каталогов некоторую информацию. Например, если вы хотите увидеть, в какие группы входит конкретный пользователь, отправьте запрос, который выглядит следующим образом:
(&(objectClass=user)(sAMAccountName=yourUserName)
(memberof=CN=YourGroup,OU=Users,DC=YourDomain,DC=com))
Синтаксис не очень простой, но в официальном вики можно найти много примеров.