Zakaj zahteve TACACS+ samega ASA obidejo tunel VPN vaše podružnice

Tunel podružnice je vzpostavljen, uporabniki se preverjajo na oddaljenem strežniku TACACS+, prijava samega požarnega zidu pa še vedno poteče. Vzrok ni napaka v tunelu: tunel LAN-to-LAN prenaša promet, ki ustreza njegovim selektorjem, upravljalni promet, ki ga ASA ustvari o sebi, pa je ločen tok z lastnim izvornim naslovom. Večina ekip to odkrije med oknom sprememb, ko je edini skrbniški račun prav tisti, ki ne uspe. Obravnavajte sejo AAA, ki jo začne ASA, kot tok, ki ga morate zasnovati, ne kot stranski učinek povezljivosti, ki že deluje.

ASA je odjemalec in njegov promet potrebuje svojo pot

Ko požarni zid stopi v stik s strežnikom TACACS+, je odjemalec kot vsak drug, le da mu nihče ni namerno konfiguriral poti. Njegovi paketi izhajajo iz naslova vmesnika na napravi, ustvarijo se lokalno, ne posredujejo, in jih je treba usmerjati, prevajati in zaščititi s politiko enako kot uporabniški promet. Tunel od lokacije do lokacije, ki ščiti uporabniško podomrežje, ne ščiti samodejno tega upravljalnega vira, ker izbira prometa temelji na naslovih in ne na namenu.

Zapišite naslov, za katerega pričakujete, da ga bo strežnik videl. Če ga ne morete povedati v eni vrstici, še nimate zasnove.

Vmesnik v vrstici aaa-server ni okras

Na ASA vnos gostitelja aaa-server sprejme povezavo z vmesnikom v oklepajih, in referenca ukazov gostitelja AAA podjetja Cisco jo opisuje kot vmesnik, na katerem je strežnik za preverjanje pristnosti. Prav ta povezava veže zahtevo na vmesnik in na politiko, ki jo ta vmesnik uporablja. Če jo izberete po tistem vmesniku, ki gleda v internet, ali pustite tisto, kar je ostalo od zadnje selitve, dobite izvorni naslov, za katerega oddaljeni strežnik in tunel nista bila nikoli zgrajena.

inside je pravilen odgovor le, kadar ima navedeni vmesnik naslov, ki ga vaša zasnova namerava uporabiti kot izvor. Na napravi v podružnici je to pogosto res; na napravi z več zasebnimi segmenti morda ne.

Sprememba povezave pomeni ponovno ustvarjanje vnosa

Ista referenca ukazov dokumentira omejitev urejanja, ki ljudi ujame med prehodi: sprememba vmesnika pri obstoječem gostitelju zahteva odstranitev in ponovno ustvarjanje vnosa gostitelja. Konfiguracija, ki je videti urejena, morda ni začela veljati, in naslednji poskus prijave bo še vedno šel s starega naslova. Načrtujte to kot brisanje in dodajanje s kopijo izvirnega vnosa pred seboj, ne kot popravek na mestu.

Če je določenih več strežnikov, spremenite enega in ga preizkusite, preden se dotaknete ostalih, da ena napaka ne zaklene vseh skrbniških poti hkrati.

Preverite selektorje, prevajanje in povratno pot skupaj

Tri stvari se morajo ujemati, da zahteva prispe. Selektorji prometa tunela, ali zaščita tunelskega vmesnika, če jo uporabljate, morajo vključevati lastni izvor ASA in naslov strežnika; seznam selektorjev, zgrajen za uporabniška podomrežja, tega običajno ne bo storil. Vsako pravilo NAT na poti mora ta izvor dosledno prevajati, ker strežnik avtorizira identiteto omrežne naprave, ki vključuje naslov, ki ga vidi. In povratna pot mora obstajati, kar pri tunelu, ki temelji na politikah, pomeni, da ima oddaljeni konec ustrezni selektor v nasprotni smeri.

Na strani strežnika ločeno potrdite identiteto naprave, skupno skrivnost in skrbniško politiko. TACACS+ ohranja preverjanje pristnosti, avtorizacijo in obračun kot ločene operacije, zato je zavrnitev, ki pride po končani izmenjavi, odgovor politike, ne napaka prenosa. Če jo berete kot omrežno težavo, boste iskali na napačnem mestu.

Med odpravljanjem napak imejte skrivnost zunaj zajemov paketov, zahtevkov in prepisov ter ne pozabite, da je izvorni naslov, ki ga strežnik zabeleži, tisti, ki ga mora vaša zasnova pojasniti.

Spremembo izvedite, ne da bi se zaklenili

Uporabite konzolo ali neodvisno pot upravljanja, ko spreminjate oddaljeno skrbniško preverjanje pristnosti, in imejte odobreno lokalno rezervno možnost, dokler nova pot ne prenese prave prijave. Nato preverite ozko: en strežnik, ena naprava, ena uspešna preveritev z izvornim naslovom, opaženim na obeh koncih.

Tok zabeležite na njegovi lastni strani: izvorni vmesnik in naslov, oddaljeni strežnik, zaščitena pot in oseba, ki ima politiko avtorizacije. Nato je mogoče poznejšo spremembo vmesnika ali tunela oceniti brez ugibanja, kateri od dveh tokov je prizadet.