Clienții VPN ai ASA primesc adrese din pool-ul DHCP greșit

Citiți dhcp-server și dhcp-network-scope pe ASA ca două câmpuri diferite, setați scope-ul pe o adresă rutabilă în afara pool-ului și apoi verificați ruta.

Clienții AnyConnect apar în subrețeaua greșită, sau serverul DHCP refuză să dea absolut nimic, în timp ce politica de grup pare corectă la prima vedere. Pe un ASA există două câmpuri în două locuri care sună amândouă ca „de unde vin adresele”, iar setarea celui greșit produce exact asta. Profilul de conexiune numește serverul DHCP; politica de grup numește o subrețea din care acel server trebuie să aleagă. Niciunul dintre ele nu creează un pool.

Trei obiecte, trei întrebări

Separați mai întâi modelul de alocare de pool, pentru că cele două modele nu împart configurația. Dacă ASA distribuie singur adresele, definiți un pool local și îndreptați politica de grup spre el. Dacă le distribuie un server DHCP extern, profilul de conexiune numește acel server, iar politica de grup oferă un indiciu de scope. Amestecarea celor două este motivul obișnuit pentru care o adresă nu apare niciodată.

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

Citiți valorile efective înainte de a schimba una

O linie omisă nu este același lucru cu un none explicit. Configurația curentă arată ce ați tastat; show run all group-policy arată la ce se rezolvă politica de fapt, inclusiv valorile implicite moștenite. Verificați ambele înainte de a decide că scope-ul este greșit, pentru că o politică de grup care moștenește dintr-o politică implicită poate furniza o valoare care nu apare niciodată în lista scurtă.

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 ?

? merită citit în versiunea instalată, pentru că valorile acceptate și textul lor de ajutor diferă între versiuni. Referința Cisco ASA 9.24 pentru politica de grup documentează atributul ca adresă rutabilă în subrețeaua dorită, în afara pool-ului de alocare, cu preferință pentru o adresă de interfață. Nu este intervalul pool-ului și nu este numărul de rețea.

Setați scope-ul pe o adresă, nu pe un interval

Presupunem că pool-ul pe care doriți să îl folosească serverul este 10.50.30.50 până la 10.50.30.200 într-un /24, iar interfața ASA din acel segment este 10.50.30.1. Valoarea scope-ului este 10.50.30.1. Scrierea 10.50.30.0 eșuează pentru că este numărul de rețea, iar scrierea intervalului eșuează pentru că atributul ia o singură adresă. Dacă adresa pe care o alegeți nu este o adresă de interfață, are nevoie de o rută statică pentru ca răspunsul serverului DHCP să poată ajunge la ea.

group-policy RemoteStaff attributes
 dhcp-network-scope 10.50.30.1

Această secvență face un singur lucru. Nu configurează serverul DHCP, nu creează un pool acolo și nu transformă un profil parțial de acces la distanță într-unul funcțional. Comportamentul documentat aici este doar IPv4; nu vă așteptați să gestioneze DHCPv6 sau delegarea de prefix.

Modificați-l cu un punct de revenire

Faceți mai întâi un snapshot, ca revenirea să fie o comandă și nu o reconstrucție. Salvați configurația relevantă într-un fișier înainte de editare și știți ce no restaurează în versiunea dumneavoastră: readuce atributul la valoarea implicită sau moștenită, care poate fi none, nu politica de deasupra.

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

Eliminarea atributului este și un pas de diagnostic. Fără un scope definit, serverul DHCP caută în pool-urile proprii o adresă neatribuită, așa că clientul poate ajunge într-un loc neașteptat, dar măcar se conectează. Acel rezultat arată că traseul cererii funcționează și că ceea ce eșuează este selecția pool-ului.

Verificați adresa, ruta și permisiunile

Citiți alocarea din tabelul de sesiuni, nu din dialogul clientului, apoi confirmați că adresa este rutabilă înapoi spre tunel și că filtrele politicii de grup permit traficul pe care îl așteptați. O decizie de alocare nu este o decizie de rutare, iar un client care primește o adresă din pool-ul corect poate totuși eșua la fiecare cerere.

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

Dacă sesiunea arată adresa dorită, dar traficul moare, scope-ul este încheiat ca suspect. Uitați-vă la ruta de retur, la setările de split-tunnel sau de filtre din politica de grup și dacă scope-ul DHCP se află într-un segment către care ASA chiar rutează.

Articole similare