Ang mga kliyente ng VPN sa ASA ay kumukuha ng address mula sa maling DHCP pool
Basahin ang dhcp-server at dhcp-network-scope sa ASA bilang dalawang magkaibang field, itakda ang scope sa isang ruta-kayang address sa labas ng pool, pagkatapos ay i-verify ang ruta.
Ang mga kliyente ng AnyConnect ay lumalabas sa maling subnet, o tumatanggi ang DHCP server na magbigay ng kahit ano, habang ang patakaran ng grupo ay mukhang tama sa unang tingin. Sa isang ASA may dalawang field sa dalawang lugar na parehong tunog na «saan galing ang mga address», at ang pagtatakda ng mali ay nagbubunga ng eksaktong ito. Pinapangalanan ng profile ng koneksyon ang DHCP server; pinapangalanan ng patakaran ng grupo ang isang subnet na pipiliin ng server na iyon. Wala sa dalawa ang gumagawa ng pool.
Tatlong bagay, tatlong tanong
Ihiwalay muna ang modelo ng paglalaan sa pool, dahil hindi nagbabahagi ng configuration ang dalawang modelo. Kung ang ASA mismo ang nagbibigay ng address, magtatakda ka ng lokal na pool at ituturo roon ang patakaran ng grupo. Kung panlabas na DHCP server ang nagbibigay, pinapangalanan ng profile ng koneksyon ang server na iyon at nagbibigay ang patakaran ng grupo ng hint sa scope. Ang paghahalo ng dalawa ang karaniwang dahilan kung bakit hindi kailanman lumalabas ang isang address.
| Intent | Objects involved |
|---|---|
| ASA allocates from its own pool | ip local pool plus the group policy's address-pool |
| External DHCP allocates | dhcp-server on the tunnel group, dhcp-network-scope on the group policy |
Basahin ang mga epektibong halaga bago baguhin ang isa
Ang linyang tinanggal ay hindi katulad ng hayagang none. Ipinapakita ng tumatakbong configuration kung ano ang tinipa mo; show run all group-policy ang nagpapakita kung ano talaga ang hinahantungan ng patakaran, kasama ang mga namamana na default. Suriin ang dalawa bago magpasyang mali ang scope, dahil ang patakarang grupo na nagmamana mula sa default na patakaran ay maaaring magbigay ng halagang hindi kailanman lumalabas sa maikling listahan.
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 ?
? ay sulit basahin sa naka-install na release mo, dahil nagkakaiba ang mga tinatanggap na halaga at ang kanilang help text sa pagitan ng mga bersyon. Dinodokumento ng reference ng Cisco ASA 9.24 para sa patakaran ng grupo ang attribute bilang ruta-kayang address sa gustong subnet, sa labas ng pool ng paglalaan, na mas pinipili ang address ng interface. Hindi ito ang saklaw ng pool at hindi ito ang numero ng network.
Itakda ang scope sa isang address, hindi sa isang saklaw
Ipagpalagay na ang pool na gusto mong gamitin ng server ay 10.50.30.50 hanggang 10.50.30.200 sa isang /24, at ang interface ng ASA sa segment na iyon ay 10.50.30.1. Ang halaga ng scope ay 10.50.30.1. Nabibigo ang pagsulat ng 10.50.30.0 dahil ito ang numero ng network, at nabibigo rin ang pagsulat ng saklaw dahil isang address lang ang tinatanggap ng attribute. Kung ang pipiliin mong address ay hindi address ng interface, kailangan nito ng static na ruta upang maabot ito ng sagot ng DHCP server.
group-policy RemoteStaff attributes
dhcp-network-scope 10.50.30.1
Ang pirasong ito ay gumagawa lamang ng isang bagay. Hindi nito kino-configure ang DHCP server, hindi ito gumagawa ng pool doon, at hindi nito ginagawang gumagana ang isang bahagyang profile ng malayuang pag-access. Ang dokumentadong pag-uugali rito ay IPv4 lamang; huwag asahan na kokontrolin nito ang DHCPv6 o pagdelegar ng prefix.
Baguhin ito nang may rollback point
Kumuha muna ng snapshot, upang ang rollback ay isang utos at hindi muling pagtatayo. I-save ang kaugnay na configuration sa isang file bago mag-edit, at alamin kung ano ang no ibinabalik sa release mo: ibinabalik nito ang attribute sa default o namamana nitong halaga, na maaaring none kaysa sa patakarang nasa itaas nito.
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
Ang pagtanggal ng attribute ay isang hakbang din sa diagnosis. Kapag walang tinukoy na scope, hinahanap ng DHCP server sa sarili nitong mga pool ang isang address na hindi pa naitalaga, kaya maaaring mapunta ang kliyente sa hindi inaasahang lugar ngunit kahit papaano ay kumokonekta. Sinasabi ng resultang iyon na gumagana ang landas ng kahilingan at ang pagpili ng pool ang nabibigo.
I-verify ang address, ang ruta at ang mga pahintulot
Basahin ang paglalaan mula sa talahanayan ng session at hindi mula sa dialog ng kliyente, pagkatapos ay kumpirmahin na ang address ay ruta-kaya pabalik sa tunnel at pinapayagan ng mga filter ng patakaran ng grupo ang trapik na inaasahan mo. Ang desisyon sa paglalaan ay hindi desisyon sa rutang, at ang kliyenteng tumatanggap ng address mula sa tamang pool ay maaari pa ring mabigo sa bawat kahilingan.
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
Kung ipinapakita ng session ang sinadya mong address ngunit namamatay ang trapik, tapos na ang scope bilang pinaghihinalaan. Tingnan ang pabalik na ruta, ang mga setting ng split-tunnel o filter sa patakaran ng grupo, at kung ang scope ng DHCP ay nasa segment na talagang ruta ng ASA.