Ѕвезда или целосна мрежа: која 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 од секоја локација до секој префикс на услуга и потврдете дека скоковите се совпаѓаат со дијаграмот. За патот на отказ, исклучете еден тунел и повторете, бидејќи рута што работи само додека сѐ е подигнато не е дизајнирана, туку само конфигурирана.
Чувајте ги двата цртежи со матрицата на пристап и вратете се на нив кога се додава локација; трошокот што го управувате е трошокот на следната промена, не елеганцијата на сегашната слика.