ASA-VPN-kliënte kry adresse uit die verkeerde DHCP-poel

Lees die ASA se dhcp-server en dhcp-network-scope as twee verskillende velde, stel die scope op ’n roeteerbare adres buite die poel en verifieer dan die roete.

AnyConnect-kliënte kom op die verkeerde subnet op, of die DHCP-bediener weier om enigiets uit te deel, en die groepsbeleid lyk met die eerste oogopslag korrek. Op ’n ASA is daar twee velde op twee plekke wat albei klink soos „waar adresse vandaan kom”, en om die verkeerde een te stel lewer presies dit. Die verbindingsprofiel noem die DHCP-bediener; die groepsbeleid noem ’n subnet waaruit daardie bediener moet kies. Nie een van hulle skep ’n poel nie.

Drie objekte, drie vrae

Skei eers die toekenningsmodel van die poel, want die twee modelle deel nie konfigurasie nie. As die ASA self adresse uitdeel, definieer jy ’n plaaslike poel en wys die groepsbeleid daarop. As ’n eksterne DHCP-bediener dit uitdeel, noem die verbindingsprofiel daardie bediener en die groepsbeleid verskaf ’n scope-hint. Om die twee te vermeng is die gewone rede waarom ’n adres nooit verskyn nie.

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

Lees die effektiewe waardes voordat jy een verander

’n Weggelaatde reël is nie dieselfde as ’n eksplisiete none. Die lopende konfigurasie wys wat jy getik het; show run all group-policy wys waarop die beleid werklik uitkom, insluitend geërfde verstekwaardes. Kontroleer albei voordat jy besluit die scope is verkeerd, want ’n groepsbeleid wat van ’n verstekbeleid erf, kan ’n waarde verskaf wat nooit in die kort lys verskyn nie.

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 ?

Die ?-uitvoer is die moeite werd om op jou geïnstalleerde weergawe te lees, aangesien aanvaarde waardes en hul hulpteks tussen weergawes verskil. Die Cisco ASA 9.24 groepsbeleid-verwysing dokumenteer die atribuut as ’n roeteerbare adres op die verlangde subnet, buite die toekenningspoel, met ’n koppelvlakadres wat verkies word. Dit is nie die poelreeks nie, en dit is nie die netwerknummer nie.

Stel die scope op ’n adres, nie ’n reeks nie

Veronderstel die poel wat jy vir die bediener wil hê is 10.50.30.50 tot 10.50.30.200 op ’n /24, en die ASA-koppelvlak op daardie segment is 10.50.30.1. Die scope-waarde is 10.50.30.1. Om 10.50.30.0 te skryf misluk omdat dit die netwerknummer is, en om die reeks te skryf misluk omdat die atribuut een adres neem. As die adres wat jy kies nie ’n koppelvlakadres is nie, benodig dit ’n statiese roete sodat die DHCP-bediener se antwoord dit kan bereik.

group-policy RemoteStaff attributes
 dhcp-network-scope 10.50.30.1

Hierdie fragment doen net een ding. Dit konfigureer nie die DHCP-bediener nie, skep nie ’n poel daar nie, en maak nie ’n gedeeltelike profiel vir afstandtoegang werkend nie. Die gedokumenteerde gedrag hier is slegs IPv4; moenie verwag dat dit DHCPv6 of prefix delegation stuur nie.

Verander dit met ’n terugrolpunt

Neem eers ’n momentopname, sodat die terugrol ’n opdrag is eerder as ’n herkonstruksie. Stoor die betrokke konfigurasie in ’n lêer voordat jy wysig, en weet wat no op jou weergawe herstel: dit bring die atribuut terug na sy verstek- of geërfde waarde, wat none kan wees eerder as die beleid daarbo.

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

Om die atribuut te verwyder is ook ’n diagnostiese stap. Met geen scope gedefinieer nie, soek die DHCP-bediener in sy eie poele na ’n onteikende adres, so die kliënt kan op ’n onverwagte plek beland maar maak ten minste verbinding. Daardie resultaat sê die versoekpad werk en die poelkeuse is wat misluk.

Verifieer die adres, die roete en die regte

Lees die toekenning uit die sessietabel eerder as uit die kliënt se dialoog, bevestig dan dat die adres terug na die tonnel roeteerbaar is en dat die groepsbeleid se filters die verkeer toelaat wat jy verwag. ’n Toekenningsbesluit is nie ’n roeteringsbesluit nie, en ’n kliënt wat ’n adres uit die regte poel kry, kan steeds elke versoek laat misluk.

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

As die sessie die adres wys wat jy bedoel het maar verkeer sterf, is die scope as verdagte afgehandel. Kyk na die terugroete, na split-tunnel- of filterinstellings op die groepsbeleid, en of die DHCP-scope op ’n segment sit waarna die ASA werklik roeteer.

Verwante artikels