Кой изходен IP използва шлюз NAT на AWS към VPN?

Отваряте конзолата на VPC, защото партньор попита кой диапазон на източника ще пристигне през VPN сайт към сайт. Страницата на шлюзовете NAT показва публичен шлюз с прикачен еластичен IP и изкушението е да изпратите този адрес и да продължите. Това е правилният отговор за интернет пътя и грешният отговор за пътя през VPN, а разликата е кой шлюз сочи таблицата с маршрути. Извървете маршрута, преди да напишете списъка с разрешени адреси.

Започнете от страницата на шлюзовете NAT, не от списъка с разрешени адреси

Страницата на шлюзовете NAT ви казва подмрежата, типа и еластичния IP и тези три полета са достатъчни за начало. Това, което не ви казва, е пътят, който трафикът поема след това. Той идва от таблиците с маршрути, прикачени към подмрежата на шлюза NAT.

Прочетете първо типа, защото публичен или частен решава дали по-късно във веригата ще се появи интернет шлюз. След това прочетете подмрежата, защото там живее вторият маршрут.

Проследете двете трансформации

И публичните, и частните шлюзове NAT преобразуват частния IPv4 източник на работното натоварване в собствения частен IPv4 адрес на шлюза NAT. Тази първа трансформация се случва независимо от типа. Втората трансформация е тази, която хората забравят: публичният шлюз NAT предава трафика на интернет шлюза, който съпоставя адреса с прикачения еластичен IP.

workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> internet gateway -> Elastic IP 203.0.113.25
workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> transit or virtual private gateway -> partner sees 10.20.2.10

По частния път във веригата няма интернет шлюз. Когато трафикът излиза през транзитен шлюз или виртуален частен шлюз, ръководството за шлюзове NAT документира частния адрес на шлюза NAT като източника, който отдалечената страна получава. Това е адресът, който партньорът трябва да разреши, а не еластичният IP.

Пътят през VPN обикновено показва частния адрес

За работно натоварване в 10.20.1.0/24, което достига префикс на партньор, таблицата с маршрути на подмрежата на натоварването сочи към шлюза NAT, а таблицата с маршрути на подмрежата на шлюза NAT сочи към пътя на частния шлюз. И двата прехода са важни и само вторият определя какво вижда партньорът. Ако подмрежата на NAT няма маршрут към пътя през VPN, пакетът никога не пристига и това е различен провал от грешен адрес на източника.

Проверете този втори маршрут, преди изобщо да обсъждате адреси. Липсващ маршрут и погрешно съобщен източник изглеждат еднакво за партньор, който просто не вижда трафик.

Когато втора трансформация промени отговора

AWS предлага също явно, съответстващо съпоставяне NAT едно към едно върху прикачване на транзитен шлюз. Това съпоставяне може да преобразува източника отново, преди отдалечената услуга да го види, и това не е поведението по подразбиране, което само маршрутизира. Понеже трябва да се конфигурира умишлено, третирайте го като изключение в дизайна, а не като нещо, което наследявате случайно. Ако никой в екипа ви не помни, че го е включил, приемете, че липсва, докато не прочетете прикачването.

Ако дизайнът ви го използва, списъкът с разрешени адреси трябва да описва окончателното съпоставяне, а не адреса на шлюза NAT. Същото внимание важи и за пътищата за достъпност: когато участват няколко адреса на шлюзове, очакваният набор от източници е обединението, а не един представителен адрес. Запишете към коя трансформация принадлежи всеки адрес, защото списък без произход е невъзможно да се одитира по-късно.

На частен шлюз NAT не може да се даде интернет услуга, като го насочите към интернет шлюз; AWS документира, че такъв трафик се отхвърля. Изберете типа от пълния път, а не от думата VPN в изискването.

Напишете договора, по който партньорът ви може да действа

Използваемият договор има четири части: посоката, от която се инициират потоците, трансформираната идентичност, която партньорът ще види, обратния маршрут за тази идентичност и обхвата на защита, който се прилага. Потоците през шлюза NAT се инициират от поддържаната страна източник, така че това не е услуга за пренасочване на входящи портове за излагане на частно работно натоварване. Да се каже това на глас рано предотвратява преглед на дизайна, при който всяка страна е предполагала, че другата инициира.

Трансформацията купува облекчение при припокриване на адреси и предвидима политика за източника и ви струва индивидуалната идентичност на работното натоварване в регистрите на партньора. Ако одитът се нуждае от приписване по работно натоварване, дръжте тази идентичност на приложния слой, вместо да се опитвате да я възстановите от трансформиран адрес на източника.

След това проверете отново двете таблици с маршрути след всяка промяна, защото ново прикачване или пресвързана подмрежа безшумно пренаписва отговора.