VPN клиентите на ASA получават адреси от грешен DHCP пул

Четете dhcp-server и dhcp-network-scope на ASA като две различни полета, задайте scope на маршрутизируем адрес извън пула и след това проверете маршрута.

AnyConnect клиенти се появяват в грешната подмрежа или DHCP сървърът отказва да отпусне каквото и да е, а груповата политика изглежда правилна на пръв поглед. На ASA има две полета на две места, които и двете звучат като „откъде идват адресите“, и задаването на грешното дава точно това. Профилът на връзката именува DHCP сървъра; груповата политика именува подмрежа, от която този сървър да избира. Нито едно от двете не създава пул.

Три обекта, три въпроса

Първо отделете модела на разпределяне от пула, защото двата модела не споделят конфигурация. Ако ASA раздава адресите сам, дефинирате локален пул и насочвате груповата политика към него. Ако външен DHCP сървър ги раздава, профилът на връзката именува този сървър, а груповата политика подава подсказка за scope. Смесването на двете е обичайната причина адрес никога да не се появи.

IntentObjects involved
ASA allocates from its own poolip local pool plus the group policy's address-pool
External DHCP allocatesdhcp-server on the tunnel group, dhcp-network-scope on the group policy

Прочетете действащите стойности, преди да промените някоя

Пропуснат ред не е същото като явно none. Текущата конфигурация показва какво сте въвели; show run all group-policy показва до какво действително се свежда политиката, включително наследените стойности по подразбиране. Проверете и двете, преди да решите, че scope е грешен, защото групова политика, наследяваща от политика по подразбиране, може да подаде стойност, която никога не се появява в краткия списък.

show running-config group-policy RemoteStaff
show run all group-policy RemoteStaff
show running-config tunnel-group RemoteStaff
group-policy RemoteStaff attributes
 dhcp-network-scope ?

? си струва да се прочете за вашата инсталирана версия, тъй като допустимите стойности и техният помощен текст се различават между версиите. Справочникът на Cisco ASA 9.24 за груповата политика описва атрибута като маршрутизируем адрес в желаната подмрежа, извън пула за разпределяне, с предпочитание към адрес на интерфейс. Това не е диапазонът на пула и не е номерът на мрежата.

Задайте scope на адрес, а не на диапазон

Да предположим, че пулът, който искате сървърът да използва, е 10.50.30.50 до 10.50.30.200 в /24, а интерфейсът на ASA в този сегмент е 10.50.30.1. Стойността на scope е 10.50.30.1. Записването на 10.50.30.0 се проваля, защото това е номерът на мрежата, а записването на диапазона се проваля, защото атрибутът приема един адрес. Ако избраният адрес не е адрес на интерфейс, той се нуждае от статичен маршрут, за да може отговорът на DHCP сървъра да го достигне.

group-policy RemoteStaff attributes
 dhcp-network-scope 10.50.30.1

Този фрагмент прави само едно нещо. Той не конфигурира DHCP сървъра, не създава пул там и не превръща частичен профил за отдалечен достъп в работещ. Документираното поведение тук е само IPv4; не очаквайте да управлява DHCPv6 или делегиране на префикс.

Променете го с точка за връщане

Първо направете моментна снимка, така че връщането да е команда, а не преизграждане. Запазете съответната конфигурация във файл преди редактиране и знайте какво възстановява no във вашата версия: връща атрибута към стойността по подразбиране или наследената, която може да е none, а не политиката над него.

copy running-config flash:pre-dhcp-scope.cfg
conf t
 group-policy RemoteStaff attributes
  no dhcp-network-scope
  dhcp-network-scope 10.50.30.1
 end
write memory

Премахването на атрибута също е диагностична стъпка. Без дефиниран scope DHCP сървърът търси в собствените си пулове незает адрес, така че клиентът може да попадне на неочаквано място, но поне се свързва. Този резултат ви казва, че пътят на заявката работи и че изборът на пул е това, което се проваля.

Проверете адреса, маршрута и разрешенията

Четете назначението от таблицата на сесиите, а не от диалога на клиента, след което потвърдете, че адресът е маршрутизируем обратно към тунела и че филтрите на груповата политика позволяват трафика, който очаквате. Решението за разпределяне не е решение за маршрутизиране и клиент, който получава адрес от правилния пул, все още може да се провали при всяка заявка.

show vpn-sessiondb detail anyconnect filter name testuser
show ip local pool
show route | include 10.50.30
ping 10.50.30.61 source inside

Ако сесията показва адреса, който сте имали предвид, но трафикът умира, scope е приключен като заподозрян. Погледнете обратния маршрут, настройките за split-tunnel или филтрите на груповата политика и дали DHCP scope е в сегмент, към който ASA наистина маршрутизира.

Подобни статии