Kial TACACS+ petoj de ASA preterpasas la VPN-tunelon de via filio

La filia tunelo funkcias, uzantoj aŭtentikigas sin kontraŭ la fora TACACS+ servilo, kaj la propra ensaluto de la fajroŝirmilo ankoraŭ tempolimas. La kaŭzo ne estas cimo en la tunelo: LAN-to-LAN tunelo portas trafikon, kiu kongruas ĝiajn selektilojn, kaj la administra trafiko, kiun ASA generas pri si mem, estas aparta fluo kun propra fonta adreso. Plej multaj teamoj malkovras tion dum ŝanĝfenestro, kiam la sola administranta konto estas ĝuste tiu, kiu malsukcesas. Traktu la AAA seancon, kiun ASA iniciatas, kiel fluon, kiun vi devas desegni, ne kiel flankefikon de konektebleco, kiu jam funkcias.

ASA estas la kliento, kaj ĝia propra trafiko bezonas propran vojon

Kiam la fajroŝirmilo kontaktas TACACS+ servilon, la fajroŝirmilo estas kliento kiel ĉiu alia, krom ke neniu intence agordis itineron por ĝi. Ĝiaj pakaĵoj originas de interfaca adreso sur la aparato, ili estas generataj loke anstataŭ plusendataj, kaj ili devas esti itinerigitaj, tradukitaj kaj protektataj per politiko same kiel uzanta trafiko. Loko-al-loka tunelo, kiu protektas uzantan subreton, ne aŭtomate protektas tiun administran fonton, ĉar trafika elekto baziĝas sur adresoj kaj ne sur intenco.

Notu la adreson, kiun vi atendas, ke la servilo vidos. Se vi ne povas esprimi ĝin en unu linio, vi ankoraŭ ne havas desegnon.

La interfaco en la aaa-server linio ne estas ornamaĵo

En ASA la gastiga enskribo aaa-server akceptas interfacan ligon en krampoj, kaj la komanda referenco por AAA-gastigoj de Cisco priskribas ĝin kiel la interfacon, kie troviĝas la aŭtentikiga servilo. Ĝuste tiu ligo ligas la peton al interfaco kaj al la politiko, kiun tiu interfaco aplikas. Elekti ĝin laŭ tiu interfaco, kiu frontas la interreton, aŭ lasi tion, kio restis de la lasta migrado, produktas fontan adreson por kiu la fora servilo kaj la tunelo neniam estis konstruitaj.

inside estas la ĝusta respondo nur kiam la nomita interfaco tenas la adreson, kiun via desegno intencas uzi kiel fonton. Sur filia aparato tio ofte estas la kazo; sur aparato kun pluraj privataj segmentoj eble ne.

Ŝanĝi la ligon signifas rekrei la enskribon

La sama komanda referenco dokumentas redaktan limigon, kiu kaptas homojn dum transiroj: ŝanĝi la interfacon de ekzistanta gastigo postulas forigi kaj rekrei la gastigan enskribon. Agordo, kiu aspektas redaktita, eble ne efikiĝis, kaj la sekva ensalutprovo ankoraŭ eliros de la malnova adreso. Planu tion kiel forigon kaj aldonon kun kopio de la originala enskribo antaŭ vi, ne kiel ŝanĝeton surloke.

Se pluraj serviloj estas difinitaj, ŝanĝu unu kaj testu ĝin antaŭ ol tuŝi la aliajn, por ke eraro ne ŝlosu ĉiujn administrajn vojojn samtempe.

Kontrolu selektilojn, tradukon kaj la revenan vojon kune

Tri aferoj devas kongrui por ke la peto alvenu. La trafikaj selektiloj de la tunelo, aŭ la protekto de la tunela interfaco se vi uzas unu, devas inkluzivi la propran fonton de ASA kaj la adreson de la servilo; selektila listo konstruita por uzantaj subretoj kutime ne faros tion. Ĉiu NAT-regulo sur la vojo devas traduki tiun fonton konsekvence, ĉar la servilo rajtigas retaparatan identecon, kiu inkluzivas la adreson, kiun ĝi vidas. Kaj la revena vojo devas ekzisti, kio ĉe politiko-bazita tunelo signifas, ke la fora flanko havas kongruan selektilon en la kontraŭa direkto.

Ĉe la servila flanko, konfirmu aparte la aparatan identecon, la komunan sekreton kaj la administran politikon. TACACS+ tenas aŭtentikigon, rajtigon kaj kontadon kiel apartajn operaciojn, do rifuzo, kiu alvenas post kompletigita interŝanĝo, estas politika respondo, ne transporta paneo. Legi ĝin kiel retan problemon sendas vin serĉi en la malĝusta loko.

Tenadu la sekreton ekster kaptaĵoj, biletoj kaj transskriboj dum vi sencimigas, kaj memoru, ke la fonta adreso, kiun la servilo registras, estas tiu, kiun via desegno devas klarigi.

Faru la ŝanĝon sen ŝlosi vin ekstere

Uzu konzolon aŭ sendependan administran vojon dum vi ŝanĝas la foran administran aŭtentikigon, kaj tenu aprobitan lokan rezervon ĝis la nova vojo portos realan ensaluton. Poste validigu mallarĝe: unu servilo, unu aparato, unu sukcesa aŭtentikigo kun la fonta adreso observata ĉe ambaŭ finoj.

Registru la fluon sur sia propra paĝo: origina interfaco kaj adreso, fora servilo, protektita vojo kaj la persono, kiu posedas la rajtigan politikon. Tiam posta interfaca aŭ tunela ŝanĝo povas esti taksita sen diveni, kiun el la du fluoj ĝi efikas.