Zašto EC2 ne može dosegnuti vaš prijenosnik preko AWS Client VPN-a
Client VPN prevodi IPv4 izvore klijenta u sučelje endpointa. Zato odgovor radi, a nova veza s EC2 ne.
Prijenosnik povezan preko AWS Client VPN-a bez problema doseže aplikaciju na EC2. Zatim pokušate obrnuto, s EC2 na adresu koja je dodijeljena klijentu, i veza se blokira ili odbija. Ta asimetrija rijetko je nedostajuće pravilo sigurnosne grupe. Na endpointu Client VPN-a povezanom s podmrežama VPC-a AWS prevodi IPv4 izvore klijenta u mrežno sučelje endpointa, pa ne postoji ulazna VPC adresa koja predstavlja vaš prijenosnik.
Počnite od onoga što snimka pokazuje
Snimite promet na hostu EC2 dok se klijent povezuje i pročitajte izvornu adresu koju aplikacija zapravo vidi. Ako je to sučelje endpointa na strani VPC-a, a ne adresa iz skupa klijenata, prijevod je potvrđen prije nego što ste promijenili i jedno pravilo.
Skup klijenata je raspon za dodjelu, a ne podmreža s povratnom rutom. Upravo se na tom razlikovanju većina ovakvih istraga izgubi.
Prijevod koji objašnjava asimetriju
Tri se toka međusobno brkaju, a samo je jedan od njih onaj koji ljudi testiraju.
| 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 |
Opis komponenti Client VPN-a izričito navodi da se IPv4 izvori klijenta prevode u sučelje endpointa, što je dovoljno da se vidi zašto srednji red nema s čime da se podudara.
Nova veza treba rutu, korak razrješavanja adrese i odluku o autorizaciji. Stanje prijevoda iz tuđe sesije ne daje nijedno od to troje.
Zašto odgovor nije nova veza
TCP odgovor se podudara s postojećim zapisom, zato povratni put radi bez ikakvog ulaznog pravila. Svježi SYN s hosta EC2 nema zapis za podudaranje, pa postaje običan izlazni pokušaj prema odredištu do kojeg VPC ne zna kako doći.
Zato je i opisivanje ovoga kao prometa koji ide samo u jednom smjeru zavaravajuće. Povratni promet u tim sesijama teče neprekidno. Bez puta je upravo pokretanje.
Šta još kvari sesiju koja bi trebala raditi
Sigurnosne grupe, mrežni ACL-ovi i vlastiti vatrozid prijenosnika svi su važni za veze koje bi trebale uspjeti. Neuspjeli ping kaže najmanje, jer je ICMP politika često odvojena od TCP politike koja vas zanima.
Ta pravila pišite prema prevedenom izvoru, a ne prema adresi klijenta. Pravila vezana uz adresu koja se nikada ne pojavljuje na mreži najčešća su samoizazvana greška u ovom dizajnu.
Kada VPC zaista mora započeti razgovor
Ako usluga mora obavijestiti radnu stanicu, okrenite smjer i pustite klijenta da drži trajni izlazni kanal na koji usluga odgovara. Ako cijela udaljena mreža mora biti dostupna iz VPC-a, odaberite arhitekturu koja objavljuje svoje prefikse i politiku pristupa umjesto da pretpostavljate da Client VPN to već čini. Pristup klijent-klijent treći je, uži slučaj s vlastitim rutama i objektima autorizacije. Ništa od toga nije samo kvadratić na postojećem endpointu.
Držite i obim objašnjenja IPv4 iskrenim. Trenutna AWS dokumentacija odvaja IPv6, gdje se taj prijevod ne primjenjuje, i druge modele priključenja koji usmjeravaju drukčije.
Testirajte u tri označena koraka: klijent otvara dopuštenu sesiju, usluga u VPC-u odgovara na tu sesiju, a host u VPC-u otvara novu sesiju prema klijentu. Uspjeh prva dva uz neuspjeh trećeg očekivani je oblik ovog dizajna, a ne kvar koji treba loviti pravilima vatrozida.