Един VPN сайт към сайт за няколко VPC в AWS Transit Gateway

Прикачете VPN веднъж и всяко VPC към един транзитен шлюз, после разделете асоциирането от пропагандирането, за да стигат клоновете до офиса, но не един до друг.

Две VPC се нуждаят от офисната мрежа това тримесечие и точно при втория тунел оценката се разпада. AWS Transit Gateway може да служи като общ маршрутизиращ център: VPN се прикачва веднъж и всяко VPC се прикачва към същия център. След това локалната мрежа стига до всяко прикачено VPC през една връзка. Това променя кой притежава решението за маршрутизиране и именно тази част повечето проекти объркват.

Прикачването на VPN и прикачванията на VPC са отделни обекти върху един и същ шлюз, затова маршрутните връзки трябва да се изградят след това.

On-premises network <-> Site-to-Site VPN <-> Transit Gateway
                                            |- VPC A
                                            |- VPC B

Защо пиърингът не е прекият път, на който хората се надяват

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

Това ограничение е свойство на пиъринга, а не квота, която можете да вдигнете.

Асоциирането и пропагандирането вършат различна работа

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

Напълно свързан малък център е лесният случай.

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

Маршрутите на работните натоварвания живеят другаде

Всяка подмрежа за работни натоварвания все още се нуждае от собствен маршрут към транзитния шлюз за предвидените локални префикси. Тези маршрутни таблици на VPC са отделни обекти от собствените таблици на транзитния шлюз. Добавете префиксите, които ви трябват, и запазете съществуващите маршрути, вместо да заменяте всяка дестинация с нов default. Маршрутът на подмрежата също не обявява нищо на клиентското устройство.

Изберете динамично или статично маршрутизиране съзнателно; пиърингът не дава нито едното.

Изолирайте клоновете, без да губите локален достъп

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

Това е изолация на маршрутизирането, а не оторизация на приложението.

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

Какво центърът не поправя

Плановете за адреси трябва да останат непрепокриващи се, защото центърът не позволява един префикс да идентифицира две работни натоварвания. Всяко прикачване на VPC се нуждае от покритието на Availability Zone, което очакват натоварванията му. С BGP маршрутите на клиентското устройство обратно към всеки необходим префикс трябва да съответстват на проекта и на политиката му за импорт. Липсващото обявление изглежда точно като счупен тунел.

VPN връзката и транзитният шлюз вече са споделена инфраструктура.

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

Миграцията от съществуваща схема с virtual private gateway заслужава същия изричен план. Изградете прикачванията и политиките, преместете един контролиран път на работно натоварване и потвърдете разрешените и забранените връзки, преди да изведете стария път. Централизацията помага, когато дава на мрежовия екип едно място за управление на споделената свързаност, и вреди, когато скрие кой до кого може да стига зад една голяма таблица.

Подобни статии