Širok selektor IPsec ni dovoljenje za vsako storitev

Dva partnerja se dogovorita zaščititi celotno podomrežje in nekdo ta dogovor prebere kot dovoljenje za doseganje vsake storitve v njem. To je mit: selektor pove, kateri promet je tunel pripravljen prenašati, in ne pove ničesar o tem, katere storitve organizacija dovoljuje. Par naprav se lahko zakonito dogovori za širok razpon naslovov, medtem ko politika dostopa v njem dovoljuje dva vrata, in obe trditvi ostaneta resnični hkrati.

Zaščitena pokritost ni pooblastilo

Selektor prometa je del dogovora o tunelu. Zoži ali potrdi, kaj bosta partnerja šifrirala med seboj, in širok selektor je pogosto najpreprostejše upravljati, ko imata obe strani veliko tokov. Filter storitev je drug nadzor na drugi točki poti in odloča, kaj se po dešifriranju paketa dejansko sme uporabiti. Odstranitev filtra, da bi en test uspel, spremeni odločitev politike v nesrečo.

Oba zapisa hranite ločeno v načrtovalnem dokumentu, ker bo bralec, ki vidi samo selektor, sklepal na pooblastilo, ki ni bilo nikoli dano. Dve vrstici v zapisu spremembe to preprečita in vzameta manj časa kot razprava, ki sledi.

Opišite en tok z obeh koncev

Zapišite pobudnika, odzivnika, vir in cilj, kot so predstavljeni, protokol in oba vrata. Nato obrnite vsako od teh oznak za drugo končno točko, ker začasna izvorna vrata odjemalca postanejo ciljna vrata odgovora in oddaljeno omrežje postane lokalno. Konfiguracija, kopirana z ene strani na drugo brez tega obračanja, je razlog, da filtri na koncu dovoljujejo točno napačno smer. Zapišite tabelo enkrat in iz nje zgradite oba filtra.

Dogovorite se o modelu izbire, preden karkoli kopirate, saj načrt na podlagi politike in načrt na podlagi poti izražata isti namen skozi različne objekte. Zapišite ime modela ob toku, sicer bo naslednji inženir preživel popoldne z usklajevanjem objektov, ki nikoli niso bili primerljivi.

Poiščite filter, ki se dejansko uporablja

Na ASA je VPN filter ACL, pritrjen na skupinsko politiko in uporabljen na prometu po dešifriranju in pred šifriranjem. Cisco dokumentacija o skupinski politiki opisuje tudi dedovanje, vključno z vrednostjo na ravni uporabnika, ki nadomesti vrednost skupinske politike. ACL, ki ste jo urejali, torej morda ni tista ACL, ki upravlja sejo pred vami. Enako velja za uporabniški objekt, ki lahko preglasi skupino, ne da bi za seboj pustil veliko vidnih dokazov.

Preverite dejansko sejo, ne objekta, ki se spomnite, da ste ga spremenili, in zabeležite, kateri objekt politike jo zagotavlja. Ta en korak reši presenetljivo veliko poročil tipa „filter je pravilen, a ne deluje“.

Smer, vrata in obrnjeni primer

Dokumentirana konvencija postavi oddaljeno omrežje ali dodeljene naslove oddaljenega odjemalca v položaj vira in lokalno omrežje v položaj cilja, odgovori pa se izrazijo z zamenjavo položajev naslovov. Pravila vrat stojijo na tej konvenciji in si zaslužijo več skrbnosti kot naslovi.

Dokumentirani model lahko dovoli, da pravilo ciljnih vrat vpliva na obrnjeno vzpostavitev, ki uporablja ista izvorna vrata, kar pomeni, da filter ni zgolj enosmerno pravilo zahteve z neškodljivimi odgovori. Izrecno premislite obe smeri vzpostavitve in vključite primer, ki ga nameravate zavrniti.

Ista dokumentacija omejuje filter na začetne povezave, zato ni splošno uveljavljanje vsakega sekundarnega kanala, ki ga odpre pregledovana aplikacija. Kjer celotna politika potrebuje to pokritost, spada na ločeno mejo, ne v ACL, raztegnjen prek svojega namena.

Preizkusite tri primere, preden rečete, da je končano

Sprejmite predvideni tok, zavrnite storitev, ki jo politika prepoveduje, in preizkusite primer obrnjene smeri, o katerem ste razmišljali. Zaženite jih po odobrenem načrtu z istimi identitetami in selektorji, ki jih boste uvedli. Test, ki pokaže le, da dovoljena storitev deluje, dokazuje tunel, ne politike.

Dogovorjeno pokritost in odločitev o dostopu hranite kot dva zapisa, ker razlaga, kaj VPN dovoljuje, potrebuje oba.