Хъб и спици или пълна мрежа: коя VPN топология пасва на вашите обекти

Два филиала си говорят по цял ден, а тунелът между тях обикаля през център за данни в друг регион. Всяка заявка плаща за този обход два пъти и никой не забелязва, докато синхронизацията на файлове не започне да изглежда погрешна. Точно тук започва въпросът за топологията: не с това коя диаграма изглежда по-устойчива, а с това за какъв модел на трафика плащате. И двата дизайна работят и се провалят по различен начин и на различна цена.

Пребройте връзките между възлите преди всичко друго

При N обекта пълната мрежа изисква N по N минус едно, делено на две, тунела; хъбът изисква N. При пет обекта това са десет срещу пет, което още изглежда управляемо. При петнадесет е 105 срещу петнадесет и разликата вече не е аритметична, а кадрова.

Всяка от тези връзки носи състояние, което трябва да притежавате. В IPsec това означава асоциация за сигурност, идентичност, ключ или сертификат, откриване на мъртъв партньор и поне един маршрут за всеки отдалечен префикс. В WireGuard това означава публичен ключ и AllowedIPs блок за всеки партньор, което е по-евтино на партньор, но идва напълно без откриване: новият обект е промяна на конфигурацията на всеки съществуващ така или иначе.

Нека решава смесът от трафик, а не рисунката

Ако трафикът на филиалите е предимно заявки към централен ERP или файлов клъстер, хъбът не е компромис, а правилната форма: трафикът вече е искал да отиде там и една политическа точка е по-лесна за одит от мрежа от двойки правила. Пълната мрежа заслужава сложността си, когато филиалите обменят данни помежду си — репликация между два офиса, глас между обекти, споделен CAD ресурс, който десетки инженери отварят по цял ден.

Неудобните случаи са по средата и те са мнозинството. Измерете, преди да спорите, вместо да гадаете по организационна схема.

Четете таблицата като решаващ фактор, не като правило. Три от четири реда в една посока обикновено решават дизайна; разделянето означава хибрид, до който повечето зрели мрежи така или иначе стигат.

На хъба трябва да се нареди да препраща

Два работещи тунела спица-към-хъб не създават достъп спица-към-спица. Хъбът се нуждае от включено IP препращане, маршрут до мрежата на всяка спица, правило във защитната стена, което разрешава транзита, и изчислен обратен път; всяка спица се нуждае от маршрут до префиксите на другия обект. На Linux хъб това е net.ipv4.ip_forward=1 плюс FORWARD верига, която не изпуска двойката тихо, а при IPsec, базиран на политики, това са селектори на трафик, които изброяват отдалечената подмрежа на спицата от двата края. При strongSwan бележките за препращането покриват страната на ядрото и защитната стена, когато това е липсващият слой. Евтин тест е да пуснете трафик от една спица към услуга на другата, докато гледате броячите на хъба; правило, което никога не се увеличава, означава, че редът е грешен, а не маршрутът.

Централната политика също е полезната част. На филиалите може да се разреши да достигат споделени услуги, без да се достигат един друг, и тази матрица на достъп си струва да бъде записана изрично. Липсващите маршрути са слаб заместител на правило, което някой може да прочете.

Пазете се от полуготовия вариант: спица A маршрутизира към спица B през хъба, хъбът маршрутизира в двете посоки, а защитната стена на хъба разрешава нови връзки от A, но не от B. Първата посока се тества добре, а втората виси, което изглежда като маршрутна повреда, а не е.

Проектирайте отказа, после нормалния път

Единственият хъб е споделена зависимост и транзитно тясно място, а резервирането е мястото, където дизайните с хъб обикновено се объркват. Два хъба означават, че всяка спица държи два тунела, и обратният път трябва да съвпада с изходящия; когато не съвпада, защитна стена със състояние изхвърля отговорите и симптомът е връзка, която се отваря и после умира. По-големите внедрявания решават това с протокол за маршрутизация върху тунелите вместо статични префикси, което е повече механизми, но премахва гаданията. Каквото и да изберете, запишете обратния път до изходящия, защото обратната половина е тази, която никой не тества.

Пълната мрежа разпръсква този риск: падането на връзката на един обект не изолира останалите. Тя също умножава местата, където изборът на път може да ви изненада, а сесиите на приложенията пак не преживяват смяна на пътя без помощ.

Нито един от двата дизайна не поддържа TCP сесия жива през превключване сам по себе си. Ако приложението не може да се свърже отново, топологията не е вашият проблем.

Избирайте по цената на промяната, после проверете маршрутите

Започнете с хъба, защото това е по-евтиното, за което да сгрешите, и добавете директни тунели за двойките, чийто трафик го оправдава. Този хибрид не е отказ да решите; това е дизайнът, до който повечето организации стигат в рамките на година. Важното е всяка директна връзка да има посочена причина и собственик.

След това проверете двете рисунки, а не една. За нормалния път, traceroute от всеки обект до всеки префикс на услуга и потвърдете, че хоповете съвпадат с диаграмата. За пътя на отказа спрете един тунел и повторете, защото маршрут, който работи само докато всичко работи, не е проектиран, а само конфигуриран.

Пазете двете рисунки заедно с матрицата на достъп и ги преглеждайте, когато се добави обект; цената, която управлявате, е цената на следващата промяна, а не елегантността на текущата картина.