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