Miksi EC2 ei tavoita AWS Client VPN -kannettavaasi
Client VPN muuntaa IPv4-asiakaslähteet päätepisteen verkkoliitäntään. Siksi vastaus toimii, mutta uusi yhteys EC2:sta ei.
AWS Client VPN:n kautta yhdistetty kannettava tavoittaa EC2-sovelluksen ongelmitta. Sitten kokeilet päinvastaista, EC2:sta asiakkaalle annettuun osoitteeseen, ja yhteys jää jumiin tai hylätään. Tämä epäsymmetria johtuu harvoin puuttuvasta tietoturvaryhmän säännöstä. VPC-verkon aliverkkoihin liitetyssä Client VPN -päätepisteessä AWS muuntaa IPv4-asiakaslähteet päätepisteen verkkoliitäntään, joten VPC:ssä ei ole saapuvaa osoitetta, joka edustaisi kannettavaasi.
Aloita siitä, mitä kaappaus näyttää
Ota kaappaus EC2-isännässä asiakkaan yhdistäessä ja lue lähdeosoite, jonka sovellus todella näkee. Jos se on VPC:n puoleinen päätepisteen liitäntä eikä asiakasvarannon osoite, muunnos on vahvistettu ennen kuin muutat yhtäkään sääntöä.
Asiakasvaranto on jakelualue, ei aliverkko, jolla on paluureitti. Juuri tässä erotuksessa useimmat tällaiset tutkimukset menevät pieleen.
Muunnos, joka selittää epäsymmetrian
Kolme virtaa sekoitetaan keskenään, ja vain yksi niistä on se, jota ihmiset testaavat.
| 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 -komponenttien kuvaus kertoo selvästi, että IPv4-asiakaslähteet muunnetaan päätepisteen liitäntään, ja se riittää näkemään, miksi keskimmäisellä rivillä ei ole mitään täsmäytettävää.
Uusi yhteys tarvitsee reitin, osoitteen selvitysvaiheen ja valtuutuspäätöksen. Jonkun toisen istunnon muunnostila ei tarjoa yhtäkään näistä kolmesta.
Miksi vastaus ei ole uusi yhteys
TCP-vastaus täsmäytetään olemassa olevaan merkintään, siksi paluupolku toimii täysin ilman saapuvia sääntöjä. EC2-isännän tuore SYN ei löydä täsmäytettävää merkintää, joten siitä tulee tavallinen lähtevä yritys kohteeseen, johon VPC ei tiedä, miten päästään.
Siksi on myös harhaanjohtavaa kuvata tätä vain yhteen suuntaan kulkevaksi liikenteeksi. Paluuliikenne virtaa näissä istunnoissa jatkuvasti. Ilman reittiä on aloitus.
Mikä yhä rikkoo istunnon, jonka pitäisi toimia
Tietoturvaryhmät, verkon ACL:t ja kannettavan oma palomuuri ovat kaikki tärkeitä yhteyksille, joiden pitäisi onnistua. Epäonnistunut ping kertoo vähiten, koska ICMP-käytäntö on usein erillään siitä TCP-käytännöstä, josta välität.
Kirjoita ne säännöt muunnettua lähdettä vasten, älä asiakkaan osoitetta vasten. Säännöt, jotka on sidottu osoitteeseen, jota ei koskaan näy verkossa, ovat tämän suunnittelun yleisin itse aiheutettu virhe.
Kun VPC:n todella on aloitettava keskustelu
Jos palvelun on ilmoitettava työasemalle, käännä suunta ja anna asiakkaan pitää pysyvää lähtevää kanavaa, johon palvelu vastaa. Jos koko etäverkon on oltava tavoitettavissa VPC:stä, valitse arkkitehtuuri, joka julkaisee etuliitteensä ja käyttöoikeuskäytäntönsä, sen sijaan että olettaisit Client VPN:n tekevän sen jo. Asiakas-asiakas-yhteys on kolmas, kapeampi tapaus, jolla on omat reitti- ja valtuutusobjektinsa. Mikään näistä ei ole vain valintaruutu olemassa olevassa päätepisteessä.
Pidä myös IPv4-selityksen laajuus rehellisenä. Nykyinen AWS-dokumentaatio erottaa IPv6:n, jossa tuota muunnosta ei sovelleta, ja muut liityntämallit, jotka reitittävät eri tavalla.
Testaa kolmessa merkityssä vaiheessa: asiakas avaa sallitun istunnon, VPC-palvelu vastaa siihen istuntoon ja VPC-isäntä avaa uuden istunnon asiakasta kohti. Se, että kaksi ensimmäistä onnistuu ja kolmas epäonnistuu, on tämän suunnittelun odotettu muoto, ei vika, jota pitäisi jahdata palomuurisäännöillä.