AWS Client VPN или бастион за достигане до VPC с peering

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

Два пътя, една крайна точка, различни собственици

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

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

Четири записа правят маршрутизирания път работещ

AWS документира този сценарий на страницата Client VPN how-it-works и на практика всичко опира до четири записа, притежавани от два или три екипа. Диапазоните са илюстративни; диапазонът с peering трябва да е уникален, а обратният диапазон трябва да отговаря на вашия план.

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

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

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

Групи за сигурност и последният метър разрешение

Маршрутизирането вкарва пакетите в B; B все още решава. За активна peering връзка в същия регион група за сигурност в B може да реферира групата, приложена към асоциацията на Client VPN, което държи правилото тясно и издържа на промени в адресите. Където референция към група не е осъществима, разрешете диапазона на подмрежата на асоциацията изрично, вместо да разширявате до 0.0.0.0/0, което превръща маршрутна грешка в необясним таймаут.

След това проверете това, което маршрутизирането никога не докосва: мрежовите ACL на двете подмрежи, allow-list на приложението или аудиторията на токена, и DNS. Peering не копира частни хоствани зони, така че лаптопът може да държи работещ маршрут към адрес, който не може да резолвне, а peering връзката не добавя доверие към сертификат. Насочете крайната точка към резолвер, който отговаря за B, после потвърдете, че частното име и сертификатът съвпадат.

Кога бастионът е честният отговор

Държа три тригера за съзнателен избор на бастион. VPC с peering принадлежи на екип, който няма да добави обратен маршрут за вашия диапазон или няма да приеме референция към група. Достъпът трябва да бъде одобряван или записван за всяка сесия, а приложението не може да го носи само. Или последният хоп трябва да остане вътре в B, защото услугата се резолвва само там и TLS идентичността ѝ е закачена към вътрешно име.

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

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

Transit Gateway и няколко асоциации променят сметката

Ако крайната точка е прикачена директно към Transit Gateway, а не към подмрежа, моделът се променя: клиентите вече не се преобразуват в адрес на интерфейс в подмрежа на асоциация и таблиците на маршрутите на шлюза трябва да носят клиентския диапазон плюс прикачването, което води до VPC с peering. По-чисто е в мащаб, но работата се мести от четири записа в таблици на маршрутите на шлюза.

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

Ред на проверка, който открива счупването бързо

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

1. Резолвнете името на приложението от клиента и проверете, че адресът е в диапазона с peering.
2. Свържете се, после прочетете лога на връзките на крайната точка за асоциацията, която е завършила сесията.
3. На тази подмрежа на асоциацията потвърдете, че таблицата на маршрутите сочи диапазона с peering към активна peering връзка.
4. На подмрежата с ресурси в B потвърдете обратен запис за диапазона на интерфейса и съответстващи правила на групата.
5. Тествайте една разрешена операция и един ресурс, който трябва да остане недостъпен; второто хваща остатъци от дебъг.
6. Свържете се отново след всяка промяна на split-tunnel маршрут, защото работещ тунел няма да поеме нов набор от маршрути.

Два симптома си струва да запомните. SYN, който достига до B без отговор, почти винаги е липсващият обратен маршрут. Връзка, която завършва и после се нулира, обикновено е групата, ACL или приложението. Нито едно от двете не се показва в лога на крайната точка като причина, затова пазете четирите записа със собственик до всеки.

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