Anypoint VPN apo NAT në Transit Gateway: ku bëhet përkthimi

Një kërkesë për NAT nuk është kërkesë derisa të emërojë adresat që ndryshojnë dhe komponentin që lejohet t'i ndryshojë ato. Në lidhshmërinë MuleSoft ajo vendimmarrje ka tre hyrje: nëse backend-i ka nevojë për përkthim portash shumë-në-një apo për një pseudonim prefiksi një-në-një, nëse lidhja AWS që zotëroni vërtet mund ta kryejë atë hartëzim, dhe nëse e gjithë rruga mbetet brenda një kombinimi që furnizuesi mbështet. Nëse këto gabohen, do të ndërtoni një laborator që funksionon por dështon në shqyrtim.

Pika e vetme e palëvizshme është se vetë Anypoint VPN nuk është pajisje përkthimi. Dokumentacioni i CloudHub 2.0 e liston NAT si të pambështetur atje, ndaj çdo dizajn që supozon se tuneli do të fshehë adresat e punëtorëve tuaj është tashmë i prishur.

Vendosni çfarë duhet të bëjë përkthimi

Nëse shumë punëtorë aplikacioni duhet t'i shfaqen backend-it si një adresë e vetme, kërkesa është përkthim i përbashkët i burimit, zakonisht SNAT ose PAT me gjendje në një firewall që ju kontrolloni. Ai element duhet të qëndrojë në një rrugë të miratuar, ta mbajë gjendjen e tij gjatë gjithë jetës së fluksit dhe të shohë trafikun e kthimit për çdo lidhje që ka rishkruar. Humbja e gjendjes në mes të sesionit nuk e përkeqëson lidhjen; e përfundon atë. Një palë firewall-e që refuzon të ndajë gjendjen e përkthimit do të hedhë çdo sesion që pas kalimit zbret në anëtarin rezervë. Përmasojeni atë element për flukset e njëkohshme, jo për xhiron.

Nëse përkundrazi dy rrjeta mbivendosen dhe çdo host ka nevojë për një pseudonim të veçantë, kërkesa është një plan adresash një-në-një me prefikse të hartëzuara pa paqartësi, rrugë përputhëse dhe zgjidhje emrash që përputhet me hartëzimin. Fshehja e çdo punëtori pas një adrese të vetme nuk është versioni më i lirë i kësaj, dhe zëvendësimi i njërës me tjetrën në një shqyrtim dizajni është mënyra se si projektet humbin një tremujor.

Regjistroni vendimin me terma konkretë përpara se të zgjidhni një produkt: burimi origjinal, destinacioni origjinal, vlera e përkthyer, drejtimi i nisjes, pronari i përkthyesit dhe rruga e pritshme e përgjigjes. Shtoni edhe çfarë identiteti do të mbajnë regjistrat e backend-it, sepse një dizajn që fsheh të gjitha burimet shkatërron edhe auditimin për çdo klient.

Kontrolloni nëse AWS mund ta bëjë hartëzimin për ju

AWS tani dokumenton NAT të menaxhuar një-në-një në lidhjet Transit Gateway dhe Cloud WAN, shpallur në fund të tetorit 2026, ndaj pretendimi i vjetër i përgjithshëm se një portë tranziti nuk mund të përkthejë kurrë është i tejkaluar. Dokumentacioni i Transit Gateway NAT përshkruan një hartëzim prefiksesh IPv4 pa gjendje: prefikset origjinale dhe të përkthyera mbajnë të njëjtën gjatësi, dhe bitet e hostit e portat e transportit i mbijetojnë përkthimit. Lexoni drejtimet hyrëse dhe dalëse si vendime dizajni të veçanta, sepse konfigurohen veçmas dhe njëra mund të jetë gati ndërsa tjetra jo. Asgjë në atë përshkrim nuk nënkupton gjendje për fluks, ndaj mos prisni që hartëzimi t'i ndjekë lidhjet në vendin tuaj.

