Зошто 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.