Перарывісты доступ праз AWS Client VPN: праверце кожную звязаную падсетку

Карыстальнік падключаецца, адкрывае ўнутраную праграму і атрымлівае адказ; калега на той жа канцавой кропцы атрымлівае тайм-аўт з ідэнтычнага ноўтбука ў той жа Wi-Fi. Гэтая карціна — подпіс канцавой кропкі client VPN з некалькімі звязанымі падсеткамі, дзе шляхі не эквівалентныя. Я іду ад кансолі вонкі, бо дзве ўкладкі вырашаюць, ці варта рабіць астатняе расследаванне. Нішто ў канфігурацыі кліента гэтага не тлумачыць.

Пачніце з канцавой кропкі і пералічыце злучэнні

У кансолі VPC адкрыйце Client VPN endpoints, выберыце канцавую кропку і прачытайце ўкладку Associations. Кожнае злучэнне — гэта падсетка ў зоне даступнасці, і кліент трапляе на тую, якую выбера сэрвіс пры стварэнні злучэння. Запішыце ID падсетак і табліцу маршрутаў, якую кожная фактычна выкарыстоўвае, бо гэтыя два спісы — і ёсць параўнанне, якое вы збіраецеся зрабіць.

Калі канцавая кропка паказвае адно злучэнне, гэтая тэорыя няправільная, і кліент — лепшы падазраваны.

Параўнайце табліцу маршрутаў канцавой кропкі з кожным злучэннем

Адкрыйце ўкладку Route table на той жа канцавой кропцы. Кожны мэтавы CIDR там мае цэль, і для client VPN цэллю з’яўляецца злучэнне, а не шлюз. AWS патрабуе запіс мэты для кожнай звязанай падсеткі, таму маршрут, які накіраваны толькі на адну з іх, робіць доступ залежным ад таго, куды трапіла сесія. Праверце мэту, якая вам сапраўды важная, затым праверце яе правіла аўтарызацыі, бо маршрут дае шлях, а правіла вырашае, хто можа ім карыстацца.

Калі вы звядзеце абодва ўзроўні ў табліцу, збой цяжка не заўважыць.

Другі радок — гэта ўвесь баг у большасці тыкетаў. Маршрут канцавой кропкі ёсць, таму ніхто не глядзіць далей, і пакет памірае праз адзін крок унутры VPC.

Прасачыце кожную падсетку да яе эфектыўнай табліцы маршрутаў

Падсетка без яўнага злучэння з табліцай маршрутаў наследуе галоўную табліцу VPC. Чытайце табліцу, якая фактычна дзейнічае, а не тую, чыя назва выглядае правільна, і параўноўвайце мэту і цэль, а не подпіс у радку.

Кіраўніцтва AWS па перарывістым доступе апісвае гэта як пакрыццё маршрутамі ўсіх злучэнняў, і гэта правільная мадэль. Канцавая кропка дастаўляе пакет у падсетку, і табліца гэтай падсеткі ўсё яшчэ павінна ведаць, дзе знаходзіцца сетка праграмы.

Выпраўце адсутны радок у табліцы, якая ім валодае. Капіраванне цэлай табліцы маршрутаў з працоўнай падсеткі таксама капіруе рашэнні пра інтэрнэт, прылады і ізаляцыю, якія ніколі не прызначаліся для гэтай, і такі абмен звычайна горш за збой, з якога вы пачалі.

Праверце правілы аўтарызацыі, затым шлях назад

Правілы аўтарызацыі — для кожнай мэты і кожнай групы, і яны ацэньваюцца асобна ад маршрутаў. Мэта з маршрутамі паўсюль, але без правіла для групы карыстальніка, паводзіць сябе як чорная дзірка з табліцай маршрутаў, якая выглядае здаровай.

Зваротны шлях заслугоўвае такой жа ўвагі. Злучэнне peering патрабуе маршрут у VPC праграмы, які паказвае назад на CIDR кліента, правілы груп бяспекі, якія дазваляюць трафік на абодвух канцах, і сеткавыя ACL, якія яго не скідваюць. Аднабаковая дасяжнасць, калі ping працуе, а рукапоціск TCP не, звычайна паказвае на ACL або групу бяспекі, а не на VPN.

Уласныя групы бяспекі канцавой кропкі знаходзяцца на эластычных сеткавых інтэрфейсах злучэння, таму правіла, якое дазваляе порт праграмы з CIDR кліента, трэба далучыць да злучэння, а не толькі да інстанса.

Правярайце перападключэннем, а не адным удалым запытам

Пры split tunnel маршруты канцавой кропкі прадастаўляюцца пры ўсталяванні злучэння, таму зменены набор маршрутаў ніколі не даходзіць да кліента, які застаецца падключаным. Адключыцеся і падключыцеся зноў праз падтрымліваны кліент, затым пераканайцеся, што новыя маршруты ёсць на машыне.

Нарэшце, суаднясіце журнал злучэнняў з адрасам, які атрымаў кліент, і паўтарыце тэст столькі разоў, каб закрануць больш за адно злучэнне. Адзін удалы запыт пасля выпраўлення даказвае, што адзін шлях працуе, а тыкет быў пра іншы.