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 връща трафика към тунела, групата за сигурност разрешава източника на клиента и собствената защитна стена на клиента разрешава отговора. След това тествайте една реална заявка, а не ping.

За публичен достъп потвърдете интернет изхода на клиента, маршрутизацията на публичния вход и неговата политика за сигурност. Дали VPN клиент може да достигне публична крайна точка през тунела зависи от правилата за изход и защитна стена на тунела, не от асоциацията с Elastic IP.

Ако публично име на хост трябва да работи от двете страни, използвайте DNS дизайн, който отговаря с частния адрес за VPN клиентите и с публичния адрес за всички останали, и дръжте сертификата валиден за името, а не за адреса. Ред на работа: назовете целта, изберете адреса, който ѝ принадлежи, след това проверете маршрути, политика и една заявка.