Чаму EC2 не дасягае вашага ноўтбука праз AWS Client VPN
Client VPN пераўтварае IPv4-крыніцы кліента ў інтэрфейс endpoint. Таму адказ працуе, а новае злучэнне з EC2 — не.
Ноўтбук, падключаны праз AWS Client VPN, без праблем дасягае праграмы на EC2. Затым вы спрабуеце зваротны кірунак — з EC2 на адрас, які быў выдадзены кліенту, — і злучэнне завісае або адмаўляецца. Такая асіметрыя рэдка бывае адсутным правілам групы бяспекі. На endpoint Client VPN, звязаным з падсеткамі VPC, AWS пераўтварае IPv4-крыніцы кліента ў сеткавы інтэрфейс endpoint, таму ўваходнага адрасу VPC, які прадстаўляе ваш ноўтбук, не існуе.
Пачніце з таго, што паказвае перахоп
Зрабіце перахоп на хаўсце EC2, пакуль кліент падключаецца, і прачытайце адрас крыніцы, які праграма фактычна бачыць. Калі гэта інтэрфейс endpoint на баку VPC, а не адрас з пула кліентаў, пераўтварэнне пацверджана яшчэ да таго, як вы зменіце хоць адно правіла.
Пул кліентаў — гэта дыяпазон выдзялення, а не падсетка са зваротным маршрутам. Менавіта на гэтым адрозненні большасць такіх расследаванняў і збіваецца.
Пераўтварэнне, якое тлумачыць асіметрыю
Тры патокі блытаюць паміж сабой, і толькі адзін з іх — той, які людзі тэстуюць.
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
Апісанне кампанентаў Client VPN ясна гаворыць, што IPv4-крыніцы кліента пераўтвараюцца ў інтэрфейс endpoint, і гэтага дастаткова, каб убачыць, чаму сярэдні радок не мае з чым супаставіцца.
Новаму злучэнню патрэбны маршрут, крок развязання адрасу і рашэнне аб аўтарызацыі. Стан пераўтварэння з чужой сесіі не дае ні аднаго з трох.
Чаму адказ — не новае злучэнне
Адказ TCP супастаўляецца з існуючым запісам, таму зваротны шлях працуе зусім без уваходнага правіла. Свежы SYN з хаўста EC2 не мае запісу для супастаўлення, таму становіцца звычайнай выходнай спробай да прызначэння, да якога VPC не ведае, як дабрацца.
Менавіта таму апісанне гэтага як трафіку, што ідзе толькі ў адзін бок, памылковае. Зваротны трафік у гэтых сесіях ідзе бесперапынна. Без шляху застаецца менавіта ініцыяцыя.
Што ўсё яшчэ ламае сесію, якая павінна працаваць
Групы бяспекі, сеткавыя ACL і ўласны фаервол ноўтбука ўсе маюць значэнне для злучэнняў, якія павінны прайсці. Няўдалы ping паведамляе найменш, бо палітыка ICMP часта асобная ад палітыкі TCP, якая вас цікавіць.
Пішыце гэтыя правілы пад пераўтвораную крыніцу, а не пад адрас кліента. Правілы, прывязаныя да адрасу, які ніколі не з'яўляецца ў сетцы, — самая частая самастойна створаная памылка ў гэтым дызайне.
Калі VPC сапраўды павінен пачаць размову
Калі сэрвіс павінен паведаміць працоўнай станцыі, перавярніце кірунак і дайце кліенту трымаць пастаянны выходны канал, на які сэрвіс адказвае. Калі ўся аддаленая сетка павінна быць дасягальнай з VPC, выбірайце архітэктуру, якая публікуе свае прэфіксы і палітыку доступу, а не мяркуйце, што Client VPN ужо гэта робіць. Доступ кліент-да-кліента — трэці, вузейшы выпадак з уласнымі аб'ектамі маршруту і аўтарызацыі. Нішто з гэтага не з'яўляецца проста пунктам на існуючым endpoint.
Трымайце межы тлумачэння IPv4 сумленнымі. Сучасная дакументацыя AWS аддзяляе IPv6, дзе гэтае пераўтварэнне не ўжываецца, і іншыя мадэлі падключэння, якія маршрутызуюць інакш.
Тэстуйце ў тры пазначаныя крокі: кліент адкрывае дазволеную сесію, сэрвіс VPC адказвае на гэтую сесію, а хост у VPC адкрывае новую сесію да кліента. Паспяховыя першыя два пры няўдалым трэцім — гэта чаканая форма гэтага дызайну, а не дэфект, за якім трэба ганяцца правіламі фаерволу.