Који изворни IP користи AWS NAT мрежни пролаз према VPN-у?
Elastic IP јавног NAT пролаза је идентитет на интернету, а не оно што види VPN партнер. Пратите руту од подмреже до пролаза да бисте пронашли прави извор.
Отварате VPC конзолу јер је партнер питао који ће изворни опсег стићи преко VPN-а од локације до локације. Страница NAT пролаза приказује јавни пролаз са придруженим Elastic IP-ом, а искушење је послати ту адресу и наставити даље. То је тачан одговор за интернетску путању и погрешан за VPN путању, а разлика је на који пролаз показује табела рута. Прођите руту пре него што напишете списак дозвољених.
Почните на страници NAT пролаза, а не на списку дозвољених
Страница NAT пролаза вам каже подмрежу, тип и Elastic IP, и та три поља су довољна за почетак. Оно што не каже јесте путања којом саобраћај затим иде. То произилази из табела рута придружених подмрежи NAT пролаза.
Прво прочитајте тип, јер јавни или приватни одређује да ли ће се касније у ланцу појавити интернетски пролаз. Затим прочитајте подмрежу, јер се ту налази друга рута.
Пратите обе конверзије
И јавни и приватни NAT пролази преводе приватни IPv4 извор радног оптерећења у сопствену приватну IPv4 адресу NAT пролаза. Та прва конверзија се дешава без обзира на тип. Друга конверзија је она коју људи заборављају: јавни NAT пролаз предаје саобраћај интернетском пролазу, који мапира адресу на придружени Elastic IP.
workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> internet gateway -> Elastic IP 203.0.113.25workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> transit or virtual private gateway -> partner sees 10.20.2.10
На приватној путањи у ланцу нема интернетског пролаза. Када саобраћај излази кроз транзитни пролаз или виртуелни приватни пролаз, водич за NAT пролазе документује приватну адресу NAT пролаза као извор који прима удаљена страна. Управо ту адресу партнер треба да дозволи, а не Elastic IP.
VPN путања обично приказује приватну адресу
За радно оптерећење у 10.20.1.0/24 које достиже префикс партнера, табела рута подмреже радног оптерећења показује на NAT пролаз, а табела рута подмреже NAT пролаза на путању приватног пролаза. Оба скока су важна, и само други одређује шта партнер види. Ако подмрежа NAT нема руту до VPN путање, пакет никада не стиже, и то је друга врста квара од погрешне изворне адресе.
Проверите ту другу руту пре него што уопште говорите о адресама. Рута која недостаје и погрешно пријављен извор изгледају идентично партнеру који једноставно не види саобраћај.
Када друга конверзија промени одговор
AWS нуди и експлицитно, одговарајуће мапирање NAT један на један на прикључку транзитног пролаза. То мапирање може још једном превести извор пре него што га удаљена услуга види, и то није подразумевано понашање које само усмерава. Пошто се мора намерно конфигурисати, третирајте га као пројектни изузетак, а не као нешто што случајно наследите. Ако се нико у вашем тиму не сећа да га је укључио, претпоставите да га нема док не прочитате прикључак.
Ако га ваш дизајн користи, списак дозвољених мора да описује коначно мапирање, а не адресу NAT пролаза. Иста пажња важи и за путање доступности: када учествује више адреса пролаза, очекивани скуп извора је унија, а не једна репрезентативна адреса. Запишите којој конверзији припада свака адреса, јер списак без порекла није могуће касније ревидирати.
Приватном NAT пролазу не може се дати интернетска услуга усмеравањем на интернетски пролаз; AWS документује да се такав саобраћај одбацује. Изаберите тип према целој путањи, а не према речи VPN у захтеву.
Напишите уговор према којем ваш партнер може да делује
Употребљив уговор има четири дела: смер из којег се токови покрећу, преведени идентитет који ће партнер видети, повратну руту за тај идентитет и примењиви обим заштите. Токови NAT пролаза покрећу се са подржане изворне стране, па то није услуга прослеђивања улазних портова за излагање приватног радног оптерећења. Рећи то наглас рано спречава преглед дизајна у којем је свака страна претпостављала да је покренула друга.
Конверзија купује олакшање од преклапања адреса и предвидиву политику извора, а кошта вас појединачним идентитетом радног оптерећења у записима партнера. Ако ревизија треба придруживање по радном оптерећењу, држите тај идентитет у апликационом слоју уместо да покушавате да га вратите из преведене изворне адресе.
Затим поново проверите обе табеле рута након сваке промене, јер ново придруживање или поново повезана подмрежа тихо преписује одговор.