Zakaj oddaljeni uporabnik ASA doseže podomrežje, ne pa aplikacije
Poti dokazujejo, da tunel deluje, ne pa da uporabnik sme odpreti aplikacijo. Preberite filter, ki ga je seja prejela, nato preizkusite dovoljeno in zavrnjeno povezavo.
Vaš uporabnik se poveže, dobi naslov, pinga strežnik v podomrežju aplikacije in vseeno ne more odpreti storitve na njem. Ta kombinacija je na ASA običajna, ker uspešen tunel in uporabno dovoljenje določajo različne nastavitve. Seznam razdeljenega tunela je izbral, kateri cilji vstopijo v tunel; filter VPN in lastna pravila dostopa cilja določajo, kaj lahko doseže dešifrirana zahteva. Pojdite skozi tri odločitve po vrsti, namesto da razširjate seznam poti, dokler se kaj ne spremeni.
Tri odločitve, ki jih je lahko zamenjati
Sprejem odgovarja, ali uporabnik sploh sme vzpostaviti tunel: poverilnice, potrdilo in morebitni drugi dejavnik. Izbira poti odgovarja, katere cilje odjemalec pošlje v ta tunel. Avtorizacija odgovarja, ali lahko dešifrirana zahteva doseže storitev. Samo tretja ustvari napako, ki jo uporabnik prijavi.
Hiter način za razlikovanje je vprašanje, kaj bi sprememba pokvarila. Odstranitev poti s seznama razdeljenega tunela ustavi promet do tega podomrežja, ne da bi kar koli dovolila; dodajanje ACE v filter VPN dovoli cilj, ne da bi spremenilo, kaj odjemalec tunelira.
| 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 |
Preberite filter, ki ga je seja dejansko prejela
Začnite pri živi seji, ne pri konfiguraciji, za katero menite, da velja. show vpn-sessiondb detail anyconnect izpiše dodeljeno skupinsko politiko in ime filtra, pritrjenega na to sejo. Če je polje prazno, noben filter ničesar ne uveljavlja in blokada prihaja od drugod.
Nato preberite politiko, ki ima vrednost, vključno s privzetimi vrednostmi, ker je filter lahko podedovan, ne pa zapisan tam, kjer gledate:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Primerjajte ime filtra v seji z ACL, ki ste ga pravkar uredili. Podobno poimenovan ACL, ki ga uporabnik ni nikoli prejel, ne more spremeniti politike virov te seje, in to je najpogostejši razlog, da sprememba, ki je videti pravilna, nima učinka.
Prednost pojasni ostalo. Za nastavitev filtra ima zapis DAP prednost pred atributi uporabniškega imena, ti pa prednost pred skupinsko politiko. Ko seja pokaže filter, ki ga niste pričakovali, pred posegom v skupino poiščite politiko DAP, ki ustreza temu uporabniku.
Razdeljeni seznam in filter sta ločeni polji
Na ASA 9.x skupinska politika hrani split-tunnel-network-list in vpn-filter kot različni nastavitvi, in priročnik za skupinske politike 9.22 ju prav zato dokumentira ločeno. Seznam omrežij je namig za usmerjanje odjemalcu; filter je seznam za nadzor dostopa, ki se uporablja za dešifriran promet.
Ta razlika je pomembna, ko uporabnik potrebuje eno storitev HTTPS v podomrežju. Vstavite podomrežje v razdeljeni seznam, da paketi vstopijo v tunel, nato v filtru dovolite samo to storitev. Razširjanje seznama poti ničesar ne avtorizira, krčenje pa ni mehanizem uveljavljanja.
Preverite, ali je ACL vmesnika sploh na poti
Dešifriran promet oddaljenega dostopa ne prečka vedno ACL zunanjega vmesnika tako, kot ljudje predvidevajo. Kjer je sysopt connection permit-vpn omogočen, ASA uporabi svoj dokumentirani obhod VPN za ta promet, medtem ko veljavni filtri VPN veljajo še naprej. Nastavitev preverite s show run all sysopt, namesto da sklepate iz diagrama topologije.
V vsakem primeru ostaneta na poti požarni zid ciljnega gostitelja in avtorizacija aplikacije. Pravilo ASA, ki dovoli TCP 443, ne povzroči, da bi aplikacija sprejela uporabnika.
Sprejmite spremembo tudi z zavrnjeno povezavo
Samo dovoljen preizkus dokaže zelo malo, ker delujoč tunel ustvari isti prvi paket ne glede na to, ali filter obstaja. Odprite predvideno storitev z odjemalca, nato poskusite cilj, ki mora ostati zaprt, in potrdite, da ne uspe iz pravega razloga.
Ob zaprtju zahtevka zapišite štiri dejstva: sprejeto identiteto, politiko in filter, ki jih je seja dejansko prejela, cilje v razdeljenem seznamu in vir, do katerega je uporabnik smel priti. Ti štirje pojasnijo, kje je promet nadzorovan, ne da bi seznam poti spremenili v požarni zid.
Če storitev še vedno zavrača, potem ko jo filter dovoli, pojdite na gostitelja: naslov poslušanja, požarni zid gostitelja in lastno preslikavo uporabnikov aplikacije. Tunel je takrat opravil svoje delo, nadaljnje spremembe na ASA pa dodajo le tveganje.