Prečo vzdialený používateľ ASA dosiahne podsieť, ale nie aplikáciu
Trasy dokazujú, že tunel funguje, nie že používateľ smie aplikáciu otvoriť. Prečítajte si filter, ktorý relácia dostala, a potom otestujte povolené a zamietnuté pripojenie.
Váš používateľ sa pripojí, dostane adresu, pingne server v podsieti aplikácie a napriek tomu na ňom nemôže otvoriť službu. Takáto kombinácia je na ASA normálna, pretože úspešný tunel a použiteľné oprávnenie sa riadia rôznymi nastaveniami. Zoznam rozdeleného tunela vyberal, ktoré ciele vstúpia do tunela; filter VPN a vlastné prístupové pravidlá cieľa rozhodujú, kam sa dešifrovaná požiadavka smie dostať. Prejdite tri rozhodnutia po poradí, namiesto rozširovania zoznamu trás, kým sa niečo nezmení.
Tri rozhodnutia, ktoré sa ľahko zamieňajú
Prijatie odpovedá, či používateľ vôbec smie tunel nadviazať: prihlasovacie údaje, certifikát a akýkoľvek druhý faktor. Voľba trasy odpovedá, ktoré ciele klient do tunela posiela. Autorizácia odpovedá, či sa dešifrovaná požiadavka smie dostať k službe. Iba tretie z nich vytvára chybu, ktorú používateľ hlási.
Rýchly spôsob, ako ich odlíšiť, je spýtať sa, čo by zmena pokazila. Odobratie trasy zo zoznamu rozdeleného tunela zastaví prevádzku do tejto podsiete, bez toho aby čokoľvek povolilo; pridanie ACE do filtra VPN povolí cieľ, bez toho aby zmenilo, čo klient tuneluje.
| 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 |
Prečítajte si filter, ktorý relácia skutočne dostala
Začnite od živej relácie, nie od konfigurácie, o ktorej si myslíte, že platí. show vpn-sessiondb detail anyconnect vypíše priradenú skupinovú politiku a názov filtra pripojeného k tejto relácii. Ak je pole prázdne, žiadny filter nič nevynucuje a blokovanie prichádza odinakiaľ.
Potom si prečítajte politiku, ktorá hodnotu vlastní, vrátane predvolených hodnôt, pretože filter môže byť zdedený a nie zapísaný tam, kam sa pozeráte:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Porovnajte názov filtra v relácii s ACL, ktorý ste práve upravili. Podobne pomenovaný ACL, ktorý používateľ nikdy nedostal, nemôže zmeniť politiku prostriedkov tejto relácie, a to je najčastejší dôvod, prečo zmena, ktorá vyzerá správne, nemá žiadny účinok.
Priorita vysvetľuje zvyšok. Pre nastavenie filtra má záznam DAP prednosť pred atribútmi používateľského mena a atribúty používateľského mena majú prednosť pred skupinovou politikou. Keď relácia ukáže filter, ktorý ste nečakali, hľadajte politiku DAP zodpovedajúcu tomuto používateľovi, skôr než sa dotknete skupiny.
Zoznam rozdeleného tunela a filter sú oddelené polia
Na ASA 9.x drží skupinová politika split-tunnel-network-list a vpn-filter ako rôzne nastavenia a príručka skupinových politík 9.22 ich z tohto dôvodu dokumentuje oddelene. Zoznam sietí je smerovacia nápoveda pre klienta; filter je zoznam riadenia prístupu uplatňovaný na dešifrovanú prevádzku.
Tento rozdiel je dôležitý, keď používateľ potrebuje jednu službu HTTPS v podsieti. Vložte podsieť do zoznamu rozdeleného tunela, aby pakety vstúpili do tunela, a potom vo filtri povoľte iba túto službu. Rozširovanie zoznamu trás nič nepovoľuje a jeho zmenšovanie nie je mechanizmus vynucovania.
Skontrolujte, či je ACL rozhrania vôbec na ceste
Dešifrovaná prevádzka vzdialeného prístupu neprechádza vždy ACL vonkajšieho rozhrania tak, ako ľudia predpokladajú. Kde je sysopt connection permit-vpn zapnuté, ASA uplatňuje svoje dokumentované obídenie VPN pre túto prevádzku, pričom príslušné filtre VPN platia aj potom. Nastavenie skontrolujte pomocou show run all sysopt namiesto úvah z diagramu topológie.
Tak či onak, vlastný firewall cieľového hostiteľa a autorizácia aplikácie zostávajú na ceste. Pravidlo ASA, ktoré povoľuje TCP 443, nespôsobí, že aplikácia používateľa prijme.
Prijmite zmenu aj so zamietnutým pripojením
Samotný povolený test dokazuje veľmi málo, pretože funkčný tunel vytvára rovnaký prvý paket bez ohľadu na to, či filter existuje. Otvorte zamýšľanú službu z klienta, potom skúste cieľ, ktorý má zostať zatvorený, a overte, že zlyháva zo správneho dôvodu.
Pri zatváraní tiketu zaznamenajte štyri skutočnosti: prijatú identitu, politiku a filter, ktoré relácia skutočne dostala, ciele v zozname rozdeleného tunela a prostriedok, ku ktorému používateľ smel dosiahnuť. Tieto štyri vysvetľujú, kde je prevádzka riadená, bez toho aby sa zoznam trás zmenil na firewall.
Ak služba stále odmieta aj potom, čo ju filter povolí, prejdite k hostiteľovi: adresa na počúvanie, firewall hostiteľa a vlastné mapovanie používateľov aplikácie. Tunel v tej chvíli urobil svoju prácu a ďalšie zmeny na ASA len pridávajú riziko.