AWS Client VPN с разделен тунел: кои маршрути да публикувате

Конзолата предлага превключвател за разделен тунел, затова решението изглежда като отметка. Не е. До клиента всъщност достига публикуваният набор от маршрути на крайната точка и този списък решава кои частни префикси минават през тунела, дали общият интернет трафик остава локален или излиза през AWS и с кой резолвер клиентът все още може да говори. Три въпроса решават дизайна и на всеки може да се отговори лошо, докато връзката все още успява.

Флагът за разделен тунел не е списък с дестинации

AWS описва разделения тунел като добавяне на маршрути на крайната точка към таблицата с маршрути на клиента при установяване на връзката. Маршрут за частната VPC ограничава тунела до тази дестинация; всичко останало следва обичайния път на клиента. Маршрутът по подразбиране е различна инструкция с различен ефект, затова документацията за разделен тунел предупреждава срещу публикуване на 0.0.0.0/0 на крайна точка, конфигурирана за този режим: той по-скоро чупи свързаността, отколкото да я разширява. Таблицата с маршрути на крайната точка е политиката, а таблицата с маршрути на клиента е резултатът, който можете да прегледате.

Четете таблицата с маршрути на крайната точка и инсталираните маршрути на клиента заедно. Етикетът описва намерение; маршрутите описват какво се случва.

Решение първо: трябва ли общият интернет трафик да остане локален?

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

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

Решение второ: кои частни префикси и с чие разрешение?

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

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

Когато дестинацията трябва да е достъпна по име, отбележете, че въпросът за разрешаване на имена е следващият, а не въпросът за маршрута.

Решение трето: кой резолвер следва тунела?

Клиентът може да получи DNS сървър, достъпен само през VPN, и този резолвер работи само ако адресът му е вътре в оторизиран маршрут. Проверете и двете половини: адресът на резолвера следва публикуван маршрут и сървърът отговаря на имената, които приложението пита. Заявка, която успява по адрес, докато името на хоста се проваля, сочи към именуване, а не към маршрутизация, и отстраняването на проблеми в тунела в такъв случай прахосва следобеда.

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

Променете набора от маршрути, после проверете двата свята

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

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

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