Una Elastic IP d'EC2 no és l'adreça VPN privada de la instància

La instància té una adreça privada, l'Elastic IP hi està associada i s'afegeix una ruta per a aquest /32 públic a la VPN amb l'esperança que les dues coses esdevinguin la mateixa. No ho fan. Una Elastic IP és una traducció feta fora del convidat, per la passarel·la d'internet, sobre el trànsit que segueix el camí d'internet. El sistema operatiu del convidat mai no veu aquesta adreça configurada en una interfície. Afegir-la a una interfície de túnel no reprodueix la traducció ascendent i crea una segona identitat en conflicte per a la mateixa màquina.

Dues adreces, una instància

La interfície de xarxa de la instància té una adreça privada dins de la VPC, i aquesta és l'adreça que coneix el convidat. L'Elastic IP està associada a la mateixa interfície, però viu al costat públic del mapatge.

Tot el que arriba a la instància per internet arriba traduït a l'adreça privada. Tot el que la instància envia a internet surt amb l'Elastic IP com a origen, de nou per aquesta traducció.

Dins del convidat hi ha una adreça. A fora n'hi ha dues. Aquesta asimetria explica la major part de la confusió en aquesta àrea. El convidat no pot configurar què tradueix la passarel·la. Només pot respondre a l'adreça que realment té.

Què fa realment la passarel·la d'internet

La documentació d'AWS sobre la passarel·la d'internet descriu el dispositiu: la instància coneix la seva adreça IPv4 privada i la passarel·la proporciona la traducció corresponent d'IPv4 pública o d'Elastic IP per al trànsit del camí d'internet.

Això és traducció d'adreces de xarxa, no un àlies. La passarel·la manté el mapatge, lliga a l'associació i només s'aplica als paquets que la travessen. Traieu l'associació i la identitat pública desapareix sense que el convidat noti res.

Per això un paquet VPN privat adreçat al /32 públic no es reinterpreta com un paquet privat a l'adreça local del convidat. El paquet segueix la ruta que coincideix, que l'envia a la passarel·la d'internet, i el comportament de la passarel·la depèn que el camí estigui permès en tots dos sentits.

Per què falla el truc de la interfície de túnel

Assignar l'Elastic IP a una interfície de túnel demana al convidat que tracti una adreça pública com a local. Ara dues coses reclamen la mateixa adreça: la traducció de la passarel·la al camí d'internet i la interfície local dins del túnel. El trànsit de retorn no té una resposta coherent sobre quina s'aplica.

Fins i tot quan sembla funcionar, el disseny ha amagat la pregunta real. Els clients o arriben a l'adreça privada pel túnel o arriben al punt final públic per internet, i els dos camins tenen grups de seguretat diferents, registres diferents i maneres de fallar diferents.

L'adreça mai no va ser el problema. La selecció del camí sí.

Tres objectius, tres dissenys

Si l'objectiu és un punt final VPN públic, l'Elastic IP és l'eina correcta: els parells remots s'hi connecten per internet i el transport xifrat acaba a la instància. El trànsit intern de l'aplicació fa servir llavors l'adreça privada.

Si l'objectiu és l'accés privat a l'aplicació, la destinació és l'adreça privada o un nom DNS privat que hi resolgui, i la ruta VPN, el grup de seguretat i el camí de retorn han de coincidir tots. L'Elastic IP no apareix en aquest disseny.

Si l'objectiu és una identitat de sortida pública estable per als usuaris de VPN, això és un disseny NAT al costat de sortida, no una adreça al túnel del client. Tres objectius que sonen igual produeixen tres diagrames diferents, i només un implica posar una Elastic IP en un lloc nou.

Verifiqueu el camí que heu triat

Per a l'accés privat, confirmeu que la ruta VPN cobreix el prefix privat, que la taula de rutes de la VPC retorna el trànsit al túnel, que el grup de seguretat permet l'origen del client i que el tallafoc propi del client permet la resposta. Després proveu una petició real en lloc d'un ping.

Per a l'accés públic, confirmeu la sortida a internet del client, l'encaminament de l'entrada pública i la seva política de seguretat. Que un client VPN pugui arribar a un punt final públic pel túnel depèn de les regles de sortida i del tallafoc del túnel, no de l'associació de l'Elastic IP.

Si un nom d'amfitrió públic ha de funcionar des dels dos costats, feu servir un disseny DNS que respongui amb l'adreça privada per als clients VPN i amb l'adreça pública per a tota la resta, i manteniu el certificat vàlid per al nom i no per a l'adreça. Ordre de treball: anomeneu l'objectiu, trieu l'adreça que hi pertany, i després verifiqueu rutes, política i una petició.