EC2 Elastic IP није приватна VPN адреса инстанце

Инстанца има приватну адресу, Elastic IP је повезан са њом, а рута за тај јавни /32 се додаје у VPN у нади да ће то двоје постати исто. Не постају. Elastic IP је превод који се изводи изван госта, од стране интернет пролаза, над саобраћајем који иде интернет путем. Оперативни систем госта никада не види ту адресу конфигурисану на интерфејсу. Њено додавање на тунелски интерфејс не репродукује превод изнад и ствара други, противречан идентитет за исти рачунар.

Две адресе, једна инстанца

Мрежни интерфејс инстанце држи приватну адресу унутар VPC-а, и то је адреса коју гост зна. Elastic IP је повезан са истим интерфејсом, али живи на јавној страни мапирања.

Све што стигне до инстанце преко интернета долази преведено на приватну адресу. Све што инстанца пошаље на интернет излази са Elastic IP-ом као извором, опет због тог превода.

Унутар госта постоји једна адреса. Напољу постоје две. Та асиметрија објашњава већину забуне у овој области. Гост не може да конфигурише шта пролаз преводи. Може да одговори само на адреси коју заиста има.

Шта интернет пролаз заправо ради

AWS документација о интернет пролазу описује распоред: инстанца је свесна своје приватне IPv4 адресе, а пролаз обезбеђује одговарајући превод на јавну IPv4 или Elastic IP за саобраћај на интернет путу.

То је превод мрежних адреса, не псевдоним. Мапирање одржава пролаз, оно је везано за асоцијацију и важи само за пакете који кроз њега пролазе. Уклоните асоцијацију и јавни идентитет нестаје без да гост ишта примети.

Зато се приватни VPN пакет упућен на јавни /32 не претумачује као приватни пакет на локалну адресу госта. Пакет следи руту којој одговара, која га шаље интернет пролазу, а понашање пролаза зависи од тога да ли је пут дозвољен у оба смера.

Зашто трик са тунелским интерфејсом не успева

Додела Elastic IP-а тунелском интерфејсу тражи од госта да јавну адресу третира као локалну. Сада две ствари полажу право на исту адресу: превод пролаза на интернет путу и локални интерфејс унутар тунела. Повратни саобраћај нема доследан одговор која од њих важи.

Чак и када изгледа да ради, дизајн је сакрио право питање. Клијенти или достижу приватну адресу кроз тунел или достижу јавну завршну тачку преко интернета, а та два пута имају различите сигурносне групе, различито евидентирање и различите начине отказа.

Адреса никада није била проблем. Избор пута је био.

Три циља, три дизајна

Ако је циљ јавна VPN завршна тачка, Elastic IP је прави алат: удаљени партнери се повезују преко интернета и шифровани пренос се завршава на инстанци. Унутрашњи саобраћај апликације затим користи приватну адресу.

Ако је циљ приватан приступ апликацији, одредиште је приватна адреса или приватно DNS име које се на њу разрешава, а VPN рута, сигурносна група и повратни пут морају сви да се сложе. Elastic IP се у том дизајну уопште не појављује.

Ако је циљ стабилан јавни идентитет излаза за VPN кориснике, то је NAT дизајн на излазној страни, а не адреса на тунелу клијента. Три циља која звуче слично дају три различита дијаграма, и само један од њих укључује постављање Elastic IP-а на ново место.

Проверите пут који сте изабрали

За приватан приступ потврдите да VPN рута покрива приватни префикс, да табела рута VPC-а враћа саобраћај у тунел, да сигурносна група дозвољава извор клијента и да сопствени firewall клијента дозвољава одговор. Затим тестирајте један стварни захтев уместо ping.

За јаван приступ потврдите интернет излаз клијента, рутирање јавног улаза и његову сигурносну политику. Да ли VPN клијент може да достигне јавну завршну тачку кроз тунел зависи од правила излаза и firewall-а тунела, не од асоцијације Elastic IP-а.

Ако јавно име хоста треба да ради са обе стране, користите DNS дизајн који одговара приватном адресом за VPN клијенте и јавном адресом за све остале, и држите сертификат важећим за име, а не за адресу. Редослед рада: именујте циљ, изаберите адресу која му припада, затим проверите руте, политику и један захтев.