En EC2 Elastic IP är inte instansens privata VPN-adress

Instansen har en privat adress, Elastic IP-adressen är kopplad till den, och en rutt för den offentliga /32 läggs till i VPN:en i hopp om att de två ska bli samma sak. Det blir de inte. En Elastic IP är en översättning som utförs utanför gästen, av internetgatewayen, på trafik som tar internetvägen. Gästens operativsystem ser aldrig den adressen konfigurerad på ett gränssnitt. Att lägga till den på ett tunnelgränssnitt återskapar inte översättningen högre upp och skapar en andra, motstridig identitet för samma maskin.

Två adresser, en instans

Instansens nätverksgränssnitt har en privat adress inne i VPC:n, och det är adressen som gästen känner till. Elastic IP-adressen är kopplad till samma gränssnitt men lever på den offentliga sidan av mappningen.

Allt som når instansen via internet anländer översatt till den privata adressen. Allt som instansen skickar till internet går ut med Elastic IP-adressen som källa, återigen på grund av den översättningen.

Inne i gästen finns en adress. Utanför finns två. Den asymmetrin förklarar det mesta av förvirringen på området. Gästen kan inte konfigurera vad gatewayen översätter. Den kan bara svara på den adress den faktiskt har.

Vad internetgatewayen faktiskt gör

AWS dokumentation om internetgatewayen beskriver arrangemanget: instansen känner till sin privata IPv4-adress, och gatewayen tillhandahåller motsvarande översättning till offentlig IPv4 eller Elastic IP för trafik på internetvägen.

Det är nätverksadressöversättning, inte ett alias. Mappningen underhålls av gatewayen, är knuten till associationen och gäller bara paket som passerar den. Ta bort associationen och den offentliga identiteten försvinner utan att gästen märker något.

Därför tolkas inte ett privat VPN-paket adresserat till den offentliga /32 om som ett privat paket till gästens lokala adress. Paketet följer den rutt det matchar, som skickar det till internetgatewayen, och gatewayens beteende beror på om vägen är tillåten i båda riktningarna.

Varför tunnelgränssnittstricket misslyckas

Att tilldela Elastic IP-adressen till ett tunnelgränssnitt ber gästen behandla en offentlig adress som lokal. Nu gör två saker anspråk på samma adress: gatewayens översättning på internetvägen och det lokala gränssnittet inne i tunneln. Returtrafiken har inget entydigt svar på vilken som gäller.

Även när det verkar fungera har designen dolt den egentliga frågan. Klienter når antingen den privata adressen genom tunneln eller den offentliga slutpunkten via internet, och de två vägarna har olika säkerhetsgrupper, olika loggning och olika felmoder.

Adressen var aldrig problemet. Valet av väg var det.

Tre mål, tre designer

Om målet är en offentlig VPN-slutpunkt är Elastic IP-adressen rätt verktyg: fjärrparter ansluter till den via internet och den krypterade transporten avslutas på instansen. Den inre applikationstrafiken använder sedan den privata adressen.

Om målet är privat åtkomst till applikationen är destinationen den privata adressen eller ett privat DNS-namn som löser till den, och VPN-rutten, säkerhetsgruppen och returvägen måste alla stämma. Elastic IP-adressen förekommer inte alls i den designen.

Om målet är en stabil offentlig utgångsidentitet för VPN-användare, är det en NAT-design på utgångssidan, inte en adress på klientens tunnel. Tre mål som låter lika ger tre olika diagram, och bara ett av dem innebär att en Elastic IP placeras på en ny plats.

Verifiera vägen du valde

För privat åtkomst, bekräfta att VPN-rutten täcker det privata prefixet, att VPC:ns rutttabell skickar tillbaka trafik till tunneln, att säkerhetsgruppen tillåter klientens källa och att klientens egen brandvägg tillåter svaret. Testa sedan en riktig begäran i stället för en ping.

För offentlig åtkomst, bekräfta klientens internetutgång, routningen för den offentliga ingången och dess säkerhetspolicy. Om en VPN-klient kan nå en offentlig slutpunkt genom tunneln beror på tunnelns utgångs- och brandväggsregler, inte på Elastic IP-associationen.

Om ett offentligt värdnamn måste fungera från båda hållen, använd en DNS-design som svarar med den privata adressen för VPN-klienter och den offentliga adressen för alla andra, och håll certifikatet giltigt för namnet i stället för adressen. Arbetsordning: namnge målet, välj adressen som hör till det och verifiera sedan rutter, policy och en begäran.