Klienci AnyConnect pojawiają się w niewłaściwej podsieci albo serwer DHCP odmawia wydania czegokolwiek, a polityka grupy na pierwszy rzut oka wygląda poprawnie. Na ASA są dwa pola w dwóch miejscach, które oba brzmią jak „skąd pochodzą adresy”, a ustawienie niewłaściwego daje dokładnie to. Profil połączenia wskazuje serwer DHCP; polityka grupy wskazuje podsieć, z której ten serwer ma wybierać. Żadne z nich nie tworzy puli.

Trzy obiekty, trzy pytania

Najpierw oddziel model przydziału od puli, bo oba modele nie dzielą konfiguracji. Jeśli ASA sam rozdaje adresy, definiujesz pulę lokalną i kierujesz na nią politykę grupy. Jeśli rozdaje je zewnętrzny serwer DHCP, profil połączenia wskazuje ten serwer, a polityka grupy podaje wskazówkę scope. Mieszanie obu to zwykła przyczyna tego, że adres nigdy się nie pojawia.

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

Przeczytaj obowiązujące wartości, zanim zmienisz którąkolwiek

Pominięty wiersz to nie to samo co jawne none. Bieżąca konfiguracja pokazuje, co wpisałeś; show run all group-policy pokazuje, do czego polityka faktycznie się sprowadza, wraz z odziedziczonymi wartościami domyślnymi. Sprawdź oba, zanim uznasz, że scope jest błędny, bo polityka grupy dziedzicząca z polityki domyślnej może podać wartość, która nigdy nie pojawia się na krótkiej liście.

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 ?

? warto przeczytać w swojej zainstalowanej wersji, bo akceptowane wartości i ich tekst pomocy różnią się między wersjami. Dokumentacja Cisco ASA 9.24 dla polityki grupy opisuje ten atrybut jako adres routowalny w żądanej podsieci, poza pulą przydziału, z preferencją adresu interfejsu. To nie jest zakres puli i nie jest numer sieci.

Ustaw scope na adres, nie na zakres

Załóżmy, że pula, której ma używać serwer, to 10.50.30.50 do 10.50.30.200 w /24, a interfejs ASA w tym segmencie to 10.50.30.1. Wartość scope to 10.50.30.1. Wpisanie 10.50.30.0 kończy się niepowodzeniem, bo to numer sieci, a wpisanie zakresu też, bo atrybut przyjmuje jeden adres. Jeśli wybrany adres nie jest adresem interfejsu, potrzebuje trasy statycznej, aby odpowiedź serwera DHCP mogła do niego dotrzeć.

group-policy RemoteStaff attributes
 dhcp-network-scope 10.50.30.1

Ten fragment robi tylko jedną rzecz. Nie konfiguruje serwera DHCP, nie tworzy tam puli i nie zamienia częściowego profilu dostępu zdalnego w działający. Opisane tu zachowanie dotyczy tylko IPv4; nie oczekuj, że będzie sterować DHCPv6 ani delegacją prefiksu.

Zmień to z punktem wycofania

Najpierw zrób snapshot, aby wycofanie było poleceniem, a nie odbudową. Zapisz odpowiednią konfigurację w pliku przed edycją i wiedz, co no przywraca w Twojej wersji: przywraca atrybut do wartości domyślnej lub odziedziczonej, która może być none, a nie polityka nad nim.

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

Usunięcie atrybutu to także krok diagnostyczny. Bez zdefiniowanego scope serwer DHCP szuka w swoich pulach nieprzydzielonego adresu, więc klient może trafić w nieoczekiwane miejsce, ale przynajmniej się łączy. Ten wynik mówi, że ścieżka żądania działa, a zawodzi wybór puli.

Zweryfikuj adres, trasę i uprawnienia

Czytaj przydział z tabeli sesji, a nie z okna klienta, następnie potwierdź, że adres jest routowalny z powrotem do tunelu i że filtry polityki grupy przepuszczają ruch, którego oczekujesz. Decyzja o przydziale nie jest decyzją o routingu, a klient, który otrzyma adres z właściwej puli, nadal może zawieść przy każdym żądaniu.

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

Jeśli sesja pokazuje zamierzony adres, ale ruch ginie, scope jest wykluczony jako podejrzany. Spójrz na trasę powrotną, ustawienia split-tunnel lub filtry w polityce grupy oraz na to, czy scope DHCP leży w segmencie, do którego ASA rzeczywiście routuje.

Powiązane artykuły