ѕодпишитесь на наш Telegram-канал Ѕудьте в курсе последних новостей 👇 😉 ѕодписатьс€
ѕоддержим в трудное врем€ —пециальное предложение на техническую поддержку вашей »“ - инфраструктуры силами наших экспертов ѕодобрать тариф
ѕоставка оборудовани€ √аранти€ и помощь с настройкой. —кидка дл€ наших читателей по промокоду WIKIMERIONET  упить
»нтерфейс статистики Merion Mertics показывает ключевые диаграммы и графики по звонкам, а также историю звонков в формате, который легко поймет менеджер ѕопробовать бесплатно
¬недрение
офисной телефонии
Ўаг на пути к созданию доступных унифицированных коммуникаций в вашей компании ¬недрить
»нтеграци€ с CRM ѕомогаем навести пор€док с данными
и хранить их в единой экосистеме
ѕодключить
»“ Ѕезопастность ”мна€ информационна€ безопасность дл€ вашего бизнеса «аказать
ћерион Ќетворкс

8 минут чтени€

ѕочитатей первую часть статьи про траблшутинг 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:

show ip nat translations

ћы можем убедитьс€, что трансл€ци€ работает:

  • Inside local IP-адрес нашего хоста.
  • Inside global находитс€ один из IP-адресов из нашей подсети 172.16.1.0/24.
  • Outside local and global IP-адрес нашего веб-сервера

Ёта трансл€ци€ выгл€дит хорошо, потому что все IP-адреса верные.

show ip route | include 192.168.34.0

ћы видим, что маршрутизатор NAT научилс€ достигать сети 192.168.34.0 / 24 через BGP.

telnet

Ќаш NAT-маршрутизатор может подключатьс€ к веб-серверу, поэтому проблема с подключением отсутствует. ќднако следует помнить одну важную вещь. ѕакет IP, который производит маршрутизатор 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 будет выгл€деть так

¬от что происходит, когда этот IP-пакет покидает маршрутизатор NAT и отправл€етс€ маршрутизатору ISP:

  1. ћаршрутизатор ISP получает IP-пакет и провер€ет свою таблицу маршрутизации, знает ли он, куда отправл€ть трафик дл€ сети 192.168.34.0 / 24.
  2. —еть 192.168.34.0/24 напр€мую подключена к маршрутизатору ISP, поэтому она выполн€ет запрос ARP дл€ MAC-адреса веб-сервера, получает ответ ARP и может пересылать IP-пакет на веб-сервер.
  3. ¬еб-сервер хочет ответить, и он создает новый IP-пакет с IP-адресом назначени€ 172.16.1.
  4. ѕоскольку веб-сервер имеет маршрутизатор ISP в качестве шлюза по умолчанию, он отправит IP-пакет маршрутизатору ISP.
  5. ћаршрутизатор ISP должен выполнить поиск в таблице маршрутизации, чтобы узнать, знает ли он, где находитс€ сеть 172.16.1.0 / 24.
  6. ћаршрутизатор 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

Ёто то, что будет производить маршрутизатор 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 и настроен ли он дл€ DHCP. » это действительно так.

включен ли интерфейс на клиенте DHCP и настроен ли он дл€ DHCP

ћы также должны убедитьс€, что интерфейс на сервере DHCP включен/включен и что у него есть IP-адрес. ѕока все выгл€дит хорошо...

debug dhcp detail

≈сли мы хотим быть абсолютно уверенным, что проблема не в клиенте, нам надо применить отладку командой debug dhcp detail, чтобы посмотреть, отправл€ет ли клиент DHCP сообщени€ об обнаружении DHCP.

отладочные выходные данные

ћы видим некоторые отладочные выходные данные, как показано выше. Ёто говорит о том, что наш DHCP-клиент отправл€ет сообщени€ DHCP Discover.  лиент, скорее всего, не €вл€етс€ источником этой проблемы.

DHCPServer#show ip dhcp pool
show ip dhcp pool

