Хаб ба бүрэн сүлжээ: таны сайтуудад аль VPN топологи тохирох вэ
Ажиллаж байгаа хоёр туннель бол топологи биш. Хаб, сүлжээ эсвэл хэдэн шууд холбоос бүхий хаб сонгохын өмнө дамжуулалт, эвдрэлийн үеийн зан төлөв, өөрчлөлтийн өртгийг харьцуулна уу.
Хоёр салбар оффис өдөржингөө бие биетэйгээ ярьж, тэдний хоорондох туннель өөр бүсийн дата төвөөр тойрч гардаг. Аливаа хүсэлт тэр тойролтын төлөө хоёр удаа төлдөг бөгөөд файлын синхрончлол буруу мэт санагдах хүртэл хэн ч анзаардаггүй. Топологийн асуулт яг эндээс эхэлдэг: аль диаграм илүү тэсвэртэй харагдахад биш, ямар трафикийн хэв маягийн төлөө төлж байгаад. Хоёр загвар хоёулаа ажилладаг бөгөөд хоёулаа өөр өөр аргаар, өөр өөр өртгөөр эвдэрдэг.
Юуны өмнө пиерийн харилцааны тоог гарга
N сайт байвал бүрэн сүлжээнд N-ийг N хасах нэгээр үржүүлээд хоёрт хуваасан хэмжээний туннель хэрэгтэй, харин хабанд N хангалттай. Таван сайтад энэ нь тавтай харьцуулахад арав, ажил гүйцэтгэхэд боломжийн харагдана. Арван таван сайтад энэ нь арван тавтай харьцуулахад 105 болж, ялгаа нь арифметик биш, боловсон хүчний асуудал болно.
Тэдгээр харилцаа бүр өөртөө хариуцах ёстой төлөвийг агуулна. IPsec-д энэ нь аюулгүй байдлын ассоциаци, таних тэмдэг, түлхүүр эсвэл сертификат, үхсэн пиерийг илрүүлэх, алсын префикс бүрт дор хаяж нэг маршрут. WireGuard-д энэ нь пиер бүрт нээлттэй түлхүүр ба AllowedIPs блок; пиер тутамд хямд боловч илрүүлэх боломж огт байхгүй: шинэ сайт аль ч тохиолдолд бүх хуучин сайтын тохиргоог өөрчлөхийг шаардана.
Зургаас биш, трафикийн бүрэлдэхүүнээс шийд
Салбарын трафик ихэвчлэн төв ERP эсвэл файлын кластерт чиглэсэн хүсэлт байвал хаб нь буулт биш, зөв хэлбэр: трафик аль хэдийн тэнд очихыг хүсч байсан бөгөөд нэг бодлогын цэг хос хосын дүрмийн сүлжээнээс хянахад хялбар. Сүлжээ нь салбарууд хоорондоо өгөгдөл солилцох үед нарийн төвөгтэй байдлаа зөвтгөдөг: хоёр оффисы хоорондын репликаци, сайтуудын хоорондын дуу, арван гаруй инженер өдөржингөө нээдэг CAD хуваалцалт.
Эвгүй тохиолдлууд энэ хооронд байрладаг бөгөөд тэдгээр нь олонх. Байгууллагын схемээс таамаглахгүйгээр маргахаасаа өмнө хэмжиж үзээрэй.
| Signal | Points to a hub | Points to a mesh |
|---|---|---|
| Branch-to-branch traffic | Occasional, small | Dominant, all day |
| Site count | Growing, past ten | Small and stable |
| Change rate | Frequent adds and moves | Rare |
| Failure tolerance | A second hub is affordable | Every site must survive alone |
Хүснэгтийг дүрэм биш, тэнцвэржүүлэгч гэж уншаарай. Дөрвөн мөрийн гурав нь нэг зүг заавал ихэвчлэн загварыг шийддэг, харин хуваагдал нь гибрид гэсэн үг бөгөөд олон төлөвшсөн сүлжээ эцэстээ ингэж ажилладаг.
Хабанд форвардлахыг хэлэх ёстой
Ажиллаж байгаа хоёр спиц-хаб туннель спицүүдийн хооронд хандалт үүсгэхгүй. Хабанд IP форвардлалт идэвхтэй, спиц сүлжээ бүрт маршрут, дамжуулалтыг зөвшөөрөх галт ханын дүрэм, буцах зам бодогдсон байх шаардлагатай; спиц бүрт нөгөө сайтын префиксүүдэд маршрут хэрэгтэй. Linux хабанд энэ нь net.ipv4.ip_forward=1 ба хосыг чимээгүй хаяхгүй FORWARD гинжин хэлхээ, харин бодлогод суурилсан IPsec-д хоёр төгсгөлдөө алсын спицийн дэд сүлжээг жагсаасан трафик сонгогч байна. strongSwan-ы форвардлах тэмдэглэл цөм ба галт ханын талыг хамардаг, яг тэр давхарга дутагдаж байгаа үед. Хямд туршилт бол нэг спицээс нөгөө дээрх үйлчилгээ рүү трафик илгээж, хабангийн тоолуурыг ажиглах; хэзээ ч өсдөггүй дүрэм нь маршрут биш, дараалал буруу гэсэн үг.
Төв бодлого нь бас ашигтай хэсэг. Салбаруудыг бие биедээ хүрэхгүйгээр хуваалцсан үйлчилгээнд хүрэхийг зөвшөөрч болох бөгөөд энэ хандалтын матрицыг тодорхой бичих нь үнэ цэнэтэй. Дутуу маршрут нь хүн уншиж болох дүрмийг орлох муу орлуулагч юм.
Хагас хийсэн хувилбараас болгоомжил: А спиц хабаар дамжин Б спиц рүү маршрутладаг, хаб хоёр тийшээ маршрутладаг, харин хабангийн галт хана А-аас шинэ холболтыг зөвшөөрөх боловч Б-ээс зөвшөөрдөггүй. Эхний чиглэл сайн шалгагдаж, хоёр дахь нь өлгөгддөг, энэ нь маршрутын алдаа мэт харагдах боловч тийм биш.
Эхлээд эвдрэлийг, дараа нь хэвийн замыг зохион бүтээ
Ганц хаб нь хуваалцсан хамаарал ба дамжуулалтын гацаа бөгөөд хаб загварууд ихэвчлэн нөөцлөлт дээр алдаа гаргадаг. Хоёр хаб гэдэг нь спиц бүр хоёр туннель барьж, буцах зам нь гадагшлах замтай тохирох ёстой; тохирохгүй бол төлөвт суурилсан галт хана хариуг хаяж, шинж тэмдэг нь нээгдээд дараа нь үхдэг холболт болно. Томоохон байршуулалт үүнийг статик префиксийн оронд туннелийн дээгүүр маршрутлалтын протоколоор шийддэг, энэ нь илүү механизм боловч таамаглалыг арилгана. Юу сонгосон ч буцах замыг гадагшлах замын хажууд бичээрэй, учир нь хэн ч шалгадаггүй хагас нь яг тэр буцах хагас юм.
Сүлжээ энэ эрсдэлийг тараадаг: нэг сайтын холбоос унахад бусдыг тусгаарлахгүй. Энэ нь маршрутын сонголт таныг гайхшруулах газрыг үржүүлдэг бөгөөд програмын сессүүд тусламжгүйгээр замын өөрчлөлтийг даван туулж чадахгүй хэвээр.
Аль ч загвар TCP сессийг шилжилтийн үед өөрөө амьд байлгадаггүй. Програм дахин холбогдож чадахгүй бол топологи таны асуудал биш.
Өөрчлөлтийн өртгөөр сонгож, дараа нь маршрутыг шалга
Буруу байх нь хямд тул хабаас эхэл, дараа нь трафик нь зөвтгөдөг хосуудад шууд туннель нэм. Тэр гибрид нь шийдэж чадаагүй байдал биш, ихэнх байгууллага нэг жилийн дотор хүрдэг загвар юм. Чухал нь шууд холбоос бүр тодорхой шалтгаан, эзэнтэй байх.
Дараа нь нэг биш, хоёр зургийг шалга. Хэвийн замын хувьд сайт бүрээс үйлчилгээний префикс бүр рүү traceroute ажиллуулж, хопүүд диаграмтай таарч байгааг батал. Эвдрэлийн замын хувьд нэг туннелийг унтраагаад давт, учир нь бүх зүйл ажиллаж байхад л ажилладаг маршрут нь зохион бүтээгдээгүй, зөвхөн тохируулагдсан.
Хоёр зургийг хандалтын матрицтай хамт хадгал, сайт нэмэгдэхэд тэдгээр рүү эргэж хар; чиний удирдаж буй өртөг бол дараагийн өөрчлөлтийн өртөг, одоогийн зургийн гоо сайхны үнэ биш.