EC2 Elastic IP není privátní VPN adresa instance

Instance má privátní adresu, Elastic IP je s ní spojena a do VPN se přidává cesta pro tuto veřejnou /32 v naději, že obě věci se stanou tímtéž. Nestanou. Elastic IP je překlad prováděný mimo hosta, internetovou branou, na provozu, který jde internetovou cestou. Operační systém hosta nikdy nevidí tuto adresu nakonfigurovanou na rozhraní. Přidání na rozhraní tunelu nenapodobuje překlad výše a vytváří druhou, konfliktní identitu pro stejný stroj.

Dvě adresy, jedna instance

Síťové rozhraní instance drží privátní adresu uvnitř VPC, a to je adresa, kterou host zná. Elastic IP je spojena se stejným rozhraním, ale žije na veřejné straně mapování.

Vše, co se k instanci dostane přes internet, přichází přeloženo na privátní adresu. Vše, co instance pošle na internet, odchází s Elastic IP jako zdrojem, opět kvůli tomuto překladu.

Uvnitř hosta existuje jedna adresa. Venku dvě. Tato asymetrie vysvětluje většinu zmatku v této oblasti. Host nemůže konfigurovat, co brána překládá. Může odpovídat jen na adrese, kterou skutečně drží.

Co internetová brána skutečně dělá

Dokumentace AWS k internetové bráně popisuje uspořádání: instance zná svou privátní adresu IPv4 a brána zajišťuje odpovídající překlad veřejné IPv4 nebo Elastic IP pro provoz na internetové cestě.

To je překlad síťových adres, ne alias. Mapování udržuje brána, je vázáno na asociaci a platí jen pro pakety, které jí procházejí. Odeberte asociaci a veřejná identita zmizí, aniž by host cokoli poznal.

Proto se privátní VPN paket adresovaný veřejné /32 nepřekládá znovu jako privátní paket na lokální adresu hosta. Paket sleduje cestu, které odpovídá, a ta jej posílá internetové bráně; chování brány závisí na tom, zda je cesta povolena v obou směrech.

Proč trik s rozhraním tunelu selhává

Přiřazení Elastic IP rozhraní tunelu žádá hosta, aby s veřejnou adresou zacházel jako s lokální. Nyní si na stejnou adresu činí nárok dvě věci: překlad brány na internetové cestě a lokální rozhraní uvnitř tunelu. Zpětný provoz nemá konzistentní odpověď, které z nich platí.

I když to vypadá, že funguje, návrh skryl skutečnou otázku. Klienti buď dosáhnou privátní adresy tunelem, nebo dosáhnou veřejného koncového bodu přes internet, a obě cesty mají jiné skupiny zabezpečení, jiné protokolování a jiné režimy selhání.

Adresa nikdy nebyla problém. Výběr cesty byl.

Tři cíle, tři návrhy

Pokud je cílem veřejný koncový bod VPN, Elastic IP je správný nástroj: vzdálení partneři se k němu připojují přes internet a šifrovaný přenos končí na instanci. Vnitřní provoz aplikace pak používá privátní adresu.

Pokud je cílem privátní přístup k aplikaci, cílem je privátní adresa nebo privátní jméno DNS, které na ni přeloží, a VPN cesta, skupina zabezpečení a zpětná cesta se musí shodovat. Elastic IP se v tomto návrhu vůbec neobjevuje.

Pokud je cílem stabilní veřejná výstupní identita pro uživatele VPN, to je návrh NAT na výstupní straně, ne adresa na tunelu klienta. Tři cíle, které znějí podobně, dávají tři různé diagramy a jen jeden z nich zahrnuje umístění Elastic IP na nové místo.

Ověřte cestu, kterou jste zvolili

U privátního přístupu ověřte, že VPN cesta pokrývá privátní prefix, že směrovací tabulka VPC vrací provoz do tunelu, že skupina zabezpečení povoluje zdroj klienta a že vlastní firewall klienta povoluje odpověď. Pak otestujte jeden skutečný požadavek místo ping.

U veřejného přístupu ověřte internetový výstup klienta, směrování veřejného vstupu a jeho bezpečnostní politiku. Zda se klient VPN dostane tunelem na veřejný koncový bod, závisí na pravidlech výstupu a firewallu tunelu, ne na asociaci Elastic IP.

Pokud má veřejné jméno hostitele fungovat z obou stran, použijte návrh DNS, který odpovídá privátní adresou klientům VPN a veřejnou adresou všem ostatním, a držte certifikát platný pro jméno, ne pro adresu. Pořadí práce: pojmenujte cíl, zvolte adresu, která k němu patří, a pak ověřte cesty, politiku a jeden požadavek.