Как да насочите SaaS трафик към правилния клиентски VPN

SaaS платформа се свързва с дванадесет клиентски мрежи и двама от тези клиенти използват 10.20.0.10 за основната си база данни. Работник, който получи този адрес в задача, няма как да разбере коя база данни има предвид задачата, а споделената таблица за маршрутизиране с удоволствие ще го изпрати към тунела, към който сочи префиксът. Решението не е повече тунели; то е да решите къде идентичността на наемателя влиза в пътя и какъв модел на изолация изисква адресният план. Три условия решават избора: дали клиентските префикси се припокриват, колко далеч може да се разпространи грешка и кой управлява конектора.

Две клиентски бази данни, един адрес на местоназначение

IP адресът е местоположение, а не идентичност. Заявката трябва да носи наемател, който сървърът е проверил, и този наемател трябва да избере мрежовия контекст, преди адресът на местоназначението да бъде разрешен.

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

Първо решете модела на изолация

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

Ако префиксите са различни и политиката позволява контролиран хъб, един Transit Gateway с таблици за маршрутизиране за всеки наемател е работещ. Асоциирането на прикачване избира таблицата за маршрутизиране, използвана за трафик, влизащ от това прикачване, а разпространението избира кои маршрути се появяват в дадена таблица. Прикачване на наемател, свързано само със собствената му таблица и разпространяващо само собствените си префикси, достига до хъба и до нищо друго. Това е решение за маршрутизиране и остава правилно само докато никой не добави маршрут по подразбиране към споделената таблица.

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

Какво всъщност означава изолацията в Transit Gateway

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

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

AWS добави NAT 1:1 на ниво прикачване за Transit Gateway и Cloud WAN на 23 октомври 2026 година, което променя отговора за припокриване при поддържаните прикачвания. Документацията за Transit Gateway NAT описва статични IPv4 съпоставяния без състояние с равни префикси и запазени битове на хоста. Проверете поддържаните типове прикачвания и регионалните ограничения, преди да проектирате около това.

Обвържете задачата с проверен наемател

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

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

Проверките на здравето трябва да посочват наемателя и етапа: установен тунел, наличен маршрут и успешна реална заявка към услуга са три различни сигнала. Общият брой на работещите тунели ще скрие единствения клиент, чийто конектор е повреден.

Тествайте пътищата, които трябва да се провалят

Изпълнете три теста преди стартиране. Разрешена операция A трябва да успее, разрешена операция B трябва да успее, а задача A, умишлено насочена към конектора на B или към неговия преведен псевдоним, трябва да се провали със затваряне. След това прекъснете един тунел и потвърдете, че задачата се проваля само за този наемател, без да пада към подмрежата със същия номер на друг клиент. Възстановяването също трябва да се тества, защото остарял маршрут или кеширани идентификационни данни могат да надживеят прекъсването.

Архитектурата може да бъде обединени работници с изолирани конектори или напълно разделени ресурси на наематели. Инвариантът е един и същ: провереният контекст на наемателя избира маршрута и идентификационните данни и никаква промяна на маршрута никога не дава на приложението разрешение между наематели.