SSH egy távoli ASA-hoz a site VPN-en keresztül: lépésről lépésre

Egy SSH-klienst a távoli ASA belső címére irányít, és a munkamenet a csatlakozásnál meghal. A tűzfal a saját site-járól válaszol, az alagút megjelenik, és mégsem figyel semmi a 22-es porton. A legtöbb ilyen esetben a csomag soha nem éri el a kezelési belépést, mert a tesztelt útvonalat soha nem kezelési útvonalnak tervezték. Kövesse az alábbi folyamatot sorrendben, és a hiba abbahagyja a vándorlást.

Válassza ki a címét, amelyet valóban kezel

Három kialakítás hasonlónak tűnik és másképp viselkedik: az ASA nyilvános, VPN felé néző címének elérése, egy belső interfész elérése IPsecen keresztül, és egy dedikált kezelési interfész elérése. Jegyezze fel az adminisztrátor forráscímét, a pontos célcímet és a TCP 22-t, mielőtt bármilyen engedélyhez nyúl. Minden további ettől a pártól függ.

Egy alagút, amely két szerver-VLAN-t szállít, lehet, hogy egyáltalán nem szállítja a tűzfal interfészcímét vagy az adminisztrátor kezelési alhálózatát. Ellenőrizze a site-to-site házirend érdekes forgalmának listáját, és erősítse meg, hogy az ASA saját címe célként jelenik meg, nem csak a rajta áthaladó alhálózatok.

Mivel a cél maga a tűzfal, a kezelési belépés elkülönül a továbbított forgalom szabályaitól. Egy ACL, amely beengedi az ügyfeleket az ASA mögötti szerverekhez, önmagában nem teszi lehetővé az eszköz SSH-kezelését, és a továbbítási szabály javítása nem mozdítja el ezt a hibát.

A management-access interfészhez kötött

A management-access parancs arra utasítja az ASA-t, hogy fogadja el a VPN-en érkező kezelési kapcsolatokat egy megnevezett interfészen. Nem hoz létre útvonalat, nem ad hozzá SSH-engedélyt, és nem vonatkozik egyszerre minden interfészre. Ha a célinterfész nem a megnevezett, a kapcsolat hitelesítés előtt eldobódik.

Két kivétel üt itt. A csak kezelésre szolgáló interfészek kívül esnek ezen a mechanizmuson, és az ASA 9.20 kezelési útmutató megjegyzi, hogy az alapértelmezett CiscoSSH verem nem támogatja az interfészek közötti SSH-t VPN-en át, míg az ASA SSH verem igen. Erősítse meg az aktív vermet a telepített kiadáson, mielőtt útvonalakra időt szán.

Négy kapu a bejelentkezési kérés előtt

Az ügyfél és a felhasználónév-kérés között négy független kapu áll: az útvonal és alagút egyezése a kezelési párhoz, egy interfész-ACL, amely engedélyezi a TCP 22-t az ASA címére, egy ssh-engedély, amely lefedi az adminisztrátor forrását, és AAA-hitelesítés ahhoz a felhasználóhoz. Bármelyik eldobhatja a csomagot anélkül, hogy megmondaná az ügyfélnek, melyik kapu záródott be.

A packet-tracer segítségével nézze meg, melyik kapu hibázik, mielőtt bármit módosít: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. A nyom megnevezi az ACL-t, a NAT szakaszt és a to-the-box döntést, ami általában elég ahhoz, hogy elválassza az útvonalproblémát a belépési problémától.

A szűk engedélyt írja meg, nem a széleset

Korlátozza az engedélyt a jóváhagyott adminisztratív alhálózatra és az alagút forgalmát fogadó interfészre: ssh 10.10.5.0 255.255.255.0 inside. Párosítsa egy hitelesítési módszerrel, például aaa authentication ssh console LOCAL-vel, és egy megnevezett helyi fiókkal, ahelyett hogy minden forrást megnyitna a külső interfészen.

Tartsa összhangban az interfész-ACL-t és az ssh-engedélyt. Egy olyan alhálózat engedélye, amelyet az ACL blokkol, továbbra is meghiúsul, és egy ACL, amely az alhálózatot megfelelő ssh-bejegyzés nélkül engedi, a következő kapunál hiúsul meg. Mindkét állítás ugyanazt az útvonalat írja le különböző rétegekből, ezért együtt tekintse át őket a futó konfigurációban.

A megnevezett hosztról ellenőrizze, majd szűkítse újra

Nyisson új munkamenetet a megnevezett kezelési hosztról, ne az asztaláról, és erősítse meg az ASA-n, hogy a kapcsolat melyik forráscímet és interfészt használta. Amíg a munkamenet nyitva van, ellenőrizze az aktív munkameneteket és a futó konfiguráció SSH szakaszát, majd zárja be, és távolítsa el a teszteléshez hozzáadott ideiglenes engedélyt. Ha a munkamenet megjelenik, de közvetlenül a bejelentkezés után leesik, a fennmaradó probléma az engedélyezés, nem az elérhetőség. Jegyezze fel az interfészt és a forrást a változásnaplóba, hogy a következő ember ne ismételje meg a diagnózist.

Tartsa elérhetően a konzolt vagy egy másik függetlenül jóváhagyott helyreállítási útvonalat a változtatás teljes ideje alatt. Miután a privát útvonal működik, erősítse meg, hogy a nyilvános források és a nem kapcsolódó VPN-felhasználók nem kapták meg ugyanazt a hozzáférést, mert a mindenki számára működő kezelési útvonal más probléma, mint amellyel elkezdte.