Un Elastic IP EC2 nu este adresa VPN privată a instanței

Instanța are o adresă privată, Elastic IP este asociată cu ea, iar o rută pentru acel /32 public este adăugată în VPN în speranța că cele două vor deveni același lucru. Nu devin. Un Elastic IP este o traducere efectuată în afara invitatului, de gateway-ul de internet, pe traficul care urmează calea de internet. Sistemul de operare al invitatului nu vede niciodată acea adresă configurată pe o interfață. Adăugarea ei pe o interfață de tunel nu reproduce traducerea de mai sus și creează o a doua identitate, contradictorie, pentru aceeași mașină.

Două adrese, o instanță

Interfața de rețea a instanței deține o adresă privată în interiorul VPC, iar aceasta este adresa pe care o cunoaște invitatul. Elastic IP este asociată cu aceeași interfață, dar trăiește pe partea publică a mapării.

Tot ce ajunge la instanță prin internet sosește tradus la adresa privată. Tot ce instanța trimite pe internet pleacă având Elastic IP ca sursă, din nou din cauza acelei traduceri.

În interiorul invitatului există o adresă. În exterior există două. Această asimetrie explică cea mai mare parte a confuziei din acest domeniu. Invitatul nu poate configura ce traduce gateway-ul. Poate răspunde doar pe adresa pe care o deține efectiv.

Ce face de fapt gateway-ul de internet

Documentația AWS despre gateway-ul de internet descrie aranjamentul: instanța își cunoaște adresa IPv4 privată, iar gateway-ul furnizează traducerea corespunzătoare în IPv4 public sau Elastic IP pentru traficul de pe calea de internet.

Aceasta este traducere de adrese de rețea, nu un alias. Maparea este întreținută de gateway, legată de asociere și se aplică doar pachetelor care o traversează. Eliminați asocierea și identitatea publică dispare fără ca invitatul să observe ceva.

De aceea un pachet VPN privat adresat către /32 public nu este reinterpretat ca pachet privat către adresa locală a invitatului. Pachetul urmează ruta cu care se potrivește, care îl trimite la gateway-ul de internet, iar comportamentul gateway-ului depinde de permisiunea căii în ambele direcții.

De ce eșuează trucul interfeței de tunel

Atribuirea Elastic IP unei interfețe de tunel cere invitatului să trateze o adresă publică drept locală. Acum două lucruri revendică aceeași adresă: traducerea gateway-ului pe calea de internet și interfața locală din interiorul tunelului. Traficul de retur nu are un răspuns consecvent cu privire la care se aplică.

Chiar și când pare să funcționeze, designul a ascuns întrebarea reală. Clienții ajung fie la adresa privată prin tunel, fie la punctul final public prin internet, iar cele două căi au grupuri de securitate diferite, jurnalizare diferită și moduri de eșec diferite.

Adresa nu a fost niciodată problema. Alegerea căii a fost.

Trei obiective, trei designuri

Dacă obiectivul este un punct final VPN public, Elastic IP este instrumentul potrivit: partenerii la distanță se conectează la el prin internet, iar transportul criptat se termină pe instanță. Traficul intern al aplicației folosește apoi adresa privată.

Dacă obiectivul este accesul privat la aplicație, destinația este adresa privată sau un nume DNS privat care se rezolvă la ea, iar ruta VPN, grupul de securitate și calea de retur trebuie toate să fie de acord. Elastic IP nu apare deloc în acel design.

Dacă obiectivul este o identitate publică de ieșire stabilă pentru utilizatorii VPN, acesta este un design NAT pe partea de ieșire, nu o adresă pe tunelul clientului. Trei obiective care sună similar produc trei diagrame diferite, iar doar unul dintre ele implică plasarea unui Elastic IP într-un loc nou.

Verificați calea pe care ați ales-o

Pentru acces privat, confirmați că ruta VPN acoperă prefixul privat, că tabelul de rute al VPC returnează traficul în tunel, că grupul de securitate permite sursa clientului și că firewall-ul clientului permite răspunsul. Apoi testați o cerere reală în loc de un ping.

Pentru acces public, confirmați ieșirea de internet a clientului, rutarea intrării publice și politica sa de securitate. Dacă un client VPN poate ajunge la un punct final public prin tunel depinde de regulile de ieșire și de firewall ale tunelului, nu de asocierea Elastic IP.

Dacă un nume de gazdă public trebuie să funcționeze din ambele părți, folosiți un design DNS care răspunde cu adresa privată pentru clienții VPN și cu adresa publică pentru toți ceilalți, și păstrați certificatul valid pentru nume, nu pentru adresă. Ordinea de lucru: numiți obiectivul, alegeți adresa care îi aparține, apoi verificați rute, politică și o cerere.