Miksi ASA-etäkäyttäjä saavuttaa aliverkon mutta ei sovellusta
Reitit todistavat, että tunneli toimii, eivät sitä, että käyttäjä saa avata sovelluksen. Lue istunnon saama suodatin ja testaa sitten sallittu ja hylätty yhteys.
Käyttäjäsi muodostaa yhteyden, saa osoitteen, pingaa sovelluksen aliverkossa olevaa palvelinta eikä silti pysty avaamaan sen palvelua. Tämä yhdistelmä on ASA:lla normaali, koska onnistuneen tunnelin ja käyttökelpoisen käyttöoikeuden ratkaisevat eri asetukset. Jaetun tunnelin lista valitsi, mitkä kohteet tulivat tunneliin; VPN-suodatin ja kohteen omat käyttösäännöt ratkaisevat, mihin purettu pyyntö saa päästä. Käy kolme päätöstä järjestyksessä läpi sen sijaan, että laajentaisit reittilistaa, kunnes jokin muuttuu.
Kolme päätöstä, jotka sekoittuvat helposti
Pääsy vastaa siihen, saako käyttäjä ylipäätään muodostaa tunnelin: tunnistetiedot, varmenne ja mahdollinen toinen tekijä. Reitin valinta vastaa siihen, mitkä kohteet asiakas lähettää tunneliin. Valtuutus vastaa siihen, saako purettu pyyntö saavuttaa palvelun. Vain kolmas tuottaa virheen, josta käyttäjä ilmoittaa.
Nopea tapa erottaa ne on kysyä, mitä muutos rikkoisi. Reitin poistaminen jaetusta listasta pysäyttää liikenteen kyseiseen aliverkkoon antamatta mitään; ACE:n lisääminen VPN-suodattimeen antaa kohteen muuttamatta sitä, mitä asiakas tunneloi.
| 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 |
Lue suodatin, jonka istunto todella sai
Aloita elävästä istunnosta, älä siitä kokoonpanosta, jonka luulet olevan voimassa. show vpn-sessiondb detail anyconnect tulostaa määritetyn ryhmäkäytännön ja kyseiseen istuntoon liitetyn suodattimen nimen. Jos kenttä on tyhjä, mikään suodatin ei valvo mitään ja esto tulee muualta.
Lue sitten käytäntö, jolle arvo kuuluu, mukaan lukien oletusarvot, koska suodatin voi periytyä sen sijaan, että se olisi kirjoitettu sinne, mihin katsot:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Vertaa istunnon suodattimen nimeä ACL:ään, jonka juuri muokkasit. Samanniminen ACL, jota käyttäjä ei koskaan saanut, ei voi muuttaa kyseisen istunnon resurssikäytäntöä, ja tämä on yleisin syy siihen, ettei oikealta näyttävä muutos vaikuta mitään.
Prioriteetti selittää loput. Suodatinasetuksessa DAP-tietue ohittaa käyttäjänimen attribuutit, ja käyttäjänimen attribuutit ohittavat ryhmäkäytännön. Kun istunto näyttää suodattimen, jota et odottanut, etsi kyseistä käyttäjää vastaava DAP-käytäntö ennen kuin kosket ryhmään.
Jaettu lista ja suodatin ovat erillisiä kenttiä
ASA 9.x:ssä ryhmäkäytäntö pitää sisällään split-tunnel-network-list ja vpn-filter erillisinä asetuksina, ja 9.22:n ryhmäkäytäntöopas dokumentoi ne erikseen juuri tästä syystä. Verkkolista on reititysvihje asiakkaalle; suodatin on pääsynvalvontaluettelo, jota sovelletaan purettuun liikenteeseen.
Tämä ero on merkityksellinen, kun käyttäjä tarvitsee yhden HTTPS-palvelun aliverkossa. Aseta aliverkko jaettuun listaan, jotta paketit tulevat tunneliin, ja salli sitten suodattimessa vain kyseinen palvelu. Reittilistan laajentaminen ei valtuuta mitään, eikä sen pienentäminen ole valvontamekanismi.
Tarkista, onko liitännän ACL ylipäätään polulla
Purettu etäkäyttöliikenne ei aina kulje ulkoliitännän ACL:n läpi niin kuin ihmiset olettavat. Kun sysopt connection permit-vpn on käytössä, ASA soveltaa dokumentoitua VPN-ohitustaan kyseiseen liikenteeseen, kun taas sovellettavat VPN-suodattimet ovat edelleen voimassa sen jälkeen. Tarkista asetus komennolla show run all sysopt sen sijaan, että päättelet topologiakaaviosta.
Kummassakin tapauksessa kohdeisännän oma palomuuri ja sovelluksen valtuutus pysyvät polulla. ASA-sääntö, joka sallii TCP 443:n, ei saa sovellusta hyväksymään käyttäjää.
Hyväksy muutos myös hylätyllä yhteydellä
Pelkkä sallittu testi todistaa hyvin vähän, koska toimiva tunneli tuottaa saman ensimmäisen paketin riippumatta siitä, onko suodatinta. Avaa aiottu palvelu asiakkaalta ja yritä sitten kohdetta, jonka pitäisi pysyä suljettuna, ja varmista, että se epäonnistuu oikeasta syystä.
Kirjaa neljä tosiseikkaa sulkiessasi tiketin: hyväksytty identiteetti, käytäntö ja suodatin, jotka istunto todella sai, jaetun listan kohteet ja resurssi, johon käyttäjällä oli lupa päästä. Nämä neljä selittävät, missä liikennettä valvotaan, muuttamatta reittilistaa palomuuriksi.
Jos palvelu yhä hylkii sen jälkeen, kun suodatin sallii sen, siirry isäntään: kuunteluosoite, isännän palomuuri ja sovelluksen oma käyttäjäkartoitus. Tunneli teki tuolloin tehtävänsä, ja lisämuutokset ASA:lla lisäävät vain riskiä.