Široký selektor IPsec není oprávnění ke každé službě

Dvě strany se dohodnou, že budou chránit celou podsíť, a někdo toto ujednání čte jako povolení dosáhnout na každou službu v ní. To je mýtus: selektor říká, jaký provoz je tunel ochoten přenášet, a neříká nic o tom, které služby organizace povoluje. Dvojice zařízení může legitimně vyjednat široký rozsah adres, zatímco přístupová politika uvnitř povoluje dva porty, a obě tvrzení platí současně.

Chráněné pokrytí není oprávnění

Selektor provozu je součástí dohody o tunelu. Zužuje nebo potvrzuje, co mezi sebou strany zašifrují, a široký selektor bývá nejjednodušší věc na provoz, když obě strany přenášejí mnoho toků. Filtr služeb je jiná kontrola v jiném bodě cesty a rozhoduje o tom, co se po dešifrování paketu skutečně smí používat. Odebrání filtru, aby prošel jeden test, mění politické rozhodnutí v nehodu.

Vedete oba záznamy odděleně v návrhovém dokumentu, protože čtenář, který vidí jen selektor, odvodí oprávnění, které nikdy nebylo uděleno. Dva řádky v záznamu změn tomu zabrání a zaberou méně času než následná hádka.

Popište jeden tok z obou konců

Zapište iniciátora, respondéra, zdroj a cíl tak, jak jsou uvedeny, protokol a oba porty. Pak každý z těchto popisků obraťte pro druhý konec, protože dočasný zdrojový port klienta se stává cílovým portem odpovědi a vzdálená síť se stává místní. Konfigurace zkopírovaná z jedné strany na druhou bez tohoto obrácení je důvod, proč filtry nakonec povolují právě špatný směr. Napište tabulku jednou a postavte z ní oba filtry.

Dohodněte model výběru dřív, než cokoli zkopírujete, protože návrh založený na politice a návrh založený na trase vyjadřují stejný záměr různými objekty. Napište název modelu vedle toku, jinak další inženýr stráví odpoledne párováním objektů, které nikdy nebyly srovnatelné.

Najděte filtr, který skutečně platí

Na ASA je filtr VPN seznam ACL připojený ke skupinové politice a uplatňovaný na provoz po dešifrování a před šifrováním. Dokumentace Cisco ke skupinovým politikám popisuje i dědění, včetně hodnoty na úrovni uživatele, která nahrazuje hodnotu skupinové politiky. Takže ACL, který jste upravili, nemusí být ten, který řídí relaci před vámi. Totéž platí pro uživatelský objekt, který může skupinu přebít, aniž by po sobě nechal mnoho viditelných stop.

Zkontrolujte efektivní relaci, ne objekt, u kterého si pamatujete, že jste ho měnili, a poznamenejte si, který objekt politiky ji poskytuje. Ten jediný krok vyřeší překvapivě mnoho hlášení typu filtr je správný, ale nefunguje.

Směr, porty a opačný případ

Dokumentovaná konvence staví vzdálenou síť, nebo přidělené adresy vzdálených klientů, do pozice zdroje a místní síť do pozice cíle, přičemž odpovědi se vyjadřují prohozením pozic adres. Pravidla portů stojí nad touto konvencí a zaslouží si větší péči než adresy.

Dokumentovaný model může dovolit, aby pravidlo cílového portu ovlivnilo opačnou iniciaci, která používá stejný zdrojový port, což znamená, že filtr není jen jednosměrné pravidlo požadavku s neškodnými odpověďmi. Projděte výslovně oba směry iniciace a zahrňte i případ, který chcete zamítnout.

Stejná dokumentace omezuje filtr na počáteční spojení, takže to není univerzální prosazování každého sekundárního kanálu, který inspektovaná aplikace otevře. Kde úplná politika takové pokrytí potřebuje, patří na samostatnou hranici, ne do ACL natahovaného za jeho účel.

Otestujte tři případy, než to označíte za hotové

Přijměte zamýšlený tok, odmítněte službu, kterou politika zakazuje, a procvičte opačný směr, o kterém jste uvažovali. Spusťte je podle schváleného plánu se stejnými identitami a selektory, které nasadíte. Test, který ukáže jen funkční povolenou službu, dokazuje tunel, ne politiku.

Vedete vyjednané pokrytí a rozhodnutí o přístupu jako dva záznamy, protože vysvětlit, co VPN povoluje, vyžaduje oba.