Miért kerülik el az ASA TACACS+ kérései a fióki VPN-alagutat

A fióki alagút él, a felhasználók a távoli TACACS+ kiszolgálónál hitelesítkeznek, a tűzfal saját bejelentkezése mégis időtúllépéssel megszakad. Az ok nem az alagút hibája: a LAN-to-LAN alagút azt a forgalmat viszi, amely illeszkedik a szelektoraihoz, az ASA pedig a magáról generált felügyeleti forgalmat külön folyamként, saját forrás-címmel küldi. A legtöbb csapat egy változási ablakban fedezi ezt fel, amikor az egyetlen adminisztrátori fiók az, amelyik meghiúsul. Kezelje az ASA által indított AAA-munkamenetet olyan folyamként, amelyet meg kell terveznie, nem pedig egy már működő kapcsolat mellékhatásaként.

Az ASA az ügyfél, és a saját forgalmának saját útvonal kell

Amikor a tűzfal TACACS+ kiszolgálót keres, a tűzfal ügyfél, mint bármelyik másik, azzal a különbséggel, hogy senki nem konfigurált neki szándékosan útvonalat. Csomagjai az eszköz interfész-címéről indulnak, helyben generálódnak továbbítás helyett, és útvonalazni, fordítani, valamint házirenddel védeni kell őket, akárcsak a felhasználói forgalmat. Az a hely-telephely alagút, amely egy felhasználói alhálózatot véd, nem védi automatikusan ezt a felügyeleti forrást, mert a forgalom kiválasztása címeken, nem szándékokon alapul.

Írja le a címet, amelyet a kiszolgáló látni fog. Ha egy sorban nem tudja megmondani, még nincs terve.

Az aaa-server sorban lévő interfész nem dísz

Az ASA-n a aaa-server hosztbejegyzés zárójelben interfész-hozzárendelést vesz fel, és a Cisco AAA hoszt parancsreferenciája úgy írja le, mint az interfészt, ahol a hitelesítési kiszolgáló található. Ez a hozzárendelés köti a kérést egy interfészhez és az ahhoz tartozó házirendhez. Ha az internet felé néző interfész szerint választja ki, vagy meghagyja, ami az utolsó migrációból maradt, olyan forrás-címet kap, amelyre a távoli kiszolgálót és az alagutat soha nem építették.

Az inside csak akkor a helyes válasz, ha a megnevezett interfész rendelkezik azzal a címmel, amelyet a terve forrásként használni akar. Fióki eszközön ez gyakran így van; több privát szegmenssel rendelkező eszközön talán nem.

A hozzárendelés módosítása a bejegyzés újralétrehozását jelenti

Ugyanez a parancsreferencia dokumentál egy szerkesztési korlátot, amely átállások idején megfogja az embereket: egy meglévő hoszt interfészének módosítása a hosztbejegyzés törlését és újralétrehozását igényli. Egy szerkesztettnek látszó konfiguráció lehet, hogy nem lépett életbe, és a következő bejelentkezési kísérlet még mindig a régi címről indul. Tervezze ezt törlésként és hozzáadásként, az eredeti bejegyzés másolatával maga előtt, nem helyben végzett módosításként.

Ha több kiszolgáló van megadva, módosítson egyet, és tesztelje, mielőtt a többihez nyúl, hogy egy hiba ne zárja le egyszerre az összes adminisztratív útvonalat.

Ellenőrizze a szelektorokat, a fordítást és a visszautat együtt

Három dolognak kell egyeznie ahhoz, hogy a kérés megérkezzen. Az alagút forgalomszelektorainak, vagy az alagút-interfész védelmének, ha ilyet futtat, tartalmaznia kell az ASA saját forrását és a kiszolgáló címét; a felhasználói alhálózatokhoz épített szelektorlista ezt általában nem teszi meg. Az útvonalon lévő bármely NAT-szabálynak konzisztensen kell fordítania ezt a forrást, mert a kiszolgáló olyan hálózatieszköz-identitást engedélyez, amely tartalmazza az általa látott címet. És a visszaútnak léteznie kell, ami házirend-alapú alagútnál azt jelenti, hogy a távoli végnek a másik irányban illeszkedő szelektora van.

A kiszolgáló oldalán külön ellenőrizze az eszközidentitást, a megosztott titkot és az adminisztratív házirendet. A TACACS+ a hitelesítést, az engedélyezést és az elszámolást külön műveletként tartja, ezért a befejezett csere után érkező elutasítás házirend-válasz, nem átviteli hiba. Ha hálózati problémaként olvassa, rossz helyen keres.

Hibakeresés közben tartsa a titkot a csomagrögzítéseken, jegyeken és átiratokon kívül, és ne feledje: a kiszolgáló által naplózott forrás-cím az, amelyet a tervének meg kell magyaráznia.

Hajtsa végre a változtatást anélkül, hogy kizárná magát

Használjon konzolt vagy független felügyeleti útvonalat a távoli adminisztratív hitelesítés módosítása közben, és tartson jóváhagyott helyi tartalékot, amíg az új útvonal valódi bejelentkezést nem vitt. Utána szűken validáljon: egy kiszolgáló, egy eszköz, egy sikeres hitelesítés a forrás-címmel mindkét végén megfigyelve.

Rögzítse a folyamot a saját oldalán: forrás-interfész és -cím, távoli kiszolgáló, védett útvonal, és az a személy, akié az engedélyezési házirend. Így egy későbbi interfész- vagy alagútmódosítás értékelhető anélkül, hogy találgatni kellene, melyik két folyamot érinti.