EC2 Elastic IP nie je súkromná VPN adresa inštancie

Inštancia má súkromnú adresu, Elastic IP je s ňou spojená a do VPN sa pridáva trasa pre túto verejnú /32 v nádeji, že obe sa stanú tým istým. Nestanú. Elastic IP je preklad vykonávaný mimo hosťa, internetovou bránou, na prevádzke, ktorá ide internetovou cestou. Operačný systém hosťa nikdy nevidí túto adresu nakonfigurovanú na rozhraní. Pridanie na rozhranie tunela nenapodobňuje preklad vyššie a vytvára druhú, protirečivú identitu pre ten istý stroj.

Dve adresy, jedna inštancia

Sieťové rozhranie inštancie drží súkromnú adresu vnútri VPC a to je adresa, ktorú hosť pozná. Elastic IP je spojená s tým istým rozhraním, ale žije na verejnej strane mapovania.

Všetko, čo sa k inštancii dostane cez internet, prichádza preložené na súkromnú adresu. Všetko, čo inštancia pošle na internet, odchádza s Elastic IP ako zdrojom, opäť kvôli tomuto prekladu.

Vnútri hosťa existuje jedna adresa. Vonku dve. Táto asymetria vysvetľuje väčšinu zmätku v tejto oblasti. Hosť nemôže konfigurovať, čo brána prekladá. Môže odpovedať len na adrese, ktorú skutočne drží.

Čo internetová brána skutočne robí

Dokumentácia AWS k internetovej bráne opisuje usporiadanie: inštancia pozná svoju súkromnú adresu IPv4 a brána zabezpečuje zodpovedajúci preklad verejnej IPv4 alebo Elastic IP pre prevádzku na internetovej ceste.

To je preklad sieťových adries, nie alias. Mapovanie udržiava brána, je viazané na asociáciu a platí len pre pakety, ktoré cez ňu prechádzajú. Odstráňte asociáciu a verejná identita zmizne bez toho, aby hosť čokoľvek spozoroval.

Preto sa súkromný VPN paket adresovaný verejnej /32 neinterpretuje znova ako súkromný paket na lokálnu adresu hosťa. Paket sleduje trasu, ktorej zodpovedá, a tá ho posiela internetovej bráne; správanie brány závisí od toho, či je cesta povolená v oboch smeroch.

Prečo trik s rozhraním tunela zlyháva

Priradenie Elastic IP rozhraniu tunela žiada hosťa, aby s verejnou adresou zaobchádzal ako s lokálnou. Teraz si na tú istú adresu robia nárok dve veci: preklad brány na internetovej ceste a lokálne rozhranie vnútri tunela. Návratová prevádzka nemá konzistentnú odpoveď, ktorá z nich platí.

Aj keď to vyzerá, že funguje, návrh skryl skutočnú otázku. Klienti buď dosiahnu súkromnú adresu tunelom, alebo dosiahnu verejný koncový bod cez internet, a obe cesty majú iné skupiny zabezpečenia, iné logovanie a iné režimy zlyhania.

Adresa nikdy nebola problém. Výber cesty bol.

Tri ciele, tri návrhy

Ak je cieľom verejný koncový bod VPN, Elastic IP je správny nástroj: vzdialení partneri sa k nemu pripájajú cez internet a šifrovaný prenos končí na inštancii. Vnútorná prevádzka aplikácie potom používa súkromnú adresu.

Ak je cieľom súkromný prístup k aplikácii, cieľom je súkromná adresa alebo súkromné DNS meno, ktoré na ňu prekladá, a VPN trasa, skupina zabezpečenia a návratová cesta sa musia zhodovať. Elastic IP sa v tomto návrhu vôbec neobjavuje.

Ak je cieľom stabilná verejná výstupná identita pre používateľov VPN, je to návrh NAT na výstupnej strane, nie adresa na tuneli klienta. Tri podobne znejúce ciele dávajú tri rôzne diagramy a iba jeden z nich zahŕňa umiestnenie Elastic IP na nové miesto.

Overte cestu, ktorú ste si vybrali

Pri súkromnom prístupe overte, že VPN trasa pokrýva súkromný prefix, že smerovacia tabuľka VPC vracia prevádzku do tunela, že skupina zabezpečenia povoľuje zdroj klienta a že vlastný firewall klienta povoľuje odpoveď. Potom otestujte jednu skutočnú požiadavku namiesto ping.

Pri verejnom prístupe overte internetový výstup klienta, smerovanie verejného vstupu a jeho bezpečnostnú politiku. Či sa klient VPN dostane tunelom na verejný koncový bod, závisí od pravidiel výstupu a firewallu tunela, nie od asociácie Elastic IP.

Ak má verejné meno hostiteľa fungovať z oboch strán, použite návrh DNS, ktorý odpovedá súkromnou adresou klientom VPN a verejnou adresou všetkým ostatným, a držte certifikát platný pre meno, nie pre adresu. Poradie práce: pomenujte cieľ, vyberte adresu, ktorá k nemu patrí, a potom overte trasy, politiku a jednu požiadavku.