ретрансляция DHCP с NAT, сервер DHCP отправляет DHCPOFFER на неправильный IP-адрес
-
Я настроил NAT и ретрансляцию DHCP в GNS3, и все хосты имеют сквозную доступность, я могу пинговать PC44 с PC11 и PC22, а также с PC33, если настрою статический IP-адрес. На маршрутизаторе NAT (R11) я также настроил ретрансляцию DHCP с «helper-address» на интерфейсе LAN, к которому подключены клиенты DHCP. R11 напрямую подключен к R22. Сервер DHCP находится на R22. Там я настроил пул DHCP для хостов в сети 192.168.33.0/24 (LAN, подключенная к R11). Но поскольку я использую NAT (PAT), весь трафик из 192.168.33.0/24 преобразуется в внутренний глобальный адрес (200.1.1.1) на R22. NAT работает. Но DHCP-клиент, подключенный к R11, не может получить IP-адрес от DHCP-сервера R22. Отладка (debug ip dhcp server packet) на R22 показывает, что поступают сообщения DHCPDISCOVER. И отправляются сообщения DHCPOFFER. Отладка (debug ip packet detail) на R22 показывает, что пакеты с исходным IP-адресом внутреннего глобального адреса поступают на R22, однако она также показывает, что DHCP-сервер (R22) отправляет ответ на адрес назначения арендованного IP-адреса (например, 192.168.33.102), а не на публичный адрес, также известный как внутренний глобальный IP-адрес... Это нормальное поведение? Или я пропустил какую-то настройку конфигурации на R22? Редактировать: я добавил скриншот топологии сети.
-
Используя ip dhcp relay source-interface
под интерфейсом, вы можете увидеть, что теперь R3 (локальный DHCP-сервер) отправляет трафик на 100.0.0.2 вместо использования 10.0.0.2 Это решение для данного случая, если вы столкнетесь с ним в будущем. MHM ![Screenshot (362).png] ![Screenshot (363).png]
-
Вам необходимо опубликовать журналы отладки и конфигурацию SW11. R11, R22 для проверки. BB
=====Пренаямо Васудевам=====
***** Оценить все полезные ответы *****
Как обратиться за помощью к сообществу Cisco -
Я привожу конфигурацию R11 и R22. SW11 не является проблемой, поскольку компьютеры слева могут пинговать компьютер PC44 справа, то есть существует сквозная связь, а R11 является DHCP-сервером для VLAN22, который работает. Редактирование: добавлены теги кода для конфигураций IOS. Конфигурация R11: R11#sh run
Building configuration... Current configuration : 2436 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R11
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
no network-clock-participate slot 1
no network-clock-participate wic 0
no ip icmp rate-limit unreachable
ip cef
!
!
no ip dhcp use vrf connected
ip dhcp excluded-address 192.168.22.1 192.168.22.99
!
ip dhcp pool VLAN22
network 192.168.22.0 255.255.255.0
default-router 192.168.22.1
lease 0 1
!
!
!
interface FastEthernet0/0
no ip address
duplex auto
speed auto
!
interface FastEthernet0/0.1
encapsulation dot1Q 1 native
ip address 192.168.1.1 255.255.255.0
ip nat inside
ip virtual-reassembly
!
interface FastEthernet0/0.2
encapsulation dot1Q 22
ip address 192.168.22.1 255.255.255.0
ip nat inside
ip virtual-reassembly
!
interface FastEthernet0/0.3
encapsulation dot1Q 33
ip address 192.168.33.1 255.255.255.0
ip helper-address 200.1.1.2
ip nat inside
ip virtual-reassembly
!
interface Serial0/0
no ip address
shutdown
!
interface FastEthernet0/1
ip address 200.1.1.1 255.255.255.0
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
!
interface Serial0/1
no ip address
shutdown
!
ip forward-protocol nd
ip route 192.168.2.0 255.255.255.0 200.1.1.2
!
!
no ip http server
no ip http secure-server
ip nat pool INSIDEGLOBAL-VLAN1 200.1.1.100 200.1.1.105 netmask 255.255.255.0
ip nat inside source list VLAN1 pool INSIDEGLOBAL-VLAN1
ip nat inside source list VLAN22 interface FastEthernet0/1 overload
ip nat inside source list VLAN33 interface FastEthernet0/1 overload
!
ip access-list standard VLAN1
permit 192.168.1.0 0.0.0.255
ip access-list standard VLAN22
permit 192.168.22.0 0.0.0.255
ip access-list standard VLAN33
permit 192.168.33.0 0.0.0.255
! Конфигурация R22: R22#sh run
Building configuration... Current configuration : 1426 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R22
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
no network-clock-participate slot 1
no network-clock-participate wic 0
no ip icmp rate-limit unreachable
ip cef
!
!
no ip dhcp use vrf connected
ip dhcp excluded-address 192.168.33.1 192.168.33.99
!
ip dhcp pool VLAN33
network 192.168.33.0 255.255.255.0
default-router 192.168.33.1
lease 0 1
!
!
no ip domain lookup
ip auth-proxy max-nodata-conns 3
ip admission max-nodata-conns 3
!
!
!
!
!
!
ip tcp synwait-time 5
!
!
!
!
!
interface FastEthernet0/0
ip address 192.168.2.1 255.255.255.0
duplex auto
speed auto
!
interface Serial0/0
no ip address
shutdown
!
interface FastEthernet0/1
ip address 200.1.1.2 255.255.255.0
duplex auto
speed auto
!
interface Serial0/1
no ip address
shutdown
! -
Конфигурации, которые я только что опубликовал, по-видимому, не были одобрены? Разрешается ли публиковать конфигурации здесь?
-
В конце концов, хост получает IP-адрес от DHCP-сервера? Неважно, является ли IP-адрес запроса DHCP NAT или нет. Внутри запроса DHCP есть опция, которая указывает реальный IP-адрес, а не сопоставленный IP-адрес, и поэтому сервер DHCP (локальный DHCP) может использовать его для назначения IP-адреса из правильного пула. MHM
-
Мне удалось заставить это работать, используя расширенный ACL для NAT. Сначала он запрещает UDP-трафик для порта назначения 67 (если это порт назначения 67, адрес не будет преобразовываться), что позволяет устройству получить IP-адрес. В конце ACL я разрешаю весь остальной трафик, поэтому, если компьютер хочет выйти в Интернет, адрес будет преобразовываться как обычно.
-
Так вы не используете NAT для запросов DHCP? Как видно из топологии сети в моем посте выше, я использую адреса RFC1918 слева, поэтому они должны быть преобразованы. R22 следует рассматривать как маршрутизатор ISP, тот факт, что я использую 192.168.2.0/24 справа, можно игнорировать, но я могу это изменить.
-
Извините, я не заметил, что это был интернет-провайдер, я думал, что это другой сайт или что-то в этом роде, тогда мое решение не сработает.
-
Вы не ответили мне, получает ли хост IP-адрес?
Если сервер находится в штаб-квартире в нескольких милях от хоста, это означает, что хост не может получить IP-адрес? Как я уже упоминал, заголовок DHCP подвержен влиянию NAT, но внутри dhcp NAT не оказывает влияния. MHM -
PC33 не может получить IP-адрес от R22. Но, кажется, теперь все наконец-то работает... Проблема была в SW11. Очевидно, VLAN не существовали на коммутаторе. После добавления VLAN интерфейсы отображаются как часть этих VLAN... что странно, потому что я их настроил, но после повторного запуска GNS3 они исчезли... Спасибо за предложения. Нет, все еще не работает. Внезапно заработало по другой причине. Все еще не работает.
-
Пожалуйста, пожалуйста Хорошего дня MHM
-
Ложная тревога, все заработало, потому что я перезагрузил маршрутизаторы, не сохранив конфигурацию. Таким образом, R22 имел маршруты к сетям слева: ip route 192.168.33.0 255.255.255.0 200.1.1.1 что не должно было произойти, потому что эти сети являются частными, внутренними для предприятия, расположенного слева в топологии сети. Поэтому маршрутизатор «ISP» не должен иметь этих маршрутов. Вот отладка (
debug ip dhcp server packet
) на R22, когда PC33 отправляет DHCPDISCOVER, а R11 ретранслирует его: R22#
*Mar 1 00:17:09.443: DHCPD: DHCPDISCOVER received from client 0100.5079.6668.05 through relay 192.168.33.1.
*Mar 1 00:17:09.447: DHCPD: Sending DHCPOFFER to client 0100.5079.6668.05 (192.168.33.101).
*Mar 1 00:17:09.447: DHCPD: unicasting BOOTREPLY for client 0050.7966.6805 to relay 192.168.33.1.
*Mar 1 00:17:10.433: DHCPD: DHCPDISCOVER received from client 0100.5079.6668.05 through relay 192.168.33.1.
*Mar 1 00:17:10.437: DHCPD: Sending DHCPOFFER to client 0100.5079.6668.05 (192.168.33.101).
*Mar 1 00:17:10.441: DHCPD: unicasting BOOTREPLY for client 0050.7966.6805 to relay 192.168.33.1.
R22#
*Mar 1 00:17:13.430: DHCPD: DHCPDISCOVER received from client 0100.5079.6668.05 through relay 192.168.33.1.
*Mar 1 00:17:13.430: DHCPD: Sending DHCPOFFER to client 0100.5079.6668.05 (192.168.33.101).
*Mar 1 00:17:13.434: DHCPD: unicasting BOOTREPLY for client 0050.7966.6805 to relay 192.168.33.1. А вот отладка на R22
debug ip packet
: *Mar 1 00:22:18.426: IP: tableid=0, s=200.1.1.1 (FastEthernet0/1), d=200.1.1.2 (FastEthernet0/1), routed via RIB
*Mar 1 00:22:18.426: IP: s=200.1.1.1 (FastEthernet0/1), d=200.1.1.2 (FastEthernet0/1), len 392, rcvd 3
*Mar 1 00:22:18.438: IP: s=199.1.2.1 (local), d=192.168.33.1, len 328, unroutable
*Mar 1 00:22:19.423: IP: tableid=0, s=200.1.1.1 (FastEthernet0/1), d=200.1.1.2 (FastEthernet0/1), routed via RIB
*Mar 1 00:22:19.427: IP: s=200.1.1.1 (FastEthernet0/1), d=200.1.1.2 (FastEthernet0/1), len 392, rcvd 3
*Mar 1 00:22:19.435: IP: s=199.1.2.1 (local), d=192.168.33.1, len 328, unroutable Примечание: я изменил сеть справа с 192.168.2.0/24 на 199.1.2.0/24, чтобы она больше походила на какую-то интернет-сеть, поэтому 199.1.2.1 — это интерфейс f0/0 R22. -
Не волнуйтесь Теперь поделитесь IP-адресом, который получает запрос dhcp от хоста (IP-адрес интерфейса, настроенного с помощью ip dhcp helper) И конфигурацию dhcp.pool MHM
-
DHCP-ретранслятор, настроенный на R11: R11#sh run int f0/0.3
Building configuration... Current configuration : 165 bytes
!
interface FastEthernet0/0.3 encapsulation dot1Q 33 ip address 192.168.33.1 255.255.255.0 ip helper-address 200.1.1.2 ip nat inside ip virtual-reassembly
end Пул DHCP для VLAN33 слева (192.168.33.0/24), настроенный на R22: ip dhcp excluded-address 192.168.33.1 192.168.33.99
ip dhcp pool VLAN33 network 192.168.33.0 255.255.255.0 default-router 192.168.33.1 lease 0 1 И интерфейсы на R22: interface FastEthernet0/0 ip address 199.1.2.1 255.255.255.0 duplex auto speed auto
!
interface FastEthernet0/1 ip address 200.1.1.2 255.255.255.0 duplex auto speed auto
! Похоже, что R22 отправляет сообщение DHCPOFFER на IP-адрес назначения 192.168.33.X, что странно, потому что я настроил NAT на R11, и пакеты поступают на R22, как можно видеть с помощью
debug ip packet
с исходным IP-адресом 200.1.1.1. -
ip dhcp-relay source-interface < 200.1.1.1 interface> Затем снова проверьте отладку MHM
Здравствуйте! Похоже, вам интересна эта беседа, но у вас пока нет учетной записи.
Вы устали просматривать одни и те же посты каждый раз, когда заходите на сайт? После регистрации, вам не придётся искать обсуждения в которых вы принимали участие, настройте уведомления о новых сообщениях так как вам это удобно (по электронной почте или уведомлением). У вас появится возможность сохранять закладки и ставить лайки постам, чтобы выразить свою благодарность другим участникам сообщества.
С вашими комментариями этот пост может стать ещё лучше 💗
Зарегистрироваться Войти