Хоёр дахь WAN VPN бичлэг ажиллахгүй байхад үндсэн нь ажилласаар байна
Хоёр дахь WAN VPN бичлэгт өөрийн сонсогч, тохирох гэрчилгээний таних тэмдэг болон буцах зам шаардлагатай, тэгж байж клиентийн failover үүнийг ашиглаж чадна.
Үндсэн туннель босоо хэвээр байна, хэрэглэгчид ажлаа үргэлжлүүлж, хоёр дахь ISP шугам юу ч өөрчилсөн сул зогсож байна. Та нөөц шугамд хаяг нийтэлж, түүн рүү нэр чиглүүлж, магадгүй клиентэд нөөц бичлэг нэмсэн, харин клиент түүнийг хэзээ ч туршиж үзэхгүй эсвэл баталгаажуулалт хийгээд дараа нь үхдэг. Миний ажигласан тохиолдлуудад failover функц ихэвчлэн хэвийн байсан; дутагдаж байсан нь бичлэгийг ашиглах боломжтой болгодог таван зүйлийн нэг байв. Нэр нөөц хаяг руу шийдэгдэж болох ч тухайн интерфейс дээр юу ч сонсогдохгүй, сонсогч холболт хүлээн авч болох ч хариу үндсэн замаар гардаг. WAN бүрийг өөрийн гэрээтэй тусдаа бичлэг гэж үзвэл эвдрэл клиентийн алдаа мэт харагдахаа болино.
WAN бүрт өөрийн бичлэгийн гэрээ хэрэгтэй
WAN бүрт таван талбар тэмдэглэнэ: нийтийн нэр ба хаяг, тээвэр ба порт, түүнийг дуусгах интерфейс эсвэл контекст, танилцуулах ёстой түншийн таних тэмдэг, хариу хаанаас гардаг вэ. Хоёр шугам гэдэг нь хоёр бүрэн багц. Хэрэв хоёр дахь багцад дуусгах интерфейс эсвэл буцах зам байхгүй бол танд нөөц бичлэг байхгүй; зорилгыг тодорхойлсон DNS бичлэг байна.
Төхөөрөмж болон түүний хувилбар ч энэ зохион байгуулалтыг дэмжих ёстой. DNS бичлэг өөр интерфейс дээр үйлчилгээ нээж чадахгүй, олон платформ дээр сонсогч төхөөрөмжөөр биш хаягаар тохируулагддаг. ASA дээр интерфейсэд суурилсан IPsec нь крипто зураглал, туннелийн бүлгүүдийг гадаад интерфейстэй холбодог тул хоёр дахь дээш холбоост эдгээр пакетууд үнэхээр ирдэг газарт бодлого хэрэгтэй. Маршрутад суурилсан шийдэл өөрөөр ажилладаг: сонсогч бүх хаяг эсвэл нэг нэрлэсэн хаягтай холбогдож болох бөгөөд энэ сонголт нь ISP B ер нь хариулж чадах эсэхийг шийддэг.
Хоёр дахь WAN үнэхээр хариулж байгаа эсэхийг шалгана
Хоёр шугамын гаднаас туршаад үзээрэй, гарцын ард байгаа машинаас биш, клиентийн профайл ашигладаг яг нэрийг туршаад үзээрэй. TLS сонсогчийн хувьд хурдан шалгалт нь openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts бөгөөд үүнийг таны сүлжээний гаднах хост дээрээс ажиллуулна. Профайл дахь нэртэй тохирох гинжилтэй дууссан гар барилт хэрэгтэй, зөвхөн холболт хүлээн авдаг TCP порт биш.
RFC 9525 нь клиент юуг шалгадгийг тайлбарлана: хүрэхийг зорьсон таних тэмдгийг үйлчилгээний танилцуулж буй гэрчилгээтэй харьцуулна. Үндсэн бичлэгийн гэрчилгээг буцаадаг эсвэл хоёр нэрийн алийг нь ч жагсаагаагүй анхдагч гэрчилгээ танилцуулдаг хоёр дахь бичлэг нь порт нээлттэй, галт хана зөвшөөрч байсан ч энэ шалгалтад унана.
Энд гарч буй ихэнх эвдрэлийг хоёр загвар тайлбарлана. Өлгөгдсөн холболт нь ихэвчлэн тухайн интерфейс дээр сонсогч байхгүй, зөвхөн үндсэн дэд сүлжээнд зөвшөөрөл өгдөг хандалтын дүрэм, эсвэл хоёр дахь шугамын өмнөх операторын төхөөрөмж портыг хаяж байгааг илтгэнэ. Буруу таних тэмдгээр төгсөх гар барилт нь ихэвчлэн өөр trustpoint, анхдагч виртуал хост, эсвэл таних тэмдгийг тохируулалгүй үндсэнээс хуулсан тохиргоог илтгэнэ.
Хариуг дагаарай, зөвхөн хүсэлтийг биш
Хоёр дахь WAN нь ихэвчлэн буцах замд эвдэрдэг. Хүсэлт ISP B-ээр ирж, төхөөрөмж хариулж, хариу нь ISP A дахь анхдагч маршрутаар клиентийн хэзээ ч хүсээгүй эх хаягтай гарна. Төлөвтэй хөрвүүлэлт үүнийг улам дордуулна: хэрэв зураглал үндсэн интерфейст зориулж бүтээгдсэн бол буцаж ирж буй пакет хөрвүүлэлтийг алгасах эсвэл клиентийн галт хана хаядаг эх сурвалжийг агуулна. Нийлүүлэгчид ч өөрсдийн өгсөн шугамд хамаарахгүй эх хаягуудыг хаядаг тул энэ нь цэвэр протоколын алдаа биш, нэг чиглэлийн хар нүх мэт харагддаг.
Хоёр дахь бичлэгээс гарах урсгалын маршрутжуулалтын шийдвэрийг шалгана. Хариу нь хүсэлт ирсэн интерфейсээр гарах ёстой, эсвэл ядаж алслагдсан тал тухайн замд хамаарах гэж хүлээн зөвшөөрөх хаяг агуулсан байх ёстой. Бодлогын маршрутжуулалтын платформ дээр энэ нь ирж буй интерфейс эсвэл хөрвүүлсэн эх сурвалжид холбогдсон дүрэм, мөн гадаад интерфейс бүрт холбогдсон хөрвүүлэлтийн мэдэгдэл гэсэн үг. Клиент холбогдох үед хоёр интерфейс дээр зэрэг бичлэг хий; ISP B дээр ирж буй SYN ба ISP A-аас гарч буй SYN-ACK асуудлыг нэг гүйлтэд шийднэ.
Клиентэд хоёр дахь бичлэгийн талаар мэдэх арга өг
Failover нь клиентийн талын шийдвэр бөгөөд клиентийн гэр бүл бүр хувилбаруудын талаар өөр өөрөөр мэддэг. ASA дээр нөөц серверийн жагсаалтыг бүлгийн бодлогын webvpn шинж чанараар хүргэдэг бол бусад клиентүүд профайл доторх жагсаалт эсвэл хэрэглэгчийн сонгодог гарын хоёр дахь профайлыг хүлээдэг. Cisco-гийн холболтын бодлогын гарын авлага нь клиентэд тохируулсан болон гарцаас өгсөн нөөц мэдээллийг хоёуланг нь тайлбарладаг бөгөөд эдгээр протоколд хамаарах дэлгэрэнгүй мэдээллийг клиент бүр эсвэл туннелийн горимд ерөнхийлөх ёсгүй. Хоёр дахь бичлэгийг буруу механизмын эргэн тойронд барихаасаа өмнө байршуулсан клиент аль механизмыг хэрэгжүүлж байгааг батал.
Ямар ч механизм байсан, клиент үндсэн замаа алдахаас өмнө өөр нэрийг шийдвэрлэж чадах ёстой. Хүмүүсийн алгасдаг хамаарал нь энэ: хэрэв нөөц нэрийг саяхан эвдэрсэн туннелээр л хүрч болох шийдвэрлэгч хариулж байвал нөөц хувилбар эхэлж ч чадахгүй. Хоёр дахь нэрийг орон нутгаас эсвэл интернэтээр хариулдаг шийдвэрлэгчид нийтэл. Шилжилтийн дараа шинэ баталгаажуулалт, шинэ програмын сесс хүлээ, учир нь клиентийн failover нь төлөвтэй failover биш бөгөөд урт хугацааны сессүүд үүнийг даван туулахгүй.
Хоёр нийлүүлэгч дээрх нэг хаяг нь өөр бүтээгдэхүүн
Нэг нийтийн хаягийг хоёр шугамаар хүрч болохоор байлгах нь маршрутжуулалтын үйлчилгээ бөгөөд VPN-ийн чагтлах нүд биш. Үүнд хоёр нийлүүлэгчийн зөөхөд бэлэн хаягийн орон зай хэрэгтэй бөгөөд тэдний сүлжээ хүлээн авах хэлбэрээр зарлах ёстой, үүнийг нийлүүлэгчээс хамааралгүй орон зай, BGP бүхий олон холболт олгодог. ISP A-ийн хаягийг ISP B-ийн интерфейст оноох нь тэнд хүргэхгүй; пакет тухайн префиксийг хэзээ ч зарлаж байгаагүй сүлжээнд хүрч, дээрээс хаягдана.
Хоёр бичлэг нийтлэхэд эдгээрийн аль нь ч хэрэггүй. Хэрэв клиент хоёр нэрийг барьж, тэдгээрийн хооронд шилжиж чадвал хоёр бие даасан бичлэг хангалттай бөгөөд та AS дугаар, peering хэлэлцээр, хаа сайгүй хүлээн зөвшөөрөгдөх префиксээс зайлсхийнэ. Зөөврийн хаягийн сонголтыг зөвхөн клиентүүдийг дахин тохируулж сольж болохгүй нэг тогтвортой орох цэг үнэхээр хэрэгтэй үед, эсвэл TTL сааталтай DNS-д суурилсан failover нь таны зохиож буй тасалдалд хэтэрхий удаан үед л авч үзээрэй.
Дараа нь юу шалгах вэ
Ажиллахгүй байгаа бичлэгээс гадагш энэ дарааллаар ажилла: хоёр дахь хаяг гаднаас хариулж байна уу, клиентийн хүлээж буй таних тэмдгийг танилцуулж байна уу, хүсэлт ирсэн замаар хариу гарч байна уу, клиент хэрэгтэй болохоос өмнө нэрийг мэдэж чадах уу. Хариу нь үгүй газарт тэр давхаргыг засаж, туршилтын хост биш байршуулсан профайлаар дахин туршаад үз, учир нь лабораторийн гар барилт бодит клиентийн дууссан холболтоос бага зүйлийг нотолдог.
WAN бүрт хаяг, порт, дуусгах интерфейс, гэрчилгээний нэр, буцах зам, хөрвүүлэлтийн дүрэм бүхий товч бүртгэл хөтөлж, шугам, NAT төхөөрөмж эсвэл клиентийн хувилбар өөрчлөгдөх бүрт дахин шалга. Сул зогссон нөөц замууд чимээгүй ялзардаг: хэн ч ашигладаггүй бичлэгийн талаар бүгд түүнээс хамааралтай болох өдөр хүртэл юу ч анхааруулдаггүй.