Защо 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 отваря нова сесия към клиента. Успехът на първите две при провал на третата е очакваната форма на този дизайн, а не дефект, който да гоните с правила на защитната стена.