ASA DHCP relay site-to-site VPN orqali: bosqichma-bosqich qoʻllanma

Relay uch bosqichda ishlaydi va VPN ni faqat oʻrta bosqich kesib oʻtadi. Mijoz filial segmentida broadcast yuboradi, ASA uni DHCP serveriga unicast soʻrovga aylantiradi, server esa mijozga emas, relay manziliga javob beradi. Bosqichlarni shu tartibda oʻting, shunda «relay buzilgan» holatlarining koʻpchiligi yetishmayotgan siyosatga yoki notoʻgʻri oʻqilgan setroute satriga olib keladi.

Birinchi bosqich: relayni mijozga qaragan interfeysda yoqish

Filial ASA sida relay mijozlarga qaragan interfeysning xususiyatidir. Serverni uning yetib boriladigan interfeysi bilan global eʼlon qilish mumkin, yoki marshrutlash jadvali chiqishni tanlashi uchun shu mijozga qaragan interfeys ostida eʼlon qilish mumkin. Bu ikki shakl bir-birini almashtirmaydi, notoʻgʻrisini koʻchirish esa qoʻllanma birinchi marta yoʻldan chiqadigan joy.

Biror narsani oʻzgartirishdan oldin joriy konfiguratsiyani tekshiring: qaysi interfeysda relay yoqilgan, qaysi server shakli mavjud va setroute mijoz interfeysiga bogʻlanganmi. Agar ASA boshqa segment uchun ham DHCP serverini ishga tushirsa, toʻxtang va cheklovlar roʻyxatini oʻqing; server va relayni bir qurilmada birga yoqish mumkin emas.

Relay oʻzining mijozga qaragan manzilini gateway manzili maydoniga qoʻyadi. Server aynan shu manzilga javob beradi, shuning uchun u faqat lokal emas, tunnel orqali uzoq saytdan ham yetib boriladigan boʻlishi kerak.

Ikkinchi bosqich: ASA yaratgan trafikni tunnel orqali oʻtkazish

Bu odamlar tashlab ketadigan qadam. Siyosatga asoslangan site-to-site VPN odatda subnetlar orasidagi trafik uchun quriladi, relay soʻrovini esa ASA oʻzi yaratadi. Agar tunnelning access list va crypto xaritasi faqat filial hostidan server subnetiga ketuvchi oqimlarga mos kelsa, relay paketi tunnelga umuman kirmasligi mumkin. Access listni ikki yoʻnalishda ham tekshiring, faqat filialdan serverga ketuvchi satrni emas.

Qiziqarli trafik ASA relay manbasi va server manzilini qamrab olishini, qaytish yoʻnalishi ham ruxsat etilganini tasdiqlang. VTI ga asoslangan loyihada marshrutlash qarori soddaroq, ammo VTI ustida relay qoʻllab-quvvatlanishi muayyan versiyada keldi; ASA ning DHCP qoʻllanmasi 9.14(1) ni koʻrsatadi, shuning uchun VTI misolini eski qurilmaga koʻchirishdan oldin obrazni tekshiring.

ASA dan serverga ping oʻz-oʻzidan koʻp narsani isbotlamaydi. U boshqa yoʻl bilan, boshqa manba manzili bilan yoki relay paketlari mos kelmaydigan siyosat ostida muvaffaqiyatli boʻlishi mumkin.

Uchinchi bosqich: javobni va setroute parametrini oʻqish

RFC 2131 ga koʻra, u maydon nolga teng boʻlmaganda server javobini giaddr dagi manzilga yuboradi. Demak qaytish yoʻli relay manziliga marshrutlanishi kerak, tunnel siyosati esa serverdan relayga yoʻnalishga ruxsat berishi kerak. Soʻrov oʻtdi, ammo taklif hech qachon kelmasa, aynan shu yerga qarash kerak.

Keyin bir xil eshitiladigan ikki narsani ajrating. setroute kalit soʻzi ASA mijozga beradigan standart marshrutizator parametrini oʻzgartiradi yoki qoʻshadi. U ASA da marshrut oʻrnatmaydi va VPN siyosati yaratmaydi. Manzil olib, hech qayerga yeta olmaydigan mijozda koʻpincha tunnel emas, setroute yoki qamrov muammosi boʻladi. Buni statik gateway boʻlmagan mijoz bilan sinab koʻring va taklifda qaysi standart marshrutizator chiqishini kuzating.

Taklifni boshidan oxirigacha oʻqing: taklif qilingan manzil, mask, standart marshrutizator, DNS va ijara muddati. Soʻng ijara yangilanishiga ruxsat bering. Bir marta ishlab, yangilashda muvaffaqiyatsiz boʻladigan relay odatda birinchi almashinuv yashirgan qamrov, ijara yoki qaytish yoʻli muammosiga ega.

«Tuzatildi» deyishdan oldin nimalarni tekshiraman

Mijozdan boshlang va broadcastni ushlang, soʻng ASA uni oʻz manzili bilan giaddr sifatida uzatganini tasdiqlang. Uzoq tomonda server bu soʻrovni koʻrganini va filialga mos qamrovni tanlaganini tasdiqlang. Filialga qaytib, mijoz taklifni qabul qilganini va oʻz gatewayiga yetayotganini tasdiqlang.

Agar biron bosqich jim boʻlsa, yana bitta relay bayonotini qoʻshish oʻrniga tegishli siyosat yoki marshrutni tekshiring. Kimdir masalani koʻtarganda relay konfiguratsiyasi odatda allaqachon toʻgʻri boʻladi; oʻzgargan narsa tunnel siyosati yoki qaytish marshruti.

Uch bosqichni oʻzgarishlar jurnaliga yozing: mijozga qaragan interfeys, relay trafigini qamrab oluvchi VPN siyosati va serverning giaddr ga qaytish marshruti. Aynan shu yozuv keyingi filial qurilishini disk raskadrovka sessiyasi emas, takrorlanadigan ishga aylantiradi. U keyingi muhandisga qaysi buyruq chiqishini birinchi toʻplash kerakligini ham aytadi.