ASA-ын DHCP релейг site-to-site VPN-ээр дамжуулах: алхам алхмаар гарын авлага

Релей гурван үе шаттай ажиллах ба зөвхөн дунд үе шат нь VPN-ийг гатална. Клиент салбарын сегмент дээр broadcast илгээж, ASA түүнийг DHCP сервер рүү чиглэсэн unicast хүсэлт болгон хувиргаж, сервер нь клиентэд биш, релейн хаяг руу хариулна. Үе шатуудыг энэ дарааллаар туулбал «релей эвдэрсэн» ихэнх тохиолдол дутуу бодлого эсвэл буруу уншсан setroute мөрөнд хүрч төгсдөг.

Эхний үе шат: клиент рүү харсан интерфейс дээр релейг идэвхжүүлэх

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

Ямар нэг зүйлийг өөрчлөхөөс өмнө ажиллаж буй тохиргоог шалгана уу: аль интерфейс дээр релей идэвхтэй, ямар серверийн хэлбэр байгаа, setroute клиентийн интерфейстэй холбогдсон эсэх. Хэрэв ASA өөр сегментийн DHCP серверийг ч ажиллуулдаг бол зогсоод хязгаарлалтын жагсаалтыг уншина уу; сервер ба релейг нэг төхөөрөмж дээр зэрэг идэвхжүүлэх боломжгүй.

Релей өөрийн клиент рүү харсан хаягийг гарцын хаягийн талбарт хийнэ. Сервер яг тэр хаяг руу хариулах тул тэр хаяг нь зөвхөн локал төдийгүй туннелээр дамжуулан алслагдсан сайтаас хүрэх боломжтой байх ёстой.

Хоёр дахь үе шат: ASA-ын үүсгэсэн урсгалыг туннелээр дамжуулах

Энэ бол хүмүүсийн алгасдаг алхам. Бодлогод суурилсан site-to-site VPN нь ихэвчлэн дэд сүлжээнүүдийн хоорондын урсгалд зориулагддаг бөгөөд релейн хүсэлтийг ASA өөрөө үүсгэдэг. Хэрэв туннелийн access list болон crypto map нь зөвхөн салбарын хостос серверийн дэд сүлжээ рүү чиглэсэн урсгалтай тохирч байвал релейн пакет туннелд огт орохгүй байж болно. Access list-ийг хоёр чиглэлд шалгана уу, зөвхөн салбараас сервер рүү чиглэсэн мөрийг биш.

Сонирхолтой урсгал нь ASA-ын релейн эх үүсвэр болон серверийн хаягийг хамарч, буцах чиглэл ч зөвшөөрөгдсөн эсэхийг баталгаажуулна уу. VTI-д суурилсан загварт маршрутын шийдвэр илүү энгийн боловч VTI дээрх релейн дэмжлэг тодорхой хувилбарт ирсэн; ASA-ын DHCP гарын авлага 9.14(1)-ийг заасан тул VTI-ийн жишээг хуучин төхөөрөмж рүү хуулахаас өмнө образыг шалгана уу.

ASA-аас сервер рүү ping нь өөрөө их зүйлийг батлахгүй. Энэ нь өөр замаар, өөр эх хаягтай, эсвэл релейн пакетууд тохирохгүй бодлогын дор амжилттай болж болно.

Гурав дахь үе шат: хариулт болон setroute сонголтыг унших

RFC 2131-д тэр талбар тэг биш үед сервер хариултаа giaddr дахь хаяг руу илгээдэг гэж заасан. Тиймээс буцах зам нь релейн хаяг руу маршрутлагдах ёстой бөгөөд туннелийн бодлого серверээс релей рүү чиглэлийг зөвшөөрөх ёстой. Хүсэлт гарсан ч санал хэзээ ч ирээгүй бол эндээс харах хэрэгтэй.

Дараа нь адил сонсогдох хоёр зүйлийг ялгана уу. setroute түлхүүр үг нь ASA клиентэд өгдөг анхдагч маршрутлагчийн сонголтыг өөрчлөх эсвэл нэмдэг. Энэ нь ASA дээр маршрут суулгахгүй, VPN бодлого үүсгэхгүй. Хаяг авсан ч хаана ч хүрч чадахгүй клиент ихэвчлэн туннелийн бус, setroute эсвэл хамрах хүрээний асуудалтай байдаг. Статик гарцгүй клиентээр туршиж, саналд ямар анхдагч маршрутлагч гарч ирэхийг ажиглаарай.

Саналыг эхнээс нь дуустал уншина уу: санал болгосон хаяг, маск, анхдагч маршрутлагч, DNS, түрээсийн хугацаа. Дараа нь түрээс шинэчлэгдэхийг зөвшөөрнө үү. Нэг удаа ажиллаад шинэчлэлтэд бүтэлгүйтдэг релей нь ихэвчлэн эхний солилцоо нуусан хамрах хүрээ, түрээс эсвэл буцах замын асуудалтай байдаг.

«Зассан» гэж хэлэхийн өмнө би юу шалгадаг вэ

Клиентээс эхэлж broadcast-ыг барьж аваад, дараа нь ASA үүнийг өөрийн хаягаар giaddr болгон дамжуулсныг баталгаажуулна уу. Алслагдсан талд сервер тэр хүсэлтийг харж, салбарт тохирох хамрах хүрээ сонгосныг баталгаажуулна уу. Салбарт буцаж ирээд клиент саналыг хүлээн авч, гарц руугаа хүрч байгааг баталгаажуулна уу.

Аль нэг үе шат чимээгүй байвал өөр релейн мэдэгдэл нэмэхийн оронд холбогдох бодлого эсвэл маршрутыг шалгана уу. Хэн нэгэн асуудлыг дээшлүүлэх үед релейн тохиргоо ихэвчлэн зөв байдаг; өөрчлөгдсөн нь туннелийн бодлого эсвэл буцах маршрут юм.

Гурван үе шатыг өөрчлөлтийн бүртгэлд бичнэ үү: клиент рүү харсан интерфейс, релейн урсгалыг хамарсан VPN бодлого, серверийн giaddr руу буцах маршрут. Яг тэр бүртгэл нь дараагийн салбарын бүтээн байгуулалтыг дибаг хийх сессил биш, давтагдах ажил болгодог. Энэ нь дараагийн инженерд аль командын гаралтыг эхлээд цуглуулахыг хэлдэг.