Ein EC2 Elastic IP er ikkje den private VPN-adressa til instansen

Instansen har ei privat adresse, Elastic IP-adressa er knytt til henne, og ei rute for den offentlege /32 blir lagd til i VPN-en i håp om at dei to blir det same. Det blir dei ikkje. Ei Elastic IP er ei omsetjing som blir gjord utanfor gjesten, av internettporten, på trafikk som tek internettvegen. Operativsystemet til gjesten ser aldri den adressa konfigurert på eit grensesnitt. Å leggje henne til eit tunellgrensesnitt attskapar ikkje omsetjinga lenger oppe og lagar ein andre, motstridande identitet for den same maskina.

To adresser, éin instans

Nettverksgrensesnittet til instansen har ei privat adresse inne i VPC-en, og det er adressa gjesten kjenner. Elastic IP-adressa er knytt til det same grensesnittet, men lever på den offentlege sida av tilordninga.

Alt som når instansen via internett, kjem omsett til den private adressa. Alt instansen sender til internett, går ut med Elastic IP-adressa som kjelde, igjen på grunn av den omsetjinga.

Inne i gjesten finst éi adresse. Utanfor finst to. Den asymmetrien forklarer det meste av forvirringa på dette feltet. Gjesten kan ikkje konfigurere kva porten omset. Han kan berre svare på adressa han faktisk har.

Kva internettporten faktisk gjer

AWS-dokumentasjonen om internettporten skildrar ordninga: instansen er klar over si private IPv4-adresse, og porten leverer den tilsvarande omsetjinga til offentleg IPv4 eller Elastic IP for trafikk på internettvegen.

Det er nettverksadresseomsetjing, ikkje eit alias. Tilordninga blir halden ved like av porten, er knytt til assosiasjonen og gjeld berre pakkar som passerer henne. Fjern assosiasjonen, og den offentlege identiteten forsvinn utan at gjesten merkar noko.

Derfor blir ein privat VPN-pakke adressert til den offentlege /32 ikkje omtolka som ein privat pakke til den lokale adressa til gjesten. Pakken følgjer ruta han passar til, som sender han til internettporten, og åtferda til porten er avhengig av om vegen er tillaten i begge retningar.

Kvifor tunellgrensesnitt-trikset mislukkast

Tilordning av Elastic IP-adressa til eit tunellgrensesnitt ber gjesten handsame ei offentleg adresse som lokal. No krev to ting den same adressa: omsetjinga til porten på internettvegen og det lokale grensesnittet inne i tunellen. Returtrafikk har ikkje eit eintydig svar på kva som gjeld.

Sjølv når det ser ut til å verke, har designet skjult det eigenlege spørsmålet. Klientar når anten den private adressa gjennom tunellen eller det offentlege endepunktet gjennom internett, og dei to vegane har ulike tryggingsgrupper, ulik logging og ulike feilmodusar.

Adressa var aldri problemet. Valet av veg var det.

Tre mål, tre design

Viss målet er eit offentleg VPN-endepunkt, er Elastic IP-adressa det rette verktøyet: eksterne partar koplar til over internett, og den krypterte transporten blir avslutta på instansen. Den indre applikasjonstrafikken brukar deretter den private adressa.

Viss målet er privat tilgang til applikasjonen, er målet den private adressa eller eit privat DNS-namn som løyser til henne, og VPN-ruta, tryggingsgruppa og returvegen må alle stemme. Elastic IP-adressa førekjem ikkje i det designet i det heile.

Viss målet er ein stabil offentleg utgangsidentitet for VPN-brukarar, er det eit NAT-design på utgangssida, ikkje ei adresse på tunellen til klienten. Tre mål som høyrest like ut gir tre ulike diagram, og berre eitt av dei inneber å plassere ein Elastic IP på ein ny stad.

Stadfest vegen du valde

For privat tilgang, stadfest at VPN-ruta dekkjer det private prefikset, at rutetabellen i VPC-en sender trafikk tilbake til tunellen, at tryggingsgruppa tillèt kjelda til klienten og at brannmuren til klienten sjølv tillèt svaret. Test deretter éin ekte førespurnad i staden for ein ping.

For offentleg tilgang, stadfest internettutgangen til klienten, rutinga til den offentlege inngangen og tryggingspolitikken hans. Om ein VPN-klient kan nå eit offentleg endepunkt gjennom tunellen, er avhengig av utgangs- og brannmurreglane til tunellen, ikkje av Elastic IP-assosiasjonen.

Viss eit offentleg vertsnamn må verke frå begge sider, bruk eit DNS-design som svarar med den private adressa for VPN-klientar og den offentlege adressa for alle andre, og hald sertifikatet gyldig for namnet i staden for adressa. Arbeidsrekkjefølgje: namngi målet, vel adressa som høyrer til, og stadfest deretter ruter, politikk og éin førespurnad.