Kuri ASA taisyklė mato srautą po to, kai VPN jį iššifruoja

Pirmoji prielaida, kurios reikia atsisakyti, yra ta, kad kriptografijos ACL yra prieigos politika. Taip nėra. Cisco ASA sistemoje šis sąrašas atsako į vieną siaurą klausimą: kurie paketai nusipelno apsaugos, ir šis atsakymas nieko nesako apie tai, ar iššifruotas paketas gali pasiekti serverį už ugniasienės. Prieiga sprendžiama vėliau – sąsajos politika, grupės politikos filtru arba abiem, priklausomai nuo to, kaip buvo pastatytas tunelis.

Kriptografijos ACL atsako į kitą klausimą

Kriptografijos ACL yra atitikčių sąrašas. Jis nurodo tuneliui, ką šifruoti tarp dviejų šalių; paketas, kuris neatitinka sąrašo, tiesiog nėra apsaugotas. Jį išplėtus pasikeičia apsaugos apimtis ir nieko daugiau.

Todėl ten pridėjus potinklį tunelis gali pakilti, nors pati programa vis tiek neveikia. Tunelis pakilo, nes dabar yra atitiktis. Programa vis tiek neveikia, nes tame sąraše niekas nieko neleidžia. Du skirtingi klausimai, du skirtingi sąrašai.

Ką apėjimo nustatymas iš tikrųjų praleidžia

sysopt connection permit-vpn leidžia apsaugotam srautui praleisti sąsajos ACL patikrą, kuri kitaip būtų taikoma įeinamojoje pusėje. Tai patogumas VPN diegimams, ir jis yra globalus. Jis neliečia grupės politikos ir neliečia vartotojo autorizacijos filtro.

Skaitykite tikrąją reikšmę, o ne prielaidą: show running-config all sysopt išspausdina nustatymą net tada, kai jis niekada nebuvo aiškiai sukonfigūruotas, ir būtent čia prasideda daug painiavos.

Kadangi nustatymas globalus, jo tikrinimas kaip greito eksperimento viename nepavykusiame potinkyje yra blogas mainas. Visi kiti tos ugniasienės tuneliai dalijasi rezultatu. Palikite jį sąmoningam pakeitimui su atsitraukimo planu.

Skaitykite filtrą iššifravimo kryptimi

LAN-to-LAN vpn-filter rašomas tunelio, o ne sąsajos požiūriu. Nuotolinis tinklas patenka į šaltinio vietą, o vietinis tinklas į paskirties vietą, nes taip paketas atrodo po iššifravimo. Tada tas pats filtras dar kartą įvertinamas priešinga kryptimi prieš šifravimą, su apverstais adresų vaidmenimis.

Prievadų sąlygos nusipelno daugiau dėmesio nei nukopijuotas sąsajos ACL būtent dėl šios priežasties. Taisyklė, leidžianti vieną paskirties prievadą, gali turėti nepageidaujamą poveikį priešinga kryptimi, kur nauja jungtis naudoja tą prievadą kaip savo šaltinį. Prieš kurdami sąrašą, užrašykite, kuri pusė gali inicijuoti, kokia yra tikroji paslauga ir kuri priešinė pusė turi likti uždaryta.

Patvirtinkite, kuris filtras iš tikrųjų prijungtas: show running-config group-policy ir show vpn-sessiondb detail l2l kartu parodo, ką sesija paveldėjo. ACL, į kurį jokia politika nenurodo, redagavimas nieko nekeičia.

Nenaudokite vieno ACL objekto dviem darbams

Sąsajos access-group ir vpn-filter atrodo kaip to paties tipo objektas ir yra vertinami skirtinguose taškuose su skirtinga adresų orientacija. Vieno sąrašo priskyrimas abiem kviečia pakeitimą, kuris sutvarko tunelį ir tyliai atlaisvina fizinę sąsają.

Laikykite juos atskirai, pavadinkite pagal jų darbą ir leiskite krypties skirtumui būti matomam pavadinimuose.

Tikrinkite naujomis jungtimis, abiem kryptimis

Po suplanuoto pakeitimo atidarykite vieną naują jungtį, kuri turėtų būti leidžiama, ir vieną naują jungtį, kuri turėtų būti atmesta, tada užrašykite adresus, kryptį ir politikos atitikimą kartu su rezultatu. Nustatyta sesija nieko neįrodo apie naujų jungčių filtravimą, nes ji jau buvo įleista pagal senas taisykles.

Atsižvelkite ir į inspekciją. Gamintojo dokumentacija pažymi, kad VPN filtras tikrina pradinę jungtį, o ne kiekvieną antrinę jungtį, kurią atidaro inspekcijos variklis, todėl valdymo kanalas ir su juo susijęs medijos srautas gali būti traktuojami kitaip. Jei programa supranta protokolą, tikrinkite tikrąjį srautą, o ne vieną prievado zondą.

Tunelis, kuris po plataus apėjimo tampa naudojamas, sako, kad apribojimas buvo pašalintas, o ne kad jis buvo įvykdytas. Rezultatas, kurį verta išsaugoti, yra įvardytas vykdymo taškas, į kurį galite nurodyti kitos peržiūros metu.