En EC2 Elastic IP er ikke instansens private VPN-adresse

Instansen har en privat adresse, Elastic IP-adressen er knyttet til den, og en rute for den offentlige /32 legges til i VPN-en i håp om at de to blir det samme. Det blir de ikke. En Elastic IP er en oversettelse som utføres utenfor gjesten, av internettgatewayen, på trafikk som tar internettveien. Gjestens operativsystem ser aldri den adressen konfigurert på et grensesnitt. Å legge den til et tunnelgrensesnitt gjenskaper ikke oversettelsen lenger opp og lager en andre, motstridende identitet for den samme maskinen.

To adresser, én instans

Instansens nettverksgrensesnitt har en privat adresse inne i VPC-en, og det er adressen gjesten kjenner. Elastic IP-adressen er knyttet til det samme grensesnittet, men lever på den offentlige siden av tilordningen.

Alt som når instansen via internett, ankommer oversatt til den private adressen. Alt instansen sender til internett, går ut med Elastic IP-adressen som kilde, igjen på grunn av den oversettelsen.

Inne i gjesten finnes én adresse. Utenfor finnes to. Den asymmetrien forklarer det meste av forvirringen på dette området. Gjesten kan ikke konfigurere hva gatewayen oversetter. Den kan bare svare på adressen den faktisk har.

Hva internettgatewayen faktisk gjør

AWS-dokumentasjonen om internettgatewayen beskriver ordningen: instansen er klar over sin private IPv4-adresse, og gatewayen leverer den tilsvarende oversettelsen til offentlig IPv4 eller Elastic IP for trafikk på internettveien.

Det er nettverksadresseoversettelse, ikke et alias. Tilordningen vedlikeholdes av gatewayen, er knyttet til assosiasjonen og gjelder bare pakker som passerer den. Fjern assosiasjonen, og den offentlige identiteten forsvinner uten at gjesten merker noe.

Derfor blir en privat VPN-pakke adressert til den offentlige /32 ikke omtolket som en privat pakke til gjestens lokale adresse. Pakken følger ruten den passer til, som sender den til internettgatewayen, og gatewayens oppførsel avhenger av om veien er tillatt i begge retninger.

Hvorfor tunnelgrensesnitt-trikset mislykkes

Tilordning av Elastic IP-adressen til et tunnelgrensesnitt ber gjesten behandle en offentlig adresse som lokal. Nå krever to ting den samme adressen: gatewayens oversettelse på internettveien og det lokale grensesnittet inne i tunnelen. Returtrafikk har ikke noe entydig svar på hvilken som gjelder.

Selv når det ser ut til å virke, har designet skjult det egentlige spørsmålet. Klienter når enten den private adressen gjennom tunnelen eller det offentlige endepunktet gjennom internett, og de to veiene har forskjellige sikkerhetsgrupper, forskjellig logging og forskjellige feilmoduser.

Adressen var aldri problemet. Valget av vei var det.

Tre mål, tre design

Hvis målet er et offentlig VPN-endepunkt, er Elastic IP-adressen det riktige verktøyet: eksterne parter kobler til over internett, og den krypterte transporten avsluttes på instansen. Den indre applikasjonstrafikken bruker deretter den private adressen.

Hvis målet er privat tilgang til applikasjonen, er målet den private adressen eller et privat DNS-navn som løser til den, og VPN-ruten, sikkerhetsgruppen og returveien må alle stemme. Elastic IP-adressen forekommer ikke i det designet i det hele tatt.

Hvis målet er en stabil offentlig utgangsidentitet for VPN-brukere, er det et NAT-design på utgangssiden, ikke en adresse på klientens tunnel. Tre mål som høres like ut gir tre forskjellige diagrammer, og bare ett av dem innebærer å plassere en Elastic IP på et nytt sted.

Bekreft veien du valgte

For privat tilgang, bekreft at VPN-ruten dekker det private prefikset, at VPC-rutetabellen sender trafikk tilbake til tunnelen, at sikkerhetsgruppen tillater klientens kilde og at klientens egen brannmur tillater svaret. Test deretter én ekte forespørsel i stedet for en ping.

For offentlig tilgang, bekreft klientens internettutgang, rutingen til den offentlige inngangen og sikkerhetspolicyen dens. Om en VPN-klient kan nå et offentlig endepunkt gjennom tunnelen, avhenger av tunnelens utgangs- og brannmurregler, ikke av Elastic IP-assosiasjonen.

Hvis et offentlig vertsnavn må virke fra begge sider, bruk et DNS-design som svarer med den private adressen for VPN-klienter og den offentlige adressen for alle andre, og hold sertifikatet gyldig for navnet i stedet for adressen. Arbeidsrekkefølge: navngi målet, velg adressen som hører til, og bekreft deretter ruter, policy og én forespørsel.