ASA packet-tracer ашиглан VPN урсгалыг хэрхэн загварчлах вэ

ASA дээрх packet-tracer нарийн асуултад хариулдаг: энэ пакет энд энэ tuple-тэй орж ирэхэд зөвшөөрөгдөх болов уу, хаашаа явах вэ. Алс хязгаар ямар нэгэн зүйл хүлээн авч байгаа эсэхэд хариулдаггүй. Ердийн алдаа нь туннелий дотор явж буй аппликейшныг шалгахыг хүсэхдээ гадаад IKE tuple өгөх явдал юм. Эхлээд tuple-ийг засаж, фазуудыг уншаад, дараа нь симулятор харж чадахгүй бүх зүйлд бодит нотолгоо цуглуул.

Доорх тойм нь ACL, NAT дүрэм болон tunnel-group контекст таны өмнө байгааг урьдчилан таамагладаг. Тэдгээргүйгээр гаралт нь шалгаж чадахгүй бодлогыг дүрсэлдэг.

Алхам 1: дотоод урсгалыг энгийн үгээр бичээрэй

Ямар нэгэн зүйл бичихээс өмнө аппликейшныг тодорхойл. Дотоод хост алс гарцын цаана байгаа сервер рүү SSH нээх нь тодорхой эх порттой нэг дотоод TCP урсгал юм. ACL болон VPN шүүлтүүр үнэлдэг урсгал нь тэр, тиймээс таны бичих урсгал нь мөн тэр.

Үүнийг нэг өгүүлбэрээр бичээд, дараа нь талбар талбараар орчуул:

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

Алхам 2: оролтын интерфэйс болон чиглэлийг сонго

Оролт нь пакет ирж буй интерфэйс, түүнээс гарч буй интерфэйс биш. Холболт эхлүүлж буй LAN хостод энэ нь inside интерфэйс. Ижил сессийн буцах пакетод энэ нь outside интерфэйс бөгөөд tuple эргэдэг. Очих газрыг эх сурвалж болгон бичих нь итгэл төрүүлэх боловч хамааралгүй ALLOW авах хоёр дахь хамгийн түгээмэл арга юм.

Портууд ч бас чиглэлтэй. Эхлүүлсэн хүсэлтэд үйлчилгээний порт очих газрын талбарт, харин клиентийн түр порт эх сурвалжийн талбарт байна. TCP очих газар 500-тай загвар нь 500 дээр сонсож буй TCP аппликейшныг дүрсэлдэг; тушаалд тоо гарсан гэж IKE тест болохгүй.

Алхам 3: фазуудыг дарааллаар нь унш

Гаралтын фаз бүр эзэнтэй шийдвэр юм: маршрут хайлт, ACL, NAT, дараа нь VPN эсвэл туннелийн сонголт. Тэдгээрийг хэвлэсэн дарааллаар уншаад загвартай нийцэхгүй эхний фаз дээр зогс.

NAT хүмүүсийг төөрөгдүүлдэг. Хэрэв орчуулсан эх сурвалж туннелийн трафикийг сонгодог crypto ACL-ээс гадагш гарвал урсгалыг зөвшөөрөх боловч хэзээ ч инкапсул хийхгүй байж болно. Мөр нь орчуулсан хаягийг хэвлэдэг тул түүнийг анхны хаягтай биш, туннелийн сонирхолтой трафиктой харьцуул.

Алхам 4: ямар тойролт сонгосноо шалга

detailed хэлбэр нь шалгалтыг алгасах сонголтуудыг авдаг бөгөөд Cisco нь ACL, VPN шүүлтүүр, uRPF болон IPsec хуурамчлалын шалгалтыг хамарсан bypass-checks сонголтыг баримтжуулдаг. Тэдгээрийг тойрч авсан ALLOW нь маршрут болон NAT ажиллана гэж хэлнэ, бодлого бодит пакетыг хүлээн авна гэсэн үг биш. Сонголтуудыг үр дүнгийн хажууд бич.

Хэрэв бодлогын хариулт хэрэгтэй бол тойролтгүйгээр ажиллуул. Маршрутжуулалтын асуултыг тусгаарлаж байгаа бол тэдгээртэй ажиллуулж, үр дүнг маршрутжуулалтын хариулт гэж тэмдэглэ.

Алхам 5: зөрүүг бодит солилцоогоор хаа

Симуляцлагдсан зөвшөөрөл ASA дээр зогсдог. Алс гарц пакетыг тайлсан эсэх, сервер холболтыг хүлээн авсан эсэх, хариу буцаж ирсэн эсэх нь тусдаа ажиглалтууд юм. Төгсгөлийн цэгийн тоолууруудыг ашиглах эсвэл зөвшөөрсөн замаар нарийн бичлэг.

Зарим trace болон replay сонголт пакет илгээдэг эсвэл төлөвийг хадгалдаг. Хувилбар бүрийг зөвхөн унших хайлт гэж үзэхийн оронд өөрийн хувилбар болон зөвшөөрсөн оношилгооны процедурын баримтжуулсан зан төлөвийг дага.

Мөр нь одоо ч хэлж чадахгүй зүйл

Нэг тэмдэглэлд дөрвөн зүйлийг хадгал: tuple, тохирсон NAT дүрэм, урсгалыг зөөх ёстой туннель эсвэл бодлого, чиглэлд тусгай ажиглалт. Тэдгээргүйгээр дараагийн инженер локал бодлогын шийдвэрийг тогтсон удирдлагын хавтгай болон ажиллаж буй үйлчилгээнээс ялгаж чадахгүй. Эхний бүтэлгүйтлийн дараах амжилт нь туннель дунд нь босох ёстой байсан гэдгийн нотолгоо биш; фазыг болон төлөвийн өөрчлөлтийг бич.

Дотоод tuple-ээс эхэлж, загварт зөрчилдөх эхний фаз дээр зогсоод, дараа нь л төгсгөлийн цэгийн нотолгоо руу ханда. Мөр нь бодлогын оракул, хүргэлтийн баримт биш.