Kvifor EC2 ikkje når AWS Client VPN-laptopen din
Client VPN omset IPv4-klientkjelder til nettverksgrensesnittet til endepunktet. Difor verkar svaret, medan ei ny tilkopling frå EC2 ikkje gjer det.
Ein laptop som er kopla til via AWS Client VPN, når ein EC2-applikasjon utan problem. Så prøver du det motsette, frå EC2 til adressa klienten fekk tildelt, og tilkoplinga heng eller blir avvist. Den asymmetrien er sjeldan ein manglande tryggingsgrupperegel. På eit Client VPN-endepunkt som er knytt til VPC-subnett, omset AWS IPv4-klientkjelder til nettverksgrensesnittet til endepunktet, så det finst inga innkomande VPC-adresse som representerer laptopen din.
Byrja med det opptaket viser
Ta eit opptak på EC2-verten medan klienten koplar til, og les kjeldeadressa applikasjonen faktisk ser. Viss det er grensesnittet til endepunktet på VPC-sida og ikkje ei adresse frå klientpoolen, er omsetjinga stadfesta før du endrar ein einaste regel.
Klientpoolen er eit tildelingsområde, ikkje eit subnett med ei returrute. Det er på denne skilnaden dei fleste slike undersøkingar går gale.
Omsetjinga som forklarer asymmetrien
Tre straumar blir forveksla med kvarandre, og berre éin av dei er den folk testar.
| 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 |
Skildringa av Client VPN-komponentane seier uttrykkeleg at IPv4-klientkjelder blir omsette til grensesnittet til endepunktet, og det er nok til å sjå kvifor den midtre rada ikkje har noko å matche.
Ei ny tilkopling treng ei rute, eit adresseoppslagstrinn og ei autorisasjonsavgjerd. Omsetjingstilstand frå ein annan sin sesjon gir ingen av dei tre.
Kvifor eit svar ikkje er ei ny tilkopling
Eit TCP-svar blir matcha mot ei eksisterande oppføring, og difor verkar returvegen heilt utan nokon innkomande regel. Eit ferskt SYN frå EC2-verten har inga oppføring å matche, så det blir eit vanleg utgåande forsøk mot ein destinasjon som VPC-en ikkje veit korleis han skal nå.
Det er òg difor det er misvisande å skildre dette som trafikk som berre går éin veg. Returtrafikken flyt kontinuerleg i desse sesjonane. Det er igangsetjinga som manglar ein veg.
Kva som framleis øydelegg ein sesjon som burde verke
Tryggingsgrupper, nettverks-ACL-ar og brannmuren til laptopen sjølv betyr alt for tilkoplingane som skal lukkast. Ein mislukka ping seier minst, fordi ICMP-politikken ofte er skild frå TCP-politikken du bryr deg om.
Skriv desse reglane mot den omsette kjelda, ikkje klientadressa. Reglar som er knytte til adressa som aldri blir vist på nettet, er den vanlegaste sjølvpåførte feilen i dette designet.
Når VPC-en verkeleg må starte samtalen
Viss ein teneste skal varsle ein arbeidsstasjon, snu retninga og la klienten halde ein varig utgåande kanal som tenesta svarar på. Viss eit heilt eksternt nettverk må vere tilgjengeleg frå VPC-en, vel ein arkitektur som publiserer prefiksa og tilgangspolitikken sin i staden for å anta at Client VPN alt gjer det. Klient-til-klient-tilgang er eit tredje, smalare tilfelle med eigne rute- og autorisasjonsobjekt. Ingen av desse er ein avkryssingsboks på det eksisterande endepunktet.
Hald òg omfanget av IPv4-forklaringa ærleg. Gjeldande AWS-dokumentasjon skil ut IPv6, der denne omsetjinga ikkje blir brukt, og andre tilkoplingsmodellar som ruter annleis.
Test i tre merkte trinn: klienten opnar ein tillaten sesjon, VPC-tenesta svarar på den sesjonen, og ein VPC-vert opnar ein ny sesjon mot klienten. At dei to fyrste lukkast medan den tredje feilar, er den venta forma for dette designet, ikkje ein feil som skal jagast med brannmurreglar.