Kial EC2 ne povas atingi vian AWS Client VPN tekkomputilon
Client VPN tradukas IPv4-klientajn fontojn al la interfaco de la finpunkto. Tial la respondo funkcias, sed nova konekto de EC2 ne.
Tekkomputilo konektita per AWS Client VPN atingas EC2-aplikaĵon senprobleme. Poste vi provas la malon, de EC2 al la adreso atribuita al la kliento, kaj la konekto haltas aŭ rifuziĝas. Tiu nesimetrio malofte estas mankanta sekurecgrupa regulo. Ĉe Client VPN-finpunkto asociita kun VPC-subretoj, AWS tradukas IPv4-klientajn fontojn al la reta interfaco de la finpunkto, do ne ekzistas envenanta VPC-adreso, kiu reprezentus vian tekkomputilon.
Komencu per tio, kion montras la kaptaĵo
Faru kaptaĵon sur la EC2-gastiganto dum la kliento konektiĝas, kaj legu la fontan adreson, kiun la aplikaĵo fakte vidas. Se ĝi estas la finpunkta interfaco sur la VPC-flanko kaj ne adreso el la klienta baseno, la traduko estas konfirmita antaŭ ol vi ŝanĝos eĉ unu regulon.
La klienta baseno estas atribua gamo, ne subreto kun revena vojo. Ĝuste ĉe tiu distingo la plej multaj el ĉi tiuj esploroj eraras.
La traduko, kiu klarigas la nesimetrion
Tri fluoj konfuziĝas unu kun la alia, kaj nur unu el ili estas tiu, kiun homoj testas.
| 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 |
La priskribo de la Client VPN-komponentoj klarigas, ke IPv4-klientaj fontoj tradukiĝas al la finpunkta interfaco, kio sufiĉas por vidi, kial la meza vico havas nenion por kongrui.
Nova konekto bezonas vojon, paŝon de adresa solvado kaj decidon pri rajtigo. Traduka stato el la sesio de iu alia donas neniun el la tri.
Kial respondo ne estas nova konekto
TCP-respondo kongruiĝas kun ekzistanta ero, kaj tial la revena vojo funkcias tute sen envenanta regulo. Nova SYN de la EC2-gastiganto havas neniun eron por kongrui, do ĝi fariĝas ordinara elira provo al celo, kiun la VPC ne scias kiel atingi.
Tial ankaŭ priskribi ĉi tion kiel trafikon irantan nur unu direkton estas misgvida. Revena trafiko fluas senĉese en ĉi tiuj sesioj. La senvoja parto estas la iniciato.
Kio ankoraŭ rompas sesion, kiu devus funkcii
Sekurecgrupoj, retaj ACL-oj kaj la propra fajroŝirmilo de la tekkomputilo ĉiuj gravas por la konektoj, kiuj devus sukcesi. Malsukcesa ping diras la malplej, ĉar ICMP-politiko ofte estas aparta de la TCP-politiko, kiu gravas al vi.
Skribu tiujn regulojn laŭ la tradukita fonto, ne laŭ la klienta adreso. Reguloj ligitaj al la adreso, kiu neniam aperas sur la reto, estas la plej ofta memkaŭzita fiasko en ĉi tiu dezajno.
Kiam la VPC vere devas komenci la konversacion
Se servo devas sciigi laborejon, inversigu la direkton kaj lasu la klienton teni daŭran eliran kanalon, al kiu la servo respondas. Se tuta fora reto devas esti atingebla el la VPC, elektu arkitekturon, kiu publikigas siajn prefiksojn kaj alirpolitikon anstataŭ supozi, ke Client VPN jam faras tion. Kliento-al-kliento aliro estas tria, pli mallarĝa kazo kun propraj vojaj kaj rajtigaj objektoj. Neniu el ĉi tiuj estas simple markobutono ĉe la ekzistanta finpunkto.
Tenu ankaŭ la amplekson de la IPv4-klarigo honesta. La nuna AWS-dokumentaro apartigas IPv6, kie tiu traduko ne aplikiĝas, kaj aliajn konektajn modelojn, kiuj enkursigas alie.
Testu en tri signitaj paŝoj: la kliento malfermas permesitan sesion, la VPC-servo respondas al tiu sesio, kaj VPC-gastiganto malfermas novan sesion al la kliento. Sukceso de la unuaj du dum la tria malsukcesas estas la atendata formo de ĉi tiu dezajno, ne difekto por ĉasi per fajroŝirmilaj reguloj.