Proč vzdálený uživatel ASA dosáhne na podsíť, ale ne na aplikaci
Trasy dokazují, že tunel funguje, ne že uživatel smí aplikaci otevřít. Přečtěte si filtr, který relace obdržela, a poté otestujte povolené a zamítnuté připojení.
Váš uživatel se připojí, dostane adresu, pingne server v podsíti aplikace a přesto na něm nemůže otevřít službu. Taková kombinace je na ASA normální, protože úspěšný tunel a použitelné oprávnění se řídí různými nastaveními. Seznam rozděleného tunelu vybíral, které cíle vstoupí do tunelu; filtr VPN a vlastní přístupová pravidla cíle rozhodují, kam se dešifrovaný požadavek smí dostat. Projděte tři rozhodnutí popořadě, místo abyste rozšiřovali seznam tras, dokud se něco nezmění.
Tři rozhodnutí, která se snadno pletou
Přijetí odpovídá na to, zda uživatel vůbec smí tunel navázat: přihlašovací údaje, certifikát a případný druhý faktor. Volba trasy odpovídá na to, které cíle klient do tunelu posílá. Autorizace odpovídá na to, zda se dešifrovaný požadavek smí dostat ke službě. Jen třetí z nich vytváří chybu, kterou uživatel hlásí.
Rychlý způsob, jak je odlišit, je zeptat se, co by změna rozbila. Odebrání trasy ze seznamu rozděleného tunelu zastaví provoz do této podsítě, aniž by cokoli povolilo; přidání ACE do filtru VPN povolí cíl, aniž by změnilo, co 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 |
Přečtěte si filtr, který relace skutečně obdržela
Začněte od živé relace, ne od konfigurace, o které si myslíte, že platí. show vpn-sessiondb detail anyconnect vypíše přiřazenou skupinovou politiku a název filtru připojeného k této relaci. Pokud je pole prázdné, žádný filtr nic nevynucuje a blokování přichází odjinud.
Poté si přečtěte politiku, která hodnotu vlastní, včetně výchozích hodnot, protože filtr může být zděděný, a ne zapsaný tam, kam se díváte:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Porovnejte název filtru v relaci s ACL, který jste právě upravili. Podobně pojmenovaný ACL, který uživatel nikdy neobdržel, nemůže změnit politiku prostředků této relace, a to je nejčastější důvod, proč změna, která vypadá správně, nemá žádný účinek.
Priorita vysvětluje zbytek. Pro nastavení filtru má záznam DAP přednost před atributy uživatelského jména a atributy uživatelského jména mají přednost před skupinovou politikou. Když relace ukáže filtr, který jste nečekali, hledejte politiku DAP odpovídající tomuto uživateli, než se dotknete skupiny.
Seznam rozděleného tunelu a filtr jsou oddělená pole
Na ASA 9.x drží skupinová politika split-tunnel-network-list a vpn-filter jako různá nastavení a příručka skupinových politik 9.22 je z tohoto důvodu dokumentuje odděleně. Seznam sítí je směrovací nápověda pro klienta; filtr je seznam pro řízení přístupu uplatňovaný na dešifrovaný provoz.
Tento rozdíl je důležitý, když uživatel potřebuje jednu službu HTTPS v podsíti. Vložte podsíť do seznamu rozděleného tunelu, aby pakety vstoupily do tunelu, a poté ve filtru povolte jen tuto službu. Rozšiřování seznamu tras nic nepovoluje a jeho zmenšování není mechanismus vynucení.
Zkontrolujte, zda je ACL rozhraní vůbec na cestě
Dešifrovaný provoz vzdáleného přístupu neprochází vždy ACL vnějšího rozhraní tak, jak lidé předpokládají. Kde je sysopt connection permit-vpn zapnutý, uplatňuje ASA své dokumentované obejití VPN pro tento provoz, přičemž příslušné filtry VPN platí i poté. Nastavení zkontrolujte pomocí show run all sysopt místo úvah z diagramu topologie.
Ať tak či onak, vlastní firewall cílového hostitele a autorizace aplikace zůstávají na cestě. Pravidlo ASA, které povoluje TCP 443, nezpůsobí, že aplikace uživatele přijme.
Přijměte změnu i se zamítnutým připojením
Samotný povolený test dokazuje velmi málo, protože funkční tunel vytváří stejný první paket bez ohledu na to, zda filtr existuje. Otevřete zamýšlenou službu z klienta, poté zkuste cíl, který má zůstat zavřený, a ověřte, že selže ze správného důvodu.
Při zavírání tiketu zaznamenejte čtyři skutečnosti: přijatou identitu, politiku a filtr, které relace skutečně obdržela, cíle v seznamu rozděleného tunelu a prostředek, ke kterému uživatel směl dosáhnout. Tyto čtyři vysvětlují, kde je provoz řízen, aniž by se seznam tras změnil ve firewall.
Pokud služba stále odmítá i poté, co ji filtr povolí, přejděte k hostiteli: adresa pro naslouchání, firewall hostitele a vlastní mapování uživatelů aplikace. Tunel v tu chvíli udělal svou práci a další změny na ASA jen přidávají riziko.