Kjo do të thotë që 10.80.0.0/16 i hartëzuar në 172.28.0.0/16 e kthen 10.80.10.23 në 172.28.10.23. Nuk e shemb /16 në një adresë të vetme dhe nuk e zëvendëson një kërkesë për PAT. Mbulon gjithashtu lloje të zgjedhura lidhjesh, ndër të cilat VPC dhe Site-to-Site VPN, por jo lidhjet Client VPN, dhe konfigurimi qëndron te pronari i portës së tranzitit, jo në anën Anypoint.

Trajtojeni veçorinë si një pikë tjetër e mundshme kontrolli, jo si provë që vendosja juaj mund ta përdorë. CloudHub 2.0 dokumenton lidhje të hapësirës private me një portë tranziti në llogarinë AWS të vetë klientit, me kushte rajonale dhe kushte të drejte, ndaj konfirmoni llojin real të lidhjes, pronarin e saj dhe qëndrimin e furnizuesit për mbështetje përpara se të dizajnoni rreth opsionit të ri.

Mbajeni rrugën brenda një kufiri të mbështetur

Për një përkthyes në firewall, përdorni modelin e mbështetur të VPN-së, përkthimit dhe rrugëzimit të atij produkti në vend që të ngjitni një rregull të përgjithshëm NAT në një tunel që funksionon. Përgjigja e backend-it duhet të kthehet përmes të njëjtit element përkthimi, dhe një tunel dalës i shëndoshë nuk thotë asgjë për atë rrugë kthimi.

Për rrugën e portës së tranzitit, inventarizoni lidhjen e hapësirës private, tabelat përkatëse të rrugëve, lidhjen në vend dhe pjesët që klienti vërtet mund t'i konfigurojë. Kjo është një arkitekturë tjetër lidhshmërie, jo një kuti kontrolli NAT e vidhosur në një lidhje ekzistuese Anypoint VPN, dhe kufiri i mbështetjes lëviz bashkë me të.

Krahasoni tre opsionet në një tabelë

Shumica e ekipeve duhet të përgjigjen vetëm për dy pyetje: shumë-në-një apo një-në-një, dhe kush e zotëron lidhjen. Tabela më poshtë i kthen ato përgjigje në një opsion fillestar.

Lexojeni kolonën e tretë si pyetjen e shqyrtimit, jo si një mendim të mëvonshëm. Një hartë prefiksesh e lejuar në letër por e konfiguruar në një lidhje që nuk e zotëroni mbetet një projekt i bllokuar, dhe një rregull PAT që lë trafikun të kalojë por prish regjistrimin për çdo klient dështon në auditimin që vjen më pas.

Vërtetoni hartëzimin përpara se ta premtoni

Kaloni një operacion të ri aplikacioni nëpër rrugë dhe konfirmoni përgjigjen, jo vetëm kërkesën. Pyetni pronarin e backend-it se cilën adresë burimi regjistruan regjistrat e tyre, kontrolloni që trajtimi i familjes së adresave përputhet me planin në të dy drejtimet dhe verifikoni që një rrugë që duhet të refuzohet vazhdon të refuzohet. Një lidhje e vjetër nuk provon asgjë për hartëzimin që sapo ndryshuat.

Mbajeni vërtetimin e backend-it të pavarur nga ajo se cila adresë e përkthyer plotëson listën e lejuar, sepse hartëzimi është hidraulikë rrjeti dhe jo një vendim kontrolli aksesi. Në momentin që rivendosja e fjalëkalimit varet nga një prefiks NAT, çdo ndryshim i ardhshëm i intervalit bëhet ndërprerje.

Përpara miratimit, shkruani tre përgjigjet: lloji i përkthimit, pronari i përkthyesit dhe lidhja ose rruga e produktit e mbështetur që e mban. Nëse ndonjëra prej tyre është ende hamendje, dizajni nuk është gati për një dritare ndryshimesh.