Kial fora uzanto de ASA atingas la subreton sed ne la aplikaĵon
Itineroj pruvas, ke la tunelo funkcias, ne ke la uzanto rajtas malfermi la aplikaĵon. Legu la filtrilon, kiun la seanco ricevis, poste testu permesitan kaj malpermesitan konekton.
Via uzanto konektiĝas, ricevas adreson, pingservas servilon en la subreto de la aplikaĵo, kaj tamen ne povas malfermi la servon sur ĝi. Tiu kombinaĵo estas normala sur ASA, ĉar sukcesa tunelo kaj uzebla permeso estas deciditaj de malsamaj agordoj. La listo de duonigita tunelo elektis, kiuj celoj eniris la tunelon; VPN-filtrilo kaj la propraj aliraj reguloj de la celo decidas, kion la malĉifrita peto rajtas atingi. Trairu la tri decidojn laŭ ordo anstataŭ larĝigi la itinerliston ĝis io ŝanĝiĝos.
Tri decidoj facile konfuzeblaj
La akcepto respondas, ĉu la uzanto entute rajtas starigi la tunelon: legitimiloj, atestilo kaj ajna dua faktoro. La itinerelekto respondas, kiujn celojn la kliento sendas en tiun tunelon. La rajtigo respondas, ĉu la malĉifrita peto rajtas atingi la servon. Nur la tria produktas la eraron, kiun la uzanto raportas.
Rapida maniero distingi ilin estas demandi, kion rompus ŝanĝo. Forigi itineron el la duonigita listo haltigas trafikon al tiu subreto sen doni ion; aldoni ACE al la VPN-filtrilo donas celon sen ŝanĝi, kion la kliento tuneligas.
| 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 |
Legu la filtrilon, kiun la seanco efektive ricevis
Komencu de la viva seanco anstataŭ de la agordo, kiun vi pensas validi. show vpn-sessiondb detail anyconnect presas la asignitan grupan politikon kaj la nomon de la filtrilo ligita al tiu seanco. Se la kampo estas malplena, neniu filtrilo devigas ion kaj la blokado venas de aliloke.
Poste legu la politikon, kiu posedas la valoron, inkluzive de la defaŭltoj, ĉar filtrilo povas esti heredita anstataŭ skribita tie, kie vi rigardas:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Komparu la filtrilan nomon sur la seanco kun la ACL, kiun vi ĵus redaktis. Simile nomita ACL, kiun la uzanto neniam ricevis, ne povas ŝanĝi la resurspolitikon de tiu seanco, kaj tio estas la plej ofta kialo, kial ŝanĝo, kiu aspektas ĝusta, havas neniun efikon.
La prioritato klarigas la reston. Por la filtrila agordo, DAP-riktipo havas prioritaton super la atributoj de uzantnomo, kaj tiuj super la grupa politiko. Kiam seanco montras filtrilon, kiun vi ne atendis, serĉu DAP-politikon kongruan al tiu uzanto antaŭ ol tuŝi la grupon.
La duonigita listo kaj la filtrilo estas apartaj kampoj
Sur ASA 9.x la grupa politiko tenas split-tunnel-network-list kaj vpn-filter kiel malsamajn agordojn, kaj la gvidilo pri grupaj politikoj 9.22 dokumentas ilin aparte ĝuste pro tio. La retlisto estas itinera indiko al la kliento; la filtrilo estas alirkontrola listo aplikata al malĉifrita trafiko.
Tiu distingo gravas, kiam uzanto bezonas unu HTTPS-servon en subreto. Metu la subreton en la duonigitan liston por ke la pakoj eniru la tunelon, poste permesu nur tiun servon en la filtrilo. Larĝigi la itinerliston rajtigas nenion, kaj mallarĝigi ĝin ne estas deviga mekanismo.
Kontrolu, ĉu interfaca ACL entute estas sur la vojo
Malĉifrita fora-alira trafiko ne ĉiam trapasas la eksteran interfacan ACL tiel, kiel homoj supozas. Kie sysopt connection permit-vpn estas ŝaltita, ASA aplikas sian dokumentitan VPN-preterpason por tiu trafiko, dum la aplikeblaj VPN-filtriloj plu validas poste. Kontrolu la agordon per show run all sysopt anstataŭ rezonadi el la topologia diagramo.
Ĉiel ajn, la propra fajroŝirmilo de la cela gastiganto kaj la rajtigo de la aplikaĵo restas sur la vojo. Regulo de ASA, kiu permesas TCP 443, ne igas la aplikaĵon akcepti la uzanton.
Akceptu la ŝanĝon ankaŭ per malpermesita konekto
Nur permesita testo pruvas tre malmulte, ĉar funkcianta tunelo produktas la saman unuan pakon ĉu filtrilo ekzistas ĉu ne. Malfermu la celitan servon de la kliento, poste provu celon, kiu devus resti fermita, kaj konfirmu, ke ĝi malsukcesas pro la ĝusta kialo.
Notu kvar faktojn, kiam vi fermas la bileton: la akceptitan identecon, la politikon kaj filtrilon, kiujn la seanco efektive ricevis, la celojn en la duonigita listo, kaj la resurson, kiun la uzanto rajtis atingi. Tiuj kvar klarigas, kie la trafiko estas kontrolata, sen transformi itinerliston en fajroŝirmilon.
Se la servo ankoraŭ rifuzas post kiam la filtrilo permesas ĝin, transiru al la gastiganto: aŭskulta adreso, gastiganta fajroŝirmilo kaj la propra uzanta mapado de la aplikaĵo. La tunelo faris sian taskon en tiu punkto, kaj pliaj ŝanĝoj en ASA nur aldonas riskon.