Kādu avota IP izmanto AWS NAT vārteja pret VPN?

Jūs atverat VPC konsoli, jo partneris jautāja, kurš avota diapazons ieradīsies caur VPN no vietas uz vietu. NAT vārteju lapā ir redzama publiska vārteja ar pievienotu Elastic IP, un kārdinājums ir nosūtīt šo adresi un doties tālāk. Tā ir pareizā atbilde interneta ceļam un nepareizā atbilde VPN ceļam, un atšķirība ir tajā, uz kuru vārteju norāda maršrutēšanas tabula. Izstaigājiet maršrutu, pirms rakstāt atļauto sarakstu.

Sāciet NAT vārteju lapā, nevis atļauto sarakstā

NAT vārteju lapa jums norāda apakštīklu, tipu un Elastic IP, un ar šiem trim laukiem pietiek, lai sāktu. Ko tā nenorāda, ir ceļš, ko satiksme veic pēc tam. Tas izriet no maršrutēšanas tabulām, kas pievienotas NAT vārtejas apakštīklam.

Vispirms izlasiet tipu, jo publiska vai privāta nosaka, vai vēlāk ķēdē parādīsies interneta vārteja. Pēc tam izlasiet apakštīklu, jo tur atrodas otrais maršruts.

Sekojiet abām pārvērtībām

Gan publiskas, gan privātas NAT vārtejas pārvērš darba slodzes privāto IPv4 avotu pašas NAT vārtejas privātajā IPv4 adresē. Šī pirmā pārvērtība notiek neatkarīgi no tipa. Otrā pārvērtība ir tā, ko aizmirst: publiska NAT vārteja nodod satiksmi interneta vārtejai, kas kartē adresi uz pievienoto Elastic 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

Privātajā ceļā ķēdē nav interneta vārtejas. Kad satiksme iziet caur tranzīta vārteju vai virtuālu privātu vārteju, NAT vārteju rokasgrāmata dokumentē NAT vārtejas privāto adresi kā avotu, ko saņem tālā puse. Tieši šī adrese partnerim ir jāatļauj, nevis Elastic IP.

VPN ceļš parasti rāda privāto adresi

Darba slodzei 10.20.1.0/24, kas sasniedz partnera prefiksu, darba slodzes apakštīkla maršrutēšanas tabula norāda uz NAT vārteju, un NAT vārtejas apakštīkla maršrutēšanas tabula norāda uz privātās vārtejas ceļu. Abi lēcieni ir svarīgi, un tikai otrais nosaka, ko partneris redz. Ja NAT apakštīklam nav maršruta uz VPN ceļu, pakete nekad neierodas, un tā ir cita kļūme nekā nepareiza avota adrese.

Pārbaudiet šo otro maršrutu, pirms vispār runājat par adresēm. Trūkstošs maršruts un nepareizi paziņots avots partnerim, kurš vienkārši neredz satiksmi, izskatās pilnīgi vienādi.

Kad otrā pārvērtība maina atbildi

AWS piedāvā arī skaidru, atbilstošu viens-pret-vienu NAT kartējumu tranzīta vārtejas piesaistē. Šis kartējums var vēlreiz pārvērst avotu, pirms to ierauga tālā pakalpojums, un tā nav noklusējuma uzvedība, kas tikai maršrutē. Tā kā tas ir jākonfigurē apzināti, uzskatiet to par projektēšanas izņēmumu, nevis kaut ko, ko nejauši manto. Ja neviens jūsu komandā neatceras to ieslēdzis, pieņemiet, ka tā nav, līdz izlasīsiet piesaisti.

Ja jūsu projekts to izmanto, atļauto sarakstam ir jāapraksta galīgais kartējums, nevis NAT vārtejas adrese. Tāda pati piesardzība attiecas uz pieejamības ceļiem: kad piedalās vairākas vārteju adreses, gaidītā avotu kopa ir apvienojums, nevis viena reprezentatīva adrese. Pierakstiet, kurai pārvērtībai pieder katra adrese, jo sarakstu bez izcelsmes vēlāk nav iespējams auditēt.

Privātai NAT vārtejai nevar dot interneta pakalpojumu, vēršot to uz interneta vārteju; AWS dokumentē, ka šāda satiksme tiek izmesta. Izvēlieties tipu pēc visa ceļa, nevis pēc vārda VPN prasībā.

Uzrakstiet līgumu, pēc kura jūsu partneris var rīkoties

Lietojamam līgumam ir četras daļas: virziens, no kura sākas plūsmas, pārtulkotā identitāte, ko partneris redzēs, atgriešanās maršruts šai identitātei un piemērojamā aizsardzības apjoms. NAT vārtejas plūsmas sākas no atbalstītās avota puses, tāpēc tas nav ienākošo portu pāradresācijas pakalpojums privātas darba slodzes atklāšanai. To agri skaļi pateikt novērš projektēšanas pārskatu, kurā katra puse pieņēma, ka sāka otra.

Pārvērtība nopērk atvieglojumu no adrešu pārklāšanās un paredzamu avota politiku, un tā jums izmaksā atsevišķu darba slodzes identitāti partnera žurnālos. Ja auditam nepieciešama attiecināšana pa darba slodzēm, glabājiet šo identitāti lietojumprogrammas slānī, nevis mēģiniet to atgūt no pārtulkotas avota adreses.

Pēc tam pēc jebkuras izmaiņas vēlreiz pārbaudiet abas maršrutēšanas tabulas, jo jauna piesaiste vai no jauna saistīts apakštīkls klusi pārraksta atbildi.