Mikä ASA-sääntö näkee liikenteen, kun VPN on purkanut sen salauksen

Ensimmäinen oletus, josta kannattaa luopua, on että krypto-ACL on käyttöoikeuskäytäntö. Se ei ole. Cisco ASA:ssa tuo lista vastaa yhteen kapeaan kysymykseen: mitkä paketit ansaitsevat suojauksen, eikä vastaus kerro mitään siitä, saako purettu paketti saavuttaa palomuurin takana olevan palvelimen. Pääsystä päätetään myöhemmin, liitännän käytännöllä, ryhmäkäytännön suodattimella tai molemmilla, riippuen siitä, miten tunneli rakennettiin.

Krypto-ACL vastaa toiseen kysymykseen

Krypto-ACL on vastaavuuslista. Se kertoo tunnelille, mitä kahden vastapuolen välillä salataan; paketti, joka ei vastaa sitä, ei yksinkertaisesti ole suojattu. Sen laajentaminen muuttaa suojauksen laajuutta eikä muuta mitään muuta.

Siksi aliverkon lisääminen sinne voi nostaa tunnelin pystyyn, vaikka varsinainen sovellus epäonnistuu edelleen. Tunneli on pystyssä, koska vastaavuus on nyt olemassa. Sovellus epäonnistuu edelleen, koska mikään tuossa listassa ei salli mitään. Kaksi eri kysymystä, kaksi eri listaa.

Mitä ohitussäätö todella ohittaa

sysopt connection permit-vpn sallii suojatun liikenteen ohittaa liitännän ACL-tarkistuksen, joka muuten soveltuisi saapuvalla puolella. Se on mukavuus VPN-käyttöönottoja varten, ja se on maailmanlaajuinen. Se ei koske ryhmäkäytäntöä eikä koske käyttäjäkohtaista valtuutussuodatinta.

Lue todellinen arvo oletuksen sijaan: show running-config all sysopt tulostaa asetuksen, vaikka sitä ei olisi koskaan määritetty nimenomaisesti, ja juuri siitä moni sekaannus alkaa.

Koska asetus on maailmanlaajuinen, sen testaaminen nopeana kokeena yhdessä rikkinäisessä aliverkossa on huono vaihtokauppa. Jokainen muu tuon palomuurin tunneli jakaa tuloksen. Säästä se harkittuun muutokseen, jolla on palautussuunnitelma.

Lue suodatin salauksenpurkusuunnassa

LAN-to-LAN-vpn-filter kirjoitetaan tunnelin näkökulmasta, ei liitännän. Etäverkko menee lähdeasemaan ja paikallinen verkko kohdeasemaan, koska sellaiselta paketti näyttää salauksen purkamisen jälkeen. Sama suodatin arvioidaan sitten uudelleen vastakkaisessa suunnassa ennen salausta, osoitteiden roolit vaihdettuina.

Porttiehdot ansaitsevat enemmän huolta kuin kopioitu liitännän ACL juuri tästä syystä. Yhden kohdeportin salliva sääntö voi vaikuttaa odottamattomasti vastakkaisessa suunnassa, jossa uusi yhteys käyttää tuota porttia lähteenään. Kirjoita muistiin, mikä puoli saa aloittaa, varsinainen palvelu ja vastapuoli, jonka on pysyttävä suljettuna, ennen kuin rakennat listan.

Varmista, mikä suodatin on todella liitetty: show running-config group-policy ja show vpn-sessiondb detail l2l yhdessä kertovat, mitä istunto peri. Sellaisen ACL:n muokkaaminen, johon mikään käytäntö ei viittaa, ei muuta mitään.

Älä käytä yhtä ACL-objektia kahteen työhön

Liitännän access-group ja vpn-filter näyttävät samalta objektityypiltä, ja ne arvioidaan eri kohdissa eri osoitesuunnalla. Yhden listan antaminen molemmille kutsuu muutoksen, joka korjaa tunnelin ja löysää hiljaa fyysistä liitäntää.

Pidä ne erillään, nimeä ne tehtävänsä mukaan ja anna suunnan eron näkyä nimissä.

Varmista uusilla yhteyksillä, molempiin suuntiin

Avaa suunnitellun muutoksen jälkeen yksi uusi yhteys, joka pitäisi sallia, ja yksi uusi yhteys, joka pitäisi hylätä, ja kirjaa sitten osoitteet, suunta ja käytäntövastaavuus tuloksen kanssa. Muodostettu istunto ei todista mitään uusien yhteyksien suodatuksesta, koska se hyväksyttiin jo vanhoilla säännöillä.

Ota tarkastus huomioon myös. Toimittajan dokumentaatio huomauttaa, että VPN-suodatin tarkistaa alkuyhteyden eikä jokaista toissijaista yhteyttä, jonka tarkastusmoottori avaa, joten ohjauskanava ja siihen liittyvä mediavirta voivat saada erilaisen kohtelun. Jos sovellus tuntee protokollan, testaa todellinen virta yhden porttikoetuksen sijaan.

Tunneli, joka tulee käyttökelpoiseksi laajan ohituksen jälkeen, kertoo, että rajoitus poistettiin, ei että se täytettiin. Tulos, joka kannattaa säilyttää, on nimetty valvontapiste, johon voit viitata seuraavassa tarkastuksessa.