Прекъсващ достъп през AWS Client VPN: проверете всеки свързан подмрежов сегмент

Един потребител се свързва, отваря вътрешното приложение и получава отговор; колега на същата крайна точка получава изтичане на времето от идентичен лаптоп в същата Wi-Fi мрежа. Този модел е отпечатъкът на client VPN крайна точка с повече от един свързан подмрежов сегмент, където пътищата не са еквивалентни. Проследявам това от конзолата навън, защото два раздела решават дали останалото разследване си заслужава. Нищо в конфигурацията на клиента не го обяснява.

Започнете от крайната точка и изброете асоциациите

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

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

Сравнете таблицата с маршрути на крайната точка с всяка асоциация

Отворете раздела Route table на същата крайна точка. Всеки целеви CIDR там има цел, а при client VPN целта е асоциация, а не шлюз. AWS изисква запис за дестинация за всеки свързан сегмент, така че маршрут, който сочи само към един от тях, прави достъпа зависим от това къде е попаднала сесията. Проверете дестинацията, която наистина ви интересува, след това проверете нейното правило за оторизация, защото маршрутът дава пътя, а правилото решава кой може да го използва.

След като таблицирате двата слоя, повредата е трудна за пропускане.

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

Проследете всеки сегмент до неговата ефективна таблица с маршрути

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

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

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

Проверете правилата за оторизация, после пътя обратно

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

Обратният път заслужава същото внимание. Peering връзката се нуждае от маршрут в VPC на приложението, сочещ обратно към CIDR на клиента, правила на групи за сигурност, които позволяват трафика в двата края, и мрежови ACL, които не го изхвърлят. Еднопосочната достъпност, при която ping работи, а TCP ръкостискането не, обикновено сочи към ACL или група за сигурност, а не към VPN.

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

Проверете с повторно свързване, а не с една щастлива заявка

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

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