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 til den offentlige /32 føjes til VPN'en i håbet om, at de to bliver det samme. Det gør de ikke. En Elastic IP er en oversættelse, der udføres uden for gæsten, af internetgatewayen, på trafik der følger internetvejen. Gæstens styresystem ser aldrig den adresse konfigureret på en grænseflade. At føje den til en tunnelgrænseflade genskaber ikke oversættelsen længere oppe og skaber en anden, modstridende identitet for den samme maskine.

To adresser, én instans

Instansens netværksgrænseflade har en privat adresse inde i VPC'en, og det er den adresse, gæsten kender. Elastic IP-adressen er knyttet til den samme grænseflade, men lever på den offentlige side af mappingen.

Alt, der når instansen via internettet, ankommer oversat til den private adresse. Alt, hvad instansen sender til internettet, forlader med Elastic IP-adressen som kilde, igen på grund af den oversættelse.

Inde i gæsten findes én adresse. Udenfor findes to. Den asymmetri forklarer det meste af forvirringen på dette område. Gæsten kan ikke konfigurere, hvad gatewayen oversætter. Den kan kun svare på den adresse, den faktisk har.

Hvad internetgatewayen faktisk gør

AWS' dokumentation om internetgatewayen beskriver ordningen: instansen er klar over sin private IPv4-adresse, og gatewayen leverer den tilsvarende offentlige IPv4- eller Elastic IP-oversættelse for trafik på internetvejen.

Det er netværksadresseoversættelse, ikke et alias. Mappingen vedligeholdes af gatewayen, er bundet til tilknytningen og gælder kun for pakker, der passerer den. Fjern tilknytningen, og den offentlige identitet forsvinder, uden at gæsten bemærker noget.

Det er derfor, en privat VPN-pakke adresseret til den offentlige /32 ikke genfortolkes som en privat pakke til gæstens lokale adresse. Pakken følger den rute, den matcher, som sender den til internetgatewayen, og gatewayens adfærd afhænger af, om vejen er tilladt i begge retninger.

Hvorfor tunnelgrænseflade-tricket mislykkes

Tildeling af Elastic IP-adressen til en tunnelgrænseflade beder gæsten om at behandle en offentlig adresse som lokal. Nu gør to ting krav på den samme adresse: gatewayens oversættelse på internetvejen og den lokale grænseflade inde i tunnelen. Returtrafik har ikke noget entydigt svar på, hvilken der gælder.

Selv når det ser ud til at virke, har designet skjult det egentlige spørgsmål. Klienter når enten den private adresse gennem tunnelen eller den offentlige endepunkt gennem internettet, og de to veje har forskellige sikkerhedsgrupper, forskellig logning og forskellige fejltilstande.

Adressen var aldrig problemet. Valget af vej var.

Tre mål, tre designs

Hvis målet er et offentligt VPN-endepunkt, er Elastic IP-adressen det rigtige værktøj: fjernpeers forbinder til den over internettet, og den krypterede transport afsluttes på instansen. Den indre applikationstrafik bruger derefter den private adresse.

Hvis målet er privat adgang til applikationen, er destinationen den private adresse eller et privat DNS-navn, der opløser til den, og VPN-ruten, sikkerhedsgruppen og returvejen skal alle stemme overens. Elastic IP-adressen optræder slet ikke i det design.

Hvis målet er en stabil offentlig udgangsidentitet for VPN-brugere, er det et NAT-design på udgangssiden, ikke en adresse på klientens tunnel. Tre mål, der lyder ens, giver tre forskellige diagrammer, og kun ét af dem indebærer at placere en Elastic IP et nyt sted.

Bekræft den vej, du valgte

For privat adgang skal du bekræfte, at VPN-ruten dækker det private præfiks, at VPC-rutetabellen sender trafik tilbage til tunnelen, at sikkerhedsgruppen tillader klientens kilde, og at klientens egen firewall tillader svaret. Test derefter én rigtig anmodning i stedet for en ping.

For offentlig adgang skal du bekræfte klientens internetudgang, den offentlige indgangs routing og dens sikkerhedspolitik. Om en VPN-klient kan nå et offentligt endepunkt gennem tunnelen, afhænger af tunnelens udgangs- og firewallregler, ikke af Elastic IP-tilknytningen.

Hvis et offentligt værtsnavn skal virke fra begge sider, skal du bruge et DNS-design, der svarer med den private adresse for VPN-klienter og den offentlige adresse for alle andre, og holde certifikatet gyldigt for navnet i stedet for adressen. Arbejdsrækkefølge: navngiv målet, vælg den adresse, der hører til, og bekræft derefter ruter, politik og én anmodning.