Зашто EC2 не може да достигне ваш AWS Client VPN лаптоп
Client VPN преводи IPv4 изворе клијента у мрежни интерфејс крајње тачке. Зато одговор ради, а нова веза са EC2 не.
Лаптоп повезан преко AWS Client VPN без проблема достиже апликацију на EC2. Затим пробате обрнуто, са EC2 на адресу која је додељена клијенту, и веза се блокира или одбија. Ова асиметрија је ретко правило безбедносне групе које недостаје. На крајњој тачки Client VPN повезаној са подмрежама VPC, AWS преводи IPv4 изворе клијента у мрежни интерфејс крајње тачке, тако да не постоји долазна VPC адреса која представља ваш лаптоп.
Почните од онога што снимак показује
Направите снимак на EC2 домаћину док се клијент повезује и прочитајте изворну адресу коју апликација заиста види. Ако је то интерфејс крајње тачке на страни 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 извори клијента преводе у интерфејс крајње тачке, што је довољно да се види зашто средњи ред нема са чим да се подудари.
Новој вези треба рута, корак разрешавања адресе и одлука о ауторизацији. Стање превода из туђе сесије не даје ниједно од то троје.
Зашто одговор није нова веза
Одговор TCP се подудара са постојећим записом, зато повратни пут ради без икаквог долазног правила. Нови SYN са EC2 домаћина нема запис за подударање, па постаје обичан излазни покушај ка одредишту до ког VPC не зна како да стигне.
Зато је и погрешно ово описивати као саобраћај који иде само у једном смеру. Повратни саобраћај у овим сесијама тече непрекидно. Без пута је управо покретање.
Шта још квари сесију која би требало да ради
Безбедносне групе, мрежни ACL-ови и сопствени firewall лаптопа сви су важни за везе које би требало да успеју. Неуспешан ping каже најмање, јер је ICMP политика често одвојена од TCP политике која вас занима.
Пишите та правила према преведеном извору, а не према адреси клијента. Правила везана за адресу која се никада не појављује на мрежи најчешћа су самонанета грешка у овом дизајну.
Када VPC заиста мора да започне разговор
Ако услуга треба да обавести радну станицу, окрените смер и дозволите клијенту да држи трајни излазни канал на који услуга одговара. Ако цела удаљена мрежа мора да буде доступна из VPC, изаберите архитектуру која објављује своје префиксе и политику приступа, уместо да претпостављате да Client VPN то већ чини. Приступ клијент-клијент је трећи, ужи случај са сопственим рутама и објектима ауторизације. Ништа од овога није само поље за штиклирање на постојећој крајњој тачки.
Држите честим и обим објашњења за IPv4. Актуелна AWS документација одваја IPv6, где се тај превод не примењује, и друге моделе повезивања који рутирају другачије.
Тестирајте у три означена корака: клијент отвара дозвољену сесију, услуга у VPC одговара на ту сесију, и домаћин у VPC отвара нову сесију ка клијенту. То што прва два успевају, а трећи не, очекивани је облик овог дизајна, а не дефект који треба јурити правилима firewall-а.