Örökli a VPN-alhálózat az ASA-interfész biztonsági szintjét?

Valaki azt kérdezi, hogy a fióktelep VPN-alhálózata „0 vagy 100 biztonsági szinttel” rendelkezik-e az ASA-n, és a kérdés már tartalmazza a hibát. A biztonsági szint egy helyi interfész tulajdonsága, amelyet az interfész konfigurációjában 0-tól 100-ig rendelnek hozzá. A tunnelen érkező távoli alhálózat nem szerez ilyet, akárhogyan is írják a crypto mapot. Ezért a kérdésnek nincs számszerű válasza.

A gyakorlati következő kérdés jobb: melyik házirend engedi a fióktelepet a kiszolgálóhoz, és melyik tartja távol magától a tűzfaltól. Ez két válasz, és az alábbi eljárás szétválasztja őket.

A biztonsági szintek az interfészekhez tartoznak

Futtassa a show running-config interface parancsot, és látni fogja a security-level minden fizikai vagy VLAN-interfész alatt, nem a tunnelcsoport vagy a crypto map alatt. A magasabbtól az alacsonyabb felé irányuló alapértelmezett engedélyezést ezen interfészek között értékelik, ezért a szám megváltoztatja az ellenőrzés és az implicit ACL viselkedését azon az útvonalon, amelyhez tartozik.

Egy visszafejtett VPN-folyamatnál a belépés továbbra is az outside interfész, ahol a tunnel végződik, a kilépés pedig a kiszolgáló felé vezető inside interfész. Írja fel mindkettőt, mielőtt bármihez hozzányúlna. Ez az egyetlen lépés megszünteti a zavar nagy részét, mert egy elvont bizalmi kérdést interfészpárrá alakít.

Az ACL megkerülésének nevesített határa van

sysopt connection permit-vpn az a beállítás, amelyre az emberek félig emlékeznek, amikor azt mondják, hogy a VPN-forgalom figyelmen kívül hagyja az ACL-eket. Valóban átugorja az interfész ACL-jét a VPN-forgalomnak minősülő forgalom esetében, és a 9.x paraméterútmutató interfész és irány szerint korlátozza, ahelyett hogy globális kivételt hirdetne.

Ellenőrizze, mi van konfigurálva, mielőtt emlékezetből érvelne:

• show running-config all sysopt a tényleges érték megtekintéséhez, nem csak a nem alapértelmezett sorokhoz.
• show running-config access-group annak megtekintéséhez, melyik ACL melyik interfészre és irányra van alkalmazva.
• show vpn-sessiondb detail l2l annak megerősítéséhez, melyik tunnelcsoportot és szűrőt használja a munkamenet valójában.

Ennek a beállításnak a kikapcsolása a VPN-hozzáférés szigorítása érdekében nagy hatókörű változás. Újra aláveti az összes megfelelő VPN-folyamatot a külső ACL-nek, ami általában olyan módon töri el a működő tunneleket, amelynek semmi köze ahhoz a fióktelephez, amelyről kérdeztek.

Olvassa el a munkamenethez csatolt szűrőt

Az igazi tunnelenkénti vezérlés a VPN-szűrő: egy ACL, amelyre csoportházirend vagy felhasználónév hivatkozik, és amelyet a visszafejtés után és a titkosítás előtt alkalmaznak. A felhasználói szintű szűrő felülírja a csoportszintű értéket, így ugyanazon tunnelcsoport két tagjának eltérő tényleges hozzáférése lehet.

Erősítse meg az elsőbbséget, ahelyett hogy feltételezné. show running-config group-policy <name> a csoport értékét mutatja, a show running-config username <name> pedig azt, hogy létezik-e felhasználónkénti érték. Ha mindkettő létezik, a felhasználói érték nyer. Ezután hasonlítsa össze az ACL bejegyzéseit azzal a folyamattal, amely érdekli, abban az irányban, amelyben a szűrő értékel.

Az alkalmazáskiszolgálót engedélyező szűrő semmit nem mond a felügyeletről. Ezek külön szabályok külön útvonalon.

Ellenőrizzen egy engedélyt és egy tiltást

A Packet-tracer a leggyorsabb módja a döntés megtekintésének anélkül, hogy megvárná, amíg egy felhasználó jelenti. Adja meg neki a visszafejtett oldali folyamatot, és hagyja, hogy megnevezze az ACL-, NAT- és ellenőrzési szakaszokat, amelyeken áthalad.

1. packet-tracer input outside tcp 10.20.30.10 49152 10.0.5.20 443 detailed
2. Olvassa el az eredménysort: megnevezi azt az ACL-t, amely engedélyezte vagy eldobta a csomagot.
3. Ismételje meg az adminisztratív céllal az inside interfészen, és erősítse meg a tiltást.
4. Ismételje meg még egyszer minden változtatás után, hogy az előtte és az utána állapot is rögzítve legyen.

Ezután ellenőrizze valódi forgalommal: egy sikeres alkalmazáskérést a fióktelepről és egy sikertelen SSH-kísérletet az ASA felé. A Packet-tracer modellezi az útvonalat; egy élő folyamat bizonyítja, hogy a modell egyezett.

Vonja vissza a változtatást, amely működésre késztette

Ha a javítás az ACL-megkerülés kikapcsolása vagy egy szűrő kiszélesítése volt, tartsa meg az előző konfigurációt. Az érintett objektumok változtatás előtt mentett show run felvétele elegendő visszaállításukhoz; az ASA konfigurációja sororientált, így a visszaállítás a régi sorok újbóli bevitele, nem egy fájl visszaállítása.

Rögzítse az interfészpárt, a tényleges szűrőt, a packet-tracerből származó ACL-nevet és az Ön által módosított pontos parancsokat. Ez a feljegyzés a következő felülvizsgálatot ötperces ellenőrzéssé teszi a bizalmi szintekről folytatott újabb vita helyett.