Kiun regulon de ASA vidas la trafiko post kiam la VPN malĉifras ĝin

La unua supozo, kiun oni devas forlasi, estas ke la kripto-ACL estas alirpolitiko. Ĝi ne estas. Sur Cisco ASA tiu listo respondas al unu mallarĝa demando: kiuj pakaĵoj meritas protekton, kaj tiu respondo diras nenion pri tio, ĉu la malĉifrita pakaĵo rajtas atingi la servilon malantaŭ la fajroŝirmilo. Pri aliro oni decidas poste, per interfaca politiko, per grup-politika filtrilo aŭ per ambaŭ, laŭ tio, kiel la tunelo estis konstruita.

La kripto-ACL respondas al alia demando

Kripto-ACL estas kongrua listo. Ĝi diras al la tunelo, kion ĉifri inter du samtavoloj; pakaĵo, kiu ne kongruas kun ĝi, simple ne estas protektita. Larĝigi ĝin ŝanĝas la amplekson de protekto kaj nenion alian.

Tial aldoni subreton tie povas levi tunelon dum la efektiva aplikaĵo ankoraŭ malsukcesas. La tunelo estas supren, ĉar nun ekzistas kongruo. La aplikaĵo ankoraŭ malsukcesas, ĉar nenio en tiu listo permesas ion. Du malsamaj demandoj, responditaj de du malsamaj listoj.

Kion la preterira agordo vere preterlasas

sysopt connection permit-vpn permesas al protektita trafiko preterlasi la kontrolon de la interfaca ACL, kiu alie validus ĉe la envena flanko. Ĝi estas oportuneco por VPN-lokadoj, kaj ĝi estas tutmonda. Ĝi ne tuŝas la grupan politikon, kaj ĝi ne tuŝas filtrilon de rajtigo por unuopa uzanto.

Legu la faktan valoron anstataŭ la supozon: show running-config all sysopt presas la agordon eĉ kiam ĝi neniam estis eksplicite agordita, kaj ĝuste tie komenciĝas multa konfuzo.

Ĉar la agordo estas tutmonda, testi ĝin kiel rapidan eksperimenton sur unu paneinta subreto estas malbona interŝanĝo. Ĉiu alia tunelo sur tiu fajroŝirmilo kunhavas la rezulton. Konservu ĝin por intenca ŝanĝo kun restariga plano.

Legu la filtrilon en la malĉifra direkto

LAN-al-LAN vpn-filter estas skribata laŭ la vidpunkto de la tunelo, ne de la interfaco. La fora reto iras en la fontan pozicion kaj la loka reto en la celan pozicion, ĉar tia aspektas la pakaĵo post malĉifrado. La sama filtrilo tiam estas taksata denove en la kontraŭa direkto antaŭ ĉifrado, kun la adresaj roloj inversigitaj.

Pordaj kondiĉoj meritas pli da zorgo ol kopiita interfaca ACL ĝuste pro tiu kaŭzo. Regulo permesanta unu celan pordon povas havi neintencitan efikon en la inversa direkto, kie nova konekto uzas tiun pordon kiel sian fonton. Notu, kiu flanko rajtas iniciati, la efektivan servon kaj la kontraŭulon, kiu devas resti fermita, antaŭ ol vi konstruos la liston.

Konfirmu, kiu filtrilo estas fakte alligita: show running-config group-policy kaj show vpn-sessiondb detail l2l kune diras al vi, kion la seanco heredis. Redakti ACL, al kiu neniu politiko referencas, ŝanĝas nenion.

Ne reuzu unu ACL-objekton por du taskoj

Interfaca access-group kaj vpn-filter aspektas kiel la sama speco de objekto kaj estas taksataj en malsamaj punktoj kun malsamaj adresaj orientiĝoj. Asigni unu liston al ambaŭ invitas ŝanĝon, kiu riparias la tunelon kaj silente malstreĉas la fizikan interfacon.

Tenu ilin aparte, nomu ilin laŭ ilia tasko, kaj lasu la direkton-diferencon videbla en la nomoj.

Kontrolu per novaj konektoj, en ambaŭ direktoj

Post planita ŝanĝo, malfermu unu novan konekton, kiu devus esti permesita, kaj unu novan konekton, kiu devus esti rifuzita, poste notu la adresojn, la direkton kaj la politikan kongruon kune kun la rezulto. Starigita seanco pruvas nenion pri filtrado de novaj konektoj, ĉar ĝi jam estis akceptita laŭ la malnovaj reguloj.

Kalkulu ankaŭ la inspektadon. La dokumentaro de la vendisto notas, ke VPN-filtrilo kontrolas la komencan konekton, ne ĉiun duagradan konekton, kiun malfermas inspektada motoro, do stirkanalo kaj ĝia rilata aŭdovida fluo povas ricevi malsaman traktadon. Se la aplikaĵo konas la protokolon, testu la faktan fluon anstataŭ unu pordan sondilon.

Tunelo, kiu fariĝas uzebla post larĝa preteriro, diras al vi, ke la limigo estis forigita, ne ke ĝi estis plenumita. La rezulto inda je konservado estas nomita plenum-punkto, kiun vi povas montri dum la sekva revizio.