Un Elastic IP EC2 non è l'indirizzo VPN privato dell'istanza

L'istanza ha un indirizzo privato, l'Elastic IP vi è associato, e una rotta per quel /32 pubblico viene aggiunta alla VPN nella speranza che i due diventino la stessa cosa. Non lo diventano. Un Elastic IP è una traduzione eseguita fuori dall'ospite, dal gateway internet, sul traffico che segue il percorso internet. Il sistema operativo dell'ospite non vede mai quell'indirizzo configurato su un'interfaccia. Aggiungerlo a un'interfaccia di tunnel non riproduce la traduzione a monte e crea una seconda identità, in conflitto, per la stessa macchina.

Due indirizzi, una istanza

L'interfaccia di rete dell'istanza contiene un indirizzo privato all'interno del VPC, e quello è l'indirizzo che l'ospite conosce. L'Elastic IP è associato alla stessa interfaccia ma vive sul lato pubblico della mappatura.

Tutto ciò che raggiunge l'istanza via internet arriva tradotto sull'indirizzo privato. Tutto ciò che l'istanza invia su internet esce con l'Elastic IP come origine, ancora una volta a causa di quella traduzione.

Dentro l'ospite esiste un indirizzo. Fuori ne esistono due. Questa asimmetria spiega gran parte della confusione in questo campo. L'ospite non può configurare ciò che il gateway traduce. Può rispondere solo sull'indirizzo che possiede davvero.

Che cosa fa davvero il gateway internet

La documentazione AWS sul gateway internet descrive la disposizione: l'istanza è consapevole del proprio indirizzo IPv4 privato e il gateway fornisce la traduzione corrispondente in IPv4 pubblico o Elastic IP per il traffico sul percorso internet.

Questa è traduzione degli indirizzi di rete, non un alias. La mappatura è mantenuta dal gateway, è legata all'associazione e si applica solo ai pacchetti che la attraversano. Rimuovete l'associazione e l'identità pubblica scompare senza che l'ospite noti nulla.

Per questo un pacchetto VPN privato indirizzato al /32 pubblico non viene reinterpretato come un pacchetto privato verso l'indirizzo locale dell'ospite. Il pacchetto segue la rotta con cui corrisponde, che lo invia al gateway internet, e il comportamento del gateway dipende dal fatto che il percorso sia consentito in entrambe le direzioni.

Perché il trucco dell'interfaccia di tunnel fallisce

Assegnare l'Elastic IP a un'interfaccia di tunnel chiede all'ospite di trattare un indirizzo pubblico come locale. Ora due cose rivendicano lo stesso indirizzo: la traduzione del gateway sul percorso internet e l'interfaccia locale dentro il tunnel. Il traffico di ritorno non ha una risposta coerente su quale si applichi.

Anche quando sembra funzionare, il progetto ha nascosto la vera domanda. I client raggiungono o l'indirizzo privato attraverso il tunnel o l'endpoint pubblico attraverso internet, e i due percorsi hanno gruppi di sicurezza diversi, registrazione diversa e modalità di guasto diverse.

L'indirizzo non è mai stato il problema. Lo era la scelta del percorso.

Tre obiettivi, tre progetti

Se l'obiettivo è un endpoint VPN pubblico, l'Elastic IP è lo strumento giusto: i peer remoti vi si connettono via internet e il trasporto cifrato termina sull'istanza. Il traffico interno dell'applicazione usa poi l'indirizzo privato.

Se l'obiettivo è l'accesso privato all'applicazione, la destinazione è l'indirizzo privato o un nome DNS privato che vi risolve, e la rotta VPN, il gruppo di sicurezza e il percorso di ritorno devono tutti concordare. L'Elastic IP non compare affatto in quel progetto.

Se l'obiettivo è un'identità di uscita pubblica stabile per gli utenti VPN, quello è un progetto NAT sul lato uscita, non un indirizzo sul tunnel del client. Tre obiettivi che suonano simili producono tre diagrammi diversi, e solo uno di essi comporta mettere un Elastic IP in un posto nuovo.

Verificate il percorso scelto

Per l'accesso privato, verificate che la rotta VPN copra il prefisso privato, che la tabella delle rotte del VPC riporti il traffico al tunnel, che il gruppo di sicurezza consenta l'origine del client e che il firewall del client consenta la risposta. Poi provate una richiesta reale invece di un ping.

Per l'accesso pubblico, verificate l'uscita internet del client, l'instradamento dell'ingresso pubblico e la sua politica di sicurezza. Se un client VPN possa raggiungere un endpoint pubblico attraverso il tunnel dipende dalle regole di uscita e dal firewall del tunnel, non dall'associazione dell'Elastic IP.

Se un nome host pubblico deve funzionare da entrambi i lati, usate un progetto DNS che risponda con l'indirizzo privato per i client VPN e con l'indirizzo pubblico per tutti gli altri, e mantenete il certificato valido per il nome invece che per l'indirizzo. Ordine di lavoro: nominate l'obiettivo, scegliete l'indirizzo che gli appartiene, poi verificate rotte, politica e una richiesta.