ASA VPN-klientoj ricevas adresojn el la malĝusta DHCP-pulo
Legu dhcp-server kaj dhcp-network-scope de la ASA kiel du malsamajn kampojn, agordu la scope al enkursigebla adreso ekster la pulo, poste kontrolu la itineron.
AnyConnect-klientoj aperas en la malĝusta subreto, aŭ la DHCP-servilo rifuzas doni ion ajn, dum la grupa politiko ŝajnas ĝusta unuavide. Sur ASA ekzistas du kampoj en du lokoj, kiuj ambaŭ sonas kiel «de kie venas la adresoj», kaj agordi la malĝustan produktas ĝuste tion. La konekta profilo nomas la DHCP-servilon; la grupa politiko nomas subreton, el kiu tiu servilo elektu. Nek unu nek la alia kreas pulon.
Tri objektoj, tri demandoj
Unue apartigu la asignan modelon de la pulo, ĉar la du modeloj ne kunhavas agordon. Se la ASA mem disdonas adresojn, vi difinas lokan pulon kaj direktas la grupan politikon al ĝi. Se ekstera DHCP-servilo disdonas ilin, la konekta profilo nomas tiun servilon kaj la grupa politiko donas scope-sugeston. Miksi la du estas la kutima kaŭzo, kial adreso neniam aperas.
| 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 |
Legu la efektivajn valorojn antaŭ ol ŝanĝi unu
Forlasita linio ne samas kiel eksplicita none. La kuranta agordo montras, kion vi tajpis; show run all group-policy montras, al kio la politiko efektive solviĝas, inkluzive de hereditaj defaŭltoj. Kontrolu ambaŭ antaŭ ol decidi, ke la scope estas malĝusta, ĉar grupa politiko heredanta de defaŭlta politiko povas doni valoron, kiu neniam aperas en la mallonga listo.
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 ?
? indas legi en via instalita eldono, ĉar akceptataj valoroj kaj ilia helpteksto malsamas inter versioj. La Cisco ASA 9.24 referenco pri grupa politiko dokumentas la atributon kiel enkursigeblan adreson en la dezirata subreto, ekster la asignan pulon, kun prefero al interfaca adreso. Ĝi ne estas la pulo-gamo kaj ne estas la reta numero.
Agordu la scope al adreso, ne al gamo
Supozu, ke la pulo, kiun vi volas ke la servilo uzu, estas 10.50.30.50 ĝis 10.50.30.200 en /24, kaj la ASA-interfaco en tiu segmento estas 10.50.30.1. La scope-valoro estas 10.50.30.1. Skribi 10.50.30.0 malsukcesas, ĉar ĝi estas la reta numero, kaj skribi la gamon malsukcesas, ĉar la atributo prenas unu adreson. Se la adreso, kiun vi elektas, ne estas interfaca adreso, ĝi bezonas statikan itineron por ke la respondo de la DHCP-servilo povu atingi ĝin.
group-policy RemoteStaff attributes
dhcp-network-scope 10.50.30.1
Ĉi tiu fragmento faras nur unu aferon. Ĝi ne agordas la DHCP-servilon, ne kreas pulon tie, nek igas partan fora-aliro-profilo funkcianta. La dokumentita konduto ĉi tie estas nur IPv4; ne atendu, ke ĝi direktos DHCPv6 aŭ prefiksan delegadon.
Ŝanĝu ĝin kun restariga punkto
Unue faru snapshot-on, por ke la restarigo estu komando anstataŭ rekonstruo. Konservu la koncernan agordon en dosiero antaŭ ol redakti, kaj sciu, kion no restarigas en via eldono: ĝi resendas la atributon al ĝia defaŭlta aŭ heredita valoro, kiu povas esti none anstataŭ la politiko super ĝi.
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
Forigi la atributon ankaŭ estas diagnoza paŝo. Sen difinita scope, la DHCP-servilo serĉas en siaj propraj puloj neasignitan adreson, do la kliento povas alteriĝi ie neatendita sed almenaŭ konektiĝas. Tiu rezulto diras, ke la petvojo funkcias kaj ke la pula elekto estas tio, kio malsukcesas.
Kontrolu la adreson, la itineron kaj la permesojn
Legu la asignon el la sesia tabelo anstataŭ el la dialogo de la kliento, poste konfirmu, ke la adreso estas enkursigebla reen al la tunelo kaj ke la filtriloj de la grupa politiko permesas la trafikon, kiun vi atendas. Asigna decido ne estas enkursiga decido, kaj kliento, kiu ricevas adreson el la ĝusta pulo, ankoraŭ povas malsukcesi ĉe ĉiu peto.
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
Se la sesio montras la celitan adreson sed la trafiko mortas, la scope finiĝis kiel suspektato. Rigardu la revenan itineron, la split-tunnel aŭ filtro-agordojn en la grupa politiko, kaj ĉu la DHCP-scope sidas en segmento, al kiu la ASA efektive enkursigas.