Kāpēc EC2 nevar sasniegt jūsu AWS Client VPN klēpjdatoru
Client VPN pārveido IPv4 klienta avotus uz galapunkta tīkla saskarni. Tāpēc atbilde darbojas, bet jauns savienojums no EC2 ne.
Klēpjdators, kas savienots ar AWS Client VPN starpniecību, bez problēmām sasniedz EC2 lietojumprogrammu. Pēc tam jūs mēģināt pretējo, no EC2 uz adresi, kas tika piešķirta klientam, un savienojums uzkaras vai tiek noraidīts. Šī asimetrija reti ir trūkstošs drošības grupas noteikums. Client VPN galapunktā, kas saistīts ar VPC apakštīkliem, AWS pārveido IPv4 klienta avotus uz galapunkta tīkla saskarni, tāpēc nav nevienas ienākošās VPC adreses, kas pārstāvētu jūsu klēpjdatoru.
Sāciet ar to, ko parāda ieraksts
Veiciet ierakstu EC2 resursdatorā, kamēr klients savienojas, un nolasiet avota adresi, ko lietojumprogramma faktiski redz. Ja tā ir VPC puses galapunkta saskarne, nevis adrese no klientu kopas, pārveide ir apstiprināta vēl pirms jūs maināt kaut vienu noteikumu.
Klientu kopa ir piešķiršanas diapazons, nevis apakštīkls ar atgriešanās maršrutu. Tieši šajā atšķirībā vairums šādu izmeklēšanu aiziet nepareizi.
Pārveide, kas izskaidro asimetriju
Trīs plūsmas tiek sajauktas savā starpā, un tikai viena no tām ir tā, ko cilvēki pārbauda.
| 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 komponentu apraksts skaidri norāda, ka IPv4 klienta avoti tiek pārveidoti uz galapunkta saskarni, un ar to pietiek, lai redzētu, kāpēc vidējai rindai nav ar ko saskaņoties.
Jaunam savienojumam ir vajadzīgs maršruts, adreses atrisināšanas solis un autorizācijas lēmums. Pārveides stāvoklis no kāda cita sesijas nesniedz nevienu no trim.
Kāpēc atbilde nav jauns savienojums
TCP atbilde tiek saskaņota ar esošu ierakstu, tāpēc atgriešanās ceļš darbojas bez jebkura ienākošā noteikuma. Jaunam SYN no EC2 resursdatora nav ieraksta, ar ko saskaņoties, tāpēc tas kļūst par parastu izejošu mēģinājumu uz galamērķi, uz kuru VPC nezina, kā nokļūt.
Tāpēc arī šī aprakstīšana kā tikai vienā virzienā plūstošs trafiks maldina. Atgriešanās trafiks šajās sesijās plūst nepārtraukti. Bez ceļa ir tieši iniciēšana.
Kas joprojām salauž sesiju, kurai vajadzētu darboties
Drošības grupas, tīkla ACL un paša klēpjdatora ugunsmūris visi ir svarīgi savienojumiem, kuriem vajadzētu izdoties. Neizdevies ping pasaka vismazāk, jo ICMP politika bieži ir atsevišķa no TCP politikas, kas jūs interesē.
Rakstiet šos noteikumus pret pārveidoto avotu, nevis klienta adresi. Noteikumi, kas piesaistīti adresei, kura tīklā nekad neparādās, ir visbiežākā paša radītā kļūda šajā dizainā.
Kad VPC tiešām ir jāsāk saruna
Ja pakalpojumam ir jāpaziņo darbstacijai, apgrieziet virzienu un ļaujiet klientam uzturēt pastāvīgu izejošu kanālu, uz kuru pakalpojums atbild. Ja visam attālinātajam tīklam jābūt sasniedzamam no VPC, izvēlieties arhitektūru, kas publicē savus prefiksus un piekļuves politiku, nevis pieņemiet, ka Client VPN to jau dara. Klienta piekļuve klientam ir trešais, šaurākais gadījums ar saviem maršruta un autorizācijas objektiem. Neviens no tiem nav vienkārši izvēles rūtiņa esošajā galapunktā.
Saglabājiet godīgu arī IPv4 skaidrojuma tvērumu. Pašreizējā AWS dokumentācija nošķir IPv6, kur šī pārveide netiek piemērota, un citus pievienošanas modeļus, kas maršrutē citādi.
Pārbaudiet trīs apzīmētos soļos: klients atver atļautu sesiju, VPC pakalpojums atbild uz šo sesiju, un VPC resursdators atver jaunu sesiju pret klientu. Tas, ka pirmie divi izdodas, bet trešais neizdodas, ir šī dizaina gaidītā forma, nevis defekts, kam jādzītojas ar ugunsmūra noteikumiem.