ћы будем использовать команду show ip dhcp pool, чтобы проверить, существует ли пул DHCP. ¬ы видите, что у нас есть пул DHCP с именем "MYPOOL", и он настроен дл€ подсети 192.168.12.0 / 24. ѕока все выгл€дит хорошо.

show ip dhcp server statistics

ћы можем использовать команду show ip dhcp server statistics, чтобы узнать, что делает сервер DHCP. ¬ы видите, что он ничего не делает ... что это может значить?

show ip sockets

Ёта команда не часто примен€етс€. show ip sockets показывает нам, на каких портах роутер слушает.  ак вы видите, он не прослушивает никакие порты ... если мы не видим здесь порт 67 (DHCP), это означает, что служба DHCP отключена.

DHCPServer(config)#service dhcp

¬ключим сервис.

show ip sockets

“ак-то лучше! “еперь мы видим, что маршрутизатор прослушивает порт 67, это означает, что служба DHCP активна.

клиент получает IP-адрес через DHCP

 ак только служба DHCP будет запущена, вы увидите, что клиент получает IP-адрес через DHCP ... проблема решена!

»тог урока: если все в пор€дке, убедитесь, что служба DHCP работает.

”рок 3

” нас есть 3 маршрутизатора

¬згл€ните на сценарий выше. ” нас есть 3 маршрутизатора; маршрутизатор на левой стороне настроен как DHCP-клиент дл€ своего интерфейса FastEthernet0/0. ћаршрутизатор с правой стороны настроен как DHCP-сервер. ѕомните, что DHCP-сообщени€ об обнаружении от клиентов транслируютс€, а не пересылаютс€ маршрутизаторами. ¬от почему нам требуетс€ команда ip helper на маршрутизаторе в середине, именуемым как relay. ѕроблема в этом сценарии заключаетс€ в том, что клиент не получает IP-адреса через DHCP

show ip interface brief

—начала мы проверим, что интерфейс настроен дл€ DHCP. ћы определим это с помощью команды show ip interface brief.

DHCPClient(config)#interface fastEthernet 0/0
DHCPClient(config-if)#shutdown
DHCPClient(config-if)#no shutdown

ћы будем переводить интерфейс в режимы up и down дл€ проверки, будет ли он отправл€ть сообщение DHCP Discover.

show ip dhcp server statistics

ћы видим, что сообщени€ DHCP Discover принимаютс€ на DHCP-сервере. Ёто означает, что маршрутизатор в середине был настроен с IP helper, в противном случае мы даже не получили бы эти сообщени€. —ообщени€ с предложени€ми DHCP отправлены, но мы не видим сообщений DHCPACK (Acknowledgment). Ёто дает нам пон€ть, что что-то происходит...

DHCPServer#debug ip dhcp server packet

¬ключим отладку, чтобы увидеть, что происходит.

DHCP-сервер пытаетс€ достичь IP-адреса 192.168.12.2

ћы видим, что наш DHCP-сервер пытаетс€ достичь IP-адреса 192.168.12.2, это интерфейс FastEthernet0/0 нашего маршрутизатора в середине. «нает ли DHCP-сервер, как добратьс€ до этого IP-адреса?

show ip route

 ак вы можете видеть, его нет в таблице маршрутизации, это означает, что IP-пакеты с назначением 192.168.12.2 будут отброшены.

debug ip packet

„тобы доказать это, мы можем включить отладку

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.

клиент получает IP-адрес через DHCP

≈сли вы оставили "debug ip dhcp server packet" включенным, вы увидите весь процесс DHCP:

  1. DHCP Discover
  2. DHCP Offer
  3. DHCP Request
  4. DHCP ACK

¬от и все ... проблема решена!

»тог урока: если вы используете IP helper, убедитесь, что DHCP-сервер знает, как св€затьс€ с подсетью, в которой находитс€ клиент.

3 часть статьи про FHRP траблшутинг на Cisco доступна по ссылке.