Miért éri el az ASA távoli felhasználója az alhálózatot, de az alkalmazást nem
Az útvonalak azt bizonyítják, hogy a tunnel működik, nem azt, hogy a felhasználó megnyithatja az alkalmazást. Olvassa el a munkamenet által kapott szűrőt, majd teszteljen egy engedélyezett és egy elutasított kapcsolatot.
A felhasználója csatlakozik, címet kap, pingel egy kiszolgálót az alkalmazás alhálózatán, és mégsem tudja megnyitni rajta a szolgáltatást. Ez a kombináció normális egy ASA-n, mert a sikeres tunnelt és a használható engedélyt különböző beállítások döntik el. A megosztott tunnel listája választotta ki, mely célok kerültek a tunnelbe; egy VPN-szűrő és a cél saját hozzáférési szabályai döntik el, mit érhet el a visszafejtett kérés. A három döntést sorrendben járja végig, ahelyett hogy az útvonallistát bővítené, amíg valami megváltozik.
Három könnyen összetéveszthető döntés
A belépés arra válaszol, egyáltalán létrehozhatja-e a felhasználó a tunnelt: hitelesítő adatok, tanúsítvány és bármilyen második tényező. Az útvonalválasztás arra válaszol, mely célokat küldi a kliens abba a tunnelbe. Az engedélyezés arra válaszol, elérheti-e a visszafejtett kérés a szolgáltatást. Csak a harmadik állítja elő azt a hibát, amelyet a felhasználó jelent.
Gyors módjuk a megkülönböztetésre megkérdezni, mit törne el egy változtatás. Egy útvonal eltávolítása a megosztott listából leállítja az adott alhálózat felé menő forgalmat anélkül, hogy bármit engedélyezne; egy ACE hozzáadása a VPN-szűrőhöz célpontot engedélyez anélkül, hogy megváltoztatná, mit tunnelel a kliens.
| Setting | What it decides | Symptom when it is wrong |
|---|---|---|
| Connection profile and authentication | Whether the tunnel is built | Login fails, no address assigned |
| Split-tunnel network list | Which destinations the client routes into the tunnel | Subnet unreachable from the client, everything else fine |
| VPN filter (ACL) | Which decrypted flows are permitted | Tunnel up, ping may work, TCP service refused or dropped |
Olvassa el a szűrőt, amelyet a munkamenet ténylegesen kapott
A tényleges munkamenettől induljon, ne attól a konfigurációtól, amelyről úgy gondolja, hogy érvényes. show vpn-sessiondb detail anyconnect kiírja a hozzárendelt csoportházirendet és a munkamenethez kapcsolt szűrő nevét. Ha a mező üres, semmilyen szűrő nem érvényesít semmit, és a blokkolás máshonnan jön.
Utána olvassa el azt a házirendet, amely a értéket birtokolja, az alapértékekkel együtt, mert egy szűrő öröklődhet, és nem ott van írva, ahol nézi:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Hasonlítsa össze a munkamenet szűrőnevét azzal az ACL-lel, amelyet épp most szerkesztett. Egy hasonló nevű ACL, amelyet a felhasználó soha nem kapott meg, nem változtathatja meg a munkamenet erőforrás-házirendjét, és ez a leggyakoribb oka annak, hogy egy helyesnek tűnő változtatás hatástalan.
A precedencia magyarázza a többit. A szűrőbeállításnál a DAP-rekord megelőzi a felhasználónév-attribútumokat, a felhasználónév-attribútumok pedig a csoportházirendet. Ha egy munkamenet nem várt szűrőt mutat, a csoport megérintése előtt keressen az adott felhasználóhoz illeszkedő DAP-házirendet.
A megosztott lista és a szűrő külön mezők
Az ASA 9.x-en a csoportházirend split-tunnel-network-list és vpn-filter külön beállításként tartja, és a 9.22-es csoportházirend-útmutató épp ezért külön dokumentálja őket. A hálózati lista útvonal-tipp a kliensnek; a szűrő a visszafejtett forgalomra alkalmazott hozzáférés-vezérlési lista.
Ez a különbség akkor számít, amikor a felhasználónak egyetlen HTTPS-szolgáltatás kell egy alhálózaton. Tegye az alhálózatot a megosztott listába, hogy a csomagok belépjenek a tunnelbe, majd a szűrőben csak azt a szolgáltatást engedélyezze. Az útvonallista bővítése semmit nem engedélyez, a szűkítése pedig nem érvényesítési mechanizmus.
Ellenőrizze, hogy egy interfész-ACL egyáltalán az útvonalon van-e
A visszafejtett távoli hozzáférési forgalom nem mindig a külső interfész ACL-jén halad át úgy, ahogy az emberek feltételezik. Ahol a sysopt connection permit-vpn engedélyezve van, az ASA alkalmazza a dokumentált VPN-megkerülését arra a forgalomra, miközben az alkalmazandó VPN-szűrők utána is érvényesek. Ellenőrizze a beállítást a show run all sysopt paranccsal, ahelyett hogy a topológiai ábrából következtetne.
Akárhogy is, a célgép saját tűzfala és az alkalmazás engedélyezése az útvonalon marad. Egy TCP 443-at engedélyező ASA-szabály nem éri el, hogy az alkalmazás elfogadja a felhasználót.
Fogadja el a változtatást elutasított kapcsolattal is
Egy engedélyezett teszt önmagában nagyon keveset bizonyít, mert egy működő tunnel ugyanazt az első csomagot állítja elő, akár van szűrő, akár nincs. Nyissa meg a szándékolt szolgáltatást a kliensről, majd próbáljon meg egy célt, amelynek zárva kell maradnia, és erősítse meg, hogy a megfelelő okból hiúsul meg.
Négy tényt rögzítsen a jegy lezárásakor: az elfogadott identitást, a munkamenet által ténylegesen kapott házirendet és szűrőt, a megosztott lista céljait és az erőforrást, amelyet a felhasználó elérhetett. Ez a négy megmagyarázza, hol szabályozzák a forgalmat, anélkül hogy az útvonallistát tűzfallá alakítanánk.
Ha a szolgáltatás a szűrő engedélyezése után is elutasít, lépjen a gazdagépre: figyelési cím, gazdagép tűzfala és az alkalmazás saját felhasználóleképezése. A tunnel ekkor tette a dolgát, és a további ASA-változtatások csak kockázatot adnak hozzá.