Хаб-спица және толық тор: сайттарыңызға қай 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-ның форвардтау жазбалары ядро мен брандмауэр жағын қамтиды, дәл сол қабат жетіспегенде. Арзан тест: бір спицадан екіншісіндегі қызметке трафик жіберіп, хабтың есептегіштерін бақылау; ешқашан өспейтін ереже маршрут емес, реттің қате екенін білдіреді.
Орталық саясат та пайдалы бөлігі. Филиалдарға ортақ қызметтерге жетуге рұқсат беріп, бір-біріне жетпеуге болады, және бұл қатынас матрицасын ашық жазып қоюға тұрарлық. Жетіспейтін маршруттар адам оқи алатын ереженің орнын баса алмайды.
Жартылай жасалған нұсқадан сақ болыңыз: A спицасы хаб арқылы B спицасына маршруттайды, хаб екі жаққа да маршруттайды, ал хабтың брандмауэры A-дан жаңа қосылыстарға рұқсат береді, B-дан бермейді. Бірінші бағыт жақсы өтеді, екіншісі ілінеді, бұл маршруттау ақауына ұқсайды, бірақ олай емес.
Алдымен ақаулықты, сосын қалыпты жолды жобалаңыз
Жалғыз хаб ортақ тәуелділік және транзит бөтелкесі, ал хаб жобалары әдетте дәл резервтеуде қателеседі. Екі хаб болса, әр спица екі туннель ұстайды және қайтару жолы шығыс жолымен келісуі керек; келіспесе, күйге негізделген брандмауэр жауаптарды тастайды, ал симптом — ашылып, сосын өлетін қосылыс. Ірі орналастырулар мұны статикалық префикстердің орнына туннель үстіндегі маршруттау протоколымен шешеді, бұл көбірек механизм, бірақ болжамды жояды. Не таңдасаңыз да, қайтару жолын шығыс жолының жанына жазыңыз, өйткені ешкім тексермейтін жарты — дәл сол қайтару жартысы.
Тор бұл тәуекелді таратады: бір сайттың арнасы өшсе, қалғандары оқшауланбайды. Ол маршрут таңдау сізді таң қалдыратын жерлерді де көбейтеді, ал қосымша сессиялары әлі де көмексіз жол өзгерісінен аман қалмайды.
Екі жобаның ешқайсысы TCP сессиясын ауысу кезінде өздігінен тірі ұстамайды. Қосымша қайта қосыла алмаса, топология сіздің мәселеңіз емес.
Өзгеріс құны бойынша таңдап, сосын маршруттарды тексеріңіз
Қателесу арзанырақ болғандықтан, хабтан бастаңыз, ал трафигі мұны ақтайтын жұптарға тікелей туннельдер қосыңыз. Бұл гибрид шешім қабылдай алмау емес; көптеген ұйым бір жыл ішінде келіп тоқтайтын жоба осы. Маңыздысы — әр тікелей байланыстың айтылған себебі мен иесі болуы.
Сосын бір емес, екі суретті тексеріңіз. Қалыпты жол үшін әр сайттан әр қызмет префиксіне traceroute іске қосып, хоптардың схемаға сәйкестігін растаңыз. Ақаулық жолы үшін бір туннельді өшіріп, қайталаңыз, өйткені бәрі тұрғанда ғана жұмыс істейтін маршрут жобаланбаған, тек конфигурацияланған.
Екі суретті де қатынас матрицасымен бірге сақтаңыз және сайт қосылғанда оларға қайта оралыңыз; сіз басқарып отырған құн — келесі өзгерістің құны, қазіргі суреттің әсемдігі емес.