Wêrom TACACS+-fersiken fan de ASA jo filiaal-VPN-tunnel misse

De filiaaltunnel is oan, brûkers autentisearje har by de fiere TACACS+-tsjinner, en de oanmelding fan 'e firewall sels rint noch altyd op tiid út. De oarsaak is gjin fout yn 'e tunnel: in LAN-to-LAN-tunnel ferfiert ferkear dat by syn selektors past, en behearferkear dat de ASA oer himsels generearret is in aparte stream mei syn eigen boarneadres. De measte teams ûntdekke dit yn in feroaringsfinster, as it iennichste behearderaccount it account is dat mislearret. Behannelje de AAA-sesje dy't de ASA begjint as in stream dy't jo ûntwerpe moatte, net as in byeffekt fan ferbining dy't al wurket.

De ASA is de klant, en syn eigen ferkear hat syn eigen paad nedich

As de firewall in TACACS+-tsjinner benadert, is de firewall in klant lykas elkenien, útsein dat nimmen bewust in rûte foar him konfigurearre hat. Syn pakketten komme fan in interface-adres op it apparaat, se wurde lokaal generearre ynstee fan trochstjoerd, en se moatte rûte, oerset en troch belied beskerme wurde krekt as brûkersferkear. In side-oant-side-tunnel dy't in brûkerssubnet beskermet, beskermet dy behearboarne net automatysk, want ferkearsseleksje is basearre op adressen en net op bedoeling.

Skriuw it adres op dat jo ferwachtsje dat de tsjinner sjocht. As jo it net yn ien rigel sizze kinne, hawwe jo noch gjin ûntwerp.

It interface yn 'e aaa-server-rigel is gjin fersiering

Op 'e ASA nimt de host-yngong aaa-server in interface-assosjaasje tusken heakjes oan, en Cisco's opdrachtreferinsje foar AAA-hosts beskriuwt it as it interface dêr't de autentikaasjetsjinner op sit. Krekt dy assosjaasje ferbynt it fersyk oan in interface en oan it belied dat dat interface tapast. Kiest men it op basis fan hokker interface dan ek nei it ynternet sjocht, of lit men stean wat der fan 'e lêste migraasje oer wie, dan ûntstiet in boarneadres dêr't de fiere tsjinner en de tunnel nea foar boud binne.

inside is allinnich it goede antwurd as it neamde interface it adres hat dat jo ûntwerp as boarne brûke wol. Op in filiaalapparaat is dat faak sa; op in apparaat mei ferskate privee segminten miskien net.

It feroarjen fan 'e assosjaasje betsjut de yngong opnij oanmeitsje

Deselde opdrachtreferinsje dokumintearret in bewurkingsbeheining dy't minsken by oergongen pakt: it feroarjen fan it interface op in besteande host freget om de host-yngong te ferwiderjen en opnij oan te meitsjen. In konfiguraasje dy't bewurke liket, is miskien net ynwurke, en de folgjende oanmeldpoging sil noch fan it âlde adres ôf gean. Plan dit as in fuortsmite-en-tafoegje mei in kopy fan 'e orizjinele yngong foar jo, net as in oanpassing op it plak sels.

As der ferskate tsjinners definiearre binne, feroarje dan ien en test dy foardat jo de oare oanreitsje, sadat in flater net alle behearspaden tagelyk ôfslút.

Kontrolearje selektors, oersetting en de weromrûte tagelyk

Trije dingen moatte oerienkomme foar't it fersyk oankomt. De ferkearsselektors fan 'e tunnel, of de tunnel-interface-beskerming as jo ien brûke, moatte de eigen boarne fan 'e ASA en it adres fan 'e tsjinner omfetsje; in selektorslist boud foar brûkerssubnetten sil dat ornaris net dwaan. Elke NAT-regel op it paad moat dy boarne konsekwint oersette, want de tsjinner autorisearret in netwurkapparaatidentiteit dy't it adres omfettet dat er sjocht. En de weromrûte moat bestean, wat op in beliedsbasearre tunnel betsjut dat de fiere kant in oerienkommende selektor yn 'e oare rjochting hat.

Oan 'e tsjinnerkant befêstigje de apparaatidentiteit, it dielde geheim en it behear belied apart. TACACS+ hâldt autentikaasje, autorisaasje en boekhâlding as aparte operaasjes, dus in wegering dy't nei in foltôge útwikseling komt is in beliedsantwurd, gjin transportflater. It lêze as in netwurkprobleem stjoert jo nei it ferkearde plak.

Hâld it geheim bûten opnames, tickets en transkripsjes wylst jo debugge, en tink derom dat it boarneadres dat de tsjinner logt datjinge is dat jo ûntwerp ferklearje moat.

Meitsje de feroaring sûnder josels bûten te sluten

Brûk in console of in ûnôfhinklik behearspaad wylst jo fiere behearsautentikaasje feroarje, en hâld in goedkarde lokale fallback oant it nije paad in echte oanmelding droegen hat. Falidearje dêrnei smel: ien tsjinner, ien apparaat, ien slagge autentikaasje mei it boarneadres oan beide kanten waarnommen.

Registrearje de stream op syn eigen side: oarsprongsinterface en -adres, fiere tsjinner, beskerme paad, en de persoan dy't it autorisaasjebelied besit. Dan kin in lettere interface- of tunnelferoaring beoardiele wurde sûnder te rieden hokker fan 'e twa streamen it rekket.