Hvers vegna EC2 nær ekki AWS Client VPN fartölvunni þinni
Client VPN þýðir IPv4 upptök biðlarans yfir á netviðmót endapunktsins. Þess vegna virkar svarið en ný tenging frá EC2 ekki.
Fartölva sem er tengd í gegnum AWS Client VPN nær EC2 forriti án vandræða. Síðan reynir þú hið gagnstæða, frá EC2 á það vistfang sem biðlarinn fékk, og tengingin hangir eða er hafnað. Þetta ósamræmi er sjaldan öryggishópsregla sem vantar. Á Client VPN endapunkti sem er tengdur VPC undirnetum þýðir AWS IPv4 upptök biðlarans yfir á netviðmót endapunktsins, svo ekkert innkomið VPC vistfang er til sem táknar fartölvuna þína.
Byrjaðu á því sem upptakan sýnir
Taktu upp á EC2 vélinni meðan biðlarinn tengist og lestu upprunavistfangið sem forritið sér í raun. Ef það er viðmót endapunktsins á VPC hliðinni en ekki vistfang úr biðlarasafninu, er þýðingin staðfest áður en þú breytir einni einustu reglu.
Biðlarasafnið er úthlutunarbil, ekki undirnet með bakleið. Það er á þessum mun sem flestar slíkar rannsóknir fara úrskeiðis.
Þýðingin sem skýrir ósamræmið
Þremur straumum er ruglað saman og aðeins einn þeirra er sá sem fólk prófar.
| 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 |
Lýsingin á Client VPN íhlutunum segir skýrt að IPv4 upptök biðlarans séu þýdd yfir á viðmót endapunktsins, og það nægir til að sjá hvers vegna miðröðin hefur ekkert til að stemma við.
Ný tenging þarf leið, skref til að leysa vistfang og ákvörðun um heimild. Þýðingarstaða úr lotu einhvers annars veitir ekkert af þessu þrennu.
Hvers vegna svar er ekki ný tenging
TCP svar er stemmt við fyrirliggjandi færslu, þess vegna virkar bakleiðin alveg án innkominnar reglu. Nýtt SYN frá EC2 vélinni hefur enga færslu til að stemma við, svo það verður venjuleg útleiðartilraun á áfangastað sem VPC veit ekki hvernig á að ná.
Þess vegna er líka villandi að lýsa þessu sem umferð sem fer aðeins í aðra áttina. Bakumferð streymir stöðugt í þessum lotum. Það sem vantar leiðina er frumkvæðið.
Hvað brýtur enn lotu sem ætti að virka
Öryggishópar, net-ACL og eldveggur fartölvunnar sjálfrar skipta öllu fyrir tengingarnar sem eiga að takast. Misheppnað ping segir minnst, því ICMP stefnan er oft aðskilin frá TCP stefnunni sem þú hefur áhyggjur af.
Skrifaðu þessar reglur miðað við þýddu upptökina, ekki vistfang biðlarans. Reglur sem eru bundnar við vistfangið sem birtist aldrei á netinu eru algengasta sjálfskapaða bilunin í þessari hönnun.
Þegar VPC verður virkilega að hefja samræðurnar
Ef þjónusta á að tilkynna vinnustöð, snúðu stefnunni við og leyfðu biðlaranum að halda varanlegri útleiðarrás sem þjónustan svarar á. Ef allt fjarlegt net þarf að vera aðgengilegt frá VPC, veldu arkitektúr sem birtir formerki sín og aðgangsstefnu í stað þess að gera ráð fyrir að Client VPN geri það þegar. Aðgangur biðlara að biðlara er þriðja, þrengra tilfellið með eigin leiðar- og heimildarhlutum. Ekkert þessara er bara hakreitur á núverandi endapunkti.
Haltu líka umfangi IPv4 skýringarinnar heiðarlegu. Núverandi AWS skjöl aðgreina IPv6, þar sem þessi þýðing á ekki við, og aðrar tengingargerðir sem beina öðru vísi.
Prófaðu í þremur merktum skrefum: biðlarinn opnar leyfða lotu, VPC þjónustan svarar þeirri lotu og VPC vélin opnar nýja lotu að biðlaranum. Að fyrstu tvö takist en það þriðja mistakist er væntanleg mynd þessarar hönnunar, ekki galli sem eiga að elta með eldveggsreglum.